Prometheus / Grafana - 모니터링 구축 + 알림 구현
지난 시간에는 PMM 오픈소스를 사용해, DB와 호스트 서버를 모니터링 하는 시스템을 구축했다.
하지만 PMM 아키텍처를 확인해보면, PMM도 Prometheus와 Grafana를 활용하고 있음을 알 수 있었다.
(사실상 Prometheus와 Grafana가 모니터링 오픈소스의 표준인 듯한..)
이번 글의 목표는 다음과 같다.
- Prometheus 내부 구성 요소와 역할을 학습하고, 아키텍처를 이해한다.
- `docker-compose`를 활용해 Prometheus, Grafana, exporter를 설치하며, Prometheus 동작 방식을 이해한다.
- Grafana의 기본 내장 데이터베이스인 SQLite를 MySQL로 대체하는 과정을 소개한다.
- Prometheus와 Grafana 을 연동하고, GUI 대시보드 생성 방법을 간략히 살펴본다.
1. Prometheus 아키텍처
Prometheus는 메트릭 정보를 수집하여, 시스템을 모니터링하고 알림을 제공하는 솔루션이다.
Prometheus는 단순히 메트릭을 수집하고 저장하는 것을 넘어, 많은 기능들을 제공한다.
메트릭 수집을 담당하는 Exporter, 메트릭 데이터를 저장하는 TSDB, 알림 기능을 제공하는 Alertmanager, 그리고 PromQL 쿼리 언어를 사용해 메트릭 데이터의 분석을 가능하게 한다.
아래의 아키텍처를 보면서 내부 구성요소와 기능들에 대해 알아보도록 하자.
1. Prometheus Server
Prometheus 서버는 아키텍처의 중심에 위치하며, 모니터링 시스템의 핵심 역할을 한다.
1) Retrieval
Prometheus는 Pull 방식으로 데이터를 수집한다.
우선 수집하려는 대상 서버에 exporter를 설치하여 메트릭을 수집하는데, Prometheus Server의 Retrieval에서 모니터링 대상이 제공하는 HTTP 엔드포인트에 주기적으로 요청을 보내 데이터를 가져오는 것이다. (= scraping)
이러한 수집 주기와 rule 평가와 같은 설정들은 `prometheus.yml`에서 다음과 같이 정의할 수 있다.
# prometheus.yml
global:
scrape_interval: 15s # 메트릭 수집 주기
evaluation_interval: 15s # 알림 및 레코딩 규칙 평가 주기
scrape_timeout: 10s # 수집 타임아웃
2) TSDB (Time Series Database)
Promethes가 수집하는 메트릭 데이터는 시간에 따라 변경되는 시계열 데이터이다.
Prometheus는 이러한 시계열 데이터들을 자체적으로 내장한 시계열 데이터베이스인 TSDB에 저장한다.
TSDB는 시간에 지남에 따라 과거의 데이터는 압축하여 공간을 절약하고, 다음과 같은 옵션으로 데이터 보존 정책을 세울 수 있다.
- `retention time`: 저장된 메트릭 데이터는 지정된 기간동안 유지되어, 이후에는 자동으로 삭제된다.
- `retention size`: TSDB가 최대 보관 용량을 지정하여, 초과 시 오래된 데이터는 자동으로 삭제된다.
3) HTTP Server
Grafana와 같은 외부 시스템과의 통신을 처리하여, Prometheus에서 제공하는 API를 지원한다.
또한 알림 규칙에 따라 문제가 발생할 시, Alert Manager로 알림을 전송한다.
- `/metrics`: Prometheus 서버 자체의 메트릭 조회
- `/api/v1/targets`: Premetheus 서버가 현재 모니터링하고 있는 모든 타겟 조회
- `/api/v1/query`: PromQL 쿼리를 실행해 저장된 메트릭 조회
- `/api/v1/rules`: 알림 및 규칙 조회
2. Service Discovery
Service Discovery는 모니터링 대상을 동적으로 탐지하는 역할을 한다.
Kubernetes
- k8s 환경에서 pods, 서비스, 노드 등을 자동으로 탐지한다.
- k8s와 같은 분산 시스템이나 자동 확장 시스템에서는 정적인 엔드포인트가 없다.
이 경우 k8s API를 통해 클러스터 내의 리소스를 조회하여 모니터링 대상으로 설정한다.
File SD
- 정적 파일에 정의된 타겟 목록을 읽어 모니터링 대상으로 등록한다.
- 애플리케이션에서는 자체적으로 Prometheus 클라이언트 라이브러리를 사용해 노출한 /metrics 엔드포인트를 대상으로 사용할 수 있다.
3. Jobs / Exporters
모니터링 대상의 메트릭 데이터를 수집하고, Prometheus 서버가 Pull 받아갈 수 있도록 `/metrics` 엔드포인트에 노출시킨다.
4. Push Gateway, Short-lived Jobs
일회성이나 주기적으로 실행되는 단기 작업(ex. batch job)의 경우는 실행이 끝나면 종료되어, 기존의 Pull 방식으로의 수집이 어렵다.
이를 위해 중간 서버 역할을 하는 Push gateway를 두어, 단기 작업의 메트릭을 Pushgateway Push하여 저장하도록 한다. 그러면 Pushgateway는 `/metric` 엔드포인트를 노출함으로써, Prometheus 서버에서 모니터링 대상으로 설정해 데이터를 Pull 하여 메트릭을 수집할 수 있게 한다.
// Prometheus.yml
scrape_configs:
- job_name: 'pushgateway'
static_configs:
- targets: ['${host ip}:9091']
5. Alertmanager
Prometheus 서버에서 생성된 알림을 외부 시스템으로 전송한다.
Prometheus 서버는 설정된 알림 규칙에 따라 알림을 생성하는데, 이렇게 생성된 알림은 HTTP를 통해 Alertmanager로 전달된다. Alertmanager는 전달받은 알림을 중복 제거 / 그룹화 / 억제 / 라우팅하여 이메일, Slack과 같은 외부 시스템으로 전송한다.
- 중복 제거(Deduplication): 동일한 알림이 반복적으로 전송되지 않도록 관리
- 그룹화(Group): 관련된 알림을 그룹화
- 억제(Suppression): 심각도가 높은 알림이 발생하면 심각도가 낮은 알림 중단
- 라우팅(Routing): 심각도에 따라 적절한 채널로 알림 라우팅
2. Prometheus / Grafana 설치
Prometheus와 Grafana 구성을 간편하게 정의하고 관리할 수 있도록, docker-compose를 사용하여 설치를 진행했다.
MariaDB 사용자 생성 및 권한 부여
- 상태 테이블 조회, 실행 중인 스레드 정보 조회, 바이너리 로그 위치 정보 조회, 래플리케이션 관련 상태 정보 조회를 위한 권한 부여
- mysqld_exporter 컨테이너 IP에 따라 변경될 수 있다.
# exporter 사용자 정의
CREATE USER 'exporter'@'192.%.%.%' IDENTIFIED BY 'test_password';
GRANT SELECT, PROCESS, REPLICATION CLIENT, SLAVE MONITOR ON *.* TO 'exporter'@'192.%.%.%';
FLUSH PRIVILEGES;
1. 디렉토리 구조
project-root/
├── docker-compose.yml
├── prometheus/
│ ├── config/
│ │ └── prometheus.yml # Prometheus 설정 파일
│ └── volume/ # Prometheus가 메트릭 데이터를 저장하는 디렉토리 (자동 생성됨)
├── grafana/
└── data/ # Grafana 대시보드, 사용자 설정 저장 (자동 생성됨)
2. prometheus.yml
- Prometheus 설정 파일
- prometheus와 node exporter, mysqld exporter 타겟 모니터링
global:
scrape_interval: 15s # 메트릭 수집 주기
evaluation_interval: 15s # 알림 및 레코딩 규칙 평가 주기
scrape_timeout: 10s # 수집 타임아웃
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['prometheus:9090'] # Docker Compose 네트워크에서 서비스 이름으로 접근
- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter:9100']
- job_name: 'mysqld-exporter'
static_configs:
- targets: ['mysqld-exporter:9104']
3. docker-compose.yml
version: "3"
services:
prometheus:
image: prom/prometheus
restart: unless-stopped # docker stop으로 중단하지 않는 한 컨테이너가 항상 실행됨
ports:
- "9090:9090"
volumes:
- ./prometheus/config:/etc/prometheus # prometheus 설정 파일 디렉토리 마운트
- ./prometheus/volume:/prometheus # prometheus에서 수집한 메트릭 데이터 저장 경로 마운트
command:
- "--config.file=/etc/prometheus/prometheus.yml" # 설정 파일 경로
- "--storage.tsdb.path=/prometheus" # 메트릭 데이터 저장 경로
- "--storage.tsdb.retention.time=90d" # 데이터 보관 기간: 90일
- "--storage.tsdb.retention.size=10GB" # 최대 저장 용량: 10GB
- "--web.enable-lifecycle" # API로 설정 변경 반영 가능 (`/-/reload`)
grafana:
image: grafana/grafana
restart: unless-stopped
ports:
- 3000:3000
depends_on:
- prometheus # grafana 컨테이너를 실행하기 전에 prometheus가 먼저 실행되도록 설정.
volumes:
- ./grafana/data:/var/lib/grafana # grafana 대시보드 설정, 사용자 설정 등의 저장 경로 마운트
environment:
- GF_SECURITY_ADMIN_USER=admin # 관리자 로그인 정보
- GF_SECURITY_ADMIN_PASSWORD=admin
node-exporter:
image: prom/node-exporter
restart: unless-stopped
ports:
- "9100:9100"
pid: host # 호스트의 PID 네임스페이스를 공유하여, 컨테이너 안에서 호스트의 프로세스를 조회할 수 있도록 함
volumes: # 호스트의 /proc, /sys, / 디렉토리를 컨테이너 안에서 읽기 전용으로 마운트
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
command: # 호스트 시스템 메트릭을 수집하도록 마운트 한 디렉토리로 수집 경로 지정
- "--path.procfs=/host/proc"
- "--path.sysfs=/host/sys"
- "--path.rootfs=/rootfs"
mysqld-exporter:
image: prom/mysqld-exporter
restart: unless-stopped
command:
- "--mysqld.username=exporter:test_password"
- "--mysqld.address={host_ip}:3306"
4. alertmanager.yml
global:
resolve_timeout: 1m
route:
receiver: 'slack-notifications'
receivers:
- name: 'slack-notifications'
slack_configs:
- api_url: ""
channel: ""
text: "{{ .CommonAnnotations.summary }}"
5. 디렉토리 권한 부여
- Prometheus 컨테이너에서 수집되는 메트릭 데이터는 호스트의 `./prometheus/volume`에 저장된다.
- 마찬가지로 Grafana 컨테이너의 대시보드, 설정 정보는 `./grafana/data`에 저장된다.
- 따라서 각 컨테이너가 해당 디렉토리에 접근해서 데이터를 write 할 수 있도록, 디렉토리의 소유자를 각각 Prometheus와 Grafana User ID로 설정해주어야 한다.
sudo chown -R 65534:65534 ./prometheus/volumesudo chown -R 472:472 ./grafana/data
3. Grafana 데이터베이스 변경 (SQLite → MySQL)
Grafana 컨테이너를 띄우는 중, 정상적으로 실행이 되지 않아 로그를 분석해보니 다음과 같은 Database locked 에러를 마주했다.
Database locked, sleeping then retrying
error="[sqlstore.max-retries-reached] retry 1: database is locked"
우선 Grafana는 기본으로 내장된 데이터베이스는 SQLite를 사용한다.
즉, Grafana가 SQLite(= grafana.db)에 접근하려고 하는데, 다른 프로세스가 이미 잠금을 걸고 있어 접근하지 못하는 상태인 것이다. 이와 관련해서 리서치를 해보니 여러 커뮤니티에서 논의된 주제로, 2019년에 grafana 프로젝트 이슈로도 등록이 됐지만 아직 닫히지 않고 있었다.
(Grafana의 문제보다는 SQLite의 동시성 문제라 그럴 수 있을 것 같다.)
이슈의 여러 댓글에서 SQLite에서의 동시성 성능을 개선하기 위한 옵션으로도 해결이 가능한 것으로 보이지만, 이를 적용시켰음에도 여전히 문제가 발생하여 많은 질의가 이루어지고 있음을 확인할 수 있었다.
[database]
type=sqlite3
connection_string=file:data/grafana.db?cache=private&mode=rwc&_journal_mode=WAL
sudo sqlite3 /var/lib/grafana/grafana.db 'pragma journal_mode=wal;'
이런 문제를 피하고자 Grafana의 내장 데이터베이스를 SQLite에서 MySQL로 대체하는 방향으로 진행했다.
문제 해결은 간단하다.
MySQL 인스턴스에 grafana 데이터베이스를 생성하고, Grafana 컨테이너가 접근할 수 있도록 사용자에게 해당 데이터베이스에 대한 권한을 열어주면 된다.
# grafana_db 사용자 정의
CREATE USER 'grafana_db'@'192.%.%.%' IDENTIFIED BY 'test_password';
GRANT ALL PRIVILEGES ON grafana.* TO 'grafana_db'@'192.%.%.%';
그리고 `docker-compose.yml`에서 Grafana 컨테이너를 실행할 때, 기존의 Grafana SQLite 데이터베이스와 연결된 마운트 볼륨 설정을 더 이상 필요하지 않고, 아래와 같이 데이터베이스 type, host, name, user, password를 추가하면 된다.
(cf. Grafana 컨테이너 내의 `/etc/grafana/grafana.ini` 에서 데이터베이스 설정을 할 수 있지만, `docker-compose`로 컨테이너를 간편하게 관리하기 위해 환경변수를 통해 설정했다.)
grafana:
image: grafana/grafana
restart: unless-stopped
ports:
- "3000:3000"
depends_on:
- prometheus # Grafana 실행 전에 Prometheus가 먼저 실행되도록 함
environment:
- GF_DATABASE_TYPE=mysql
- GF_DATABASE_HOST={host_ip}:3306
- GF_DATABASE_NAME=grafana
- GF_DATABASE_USER=grafana_db
- GF_DATABASE_PASSWORD=test_password
- GF_SECURITY_ADMIN_USER=admin
- GF_SECURITY_ADMIN_PASSWORD=admin
4. Prometheus - Grafana 연동
이렇게 `docker-compose.yml`을 통해서 Prometheus와 Grafana, 그리고 필요한 exporter를 설치하면
`http://{host ip}:9090/targets`에서 Prometheus Server가 현재 모니터링 대상으로 지정한 타겟들이 정상적으로 실행되고 있는지 상태를 파악할 수 있다. 이 때, 표시되는 UP/DOWN 상태는 "target의 엔드포인트가 활성화 여부, 즉 Prometheus 서버가 해당 target에 HTTP로 접근 가능한지"만 판단하고 타겟이 내부에서 메트릭을 정상적으로 수집하는지는 반영되지 않는다.
타겟이 메트릭이 정상적으로 수집하는지 알기 위해서는 실행된 도커 컨테이너의 로그를 조회하거나, Prometheus 또는 Grafana에서 메트릭의 존재 여부를 모니터링 하는 방법을 사용할 수 있다.
Grafana는 `http://{host ip}:3000`에서 설정한 관리자 계정으로 로그인 시, 초기 화면을 확인할 수 있다.
그리고 Connections/Data source > Prometheus 커넥션을 추가하면 된다.
추가한 Data source에 대한 대시보드 양식을 정할 수 있는데,
https://grafana.com/grafana/dashboards/ 에서 원하는 대시보드 템플릿을 찾아 URL이나 ID로 추가할 수 있다.
참고로 각 exporter 별로 대시보드를 만들어야 하며, 아래 대시보드 템플릿으로 진행했다.
- node exporter: https://grafana.com/grafana/dashboards/1860-node-exporter-full/
- mysqld exporter: https://grafana.com/grafana/dashboards/14057-mysql/
5. Prometheus 알림 구현
알림 기능을 구현하기 전, Prometheus에서 어떤 시점에 알림이 전송되는지 정확히 이해하기 위해서는 Alert state에 대해 먼저 알고 넘어가면 좋다. Prometheus에서는 Alert Rule의 평가 결과에 따라 알림을 크게 세 가지 상태로 관리하고 있다.
Alert State
- Inactive: 알림이 없는 상태, 시스템이 정상적으로 동작 중이다.
- Pending: 알림이 발생한 상태, 기본 알림 조건이 충족되었지만 `for` 기간동안 대기 중인 상태를 의미한다.
- Firing: 알림이 활성화 된 상태, Prometheus가 Alertmanager로 알림을 전송한다.
Resolved- Prometheus 내부 상태는 아니며, Alertmanager에서 알림이 해결된 상태를 나타내는 용도로 사용된다.
1. 디렉토리 구조
- Alertmanager가 추가된 디렉토리 구조는 다음과 같아진다.
- metric 수집 데이터에 대한 alert 규칙을 정의하는 `rules.yml`
- 수신받은 alert를 외부로 보내기 위한 설정이 담겨져 있는 `alertmanager.yml`이 추가됐다.
project-root/
├── docker-compose.yml
├── prometheus/
│ ├── config/
│ │ └── prometheus.yml # Prometheus 설정 파일
│ │ └── rules/ # alert rule 디렉토리
│ │ │ └── rules.yml
│ └── volume/ # Prometheus가 메트릭 데이터를 저장하는 디렉토리 (자동 생성됨)
├── grafana/
│ └── data/ # Grafana 대시보드, 사용자 설정 저장 (자동 생성됨)
├── alertmanager/
│ ├── config/
│ │ └── alertmanager.yml # Alertmanager 설정 파일
│ └── volume/ # Alertmanager 내부 데이터 저장 디렉토리 (자동 생성됨)
2. docker-compose.yml
- Alertmanager는 Prometheus 서버와 독립적으로 실행되기 때문에, 별도로 설치를 진행해주어야 한다.
- `./alertmanager/volume`: 알림 상태가 저장되어, 도커 up/down 시 `group_interval`, `repeat_interval`에 영향을 미쳐 알림이 외부로 전송이 안 될 수도 있으므로, 테스트 환경에서는 마운트하지 않도록 한다.
- `--log.level=debug`: 내부적으로 alert가 receive / flush / send 되는 로그가 모두 debug 레벨로 찍히기 때문에, 테스트 환경에서는 debug 레벨로 실행시켜주는 것이 좋다.
alertmanager:
image: prom/alertmanager
restart: unless-stopped
ports:
- "9093:9093"
volumes:
- ./alertmanager/config:/etc/alertmanager # alertmanager.yml 디렉토리 마운트
- ./alertmanager/volume:/alertmanager # alertmanager 내부 데이터 저장 디렉토리 마운트
command:
- '--config.file=/etc/alertmanager/alertmanager.yml' # 설정 파일 경로
- '--storage.path=/alertmanager'
- '--log.level=debug'
3. alertmanager.yml
- Alertmanager의 설정 파일로, 외부 수신 채널(Slack, Email 등) 정의 및 알림 전송 규칙을 설정하는 데 사용된다.
- `resolve_timeout`: 이 옵션은 다소 특이한 설정이다. 참고했던 여러 블로그에서 자주 등장하지만, 공식문서를 찾아보니 다음과 같이 설명되어 있다. "해당 값은 알림에 `EndsAt`값이 없을 때 사용된다. 그러나 Prometheus에서 전송되는 알림에는 항상 `EndsAt` 값이 포함되어 있기 때문에, 이 설정은 Prometheus에서 발생한 알림에 대해선 영향을 주지 않는다." 이에 따르면, Prometheus가 아닌 외부 시스템에서 알림을 전송하는 경우에만 의미를 가질 수 있는 설정으로 보인다.
- `group_wait`: 새로운 알림이 도착하면 Aleartmanager는 새로운 그룹을 생성하고, 이 그룹의 첫 번째 알림 전송을 `group_wait` 동안 지연시킨다. 이 대기 시간동안 같은 그룹에 포함되는 추가 알림이 발생하면 묶어서 한 번에 전송한다.
- `group_interval`: 동일한 그룹에서 이미 알림이 한 번 전송된 후, 추가로 새로운 알림이 발생했을 경우, 지정된 group_interval 시간이 지나야 다시 전송된다. 즉, 그룹 간 전송 간격을 조절하는 설정으로 보면 된다.
- `repeat_interval`: 동일한 알림이 여전히 active 상태일 경우, 이미 전송한 알림이라도 repeat_interval 시간 이후 다시 전송된다.
- Prometheus Alertmanager 명령어 옵션에 대한 자세한 설명은 아래 공식문서에서 확인할 수 있다.
global:
resolve_timeout: 5m # 경고 알림이 더 이상 업데이트 되지 않을 경우, 자동으로 resolved 상태로 변환
slack_api_url: '---'
route:
receiver: 'slack-notifications'
group_wait: 10s # 10초 기다린 후 알림 전송
repeat_interval: 1h # 동일한 알림이 계속 존재하는 경우, 1시간마다 반복 전송
receivers:
- name: 'slack-notifications'
slack_configs:
- channel: '#monitoring-alert'
username: 'Prometheus'
send_resolved: true
title: '{{ range .Alerts }}{{ .Annotations.summary }} ({{ .Labels.severity }}){{ "\n" }}{{ end }}'
text: '{{ range .Alerts }}{{ .Annotations.description }}{{ "\n" }}{{ end }}'
3. prometheus.yml
- Prometheus 서버가 알림을 전송할 Alertmanager 인스턴스의 주소를 지정한다.
- docker compose 환경에서는 `alertmanager` 컨테이너 이름이 호스트 url로 사용된다.
- 그리고 Alert Rule이 작성된 설정 파일을 불러올 수 있도록 경로를 정의한다.
alerting:
alertmanagers:
- static_configs:
- targets:
- 'alertmanager:9093' # Alertmanager 주소
rule_files:
- "rules/*.yml" # 알림 및 레코딩 규칙 파일 경로 지정
4. os-rules.yml / mysql-rules.yml
- Alert rule을 정의하는 설정 파일이다.
- 아래 예시에서는 서버와 데이터베이스 관련 alert rule을 각각의 파일로 분리하여 정의했다.
- 각 alert rule에는 조건을 정의하는 PromQL과, 알림 메시지로 사용될 summary 및 description이 포함된다.
- `{{ $labels.job }}`: Prometheus가 수집한 대상의 job 라벨 (job_name)
- `{{ $labels.instance }}`: Prometheus가 수집한 대상의 주소, (targets)
# prometheus.yml
scrape_configs:
- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter:9100']# os-rules.yml
groups:
- name: os.rules
rules:
- alert: NodeDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "{{ $labels.job }} 다운 "
description: "{{ $labels.job }}가 1분 이상 응답하지 않고 있습니다."
- alert: HighCPUUsage
expr: (avg by (instance) (rate(node_cpu_seconds_total{mode="user"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.job }} CPU 사용률 경고"
description: "{{ $labels.job }} CPU 사용률이 80%를 초과한 상태가 5분 이상 지속되고 있습니다."
- alert: HighMemoryUsage
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.job }} 메모리 사용률 경고"
description: "{{ $labels.job }} 메모리 사용률이 80%를 초과한 상태가 5분 이상 지속되고 있습니다."# mysql-rules.yml
groups:
- name: mysql.rules
rules:
- alert: MySQLInstanceDown
expr: mysql_up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "{{ $labels.job }} 서버 다운"
description: "{{ $labels.job }}가 1분 이상 응답하지 않고 있습니다."
- alert: MySQLHighConnectionCount
expr: (mysql_global_status_threads_connected / mysql_global_variables_max_connections) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.job }} 커넥션 사용률 경고"
description: "{{ $labels.job }} 커넥션 사용률이 80%를 초과한 상태가 5분 이상 지속되고 있습니다."
- alert: MySQLSlowQueries
expr: rate(mysql_global_status_slow_queries[5m]) > 10
for: 5m
labels:
severity: warning
annotations:
summary: "{{ $labels.job }} 슬로우 쿼리 경고"
description: "{{ $labels.job }} 평균 초당 슬로우 쿼리 수가 10건을 초과한 상태가 5분 이상 지속되고 있습니다."
- Alert 구현 확인
먼저 Prometheus 서버의 엔드포인트인 `http://localhost:9090/alerts`에서, 앞서 정의한 각 Alert Rule의 상태를 확인할 수 있다.
또한, Grafana 대시보드에서도 Alert Rule을 확인할 수 있다.
아래 스크린샷에서는 두 종류의 Alert Rule이 표시되는 것을 확인할 수 있다:
- Grafana-managed:
Grafana 자체에서 생성한 Alert Rule로, Grafana Alerting이 관리한다.
(예: Grafana의 GUI를 통해 직접 생성한 알람) - Data source-managed:
Prometheus에서 정의된 Alert Rule을 Grafana가 가져와서 시각화하는 형태이다.
실제 알람은 Prometheus → Alertmanager를 통해 전송된다.
비교를 위해 Grafana GUI 대시보드에서 Alert rule을 생성하여 진행했다.
Grafana GUI 대시보드에서 Alert rule을 만드는 방법은 앞선 PMM 포스팅에서 확인할 수 있다.
참고 문서
Prometheus 아키텍처 이해
- https://prometheus.io/docs/introduction/overview/
- https://devopscube.com/prometheus-architecture/
- https://badcandy.github.io/2018/12/25/prometheus-architecture/
Prometheus AlertManager vs. Grafana AlertManager
- https://alexandre-vazquez.com/grafana-alerting-vs-alert-manager/
- https://www.reddit.com/r/sre/comments/1e7s779/prometheus_alertmanager_vs_grafana_alertmanager/
Prometheus AlertManager
- https://blog.naver.com/alice_k106/221910045964
- https://blog.omoknooni.me/115
Grafana AlertManager
- https://grafana.com/docs/grafana/latest/alerting/
Prometheus DB 성능 비교 (OpenTelemetry, VictoriaMetrics)
- https://victoriametrics.com/blog/opentelemetry-prometheus-and-more/
- https://last9.io/blog/prometheus-vs-victoriametrics/