17.8 장애 감지 및 알림(Alerting) 파이프라인 자동화

모니터링 대시보드 및 지표 저장소를 선언적으로 구축하는 행위는 관측성(Observability)의 1차 조건일 뿐이다. 인간 운영자의 육안 관제에 의존하는 수동적 모니터링 모델은, 비업무 시간대에 발생하는 시스템 붕괴나 수십만 개 메트릭에서 발화하는 국지적 이상 징후를 선제적으로 방어하는 데 태생적 한계를 지닌다.

본 절에서는 정적 및 동적 임계치(Threshold)를 초과한 이벤트에 대해 운영체제의 개입 없이 실시간 대응망(Slack, PagerDuty 등)을 일제히 점화(Trigger)하고, 복구 파이프라인을 기계 대 기계(M2M) 레이어에서 발동시키는 공세적 방어(Proactive Defense) 기반 자동화 알림 체계의 아키텍처 런북(Runbook)을 명세한다.

1. Prometheus Alertmanager 경고 규칙(Alerting Rules) 작성

Prometheus 코어 데몬 자체는 시계열 데이터(TSDB)의 덤프 및 집계 연산에 특화되어 있으나, 규칙 기반의 경보 상태 전환(State Transition) 및 대상 전파 기능은 부재한다. 해당 공백을 채우기 위해 전용 컴포넌트인 Alertmanager 서브시스템을 체인으로 연동하고 경고 규칙(Alerting Rules)을 선언해야 한다.

1. 임계치 폭발(Spike) 알람 및 처리율 제한 룰
특정 네트워크 대역폭이나 폐기(Drop)율이 정의된 쿼터(Quota)를 초과하려는 순간을 지시하는 설정이다.

# prometheus_rules.yml (Zenoh Router Monitoring)
groups:
- name: zenoh_network_alerts
  rules:
  - alert: HighPacketDropRate
    expr: rate(zenoh_messages_dropped_total[5m]) > 100
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "[Critical] Zenoh 라우터 패킷 드롭 임계치 초과"
      description: "{{ $labels.instance }} 라우터에서 초당 100회 이상의 지속적인 패킷 폐기가 관측되었습니다. 버퍼 프로비저닝 조치가 요구됩니다."

2. 서비스 수준 협약(SLA) 지연 시간(Latency) 타격 룰
관제 대상의 P99(99th Percentile) 지연 시간이 100ms를 초과하여 SLA 붕괴가 의심될 시 발화하는 조건식이다.

  - alert: LatencySpike
    expr: histogram_quantile(0.99, rate(zenoh_latency_bucket[1m])) > 0.1
    for: 2m
    labels:
      severity: warning

여기서 가장 중요한 아키텍처적 장치는 for: 1m 과 같은 지연 평가 파라미터다. 일시적으로 튀어 오르는 노이즈성 지표에 즉각 알람을 발송하는 빈번한 오탐(False Positive)은 운영 조직의 경계 심리를 무력화(Alert Fatigue)시킬 수 있으므로, 반드시 임계치 초과 상태가 1분 이상 지속(Duration)될 때만 상태를 격상시키는 디바운싱(Debouncing) 로직이 필수적이다.

2. 노드 다운타임 및 응답 지연 임계치(Threshold) 설정

정상적인 패킷 지연보다 더욱 치명적인 위협 요소는 물리 서버나 로보틱스 OS 자체가 침묵 상태(Down)로 전락하는 인프라 척추 붕괴 이벤트다.

1. 상태 지표(Up Pointer)의 실종 추적
Prometheus가 분산 인스턴스를 스크레이핑(Scraping)할 시 기본 산출하는 스택 변수인 up 지표를 활용한다. (1: 정상, 0: 통신 두절).

  - alert: ZenohRouterDown
    expr: up{job="zenoh-cloud-router"} == 0
    for: 30s # 30초 연속 상태 확인 실패 시 즉각 알럿 트리거
    labels:
      severity: disaster

클라우드 핵심 라우터가 30초 이상 응답하지 않는다는 것은, 해당 관할의 접속된 에지 장비군 통제권을 완전히 상실(Brain Split)했음을 시사하는 재앙 척도(Disaster Scale)의 인시던트(Incident)다.

2. 에지(Edge) 기기 특화 예외 처리 및 플래핑(Flapping) 방어 전술
이동성이 높은 에지 로보틱스 노드는 본질적으로 무선 통신망(5G/LTE/Wi-Fi 등)을 경유하므로 연결의 단속(Flapping) 빈도가 매우 높다. 해당 군집에 대해 클라우드 서버와 동일한 평가선(for: 30s)을 적용할 경우, 매일 수천 건의 무의미한 상태 핑퐁(Ping-pong) 알람이 폭주하게 된다.
따라서 에지 노드 타겟에는 for: 5m 수준으로 검증 시간을 대폭 완화하거나, sliding_window를 결합하여 “최근 1시간 내 단절 횟수가 10회 이상 누적된 계정” 만을 격리(Quarantine)하여 통보(Notification)하는 피로도 통제(Alert Fatigue Management) 기법을 필히 적용해야 한다.

