패널은 정확했고, 질문이 달랐다

한 줄 요약

패널이 틀린 값을 그리는 일은 드물다. 흔한 것은 우리가 묻지 않은 질문의 답을 패널이 정확하게 보여 주고 있는 것이다.

왜 이게 필요했나

장애가 끝난 뒤 회고에서 자주 나오는 문장이 있다. "대시보드는 정상이었는데요." 그런데 같은 시간의 원본 자료를 다시 재 보면 이상은 분명히 있었다. 쿼리도 맞았고 데이터도 있었다. 그 사이에서 사라진 것은 패널 옵션이다.

숫자 하나를 크게 보여 주는 패널이 있다고 하자. 사람들은 그것을 "지금 값" 으로 읽는다. 그런데 그 패널이 실제로 계산하는 것은 화면에 보이는 시간 범위의 평균일 수 있다. 여섯 시간을 보고 있었다면, 20분짜리 급증은 평균 속에서 거의 사라진다. 패널은 정확했다. 다만 "지난 여섯 시간의 평균이 얼마인가" 라는, 아무도 하지 않은 질문에 답하고 있었다.

빠진 점도 마찬가지다. 수집이 30분 끊기면 그 구간에는 점이 없다. 선을 그대로 이으면 그래프는 매끈하게 흐르고, 보는 사람은 그 30분 동안에도 서비스가 잘 돌고 있었다고 읽는다. 끊긴 것은 자료가 없다는 사실인데, 이어 그리는 선택이 그 사실을 지워 버린다.

어떻게 동작하나

Grafana 의 패널은 크게 세 겹이다. 쿼리가 시계열을 가져오고, 필드 설정과 변환이 그것을 다듬고, 시각화 옵션이 그리는 방법을 정한다. 잘못 읽히는 패널은 대부분 두 번째와 세 번째 겹에서 생긴다. 그래서 쿼리를 아무리 들여다봐도 원인이 안 보인다.

| 옵션 | 무엇을 정하나 | 잘못 두면 |
| --- | --- | --- |
| 계산값(reduceOptions.calcs) | 시계열 하나를 숫자 하나로 줄이는 방법 | 평균으로 두면 급증이 묻힌다 |
| 널 처리(spanNulls) | 빠진 점을 이을 것인가 | 이으면 수집 중단이 지워진다 |
| 스택(stacking.mode) | 계열을 쌓을 것인가 | 쌓으면 개별 값을 읽을 수 없다 |
| 계열 수 | 패널 하나가 몇 개를 보이나 | 값 하나짜리 질문에 상자가 넷이 뜬다 |

계산값부터 보자. 시계열은 점이 여럿인데 숫자 하나짜리 패널은 그중 하나를 골라야 한다. 마지막 값을 고르면 "지금", 평균을 고르면 "이 기간 평균", 최댓값을 고르면 "이 기간 최악" 이다. 셋은 전혀 다른 질문이고, 패널 제목은 셋을 구분해 주지 않는다. 그래서 제목이 "요청률" 이면 사람들은 반드시 "지금 요청률" 로 읽는다. 그 읽기와 패널의 계산이 어긋나 있으면 화면은 조용히 틀린다.

널 처리는 세 갈래다. 이어 그리기·끊기·0 으로 채우기. 셋은 각각 "그 사이에도 값이 있었다"·"그 사이는 모른다"·"그 사이는 0 이었다" 를 주장한다. 카운터의 변화율처럼 수집이 끊기면 정말로 알 수 없는 값은 끊어 그려야 하고, 큐 길이처럼 0 이 의미 있는 값은 상황에 따라 다르다. 중요한 것은 어느 쪽이든 주장을 하고 있다는 사실을 알고 고르는 것이다.

스택은 전체 합을 보고 싶을 때만 옳다. 쌓아 올린 그래프의 맨 위 선은 어느 계열의 값도 아니라 전부의 합인데, 사람 눈은 맨 위 선을 "가장 큰 계열" 로 읽는다. 계열끼리 견주는 것이 목적이라면 쌓지 않아야 하고, 비중이 궁금하다면 100% 스택처럼 비율을 명시적으로 말하는 모양을 쓴다.

마지막으로 제목과 설명이다. Grafana 의 패널에는 설명을 적는 자리가 있고([패널 편집 문서](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/configure-panel-options/)), 거기에 질문 문장을 적어 두면 두 가지가 한꺼번에 해결된다. 읽는 사람은 이 패널을 어떻게 읽어야 하는지 알게 되고, 반년 뒤에 이 패널을 지워도 되는지도 판단할 수 있다 — 그 질문을 아직 하고 있는가만 보면 되기 때문이다.

현장에서 만나는 모습

결제 서비스의 상태 대시보드에서 실제로 있었던 일이다. 오류율 패널은 종일 초록이었는데 고객 문의는 계속 들어왔다. 패널은 stat 이었고 계산값이 평균이었으며 기본 시간 범위가 24시간이었다. 오전에 12분 동안 오류율이 30% 였지만 하루 평균으로는 0.25% 였다. 계산값을 마지막 값으로 바꾸고 시간 범위를 한 시간으로 줄이자, 같은 사고가 다음 주에 3분 만에 눈에 띄었다.

또 하나는 스택이었다. 핸들러별 요청률 패널이 스택으로 그려져 있었고, 팀은 맨 위 선을 /api/orders 의 요청률로 읽고 용량 계획을 세웠다. 실제 /api/orders 는 그 절반이었다. 숫자를 고친 것이 아니라 쌓기를 끈 것만으로 오해가 사라졌다.

이 환경에서 판정할 수 있는 것과 없는 것

이 파드의 Grafana 는 진짜로 돌지만 이미지 렌더러 플러그인이 없다. 그래서 패널이 화면에 어떻게 그려지는지는 검사할 수 없다. 대신 대시보드 JSON 모델(계산값·널 처리·스택·제목·설명)과 그 쿼리를 데이터소스로 실제 실행한 값으로 판정한다. 색이 실제로 어떻게 보이는지, 선이 어디서 끊기는지는 결국 눈으로 한 번 봐야 한다 — 실습에서도 웹 프리뷰로 3000번 포트를 열어 확인해 보기를 권한다.

다음 실습에서 할 것

결함 여섯 개가 든 대시보드를 그대로 올려 놓고, 계산값·널 처리·스택·계열 수·제목과 설명을 하나씩 고친다. 고칠 때마다 왜 그 선택이 틀렸는지를 숫자로 확인한다 — 고정 구간에서 last·mean·max 를 직접 재고, 한 시각에서 합과 개별 값을 각각 재어 스택이 무엇을 숨겼는지 본다. 마지막에는 같은 결함을 다음 대시보드에서도 잡는 검사기를 만들어, 고친 대시보드가 그 검사기를 통과하는 것까지 확인한다.