프로메테우스란?

개요

---

프로메테우스...

프로메테우스는 그리스 로마 신화에서 사람들에게 불을 가져다 준 신으로 알려져 있는데 사람들은 이 불을 통해 음식을 익혀먹고, 밤에 보지 못했던 것들을 볼 수 있게 되었다. 모니터링 툴 Prometheus는 불을 통해 무언가를 잘 관찰할 수 있게 해 준 신의 이름을 차용해 지어졌다고 한다.

 

사전적인 의미로 정의하면 프로메테우스는 SoundCloud에서 만든 오픈소스 시스템 모니터링 및 경고 툴킷으로 요약할 수 있다. 아래 그림은 프로메테우스 공식 홈페이지에 있는 특징들인데, 큰 특징들만 추려 정리하자면 아래와 같다.

• 메트릭을 수집하여 시계열 데이터 저장
• 수집한 데이터의 시각화 (with Grafana)
• PromQL을 통한 강력한 쿼리
• AlertManager를 통한 쉽고 정확한 알림
• 다양한 클라이언트 라이브러리들

그림 1. Prometheus 특징

이렇게 많은 특징들을 갖고 있는 프로메테우스는 단 하나의 컴포넌트가 아닌 여러 개의 컴포넌트의 조합으로 이루어져 있으며 각 컴포넌트간의 상호작용을 통해 강력한 모니터링과 알람등의 기능을 제공한다.

 

기본 구조

---

그림 2. Prometheus 아키텍처

위 그림은 프로메테우스의 구조를 검색하면 쉽게 찾아볼 수 있는 아키텍처 모식도이다. 기본적으로 metric 데이터를 Pull하여 TSDB라는 저장소 혹은 디스크에 저장한 후에 해당 정보를 바탕으로 알람이나 모니터링 툴과 연결되는 구조이다. 주요 요소들의 기능은 아래와 같다.

---

Jobs/exporters

exporters는 말 그대로 데이터를 밖으로 전달하는역할을 하는 컴포넌트이며 프로메테우스가 Pull 방식으로 데이터를 수집할 수 있도록 메트릭을 노출하는 agent이다. 지난 글에서 정리했던 스프링 부트의 actuator가 이러한 exporter의 역할을 수행할 수 있으며, 어플리케이션 상태 뿐만 아니라 CPU, 메모리, 디스크 등의 하드웨어 상태도 메트릭으로 전달 할 수 있다.

프로메테우스는 이러한 exporter가 제공하는 endpoint로 GET요청을 날려 형식화된 메트릭 데이터를 수집하고 저장한다.

---

Pushgateway

기본적으로 프로메테우스는 Pull방식을 통해 데이터를 수집하지만 배치잡과 같은 작업은 실시간으로 정보를 요청해서 받아오는 것이 불가능하다. 따라서 이에 대한 대안으로 어플리케이션은 Pushgateway로 메트릭을 Push하고 프로메테우스는 이 Pushgateway에 접근하여 쌓여있는 메트릭을 Pull하는 방식으로 데이터를 얻을 수 있다.

---

Service Discovery

이전 글에서 다루었던 Netflix Eureka가 이에 속하며, 프로메테우스가 메트릭을 수집할 대상을 동적으로 설정하는 것을 가능케 한다. MSA와 같은 환경에서는 오토 스케일링이 될 수 있기 때문에 이러한 인스턴스들을 Service Discovery를 통해 추적할 수 있다.

---

TSDB

Time-series Database의 약어이며 수집된 메트릭을 저장하는 역할을 한다. 프로메테우스 서버의 메모리, 디스크에 저장되며 최초 프로메테우스를 설계할 때에는 Scale out을 고려하지 않았기 때문에 모니터링할 데이터가 많아질 수록 장비를 업그레이드 해주어야 하는 문제가 있었다. 최근에는 클러스터링을 지원하는 Thanos 등의 오픈 소스를 사용하면 해결할 수 있다.

---

AlertManager

수집된 메트릭을 기반으로 임계치를 넘는 시점에 slack, mail등을 통해 알람을 보내주는 컴포넌트이며, 이는 Rule을 작성하여 정할 수 있다.

---

PromQL & Visualization

TSDB에 저장된 메트릭을 PromQL을 통해 조회하고 이를 외부 API나 프로메테우스 웹콘솔을 통해 시각화가 가능하다. 프로메테우스와 함께 많이 언급되는 Grafana등과 통합하여 시각화 하는것도 가능하다.

그림 3. PromQL로 조회한 프로메테우스 콘솔 그래프

그림 4. 그라파나 패널 그래프

 

Metric

---

위의 프로메테우스 구조에서 계속 언급되는 것이 메트릭인데 메트릭은 일반적으로 타임스탬프와 한 두가지 숫자값을 포함하는 이벤트로 볼 수 있다. 프로메테우스는 근본적으로 모든 데이터를 시계열로 저장하고, 이는 고유한 메트릭명과 옵셔널하게 들어갈 수 있는 key-value 쌍의 라벨로 구분될 수 있다.

메트릭명{라벨명=값, 라벨명=값} 샘플링 데이터

프로메테우스의 메트릭을 정의하면 위처럼 구성되어 있으며 실제 수집되는 메트릭의 예시는 아래와 같다.

그림 5. 프로메테우스 메트릭 예시

첫 번째 데이터를 해석하면 cpu 라벨 값이 0, mode 라벨 값이 idel인 node_cpu_seconds_total이라는 메트릭 이름이 있고, 이 값은 48629.88이다. 이 메트릭은 프로메테우스에 수집되어 timestamp와 함께 저장되고, 이렇게 누적된 메트릭 데이터를 시계열 데이터라고 한다.

 

보통 메트릭은 매 순간 수집되는 것이 아닌 일정 텀을 두고 수집되며, 이렇게 수집된 데이터가 시간순서로 점차 쌓이기 때문에 프로메테우스를 통해 어떠한 이벤트의 추이를 파악하기가 좋다. 하지만 항상 데이터 수집의 성공을 보장할 수 없기 때문에 약간의 부정확성과 레이스 컨디션이 따르며 따라서 100%의 정확성이 요구되는 사항에는 적합하지 않을 수 있다.

 

Continue...

---

이번 글에서는 프로메테우스가 무엇인지, 어떤 구성요소로 이루어져 있는지를 정리해 보았다. 다음에는 이전에 정리했던 스프링 부트 엑추에이터와 프로메테우스, 그라파나를 사용해서 실제 서비스를 모니터링해보고 이를 정리해보려고 한다. (사실 Windows docker랑 씨름하다가 못했음…)

 

참고

---

 

프로메테우스(Prometheus) 알아보기

 

Prometheus 란?