프로메테우스(Prometheus) 알아보기

1. 프로메테우스(Prometheus)란?

• 메트릭 기반의 오픈소스 모니터링 시스템이다.
• 이벤트 모니터링 및 경고에 사용되는 무료 소프트웨어 응용 프로그램이다.
• 유연한 쿼리(PromQL) 및 실시간 경고가 가능하다.
• 구조가 간단해서 운영이 쉽고, 강력한 쿼리 기능을 가지고 있으며, 그라파나(Grafana)를 통한 시각화를 지원한다.
•  ELK와 같은 로깅이 아니라, 대상 시스템으로부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있는 시스템이다.
• Go 언어로 작성되었으며 아파치 2 라이선스를 사용한다.

메트릭이란?
수집하는 시계열 데이터를 말한다.
프로메테우스의 메트릭은 "메트릭명{필드1=값, 필드2=값} 샘플링데이터" 와 같이 수집된다.

2. 기능 및 구성

• 메트릭 수집, 시계열 데이터 저장
• 유연한 쿼리 언어인 PromQL을 통한 성능 분석
• 그라파나를 통한 데이터 시각화
• alertmanager를 통한 알림 생성 
• 애플리케이션 코드 계측을 위한 클라이언트 라이브러리

3. 아키텍처

• Pushgateway : Proxy Forwarding을 하여 접근할 수 없는 곳에 데이터가 존재하는 경우에 사용할 수 있는 대안이다. 애플리케이션이 Pushgateway에 메트릭을 push 한 후, Prometheus server가 Pushgateway에 접근하여 메트릭을 pulling 한다.
• Prometheus server : 프로메테우스의 메인 서버로 메트릭 데이터를 수집하고 저장한다. Prometheus server 내부에는 Retrieval, TSDB, HTTP server 모듈이 있다.
• TSDB(Time-series Database) : 수집된 메트릭은 Prometheus server 내의 메모리와 (default) 로컬 디스크에 저장된다. ( 필요에 따라 원격 서버에 데이터를 저장할 수 있다.) 데이터베이스에 별도로 저장하지 않기 때문에 대상 시스템이 늘어날수록 디스크를 늘려야 한다.
• HTTP Server : 프로메테우스에 저장된 데이터를 조회하기 위해서 필요한 서버이다. 프로메테우스는 데이터를 가져가기 위한 프로토콜로 HTTP REST API를 제공하고, 직접 API를 통해 데이터를 가져가든지, Web UI 대시보드에서 데이터를 조회하는 방법으로 그라파나를 통해 데이터를 시각화할 수 있다.
• Alertmanager : 프로메테우스에서 문제가 발생했다고 생각되는 시점에 slack, mail, hipchat 등을 통해 알람을 보내준다. 알람을 거는 기준은 Rule을 작성해서 load 시키는 방식으로 정할 수 있다.

 

4. 기본 동작 구조

4.1 Metric 수집

• 수집 하려는 대상 시스템이 Target System이다. MySQL이나, Tomcat 또는 VM과 같이 여러가지 자원이 모니터링 대상이 될 수 있다. 이 대상 시스템에서 메트릭을 프로메테우스로 전송하기 위해서는 Exporter라는 것을 사용한다.

4.2 Pulling 방식

• 프로메테우스가 Taget System에서 메트릭을 수집하는 방식을 Pulling 방식을 사용한다. 프로메테우스가 주기적으로 Exporter로부터 메트릭을 읽어와서 수집하는 방식이다. 보통 모니터링 시스템의 에이전트들은 에이전트가 모니터링 시스템으로 메트릭을 보내는 Push 방식을 사용한다. 특히 Push 방식은 서비스가 오토 스켈링등으로 가변적일 경우에 유리하다. Pulling 방식은 모니터링 대상이 가변적으로 변경될 경우, 모니터링 대상의 IP 주소들을 알 수 없기 때문에 어려운 점이 존재한다.

4.3 Service Discovery

• 프로메테우스도 서비스 디스커버리 시스템과 통합을 하도록 되어 있다. 앞에서 언급한 DNS나, 서비스 디스커버리 전용 솔루션인 Hashicorp사의 Consul 또는 쿠버네티스를 통해서, 모니터링해야할 타겟 서비스의 목록을 가지고 올 수 있다.

