퀴즈: 대시보드의 비용

패널 8개에 쿼리가 모두 10개이고, 목록을 서버에 물어보는 변수가 2개인 대시보드가 있다. 자동 새로고침이 10초일 때 1분 동안 날아가는 패널 쿼리는 몇 번인가?

• 12번 — 한 번 열 때의 질의 수와 같다
• 60번 — 쿼리 10개가 1분에 6번씩 다시 날아간다
• 80번 — 패널 8개에 10초 주기를 곱한다
• 10번 — 새로고침은 화면만 다시 그린다

rate(http_request_duration_seconds_bucket{job="shop-api"}[5m]) 를 그대로 시계열 패널에 그렸다. 핸들러가 4개이고 버킷 경계가 12개일 때 이 패널이 받는 계열은 몇 개인가?

• 4개 — 핸들러마다 하나씩 온다
• 12개 — 버킷마다 하나씩 온다
• 16개 — 핸들러 수와 버킷 수를 더한다
• 48개 — 핸들러 수와 버킷 수를 곱한다

같은 쿼리를 같은 2시간 구간에 던지면서 step 만 15초에서 300초로 바꿨다. 계열 하나에 돌아오는 점 개수는 어떻게 되나?

• 20분의 1쯤으로 줄어든다
• 거의 그대로다 — step 은 표시 간격일 뿐이다
• 20배로 늘어난다
• 시간 범위가 같으므로 변하지 않는다

버킷 계열 마흔여덟 개에서 매번 분위수를 계산하는 패널이 있다. 레코딩 룰로 옮기면 무엇이 달라지나?

• 대시보드가 쿼리를 아예 던지지 않게 된다
• 계산이 정해진 주기에 한 번만 일어나고 패널은 결과를 읽기만 한다
• Prometheus 가 저장하는 시계열 수가 줄어든다
• 패널의 자동 새로고침 주기가 규칙의 주기로 바뀐다

어느 패널도 참조하지 않는 드롭다운 변수가 대시보드 위쪽에 두 개 남아 있다. 이것을 지워야 하는 이유는?

• 변수가 있으면 패널 쿼리가 느려진다
• 변수가 많으면 대시보드 JSON 이 커져 저장이 실패한다
• 대시보드를 열 때마다 목록을 채우려고 질의가 날아간다
• 변수가 있으면 자동 새로고침이 꺼진다

대시보드 비용을 절대 수치(밀리초)로 잡지 않고 개수로 잡는 예산이 더 나은 이유는?

• 개수는 대시보드 JSON 만으로 다시 셀 수 있어 누가 언제 재도 같은 값이 나온다
• 밀리초는 Prometheus 가 기록하지 않아 구할 방법이 아예 없다
• 개수로 잡으면 쿼리의 무게 차이까지 정확히 반영된다
• 밀리초 예산은 Grafana 가 저장 단계에서 거부한다