[Prometheus] Prometheus란?

Prometheus

Prometheus는 메트릭 기반의 오픈소스 모니터링 시스템으로, SoundCloud사에서 만들었다. 2016년 부터 CNCF 프로젝트로 등록되었으며, 두 번째로 졸업한 CNCF 프로젝트입니다. Prometheus는 많은 관심을 받고있는 모니터링 시스템중 하나로, Kubernetes에서도 Prometheus를 사용하여 모니터링을 환경을 구축하는 것을 권장하고 있습니다.

 

Prometheus 기능

Prometheus 공식 사이트에서 설명하는 Prometheus의 기능들입니다. 

• 차원 데이터(Dimensional data)
  • 고차원 데이터 모델을 구현하기 위해 수집한 메트릭을 키-값(JSON) 형식의 시계열 데이터로 저장합니다.
• 강력한 쿼리
  
  • Prometheus 전용 쿼리 언어인 PromQL이라는 언어를 사용해 모든 종류의 집계, 분석, 연산을 할 수 있는 기능을 제공합니다.
• 뛰어난 시각화
  • Prometheus는 Grafana와 연동하여 데이터를 시각화할 수 있습니다.
• 효율적인 보관(?)
  • Prometheus는 TSDB(Time-series Database)라는 로컬 디스크에 수집된 메트릭을 저장합니다.
  • 로컬 디스크이기 때문에 스케일링이 불가능합니다.  따라서 시스템이 늘어나면 디스크를 직접 늘려야하는데 이때 샤딩(Sharding)을 사용합니다.
• 간단한 조작
  • 하나의 바이너리 파일로 동작하기 때문에 로컬 디스크만 있으면 되고 설치가 간편합니다.
  • 구조가 복잡하지 않고 간단하기 때문에 특정 솔루션에 대한 Export가 쉽습니다.
• 정확한 알림
  • Alertmanager를 통해 Prometheus에서 문제가 발생한 시점에 Slack, mail 등을 통해 알람을 보낼 수 있습니다.
• 많은 클라이언트 라이브러리
  • Go, Java, Scala, Python, Ruby, Rust 등등 다양한 클라이언트 라이브러리를 지원합니다.
  • Bash, C, C++, Dart, Node.js 등등 다양한 서드 파티 클라이언트 라이브러리도 지원합니다.
• 많은 통합
  • Docker, HAProxy, StatsD, JMX 등 다양한 서비스의 메트릭을 Protmetheus를 통해 수집할 수 있습니다.

 

Prometheus 아키텍처

Prometheus가 메트릭을 수집하는 방법은 push가 아니라 pull 방식입니다. 클라이언트(Job/exporter)가 Prometheus 서버로 메트릭을 전송하는 것이 아니라 Proemetheus 서버에서 주기적으로 클라이언트에 접속해서 메트릭을 수집합니다.

• Service Discovery
  
  • Prometheus가 메트릭을 수집할 대상을 동적으로 설정하는 것을 가능하게 해줍니다.
  • 이를 통해 오토 스케일링 되는 EC2 인스턴스나 Kubernetes Pod로부터 메트릭 수집이 가능합니다.
• Jobs/exporters
  
  • exporter는 Prometheus가 pull 방식으로 데이터를 수집할 수 있도록 메트릭을 노출하는 Agent입니다.
  • exporter는 서버들로부터 메트릭을 수집해 metrics HTTP endpoint를 제공합니다. /metrics 경로에는 Prometheus가 수집할 수 있는 메트릭에 대한 정보들이 있습니다.
  • Prometheus는 exporter의 metrics HTTP endpoint로 GET 요청을 보내 메트릭을 수집하는 것입니다.
• Pushgateway
  • Prometheus가 exporter의 metrics HTTP endpoint에 접근이 안되는 곳은 pull 방식의 수집이 불가능 합니다. (ex Batch Job)
  • 이 경우에 Pushgateway를 사용해 어플리케이션 단에서 Pushgateway로 메트릭을 push하고, Prometheus는 Pushgateway에 접근해 쌓인 메트릭을 pull 하는 방식으로 메트릭을 수집합니다.
• Prometheus Server
  • Prometheus의 메인 서버로, 메트릭 데이터를 수집하고 저장합니다.
  • Retrieval
    • Service Discovery로 부터 모니터링 대상 목록을 받아오고, exporter로부터 주기적으로 메트릭을 수집합니다.
  • TSDB(Time-series Database)
    • 수집된 메트릭은 TSDB라는 Prometheus 내의 로컬 디스크에 저장됩니다.
    • 로컬 디스크라 설치는 빠르지만 스케일링이 불가능합니다.
    • 샤딩을 통해 디스크를 직접 늘릴 수 있습니다.
  • HTTP Server
    • Prometheus에 저장된 데이터를 조회하기 위한 서버입니다.
    • Promethus는 REST API로 데이터를 제공하고, 해당 API를 가지고 Prometheus web UI에서 데이터를 조회하거나, Grafana에서 Prometheus 메트릭을 가져와 시각화할 수 있습니다.
• Alertmanager 
  • Prometheus에서 문제가 발생한 시점에 Slack, mail등을 통해 알람을 보냅니다.
  • Rule file을 작성해 조건(expr)이 일정 기간(for)이상 발생한 경우 알람을 발생시킵니다.
• PromQL
  
  • TSDB에 있는 데이터를 쿼리하기 위해 자체 개발한 PromQL이라는 쿼리 언어를 사용합니다.
  • TSDB(Time-series Database)이기 때문에 모든 쿼리는 Select문을 전제로 하며, CRUD를 기본 원칙으로 합니다.

 

Prometheus 장/단점

장점

1. 메트릭을 키-값(JSON) 형식의 시계열 데이터로 저장하여 다차원 데이터 모델을 구현할 수 있다.
2. 다차원 데이터 모델을 활용할 수 있는 전용 쿼리 언어(PromQL)를 지원한다.
3. 일반적으로 pull 방식으로 데이터를 수집한다. (push 방식도 가능하다.)
   
   • Prometheus 서버에 장애가 생겨도 어플리케이션에는 전혀 영향이 없다.
4. 데이터베이스나 캐시와 같은 다른 솔루션과의 종속성이 거의 없다.
   • 하나의 바이너리 파일로 동작하기 때문에 로컬 디스크만 있으면 된다.
   • 다른 솔루션에 대한 Export가 쉽다.
5. 시계열 데이터베이스를 사용하여, 많은 양의 데이터를 빠르게 검색할 수 있다.

 

단점

1. 메트릭을 일정 주기마다 수집하기 때문에 모든 메트릭을 수집할 수 없다.
   • 대략적인 메트릭을 추측하는데에는 좋지만, APM(Application Perfomence Monitoring)과 같이 발생한 모든 로그를 추적하기에는 적합하지 않다.
   • Prometheus가 Pull하는 순간의 스냅샷 정보만 알 수 있다.
2. 로컬 디스크를 사용하기 때문에 용량이 부족할 경우 직접 디스크를 늘려야 한다.
3. 클러스터링이 불가능하다. 
   • 아래와 같이 Region마다 Slave를 배치한 뒤 이를 Master에서 Aggreagte 하는 Hierarchical Federation 방식이 Prometheus에서 권장하는 공식적인 다중화 방식이다.

 

참고

• https://prometheus.io/
• https://gurumee92.tistory.com/220
• https://cumulus.tistory.com/86
• https://medium.com/finda-tech/prometheus%EB%9E%80-cf52c9a8785f
• https://yjkim97.tistory.com/50
• https://grepper.tistory.com/67
• https://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221535575875