2.1 전체 아키텍처
실습 환경은 네 서비스로 구성합니다. PostgreSQL Exporter가 통계 view를 SQL로 조회하고 /metrics에 노출하면 Prometheus가 15초마다 가져가 저장합니다. Grafana는 Prometheus API에 PromQL을 보내 결과를 표시합니다.
각 컴포넌트의 책임
PostgreSQL
관측의 원본입니다. Exporter가 값을 만들어 내는 것이 아니라 PostgreSQL의 누적 통계와 현재 상태를 읽어 Prometheus 형식으로 변환합니다. 통계가 reset되거나 서버가 재시작되면 counter의 시작점도 달라집니다.
PostgreSQL Exporter
Exporter는 metric 저장소가 아닙니다. Prometheus가 /metrics를 호출할 때 PostgreSQL에 접속해 collector를 실행하고 결과를 반환합니다. Exporter 응답이 느리다면 database lock, 네트워크, collector query 비용, connection 부족을 모두 확인해야 합니다.
Prometheus
Target을 주기적으로 scrape하고 time series를 로컬 TSDB에 저장합니다. PromQL 실행, recording rule 평가, alerting rule 판정도 담당합니다. Grafana가 없어도 Prometheus expression browser에서 모든 query를 검증할 수 있습니다.
Grafana
Grafana는 source of truth가 아니라 조회와 시각화 계층입니다. panel이 비어 있을 때 dashboard부터 수정하지 않고 Prometheus query와 target 상태를 먼저 확인합니다.
네 구간의 health check
| 구간 | 확인 방법 | 정상 기준 |
|---|---|---|
| PostgreSQL | pg_isready/psql | connection과 SELECT 1 성공 |
| Exporter | curl :9187/metrics | HTTP 200, pg_up 1 |
| Prometheus | /targets | postgres target UP |
| Grafana | Explore에서 pg_up | series와 값 표시 |
이 구분은 운영 환경에서도 그대로 적용됩니다. Dashboard에 No data가 보인다는 한 가지 증상만으로 PostgreSQL 장애라고 결론내리지 않습니다.
Pull 모델의 의미
Prometheus가 Exporter를 호출하므로 중앙에서 target 목록과 scrape 간격을 관리할 수 있습니다. 반면 방화벽이나 NetworkPolicy가 Prometheus에서 Exporter 방향의 연결을 허용해야 합니다. Exporter의 9187 포트를 인터넷에 공개할 이유는 없습니다.
Scrape가 실패하면 Prometheus는 이전 값을 계속 현재값처럼 사용하지 않습니다. 일정 시간이 지나 series가 stale 상태가 되므로, dashboard가 끊어지거나 query 결과에서 사라집니다. 운영 alert에는 database health뿐 아니라 scrape 자체의 실패도 포함해야 합니다.
실습 목표
이 Part에서는 다음을 직접 확인합니다.
- PostgreSQL transaction이 exporter metric으로 변환되는 과정
/metrics에는 값이 있는데 Prometheus에 없을 때의 진단- PromQL 결과와 Grafana panel이 같은 값을 가리키는지 확인하는 방법
- container 재시작으로 counter가 reset될 때
rate()가 처리하는 방식