route·code·region처럼 유한한 값을 쓰고 user ID·raw URL은 차단합니다.
메트릭 모니터링·
알림 시스템 설계
좋은 모니터링은 모든 값을 모으는 일이 아닙니다. 사용자 영향과 SLO에 연결되는 신호를 제한된 cardinality로 수집하고, 저장·질의·경보의 실패 경계를 각각 설명 가능하게 만드는 일입니다.
개념 이해수집 경계장애 대응SLO·알림진도 저장
30초 핵심 요약
지속 실행 서비스는 pull scrape로 관측하고, 짧게 끝나는 batch 결과만 제한된 push 경계로 받습니다. ingestion은 cardinality guard → WAL → head → block compaction으로 나누고, 반복 질의는 recording rule로 저장합니다. alert는 threshold만이 아니라 SLO, `for`, grouping, dedupe, silence, receiver failure까지 하나의 운영 흐름으로 설계합니다.
수집 기본값Scrape · bounded labels
저장 경계WAL → TSDB block
경보 의미Firing ≠ acknowledged
01 · REQUIREMENTS
# 요구사항사용자 영향과 플랫폼 건강을 다른 신호로 본다
대시보드가 많다고 관측 가능성이 높아지는 것은 아닙니다. 서비스 SLI, platform health, telemetry freshness의 failure domain을 나누고, 각 signal이 어떤 의사결정을 지원하는지 먼저 정합니다.
WAL과 backpressure로 restart·burst 때 손실 범위를 설명합니다.
raw 조사, recording rule, long-term aggregate를 서로 다른 budget으로 둡니다.
각 page에 owner·runbook·SLO·dedupe 정책을 연결합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처수집·저장·질의·경보를 하나의 신뢰성 경로로 잇는다
scrape fleet는 target lifecycle을, ingest gateway는 tenant·cardinality budget을, TSDB는 durable sample과 range query를, rule evaluator와 alert router는 사람에게 전달할 판단을 담당합니다. 어느 한 단계의 성공을 전체 관측 성공으로 과장하지 않습니다.
메트릭 수집에서 on-call까지의 흐름 SVG DIAGRAM · scrape / WAL / TSDB / rules / alerts
경계: Alertmanager류 router의 grouping·dedupe·silence는 notification volume을 관리합니다. firing alert가 고객 영향 확정, notification 성공이 사람이 확인했다는 뜻은 아닙니다. incident acknowledgement와 해결은 별도 상태로 남깁니다.
03 · WRITE / READ FLOW
# 흐름sample의 내구성과 경보의 의미를 별도 상태로 남긴다
write path는 cardinality guard와 WAL로, read path는 query budget과 recording rule로 보호합니다. alert path는 pending·firing·silenced·notified를 구분해야 timeout과 중복 전달을 설명할 수 있습니다.
서비스가 canonical name·unit과 bounded label로 집계값을 노출합니다.
collector가 target을 읽고 auth·quota·cardinality rule을 검사합니다.
shard WAL append 뒤 최신 chunk와 in-memory index를 갱신합니다.
compaction이 immutable block을 만들고 query가 hot/cold tier를 읽습니다.
SLO rule의 후보를 grouping·dedupe·silence 정책으로 전달합니다.
04 · TRADEOFFS
# 트레이드오프관측 해상도는 저장비·질의비·사람의 주의를 함께 바꾼다
고해상도 raw metric과 장기 분석, instance-level diagnosis와 symptom alert, push 편의와 target freshness는 한 선택으로 모두 최적화되지 않습니다.
| 선택 | 장점 | 제약 | 권장 판단 |
|---|---|---|---|
| Pull scrape | target 목록·마지막 성공·timeout을 collector가 관찰 | network reachability와 scheduling 필요 | 지속 실행 서비스의 기본값 |
| Push gateway | scrape 전에 끝나는 batch result 보존 | 장기 service lifecycle·health가 흐려짐 | ephemeral job 결과에 한정 |
| Raw range query | 조사·backfill 자유도 | 광범위 selector와 장기 range 비용 | interactive budget과 limit 아래에서 |
| Recording rule | dashboard·SLO·alert의 계산 공유 | rule stale·오류도 운영 대상 | 반복 expression의 기본 |
| Per-instance page | 장애 위치가 명확 | alert storm·fatigue 위험 | symptom은 group, diagnosis는 drill-down |
05 · FAILURE MODES
# 장애 6가지여섯 가지 실패를 데이터 공백과 운영 행동으로 나눈다
scrape timeout
exporter·TLS·network failure가 최신 sample을 비우고 missing data를 business failure처럼 보이게 할 수 있습니다.
대응 · `scrape_success`, 마지막 성공, service traffic을 함께 확인하고 freshness 회복을 검증합니다.
label cardinality 폭증
user ID, raw URL, request ID가 각 sample마다 새 series를 만들어 head memory·index와 query 비용을 급증시킵니다.
대응 · allowlist·quota·route 정규화로 차단하고 active series 증가율이 안정되는지 봅니다.
WAL disk full
append 실패나 restart 뒤 replay 지연으로 ingest gap과 recovery time이 길어집니다.
대응 · disk headroom·throttle·replay age를 관측하고 gap의 실제 범위를 incident에 남깁니다.
compaction backlog
작은 chunk와 pending block이 누적되어 disk를 채우고 long-range query가 느려질 수 있습니다.
대응 · compaction I/O·concurrency·checksum을 점검하고 backlog drain을 확인합니다.
rule evaluation 지연
비싼 expression이나 query fan-out이 evaluation interval을 넘겨 alert와 recording series를 stale하게 만듭니다.
대응 · recording rule 분해·query budget·duration SLI로 interval 아래 회복을 검증합니다.
alert storm·route 오류
한 root cause가 수백 page로 fan-out되거나 잘못된 route가 핵심 on-call을 건너뛸 수 있습니다.
대응 · group·dedupe·inhibition·silence를 game day에서 시험하고 receiver failure를 별도 alert로 둡니다.
06 · OPERATIONS
# 운영보안·관측·비용은 플랫폼 자체의 SLO가 된다
scrape·remote-write에는 workload identity와 최소 권한을 적용하고, labels·annotations·exemplars에서 ID·secret·raw query를 배제합니다.
mTLS · RBAC · audit · TTL
ingest reject, active series, WAL replay age, compaction backlog, query scanned series, rule duration, receiver failure를 플랫폼 SLI로 둡니다.
freshness · lag · reject reason
sample rate보다 metric family × labelset × histogram bucket × retention × replica가 비용을 결정합니다. raw/hot/cold tier를 분리합니다.
series × retention × query fan-out
면접 모드 · 추가 질문06:00
“18,000개 target에서 평균 150만 samples/s를 수집하고 checkout SLO를 page해야 합니다. pull과 push의 경계, label cardinality budget, WAL·compaction·retention, recording rule, alert grouping·silence와 alert fatigue를 어떤 상태·지표·실패 시나리오로 설계하겠습니까?”
scrape defaultbounded labelWAL → blockSLO recording rulededupe · silence
SOURCES
공식·1차 출처
- Prometheus — Instrumentation: online-serving·batch 관측, label cardinality, metric type 가이드.
- Prometheus — Metric and label naming: unit·name과 high-cardinality label의 비용 경고.
- Prometheus — Alerting rules: rule evaluation과 pending·firing alert rule 설정.
- Prometheus — Alertmanager: grouping, dedupe, routing, silences, inhibition 개요.
- Prometheus — Storage: local storage, WAL, block compaction과 운영 고려사항.
- OpenTelemetry — Metrics data model: metrics identity, attributes, aggregation과 변환 모델.
NEXT CASE STUDY결제 시스템 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- Prometheus — Instrumentation: online-serving·batch 관측, label cardinality, counter·gauge 사용 가이드.
- Prometheus — Metric and label naming: metric unit·name과 high-cardinality label 경고.
- Prometheus — Alerting rules: rule evaluation과 alert state·`for` 설정.
- Prometheus — Alertmanager: dedupe, grouping, routing, silences, inhibition 개요.
- Prometheus — Storage: local storage, WAL, compaction과 운영 고려사항.
- OpenTelemetry — Metrics data model: metrics data model, attributes, aggregation과 변환.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.