지속 서비스는 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를 숨기지 않는지 검증해야 합니다.
01 · REQUIREMENTS
사용자 영향과 플랫폼 건강을 다른 신호로 본다
# 요구사항
대시보드가 많다고 관측 가능성이 높아지는 것은 아닙니다. 서비스 SLI, platform health, telemetry freshness의 failure domain을 나누고, 각 signal이 어떤 의사결정을 지원하는지 먼저 정합니다.
R1제한된 label
route·code·region처럼 유한한 값을 쓰고 user ID·raw URL은 차단합니다.
R2내구성 있는 ingest
WAL과 backpressure로 restart·burst 때 손실 범위를 설명합니다.
R3질의 분리
raw 조사, recording rule, long-term aggregate를 서로 다른 budget으로 둡니다.
R4행동 가능한 alert
각 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는 사람에게 전달할 판단을 담당합니다. 어느 한 단계의 성공을 전체 관측 성공으로 과장하지 않습니다.
사용자 영향 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 수를 측정한다.
INTERVIEW ↔ PRACTICE · 면접과 실무의 차이
cardinality guard를 설명하고 alert owner·ack를 운영하기
INTERVIEW · 면접
수집량보다 고유 label 조합과 행동 가능한 경보의 경계를 먼저 답합니다.
scrape와 제한적 push의 수명 경계를 설명합니다.
active-series budget과 WAL·head 회복을 말합니다.
firing·delivery·acknowledgement를 구분합니다.
PRACTICE · 실무
고카디널리티 배포와 alert storm을 주입해 보호 범위를 확인합니다.
series 증가율·reject reason·WAL replay age를 관측합니다.
owner 없는 alert와 과도한 grouping을 찾아 수정합니다.
receiver 장애 뒤 escalation과 실제 acknowledgement를 검증합니다.