장애 알림이 울립니다. "에러율 급증, p99 지연 5초, 502가 쏟아져요." 그런데 로그는 서비스마다 흩어져 있고, 어느 요청이 어디서 막혔는지 추적이 안 됩니다. "평균 응답은 정상인데요?"라는 말에 다들 헷갈립니다. 관측성 용어를 모르면 '무엇이 언제 왜 어디서' 잘못됐는지 추적할 도구도, 언어도 없습니다. 이 사전은 관측성·장애 분석 용어를 빠르게 해독합니다. 운영 철학(SLO·포스트모템)은 [[slo-error-budget]]에서, 깊은 모니터링 실습은 관련 트랙에서 다룹니다.
- 1관측성 세 기둥(메트릭·로그·트레이스)의 역할을 구분할 수 있다
- 2핵심 지표(에러율·지연 p95/p99·처리량·자원)를 해석할 수 있다
- 3HTTP 4xx/5xx 에러코드로 문제 영역을 가를 수 있다
- 4상관 ID·스택트레이스·RCA로 장애를 추적·분석할 수 있다
관측성 세 기둥 + 도구
메트릭·로그·트레이스, 그리고 그것을 보는 스택
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Monitoring / Observability | 모니터링 / 관측성(내부상태 추론) | → [[slo-error-budget]] | ★★★ |
| Metric / Log / Trace | 수치추세 / 이벤트기록 / 요청경로 | 세 기둥 | ★★★ |
| APM | 애플리케이션 성능 모니터링 | 코드 레벨 추적 → [[apm-monitoring]] | ★★ |
| Prometheus / Grafana | 메트릭 수집 / 시각화 | 대표 스택 → [[monitoring-prometheus]] | ★★ |
| ELK / Elasticsearch / Logstash / Kibana / Filebeat / Fluentd | 로그 수집·검색·시각화 | 로그 파이프라인 → [[log-aggregation]] | ★★ |
| OpenTelemetry / Jaeger / Zipkin | 분산 추적 표준·도구 | 요청 경로 추적 | ★★ |
| Correlation ID / Request ID / Trace ID / Span ID | 요청 식별자 / 구간 식별자 | 흩어진 로그를 묶음 | ★★★ |
| Alert | 임계 초과 알림 | 경보피로 주의 → [[cicd-pipeline]] | ★★ |
핵심: 메트릭으로 '언제 이상한가'를 보고, 트레이스로 '어디서'를, 로그로 '왜'를 봅니다. 상관 ID가 있어야 MSA에서 흩어진 로그를 한 요청으로 묶습니다([[architecture-patterns]]).
핵심 지표
무엇을 보고 건강을 판단하나
| 용어 | 한 줄 뜻 | 판단 기준 | 중요도 |
|---|---|---|---|
| Error Rate | 에러 비율 | 급증=장애 1순위 신호 | ★★★ |
| Latency / p95 / p99 | 지연 / 95·99퍼센타일 | 평균 말고 p95/p99로 | ★★★ |
| Throughput / TPS / QPS | 처리량 / 초당 트랜잭션·쿼리 | 부하 추세 | ★★ |
| CPU / Memory / Disk Usage / Network I/O | 자원 사용률 | 임계 → [[server-triage]] | ★★ |
| GC Time / Thread Count / Connection Count | GC시간 / 스레드 / 커넥션 수 | 자바 → [[jvm-operations]]·[[connection-pooling]] | ★★ |
| Slow Log / Access Log / Error Log | 느린쿼리 / 접근 / 에러 로그 | 어느 로그를 볼지 | ★★ |
핵심: 평균 지연은 꼬리 지연을 가립니다 — p95/p99로 '대부분 사용자가 겪는 최악'을 봅니다. 이 값이 SLO([[slo-error-budget]])의 기준이 됩니다.
HTTP 에러 · 예외
에러코드가 가리키는 방향
| 코드/예외 | 의미 | 방향 | 중요도 |
|---|---|---|---|
| 400 / 401 / 403 | 잘못된요청 / 미인증 / 권한없음 | 클라이언트·인증 → [[glossary-api-auth]] | ★★ |
| 404 / 405 / 409 / 429 | 없음 / 메서드불가 / 충돌 / 한도초과 | 라우팅·멱등·레이트리밋 | ★★ |
| 500 / 502 / 503 / 504 | 서버오류 / 게이트웨이불량 / 불가 / 타임아웃 | 5xx=서버측 | ★★★ |
| Stack Trace / Exception | 예외 호출스택 / 예외 | 원인 코드 위치 | ★★ |
| NullPointer / SQL / Socket / Timeout Exception | 대표 예외들 | NPE=널참조, Socket=연결 | ★★ |
| Connection Refused / Reset / Broken Pipe | 거부 / 재설정 / 끊김 | 뒷단 죽음·네트워크 | ★★ |
핵심: 4xx는 보통 클라이언트/요청 문제, 5xx는 서버 문제입니다. 502=뒷단 죽음/비정상, 503=과부하·점검, **504=뒷단 느림(타임아웃)**으로 방향이 갈립니다([[glossary-network-security]]).
장애 분석 — RCA·포스트모템
원인을 찾고 재발을 막는 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| RCA (Root Cause Analysis) | 근본 원인 분석 | 증상 아닌 원인 | ★★ |
| Incident / Postmortem | 장애 / 사후분석 | 비난없이 → [[slo-error-budget]] | ★★★ |
| Hotfix / Temporary Workaround | 긴급수정 / 임시조치 | 임시는 부채로 → [[tech-debt-refactoring]] | ★★ |
핵심: 임시조치(workaround)로 급한 불을 끈 뒤 RCA로 근본 원인을 찾아 포스트모템 액션(테스트·자동화·알람 추가)으로 재발을 막습니다([[slo-error-budget]]). 임시조치를 방치하면 기술 부채가 됩니다([[tech-debt-refactoring]]).
지표·로그로 장애 추적 — 직접 확인
장애 시 메트릭(언제) → 트레이스(어디서) → 로그(왜) 순으로 좁힙니다.
1) 메트릭: 에러율·p99가 언제 치솟았나? (배포 시각과 겹치나?)
2) 에러코드: 5xx 중 무엇? 502(뒷단 죽음)/503(과부하)/504(느림)
3) 트레이스: 느린 요청의 Trace ID로 어느 서비스/구간이 병목인지
4) 로그: 그 Trace ID로 모든 서비스 로그를 묶어 예외·원인 확인
에러율 0.1%→8% (14:02, v1.3 배포 직후) → 배포가 원인 1순위
5xx 분포: 504 Gateway Timeout 다수 → 뒷단 '느림'(죽음 아님)
Trace abc123: payment-service 4.8s 점유 → 그 서비스 슬로우([[glossary-db-sql]])
로그(abc123): "Slow query ... orders Full Scan" → 인덱스 부재
→ 14:02 배포의 쿼리 변경 의심 → 롤백 + 인덱스 추가
echo '대시보드 에러율·p99 → 상관ID로 로그 추적'- 에러율/지연 급증 시각이 배포 시각과 겹치면 그 배포가 1순위 의심 → [[release-strategy]]로 롤백 우선, 원인은 그다음
- 5xx 종류로 방향을 가른다: 502=뒷단 죽음(재시작?), 503=과부하(스케일?), 504=뒷단 느림(슬로우쿼리·외부지연)([[glossary-network-security]])
- p99가 나쁜데 평균은 정상이면 꼬리 지연 — 일부 요청만 느린 것. 트레이스로 그 느린 요청의 병목 구간을 특정
- 상관ID(Trace ID)가 로그에 없으면 분산 추적 불가 → 진입점에서 ID 부여·전파를 인프라가 표준화해야 함([[architecture-patterns]])
상황: 대시보드의 평균 응답시간은 200ms로 양호한데, 일부 사용자가 "몇 초씩 걸린다"고 항의합니다. 평균만 보던 팀은 문제를 재현·인지하지 못합니다.
원인: 평균이 꼬리 지연(tail latency)을 가린 것입니다. 빠른 요청 다수가 느린 소수를 희석해 평균은 좋아 보이지만, p95/p99로 보면 '상위 1~5% 사용자'는 수 초를 겪고 있습니다.
진단:
□ p95/p99 지연을 보고 있나? (평균만 보면 함정)
□ 느린 요청의 Trace ID로 병목 구간(특정 쿼리·외부호출)을 특정했나?
□ 특정 조건(데이터 많은 사용자·특정 엔드포인트)에 몰리나?
해결: 대시보드에 p95/p99를 핵심 지표로 추가하고([[slo-error-budget]]), 느린 요청을 트레이스로 추적해 병목(N+1·슬로우쿼리·외부 동기호출)을 특정합니다([[glossary-db-sql]]·[[async-event-driven]]). SLO를 p99 기준으로 잡으면 '대부분 사용자의 최악 경험'을 관리하게 됩니다. 평균은 안심을 주지만 진실을 가립니다.
인프라/SRE에게 관측성은 직무의 눈입니다 — 메트릭·로그·트레이스를 엮어 장애를 '언제·어디서·왜'로 추적하고([[slo-error-budget]]), 상관 ID로 MSA의 흩어진 로그를 묶습니다. 깊은 모니터링 실습(Prometheus·Loki·APM)은 관련 트랙에 있습니다. PM은 이 용어로 장애 보고를 정확히 읽고("502 다수=뒷단 죽음", "p99 악화=꼬리 지연"), 포스트모템 액션을 백로그로 추적합니다([[roadmap-issue-tracking]]). 관측성 없는 운영은 깜깜이 운전이며, 좋은 지표는 사고를 조기에 드러냅니다.
다음 용어사전에서는 대량 데이터를 다루는 배치·비동기 처리 용어를 정리합니다.