모니터링 시스템 구축 2편, Prometheus 개념 및 특징
이전 포스팅을 통해 '모니터링의 개념과 목적' 그리고 spring-boot-actuator, Prometheus, Grafana를 통한 '모니터링 시스템 구축의 전체적인 흐름'에 대해서 살펴보았으며, 그중에서 'Actuator'와 'Micrometor'에 대해서 자세하게 알아봤습니다.
2023.09.09 - [Programming/Monitoring] - Spring Boot Actuator(+ Micrometor) 모니터링 시스템 구축 1편
이어지는 이번 포스팅에서는 actuator에서 만들어진 메트릭을 수집 및 통합하여 저장하는 역할을 하는 'Prometheus'의 개념과 특징에 대해 살펴보겠습니다.
Prometheus 개념 및 특징
Prometheus는 SoundCloud에서 처음 개발되어 현재는 CNCF(Cloud Native Computing Foundation)에서 지원하고 있는 오픈소스 프로젝트로 메트릭 기반의 모니터링 시스템을 구축하는 데 사용되는 도구입니다.
(CNCF에 속해 있기 때문에 Kubernetes, Jaeger, Istio의 Mixer 등 CNCF의 프로젝트 대부분이 프로메테우스를 지원한다는 특징이 있습니다.)
Actuator를 통해 만들어지는 다양한 메트릭은 실시간 정보만을 조회할 수 있기 때문에 과거의 메트릭을 확인할 수 없다는 문제점이 있었는데요.
이러한 문제점을 해결하기 위해 Actuator의 메트릭을 지속적으로 수집하고 보관하는 데이터베이스 역할을 하는 것이 바로 'Prometheus'입니다.
***
일반적인 모니터링 도구의 경우 서버에 클라이언트를 설치하고, 클라이언트가 메트릭을 수집하여 서버로 보내는 방식(push-based monitoring system)으로 동작하는 반면, 프로메테우스는 반대로 HTTP 요청을 통해 클라이언트에 직접 접속해서 주기적으로 메트릭을 가져오는 방식(pull-based monitoring system)으로 동작한다는 특징이 있습니다.
(Actuator의 endpoints에 주기적인 요청을 통해 메트릭을 수집합니다.)
그리고 프로메테우스는 pull 방식을 통해 가져온 시계열(time series) 데이터를 기록(저장)합니다.
* 시계열 데이터란 일정한 시간 동안 수집된 순차적 데이터 셋의 집합이며, 프로메테우스가 수집하는 시계열 데이터의 형식은 아래와 같습니다.
<metric name>{<label name>=<label value>, ...}(시계열 데이터 형식과 아래 예시)
Prometheus의 특징을 정리해 보면 아래와 같은데요.
- '다차원 데이터 모델' (메트릭 이름 및 key/value 차원 집합으로 정의된 시계열)을 사용합니다.
- 그리고 다차원 데이터 모델을 활용하는 쿼리 언어인 'PromQL'을 사용합니다.
- 타겟의 'metric을 pull 방식으로 수집'합니다. (필요한 경우 push 방식도 가능하며, 이때 Pushgateway가 사용됩니다.)
- 다양한 '그래프 및 대시보드'를 지원합니다. (시각화에는 Grafana가 많이 사용됩니다.)
- 'Service discovery'를 통해 모니터링 대상에 대한 타겟팅을 지원합니다.
- 분산 스토리지에 대한 종속성이 없고, 단일 서버로 운영됩니다.
(네트워크 스토리지 또는 기타 원격 서비스에 의존하지 않고 독집적이라는 이야기로, 인프라의 다른 부분이 중단된 경우에도 동작하는데 문제가 없습니다.)
Pushgateway, Service discovery 등에 대해서는 아래 Architecture 부분을 통해 자세하게 살펴볼 수 있습니다.
* 주의할 점
프로메테우스에서 주의해야 할 점은 수집되는 데이터가 100% 정확한 것이 아니라 근사치라는 것인데요.
Prometheus는 일정한 주기로 metric을 가져오기 때문에 풀링 하는 순간의 스냅샷이 있으며, 만약 1분을 주기로 메트릭을 가져온다고 했을 때, 메트릭을 가져오고 다음 메트릭을 가져오기까지 1분 사이에 cpu 사용량이 급격하게 올라갔다가 다시 내려와서 다음 메트릭이 측정된다면 그 사이에 발생했던 급격한 cpu 사용량 증가는 측정이 되지 않게 됩니다.
이처럼 수집되는 metric은 풀링 하는 순간의 스냅샷에 대한 연속된 모음일 뿐이며, 근삿값의 형태를 가진다는 것은 꼭 알아두어야 하는 부분입니다.
Architecture
이어서 Prometheus Architecture를 통해 각각의 부분에 대해서 살펴보겠습니다.
(해당 이미지의 프로메테우스 공식 문서에서 참고한 것입니다.)
Exporter
Exporter는 모니터링 대상의 metric을 수집하여 Prometheus가 가져갈 수 있도록 메트릭을 노출시켜 주는 역할을 하는데요.
해당 예시에서는 Actuator가 Exporter의 역할을 담당하고 있으며 '/actuator/prometheus' 엔드포인트를 통해 메트릭을 가져갈 수 있도록 합니다.
Pushgateway
앞서 이야기한 것처럼 프로메테우스는 기본적으로 pull 방식을 통해 메트릭을 수집합니다.
하지만 배치잡 등의 경우에 pull 방식을 통해 메트릭을 수집하지 못하는 상황이 생길 수도 있는데요.
이럴 때 Pushgateway를 사용할 수 있는데, application에서 Pushgateway에 메트릭을 push 한 후, prometheus server에서 pushgateway에 접근하여 metric을 pull 하는 방식입니다.
Service discovery
풀링 방식의 경우 오토스케일링(Autosacling)으로 인해 모니터링 대상이 가변적으로 변경될 경우 대상을 알 수 없다는 것이 문제가 될 수 있는데요.
이러한 문제를 해결하기 위해 Service discovery가 사용되며, 서비스 디스커버리는 기본적으로 모니터링 대상 목록을 유지하고 있고, 대상에 대한 정보도 가지고 있습니다.
Alertmanager
Alertmanager는 Prometheus와 함께 작동하는 알림 및 경고 관리를 위한 도구로, Prometheus에서 수집된 메트릭을 기반으로 경고를 생성하고 관리합니다.
푸시 알림, Email, Slack 등의 다양한 채널을 통해 경고 알림을 전송할 수 있습니다.
여기까지 Prometheus의 개념 및 특징에 대한 정리입니다.
원래 계획은 개념 및 특징과 함께 기본적인 사용 방법까지 포스팅할 예정이었으나, 생각보다 내용이 길어져서 나누어 포스팅하게 되었으며, 이어지는 포스팅은 작성 후 아래 링크를 추가하도록 하겠습니다. 감사합니다.
< 이어지는 포스팅 >
2023.09.21 - [Programming/Monitoring] - Prometheus 설정 및 실행, 사용 방법(+ PromQL)
< 참고 자료 >
'Programming > Monitoring' 카테고리의 다른 글
| Prometheus 설정 및 실행, 사용 방법(+ PromQL) (0) | 2023.09.21 |
|---|---|
| Spring Boot Actuator(+ Micrometor) 모니터링 시스템 구축 1편 (0) | 2023.09.09 |