Prometheus 대안과의 비교

1 개요

COMPARISON TO ALTERNATIVES

대안과의 비교

2 Prometheus vs. Graphite

2.1 스코프

Graphite는 쿼리 언어와 그래프 기능이 있는 패시브 시계열 데이터베이스에 초점을 맞춥니다. 다른 문제는 외부 구성 요소에서 처리합니다.

Prometheus는 시계열 데이터를 기반으로 빌트및·액티브 스크래핑, 저장, 쿼리, 그래프 작성 및 알림을 포함하는 완전한 모니터링 및 추세 시스템입니다. 세상이 어떻게 보여야 하는지(어떤 엔드포인트가 존재해야 하는지, 어떤 시계열 패턴이 문제를 의미하는지 등)에 대한 지식이 있으며 적극적으로 오류를 찾으려고 합니다.

2.2 데이터 모델

Graphite는 Prometheus와 매우 비슷하게 명명된 시계열에 대한 숫자 샘플을 저장합니다. 그러나 Prometheus의 메타데이터 모델은 더 풍부합니다. Graphite 메트릭 이름은 차원을 암묵적으로 인코딩하는 점으로 구분된 구성요소로 구성되는 반면, Prometheus는 차원을 메트릭 이름에 첨부된 레이블이라고 하는 키-값 쌍으로 명시적으로 인코딩합니다. 이를 통해 쿼리 언어를 통해 이러한 레이블을 통해 쉽게 필터링, 그룹화·매치시킬 수 있습니다.

또한, 특히 Graphite를 StatsD와 함께 사용하는 경우 인스턴스를 차원으로 보존하고 문제가 있는 개별 인스턴스를 자세히 조사하는 것보다, 모니터링되는 모든 인스턴스에 대해 집계된 데이터만 저장하는 것이 일반적입니다.

예를 들어, 응답 코드 500와 /tracks 엔드포인트에 대한 메서드 POST를 사용하여 API 서버에 대한 HTTP 요청 수를 저장하는 것은 일반적으로 Graphite/StatsD에서 다음과 같이 인코딩됩니다.

stats.api-server.tracks.post.500 -> 93

Prometheus에서는 동일한 데이터를 이와 같이 인코딩할 수 있습니다(API 서버 인스턴스가 3개 있다고 가정):

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31

2.3 스토리지

Graphite는 Whisper 형식으로 로컬 디스크에 시계열 데이터를 저장합니다. Whisper는 샘플이 정기적으로 도착할 것으로 예상하는 RRD 스타일 데이터베이스입니다. 모든 시계열은 별도의 파일에 저장되고, 일정 시간이 지나면 새 샘플이 이전 샘플을 덮어씁니다.

Prometheus는 또한 시계열당 하나의 로컬 파일을 생성하지만, 스크래핑이나 규칙 평가가 발생할 때 임의의 간격으로 샘플을 저장할 수 있습니다. 새 샘플은 간단히 추가되므로, 이전 데이터는 임의로 오랫동안 보관할 수 있습니다. Prometheus는 또한 수명이 짧고 자주 변경되는 많은 시계열 세트에도 적합합니다.

2.4 요약

Prometheus는 사용자 환경에서 실행과 통합이 쉬울 뿐만 아니라 더 풍부한 데이터 모델과 쿼리 언어를 제공합니다. 장기간 과거 데이터를 보관할 수 있는 클러스터링 솔루션이 필요한 경우 Graphite가 더 나은 선택일 수 있습니다.

6 Prometheus vs. Sensu

Sensu는 확장성을 위한 추가 기능을 제공하는 상용 배포판이 있는 오픈 소스 모니터링 및 관찰 파이프라인입니다. 기존 Nagios 플러그인을 재사용할 수 있습니다.

6.1 스코프

Sensu는 이벤트 스트림으로 관찰 데이터를 처리하고 경고하는 데 중점을 둔 관찰 파이프라인입니다. 이벤트 필터링, 집계, 변환 및 처리를 위한 확장 가능한 프레임워크를 제공합니다. 여기에는 다른 시스템에 경고를 보내고 타사 시스템에 이벤트를 저장하는 것이 포함됩니다. Sensu의 이벤트 처리 기능은 범위가 Prometheus 경고 규칙 및 Alertmanager와 비슷합니다.

6.2 데이터 모델

Sensu 이벤트는 엔터티 이름(예: 서버, 클라우드 컴퓨팅 인스턴스, 컨테이너 또는 서비스), 이벤트 이름 및 "레이블" 또는 "주석"이라는 선택적 키-값 메타데이터로 식별되는 구조화된 데이터 형식으로 서비스 상태 및/또는 메트릭을 나타냅니다. Sensu 이벤트 페이로드에는 이름, 태그(키/값 쌍), 타임스탬프, 값(항상 부동 소수점)을 포함하는 JSON 객체로 표현되는 하나 이상의 메트릭 포인트가 포함될 수 있습니다.

6.3 스토리지

Sensu는 현재 및 최근 이벤트 상태 정보와 실시간 인벤토리 데이터를 내장 데이터베이스(etcd) 또는 외부 RDBMS(PostgreSQL)에 저장합니다.

6.4 아키텍처

Sensu 배포의 모든 구성 요소는 고가용성과 향상된 이벤트 처리 처리량을 위해 클러스터링될 수 있습니다.

6.5 요약

Sensu와 Prometheus는 몇 가지 공통적인 기능을 가지고 있지만 모니터링에 대한 접근 방식은 매우 다릅니다. 둘 다 동적 클라우드 기반 환경과 일시적 컴퓨팅 플랫폼에 대한 확장 가능한 검색 메커니즘을 제공하지만 기본 메커니즘은 상당히 다릅니다. 둘 다 레이블과 주석을 통해 다차원 메트릭을 수집하는 것을 지원합니다. 둘 다 광범위한 통합을 가지고 있으며 Sensu는 기본적으로 모든 Prometheus 익스포터에서 메트릭을 수집하는 것을 지원합니다. 둘 다 관찰 데이터를 타사 데이터 플랫폼(예: 이벤트 스토어 또는 TSDB)으로 전달할 수 있습니다. Sensu와 Prometheus가 가장 다른 점은 사용 사례입니다.

Sensu가 더 나은 점:

• 하이브리드 관찰 데이터(메트릭 및/또는 이벤트 포함)를 수집하고 처리하는 경우
• 여러 모니터링 도구를 통합하고 메트릭 및 Nagios 스타일 플러그인 또는 검사 스크립트에 대한 지원이 필요한 경우
• 더욱 강력한 이벤트 처리 플랫폼

Prometheus가 더 나은 점:

• 주로 메트릭을 수집하고 평가하는 경우
• 동종 Kubernetes 인프라를 모니터링하는 경우(모니터링하는 워크로드의 100%가 K8s에 있는 경우 Prometheus가 더 나은 K8s 통합을 제공함)
• 더욱 강력한 쿼리 언어 및 과거 데이터 분석을 위한 빌트인 지원

Sensu는 오픈 코어 비즈니스 모델을 따르는 단일 상업 회사에서 유지 관리하며, 폐쇄 소스 이벤트 상관 관계 및 집계, 페더레이션 및 지원과 같은 프리미엄 기능을 제공합니다. Prometheus는 완전히 오픈소스이고 독립적인 프로젝트로, 여러 회사와 개인이 유지 관리하며, 일부는 상업 서비스와 지원도 제공합니다.

7 참고

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