[Prometheus] 프로메테우스 기본 개념 정리 (p.s. 메트릭이란?)

 

prometheus는 오픈 소스 기반의 모니터링 시스템이다. (그리스 로마 신화에서 최초로 인간을 창조했다는 그 프로메테우스가 말고..ㅎ) SoundCloud사에서 만들었지만 지금은 독립형 오픈소스 프로젝트이고, 현재 필자가 속해 있는 회사는 prometheus를 사용하여 쿠버네티스 환경에 동작하는 어플리케이션들의 메트릭을 수집하고 있다.

 

모니터링은 로깅과는 성격이 약간 다르다. 로깅은 어플리케이션 로직 내에서 발생하는 일들에 대한 것이라면, 모니터링은 response latency, RPM, 컨넥션 갯수와 같은 모니터링 지표들을 수집하여 저장하고 검색하는 것을 의미한다.

 

prometheus는 기본적으로 pull model을 사용해 메트릭을 수집한다. 이를 간단하게 설명하자면 메트릭 대상이 되는 타겟 서비스들이 HTTP endpoint를 expose하고 있고, 프로메테우스 서버에서 이 엔드포인트를 통해 메트릭을 scrape하는 구조다.

 

prometheus의 장점 중 하나는 매우 활성화된 커뮤니티 덕분에 이미 구현된 exporter들이 정말 많다는 점이다. exporter가 무엇인지 모른다면 이 글을 읽으면 된다. 또한 prometheus는 Go, Python, Ruby, Node.js, Java, .NET등 다양한 클라이언트 라이브러리를 제공하기 때문에 언어에 크게 제약없이 할 수 있다. 추가로 프로메테우스를 지원하는 시각화 툴들은 여러 가지가 있지만 대표적으로 가장 많이 사용되는게 Grafana다. (필자 회사에서는 뉴렐릭이랑 grafana를 같이 쓰고 있음)

 

자 그래서 본 글은 알고있겠지만 프로메테우스에 대해 정리한다. 블로그 글 하나 만으로 정리할 수 없을 만큼 방대한 양이기에 이번 시리즈에서는 다음만 다루려고 한다

 

(1) 프로메테우스의 기본 개념

(2) 프로메테우스의 메트릭 종류 및 설명

(호응이 좋다면 예제도 다룰 예정임)

 

그리고 본 글은 (1)인 프로메테우스를 이해하는데 필요한 기본 개념들에 대해 정리한다

 

메트릭이란?

메트릭은 특정 소프트웨어의 성능, 소비량, 생산성 등을 평가하는데 사용될 수 있는 값을 측정한다. 개발자는 메트릭을 활용해 CPU, memory 사용량, request duration 등과 같은 정보를 수집해 대쉬보드를 구성하거나 알림을 보낼 수 있다.

기본적으로 아래 세가지 정보로 구성된다

(1) 메트릭 이름

(2) 특정 메트릭이 측정된 타임스탬프

(3) 측정된 메트릭 값

 

간단하게 메트릭이 무엇인지에 대해 알아보았으니, 본격적으로 프로메테우스에 대해 알아보자!

 

프로메테우스 아키텍처

프로메테우스의 아키텍처를 도식화 하면 위와 같다. 프로메테우스의 메트릭 수집 대상은 다양하다. 동작하고 있는 웹서버일 수도 있고, 하드웨어 서버를 대상으로도 수집할 수 있다. 자주 등장하는 용어들만 몇 개 정리해보자.

 

prometheus server : 프로메테우스가 동작하고 있는 서버를 의미한다.

참고로 프로메테우스 서버는 싱글 호스트 아키텍처 구조 때문에, 이중화나 클러스트링 적용하기가 매우 까다롭다(이중화가 불가능한건 아니지만 비효율적). 따라서 주로 scale-up으로 리소스 이슈를 해결한다.

 

exporter : 메트릭 정보를 수집하는 모니터링 에이전트다. exporter를 실행하면 데이터를 수집하는 동시에 HTTP 엔드포인트를 열어서 prometheus 서버가 데이터를 수집해 갈 수 있도록 한다. 대표적인 exporter종류는 아래와 같다.

• node exporter : 하드웨어 상태와 커널 관련 메트릭을 수집하는 모니터링 에이전트
• {soultion-name}-exporter : 특정 솔루션 서버의 상태에 대한 메트릭을 수집하는 모니터링 에이전트
  • 예: mysql-exporter, postgres-exporter
• custom exporter : exporter가 기본적으로 제공되지 않는 웹 어플리케이션과 같은 경우, 클라이언트 라이브러리를 이용해 직접 metric을 만들고 수집하는 custom exporter를 구현한다.

push gateway : push gateway는 ephemeral한 특성을 가진 batch job 등도 메트릭 수집이 가능하도록 metric의 proxy역할을 하는 중재자다. 결국 push gateway도 exporter같은 느낌이다.

 

alert manager : 정해진 규칙에 따라 알람을 보내주는 역할을 한다. 문제가 발생했을 때 알림을 받을 규칙을 만들어서 alert manager에 보내면 알을 전송해준다.

 