4.4 Exporter

• 모니터링 에이전트로 타겟 시스템에서 메트릭을 읽어서, 프로메테우스가 Pulling 할 수 있도록 한다. 또한, 단순히 HTTP GET으로 메트릭을 텍스트 형태로 프로메테우스에 리턴한다. 요청 당시의 데이타를 리턴하는 것일뿐, Exporter 자체는 기존값(히스토리)를 저장하는 등의 기능은 없다.

4.5 Retrieval

• 서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오고, Exporter로 부터 주기적으로 그 대상으로 부터 메트릭을 수집하는 모듈이다.

4.6 저장

• 이렇게 수집된 정보는 프로메테우스 내의 메모리와 로컬 디스크에 저장된다. 별도의 데이터베이스 등을 사용하지 않고, 그냥 로컬 디스크에 저장하는데, 그로 인해서 설치가 매우 쉽다는 장점이 있지만 반대로 스케일링이 불가능하다는 단점을 가지고 있다. 대상 시스템이 늘어날 수록 메트릭 저장 공간이 많이 필요한데, 단순히 디스크를 늘리는 방법 밖에 없다.
• 프로메테우스는 구조상 HA를 위한 이중화나 클러스터링등이 불가능하다. (클러스터링 대신 샤딩을 사용한다. HA는 복제가 아니라 프로메테우스를 두개를 띄워서 같은 타겟을 동시에 같이 저장 하는 방법을 사용한다. 이 문제에 대한 해결 방법은 Thanos 라는 오픈 소스를 사용하면 된다고 한다.)

4.7 서빙

• 이렇게 저장된 메트릭은 PromQL 쿼리 언어를 이용해서 조회가 가능하고, 이를 외부 API나 프로메테우스 웹콘솔을 이용해서 서빙이 가능하다. 또한 그라파나등과 통합하여 대쉬보드등을 구성하는 것이 가능하다.

5. 장/단점

장점
1. pull 방식의 구조를 채택함으로써, 모든 메트릭의 정보를 중앙 서버로 보내지 않아도 된다.
2. Kubernetes 환경에서 설치가 쉽고, grafana와의 연동을 통한 운영이 쉽다.
3. Linux, Window등의 OS metric 뿐 아니라 각종 Third-party의 다양한 exporter를 제공한다.
4. 데이터 저장소가 시계열 데이터 저장소로 구성되어있어, 많은 양의 정보를 빠르게 검색 가능하다.
5. 구조가 복잡하지 않고 간단하기 때문에 특정 솔루션에 대한 export가 어렵지 않다.
6. 모든 데이터를 수집하지 않고 일정 주기(기본 값: 15초)로 메트릭을 수집하기 때문에 애플리케이션에 무리가 없다.

 

단점
1. 클러스터링이 불가능하다. 프로메테우스를 여러대 구성하려면 아래 그림처럼 Hierarchy 구조를 구성하여 사용해야한다.
2. 모든 메트릭을 수집하지 않기 때문에 사실상 "추리"를 보는데에는 좋지만 APM(Application Performance Monitoring)과 같이 모든 로그를 추적하기에는 적합하지 않다. Pullling 하는 순간의 스냅샷 정보만 알 수 있다.
3. 싱글 호스트 아키텍처이기 때문에 저장용량이 부족하면 디스크 용량을 늘리는 방법밖에 없다.
4. Prometheus server가 다운되거나, 설정 변경 등을 위해 재시작할 경우 메트릭이 일정시간동안 유실된다.

 

각 Region에 프로메테우스를 배치 한 뒤, 이를 Master에 Aggregate하는 방식이 프로메테우스가 공식적으로 권장하는 다중화 방식으로 Clustering과는 거리가 멀다.

 

참고 사이트

https://owin2828.github.io/devlog/2020/03/13/etc-5.html

https://velog.io/@ckstn0777/prometheus%ED%94%84%EB%A1%9C%EB%A9%94%ED%85%8C%EC%9A%B0%EC%8A%A4%EB%9E%80

https://yjkim97.tistory.com/50