Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
Tags
- HTTP
- aws
- backend
- DevOps
- 버전관리
- SRE
- Infra
- Operations
- auth
- API
- CSS
- reliability
- Microservices
- architecture
- CI
- Git
- frontend
- Security
- NextJS
- Debugging
- react
- 성능
- web
- Ops
- Kubernetes
- Performance
- database
- version-control
- observability
- JavaScript
Archives
- Today
- Total
고민보단 실천을
Prometheus scrape/relabeling 실전: 지표 라벨 폭발을 막고 쿼리를 빠르게 만드는 법 본문
Prometheus scrape/relabeling 실전: 지표 라벨 폭발을 막고 쿼리를 빠르게 만드는 법
Prometheus가 느려지고 비용이 늘어나는 가장 흔한 이유는 '라벨 폭발'입니다.
scrape/relabeling으로 지표를 운영 가능한 형태로 정리하는 방법을 실무 기준으로 정리합니다.
이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.
왜 이게 어려운가(운영 관점)
운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).
따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.
실전 내용(바로 적용)
Prometheus가 느려지고 비용이 늘어나는 가장 흔한 이유는 '라벨 폭발'입니다.
scrape/relabeling으로 지표를 운영 가능한 형태로 정리하는 방법을 실무 기준으로 정리합니다.
핵심 요약(결론부터)
- 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
- 실패/예외/회귀를 운영 체크리스트로 막는다
- 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다
라벨 폭발이 왜 문제인가
카디널리티가 커지면 메모리/CPU/스토리지 비용이 급증
대시보드 쿼리가 느려지고 알람이 불안정
relabeling으로 줄이는 전략
- 불필요한 라벨 drop
- 동적 값(요청 ID 등) 금지
- labelmap/replace를 최소화
가드레일(요약)
요청 ID/유저 ID 같은 고카디널리티 라벨 금지
namespace/pod 등 필요한 라벨만 유지
대시보드/알람 쿼리 성능도 같이 측정운영 체크리스트(바로 적용)
- 카디널리티 상위 지표를 정기 점검
- relabel 규칙은 PR로 관리
- 알람 쿼리의 실행 시간/부하를 검증
FAQ
Q. 라벨을 많이 넣으면 더 좋은 거 아닌가요?
A. 디버깅에는 좋아 보이지만, 운영 비용이 폭발합니다. 로그/트레이스와 역할을 분리하는 게 안전합니다.
마무리: 다음 액션
- 팀의 기본값(정책)을 1페이지로 문서화한다
- 대표 시나리오 1개를 코드/설정 예시로 고정한다
- 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다
자주 하는 실수(사고 패턴)
- 증상만 보고 timeout/limit을 크게 늘려 원인을 숨긴다
- 프로브/스케일/리소스를 따로따로 튜닝해 전체 QoS가 흔들린다
- 변경 후 효과를 지표로 검증하지 않아 회귀가 반복된다
- 운영 자동화(CI/CD)에서 권한/보안 경계를 느슨하게 둔다
적용 순서(추천)
- 1) 지표로 증상을 고립한다(오류율/지연/재시도율/리소스)
- 2) 타임아웃을 레이어별로 정렬한다(client > proxy > server > db)
- 3) 스케일(파드/노드)과 워밍업(readiness)을 같이 설계한다
- 4) 변경은 작게/단계적으로 하고, 알람/롤백을 같이 준비한다
- 5) 운영 기준을 문서로 고정하고, 체크리스트로 반복 가능하게 만든다
검증/회귀 방지
- 재현: 스파이크/롤링업데이트/대용량 업다운로드 같은 시나리오를 고정
- 로그: upstream time, 종료 이벤트, 재시도 횟수 같은 필드를 고정
- 알람: OOMKilled, throttling, 5xx burst, p99 spike를 조기 경보로 운영
팀 합의 템플릿(복붙용)
# 장애 대응 템플릿(복붙용)
증상: (오류율/지연/시점/영향 범위)
가설: (타임아웃/리소스/종료/프록시/코드)
검증: (재현/로그/지표 링크)
조치: (설정 변경/배포/롤백)
재발 방지: (알람/체크리스트/문서)FAQ
Q. 라벨을 많이 넣으면 더 좋은 거 아닌가요?
A. 디버깅에는 좋아 보이지만, 운영 비용이 폭발합니다. 로그/트레이스와 역할을 분리하는 게 안전합니다.
참고/출처
버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.
Comments
