알람 전략: 에러율/레이턴시/자원지표 설계

에러율 급증 → 사용자가 실제로 아프다
p99 레이턴시 급증 → 사용자 체감이 나빠졌다
SLO 위반(번레이트 초과) → 이 속도면 월말까지 에러 버짓을 다 쓴다

DB 커넥션 풀 고갈 → 10분 안에 요청 실패 시작될 수 있다
메모리 누수(점진 상승) → OOM까지 몇 시간 남았다
큐 backlog 증가 → 처리 지연이 사용자에게 곧 전달된다
디스크 사용률 상승 → 며칠 안에 write 실패 가능

에러 버짓 = 1 - SLO = 0.1% (SLO 99.9%)
번레이트 = 실제 에러율 / 에러 버짓

번레이트 1 = 정확히 예산대로 소비 (30일 뒤 0%)
번레이트 14.4 = 1시간이면 에러 버짓 2%를 태움 → 즉시 대응 필요
번레이트 6 = 6시간이면 에러 버짓 5%를 태움 → 티켓/조사 필요

# prometheus/rules/slo-burn-rate.yml
groups:
  - name: slo-availability-burn-rate
    interval: 30s
    rules:
      # -- SLI 기록 규칙 (재사용) --
      - record: sli:http_requests:error_rate_5m
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          )

      - record: sli:http_requests:error_rate_30m
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[30m]))
            /
            sum(rate(http_requests_total[30m]))
          )

      - record: sli:http_requests:error_rate_1h
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          )

      - record: sli:http_requests:error_rate_6h
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          )

      # -- 알람 규칙 --
      # Page: 1시간 창에서 번레이트 14.4× 초과 + 5분 창에서도 확인
      - alert: SLOBurnRateCritical
        expr: |
          sli:http_requests:error_rate_1h > (14.4 * 0.001)
          and
          sli:http_requests:error_rate_5m > (14.4 * 0.001)
        for: 2m
        labels:
          severity: page
          slo: availability
        annotations:
          summary: "SLO 번레이트 Critical — 1시간 내 에러 버짓 2% 소진 속도"
          description: |
            1h 에러율: {{ $value | humanizePercentage }}
            SLO: 99.9%, 번레이트: 14.4×
          runbook_url: "https://wiki.internal/runbooks/slo-burn-rate-critical"

      # Page: 6시간 창에서 번레이트 6× 초과
      - alert: SLOBurnRateHigh
        expr: |
          sli:http_requests:error_rate_6h > (6 * 0.001)
          and
          sli:http_requests:error_rate_30m > (6 * 0.001)
        for: 5m
        labels:
          severity: page
          slo: availability
        annotations:
          summary: "SLO 번레이트 High — 6시간 내 에러 버짓 5% 소진 속도"
          runbook_url: "https://wiki.internal/runbooks/slo-burn-rate-high"

      # Ticket: 3일 창에서 번레이트 1× 지속
      - alert: SLOBurnRateWarning
        expr: |
          sli:http_requests:error_rate_6h > (1 * 0.001)
        for: 30m
        labels:
          severity: ticket
          slo: availability
        annotations:
          summary: "SLO 번레이트 Warning — 에러 버짓 소비가 예산 속도 이상"
          runbook_url: "https://wiki.internal/runbooks/slo-burn-rate-warning"

