[kubernetes] 모니터링

모니터링 대상

1. host(node-exporter)
   노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링
2. container(kubelet[cadvisor])
   노드에서 가동되는 컨테이너에 대한 정보. CPU, 메모리, 디스크, 네트워크 사용량 등
3. app
   컨테이너안에서 구동되는 개별 애플리케이션의 지표를 모니터링. 애플리케이션의 응답시간, HTTP 에러 빈도 등을 모니터링
4. kubernetes({etcd <- api} -> kube-state-metrics)
   쿠버네티스 자체에 대한 모니터링. 서비스나 POD, 계정 정보 등이 해당

 

 

Prometheus

Metric Collector + Metric Database
Opensource Monitoring/ alerting tool
실제 프로덕션에서 사용하는 비율이 70% - 2020

 

프로메테우스 아케텍쳐

주황색 아웃라인이 그려진 것들이 프로메테우스의 구성요소이다. 각 구성요소들이 파드로 실행된다.

가장 중요한 것은 중앙의 Prometheus server이다. 그 중 Retrieval은 회수/수집의 의미를 가진다.

 

Prometheus targets - 프로메테우스가 측정할 대상, VM, 컨트롤 플레인, 워커 노드의 호스트, 파드 등의 CPU, Memory 정보가 될 수 있다.

Jobs/exporters - Job은 프로세스나 App이 될 수 있다.

 

Short-lived jobs이 metrix을 수집해서 가져온다. (Pull metrics)
metric이란 수집 가능한 요소(: CPU, Memoty, Network IO, Disk IO)들을 수집한 것이다.

 

Short-lived jobs(금방 생성되고 금방 삭제되는 것)들은 제대로 측정을 하지 못하는 경우가 생긴다.
생명주기가 짧은 애들은 미쳐 가져오기도 전에 생명주기가 끝나서 모니터링을 할 수 없다.

Pushgateway - 생명주기가 짧은 것들은 Pushgateway가 대신해서 생명주기가 끝나기 전에 메트릭을 미리 받아둔다.

 

즉, Retrieval이 Pushgateway 또는 해당되는 타겟의 해당되는 메트릭을 pulling하여 데이터를 수집한다.

 

 

왜 프로메테우스를 사용하는가?
1. 메트릭 수집을 위한 서버나 컨테이너 구성/설치 불필요
2. 애플리케이션에서 메트릭 푸시를 위해 CPU 사용이 불필요
3. 중앙 집중식 구성 및 관리 콘솔 제공
4. 서비스 장애 및 비가동 상황을 gracefully 처리 가능
5. 수천, 수만개의 메트릭을 직접 보지 않고 쿼리를 통해 그때그때 보기 때문에 트래픽 및 오버헤드 감소
6. pull 방식이 불가능할 경우 Pushgateway로 Push 방식 수집 가능

 

 

Metric 수집 방식의 이해

Push

• 모니터링 주체가 서버에 정보를 보냄
• 수집 서버 정보를 알아야 함. agent에는 반드시 system agent가 설치되야 하고 agent는 중앙에 있는 서버에 metric을 보내야 하기 때문에 서버의 end-point IP를 알아야 한다. metric 정보가 변경될 때 마다 재 배포 해야 한다.
• 버퍼링 메커니즘(queue)
• 구성관리도구(CMDB) 필요
• 예) TICK Stack, Nagios

Pull (prometheus 방식)

• exporters(like agent)
• 보통 수집 서버에 대한 정보를 agent나 서비스들이 알지 못한다. 프로메테우스는 agent가 내부 metric을 노출하고, 프로메테우스 중앙 집중형 컴포넌트가 metric을 수집한 후 DB에 저장한다.
• 중앙집중식 모니터링이지만 agent는 서버에 대한 정보를 모르고 외부에서 exporter나 다른 정보들이 metric을 expose 하는 것
• Service Discovery; k8s같은 오케스트레이션 툴을 통해 리소스에 있는 정보를 다이나믹하게 가져오는 방식
• push 방식도 지원