Prometheus 기능 개요
1. 메트릭 수집
1-1. Metric 수집
수집하려는 대상 서버에 Exporter를 설치하여, Prometheus 중앙 서버에서 메트릭을 수집한다. 데이터 수집은 Pulling 방식으로 이루어지며, 수집하려는 데이터에 따라 여러 Exporter가 서드파티앱으로 존재한다.
MySQL exporter
- https://github.com/prometheus/mysqld_exporter/tree/release-0.13
- MySQL ≥ 5.6, MariaDB ≥10.2
1-2. Pull 방식의 데이터 수집
풀링 방식이란, 중앙 서버가 수집 대상 서버에서 데이터를 긁어가는 것을 뜻한다.
풀링 방식에선 중앙 서버가 수집할 서버들의 목록을 관리해야하는데, Prometheus에서는 이를 위해 Service Discovery 기능을 가지고 있다.
서비스 디스커버리 방식: 특정 시스템이 현재 기동중인 서비스들의 목록과 IP 주소를 가지고 있는 방식. 예를 들어 앞에서 VM들을 내부 DNS에 등록해놓고 새로운 VM이 생성될때에도 DNS에 등록을 하도록 하면, DNS에서 현재 기동중인 VM 목록을 얻어와서 그 목록의 IP들로 풀링을 하면 되는 구조
1-3. Service Discovery
프로메테우스도 서비스 디스커버리 시스템과 통합을 하도록 되어 있다. 앞에서 언급한 DNS나, 서비스 디스커버리 전용 솔루션인 Hashicorp사의 Consul 또는 쿠버네티스를 통해서, 모니터링해야할 타겟 서비스의 목록을 가지고 올 수 있다.
1-4. Exporter
Exporter는 모니터링 에이전트로 타겟 시스템에서 메트릭을 읽어서, 프로메테우스가 풀링을 할 수 있도록 한다. 또한, 단순히 HTTP GET으로 메트릭을 텍스트 형태로 프로메테우스에 리턴한다. 요청 당시의 데이타를 리턴하는 것일뿐, Exporter 자체는 기존값(히스토리)를 저장하는 등의 기능은 없다.
1-5. Retrieval
서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오고, Exporter로 부터 주기적으로 그 대상으로 부터 메트릭을 수집하는 모듈이 프로메테우스내의 Retrieval 이라는 컴포넌트이다.
2. 저장
수집된 정보는 프로메테우스 내의 메모리와 로컬 디스크에 저장된다. 뒷단에 별도의 데이타 베이스등을 사용하지 않고, 그냥 로컬 디스크에 저장하는데, 그로 인해서 설치가 매우 쉽다는 장점이 있지만 반대로 스케일링이 불가능하다는 단점을 가지고 있다. 대상 시스템이 늘어날 수록 메트릭 저장 공간이 많이 필요한데, 단순히 디스크를 늘리는 방법 밖에 없다.
프로메테우스는 구조상 HA를 위한 이중화나 클러스터링등이 불가능하다. (클러스터링 대신 샤딩을 사용한다. HA는 복제가 아니라 프로메테우스를 두개를 띄워서 같은 타겟을 동시에 같이 저장 하는 방법을 사용한다. 이 문제에 대한 해결 방법은 Thanos 라는 오픈 소스를 사용하면 된다고 한다.)
3. 서빙
이렇게 저장된 메트릭은 PromQL 쿼리언어를 이용해서 조회가 가능하고, 이를 외부 API나 프로메테우스 웹콘솔을 이용해서 서빙이 가능하다. 또한 그라파나등과 통합하여 대쉬보드등을 구성하는 것이 가능하다
참조블로그
https://owin2828.github.io/devlog/2020/03/13/etc-5.html
https://bcho.tistory.com/1372?category=731548
Prometheus의 단점
싱글 호스트 구조의 문제
Prometheus는 데이터 백엔드와 저장소가 결합된 싱글 호스트 아키텍처다.
HA 구성을 위한 개발은 개발사(사운드클라우드, Cloud Native Computing Foundation)에서 진행되고 있지 않으며 써드 파티앱을 통해 구성해야한다.
수집된 데이터는 근사치에 불과하다
풀링 주기를 기반으로 메트릭을 수집하기에, 수집된 데이터는 풀링하는 순간의 스냅샷이다. 풀링이 수행되지 않는 시점에 메모리 사용률이 한번 튀었더라도 해당 상황을 잡아내지는 못한다.
Prometheus를 선택한 이유
1. 라이센스에서의 자유로움
Prometheus는 Apache v2.0 라이센스를 따르고 있으며, 내가 사용할 써드파티앱 역시 Apache v2.0 라이센스를 따르고 있다. Prometheus의 대체제로 고려했던 Telegraf의 경우 MIT License라 내가 개발할 서비스용도로 어려움이 없지만 Telegraf와 결합되어야 할 InfluxDB의 라이센스 이슈가 있다.
라이센스 정보
Prometheus: Apache v2.0
Thanos: Apache v2.0
Grafana: AGPLv3 -> 사용못함
2. 수집 대상의 유연성
Prometheus는 Pulling 방식이기에, Data-Backend에서 어떤 메트릭이든지 수집할 수 있도록 구현됐다. 그에 따라, 추후 새로운 Application에 대한 모니터링 수요가 발생하더라도, 해당 앱에 대한 써드파티 Exporter만 설치해주면 모니터링이 가능하다.
현재 진행중인 프로젝트에서는 mysql exporter만을 사용할 예정이지만 추후 다른 서비스들도 수용이 가능할 것으로 보인다.
3. 커뮤니티의 규모
Prometheus는 Github기준 42k Star이며, 이에 따른 방대한 커뮤니티가 존재한다. Telegraf는 현재 11k로 Prometheus보다 빈약하다.
3. Spring에서의 모듈 지원을 통해 Java Application 모니터링 가능
Spring Boot는 어플리케이션을 모니터링하고 관리할 수 있는 HTTP 엔드포인트를 제공하는 Actuator라는 라이브러리를 지원한다.
또한, 데이터를 Prometheus에서 사용되는 Metric 형태로 제공하는 Spring Metrics 라이브러리를 지원한다.
소속팀의 주요 기술스택이 Spring이므로, 추후 개발되는 Micro Service들에 대해서도 모니터링할 수 있을 것으로 보인다. (물론 각 담당자들이 본인 MS에서 개발을 해줘야한다..)
Spring Metrics
https://docs.spring.io/spring-metrics/docs/current/public/prometheus
Metrics - Spring Boot Docs
https://docs.spring.io/spring-boot/docs/2.1.9.RELEASE/reference/html/production-ready-metrics.html
Histograms and percentiles - Micrometer Concepts
https://micrometer.io/docs/concepts#_histograms_and_percentiles
Micrometer: Spring Boot 2’s new application metrics collector
https://spring.io/blog/2018/03/16/micrometer-spring-boot-2-s-new-application-metrics-collector
