Overview
Prometheus와 Thanos에 대해서 알아본다.
📅 관련 글
2024.03.05 - [Monitoring] - Fluent Bit (With Loki)
2024.09.12 - [Monitoring] - Prometheus와 Thanos란?
2024.09.12 - [Monitoring] - Prometheus 와 Thanos 설치 및 구성
2024.09.12 - [Monitoring] - Loki란?
2024.09.13 - [Monitoring] - Loki와 Promtail 설치
2025.01.13 - [Monitoring] - ELK Stack 구축해보기
Prometheus와 Thanos란?
Prometheus
Prometheus는 오픈 소스 모니터링 시스템으로, 주로 시간에 따라 변하는 시스템 및 서비스의 메트릭을 수집하고 저장하는 데 사용된다. CNCF(Cloud Native Computing Foundation)에 의해 유지 관리되고 있으며, 많은 클라우드 네이티브 애플리케이션에서 기본 모니터링 도구로 채택되었다.
주요 특징
- Multidimensional data model: 메트릭 이름과 키-값 쌍으로 구성된 레이블을 사용하여 데이터를 저장한다.
- Powerful query language: PromQL(Prometheus Query Language)을 통해 데이터를 효율적으로 검색하고 집계할 수 있다.
- No dependency storage: 자체적인 시간 계열 데이터베이스를 사용하여 외부 데이터베이스에 의존하지 않는다.
- Service discovery: Kubernetes, Consul 등 다양한 서비스 디스커버리 옵션을 통해 동적인 서비스 환경을 자동으로 모니터링 할 수 있다.
- Warning: Alertmanager와 통합하여 경고 규칙을 정의하고, 문제가 발생했을 때 알림을 보낼 수 있다.
Prometheus 구성요소
- Prometheus Server
- 메트릭 데이터를 수집하고, 저장하며, 쿼리를 실행한다.
- Prometheus 서버는 스크래핑(scrapping)을 통해 메트릭을 수집하고, 자체적인 시계열 데이터베이스에 저장한다.
- Alertmanager
- 알림을 관리하고 처리한다.
- Prometheus 서버에서 설정된 규칙에 따라 발생하는 경고를 받아, 이메일, Slack, PagerDuty 등 여러 알림 채널을 통해 알림을 보낸다.
- Pushgateway
- 일반적으로 서버/장치가 짧은 기간 동안만 존재하거나, 메트릭을 직접적으로 Prometheus 서버에 푸시(push)해야 하는 배치 작업과 같은 nondurable 작업에 대한 메트릭을 중간에 저장한다.
- Exporters
- Prometheus가 자체적으로 수집하지 못하는 메트릭을 위해 사용되는 도구이다.
- 다양한 서비스, 시스템, 인프라에서 메트릭을 수집하기 위해 특별히 설계된 Exporters가 있다.
- 예를 들어, Node Exporter는 서버의 시스템 메트릭을 수집하고, MySQL Exporter는 MySQL 데이터베이스의 메트릭을 수집한다.
- Service Discovery
- 메트릭을 수집할 타겟의 목록을 동적으로 관리하기 위해 사용된다.
- Kubernetes, AWS, Azure 등 여러 클라우드 및 오케스트레이션 플랫폼과 통합하여 자동으로 모니터링할 타겟을 찾고 업데이트한다.
Prometheus 구성 시 주의사항
| 항목 | 상세 설명 |
| 보존기간 설정 | Prometheus 기본 보존 기간은 15일이며, 장기 보관 필요 시 Thanos로 연계 필요 |
| 자원 제한 | 메모리 및 디스크 사용량을 꾸준히 모니터링해야 OOM(Out Of Memory) 방지 |
| Target 관리 | Service Discovery 활용하여 대상 자동 관리 권장 |
| Alert Rule | 지나치게 많은 Alert Rule 설정 시, 성능 저하 및 Alert 폭풍 가능성 |
Thanos
Thanos는 Prometheus의 데이터를 장기간 보관하고, 확장성을 높이며, 고가용성을 보장하기 위해 설계된 오픈 소스 프로젝트이다. 크게 확장된 환경에서 Prometheus의 한계를 극복하고자 개발되었다.
주요 특징
- Long-term data archiving: Thanos는 다양한 클라우드 스토리지 백엔드(S3, GCS, Azure Blob Storage 등)에 데이터를 저장하여 장기적인 데이터 보관을 가능하게 한다.
- Expandable Queries: 여러 Prometheus 인스턴스에서 데이터를 수집하고 Thanos Querier를 통해 이를 하나의 전역 뷰로 통합하여 쿼리할 수 있다.
- High availability: Thanos는 데이터 손실 없이 높은 가용성을 제공한다. 여러 복제본에서 데이터를 읽을 수 있도록 지원한다.
- Cost-effective storage: Thanos Compactor를 사용하여 시간에 따라 데이터를 압축하고 최적화하여 스토리지 비용을 절감할 수 있다.
- Multiple clusters: 여러 Prometheus 클러스터의 데이터를 하나의 Thanos 시스템으로 통합하여 관리할 수 있다.
Thanos 구성요소
- Sidecar: Prometheus 서버에 배치되어 실시간 데이터를 접근하고, 필요한 경우 외부 스토리지로 업로드한다.
- Querier: 여러 Sidecar 또는 Store 게이트웨이에서 데이터를 쿼리하여 사용자에게 단일 뷰를 제공한다.
- Store Gateway: 장기 스토리지에서 데이터를 읽어 Querier에 제공한다.
- Compactor: 장기 스토리지에 저장된 데이터를 압축 및 최적화한다.
- Receiver: Thanos의 확장성을 위해 Prometheus로부터 직접 데이터를 수신할 수 있는 역할을 한다.
- Ruler: 경고 규칙과 Prometheus 호환 집계 규칙을 실행한다.
- Frontend: Thanos의 상태를 웹에서 확인가능하다.
Prometheus와 Thanos의 동작방식
Thanos 구성요소들과 Prometheus의 데이터 흐름을 순서대로 설명하면 아래와 같다.
- Prometheus
- 메트릭을 수집하고 로컬 스토리지에 저장한다. 이는 각 노드나 서비스에서 메트릭을 주기적으로 가져오는 과정을 포함한다.
- Local Storage
- Prometheus가 수집한 데이터를 자체적인 시계열 데이터베이스에 저장한다. 이는 실시간 데이터 조회에 사용된다.
- Thanos Sidecar
- Prometheus 인스턴스와 함께 배포되어, Prometheus의 로컬 스토리지에 저장된 데이터에 접근할 수 있도록 한다. 이 컴포넌트는 실시간 데이터를 조회하고, 구성된 장기 저장소로 오래된 데이터 블록을 업로드한다.
- Thanos Query
- 사용자와 다른 시스템의 데이터 쿼리 요청을 받아 처리한다. Thanos Query는 Thanos Sidecar를 통해 실시간 데이터와, Thanos Store를 통해 장기 데이터를 조회할 수 있다.
- Object Storage(ex. AWS S3, Google Cloud Storage, Minio, Ceph, etc..)
- 장기적으로 데이터를 저장하는 저장소이다. Thanos Sidecar에서 업로드한 데이터 블록들이 저장된다.
- Thanos Store
- Object Storage에 저장된 데이터에 접근하여 쿼리를 수행한다. 이 컴포넌트는 오래된 데이터에 대한 쿼리를 가능하게 하여, 장기적인 데이터 분석과 모니터링을 지원한다.
- Users
- 최종 사용자나 다른 시스템들이 Thanos Query를 통해 데이터를 조회할 수 있다. 이는 대시보드, 알림 시스템, 또는 데이터 분석 도구를 통해 이루어질 수 있다.
Thanos 구성 시 주의사항
| 항목 | 상세 설명 |
| Object Storage 선택 | AWS S3, GCS 등 신뢰성 높은 저장소 선택 필수 |
| Compaction 주기 | 데이터 압축 주기 설정으로 스토리지 비용 절감 가능 |
| Querier 부하 | 많은 데이터 조회 시 Querier 부하 증가 가능성, 캐싱 전략 검토 필요 |
| Sidecar 설정 | Prometheus 인스턴스별 Sidecar 반드시 구성 필요 (빠뜨리면 데이터 누락 위험) |
Prometheus와 Thanos의 도입 배경과 필요성
Prometheus는 강력한 모니터링 도구이지만, 다음과 같은 한계가 있다.
| 한계점 | 설명 |
| 단기 데이터 보관 | Prometheus는 기본적으로 로컬 디스크에 데이터를 저장하며, 데이터 보존 기간이 짧음 (디스크 용량 한계) |
| 복수 클러스터 통합 어려움 | 여러 클러스터에서 Prometheus를 운영할 경우, 각각의 데이터가 분리 관리됨 |
| 고가용성 부족 | 단일 Prometheus 인스턴스 장애 시 데이터 손실 가능성 |
➡️ Thanos는 이런 한계를 해결하기 위해 등장한 확장 솔루션
- 장기 보관 및 백업 지원
- 여러 Prometheus 인스턴스를 통합 관리
- 중앙 쿼리 및 글로벌 뷰 제공
- Object Storage 기반의 경제적 스토리지 운영
Prometheus와 Thanos 아키텍처 흐름도 예시
+-----------------+ +------------------+ +---------------------+
| Kubernetes | | Kubernetes | | Object Storage (S3) |
| Cluster A | | Cluster B | | |
| | | | | |
| Prometheus | | Prometheus | | |
| + Sidecar | | + Sidecar | | |
+-----------------+ +------------------+ +---------------------+
\ / /
\ / /
+-------------------------------------+
| Thanos Querier |
+-------------------------------------+
|
Grafana / AlertManager 등
마무리
Prometheus와 Thanos는 클라우드 네이티브 환경에서 필수적인 모니터링 조합이다.
특히 데이터 보존 기간 문제, Multi Cluster 통합 모니터링, 장기 저장 비용 절감 같은 문제를 효과적으로 해결할 수 있다.
하지만 단순히 도입하는 것만으로는 효과를 보기 어렵다.
- ✅ 클러스터 규모에 맞는 저장소 전략
- ✅ 적절한 보존 기간 설정
- ✅ 효과적인 Alert Rule 구성
- ✅ 성능 튜닝 및 쿼리 캐싱 전략
등이 함께 고려되어야 한다.
궁극적으로 Prometheus와 Thanos는 '단순 모니터링 도구'가 아니라, 전체적인 관측 가능성(Observability) 플랫폼으로 발전하고 있다. 이를 활용해 서비스 품질 개선과 장애 예방에 적극적으로 활용하는 것이 최종 목표가 되어야 한다.
다음 포스팅에서는 Prometheus와 Thanos를 Helm Chart를 사용해서 구성하는 방법에 대해서 알아본다.
그리고 Multi Cluster를 구성하고 있다면 다른 Cluster의 Metric들을 통합하여 관리하는 방법에 대해서 알아본다.
Reference
https://medium.com/@MetricFire/remote-prometheus-monitoring-using-thanos-4e2269000bf0
https://prometheus.io/docs/introduction/overview/
https://thanos.io/tip/thanos/getting-started.md/
https://grafana.com/docs/grafana/latest/datasources/prometheus/
https://blog.kloudless.com/2020/06/23/prometheus-architecture-and-key-components/
'Monitoring' 카테고리의 다른 글
| ELK Stack 구축해보기 (2) | 2025.01.27 |
|---|---|
| Loki와 Promtail 설치 (5) | 2024.10.02 |
| Loki란? (4) | 2024.09.26 |
| Prometheus 와 Thanos 설치 및 구성 (0) | 2024.09.19 |
| Fluent Bit (With Loki) (4) | 2024.03.08 |