본문으로 건너뛰기

1.1 관측성과 신뢰성

서버가 살아 있는지 주기적으로 확인하는 것은 monitoring입니다. 이미 예상한 실패를 검사하고, 임계값을 넘으면 알려 줍니다. observability는 여기서 한 단계 더 나아가, 처음 보는 현상도 시스템이 내놓은 신호를 조합해 내부 상태를 추론할 수 있게 만드는 성질입니다.

둘은 경쟁 개념이 아닙니다. monitoring이 알려진 질문에 빠르게 답하고, observability가 원인을 좁힐 증거를 제공합니다. reliability는 그 증거를 이용해 사용자가 기대한 동작을 일정 수준 이상 유지하는 운영 결과입니다.

PostgreSQL에서 질문이 달라지는 과정

다음 세 질문은 비슷해 보이지만 필요한 데이터가 다릅니다.

  1. PostgreSQL 프로세스가 살아 있는가?
  2. 새 connection을 받고 간단한 query를 처리할 수 있는가?
  3. 사용자의 결제 요청이 목표 시간 안에 commit되는가?

pg_up == 1은 첫 번째 질문에 가깝습니다. exporter가 PostgreSQL에 접속해 통계 view를 읽었다는 뜻이지, 애플리케이션의 transaction이 성공한다는 보장은 아닙니다. connection pool이 고갈되거나 특정 lock이 핵심 table을 막아도 pg_up은 1일 수 있습니다.

건강 상태는 요청 경로의 각 계층에서 따로 측정하며, 다음 운영 질문을 기준으로 필요한 신호를 정합니다.

네 가지 운영 질문

관측 데이터를 추가하기 전에 질문을 먼저 적습니다.

목적질문대표 데이터
탐지사용자가 지금 영향을 받는가?성공률/latency/처리량
분류어느 계층에서 문제가 시작됐는가?app/pool/DB/node metric
원인 확인어떤 작업이나 자원이 병목인가?lock/query ID/I/O wait/trace
예방같은 조건이 다시 올 가능성이 있는가?증가 추세/capacity/변경 이력

이 네 질문은 dashboard panel의 목적을 분류하는 기준으로 사용합니다.

PostgreSQL 관측성의 세 층

첫 번째는 데이터베이스 내부입니다. pg_stat_activity, pg_stat_database, pg_locks, pg_stat_replication, pg_stat_statements 같은 view가 connection, transaction, lock, replication, workload를 보여 줍니다.

두 번째는 호스트와 container입니다. CPU 사용률만 볼 것이 아니라 run queue, memory pressure, page cache, disk latency, cgroup throttling을 함께 봐야 합니다. PostgreSQL은 OS 위에서 I/O와 메모리를 소비하므로 이 층을 빼면 원인과 결과를 뒤집기 쉽습니다.

세 번째는 서비스 경로입니다. 애플리케이션 성공률, connection pool 대기, API latency, trace의 database span이 여기에 속합니다. 서비스 경로 데이터는 사용자 영향과 PostgreSQL 내부 현상을 같은 시간축에 연결합니다.

서비스 경로/데이터베이스/호스트를 함께 보는 PostgreSQL 관측성의 세 층

좋은 시작점

처음부터 모든 신호를 모으지 않습니다. 다음 최소 집합으로 시작합니다.

  • 서비스 요청 수/오류율/latency
  • pool 사용량과 대기 시간
  • PostgreSQL availability/connection/transaction/lock/WAL/replication
  • node CPU/memory/disk/network
  • 배포와 설정 변경 annotation

이 최소 집합으로 실제 incident를 한두 번 분석한 다음, 답하지 못했던 질문에 필요한 metric이나 log를 추가합니다. 이 과정을 반복하면서 수집 범위를 넓힙니다.

정리

Monitoring은 상태 변화를 알려 주고, observability는 원인을 추론할 증거를 제공하며, reliability는 사용자 기대를 목표 수준으로 지키는 활동입니다. 이 문서에서는 PostgreSQL Exporter를 데이터베이스 내부 계층의 데이터 원천으로 다루고, 이후 Part에서 서비스와 OS 신호를 연결합니다.

참고: OpenTelemetry Observability Primer, Google SRE의 Monitoring Distributed Systems