[Prometheus] 왜 다들 프로메테우스를 사용할까

Kubernetes나 클라우드 환경에서 모니터링을 이야기하면 Prometheus라는 이름이 자주 나온다. Grafana 대시보드, Alertmanager 알림, Datadog 연동, OpenMetrics 같은 이야기를 하다 보면 거의 자연스럽게 Prometheus로 이어진다.

아키텍처 그림을 보다 보면 불꽃 모양의 주황색 Prometheus 로고를 만날 때가 있다. 그 로고가 있다면 보통 “여기서 metric을 모으고 있다”는 뜻으로 보면 된다.

처음 듣는 사람 입장에서는 조금 낯설 수 있다. 모니터링 도구는 이미 많은데, 왜 다들 Prometheus를 이야기할까? 이 글은 그 질문에 대한 가벼운 첫 번째 정리다.

Prometheus를 한 줄로 말하면

Prometheus는 서버, 애플리케이션, Kubernetes 같은 시스템에서 숫자 지표를 주기적으로 수집해서 저장하는 모니터링 시스템이다.

여기서 말하는 숫자 지표는 이런 것들이다.

• CPU 사용률
• 메모리 사용량
• HTTP 요청 수
• 에러 수
• 응답 시간
• 디스크 사용량

쉽게 말하면 Prometheus는 시스템 상태를 계속 숫자로 기록하는 도구다. 그리고 그 숫자를 시간 순서대로 쌓아두기 때문에, 나중에 그래프로 보거나 알림 조건으로 사용할 수 있다.

그림으로 보면 이런 구조다

아래 그림처럼 Prometheus는 애플리케이션이나 Exporter가 열어둔 /metrics endpoint에서 지표를 가져간다. 그리고 그 데이터를 Grafana 대시보드나 Alertmanager 알림에서 사용한다.

핵심은 Prometheus가 데이터를 기다리는 것이 아니라, 직접 가지러 간다는 점이다. 이 방식을 보통 Pull 방식이라고 부른다.

Prometheus는 왜 직접 가지러 갈까?

Prometheus는 보통 모니터링 대상의 /metrics 주소로 직접 접근해서 지표를 가져온다. 예를 들어 어떤 애플리케이션이 이런 endpoint를 열어둔다고 생각하면 된다.

http://my-service:8080/metrics

Prometheus는 정해진 시간마다 이 주소를 호출하고, 응답으로 받은 숫자들을 저장한다. 대상이 죽었거나 응답하지 않으면 수집 실패로 남는다. 그래서 Prometheus 입장에서는 어떤 대상이 살아 있는지, 지표를 정상적으로 가져왔는지도 함께 알 수 있다.

이 방식은 Kubernetes와 잘 맞는다. Kubernetes에서는 Pod가 계속 생기고 사라진다. 오늘 있던 Pod가 내일은 없을 수 있고, 장애가 나면 새로운 Pod가 자동으로 뜬다. 이런 환경에서는 모니터링 대상을 사람이 하나씩 관리하기 어렵다.

Prometheus는 Kubernetes API를 통해 모니터링할 대상을 찾고, 조건에 맞는 대상의 metric을 가져갈 수 있다. 그래서 동적으로 변하는 클러스터 환경에서 많이 쓰이게 되었다.

Exporter는 번역기 같은 역할을 한다

Prometheus가 널리 쓰이게 된 또 다른 이유는 Exporter 생태계다. Exporter는 어떤 시스템의 상태를 Prometheus가 이해할 수 있는 metric 형식으로 바꿔주는 도구다.

비유하자면 Exporter는 번역기와 비슷하다. Linux 서버, MySQL, Redis, Kubernetes 같은 시스템은 각자 상태를 표현하는 방식이 다르다. Exporter는 이 상태를 Prometheus가 읽을 수 있는 형식으로 바꿔서 /metrics로 보여준다.

대상	자주 쓰는 Exporter
Linux 서버	Node Exporter
Kubernetes 리소스	kube-state-metrics
컨테이너 리소스	cAdvisor
JVM 애플리케이션	JMX Exporter

이런 Exporter들이 많아지면서 Prometheus는 여러 시스템의 metric을 같은 방식으로 수집할 수 있게 되었다. 운영자 입장에서는 도구마다 다른 방식으로 지표를 보는 대신, Prometheus와 PromQL이라는 공통 방식으로 접근할 수 있다.

Prometheus의 진짜 핵심은 Label이다

Prometheus를 처음 보면 metric 이름이 먼저 보인다. 예를 들면 이런 이름이다.

http_requests_total
container_cpu_usage_seconds_total
node_filesystem_avail_bytes

하지만 Prometheus에서 정말 중요한 것은 Label이다. Label은 같은 metric을 여러 관점으로 나눠볼 수 있게 해준다.

http_requests_total{
  service="payment",
  method="GET",
  status="200"
}

위 metric은 결제 서비스의 GET 요청 중 HTTP 200 응답 수를 의미한다. Label이 있기 때문에 서비스별, 메서드별, 상태 코드별로 데이터를 나눠볼 수 있다. Grafana에서 필터를 걸거나, 특정 서비스의 에러율만 보는 것도 대부분 Label 덕분이다.

여기까지 보면 Label은 아주 좋은 기능처럼 보인다. 실제로도 그렇다. Prometheus가 강력한 이유 중 하나가 바로 Label이다.

하지만 이 시리즈에서 앞으로 다룰 문제도 여기서 시작된다. Label을 잘못 붙이면 Prometheus가 저장해야 하는 데이터가 폭발적으로 늘어날 수 있다. 그리고 이 문제는 성능 문제뿐 아니라 Datadog 같은 외부 Observability 도구의 비용 문제로도 이어질 수 있다.

정리

• Prometheus는 시스템의 숫자 지표를 수집하고 저장하는 모니터링 시스템이다.
• Pull 방식으로 /metrics endpoint에서 지표를 가져간다.
• Kubernetes처럼 Pod가 계속 바뀌는 환경과 잘 맞는다.
• Exporter는 여러 시스템의 상태를 Prometheus metric 형식으로 바꿔준다.
• Prometheus의 핵심은 Label이며, 다음 글부터는 이 Label이 만드는 문제를 다룬다.

다음 글

다음 글에서는 Prometheus의 Label이 왜 중요한지, 그리고 Label 하나가 어떻게 시스템을 느리게 만들 수 있는지 정리해보겠다. 특히 user_id, request_id, pod_name 같은 값이 왜 조심해야 하는 Label인지 다룰 예정이다.

• 2편: Prometheus Label 하나가 시스템을 느리게 만드는 이유
• 3편: Prometheus Cardinality 줄이는 방법
• 4편: Datadog에서 Label이 비용이 되는 순간

참고

• Prometheus Overview
• Prometheus Data model