Prometheus는 SoundCloud 사에서 만들었다가 독립된 오픈소스 시스템 모니터링 및 경고 툴킷이다.
2016년에 쿠버네티스를 잇는 두번째 호스팅 프로젝트로 Cloud Native Computing Foundation(CCNF)에 합류했다.
✔️ Prometheus 기능
프로메테우스의 주요 기능들은 다음과 같다.
메트릭 이름 및키/값쌍으로 식별되는 다차원 데이터 모델을 시계열로 저장
다차원 모델을 다각도로 활용하는 유연한 쿼리 언어인PromQL. 이를 통해 성능 분석이 가능.
다양한 그래프 및대시보드지원(with Grafana)
alertmanager를 통한 알림 생성 발생
애플리케이션 코드 계측을 위한클라이언트 라이브러리
분산 스토리지나 다른 원격 서비스에 의존하지 않고 모든 서버 노드가 자율적으로 동작
HTTP를 통한 pull 모델로 시계열 수집(push 방식도 가능)
Pull 방식이란 서버가 주기적으로 클라이언트에 접속해 데이터를 가져오는 방식이다.
custom format을 통해 효율적인 데이터 저장
중간 게이트웨이를 통한 시계열 push 지원
서비스 디스커버리나 스태틱 설정을 통한 모니터링 대상 타겟팅
메트릭이란 ? 지표로 사용될 수 있는 데이터를 말한다. 프로메테우스의 메트릭은 "메트릭명 {필드1 = 값, 필드2 = 값} 샘플링데이터"와 같이 수집된다. https://dysong.tistory.com/15 시계열 데이터란 ? 일정한 시간동안 수집된 일련의 순차적으로 정해진 데이터 셋의 집합이다. 시계열 데이터의 특징으로는 시간에 관해 순서가 매겨져 있다는 점이다.
시계열 데이터의 분석 목적은 시계열이 갖고 있는 법칙성을 발견해 이를 "모형화"하고 추정된 모형을 통해 미래의 값을 forecasting 하는 것이다.
시계열 자료의 종류로는
POS (Points of Sales) 구매 자료 (불규칙적인 시차)
일일 코스피 주식 가격
월별/분기별/연도별 특정 사건의 수치 (규칙적인 시차) 등 일어난 사건의 데이터 값을 모은 데이터 셋이다.
✔️ Prometheus 아키텍처
Jobs/exporters 는 실제로 매트릭 수집하는 프로세스라고 보면 된다.
이 exporter가 매트릭을 수집하고 HTTP 통신을 통해 매트릭 데이터를 가져갈 수 있게 /metrics 라는 HTTP 엔드포인트를 제공한다.
그러면 Prometheus server가 이 exporter의 엔드포인트로 HTTP GET 요청을 날려 매트릭 정보를 수집(Pull)한다.
수집한 정보를 Prometheus가 제공하는 간단한 웹 뷰를 통해 조회할 수 있고 그 안에서 테이블 및 그래프 형태로 볼 수 있다.
하지만 시각화 도구가 부족해서 이를 직접 사용하지는 않고 대게 Grafana라는 데이터 시각화 툴을 이용해 시각화한다.
용어 설명
Service Discovery:데이터 수집 대상을 발견. 프로메테우스는 기본적으로 모니터링 대상 목록을 유지하고 있다.
Pushgateway: Prometheus가 exporter를 통한 HTTP endpoint에 접근할 수 없는 곳에서는 Pull 방식을 사용할 수 없으므로 application이 pushgateway 에 메트릭을 push한 후, prometheus server 가 pushgateway 에 접근해 metric 을 pull 해서 오는 방식으로 동작한다.
Retrieval :서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오고, Exporter로 부터 주기적으로 그 대상으로 부터메트릭을 수집하는 모듈이다.
Jobs/Exporter: Exporter는 프로메테우스에게 메트릭을 가져가도록 특정 서비스에 metric을 노출하게 하는 agent라고 이해하면 편하다(메트릭을 가져오기 힘든경우 사용). 우리가 모니터링 할 서버에 Exporter가 설치되어 있어야 하며 Node exporter,SQL Exporter등 다양한 커스텀 exporter 이 개발되어 사용되고 있다. 이러한 Exporter를 사용하여 metric을 Prometheus에 긁어가도록 할 수 있다.
데이터 수집: 이제 프로메테우스 서버가 익스포터가 열어놓은 HTTP 엔드포인트에 접속해서 메트릭을 주기적으로 수집한다. 이렇게 메트릭을 가져오고 수집에 대한 구문 분석 후 저장 장치에 저장된다. (프로메테우스는pull 기반시스템!!)
Alert manager: PromQL로 실행된 모든 결과는 알림이고, 이 알림 중에서 특정 알림에 대해 규칙을 만들어서 이메일, 페이저듀티, 슬랙 등 기타 애플리케이션으로 전송되게 할 수 있다.
https://grepper.tistory.com/67
Prometheus server : 프로메테우스의 메인 서버로 HTTP를 이용하거나 메모리 버퍼에서 메트릭 데이터를 수집하고 저장한다. Prometheus server 내부에는 Retrieval, TSDB, HTTP server 모듈이 있다.
TSDB(Time-series Database) : 수집된 메트릭은 Prometheus server 내의 메모리와 (default) 로컬 디스크에 저장된다. (필요에 따라 원격 서버에 데이터를 저장할 수 있다.) 데이터베이스에 별도로 저장하지 않기 때문에 대상 시스템이 늘어날수록 디스크를 늘려야 한다. (스케일링 불가 !)
프로메테우스는 구조상 고가용성을 위한 이중화나 클러스터링이 불가능하다. (클러스터링 대신 샤딩을 사용) 고가용성을 위해 복제가 아닌 프로메테우스를 두개를 띄워 같은 타겟을 동시에 같이 저장하는 방법을 사용한다. (Thanos라는 오픈소스 사용)
HTTP Server : 프로메테우스에 저장된 데이터를 조회하기 위해서 필요한 서버이다. 프로메테우스는 데이터를 가져가기 위한 프로토콜로 HTTP REST API를 제공하고, 직접 API를 통해 데이터를 가져가든지, Web UI 대시보드에서 데이터를 조회하는 방법으로 그라파나를 통해 데이터를 시각화할 수 있다.
Data Visualizion : 프로메테우스의 Metric 데이터를 시각화 하는 툴을 제공하는 역할을 한다.
기본 동작 과정
1. Service Discovery의 정보를 Retrieval에게 전달 (yaml 확장자 파일에 모니터링 대상의 기동중인 서비스 목록, IP 정보)
2. Retrieval이 모니터링 대상을 Service Discovery에게 전달받아, 타겟에 접근하여 메트릭을 수집한다.
3. exporters는 모니터링 대상에 설치되며, 본인 Metric을 수집하고 Retrieval이 수집해 갈 수 있도록 엔트포인트를 제공
exporter가 /metrics 라는 HTTP 엔드포인트를 본인쪽에서 제공하고, 서버(Retrieval)가 GET 요청을 모니터링 대상의 엔드포인트로 날려 정보를 가져오는(Pull) 형식 - 웹 브라우저로 직접 접속해 해당 정보를 볼 수도 있다 - Metric
4. Retrieval가 수집한 타겟의 Metric들을 TSDB가 저장 후에 시각화 한다.
데이터를 저장하는 방법은 Local, Remote 두 가지 방법이 존재한다. 보통 Local 방식으로 저장하며 Google의 Level DB를 사용한다.
5. 시각화한 데이터를 보여주기 위해, Prometheus 내부 HTTP Server가 별도의 HTTP REST API를 제공한다.
서버나 치수를 추가하고 싶다면 ?
각 서버에 agent 파일을 실행 후 Prometheus를 재시작(Prometheus 내 prometheus.yml에 정보를 추가후 재가동)
재가동 후에는 제대로 올라왔는지 status의 Targets에서 확인
알림 기능
Grouping으로 해서 여러 알림을 하나의 알림으로 받을 수 있다.
Alert Manager를 통해 규칙을 설정하면 그 규칙에 따라 알람을 보낼 수 있다.
저장 방식
수집된 정보는 프로메테우스 내의 메모리와 로컬 디스크에 저장된다. 별도의 데이터베이스 등을 사용하지 않고, 그냥 로컬 디스크에 저장하는데 그로 인해서 설치가 매우 쉽다는 장점이 있으나 스케일링이 불가하다는 단점이 있다.
서빙 기능
저장된 메트릭은 PromQL 쿼리 언어를 이용해 조회가 가능하고 이를 외부 API나 프로메테우스 웹 콘솔을 이용해 서빙이 가능하다. 또한 그라파나 등과 통합해 대시보드를 구성하는 것이 가능하다.
✔️ When does Prometheusfit ?
프로메테우스는 시계열로 수집할 수 있는 순수한 숫자 데이터를 기록하는 일에 적합하다.
장비 관련 지표를 모니터링 하기 좋으며, 매우 동적인 서비스 지향 아키텍처 모니터링에도 적합하다.
마이크로 서비스 세계에서 다차원 데이터 수집과 질의를 지원 한다는 점에서 특별하다.
프로메테우스는 가동 중단 시 문제를 신속하게 진단할 수 있는 시스템이 될 수 있도록, 신뢰도를 중심으로 설계됐다.
프로메테우스 서버는 각각 네트워크 스토리지나 다른 원격 서비스에 의존하지 않는 독립형 서버다.
인프라에 있는 다른 서버에 문제가 있을 땐 프로메테우스 서버를 신뢰하고 활용할 수 있으며, 프로메테우스를 위해 대규모 인프라를 세팅하지 않아도 된다.
✔️ When doesPrometheus not fit ?
100% 정확해야 하는 데이터를 수집해야 할 때 권장하지 않는다.
프로메테우스는 신뢰도를 중요한 가치로 여긴다. 시스템에 오류가 있더라도 가능한 통계들은 항상 조회할 수 있다.
하지만 프로메테우스 수집하는 데이터에 상세 정보를 모두 담기는 힘들고 완전하지 않을 수 있기 때문에 요청 당 거래액 같이 100% 정확해야 하는 데이터에는 프로메테우스를 이용하기 어렵다.
✔️ Prometheus 권장 방식
https://cumulus.tistory.com/86
프로메테우스가 권장하는 다중화 방식 → 각 Region에 프로메테우스를 배치 한 뒤, 이를 Master에 Aggregate하는 방식
✔️ 프로메테우스를 쓰는 이유
Prometheus를 사용하는 가장 큰 이유는 아무래도 HTTP Pull 방식을 사용하는데 있는 것 같습니다.
어플리케이션의 Metrics를 Pull 방식을 통해서 가져온다는 것은 프로메테우스 같은 모니터링 시스템에 장애가 발생하더라도 실제 사용중인 어플리케이션에는 어떤 문제도 생기지 않는 점이 제가 생각하는 큰 장점인 것 같습니다.
즉 어플리케이션은 Metrics의 데이터를 제공해줄 준비만 하고 있으면 되고 프로메테우스는 이를 Pull을 통해 가져가기만 하면 됩니다.
