5.1 Dashboard 설계
좋은 dashboard는 모든 metric을 보여 주지 않습니다. 특정 상황에서 다음 행동을 결정하게 합니다. PostgreSQL dashboard는 overview, database drill-down, query workload, infrastructure의 네 단계로 나누면 운영 중 길을 잃기 어렵습니다.
1단계: Service overview
첫 화면은 사용자 영향과 database 상태를 함께 보여 줍니다.
| Row | Panel |
|---|---|
| 사용자 영향 | request rate/error rate/p95/p99 latency |
| Database 상태 | up/pg_up/TPS/connection 사용량 |
| 위험 신호 | lock wait/deadlock/oldest transaction/replica lag |
| 자원 | CPU pressure/memory pressure/disk latency/volume 사용률 |
| 변경 | deploy/failover/parameter 변경 annotation |
Overview에서 table별 dead tuple이나 query ID 수백 개를 펼치지 않습니다. 이상을 발견하면 다음 dashboard로 이동합니다.
2단계: Database drill-down
cluster, instance, datname 변수를 선택해 범위를 좁힙니다.
- commit/rollback rate
- active/idle/idle in transaction session
- lock mode와 blocking session
- cache hit/temporary bytes/tuple change rate
- vacuum/analyze/wraparound 위험
- WAL generation/checkpoint/archive
- replication sender/receiver/slot
Panel 제목은 metric 이름보다 질문으로 씁니다. pg_stat_database_xact_commit rate보다 초당 commit은 평소와 다른가?가 incident 중 읽기 쉽습니다.
3단계: Query workload
pg_stat_statements의 top query ID를 총 실행 시간, 호출 수, 평균 시간, block I/O 시간으로 나눕니다. 총부하와 단일 호출 지연은 다른 질문입니다.
총부하 = 호출 수 × 평균 실행 시간
호출이 매우 많은 5ms query와 한 번에 30초 걸리는 query는 대응이 다릅니다. 두 ranking을 같은 table에 섞으면 중요도를 판단하기 어렵습니다.
4단계: Infrastructure
PostgreSQL instance가 올라간 node나 Pod로 연결합니다.
- CPU utilization/run queue/throttling
- memory available/major fault/PSI/OOM
- disk await/IOPS/throughput/queue depth
- filesystem 사용률/inode
- network retransmission/drop
- Kubernetes request/limit/restart/eviction
단위와 축
Panel마다 단위를 명시합니다.
- duration: seconds 또는 milliseconds 중 하나
- size: bytes
- rate: ops/s, bytes/s
- ratio: 0부터 1 또는 percent 중 dashboard 내 통일
- timestamp: timezone 표시
서로 다른 단위의 series를 한 축에 겹치지 않습니다. TPS와 latency를 같은 graph에 올려 상관관계를 보려면 좌우 축과 legend를 명확히 하거나 panel을 나란히 배치합니다.
Threshold는 의미에서 출발한다
CPU 80%를 무조건 빨간색으로 칠하지 않습니다. CPU가 90%여도 latency와 run queue가 안정적일 수 있고, CPU가 30%인데 I/O wait 때문에 서비스가 느릴 수 있습니다.
Threshold는 다음 중 하나에 근거해야 합니다.
- SLO와 사용자 영향
- 실제 hard limit
- capacity lead time
- 과거 incident에서 확인된 위험 지점
- 제품 공식 제약
변경 annotation
배포, failover, restart, configuration 변경을 graph 위에 표시합니다. Metric 변화와 변경 시각이 일치하면 조사 범위를 빠르게 줄일 수 있습니다. Annotation 자체가 원인 증명은 아니므로 rollback 전에는 추가 증거를 확인합니다.
Dashboard review 질문
- 첫 30초 안에 사용자 영향 여부를 판단할 수 있는가?
- 각 panel이 다음 조사 위치를 알려 주는가?
- 같은 metric이 여러 dashboard에 중복되어 있지 않은가?
- No data와 0을 구분하는가?
- Alert에서 관련 dashboard와 runbook으로 바로 이동할 수 있는가?