Prometheus 모니터링 실무 적용기 2탄

코인원 Prometheus 실무 적용기 2편으로, 수집한 metric 을 Grafana 대시보드와 알림으로 실제로 써먹는 방법을 다룬다. 차세대 거래 엔진의 성능 테스트를 위해 CPU, Memory, Network usage 대시보드를 만들고, 메모리 급증을 슬랙으로 받는 알림 규칙까지 구성한 과정이다.

핵심 포인트

시작은 차세대 엔진 프로젝트의 성능 테스트다. CPU 와 Memory, Network usage 를 범위로 잡고 Prometheus Web UI Console 에서 관련 metric 유무부터 확인했다.
kubernetes 관련 metric 은 체계적으로 잘 정의돼 있어 쿼리 입력창에서 바로 확인이 가능했다.
Pod 는 생성과 삭제가 반복돼 이름을 고정할 수 없으므로, kube_deployment_metadata_generation 쿼리로 Grafana variable 의 label_values 를 채웠다.
대시보드는 대형 모니터에 띄워 전체 애플리케이션의 사용량 추이를 한눈에 보게 구성했고, 화면 크기 제약 때문에 꼭 필요한 metric 만 골랐다.
함정 하나를 짚는다. Grafana 는 Prometheus 쿼리에 variable 을 쓰면 그 대시보드에 Alert 를 만들 수 없다.

상세 정리

선별한 지표는 Pod 수량과 상태, Node 의 Memory 및 Disk usage, 해당 Node 에서 도는 Pod 개수, Uptime 정도다.
대시보드는 상단 드롭다운에서 namespace 와 pod 를 고르면 해당 항목이 행 단위로 펼쳐지는 구조이고, Node 도 같은 방식으로 만들었다.
실제 장애 사례가 있다. 사이트 기능이 간헐적으로 문제를 일으켰는데 kubectl 로는 Pod 가 멀쩡히 running 이었다.
Prometheus 데이터를 보니 특정 Pod 의 Memory 사용률이 급격히 오르고 있었다. 수정과 검증에 시간이 오래 걸린다는 피드백을 받았고, 24시간 운영이라 언제 재발할지 알 수 없었다.
확실한 것은 평상시 메모리 사용량이 일정하다는 점이었다. 그래서 Grafana 알림 규칙을 만들고 슬랙으로 알림을 받도록 지정했다.
variable 제약은 알림 전용 대시보드를 따로 만들고 쿼리의 variable 자리를 고정값으로 바꿔 해결했다.
Prometheus alertmanager 로도 구성할 수 있지만, Grafana 쪽이 언제 문제가 생겼고 알림을 보냈으며 해결됐는지 확인하기 좋아 그쪽을 택했다.
운영 초기에 Worker Node 의 CPU 나 Memory 가 부족해 Pod 가 pending 으로 멈추는 일이 잦아, Node 리소스 현황 대시보드도 만들었다.
이 대시보드는 자원이 부족할 때 다른 Node 로 배포할지 Node 를 늘릴지 판단하는 근거로 쓴다.
개별 Worker Node 안에 어떤 Pod 가 생성됐고 얼마나 쓰는지 보는 대시보드도 앞선 쿼리들을 응용해 만들었다.
저자는 방대한 metric 앞에서 손을 놓기보다 기본적인 것부터 하나씩 구성해 자기 팀에 맞는 모니터링을 만들어가기를 권한다.