[모니터링]프로메테우스, 모니터링 도구

프로메테우스(Prometheus)란?

모니터링 도구이다.

왜 프로메테우스를 쓸까?

• 마이크로 서비스, 클라우드 아키텍처가 적용되면서 DevOps가 훨씬 복잡해졌다.
• 컨테이너화된 애플리케이션이 다양한 컴퓨터에서 실행되고, 많은 프로세스들이 실행되며 그들은 서로 연결되어 있다.(마이크로서비스)
• 따라서 자동화가 필요하다.
• 엔지니어는 하드웨어 또는 애플리케이션 수준에서 잘 작동하는지 모니터링해야하는데, 너무너무 복잡하다.
• 애플리케이션 Error는 뜨는지, Response Latency가 너무 늦진 않은지, 애플리케이션이 Overloaded되진 않았는지, 하드웨어의 리소스가 애플리케이션을 실행하기에 충분한 리소스가 있는지.. 확인할 것들이 너무 많다.
• 만약 버그가 발생하여 다른 서비스에까지 장애를 일으킨다면 큰일이다. 빨리, 정확히 알아채고 디버깅해야할 것이다.
• 그래서 모니터링 툴을 사용하여 지속적으로 서비스를 모니터링하고, 문제가 발생했을때 알려주고, 문제가 발생하기 사전에 알아챌 수 있도록 한다.

프로메테우스는 어떻게 작동할까?

from TechWorld with Nana on Youtube

• 프로메테우스 서버는 위와 같이 3가지로 구성된다.
• CPU, memory 사용량과 같은 메트릭 데이터가 DB에 저장된다. 시계열 데이터(Time Series)를 저장한다.
• 애플리케이션이나, 서비스로부터 메트릭 데이터를 받아와(pull) DB에 저장한다.
• 엔드포인트로 서버에 접근하여 메트릭 데이터를 수집하여 DB에 저장한다.
• 이때 HTTP Server와 통신하여 Grafana와 같은 도구를 활용하여 메트릭을 UI로 볼 수 있다.

메트릭?

CPU, memory, ram 사용량 또는 네트워크, 요청 수 등 모니터링해야할 값을 가진 대상이다.

사람이 읽을 수 있는 포맷으로 구성된다.

3가지 타입이 있다.

• Counter: 얼마나 많은 (요청)이 있었나?
• Gauge: (CPU 사용량)이 얼마냐?
• histogram: (요청 바디의 용량이)얼마나 크냐? 얼마나 지속되었나?

어떻게 메트릭을 pull 해올까?

위의 Retrieval Worker는 HTTP 엔드포인트를 통해 메트릭을 가져온다.

뭐 리눅스 서버같은 것은 기본값으로 hostaddress/metrics를 통해 데이터를 가져올 수 있지만, 그렇지 않은 경우 직접 설정해주어야 한다. 이때 사용하는 것이 Exporter이다.

프로메테우스 공식 Exporter가 있다. 이를 참고하여 모니터링이 필요한 타겟서비스에 맞게 컨테이너 옆에 함께 띄워놓으면(사이드카 컨테이너) 메트릭이 수집된다고 한다.

 

예를 들어 쿠버네티스 exporter를 활용하여 메트릭을 수집하는 경우, 다음과 같이 아키텍처가 그려진다.

프로메테우스 서버는 Kube API를 사용하여 메트릭 데이터에 접근할 수 있고, 필요한 대부분의 데이터를 가져올 수 있다.

그런 후 Grafana를 통해 UI로 표시하거나 slack으로 메시지를 발송할 수 있다.

Pull vs. Push

프로메테우스는 pull 방식으로 메트릭을 가져온다했다. 그런데 다른 대분의 모니터링 시스템(Amazon Cloud Watch)은 Push 방식을 사용하고 있다. 둘은 어떻게 다르며 장단점은 무엇일까?

	pull	push
작동방식	프로메테우스 서버가 애플리케이션 또는 서버에 접근하여 메트릭 데이터를 가져옴	애플리케이션 또는 서버가 직접 메트릭 데이터를 전송함
네트워크	부담이 적음	각 애플리케이션이 중앙 데이터 수집 플랫폼으로 메트릭 데이터를 전송하므로, 네트워크가 혼잡함
필요한 소프트웨어 툴	필요없음(엔드포인트만 확보되면 됨)	각 서비스 마다 있음(데이터를 직접 전송해야 하므로)
가용성 (네트웨크 문제 등등)	전체 서비스에 문제가 있더라도, 보낼 수 있음	메트릭 데이터를 보낼 수 없음
동시성	가능(여러 프로메테우스 인스턴스가 하나의 메트릭을 수집할 수 있음)	불가(한 애플리케이션이 하나의 수집 플랫폼으로 보낼 수 밖에 없음)