Observability 플랫폼 구축
Observability 플랫폼 구축
4주차에서 Metrics / Logs / Traces 개념을 배웠다. 이번엔 그걸 실제로 어떻게 구축하는지다.
표준 스택
| 역할 | 도구 |
|---|---|
| 메트릭 수집 | Prometheus |
| 메트릭 시각화 | Grafana |
| 로그 수집 | Fluentd / Fluent Bit |
| 로그 저장 | Loki / Elasticsearch |
| 트레이싱 | Jaeger / Tempo |
| 알림 | Alertmanager |
Prometheus 구조
Prometheus는 Pull 방식으로 메트릭을 수집한다. 서비스가 메트릭을 보내는 게 아니라 Prometheus가
주기적으로 가져간다.
[서비스] → /metrics 엔드포인트 노출
[Prometheus] → 주기적으로 /metrics 호출해서 수집
[Grafana] → Prometheus에서 데이터 조회해서 시각화
서비스가 죽어도 Prometheus가 감지할 수 있다는 게 Pull 방식의 장점이다.
메트릭 타입
| 타입 | 설명 | 예시 |
|---|---|---|
| Counter | 누적 카운트, 감소하지 않음 | 총 요청 수, 에러 수 |
| Gauge | 현재 값, 오르내림 | CPU 사용률, 메모리 |
| Histogram | 구간별 분포 측정 | 응답 시간 분포 |
| Summary | 분위수 측정 | p99 응답 시간 |
SLI를 측정할 때 응답 시간은 Histogram, 에러율은 Counter로 계산한다.
로그 파이프라인
[서비스] → [Fluent Bit] → [Loki / Elasticsearch] → [Grafana]
Fluent Bit은 각 노드에 DaemonSet으로 배포해서 모든 컨테이너 로그를 빠짐없이 수집한다.
| 도구 | 특징 |
|---|---|
| Loki | 레이블 기반 저장, Grafana와 연동이 자연스럽다 |
| Elasticsearch | 전문 검색이 강력하다, 복잡한 검색이 필요할 때 적합하다 |
분산 트레이싱
각 서비스가 Span을 생성하고 같은 Trace ID로 묶인다. 요청이 어디서 느려졌는지 한눈에 볼 수 있다.
[서비스 A] → [서비스 B] → [서비스 C]
↓ ↓ ↓
Span 생성 Span 생성 Span 생성
↓
[Jaeger / Tempo] → [Grafana]
Grafana로 연결하기
Grafana는 여러 데이터 소스를 연결해서 한 화면에서 보는 도구다. Prometheus는 데이터를 모으는 역할,
Grafana는 모인 데이터를 보여주는 역할이다.
-
Prometheus → 메트릭 대시보드
-
Loki → 로그 검색
-
Jaeger / Tempo → 트레이스 조회
하나의 장애 상황에서 메트릭, 로그, 트레이스를 Grafana 한 화면에서 전환하며 볼 수 있다.
구축 시 흔한 실수
실수 문제 메트릭만 수집하고 로그 없음 수치는 보이는데 원인을 모른다 로그에 컨텍스트 없음 어떤 요청에서 난 에러인지 모른다 트레이스 ID 미연동 로그와 트레이스를 연결 못 한다 대시보드만 있고 알림 없음 사람이 직접 보고 있어야 한다
