대시보드를 복사하는 순간 갈라진다

한 줄 요약

템플릿 변수는 대시보드를 복사하지 않게 해 준다. 복사본은 반드시 갈라지고, 갈라진 뒤에는 어느 쪽이 맞는지 아무도 모른다.

왜 이게 필요했나

서비스가 열둘이면 대시보드를 열둘 만드는 것이 처음에는 자연스럽다. 하나 만들어 두고 복사해서 쿼리의 서비스 이름만 바꾸면 되니까.

문제는 그다음이다. 오류율 패널에 5분 rate 대신 1분 rate 를 쓰기로 정하면 열두 곳을 고쳐야 하고, 실제로는 서너 곳만 고쳐진다. 그리고 열세 번째 서비스가 생겼을 때 아무도 대시보드를 만들지 않는다. 그 서비스는 장애가 나기 전까지 아무에게도 안 보인다.

변수는 이 문제를 구조적으로 없앤다. 대시보드는 하나고, 보는 대상만 화면 위 드롭다운에서 바뀐다.

어떻게 동작하나

변수에는 여러 종류가 있는데 실무에서 갈리는 것은 둘이다.

| 종류 | 값이 어디서 오나 | 문제 |
|---|---|---|
| custom | 사람이 목록을 적어 둔다 | 대상이 하나 늘면 그날로 낡는다 |
| query | 데이터에서 읽어 온다 | 없다. 이걸 쓴다 |

프로메테우스 데이터소스에서는 label_values 로 읽는다.

label_values(http_requests_total, handler)

지금 데이터에 실제로 존재하는 handler 값들이 드롭다운이 된다. 핸들러가 하나 늘면 드롭다운에도 저절로 는다.

그리고 변수는 선언만으로는 아무 일도 하지 않는다. 패널 쿼리가 그 변수로 좁혀져야 한다.

sum(rate(http_requests_total{handler="$handler"}[5m]))

표기는 $handler, ${handler}, [[handler]] 셋 다 된다. 값이 여럿 선택되는 변수(multi-value)라면 = 가 아니라 =~"$handler" 로 쓴다 — Grafana 가 값들을 a|b|c 형태로 이어 붙이기 때문이다.

흔한 착각

"변수를 넣으면 느려진다." 대개 반대다. 변수로 좁힌 쿼리는 읽는 시계열이 줄어 오히려 빨라진다. 느려지는 것은 값이 수천 개인 라벨을 변수로 만들었을 때인데, 그건 변수의 문제가 아니라 그 라벨을 드롭다운으로 고를 수 없다는 신호다.

"변수 이름은 아무거나." 라벨 이름과 같게 짓는다. $svc 가 job 라벨을 가리키면, 여섯 달 뒤 그 대시보드를 고치는 사람이 반드시 헷갈린다.

실무에서 진짜 중요한 것

알림 규칙에는 대시보드 변수를 쓸 수 없다. 알림은 대시보드 밖에서, 화면 없이 평가된다. $handler 를 풀어 줄 드롭다운이 없으므로 그 글자가 그대로 프로메테우스로 날아가고 쿼리는 문법 오류로 죽는다.

그래서 패널 쿼리를 알림으로 옮길 때는 변수를 반드시 풀어야 한다. 특정 핸들러를 감시하려면 값을 직접 적고, 전체를 보려면 변수 조건을 지운다. 이것이 "대시보드에서 알림을 만든다" 가 복사·붙여넣기로 끝나지 않는 이유다.