revenge1005 🧗

[Monitoring] 01. 프로메테우스(Prometheus)?

Date:     Updated:

카테고리:

태그:


01. 프로메테우스란?

프로메테우스(Prometheus)는 SoundCloud사에서 만든 오픈소스 시스템 모니터링 및 경고 툴킷으로 2016년에 쿠버네티스를 잇는 두번째 호스팅 프로젝트로 Cloud Native Computing Foundation(CCNF)에 합류했다.

설정된 작업(job)에 대로 매트릭(metrics) 정보를 모니터링 대상 시스템에 설치된 익스포터(Exporter) 혹은 푸시 게이트웨이(Push Gateway)를 통해 수집한다.

수집된 모든 정보를 로컬에 저장하고, 규칙(rule)을 수행하여 시계열 형태의 데이터(TSDB: Time Series Database)로 수집하고 특정 조건에 설정된 경고(Alert) 등을 발생한다.


■ 프로메테우스의 특징

eqweqw

1) 메트릭 이름 및 키/값 쌍으로 식별되는 다차원 데이터 모델을 시계열로 저장

2) 다차원 모델을 다각도로 활용하는 유연한 쿼리 언어인 PromQL. 이를 통해 성능 분석이 가능.

3) 다양한 그래프 및 대시보드 지원(with Grafana)

4) alertmanager를 통한 알림 생성 발생

5) 애플리케이션 코드 계측을 위한 클라이언트 라이브러리

6) 분산 스토리지나 다른 원격 서비스에 의존하지 않고 모든 서버 노드가 자율적으로 동작

7) HTTP를 통한 pull 모델로 시계열 수집 (push 방식도 가능)

  • Pull 방식은 프로메테우스 서버가 주기적으로 모니터링 대상 시스템으로부터 데이터를 가져오는 방식

  • Push 방식은 모니터링 대상 시스템이 주기적으로 프로메테우스 서버로 데이터를 전송(push)하는 방식

8) custom format을 통해 효율적인 데이터 저장

9) 서비스 디스커버리나 스태틱 설정을 통한 모니터링 대상 타겟팅


■ 메트릭(Metric)?

메트릭(Metric)은 타임스탬프와 한 두가지 숫자값을 포함하는 이벤트로 프로메테우스는 근본적으로 모든 데이터를 시계열로 저장하고, 이는 고유한 메트릭명과 옵셔널하게 들어갈 수 있는 key-value 쌍의 라벨로 구분될 수 있다.

다운로드

메트릭은 매 순간 수집되는 것이 아닌 일정 텀을 두고 수집되며, 이렇게 수집된 데이터가 시간순서로 점차 쌓이기 때문에 프로메테우스를 통해 어떠한 이벤트의 추이를 파악하기가 좋다.

하지만 항상 데이터 수집의 성공을 보장할 수 없기 때문에 약간의 부정확성과 레이스 컨디션이 따르며 따라서 100%의 정확성이 요구되는 사항에는 적합하지 않을 수 있다.

시계열 데이터? 일정한 시간동안 수집된 일련의 순차적으로 정해진 데이터 셋의 집합으로 시계열 데이터의 특징으로는 시간에 관해 순서가 매겨져 있다는 점이다.
시계열 데이터의 분석 목적은 시계열이 갖고 있는 법칙성을 발견해 이를 "모형화"하고 추정된 모형을 통해 미래의 값을 forecasting 하는 것이다.


■ 기본 구조

architecture


▶ Jobs/exporters

exporters는 말 그대로 데이터를 밖으로 전달하는역할을 하는 컴포넌트이며 프로메테우스가 Pull 방식으로 데이터를 수집할 수 있도록 메트릭을 노출하는 agent이다. 프로메테우스는 이러한 exporter가 제공하는 endpoint로 GET요청을 날려 형식화된 메트릭 데이터를 수집하고 저장한다.


▶ Push-gateway

프로메테우스는 Pull방식을 통해 데이터를 수집하지만 배치잡과 같은 작업은 실시간으로 정보를 요청해서 받아오는 것이 불가능하다. 따라서 이에 대한 대안으로 어플리케이션은 Push-gateway로 메트릭을 Push하고 프로메테우스는 이 Push-gateway에 접근하여 쌓여있는 메트릭을 Pull하는 방식으로 데이터를 얻을 수 있다.


▶ Retrieval

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


▶ Service Discovery

메트릭을 수집할 대상을 동적으로 설정하는 것을 가능케 하는 것으로, 프로메테우스는 기본적으로 모니터링 대상 목록을 유지하고 있다.


▶ Prometheus server

프로메테우스의 메인 서버로 HTTP를 이용하거나 메모리 버퍼에서 메트릭 데이터를 수집하고 저장한다. Prometheus server 내부에는 Retrieval, TSDB, HTTP server 모듈이 있다.


▶ TSDB(Time-series Database)

수집된 메트릭을 저장하는 역할로 수집된 메트릭은 프로메테우스 서버의 메모리와 (default) 로컬 디스크에 저장되며 (필요에 따라 원격 서버에 데이터를 저장할 수 있다.) 최초 프로메테우스를 설계할 때에는 Scale out을 고려하지 않았기 때문에 모니터링할 데이터가 많아질 수록 장비를 업그레이드 해주어야 하는 문제가 있었다.

프로메테우스는 구조상 고가용성을 위한 이중화나 클러스터링이 불가능하다. (클러스터링 대신 샤딩을 사용) 고가용성을 위해 복제가 아닌 프로메테우스를 두개를 띄워 같은 타겟을 동시에 같이 저장하는 방법을 사용한다. (Thanos라는 오픈소스 사용)


