Observability & Reliability
PostgreSQL을 운영할 때 대시보드가 있다는 사실보다 중요한 것은, 느려짐이나 장애가 발생했을 때 어떤 신호에서 출발해 어디까지 좁혀 갈지 알고 있는가입니다. 이 노트는 PostgreSQL Exporter로 데이터베이스 상태를 수집하는 것부터 Prometheus, PromQL, Grafana, Linux와 Kubernetes 지표, trace, SLO와 incident 대응까지 하나의 흐름으로 연결합니다.
가장 짧은 학습 경로는 Part I → II → III → VI → VII입니다. 도구를 이미 운영 중이라면 Part III의 PostgreSQL Exporter부터 시작해도 됩니다.
차례
- Part I. 관측성과 신뢰성 기초: signal/metric 모델/cardinality/SLI/SLO
- Part II. 실습 환경: PostgreSQL/Exporter/Prometheus/Grafana를 한 번에 구성
- Part III. PostgreSQL Exporter: collector/권한/핵심 metric/pg_stat_statements
- Part IV. Prometheus와 PromQL: scrape/PromQL/recording rule/cardinality 관리
- Part V. Grafana와 신호 연결: dashboard/변수/provisioning/OS/Kubernetes/trace 연결
- Part VI. PostgreSQL 진단: 연결/lock/vacuum/WAL/replication/query workload
- Part VII. Reliability 운영: alert/SLO/error budget/runbook/capacity/postmortem
이 노트의 기준
- PostgreSQL Exporter는
prometheus-community/postgres_exporter를 기준으로 합니다. - 실습은 Docker Compose를 사용하며 PostgreSQL 17 이상을 기준으로 설명합니다.
- exporter의 custom query 파일 기능은 deprecated 상태이므로 built-in collector를 우선 사용합니다.
- metric 이름은 exporter와 PostgreSQL 버전에 따라 달라질 수 있습니다. 실제
/metrics출력과 Prometheus의/targets를 먼저 확인합니다. - 대시보드는 결과 화면이고, 진단의 출발점은 사용자 증상과 검증 가능한 가설입니다.
실습이 끝나면 답할 수 있어야 하는 질문
- 애플리케이션이 느릴 때 PostgreSQL 문제인지 OS/네트워크 문제인지 어떻게 구분하는가?
pg_up이 1인데도 서비스가 실패할 수 있는 이유는 무엇인가?- connection, transaction, lock, vacuum, WAL 중 어디가 병목인지 어떤 순서로 확인하는가?
- 어떤 metric을 page alert로 만들고 어떤 metric은 dashboard에만 남겨야 하는가?
- 99.9% SLO를 위반하는 속도를 PromQL로 어떻게 계산하는가?