[DEVOPS-008][중급] 세 가지 관측 신호 연결하기 > IT 기술 공유

• 목록

[이번 수업]
관측성은 시스템이 내보낸 자료로 내부 상태를 이해하는 능력입니다. 로그, 메트릭, 트레이스가 답하는 질문을 구분하고, 메트릭에서 이상을 발견해 느린 구간과 관련 로그를 찾는 흐름을 실습합니다.

[선수지식]
DEVOPS-007의 배포 전략, OS-008의 로그 필드와 요청 식별자, HTTP 요청 흐름을 알고 있어야 합니다.

[학습목표]
1. 로그·메트릭·트레이스의 역할을 구분할 수 있습니다.
2. 추적 ID로 트레이스와 로그를 연결할 수 있습니다.
3. 값이 끝없이 늘어나는 메트릭 라벨을 피할 수 있습니다.

[핵심개념]
로그는 특정 시각에 일어난 사건의 상세 기록으로 ‘무슨 일이 있었나’를 보여 줍니다. 메트릭은 요청 수, 오류 수, 지연시간 같은 숫자를 시간에 따라 집계해 ‘얼마나 자주, 얼마나 심한가’를 보여 줍니다. 트레이스는 한 요청이 여러 서비스를 지나는 경로입니다. 각 작업 구간을 스팬(span)이라고 하며 ‘어디에서 시간이 걸렸나’를 찾습니다.

실무에서는 ① 메트릭으로 이상 감지 ② 그 시간대의 느리거나 실패한 트레이스 선택 ③ 오래 걸리거나 실패한 스팬 확인 ④ 같은 trace_id의 로그로 세부 원인 확인 순서로 살펴봅니다. 서비스 이름, 시간대, 단위와 공통 속성을 맞춰야 신호를 연결할 수 있습니다. W3C Trace Context는 HTTP의 `traceparent` 헤더로 추적 문맥을 전달하는 형식을 정의합니다.

메트릭 라벨은 `method=GET`, `status=500`처럼 제한된 값으로 자료를 나눕니다. 사용자 ID, 전체 URL, 요청 ID를 넣으면 조합 수인 카디널리티가 늘어 저장·조회 비용이 커집니다. 요청별 식별자는 트레이스와 로그에 두세요. 일부 요청만 보관하는 샘플링을 쓸 수 있으므로 ‘트레이스가 없다’가 ‘문제가 없다’를 뜻하지 않습니다.

[따라하기]
아래를 observe.py로 저장하세요. 메트릭의 오류율을 계산하고, 같은 추적 ID의 가장 느린 스팬과 로그를 찾습니다.

```python
metric = {"requests": 1000, "errors": 50, "p95_ms": 820}
trace_id = "4bf92f3577b34da6"
spans = [
    {"trace_id": trace_id, "name": "checkout", "duration_ms": 160},
    {"trace_id": trace_id, "name": "db", "duration_ms": 610},
    {"trace_id": trace_id, "name": "cache", "duration_ms": 30},
]
logs = [
    {"trace_id": trace_id, "level": "WARN", "event": "connection_pool_wait"}
]

error_rate = metric["errors"] / metric["requests"] * 100
slowest = max(spans, key=lambda span: span["duration_ms"])
related = next(log for log in logs if log["trace_id"] == slowest["trace_id"])
print(f"metric: error rate {error_rate:.1f}%, p95 {metric['p95_ms']}ms")
print(f"slowest span: {slowest['name']} {slowest['duration_ms']}ms")
print(f"related log: {related['event']}")
```

Windows는 `py observe.py`, macOS와 Linux는 `python3 observe.py`로 실행합니다. 예상 결과입니다.

```text
metric: error rate 5.0%, p95 820ms
slowest span: db 610ms
related log: connection_pool_wait
```

연결 대기 가능성을 보여 주지만 원인을 확정하지는 않습니다. 연결 풀 사용량과 데이터베이스 지연 등 증거를 더 확인해야 합니다.

[흔한 실수]
목적 없이 모든 자료를 저장하거나, 서비스마다 시간대와 필드 이름이 달라 신호를 연결하지 못하기 쉽습니다. 평균 지연시간만 보면 느린 상위 요청을 놓칩니다. 경보 메트릭에서 트레이스와 로그로 이동할 연결 고리를 만들고 수집기의 누락과 지연도 감시하세요.

[보안 주의]
본인 소유의 로컬·격리 환경 자료만 사용하세요. 로그와 스팬에 비밀번호, 토큰, 요청 본문, 불필요한 개인정보를 넣지 말고 허용 목록으로 수집합니다. 외부 입력을 메트릭 이름이나 라벨 이름으로 만들지 않습니다. 수집기와 저장소 통신을 인증·암호화하고 조회 권한과 보관 기간을 제한하세요. 추적 헤더는 상관관계 정보일 뿐 인증이나 권한 증명이 아닙니다.

[직접 해볼 과제]
spans에 900ms짜리 `payment` 스팬과 같은 trace_id의 오류 로그를 추가하세요. 가장 느린 구간과 관련 로그가 바뀌는지 확인하고, 사용자 ID를 메트릭 라벨 대신 로그나 트레이스에 두어야 하는 이유를 설명하세요.

[확인문제]
1. 전체 오류율을 빠르게 파악하는 데 가장 알맞은 신호는 무엇인가요?
2. 한 요청에서 느린 서비스 구간을 찾는 신호는 무엇인가요?
3. 요청 ID를 메트릭 라벨로 쓰면 어떤 문제가 생기나요?

[다음 학습]
다음 SEC-008에서는 비밀정보를 코드와 분리하고 안전한 저장소에서 다루는 방법을 배웁니다.

[공식 참고 자료]
관측 신호 공식 개요: https://opentelemetry.io/docs/concepts/signals/
로그 데이터 모델 공식 사양: https://opentelemetry.io/docs/specs/otel/logs/data-model/
메트릭 계측과 라벨 공식 지침: https://prometheus.io/docs/practices/instrumentation/
분산 추적 문맥 표준: https://www.w3.org/TR/trace-context/
관측 자료 보안 공식 지침: https://opentelemetry.io/docs/security/