1. Prometheus
쿠버네티스에 종속적이지 않고, 바이너리 혹은 docker container 형태로도
사용하고 배포 가능
쿠버네티스 생태계의 오픈 소수 중에서는 사실상의 표준
특징
- 수집하는 Metric 데이터를 다차원의 시계열 데이터 형태로 저장
- 데이터 분석을 위한 자체 언어 PromQL 지원
- 시계열 데이터 저장에 적합한 TimeSeries DB 지원
- 데이터 ㅜ집하는 방식이 Pull 방식
- 모니터링 대상의 Agent가 Server로 Metric을 보내는 Push 방식이 아닌,
Server가 직접 정보를 가져가는 Pull 방식
- 다양한 시각화 툴과의 연동
- 다양한 방식의 Alarming 지원
구조
-
Prometheus Server
- 시계열 데이터를 수집하고 저장
- Metric 수집 주기를 설치 시 정할 수 있으며 default는 15초
-
Service Deiscoery
- Monitoring 대상 리스트를 조회
- 사용자는 쿠버네티스에 등록하고, Prometheus Server는 쿠버네티스 API Server에게 모니터링 대상을 물어보는 형태
-
Exporter
-
Prometheus가 metrics를 수집해갈 수 있도록 정해진 HTTP Endpoint를
제공하여 정해진 형태로 metrics를 Export
-
Prometheus Server가 이 Exporter의 Endpoint로 HTTP GET Request를 보내, metrics를 Pull하여 저장
-
하지만, 이런 pull 방식은 수집 주기와 네트워크 단절 등의 이유로
모든 Metrics 데이터를 수집하는 것을 보장할 수 없기 때문에 Push 방식을 위한
Pushgateway 제공
-
Pushgateway
- 보통 Prometheus Server의 pull 주기 (period) 보다 짧은 lifecycle을 지닌 작업의 metrics 수집 보장을 위함
-
AlertManager
- PromQL을 사용해 특정 조건문을 만들고, 해당 조건문이 만족되면
정해진 방식으로 정해진 메세지를 보냄.
- ex) service A가 5분간 응답이 없으면, 관리자에게
슬랙 DM과 이메일 발송
-
Grafana
- Prometheus와 항상 함께 연동되는 시각화 툴
- Prometheus 자체 UI도 있고, API 제공을 하기에 직접 시각화 대시보드 구성 가능
-
PromQL
- Prometheus가 저장한 데이터 중 원하는 정보만 가져오기 위한
Query Language
- Time Series Data이며, Multi-Dimensional Data이기 때문에,
처음 보면 다소 복잡할 수 있으나 Prometheus 및 Grafana를 잘 사용하기 위해서는 잘 익혀두어야 함.
단점
- Scalability, High-Availability
- Prometheus Server가 Single Node로 운영되어야 하기 때문에 발생하는 문제
- Thanos 라는 오픈 소스를 활용해 multi prometheus server 운영
2. Grafana
다양한 외부 플러그인
https://grafana.com/grafana/plugins/
다양한 Grafana Dashboard
https://grafana.com/grafana/dashboards/
Grafana Dashboard 모범사례
-
수많은 Metric 중 모니터링 해야할 대상을 정하고
어떤 방식으로 시각화 할 것인지에 대한 정답은 없다.
-
다만, Goolgle에서 제시한 전통 SW 모니터링을 위한 4가지 황금 지표는 다음과 같다.
- Latency
- 사용자가 요청 후 응답을 받기까지 걸리는 시간
- traffic
- Errors
- Saturation
-
ML 기반의 서비스를 모니터링할 때도 위 4가지 지표를 염두에 두고
대시보드를 구성하는 것을 권장
- 다만, 처음 시작할 때는 위의 다양한 오픈 소스 대시보드 중
하나를 import 하는 것부터 시작