Prometheus 대안과의 비교

1 개요

COMPARISON TO ALTERNATIVES

대안과의 비교

2 Prometheus vs. Graphite

2.1 스코프

Graphite는 패시브 시계열 데이터베이스로서 쿼리 언어와 그래프 기능에 중점을 둡니다. 다른 관심사는 외부 구성 요소에 의해 처리됩니다.

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

2.2 데이터 모델

Graphite는 Prometheus와 마찬가지로 이름이 지정된 시계열의 숫자 샘플을 저장합니다. 하지만 Prometheus의 메타데이터 모델은 더 풍부합니다. Graphite의 메트릭 이름은 점으로 구분된 구성요소들로 구성되어 있으며, 이 구성요소들은 암묵적으로 차원을 인코딩합니다. 반면, Prometheus는 메트릭 이름에 키-값 쌍 형태의 레이블을 명시적으로 첨부하여 차원을 인코딩합니다. 이를 통해 쿼리 언어를 사용하여 이러한 레이블을 쉽게 필터링, 그룹화 및 매칭할 수 있습니다.

따라서 특히 Graphite와 StatsD를 조합해서 사용할 경우, 모든 모니터링 인스턴스에 대한 집계된 데이터만을 저장하고, 인스턴스를 차원으로 유지하지 않음으로써 개별적인 문제가 있는 인스턴스를 자세히 조사할 수 없는 경우가 일반적입니다.

예를 들어, API 서버의 /tracks 엔드포인트에 POST 메소드로 500 응답 코드를 반환한 HTTP 요청 수를 저장한다고 가정해 봅시다. 이는 Graphite/StatsD에서 일반적으로 다음과 같이 인코딩됩니다:

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

Prometheus에서는 동일한 데이터를 다음과 같이 인코딩할 수 있습니다 (세 개의 api-server 인스턴스를 가정):

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 또한 시계열마다 하나의 로컬 파일을 생성하지만, 스크레이핑(scraping)이나 규칙 평가가 발생할 때마다 임의의 간격으로 샘플을 저장할 수 있습니다. 새로운 샘플은 단순히 추가되기 때문에 오래된 데이터를 임의로 오래 보관할 수 있습니다. Prometheus는 짧은 주기로 빈번하게 변경되는 많은 시계열 세트에도 잘 작동합니다.

2.4 요약

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

3 Prometheus vs. InfluxDB

InfluxDB는 확장 및 클러스터링을 위한 상업적 옵션이 있는 오픈소스 시계열 데이터베이스입니다. InfluxDB 프로젝트는 Prometheus 개발이 시작된 지 거의 1년 후에 출시되었으므로 당시에는 대안으로 고려할 수 없었습니다. 그래도 Prometheus와 InfluxDB 사이에는 상당한 차이가 있으며 두 시스템 모두 약간 다른 사용 사례에 맞춰져 있습니다.

3.1 스코프

공정한 비교를 위해 Kapacitor와 InfluxDB도 함께 고려해야 합니다. 두 시스템을 결합하면 Prometheus와 Alertmanager와 동일한 문제 공간을 해결하기 때문입니다.

Graphite의 경우와 동일한 스코프 차이가 InfluxDB 자체에도 적용됩니다. 또한 InfluxDB는 Prometheus 기록 규칙과 동일한 연속 쿼리를 제공합니다.

Kapacitor의 범위는 Prometheus 기록 규칙, 알림 규칙 및 Alertmanager의 알림 기능을 결합한 것입니다. Prometheus는 그래프 및 알림을 위한 더 강력한 쿼리 언어를 제공합니다. Prometheus Alertmanager는 또한 그룹화, 중복 제거 및 침묵 기능을 제공합니다.

3.2 데이터 모델 / 스토리지

Prometheus와 마찬가지로 InfluxDB 데이터 모델은 태그라고 하는 레이블인 키-값 쌍을 가지고 있습니다. 또한 InfluxDB에는 필드라고 하는 두 번째 레벨의 레이블이 있으며, 이는 사용이 더 제한적입니다. InfluxDB는 최대 나노초 해상도의 타임스탬프와 float64, int64, bool, 문자열 데이터 유형을 지원합니다. 반면 Prometheus는 문자열에 대한 제한적인 지원과 밀리초 해상도 타임스탬프를 제공하는 float64 데이터 유형을 지원합니다.

InfluxDB는 시간별로 분할된 쓰기 사전 로그와 함께 저장을 위해 로그 구조 병합 트리의 변형을 사용합니다. 이는 Prometheus의 시간 시리즈별 추가 전용 파일 접근 방식보다 이벤트 로깅에 훨씬 더 적합합니다.

로그와 메트릭과 그래프, 오 마이!는 이벤트 로깅과 메트릭 기록의 차이점을 설명합니다.

3.3 아키텍처

Prometheus 서버는 서로 독립적으로 실행되며 스크래핑, 규칙 처리, 알림과 같은 핵심 기능을 위해 로컬 스토리지에만 의존합니다. InfluxDB의 오픈 소스 버전도 비슷합니다.

상업용 InfluxDB 제품은 설계상 여러 노드가 한 번에 스토리지와 쿼리를 처리하는 분산 스토리지 클러스터입니다.

즉, 상업용 InfluxDB는 수평적으로 확장하기가 더 쉽지만 처음부터 분산 스토리지 시스템의 복잡성을 관리해야 합니다. Prometheus는 실행하기가 더 간단하지만 어느 시점에서는 제품, 서비스, 데이터 센터 또는 유사한 측면과 같은 확장성 경계를 따라 서버를 명시적으로 샤딩해야 합니다. 독립적인 서버(병렬로 중복 실행 가능)는 더 나은 안정성과 장애 격리를 제공할 수도 있습니다.

