Observability (Metric·Log·Trace) + 이상 분석
1. Metric — Prometheus
| 개념 | 핵심 |
|---|---|
| 수집 방식 | Pull 모델. Prometheus가 target의 /metrics를 주기적으로 긁어온다 |
up 값 | 1=발견+수집 성공 / 0=발견했지만 수집 실패 / 결과 자체가 없음(빈 배열)=target 미등록(대개 ServiceMonitor selector 불일치) |
| ServiceMonitor | Service의 label과 selector가 일치해야 함. 다른 namespace면 namespaceSelector 필요 |
count(up) vs sum(up) | count=등록된 target 수(죽어도 안 줄어듦) / sum=그중 정상(up=1)인 개수만 |
| rate window | 짧은 창(1m)=스파이크에 민감·빨리 반응 / 긴 창(30m)=완만하지만 장애 끝난 뒤에도 "여운"이 남음(값이 남아있다≠아직 장애) |
| Exporter | 다른 시스템 값을 Prometheus 포맷으로 변환. Pull 방식으로 수집됨(Push 아님) |
| Pushgateway | 짧게 실행되고 끝나는 batch job 전용. 상시 서비스에는 쓰지 않음 |
| Alert 상태 | Inactive → Pending → Firing → (해제) Inactive. for 시간 채우기 전 조건이 풀리면 Pending→Inactive로 리셋 |
| Alertmanager | Routing/Grouping/Silence 담당. PromQL 평가는 Prometheus 몫(Alertmanager 아님) |
| histogram | _bucket, _sum, _count 3종 노출. histogram_quantile()엔 le 라벨 필수 |
2. Metric — Grafana
| 개념 | 핵심 |
|---|---|
| Data Source health | API: /api/datasources/uid/<uid>/health (id 아니라 uid) |
| No data 진단 순서 | health 확인 → Explore 기본쿼리 → time range 확장 → label 필터 제거 |
| Explore vs Dashboard | Explore=임시 조회/디버깅, Dashboard=반복적으로 보는 화면 |
| Stat vs Time series | Stat=마지막 값 하나, Time series=변화 모양(추세 파악에 필요) |
| Variable | label_values(metric, label)로 드롭다운 값 목록 생성 |
3. Log — Fluent Bit → Loki
| 개념 | 핵심 |
|---|---|
| 파이프라인 순서 | Input → Parser → Filter → Output |
| 메타데이터 부착 | [FILTER] Name kubernetes가 namespace/pod 등 라벨을 붙임 (앱 자체는 이 정보를 모름) |
| 라벨 vs 본문 필드 판단 기준 | 값의 종류(cardinality)가 적고 자주 묶어보면 → 라벨 / 요청·사용자마다 값이 달라지면(trace_id,user_id,request_id,email) → 본문 필드 |
| 라벨의 비용 | 라벨 조합 하나 = 스트림(chunk 저장 단위) 하나. 카디널리티 높은 값을 라벨화하면 스트림 폭증 → 조회 느려짐·메모리 급증 |
| 3시스템 라벨 비교 | Kubernetes=오브젝트 메타데이터(비용 무관) / Prometheus=시계열 차원(카디널리티만큼 시계열 증가) / Loki=스트림 색인 키(카디널리티만큼 스트림 증가) |
| LogQL 4단계 | **label selector → text filter(` |
이 실습환경의 level | 라벨이 아니라 JSON 본문 필드 → `{service="x"} |
점(.) 필드 | payment.provider처럼 파싱된 필드는 조회 시 밑줄로 변환: payment_provider="..." |
| broken JSON 진단 | 겉 JSON(log 필드)을 line_format으로 한 겹 더 벗겨야 __error__="JSONParserErr" 확인 가능 |
| log → metric | sum(rate({...}[1m])) : 로그 스트림을 세어(count) 지표처럼 씀 |
| retention | retention_period + compactor의 retention_enabled 둘 다 켜야 실제 삭제됨. 스트림(라벨)별 차등 보존 가능 |
| trace_id 위치 | 라벨 아님, 로그 본문 필드(cardinality 이유) |
4. Trace — Tempo
| 개념 | 핵심 |
|---|---|
| 저장 단위 | Span 하나하나 (Trace 전체 그래프가 통째로 저장되는 게 아님). Waterfall은 조회 시점에 조립 |
| 핵심 개념어 | Trace=전체 흐름 / Span=작업 단위 / trace_id=요청 연결 키 / span_id=개별 Span 키 / Parent-Child |
| Trace가 필요한 이유 | Log 조인만으로는 ①인과관계 ②구간(시작~끝) 시간 ③서버 간 시계 오차 문제를 해결 못함. Trace는 Context Propagation으로 인과·구간을 데이터에 박아둠 |
| 가장 긴 Span ≠ 원인 | Parent 시간엔 Child 대기시간이 포함됨. 가장 안쪽(가장 깊은) Span이 실제 원인인 경우가 많음 |
| 병렬 vs 순차 판별 | 막대 길이가 아니라 실행 구간(시작~끝)이 시간축에서 겹치는지로 판단 |
| 강결합(동기) | 하위 지연이 그대로 상위에 전파. 하나 장애나면 전체로 번짐. 재시도/타임아웃이 오히려 전파를 키울 수 있음 |
| 느슨한 결합(비동기) | 큐로 분리해 서로 안 기다림. 대신 "완료 즉시 확인 불가", 관측 연결이 어려움(Context Propagation 필요) |
| Trace의 한계 | 미계측 구간, Propagation 실패, Sampling → "Trace가 없다"≠"문제 없었다" |
| Sampling | Head=시작 시점 결정(뒤늦은 오류 놓칠 위험) / Tail=끝까지 보고 결정(자원·복잡도 ↑) |
| 조회 언어 대응 | Prometheus–Metric–PromQL / Loki–Log–LogQL / Tempo–Trace–TraceQL |
| TraceQL duration | trace:duration=Trace 전체(최초 시작~최후 종료) / span:duration=개별 Span 하나 |
| Trace↔Log 연결 | Tempo Trace to logs의 Tags는 scope 접두사 없는 키(service.name) 그대로 적어야 함 |
| 보존 기간 차이 | Loki(길게/무기한) vs Tempo(짧게, 예: 1h) → 오래된 로그의 TraceID 링크가 trace not found일 수 있음(보존 기간 문제, 장애 아님) |
5. 관측 신호 연결 (Metric·Log·Trace)
trace_id: 한 요청을 Trace↔Log 사이에서 잇는 키 (카디널리티 높아 라벨 X, 본문 필드로)service.name/service라벨: 같은 서비스의 Metric·Log·Trace 세 신호를 묶는 축- 조사 순서 예시: Metric(영향 범위 파악) → Trace(요청 단위 원인 좁히기) → Log(상세 원인) → 다시 Metric(전체 영향 재확인)
6. 이상 분석 — 판단의 뼈대
판단의 세 질문
- 예상 범위를 벗어났는가 (Anomaly)
- 사용자 영향이 있거나 임박했는가 (Incident)
- 지금 행동이 필요한가 (Alert)
Anomaly / Incident / Alert
| 용어 | 의미 | 주의 |
|---|---|---|
| Anomaly | 평소/예상과 다른 패턴 | 단순 "임계값 초과"와 다름. 시간대별 기대 범위(예: 새벽 배치 lag)를 고려해야 함 |
| Incident | 사용자/비즈니스 영향 발생·임박 | 지속시간·실제 영향 사용자 유무·문의 등 증거로 확인 |
| Alert | 조건 충족 신호 | 담당자가 확인·조치할 수 있어야 좋은 Alert. 대응 불가한 알림 반복 = 알림 피로 |
- Anomaly ≠ Incident, Incident ≠ 반드시 즉시 호출 Alert, Alert ≠ 장애의 원인 (셋은 순차 단계가 아니라 부분적으로만 겹치는 개념)
- "아직 판단할 수 없다"도 정당한 결론 (근거 부족을 정확히 인정하는 것)
변화의 크기 ≠ 장애 여부
- Request rate·CPU는 "무슨 변화가 있었는지"만 보여줌
- 장애 여부는 latency, 성공률, 고객 문의 등 사용자 영향 지표로 판단
SLI / SLO / SLA / Error Budget
| 용어 | 정의 |
|---|---|
| SLI | 사용자 관점에서 서비스 수준을 측정하는 지표 (대상+계산 범위까지 정의해야 함). 기성 지표(p99, RPS) 목록에서 고르는 게 아니라 "사용자가 누구인가"에서 출발 |
| SLO | 일정 기간 달성하려는 목표 수준 (예: 28일간 99.9%) |
| SLA | 고객과의 외부 약속. 보통 SLO보다 느슨함 (SLO를 먼저 어겨야 SLA까지 여유) |
| Error Budget | SLO가 허용하는 실패 범위. 장애 면허가 아니라 안정성-배포속도 트레이드오프의 운영 기준 |
- Time Window: 짧은 창(1분)=급격한 장애 감지용 Alert / 긴 창(28일)=SLO 평가용. 셋 다 "진짜" 값이며 역할이 다를 뿐
- 평균의 함정: 전체 성공률이 정상으로 보여도 특정 세그먼트(PG, 국가, 사용자군)에서 심각한 실패가 숨어있을 수 있음 → 세그먼트별로 나눠 봐야 함
- 대리지표(proxy metric) 주의: 가장 눈에 띄는 지표(fps 등)를 그대로 SLI로 쓰지 말고, 진짜 알고 싶은 사용자 경험에 더 가깝게 조건을 붙여 정의
상관 ≠ 인과
- 같이 움직인다(상관) ≠ 원인이다(인과)
- 인과 확정 조건: 반증을 견뎌야 함 — "원인이 맞다면 안 보여야 할 경우"를 찾아서 실제로 없는지 확인
- 제3의 공통 원인(예: "저녁"이라는 시간대에 도는 배치)이 둘 다에 영향을 줬을 가능성 항상 의심
장애 후 회고에서 짚을 것
- 더 빨리 확인할 SLI가 있었는가 / 부족했던 지표·로그 / Alert가 너무 늦거나 시끄러웠는가 / 매뉴얼·Workflow에 빠진 분기
- 주의: SLO는 장애가 날 때마다 낮추는 값이 아니라, 사용자 기대·비즈니스 목표가 실제로 바뀌었을 때만 재검토
