03 · 우리가 보는 자기감시 메트릭

Phase 1이 제대로 적용됐는지 전송이 건강한지 판정할 때 보는 자기감시(self-monitoring) 메트릭을 정리합니다. 02의 적용 후 확인이 여기로 이어집니다.

관련 문서: 02 vmagent 전송 튜닝 · 실전 01 카디널리티 · 04 스케일링·용량 기준치 · 우리의 운영 허브

전송 상태 4지표

• vmagent_remotewrite_retries_count_total — 전송 재시도 횟수. 정상 기준: rate(...[5m]) ≈ 0 유지. 값이 오르면 목적지가 불안정하거나 write가 반복 실패하는 중입니다.
• vmagent_remotewrite_packets_dropped_total — 버려진 패킷 수. 정상 기준: increase(...[1h]) = 0 유지. 0이 아니면 데이터가 실제로 유실됐습니다(큐 상한 초과·포맷 거부 등).
• vmagent_remotewrite_bytes_sent_total — URL별 전송 바이트. 정상 기준: 안정적 추세. forceVMProto 효과 판정용(아래 참고).
• vmagent_remotewrite_pending_data_bytes — 아직 못 보낸 대기 큐 크기. 정상 기준: 평시 0 근처. 계속 증가하면 목적지 병목입니다(큐가 계속 쌓임).

PromQL 예제

# ① 재시도 — 0 근처 유지
rate(vmagent_remotewrite_retries_count_total[5m])

# ② 드랍 — 0 유지 (0이 아니면 유실 발생)
increase(vmagent_remotewrite_packets_dropped_total[1h])

# ③ URL별 전송량 — forceVMProto 효과 판정
sum(rate(vmagent_remotewrite_bytes_sent_total[10m])) by (url)

# ④ 대기 큐 — 지속 증가하면 목적지 병목
vmagent_remotewrite_pending_data_bytes

bytes_sent로 forceVMProto 효과 판정

forceVMProto 적용 전후로 URL별 전송량을 비교합니다.

• 뚝 떨어짐 → 여태 snappy로 나갔습니다. zstd 고정으로 절감이 확정됐습니다.
• 그대로 → 이미 zstd였다는 뜻입니다. 이번 변경은 다운그레이드 방지 보장만 추가했습니다.

둘 다 정상입니다. 떨어졌다면 절감 효과를 얻었고 그대로라면 원래 최적이던 상태를 고정했습니다. 나빠질 시나리오는 없습니다.

카디널리티 감시 — D2 개념 계승

전송 지표와 별개로 수집하는 시계열 자체가 건강한지도 확인해야 합니다. 원리는 D2 발표에서 정리한 그대로입니다 — churn rate(24시간 내 신규 시계열 생성 속도)와 slow insert rate(지속 10% 초과 시 메모리 부족 경고)를 봅니다. 개념과 임계의 근거는 실전 01 카디널리티에서 다룹니다. slow insert 임계를 운영에 어떻게 적용하는지는 04에도 정리했습니다.

인벤토리 도구

지금 어떤 지표가 카디널리티를 먹고 있는지는 다음으로 뽑습니다.

• vmui 카디널리티 익스플로러 — /vmui/#/cardinality
• 메트릭 이름별 통계 API — /api/v1/status/metric_names_stats

이 인벤토리로 무엇을 drop/keep 할지는 실측한 뒤 정할 예정입니다(TODO). 규칙을 성급하게 넣기보다 실제 분포를 먼저 봅니다.