Production 서버 운영에서 가장 중요한 것은 장애를 빠르게 발견하고 대응하는 것입니다.
하지만 관리자가 항상 서버 상태를 확인할 수는 없습니다.
기존 방식:
서버 이상 발생
↓
관리자가 직접 확인
↓
문제 해결
문제:
- 장애 발견 지연
- 서비스 영향 증가
- 대응 시간 증가
Monitoring 시스템에서는 문제가 발생하면 자동으로 알려주는 Alert 기능이 필요합니다.
구조:
Server
↓
Prometheus
↓
Alertmanager
↓
Slack / Email / Webhook
Alertmanager는 Prometheus에서 발생한 Alert를 받아 관리자에게 전달하는 역할을 담당합니다.
이번 글에서는 Docker Compose 환경에서 Alertmanager 구성부터 Prometheus 연결, Alert Rule 작성, Slack·Email 알림 설정, Production 장애 대응 구조까지 알아보겠습니다.
Alertmanager란 무엇인가?
Alertmanager는 Prometheus Alert를 관리하는 알림 시스템입니다.
역할:
- Alert 수신
- Alert 그룹화
- 중복 제거
- 알림 전달
- 장애 관리
기본 구조:
Prometheus
↓
Alertmanager
↓
Notification Channel
Monitoring과 Alert의 차이
Monitoring:
현재 상태 확인
예:
CPU 85%
Memory 70%
Alert:
문제 발생 알림
예:
CPU 95% 이상
↓
Slack 알림
Docker Compose Alertmanager 구조
전체 구조:
Container
↓
Exporter
↓
Prometheus
↓
Alertmanager
↓
관리자
구성 요소:
Prometheus:
Metrics 수집
Alert Rule:
조건 판단
Alertmanager:
알림 전달
Docker Compose Alertmanager 설치
docker-compose.yml:
services:
alertmanager:
image: prom/alertmanager
container_name: alertmanager
ports:
- "9093:9093"
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
실행:
docker compose up -d
확인:
docker ps
결과:
alertmanager running
Alertmanager 설정 파일 구성
alertmanager.yml:
global:
resolve_timeout: 5m
route:
receiver: default
receivers:
- name: default
기본 구조:
Alert 발생
↓
Route
↓
Receiver
↓
알림 전송
Prometheus와 Alertmanager 연결
prometheus.yml:
alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager:9093
구조:
Prometheus
↓
Alertmanager
Alert Rule 작성 방법
Alert 조건을 정의해야 합니다.
예:
CPU 사용량 증가:
groups:
- name: server-alert
rules:
- alert: HighCPUUsage
expr: cpu_usage > 90
for: 5m
의미:
CPU 90% 이상
↓
5분 유지
↓
Alert 발생
Docker Compose CPU 장애 알림 구성
상황:
CPU 95%
흐름:
Node Exporter
↓
Prometheus
↓
Alert Rule 확인
↓
Alertmanager
↓
Slack 알림
Memory 부족 Alert 구성
Memory 부족은 Container 장애의 주요 원인입니다.
조건:
Memory 사용률 90%
동작:
Memory 증가
↓
Alert 발생
↓
관리자 확인
Container Down Alert 구성
Container 장애 감지:
상태:
Container 종료
흐름:
Docker
↓
Exporter
↓
Prometheus
↓
Alertmanager
알림:
Container Down
Docker Compose Disk 부족 Alert
Disk 부족도 중요한 장애 원인입니다.
예:
Disk 사용률 95%
문제:
- Log 저장 실패
- Database 오류
- Container 중단
Alert:
Disk Warning
Slack 알림 연결
운영 환경에서는 Slack 알림을 많이 사용합니다.
구조:
Alertmanager
↓
Slack Webhook
↓
운영 채널
설정 예:
receivers:
- name: slack
slack_configs:
- api_url: WEBHOOK_URL
결과:
CPU Warning 발생
↓
Slack 메시지 전달
Email 알림 구성
Email도 사용할 수 있습니다.
구조:
Alertmanager
↓
SMTP
↓
Email
활용:
- 긴급 장애
- 보안 이벤트
- 서비스 중단
Webhook 알림 구성
외부 시스템과 연결할 수 있습니다.
예:
Alertmanager
↓
Webhook
↓
자동 복구 시스템
활용:
- 자동 Restart
- Ticket 생성
- Incident 관리
Alert 그룹화 기능
같은 장애가 반복되면 알림이 너무 많이 발생할 수 있습니다.
Alertmanager:
100개 Alert
↓
1개 그룹 알림
장점:
- 알림 피로 감소
- 중요한 장애 집중
Alertmanager Silence 기능
점검 시간에는 Alert를 잠시 중지할 수 있습니다.
예:
서버 업데이트
↓
예상 장애
↓
Alert Silence
불필요한 알림을 방지합니다.
Docker Compose Production Alert 구조
실제 운영:
Application
↓
Exporter
↓
Prometheus
↓
Alertmanager
↓
Slack
↓
Engineer
장애 대응 자동화 구조
발전된 구조:
Alert 발생
↓
Alertmanager
↓
Webhook
↓
Automation Script
↓
복구 작업
예:
Container Down
↓
docker restart 실행
Docker Compose Alertmanager Best Practice
추천:
- 중요 Alert만 설정
- Alert Threshold 조정
- Slack 연동
- Email 백업
- 장애 테스트 진행
- Alert 기록 관리
운영 흐름:
Metrics 수집
↓
이상 감지
↓
Alert 발생
↓
알림 전달
↓
장애 대응
자주 묻는 질문
Alertmanager는 Prometheus와 같이 사용해야 하나요?
일반적으로 Prometheus와 함께 사용합니다.
모든 문제가 Alert로 만들어야 하나요?
아닙니다.
서비스 영향이 있는 중요한 이벤트 중심으로 설정하는 것이 좋습니다.
Alert와 Log는 다른가요?
Alert는 문제 알림, Log는 문제 분석을 위한 기록입니다.
작은 서버에서도 필요한가요?
CPU, Memory, Disk 같은 기본 Alert부터 적용하면 효과적입니다.
마무리
Docker Compose Alertmanager 구성은 장애를 빠르게 발견하고 대응하기 위한 핵심 운영 기술입니다.
최종 구조:
Container
↓
Metrics
↓
Prometheus
↓
Alertmanager
↓
Notification
↓
장애 대응
Monitoring은 상태를 보여주는 역할이라면 Alertmanager는 문제가 발생했을 때 즉시 알려주는 운영 자동화 시스템입니다.
다음 글에서는 Container와 Application 로그를 중앙에서 관리하는 Docker Compose Loki Logging 시스템 구축 방법을 알아보겠습니다.