Kubernetes 모니터링 구축 가이드 - Prometheus와 Grafana를 어떻게 운영할까
Kubernetes 운영에서 필수인 모니터링 체계를 Prometheus와 Grafana 기준으로 설명합니다. 어떤 메트릭을 수집해야 하는지, 알림 설계는 어떻게 해야 하는지, 운영 중 흔한 실수까지 실무 관점으로 정리합니다.
TestForge Team ·
모니터링이 없으면 운영은 추측이 된다
Kubernetes는 장애 지점이 많습니다.
- node
- pod
- deployment
- ingress
- application
- database
그래서 “왜 느린가”, “왜 재시작하는가”, “왜 배포 이후 에러가 늘었는가”를 보려면 메트릭이 필수입니다.
기본 구성
가장 보편적인 조합:
- Prometheus: 수집
- Alertmanager: 알림
- Grafana: 시각화
추가로 자주 함께 봅니다.
- kube-state-metrics
- node-exporter
- cAdvisor 계열 메트릭
최소한 봐야 하는 메트릭
클러스터 수준
- node CPU / memory
- disk pressure
- node ready 상태
워크로드 수준
- pod restart count
- deployment unavailable replicas
- container CPU throttling
- memory working set
서비스 수준
- request rate
- error rate
- latency p95/p99
비즈니스 수준
- 주문 실패율
- 로그인 실패율
- 결제 성공률
이 중 마지막은 인프라 메트릭보다 더 중요할 때가 많습니다.
알림은 어떻게 설계할까
좋은 알림 원칙:
- 즉시 대응이 필요한 것만 페이지
- 추세성 경고는 채널 알림
- 중복 알림 최소화
예:
- node down: page
- deployment replica 부족: page 또는 high-priority alert
- CPU 70% 지속: Slack 경고
흔한 실수
모든 메트릭을 다 모으는 경우
비용도 커지고, 실제 필요한 지표가 묻힙니다.
대시보드는 화려한데 알림이 약한 경우
문제는 대시보드가 아니라 대응 속도에서 드러납니다.
인프라 메트릭만 보고 앱 메트릭이 없는 경우
사용자 영향은 잘 안 보입니다.
마무리
좋은 Kubernetes 모니터링은 많은 그래프가 아니라, 장애를 빨리 발견하고 원인 범위를 줄일 수 있는 구조입니다.
Prometheus와 Grafana는 도구일 뿐이고, 중요한 것은 무엇을 수집하고 어떤 기준으로 알림을 줄지 정의하는 것입니다.