route·code·region처럼 유한한 값을 쓰고 user ID·raw URL은 차단합니다.
메트릭 모니터링·
알림 시스템 설계
모든 값을 오래 모으면 관측이 좋아지는 것이 아닙니다. cardinality와 경보 수가 사람과 저장소의 한계를 넘지 않도록 사용자 영향에 연결되는 신호부터 남깁니다.
개념 이해수집 경계장애 대응SLO·알림진도 저장
30초 핵심 요약
지속 서비스는 scrape하고 ingest 앞에서 무한 label과 active-series budget 초과를 막습니다. 반복 계산은 recording rule로 줄이며 owner·runbook·severity가 있는 SLO 경보만 전달합니다.
수집 기본값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와 해결은 별도 상태로 남깁니다.
카디널리티 폭증을 막으면서 사람이 행동할 경보만 어떻게 남길 것인가?
예시 ingest
150만 samples/s
계산 결과
예시 피크
375만 samples/s
계산 결과
예시 활성 시계열
2,400만
설계 가정
bounded-label scrape + active-series guard + owner SLO alert
지속 서비스는 scrape하고 ingest 앞에서 label deny rule과 서비스별 active-series budget을 적용합니다. recording rule로 SLO 신호를 줄인 뒤 owner·runbook·severity가 있는 alert만 route합니다.
선택 이유
- 한 배포의 무한 label이 전체 WAL·head·query를 압박하는 일을 앞에서 차단합니다.
- 기존 정상 series를 유지하며 신규 고카디널리티 조합만 이유별로 거절할 수 있습니다.
- receiver 성공과 on-call acknowledgement를 다른 상태로 운영합니다.
모든 dimension을 label로 저장한 뒤 query에서 정리
저장 시점에 이미 series 조합과 index 비용이 폭증하므로 느린 query를 고치는 것만으로 ingest 장애를 복구할 수 없습니다.
감수한 단점
- budget이 너무 낮으면 필요한 진단 차원을 잃을 수 있습니다.
- 거절된 label의 원인을 개발팀이 빠르게 찾을 tooling이 필요합니다.
- recording rule과 grouping이 세부 incident를 숨기지 않는지 검증해야 합니다.
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을 오래 보관하면 조사 폭은 넓어지지만 저장·질의·경보 피로가 함께 늘어납니다. SLO 판단에 필요한 신호와 진단용 세부 신호의 보존 기간을 나눕니다.
| 선택 | 장점 | 제약 | 권장 판단 |
|---|---|---|---|
| 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
답변 구조 보기 5단계
- 사용자 영향 SLI와 SLO를 먼저 정하고 수집 가능한 모든 값을 label로 만들지 않는다.
- 지속 서비스는 scrape, 짧은 batch 결과는 제한적 push로 경계를 나눈다.
- cardinality budget을 ingest 앞에서 적용하고 WAL·head·block의 회복 지표를 분리한다.
- 반복 질의는 recording rule로 줄이고 alert에는 owner·runbook·severity를 요구한다.
- firing·receiver success·on-call ack·mitigation을 서로 다른 상태로 추적한다. 이번 선택: bounded-label scrape와 active-series guard를 기본으로 두고, SLO rule과 owner가 있는 alert만 사람에게 전달한다. 깨지는 신호: 신규 series 증가율이 budget을 넘거나 receiver 성공 뒤에도 acknowledgement가 지연된다. 다음 검증: 고카디널리티 배포와 alert storm을 재현해 차단 범위, WAL 회복 시간, 실제 page 수를 측정한다.
cardinality guard를 설명하고 alert owner·ack를 운영하기
수집량보다 고유 label 조합과 행동 가능한 경보의 경계를 먼저 답합니다.
- scrape와 제한적 push의 수명 경계를 설명합니다.
- active-series budget과 WAL·head 회복을 말합니다.
- firing·delivery·acknowledgement를 구분합니다.
고카디널리티 배포와 alert storm을 주입해 보호 범위를 확인합니다.
- series 증가율·reject reason·WAL replay age를 관측합니다.
- owner 없는 alert와 과도한 grouping을 찾아 수정합니다.
- receiver 장애 뒤 escalation과 실제 acknowledgement를 검증합니다.
TECHNICAL DOCUMENTS
기술 규격·공식 문서
- 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과 변환 모델.
이 문제와 이어지는 문서분산 메시지 큐
수집 backlog와 처리 지연을 연결합니다.
REAL PROJECT CASE
실제 구현 해설 보기 →
AI Systems Atlas에서 이 개념 보기
파싱·저장·검색·화면 투영 단계별 지연과 품질 지표를 분리하는 운영 사례입니다.
TECHNICAL DOCUMENTS & CONTACT
문의·정정
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.