Prometheus 를 이용한 모니터링 — Part 1

7 min readSep 29, 2019

Kubernetes 환경에 들어오면서, 전체 인프라 환경과 Application 에 대한 모니터링을 하는 것이 매우 중요해졌다. 인프라에 대한 전체적인 가시성을 확보해야 Kubernetes 내에 돌아가는 Application 에 대한 가용성과 안정성을 확보할 수 있으며, 더 나아가 이러한 모니터링 결과를 통해 고도화된 Cloud Native 시스템을 구축할 때 사용하는 지표로 활용할 수 있다.

이번 글에서는 모니터링 아키텍쳐에 대한 간단한 Intro 와, Kubernetes 에서 가장 많이 사용되고 있는 Prometheus에 대해 알아보려고 한다.

Change of Monitoring Architecture

Legacy environment

기존 레거시 환경은 고사양의 서버에 application을 크게 운영하는 방식으로 운영되었다.
따라서, 고 사양의 서버에 Monitoring Agent를 서버에 설치 한 후, Agent 가 Os 의 메트릭을 수집하여 backend 에 직접 전송하는 방식을 사용하였다.

Cloud Native Environment

이에 반해, Cloud Native 환경에서는 Container 기반의 Application 을 작게 운영하고 필요할 때마다 확장, 파괴하는 방식을 선택한다.
동적으로 확장하는 서버에 agent를 일일이 설치 불가능하므로, kubernetes api를 통해 동적으로 확장된 서버 endpoint를 discovery 하는 방식으로 운영된다.
이후에 Monitoring backend에서 discovery 한 endpoint 를 통해 metric을 수집한다.

Kubernetes Monitoring Pipeline

Kubernetes 의 모니터링 파이프라인은 2가지로 나눌 수 있는데, Kubernetes 관련 구성 요소를 관리하는 Core Metric Pipeline과 Monitoring 으로 나눌 수 있다.

Core Metric Pipeline

Core Metric Pipeline 은 쿠버네티스 관련 구성 요소를 직접 관리하는 파이프라인이다.
kubelet, metrics-server, metric API 등등으로 구성되어 있으며, 쿠버네티스의 핵심 동작 요소에 대한 모니터링을 담당하고, 현재 상태가 Desired State가 되는 것을 모니터링한다.
Kubelet 에 저장된 cadvisor 를 통해 노드/포드/컨테이너의 사용량 정보를 수집하며, 동적으로 확장 된 노드에 관련된 정보도 같이 수집한다.
Kubelet 에 저장된 정보는 metric server가 수집하여 메모리에 저장한다. 이때, 메모리에 저장하기 때문에 짧은 기간의 데이터만 저장한다.
이렇게 저장된 정보는 Kubernetes Master Metric API를 통해 다른 시스템 component가 조회 가능하게 한다.

Monitoring Pipeline

이 그림에서 파란색으로 써져 있는 부분이 Monitoring Pipeline 이며, Monitoring Pipeline은 Kubernetes에서 제공하는 기본 메트릭 외에 다양한 메트릭을 수집한다. 특히, 클러스터 사용자들이 필요한 모니터링을 하는데 사용된다.
이 모니터링 파이프라인은 시스템 메트릭과 서비스 메트릭을 동시에 수집 가능도록 설계되었다.
쿠버네티스에서는 모니터링 파이프라인은 직접 관리하지 않기 때문에, 사용자가 직접 설치하여 Monitoring 파이프라인을 구축해야한다. 주로 cAdvisor + Heapster + InfluxDB조합이 가장 많이 쓰였으나, 프로젝트가 중단되어 현재는 cAdvisor + Prometheus 조합이 가장 많이 쓰인다.

Prometheus Overview

What is Prometheus?

Prometheus 는 현재 Kubernetes 상에서 가장 많이 사용하는 오픈 소스 기반 모니터링 시스템이다.
CNCF 에 소속되어 있으며, Kubernetes 클러스터 및 Docker 컨테이너들를 손쉽게 모니터링 가능하다.
간단한 텍스트 형식으로 메트릭을 쉽게 노출 가능하며, 데이터 모델은 key-value 형태로 레이블을 집계한 후 , Grafana같은 대시 보드 시스템에서 그래프로 쉽고 간단하게 Dashboard 를 만들 수 있다.
또한 이해하기 쉬운 PromQL 쿼리 언어를 사용하여 간단하게 경고와 Ruleset을 정의 가능하다.

Prometheus Architecture

대부분의 모니터링 도구가 Push 방식 즉, 각 서버에 클라이언트를 설치하고 이 클라이언트가 메트릭 데이터를 수집해서 서버로 보내면 서버가 모니터링 상태를 보여주는 방식을 취한다.

하지만 Prometheus는 Pull 방식을 사용하여, 서버에 클라이언트가 떠 있으면 서버가 주기적으로 클라이언트에 접속해서 데이터를 가져오는 방식을 취한다.

Service discovery : Prometheus는 기본적으로 모니터링 대상 목록을 유지하고 있으며, 대상에 대한 ip나 기타 접속 정보를 설정 파일에 주어서 모니터링 정보를 가져오는 방식을 사용한다.
이러한 환경을 대처하기 위해 서비스 디스커버리를 사용하지만, 오토스케일링을 하는 환경에서는 ip가 동적으로 변경되는 경우가 많기 때문에 , 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링하는 형태를 취한다. ex) kubelet
Push gateway : Pushgateway는 쉽게말해 Proxy Forwarding을 해서 접근할 수 없는 곳에 데이터가 존재하는 경우에 사용할 수 있는 대안이다. application 이 pushgateway 에 메트릭을 push한 후, prometheus server 가 pushgateway 에 접근해 metric 을 pull 해서 오는 방식으로 동작한다.
Exporter & job: Exporter 는 Prometheus 에게 메트릭을 가져가도록 특정 Service 에 metric 을 노출하게 하는 Agent 라고 이해하면 편하다.
Exporter 는 서버 상태를 나타내는 Node exporter , SQL Exporter 등 다양한 커스텀 exporter 이 개발되어 사용되고 있으며, 이러한 Exporter를 사용하여 metric 을 Prometheus 에 긁어가도록 할 수 있다.
Alert manager: Alert manager 는 metric 에 대한 어떠한 지표 를 걸어놓고 그 규칙을 위반하는 사항에 대해 알람을 전송하는 역할을 한다.
Data visualiztion: Data visualiztion은 다양한 모니터링 Dashboard 를 위한 visualization 을 제공한다. 주로 Prometheus 가 수집한 데이터에 대한 외부 시각화 툴 및 api를 제공하는 역할을 한다.

지금까지 기존의 모니터링 시스템과 Cloud native 환경의 모니터링이 어떻게 차이 나는지, Prometheus에 대한 간단한 개요 및 아키텍쳐에 대해 알아보았다.

다음 Part 2는 Prometheus 가 다른 모니터링 시스템에 비해 어떤 장점이 있는지, Prometheus 에서 가장 많이 사용하는 visualization Tool 인 Grafana에 대해 알아보려고 한다.