1. Prometheus와 kubernetes
Kubernetes 모니터링에서 가장 높은 점유율을 보여주는 tool은 Prometheus입니다. Prometheus는 CNCF 재단의 2번째 graduate 프로젝트입니다.
Kubernetes component들이 노출하는 metric 형식 또한 prometheus metric 형식입니다.
따라서 Gitlab, jenkins, argocd, nginx-ingress, keycloak 등 많은 오픈소스 프로젝트에서 자신들의 메트릭을 prometheus metric 형식에 맞게 지원하고 있습니다.
( Kubernetes에 최적화가 잘 되어있고, 많은 오픈소스에서 공식 지원하는 만큼 prometheus를 잘 활용하면 아주 많은 것들을 할 수 있습니다. )
2. prometheus 동작 방식
Prometheus는 데이터를 수집할 대상을 정의해놓고, 수집 대상에 데이터를 요청하고 받아오는 방식으로 동작합니다.
2.1. EC2 환경에서의 prometheus 동작
이해를 돕기 위해 EC2 환경에서의 prometheus 동작을 간략하게 설명해보겠습니다.
위와 같이 메트릭 데이터를 수집할 대상(ex. agent)의 IP와 port정보를 prometheus.yaml
파일에 정의합니다.
Prometheus는 prometheus.yaml
에 정의된 수집 대상에게 데이터를 요청하고, 받아와서 TimeSeriesDataBase에 저장하게 됩니다.
2.2. Kubernetes에서의 prometheus 동작
kubernetes에서는 pod가 다시 생성되면 IP가 바뀌고, Service도 마찬가지입니다.
이처럼 수집 대상의 IP가 유동적이기 때문에, IP 정보를 수동으로 기입해서 대상을 정의하기가 어렵습니다.
( IP 정보가 바뀔 때마다 prometheus.yaml
을 수정해야 하기 때문입니다. )
따라서, Prometheus는 메트릭 수집 대상을 Discover하기 위해 Prometheus operator와 ServiceMonitor, PodMonitor와 같은 Custom Resource Definition을 구성했습니다.
여기서, Custom Resource Definition란 Kubernetes환경에서 사용자가 필요한 기능을 직접 구현할 수 있도록 Object를 직접 정의하는 것입니다. Custom Resource Definition을 통해 Object에 대한 정의를 해두고, 해당 CRD type의 Custom resource를 생성하여 정보를 etcd에 저장합니다.
pod - service - service monitor - Prometheus의 관계
특정 pod를 노출시키는 service → 특정 service를 지정하는 service monitor → service monitor를 이용해 scrape 할 pod를 decovery하는 prometheus
- Pod : pod Label을 정의 (metric을 노출시키는 기능이 있는 pod)
- Service : pod Label을 기준으로 해당 pod를 노출 + service label을 정의
- Service Monitor : service label을 기준으로 해당 service의 endpoint를 확인
- Prometheus operator : 현재 정의되어 있는 service monitor들을 prometheus config의 scrape 항목에 포함시키기 위해 configuration을 생성하고 prometheus.yaml secret을 업데이트
podmonitor, servicemonitor와 prometheus-operator, prometheus
ServiceMonitor와 PodMonitor는 모니터링 할 대상(수집 대상)에 대한 정보를 etcd에 저장하기 위한 용도로 사용됩니다. 여기서 etcd에 저장하는 것은 IP, port 정보가 아닌, kubernetes object인 pod나 service 정보가 포함된 Custom Resource 상태 정보입니다.
prometheus operator는 ServiceMonitor나 PodMonitor를 kubernetes API server에게 질의하고, 변경된 점이 있으면 prometheus.yaml 을 최신화 한 다음 kubernetes의 secret 형식으로 생성합니다.
재정의한 prometheus configuration은 Prometheus pod에 속한 컨테이너 중, prometheus config reloader라는 컨테이너를 통해 prometheus 컨테이너가 사용하고 있는 prometheus.yaml
파일에 업데이트됩니다.
(동일한 pod 내에서 동작하는 여러 대의 container는 volume을 공유하기 때문에, 이처럼 prometheus pod 안에 prometheus container, prometheus config reloader container를 함께 배치시켜서 작동시킴으로써 config reloader가 prometheus의 prometheus.yaml
을 수정할 수 있습니다.)
이후의 prometheus 동작은 ec2환경과 동일합니다.
메트릭 수집 대상에 메트릭을 요청하고, 데이터를 받아서 저장합니다.
3. kubernetes에서의 prometheus 모니터링 대상
EC2 환경에서는 주로 node exporter를 이용하여 가상 머신의 cpu, memory, disk, network와 같은 메트릭 정보를 수집합니다.
3.1. node-exporter
kubernetes에서도 마찬가지로, worker node들의 리소스 사용량을 확인하기 위해 node exporter를 사용합니다.
( node exporter를 모든 worker node에 배포하기 위해 daemonset 형식으로 배포합니다. )
3.2. kubelet
kubernetes에서는 worker node의 리소스 사용량도 중요하지만, kubernetes object들의 리소스 사용량이나 현재 상태도 중요합니다.
kubernetes object의 리소스 사용량은 주로 kubelet에 붙인 servicemonitor를 통해 메트릭을 가져옵니다.
( kubelet은 원래 따로 service object가 존재하지 않지만, kubelet servicemonitor를 생성하면 prometheus operator가 그에 맞는 service object와 endpoints object를 생성합니다. )
3.3. kube-state-metrics
kubernetes object의 상태정보는 kube-state-metric이라는 agent를 설치하여 수집합니다.
주로 workload의 replica 개수, 상태, pod 상태, 타입 등의 정보를 수집할 수 있습니다.
3.4. ETC
지금까지 얘기한 항목들은 가장 기본적인 대상입니다.
이외에도 kubernetes에 배포하는 모든 것들(ex.gitlab, jenkins, nginx-ingress, keycloak, etc)에 대해서, 해당 서비스에서 노출시키는 metric이 있다면 podmonitor나 servicemonitor 를 생성하여 해당 서비스 모니터링에 대해 etcd에 등록하여 prometheus에서 수집하도록 할 수 있습니다.
예를 들어, ArgoCD의 Servicemonitor를 활성화시키면
- 현재 배포되어 있는 application의 정보
- sync 상태
- 참조하고 있는 git repository와의 sync상태
등을 prometheus에 수집할 수 있습니다.
'Monitoring' 카테고리의 다른 글
Loki Deployment to k8s (0) | 2023.02.14 |
---|---|
Prometheus ISSUE (0) | 2023.02.14 |
TSDB의 데이터 수집 방식 (polling, trapping) (0) | 2023.02.14 |
Prometheus Recording Rule (0) | 2023.02.14 |
prometheus relabeling (0) | 2023.02.14 |