service discovery : 프로메테우스는 풀링 방식으로 메트릭을 수집하기 때문에, 모니터링 대상이 가변적으로 변경될 경우 모니터링 대상의 IP 주소들을 알 수가 없다. 따라서 라벨을 통해 타겟 서버들을 관리한다. 예를 들어 새로운 exporter가 있을 때 DNS에 등록해두고 목록에 등록된 IP들을 대상으로 pulling하면 된다.

 

프로메테우스 동작 방식 및 주요 용어들

 

pulling 방식

pull 모델 예시

모니터링 시스템은 크게 두 가지 방식을 통해 메트릭을 수집한다. Graphite과 같이 모니터링 서비스는 타겟 클라이언트가 Graphite 서버에 메트릭을 push할 때 까지 기다리는 방식이 있고, 반대로 Prometheus와 같이 직접 클라이언트에게 요청을 날려 메트릭을 수집하는 pull 방식이 있다.

 

prometheus는 메트릭 수집 대상인 target system에서 메트릭을 수집할 때 pull 방식을 사용한다. pull 방식이란 프로메테우스가 직접 exporter들로부터 메트릭을 읽어와서 수집하는 방식을 의미한다. 타겟 서비스에서 열어두고 있는 /metrics 와 같은 metric endpoint에 HTTP요청을 보내 메트릭을 수집하는 것이다.

 

pulling 방식의 장점

 

(1) 클라이언트의 부하를 줄여줄 수 있다. 메트릭 서비스를 discover하고, 복잡한 연산을 하는등의 작업을 prometheus에게 전담하기 때문에 클라이언트가 좀 더 가볍게 동작 할 수 있다. push방식을 사용하는 다른 모니터링 서비스에서는 타겟 서버에 부하가 걸릴 경우 fail point가 될 수 있는데, pull 방식은 이에 비해 안전하다

(2) 여러개의 prometheus 인스턴스에서 메트릭을 수집할 수 있다.

(3) 서비스의 정상 동작여부를 쉽게 확인할 수 있다.

 

pulling 방식의 단점  

 

(1) pull 방식으로 메트릭을 수집하기 때문에, 장애 발생을 빠르게 감지하기 어렵다.

(2) pull 하는 순간의 메트릭 정보만 가지고 있기 때문에 근삿값만을 알 수 있다.

 

참고로 batch job같은 ephemeral한 특성을 가진 타겟 서비스들은 pull 방식이 당연히 적용하기 어렵기 때문에 push gateway에게 메트릭을 push해서 메트릭을 수집가능하게 할 수 있다.

 

Service Discovery

Service discovery란 메트릭을 수집할 대상의 endpoint를 찾는 방버을 의미한다. DNS나, 서비스 디스커버리 전용 솔루션인 Hashicorp사의 Consul 혹은 쿠버네티스를 통해서 모니터링해야 할 타겟 서비스의 목록을 불러올 수 있다. 쿠버네티스를 사용하는 경우를 예로 좀 들어보면 Kube API를 통하여 endpoint 변경사항을 자동으로 감지할 수 있다. 예를 들어 Pod가 2개에서 3개로 증가하면 직접 수동으로 설정해주지 않아도 자동으로 감지하는 것이다.

 

데이터 저장

프로메테우스에서 수집한 메트릭 정보들은 메모리와 로컬 디스크에 저장된다. 별도의 데이터베이스나 처리기를 사용하지 않고 로컬 디스크에 저장하기 때문에 설치가 매우 쉽지만, 스케일링이 불가능하다는 단점을 가지고 있다. 메트릭 수집 대상 서비스들이 늘어날 수록 저장공간이 많이 필요해질 경우 디스크를 늘리는 방법으로밖에 해결할 수 없다.

 

데이터 조회 (PromQL)

프로메테우스에 저장된 메트릭은 PromQL이라는 언어를 이용해서 조회할 수 있다.

예를 들어 아래와 같이 [host1.domain.com](http://host1.domain.com) 서버의 최근 10분간의 메모리 사용량 조회와 같은 쿼리를 날릴 수 있다. PromQL에 대한 내용은 추후 별도 포스팅에서 다루도록 하겠다.

avg_over_time(node_memory_used_bytes{hostname="host1.domain.com"}[10m])

 

메트릭

프로메테우스는 총 4종류의 메트릭 타입을 제공하고 있으며, client library를 사용해야지만 메트릭을 expose할 수 있다. 메트릭 종류와 상세한 설명은 다음 시리즈 글에서 다루도록 하겠다.

 

 

자 이렇게 프로메테우스에 대한 기본 내용을 다루어보았다. 이제 다음 글에서 본게임인 메트릭에 대해 알아보도록 하자

 

 

 

본 글은 아래 글들을 참고하여 재구성한 글임을 알려드립니다.

https://medium.com/devops-mojo/prometheus-overview-what-is-prometheus-introduction-92e064cff606

https://lob-dev.tistory.com/entry/Monitoring-01-프로메테우스를-이용하여-프로젝트-메트릭-수집하기

https://medium.com/finda-tech/prometheus란-cf52c9a8785f

https://www.timescale.com/blog/four-types-prometheus-metrics-to-collect/

https://owin2828.github.io/devlog/2020/03/13/etc-5.html