- alert: HighErrorRate
  expr: |
    sum(rate(http_requests_total{status=~"5.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
    > 0.01
  for: 5m
  labels:
    severity: page
  annotations:
    summary: "5xx 에러율 {{ $value | humanizePercentage }} (> 1%)"
    dashboard: "https://grafana.internal/d/http-overview"

- alert: HighP99Latency
  expr: |
    histogram_quantile(0.99,
      sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
    ) > 2.0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "p99 레이턴시 {{ $value }}s (> 2s)"
    description: "최근 5분간 p99 응답시간이 2초를 넘겼습니다."

# 트래픽 급감: 정상 대비 50% 이하
- alert: TrafficDropSevere
  expr: |
    sum(rate(http_requests_total[5m]))
    < 0.5 * sum(rate(http_requests_total[1h] offset 1d))
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "트래픽 급감 — 전일 동시간 대비 50% 이하"

# 트래픽 급증: 정상 대비 3배 이상
- alert: TrafficSpikeSevere
  expr: |
    sum(rate(http_requests_total[5m]))
    > 3 * sum(rate(http_requests_total[1h] offset 1d))
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "트래픽 급증 — 전일 동시간 대비 300% 이상"

# DB 커넥션 풀 고갈 임박
- alert: DBConnectionPoolExhaustion
  expr: |
    hikaricp_connections_active
    /
    hikaricp_connections_max
    > 0.85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "HikariCP 커넥션 풀 사용률 {{ $value | humanizePercentage }}"

# JVM 메모리 — Old Gen 지속 상승(누수 의심)
- alert: JVMOldGenHighUsage
  expr: |
    jvm_memory_used_bytes{area="heap", id=~".*Old.*|.*Tenured.*"}
    /
    jvm_memory_max_bytes{area="heap", id=~".*Old.*|.*Tenured.*"}
    > 0.85
  for: 15m
  labels:
    severity: warning
  annotations:
    summary: "JVM Old Gen 힙 사용률 85% 초과, 15분 지속 — 메모리 누수 의심"

# 디스크 잔여 용량 예측
- alert: DiskSpaceRunningOut
  expr: |
    predict_linear(
      node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600
    ) < 0
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "디스크 여유 공간이 24시간 내 소진 예상"

- alert: KafkaConsumerLagHigh
  expr: |
    kafka_consumer_group_lag_sum > 10000
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Kafka consumer lag {{ $value }} (> 10,000)"
    description: "consumer group이 10분 이상 10,000건 이상 뒤처져 있습니다."

# alertmanager.yml
global:
  resolve_timeout: 5m
  slack_api_url: 'https://hooks.slack.com/services/xxx/yyy/zzz'

route:
  receiver: 'default-slack'
  group_by: ['alertname', 'service']
  group_wait: 30s        # 첫 알람 후 그룹핑 대기
  group_interval: 5m     # 같은 그룹 재알림 간격
  repeat_interval: 4h    # 해소 안 될 때 반복 간격

  routes:
    # Page 심각도 → PagerDuty (즉시 호출)
    - match:
        severity: page
      receiver: 'pagerduty-oncall'
      group_wait: 10s
      repeat_interval: 30m

    # Ticket 심각도 → Jira + Slack
    - match:
        severity: ticket
      receiver: 'jira-slack'
      repeat_interval: 12h

    # Warning → Slack만
    - match:
        severity: warning
      receiver: 'default-slack'
      repeat_interval: 4h

receivers:
  - name: 'default-slack'
    slack_configs:
      - channel: '#alerts-warning'
        send_resolved: true
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'

  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - service_key: '<PD_SERVICE_KEY>'
        severity: 'critical'

  - name: 'jira-slack'
    slack_configs:
      - channel: '#alerts-tickets'
        send_resolved: true

inhibit_rules:
  # Page가 울리면 같은 서비스의 Warning은 억제
  - source_match:
      severity: 'page'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'service']

  # 인프라 다운이면 해당 인프라 위 서비스 알람 억제
  - source_match:
      alertname: 'NodeDown'
    target_match_re:
      alertname: '.+'
    equal: ['instance']

# CI/CD 파이프라인에서 배포 시작 시 silence 생성
amtool silence add \
  --alertmanager.url=http://alertmanager:9093 \
  --duration=30m \
  --comment="Deployment: ${SERVICE_NAME} ${VERSION}" \
  service="${SERVICE_NAME}" severity="warning"

# Runbook: [알람 이름]

## 의미
- 이 알람은 [어떤 증상/위험]을 나타냅니다.
- 영향 범위: [사용자 영향 / 내부 영향]

## 1차 확인 (5분 이내)
1. [ ] 최근 배포가 있었는가? → [배포 이력 링크]
2. [ ] 의존성(DB/외부 API)은 정상인가? → [의존성 대시보드 링크]
3. [ ] 에러 로그에 새로운 패턴이 있는가? → [Kibana/Loki 검색 링크]

## 응급 조치 (10분 이내)
- 배포가 원인이면: `kubectl rollout undo deployment/xxx`
- 트래픽 급증이면: HPA min replica 상향 또는 기능 플래그 off
- DB 커넥션 고갈이면: 커넥션 풀 사이즈 임시 상향

## 근본 원인 분석
- 트레이스: [Jaeger/Tempo 링크]
- 메트릭: [Grafana 대시보드 링크]
- 로그: [구조화 로그 검색 쿼리]

## 에스컬레이션
- 15분 내 해결 안 되면: [팀 리드/SRE 담당 연락처]
- 30분 내 해결 안 되면: [인시던트 선포 절차]

annotations:
  runbook_url: "https://wiki.internal/runbooks/{{ $labels.alertname }}"

0~5분:  1차 온콜 → PagerDuty 자동 호출
5~15분: 응답 없으면 → 2차 온콜 자동 에스컬레이션
15~30분: 해결 안 되면 → 팀 리드 + SRE 합류
30분+:  인시던트 선포 → 전사 커뮤니케이션 채널 활성화

## 월간 알람 위생 리뷰

- [ ] 지난 달 울린 알람 전수 목록 확인
- [ ] 액션 없이 해소된 알람 → 임계치 조정 또는 삭제 후보
- [ ] 한 번도 안 울린 알람 → 임계치가 너무 높거나 죽은 알람
- [ ] 중복 알람(같은 증상을 다른 규칙으로) → 통합
- [ ] Runbook이 없는 알람 → Runbook 작성 또는 알람 삭제
- [ ] 새로 추가한 알람 → 1주일 노이즈 리뷰 후 심각도 조정