Prometheus
- Prometheus는 오픈 소스 기반의 모니터링 시스템이다.
- kubernetes에서도 Prometheus를 사용하여 매트릭 수집 및 대시보드 구축하는 방식을 장려한다.
- 다른 모니터링 도구와 가장 다른 점은 대부분의 모니터링 도구는 Push 방식(각 서버에 클라이언트를 설치하고 이 클라이언트가 메트릭 데이터를 수집하여 서버로 보내면, 서버가 모니터링 상태를 보여주는 방식)이다.
- Prometheus는 Pull 방식(서버가 각 클라이언트를 알고 있어야 하는것이 아니라 서버에 클라이언트가 떠 있으면 서버가 주기적으로 클라이언트에 접속하여 데이터를 가져오는 방식)이다.
- Prometheus 구조가 간단하여 운영하기 쉽고, 강력한 쿼리 기능을 가지고 있으며, 그라파나(Grafana)를 통한 시각화 Dashboard를 지원한다.
- 넓은 오픈 소스 생태계를 기반하여 많은 시스템을 모니터링할 수 있는 다양한 플러그인을 가지고 있으며, 이런 간편함 덕분에 kubernetes의 메인 모니터링 시스템으로 많이 사용된다.
Prometheus 구조
- 위 그림은 Prometheus의 아키텍처이다. 기본적으로 Metric 데이터를 Pull하여 TSDB라는 저장소 혹은 디스크에 저장한 후 해당 정보를 알람이나 모니터링 툴과 연결되는 구조이다.
- 주요 기능은 아래와 같다.
Jobs/Exporters
- 모니터링 대상의 Metric 데이터를 수집하는 컴포넌트이며, Prometheus가 접속했을 때 Pull 방식으로 데이터를 수집할 수 있도록 메트릭 정보를 노출시켜주는 agent 이다.
- Exporter를 실행하면 데이터를 수집하는 동시에 HTTP Endpoint(default Port 9100)를 열어서 Prometheus에 노출하여 Prometheus Server가 이 Exporter의 Endpoint로 HTTP GET 요청을 날려 메트릭 정보를 수집(Pull)해 간다.
- 즉, 웹 브라우저 등에서 해당 HTTP Endpoint에 접속하면 Metric의 내용을 확인할 수 있다.
- 호스트 서버의 CPU, Memory등을 수집하는 node-exporter이 있으며, nginx의 데이터를 수집하는 nginx-exporter도 존재한다.( Consul exporter, MySQL server exporter, RabbitMQ exporter, HAProxy exporter, Docker Hub exporter, AWS CloudWatch exporter 등 다양한 Exporter를 지원 )
- Exporter는 데이터를 가져오고 싶은 시스템(인스턴스)에 설치해야한다.
Prometheus Server
- 시계열 데이터를 생성하고 저장하는 핵심 서비스이다.
- Exporter가 열어놓은 HTTP Endpoint에 접속하여 Metric을 수집한다.
- 그렇기 때문에, Pull 방식이다.
Retrieval
- Service Discovery로 부터 모니터링 대상을 받아오고 Exporter로부터 주기적으로 그 대상의 메트릭을 수집하는 모듈이다.
TSDB
- Time-series Database의 약어, 수집된 메트릭을 저장하는 역할을 한다.
- 시계열 데이터를 저장하는 자체 스토리지 엔진이며, 외부에 DB를 두고 사용하는 것이 아니라면 Prometheus는 로컬에 데이터를 저장한다.
- Prometheus Server의 Momory, Disk에 저장되며 최초 Prometheus를 설계할 때에는 Scale out을 고려하지 않았기 때문에, 모니터링할 데이터가 많을 수록 장비를 업그레이드 해주어야 하는 문제가 있는데, 최근 클러스터링을 지원하는 Thanos등의 오픈 소스를 사용하면 해결 가능하다.
HTTP Server
PushGateway
- 기본적으로 Prometheus는 Pull 방식을 통해 데이터를 수집하지만 배치잡과 같은 작업은 실시간으로 정보를 요청하여 받아오는 것이 불가능하다.
- 따라서 이에 대한 대안으로 애플리케이션은 Pushgateway로 메트릭을 Push하고 Prometheus는 이 Pushgateway에 접근하여 쌓여있는 메트릭을 Pull하는 방식으로 데이터를 얻을 수 있게 하는 중재자 역할을 수행한다.
Service Discovery
- Prometheus가 메트릭을 수집할 대상을 동적으로 설정하는 것을 가능하게 한다.
- Micro Service Architecture와 같은 분산 환경에서 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치를 알아내는 기능을 한다.
- 인스턴스가 auto Scaling이 될 수 있기 때문에 이 모든 인스턴스들을 Service Discovery를 통해 추적해 메트릭을 수집 가능케 한다.
PromQL & Visualization (Grafana)
- TSDB에 저장된 메트릭을 PromQL을 통해 조회하고 이를 외부 API나 Prometheus 자체적 웹 콘솔(Visualization)을 통해 시각화가 가능하다.(Prometheus의 자체적 대시보드는 시각화 기능이 약해 Grafana의 대시보드를 사용한다.)
- Grafana는 Prometheus Server에 Grafana를 연동하여 대시보드를 통해 시각화한다.
Alert Manager
- 알림을 받을 Rule을 만들어 Alert Manager에 보내면 Alert Manager가 규칙에 따라 수집된 메트릭을 기반으로 임계치를 넘는 시점에 Slack, Mail등을 통해 알림을 보내주는 컴포넌트이다.
장단점
장점
- Pull 방식의 구조를 채택하여 모든 메트릭 정보를 중앙 서버로 보내지 않아도 된다.
- 다양한 써드파티 프로그램과 연동을 통해 운영이 쉽다.
- 구조가 복잡하지 않고 간단한다.
- 모든 데이터를 수집하지 않고 일정 주기로 메트릭을 수집해 애플리케이션에 무리가 없다.
단점
- 클러스터링이 불가능하다.
- 스케일을 키우고 싶으면 Prometheus를 여러개 구축하여 계층형으로 연결해야 한다.
- 모든 데이터를 수집하지 않아 대략적인 데이터 흐름을 보기엔 좋지만 모든 데이터를 필요로하는 목적에는 부적합하다.
- APM(Application Performance Monitoring)같이 모든 로그를 추적해야하는 상황에는 좋지 않음(다양한 open source tool과 함께 사용해야한다. (ex, jaeger, ELK etc))
- Pulling하는 그 순간의 스냅샷 정보만 알 수 있음
Metric
- 메트릭은 일반적으로 타임스탬프와 한 두가지 숫자값을 포함하는 이벤트로 볼 수 있다.
- 프로메테우스는 근본적으로 모든 데이터를 시계열로 저장하고, 이는 고유한 메트릭명과 옵셔널하게 들어갈 수 있는 key-value 쌍의 라벨로 구분될 수 있다.
메트릭명{라벨명=값, 라벨명=값} 샘플링 데이터
출처
https://blog.outsider.ne.kr/1254
