Application Observability

Overview

Monitoring이 미리 정한 실패를 감시한다면 Observability는 외부 출력만으로 내부 상태를 설명할 수 있는 능력이다. Metric은 변화와 규모, Log는 개별 사건, Trace는 한 요청이 여러 경계를 지난 경로를 보여준다.

flowchart LR; A[Application] --> M[Metrics]; A --> L[Logs]; A --> T[Traces]; M --> C[상관관계]; L --> C; T --> C; C --> D[Dashboard·Alert·Investigation]

무엇을 측정할까

요청은 Rate, Error, Duration을 기본으로 본다. 자원은 Utilization, Saturation, Error를 보고 Queue·Thread·Connection Pool은 active, idle, pending, wait time을 함께 본다. 평균만으로 Tail Latency를 숨기지 않도록 p95/p99를 사용한다.

실무에서 발생하는 문제

Label에 사용자 ID 같은 고유 값을 넣어 Cardinality가 폭증하거나, Dashboard 백업과 Version 관리가 없어 운영 지식이 사라질 수 있다. Trace ID가 Log에 연결되지 않으면 분산 요청을 재구성하기 어렵다. Alert는 원인보다 사용자 영향과 행동 가능한 임계값에 맞춘다.

Interview Questions

1. Monitoring과 Observability의 차이는?
2. p99가 평균보다 중요한 상황은?
3. High-cardinality Label이 위험한 이유는?
4. Connection Pool Dashboard에 어떤 지표를 함께 놓을 것인가?

Related Topics

Latency와 Throughput, Load Testing, Incident Response로 이어진다.