Monitoring
모니터링
시스템 상태 실시간 관찰. Prometheus, Grafana, Datadog.
모니터링
시스템 상태 실시간 관찰. Prometheus, Grafana, Datadog.
Monitoring(모니터링)은 시스템, 애플리케이션, 인프라의 상태와 성능을 지속적으로 수집, 분석, 시각화하는 활동입니다. 모니터링의 핵심 목표는 문제를 사전에 감지하고, 장애 발생 시 빠르게 대응하며, 시스템 건강 상태를 파악하는 것입니다.
모니터링은 크게 인프라 모니터링과 애플리케이션 모니터링으로 나뉩니다. 인프라 모니터링은 CPU, 메모리, 디스크, 네트워크 같은 시스템 리소스를 추적합니다. 애플리케이션 모니터링(APM)은 요청 처리 시간, 오류율, 처리량 같은 비즈니스 메트릭을 추적합니다.
메트릭은 시계열 데이터로 저장되며, 시간에 따른 변화를 분석합니다. 핵심 메트릭으로는 RED 메서드(Rate, Errors, Duration)와 USE 메서드(Utilization, Saturation, Errors)가 있습니다. 서비스 품질을 정의하는 SLI(Service Level Indicators)를 측정하고, 목표치 SLO(Service Level Objectives)와 비교하여 서비스 건강도를 판단합니다.
대표적인 모니터링 도구로는 오픈소스 Prometheus+Grafana 스택과 상용 서비스인 Datadog, New Relic, Dynatrace가 있습니다. Prometheus는 Pull 방식으로 메트릭을 수집하고 PromQL로 쿼리하며, Grafana에서 대시보드를 구성합니다. Alertmanager와 연동하여 임계치 기반 알림을 설정합니다.
# prometheus.yml - Prometheus 설정
global:
scrape_interval: 15s # 메트릭 수집 주기
evaluation_interval: 15s # 알림 규칙 평가 주기
alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']
rule_files:
- "alerts/*.yml"
scrape_configs:
# Prometheus 자체 모니터링
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# Kubernetes Pod 자동 발견
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
# prometheus.io/scrape: "true" 어노테이션이 있는 Pod만
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
# 커스텀 경로 지원
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
# 포트 지정
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
# alerts/api-alerts.yml - 알림 규칙
groups:
- name: api-alerts
rules:
# 높은 에러율 감지
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)
> 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate on {{ $labels.service }}"
description: "Error rate is {{ $value | humanizePercentage }}"
# 느린 응답 시간
- alert: HighLatency
expr: |
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
) > 1
for: 10m
labels:
severity: warning
annotations:
summary: "P95 latency above 1s on {{ $labels.service }}"
# Pod 메모리 사용량
- alert: PodHighMemory
expr: |
container_memory_working_set_bytes / container_spec_memory_limit_bytes > 0.9
for: 15m
labels:
severity: warning
SRE: "주말에 알림이 너무 많이 울렸어요. alert fatigue 걸릴 수준이에요."
개발자: "HighCPU 알림이 대부분인데, 크론잡 돌 때마다 울려서..."
시니어: "크론잡 시간대는 알림 억제하거나, CPU 임계치를 올리거나, 지속 시간(for)을 늘려서 일시적 스파이크는 무시하게 합시다. 진짜 중요한 알림만 가도록요."
면접관: "SLI/SLO 기반 모니터링 경험이 있으신가요?"
지원자: "네, 주요 API의 SLO를 "99.9% 가용성, P95 응답시간 200ms 이내"로 정의했습니다. Prometheus에서 error rate와 latency percentile을 측정해서 SLI로 사용하고, Grafana에 SLO 대시보드를 만들어 Error Budget 소진율을 추적했습니다. 월간 Error Budget이 80% 소진되면 feature freeze하고 안정화에 집중하는 정책을 운영했어요."
리뷰어: "이 커스텀 메트릭, label cardinality 확인했어요? user_id를 레이블로 넣으면 메트릭 폭발해요."
작성자: "아, user_id는 빼고 user_type(free, premium, enterprise)처럼 bounded된 값만 레이블로 쓰겠습니다."