이 덱은 도구 넷의 매뉴얼이 아니라 조사 경로 하나의 설계도다 — 알림에서 원인까지
관측 가능성Observability신호Telemetry Signalkubectl logs와 kubectl top까지는 하는데, 그 위의 스택을 직접 세워 본 적은 없는 사람전제하는 것: 쿠버네티스 기본기(Deployment · Service · PV/PVC · Helm), 터미널, YAML. 전제하지 않는 것: 관측 도구와 질의 언어 경험 — 제품 이름과 문법은 필요한 장에서 처음부터 쌓는다.
다룬다
세 신호가 각각 무엇에 답하고 무엇에 답하지 못하는가.
Prometheus — 메트릭의 생김새, PromQL, ServiceMonitor, 리텐션, 알림 설계.
Loki — 라벨만 인덱싱하는 구조, Alloy 수집, LogQL, 보존.
Tempo — 스팬의 생김새, 계측과 컨텍스트 전파, 샘플링, TraceQL, 3.0의 구조 변화.
Grafana — 셋을 잇는 상관 관계 설정, 조사 흐름, 대시보드 설계, SSO.
안 될 때 어디를 보나 — 장마다 점검 절과 증상·원인 표.
다루지 않는다
쿠버네티스 기초 (→ CKA 덱).
오브젝트 스토리지·Postgres·SSO를 세우는 일 (→ 온프렘 덱).
온프렘 고유의 제약 자체 — egress 프록시 · 사내 CA는 온프렘 덱 1장 · 4장, 관측 스택의 배치·용량 계획은 8장.
애플리케이션 코드 계측의 언어별 상세 (4장은 개념과 경계까지, 11장이 Python 예제 하나를 손에 잡게 한다).
Mimir · Thanos 운영 — 필요해지는 시점까지만 다룬다.
프로파일링(Pyroscope) · eBPF 기반 자동 계측 — 자리만 잡아 준다.
SLO 정의와 에러 버짓 — 알림 설계 원칙까지만.
도구를 배울 때 제일 흔한 실패는 설정 파일부터 보는 것이다. 값이 무슨 뜻인지 모른 채 YAML을 복사하면, 안 될 때 어디를 봐야 할지 알 수 없다. 그래서 2~4장은 전부 같은 순서로 간다. (5장 Grafana는 예외다 — 자기 데이터가 없는 조회 층이라 ①이 없고, 셋을 잇는 설정에서 시작한다.)
| 순서 | 무엇을 | 왜 이 순서인가 |
|---|---|---|
| ① 데이터가 어떻게 생겼나 | 메트릭 한 줄 · 로그 한 줄 · 스팬 하나의 실제 모양 | 저장되는 물건을 봐야 나머지가 다 읽힌다 |
| ② 어떻게 묻나 | PromQL · LogQL · TraceQL | 질의를 알면 무엇을 저장해야 하는지가 거꾸로 보인다 |
| ③ 어떻게 세우나 | Helm · CRD · 에이전트 설정 | 이제 각 값이 ①②의 무엇을 정하는지 안다 |
| ④ 안 될 때 어디를 보나 | 명령어 + 증상·원인·확인 표 | 실제로 제일 자주 열리는 자리 |
“메트릭 → 로그 → 트레이스” 순서로 고급이 되는 게 아니다. 각각 다른 질문에 답한다.
| 신호 | 답한다 | 답하지 못한다 |
|---|---|---|
| 메트릭 | 얼마나 · 언제부터 · 추세는 | 왜 그런지 |
| 로그 | 정확히 무슨 일이 있었나 | 전체에서 그게 얼마나 흔한지 |
| 트레이스 | 한 요청이 어디서 느렸나 | 그게 평소 대비 이상한지 |
그래서 조사는 대개 메트릭에서 시작해 로그·트레이스로 갈라진다. 셋 중 하나만 있으면 그 신호가 답하지 못하는 질문 앞에서 매번 막힌다.
도구 넷을 각각 설치하는 건 하루면 된다. 진짜 값은 그래프에서 튄 점을 눌러 그 순간의 트레이스로 가고, 그 트레이스에서 그 서비스의 로그로 건너뛰는 연결에서 나온다. 그 연결이 없으면 창을 세 개 띄워 놓고 시각을 손으로 맞추게 되고, 그러면 아무도 관측 스택을 안 쓴다.
이어 붙이는 장치는 셋뿐이다 — 로그의 trace_id, 메트릭에 매다는 표본 링크(exemplar),
트레이스→로그 링크.
대시보드보다 이 셋이 먼저다 (5장).
하루 로그 100GB는 견딘다. 라벨에 request_id를 넣은 앱 하나는 못 견딘다.
라벨 조합 하나가 시계열 하나(Prometheus) · 스트림 하나(Loki)이기 때문에,
값의 가짓수가 무한한 것을 라벨에 넣으면 저장소가 아니라 인덱스와 메모리가 먼저 터진다.
원칙 하나 — 라벨은 값의 종류를 미리 셀 수 있는 것만. 나머지는 본문·속성에 넣고 질의할 때 파싱한다.
Grafana AlloyOTelOpenTelemetry2026년 8월 기준이다. 관측 스택은 2026년에 수집기와 트레이스 백엔드가 동시에 바뀐 시기를 지났다 — Promtail EOL과 Tempo 3.0이다. 둘 다 옛 방식으로 쓰인 문서가 검색 결과에 훨씬 많이 남아 있어서, 시점 확인이 특히 중요하다.
| 항목 | 지금 | 낡은 정보 (검색 결과에 많이 남아 있음) |
|---|---|---|
| 수집기 | Grafana Alloy — 로그·메트릭·트레이스를 한 에이전트로 | Promtail은 2026-03-02 EOL — 대부분의 Loki 튜토리얼이 아직 Promtail 기준 |
| Loki Helm 차트 | 2026-03-16부터 grafana-community/helm-charts | grafana/helm-charts 저장소를 가리키는 설치 명령 |
| 트레이스 | Tempo 3.0 — 인입과 질의를 분리한 새 아키텍처. ingester · compactor · v2 블록 제거, 2.x로 되돌릴 수 없다 | ingester/compactor를 튜닝하는 2.x 기준 운영 글 |
| 메트릭 | Prometheus 3.13 LTS — OTLP 수신 · UTF-8 라벨 | 2.x 기준 설정 (대부분 그대로 통하지만 새 기능이 빠져 있다) |
| 로그 저장소 | Loki 3.7 | 인덱스를 BoltDB에 두던 2.x 시절 구성 |
| 조회 | Grafana 13.1 | 알림이 Grafana와 Alertmanager로 갈라지기 전 자료 |
앞에서 뒤로 읽으면 실제 도입 순서와 대체로 같다 — 신호 이해(1장) → 메트릭·알림(2장) → 로그(3장) → 조회 연결(5장) → 추적(4장). 다만 급하면:
| 지금 처지 | 먼저 볼 장 |
|---|---|
| 아무것도 없다. 뭐부터 세우나 | 1장 끝의 “무엇부터 만드나” |
rate()가 뭔지 모른 채 남의 쿼리를 붙여 쓰고 있다 | 2장 메트릭의 생김새 · PromQL 절 |
| 그래프는 있는데 알림이 없다 | 2장 알림 설계 절 |
로그가 안 들어온다 · too many streams | 3장 라벨 설계와 점검 |
| 로그 검색이 매번 타임아웃된다 | 3장 LogQL 절 (필터 순서가 원인인 경우가 많다) |
| 로그에서 트레이스로 못 건너간다 | 5장 상관 관계 절 |
| 읽는 것보다 먼저 한 번 직접 해보고 싶다 | 8장 공식 샘플 준비 → 9장 공식 앱 조사 → 10장 첫 대시보드 |
| 내 서비스를 이 스택에 연결하고 싶다 | 4장 계측 절 → 11장 내 앱 계측 |
| Tempo 업그레이드했더니 안 뜬다 | 4장 Tempo 3.0 절 |
| 디스크가 차고 있다 | 2장 리텐션 · 3장 보존 · 온프렘 덱 8장 |