▶ HTTP Server

프로메테우스에 저장된 데이터를 조회하기 위해서 필요한 서버, 프로메테우스는 데이터를 가져가기 위한 프로토콜로 HTTP REST API를 제공하고, 직접 API를 통해 데이터를 가져가든지, Web UI 대시보드에서 데이터를 조회하는 방법으로 그라파나를 통해 데이터를 시각화할 수 있다.


▶ AlertManager

수집된 메트릭을 기반으로 임계치를 넘는 시점에 slack, mail등을 통해 알람을 보내주는 컴포넌트이며, 이는 Rule을 작성하여 정할 수 있다.


▶ PromQL & Data Visualizion

TSDB에 저장된 메트릭을 PromQL을 통해 조회하고 이를 외부 API나 프로메테우스 웹콘솔을 통해 시각화가 가능하다. 프로메테우스와 함께 많이 언급되는 Grafana등과 통합하여 시각화 하는것도 가능하다.


■ 기본 동작

  1. Service Discovery의 정보를 Retrieval에게 전달

  2. Retrieval이 모니터링 대상을 Service Discovery에게 전달받아, 타겟에 접근하여 메트릭을 수집

  3. exporters는 모니터링 대상에 설치되며, 본인 Metric을 수집하고 Retrieval이 수집해 갈 수 있도록 엔트포인트를 제공

    • exporter가 /metrics 라는 HTTP 엔드포인트를 본인쪽에서 제공

    • 서버(Retrieval)가 GET 요청을 모니터링 대상의 엔드포인트로 날려 정보를 가져오는(Pull) 형식

  4. Retrieval가 수집한 타겟의 Metric들을 TSDB가 저장 후에 시각화

  5. 시각화한 데이터를 보여주기 위해, Prometheus 내부 HTTP Server가 별도의 HTTP REST API를 제공


■ When does Prometheus fit ?

  1. 시계열로 수집할 수 있는 순수한 숫자 데이터를 기록하는 일에 적합

  2. 장비 관련 모니터링과 매우 동적인 서비스 지향 아키텍처 모니터링에 적합

  3. 마이크로 서비스 환경에서 다차원 데이터 수집과 질의를 지원하는 것히 특히 강점

    • 프로메테우스는 클라우드 네이티브 환경이나 컨테이너 오케스트레이션 플랫폼(대표적으로 Kubernetes, Docker, OpenShift 등)에서 많이 사용된다.

  4. 가동 중단 시 문제를 신속하게 진단할 수 있는 시스템이 될 수 있도록, 신뢰도를 중심으로 설계됨

  5. 각 Prometheus 서버는 네트워크 스토리지나 다른 원격 서비스에 의존하지 않는 독립형 서버다.

  6. 인프라에 있는 다른 서버에 문제가 있을 땐 프로메테우스 서버를 신뢰하고 활용할 수 있으며, 프로메테우스를 위해 대규모 인프라를 세팅하지 않아도 된다.


■ When does Prometheus not fit ?

  1. 100% 정확해야 하는 데이터(클라우드 서비스 요청당 요금 청구와 같은)를 수집해야 할 때 권장하지 않는다.

  2. 프로메테우스는 신뢰도를 중요한 가치로 여기며, 시스템에 오류가 있더라도 가능한 통계들은 항상 조회할 수 있다.

  3. 하지만 프로메테우스 수집하는 데이터에 상세 정보를 모두 담기는 힘들고 완전하지 않을 수 있기 때문에 정확해야 하는 데이터에는 이용하기 어렵다.


■ 프로메테우스의 장/단점


▶ 장점

  1. Pull 방식의 구조를 채택함으로써, 모든 매트릭의 정보를 중앙 서버로 보내지 않아도 된다.

    • 대부분의 모니터링 구조는 Push인데, 각 타겟 서버에서 부하가 결릴 경우 Push 방식은 Fail Point가 될 가능성이 있다.

  2. Kubernetes 환경에서 설치가 간단하고, Grafana와 연동을 통한 운영이 쉽다.

  3. 다양한 “Metric Exporter” 제공

    • Linux, Window 등의 OS 매트릭 뿐 아니라 각종 Thrid party의 exporter를 제공한다.

  4. 장기간 데이터 유지와 확인

    • 데이터 저장소가 시계열 데이터 저장소로 구성되어 있어 많은 양의 정보를 빠르게 검색 가능하다.


▶ 단점

etc_5_3

  1. 각 Region에 프로메테우스를 배치한 뒤, 이를 Master에 Aggregate(집계)하는 방식이 프로메테우스가 공식적으로 권장하는 다중화 방식으로 즉, 자체적으로는 클러스터를 구성할 수 없고 외부 도구(Thanos 등..) 또는 Kubernetes와 같은 오케스트레이션 플랫폼을 이용해야 한다.

  2. 싱글 호스트 아키텍처이기 때문에 저장용량이 부족하면 디스크 용량을 늘리는 것 밖에 방법이 없다.

  3. 프로메테우스 서버가 다운되거나, 설정 변경 등을 위해서 재시작을 할 경우 그간의 metric은 유실된다.

  4. 일정 풀링 주기를 기반으로 metric을 가져오기 때문에 풀링하는 순간의 스냅샷 정보만 알 수 있다.(스냅샷의 연속된 모음이기 때문에 근사값의 형태)


■ 참고

  • https://prometheus.io/docs/introduction/overview/

  • https://joon2974.tistory.com/29

  • https://nice-engineer.tistory.com/entry/Prometheus%EB%9E%80

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

MONITORING 카테고리 내 다른 글 보러가기

댓글 남기기

최근 글 10 개 :)