3. Slack, 이메일, Webhook 연동을 통한 실시간 알림 파이프라인

Alertmanager 서브시스템이 조건을 만족하는 평가(Firing 상태)를 생성하면, 이를 등급(Severity) 및 채널 스펙에 맞추어 실제 인간이나 시스템으로 배송하는 라우팅 계층이 개입한다.

1. Alertmanager 라우팅 및 에스컬레이션(Escalation) 전술
위해 등급(Severity Level)에 따라 도달해야 할 수신 매체와 담당 조직을 분리한다.

# alertmanager.yml
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 10s
  receiver: 'slack-warning-tier'
  routes:
    # Disaster 등급: 최상위 심야 대응팀 Call(PagerDuty) 및 SMS 동시 브로드캐스트
    - match:
        severity: disaster
      receiver: 'sms-pagerduty-critical'
    # Warning 등급: 인프라 데브옵스 채널에만 비동기 통보
    - match:
        severity: warning
      receiver: 'slack-warning-tier'

2. Webhook 파이프라인을 응용한 자가 치유(Auto-Healing) 전략
통보 대상을 인간에게만 국한시키는 것은 사후약방문에 가깝다. AIOps 및 SRE(Site Reliability Engineering)의 지향점은 기계가 알람을 기계 시스템으로 우회(Webhook)시키는 오케스트레이션(Orchestration)이다.
예컨대 메모리 고갈 의심 알람(HighMemoryUsage)이 발화될 시, 알람 페이로드를 직접 Kubernetes API 서버나 사내 자동화 스크립트로 전송(POST)하여, OOM 프로세스 종료가 발생하기 직전에 Zenoh 라우터 파드(Pod)를 스케일 아웃(Scale-out) 시키는 폐쇄 루프 컨트롤(Closed-Loop Control) 체계를 포괄해야 한다.

4. 장애 조치(Failover) 이벤트 발생 추적 및 기록

고가용성(HA) 아키텍처(14장 인용)가 정상 가동 중인 환경이라면, 특정 라우터 인스턴스가 물리적으로 붕괴되더라도 로보틱스 클라이언트들은 이중화된 백업(Backup) 라우터 인스턴스로 경로를 재설정하여 서비스 논리적 결점(Drop) 없는 무중단 통신(Zero-Downtime)을 달성한다. 그러나 이러한 성공적 대응 이면의 장애 발현 사실마저 모니터링 콘솔 내에서 침묵당해선 안 된다.

1. 위상 변동(Topology Shift) 트래킹 기반 보이지 않는 사건(Shadow Incident) 탐지
Zenoh 통신망의 라우팅 테이블(Routing Table) 수량이나 zenoh_session_count 시계열 메트릭이 특정 노드군에서 급락하고 백업 노드군에서 수직 상승(Spike)하는 스윙(Swing) 패턴을 식별해 내어야 한다. 이는 Failover 정책의 발동 물증이므로 "Failover Operation Successful: 라우터 A 통신단절 후 B 노드로 세션 인계 완료"라는 정보성(INFO) 알람을 명시적으로 시스템 운영진에게 보고해야 한다.

2. 사후 분석(Post-mortem)을 위한 대시보드 애노테이션(Annotation) 마킹
장애 요약 보고서를 작성할 시, 사건 전후 구간의 메트릭 연관성을 규명하기 위해 이벤트 트리거와 동시에 Grafana 타임라인 디스플레이에 수직 실선 마커(Annotation Point)를 강제 삽입해야 한다. API를 통해 발화된 “09:10:00 라우터 B 스위치오버 조치“라는 기록선 하나가, 왜 해당 시점의 네트워크 병목이 일시적으로 한계 수치를 타격했는지 사후 변호하는 완벽한 아키텍처 지름길(Shortcut)이 된다.

graph TD
    classDef monitor fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
    classDef evaluate fill:#fff3e0,stroke:#ef6c00,stroke-width:2px;
    classDef alert fill:#ffebee,stroke:#c62828,stroke-width:2px;
    classDef action fill:#e1f5fe,stroke:#0277bd,stroke-width:2px;

    subgraph Monitoring_Engine [Metrics Hub]
        Prometheus[(Prometheus <br> Multi-dimensional TSDB)]:::monitor
    end

    subgraph Rules_Engine [Evaluation Layer]
        Rules[Alerting Rules<br>- HighPacketDrop<br>- NodeDown]:::evaluate
    end

    subgraph Routing_Engine [Alertmanager Pipeline]
        AlertManager{Alertmanager<br>Route & Grouping}:::evaluate
    end

    Prometheus -->|Scrape TS Data| Rules
    Rules -->|Rules evaluated <br> Status Firing| AlertManager

    AlertManager -->|Severity: Disaster| PagerDuty[PagerDuty / SMS Alert <br> Call Engineer]:::alert
    AlertManager -->|Severity: Warning / Info| Slack[Slack / Teams Channel <br> Async Notification]:::alert
    AlertManager -->|Severity: HighMemory| Webhook[Automation Webhook]:::action
    
    Webhook -->|Scale Out Pod| K8s[Kubernetes Core API<br>Auto-Healing Subsystem]:::action