Kapacitor의 오픈 소스 릴리스에는 규칙, 알림 또는 알림에 대한 기본 제공 분산/중복 옵션이 없습니다. Kapacitor의 오픈 소스 릴리스는 Prometheus 자체와 유사하게 사용자가 수동 샤딩을 통해 확장할 수 있습니다. Influx는 HA/중복 알림 시스템을 지원하는 Enterprise Kapacitor를 제공합니다.

Prometheus와 Alertmanager는 대조적으로 Prometheus의 중복 복제본을 실행하고 Alertmanager의 고가용성 모드를 사용하여 완전히 오픈 소스 중복 옵션을 제공합니다.

3.4 요약

시스템 간에는 많은 유사점이 있습니다. 둘 다 다차원 메트릭을 효율적으로 지원하기 위한 레이블(InfluxDB에서는 태그라고 함)이 있습니다. 둘 다 기본적으로 동일한 데이터 압축 알고리즘을 사용합니다. 둘 다 서로를 포함하여 광범위한 통합이 있습니다. 둘 다 통계 도구에서 데이터를 분석하거나 자동화된 작업을 수행하는 것과 같이 더 확장할 수 있는 후크가 있습니다.

InfluxDB가 더 나은 점:

• 이벤트 로깅을 수행하는 경우.
• 상업용 옵션은 InfluxDB에 대한 클러스터링을 제공하며, 이는 장기 데이터 저장에도 더 좋습니다.
• 레플리카 간의 최종적으로 일관된 데이터 보기.

Prometheus가 더 나은 점:

• 주로 메트릭을 다루는 경우.
• 더 강력한 쿼리 언어, 알림 및 알림 기능.
• 그래프 및 알림에 대한 더 높은 가용성 및 가동 시간.

InfluxDB는 오픈 코어 모델을 따르는 단일 상업 회사에서 유지 관리하며, 폐쇄형 소스 클러스터링, 호스팅 및 지원과 같은 프리미엄 기능을 제공합니다. Prometheus는 완전히 오픈 소스이고 독립적인 프로젝트로, 일부는 상업용 서비스와 지원도 제공하는 여러 회사와 개인이 유지관리합니다.

4 Prometheus vs. OpenTSDB

OpenTSDB는 Hadoop과 HBase를 기반으로 하는 분산형 시계열 데이터베이스입니다.

4.1 스코프

Graphite의 경우와 동일한 범위 차이가 여기에 적용됩니다.

4.2 데이터 모델

OpenTSDB의 데이터 모델은 Prometheus와 거의 동일합니다. 시계열은 임의의 키-값 쌍(OpenTSDB 태그는 Prometheus 레이블)으로 식별됩니다. 메트릭의 모든 데이터는 함께 저장되어 메트릭의 기수가 제한됩니다. 그러나 사소한 차이점이 있습니다. Prometheus는 레이블 값에 임의의 문자를 허용하는 반면 OpenTSDB는 더 제한적입니다. OpenTSDB에는 전체 쿼리 언어가 없으며 API를 통한 간단한 집계 및 수학만 허용합니다.

4.3 스토리지

OpenTSDB의 저장소는 Hadoop과 HBase 위에 구현됩니다. 즉, OpenTSDB를 수평적으로 확장하기 쉽지만 처음부터 Hadoop/HBase 클러스터를 실행하는 전반적인 복잡성을 수용해야 합니다.

Prometheus는 처음에는 실행하기가 더 간단하지만 단일 노드의 용량을 초과하면 명시적 샤딩이 필요합니다.

4.4 요약

Prometheus는 훨씬 더 풍부한 쿼리 언어를 제공하고, 더 높은 카디널리티 메트릭을 처리할 수 있으며, 완전한 모니터링 시스템의 일부를 형성합니다. 이미 Hadoop을 실행 중이고 이러한 이점보다 장기 저장을 중요하게 생각한다면 OpenTSDB가 좋은 선택입니다.

5 Prometheus vs. Nagios

Nagios는 1990년대에 NetSaint로 시작된 모니터링 시스템입니다.

5.1 스코프

Nagios는 주로 스크립트의 종료 코드를 기반으로 하는 경고에 관한 것입니다. 이를 "점검(checks)"라고 합니다. 개별 경고는 침묵시키지만 그룹화, 라우팅 또는 중복 제거는 없습니다.

다양한 플러그인이 있습니다. 예를 들어, 몇 킬로바이트의 perfData 플러그인을 파이프로 연결하여 Graphite와 같은 시계열 데이터베이스로 반환하거나 NRPE를 사용하여 원격 컴퓨터에서 점검을 실행할 수 있습니다.

5.2 데이터 모델

Nagios는 호스트 기반입니다. 각 호스트는 하나 이상의 서비스를 가질 수 있으며 각 서비스는 하나의 점검을 수행할 수 있습니다.

레이블이나 쿼리 언어에 대한 개념은 없습니다.

5.3 스토리지

Nagios는 현재 점검 상태를 넘어서는 저장소가 없습니다. 시각화를 위해 데이터를 저장할 수 있는 플러그인이 있습니다.

5.4 아키텍처

Nagios 서버는 독립형입니다. 모든 점검 설정은 파일을 통해 이루어집니다.

5.5 요약

Nagios는 블랙박스 프로빙이 충분한 소규모 및/또는 정적 시스템의 기본 모니터링에 적합합니다.

화이트박스 모니터링을 수행하거나 동적 또는 클라우드 기반 환경을 원할 경우 Prometheus가 좋은 선택입니다.

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/