"Prometheus 대안과의 비교"의 두 판 사이의 차이

5번째 줄: 5번째 줄:
==Prometheus vs. Graphite==
==Prometheus vs. Graphite==
===스코프===
===스코프===
[[Graphite]]는 쿼리 언어와 그래프 기능이 있는 패시브 시계열 데이터베이스에 초점을 맞춥니다. 다른 문제는 외부 구성 요소에서 처리합니다.
Prometheus는 시계열 데이터를 기반으로 빌트및·액티브 스크래핑, 저장, 쿼리, 그래프 작성 및 알림을 포함하는 완전한 모니터링 및 추세 시스템입니다. 세상이 어떻게 보여야 하는지(어떤 엔드포인트가 존재해야 하는지, 어떤 시계열 패턴이 문제를 의미하는지 등)에 대한 지식이 있으며 적극적으로 오류를 찾으려고 합니다.
===데이터 모델===
===데이터 모델===
Graphite는 Prometheus와 매우 비슷하게 명명된 시계열에 대한 숫자 샘플을 저장합니다. 그러나 Prometheus의 메타데이터 모델은 더 풍부합니다. Graphite 메트릭 이름은 차원을 암묵적으로 인코딩하는 점으로 구분된 구성요소로 구성되는 반면, Prometheus는 차원을 메트릭 이름에 첨부된 레이블이라고 하는 키-값 쌍으로 명시적으로 인코딩합니다. 이를 통해 쿼리 언어를 통해 이러한 레이블을 통해 쉽게 필터링, 그룹화·매치시킬 수 있습니다.
또한, 특히 Graphite를 StatsD 와 함께 사용하는 경우 인스턴스를 차원으로 보존하고 문제가 있는 개별 인스턴스를 자세히 조사하는 것보다, 모니터링되는 모든 인스턴스에 대해 집계된 데이터만 저장하는 것이 일반적입니다.
예를 들어, 응답 코드 <code>500</code>와 <code>/tracks</code> 엔드포인트에 대한 메서드 <code>POST</code>를 사용하여 API 서버에 대한 HTTP 요청 수를 저장하는 것은 일반적으로 Graphite/StatsD에서 다음과 같이 인코딩됩니다.
<syntaxhighlight lang='text'>
stats.api-server.tracks.post.500 -> 93
</syntaxhighlight>
Prometheus에서는 동일한 데이터를 이와 같이 인코딩할 수 있습니다(API 서버 인스턴스가 3개 있다고 가정):
<syntaxhighlight lang='text'>
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
</syntaxhighlight>
===스토리지===
===스토리지===
===요약===
===요약===
==Prometheus vs. InfluxDB==
==Prometheus vs. InfluxDB==
===스코프===
===스코프===

2024년 9월 26일 (목) 20:32 판

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 스토리지

2.4 요약

3 Prometheus vs. InfluxDB

3.1 스코프

3.2 데이터 모델 / 스토리지

3.3 아키텍처

3.4 요약

4 Prometheus vs. OpenTSDB

4.1 스코프

4.2 데이터 모델

4.3 스토리지

5 Prometheus vs. Nagios

5.1 스코프

5.2 데이터 모델

5.3 스토리지

5.4 아키텍처

5.5 요약

6 Prometheus vs. Sensu

6.1 스코프

6.2 데이터 모델

6.3 스토리지

6.4 아키텍처

6.5 요약

7 참고

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}