k3s 클러스터, GitOps 배포 상태, 앱 런타임, 로그 이상 징후를 한 채널 체계로 묶되 메시지 형식은 일관돼야 한다.Prometheus, Alertmanager, ArgoCD Notifications, ELK, OTel, Tempo를 최대한 재사용하고, 새 컴포넌트는 꼭 필요한 경우에만 얇게 추가한다.현재 운영 클러스터에는 아래 구성요소가 이미 있다.
kube-prometheus-stack, Prometheus, Alertmanager, GrafanaArgoCD, argocd-notifications-controllerElasticsearch, Kibana, Filebeat, OTel Gateway, Tempodo4i, palcar, papersens, namanva즉 "알림 판단 엔진"은 이미 일부 있다. 빠진 것은 아래다.
추가로 2026-03-29 공식 문서 리서치 기준으로 아래를 반영해야 한다.
Alertmanager 는 현재 Discord native integration 을 공식 지원한다.ArgoCD Notifications 는 webhook 서비스로 Discord 또는 relay 호출이 가능하다.Grafana OnCall OSS 는 2026-03-24 archive 상태라 신규 도입 후보에서 제외하는 것이 맞다.NotReadyArgoCD Application 이 Degraded, Missing, SyncFailedHealthy 로 수렴하지 않음error, exception, traceback 폭증| 옵션 | 구성 | 장점 | 한계 | 적합도 |
|---|---|---|---|---|
| A | Alertmanager -> Discord 직접 전송만 사용 |
기존 메트릭 알림을 가장 빨리 붙일 수 있고 현재는 공식 native 지원이 있음 | GitOps 이벤트와 로그 이벤트 포맷이 분리되고, Discord 전용 템플릿 통일이 약함 | 보조 옵션 |
| B | Alertmanager + ArgoCD Notifications + 얇은 Discord relay |
기존 스택을 재사용하면서 메시지 포맷, severity, 링크를 한곳에서 통일 가능 | relay를 새로 하나 운영해야 함 | 권장 |
| C | B + ElastAlert2 같은 로그 룰 엔진 추가 |
로그 폭증과 에러 패턴까지 같은 채널로 편입 가능 | 룰 튜닝과 오탐 억제가 필요함 | 2단계 권장 |
| D | 새 incident aggregator 서비스가 모든 이벤트를 직접 수집 | 장기적으로 가장 유연함 | 지금 시점에는 과설계이고 구현량이 큼 | 장기 후보 |
현재 기준 권장안은 옵션 B를 1단계 기본안으로 잡고, 로그 이상 징후는 옵션 C로 2단계 확장하는 방식이다.
Alertmanager가 인프라/앱 메트릭 알림을 발생시킨다.ArgoCD Notifications가 Application 상태 이상 이벤트를 발생시킨다.discord-relay HTTP endpoint 하나로 먼저 보낸다.이 구성을 권장하는 이유는 아래와 같다.
Alertmanager와 ArgoCD Notifications 는 입력 포맷이 다르다.Elasticsearch/Kibana 자체 alerting에 바로 의존하지 않는다.ElastAlert2 같은 룰 엔진을 별도로 붙이거나, 장기적으로 OTel/Prometheus 지표화 방식으로 흡수한다.즉 초기에는 아래 순서를 권장한다.
모든 알림 메시지는 최소한 아래 필드를 공통으로 가져야 한다.
severity: critical, high, warning, infostatus: firing, resolvedsource: alertmanager, argocd, log-rulecluster: do4ai-prod-k3s 같은 운영 식별자namespaceappsummary: 한 줄 요약evidence: 첫 근거 1~3개started_atdashboard_links: Grafana, Kibana, ArgoCD, Headlamp, Runbook예시 메시지 형태는 아래 수준이 적절하다.
[critical][argocd] do4i 배포 수렴 실패
- cluster: do4ai-prod-k3s
- namespace: do4i
- app: do4i
- symptom: Application Health=Degraded, Sync Status=OutOfSync
- evidence: deployment/api availableReplicas=0
- links: ArgoCD / Headlamp / Runbook
#ops-incidents
critical, high#ops-deploy
#ops-observability
초기에는 채널을 너무 많이 쪼개지 말고, 최소 2개 또는 3개로 시작하는 편이 낫다.
담당 범위:
장점:
PrometheusRule 로 선언형 관리가 가능함담당 범위:
장점:
담당 범위:
새 컴포넌트지만 책임을 작게 유지해야 한다.
초기 목표는 "운영 장애를 사람이 늦지 않게 인지하는 것"이지 "완전한 incident platform"이 아니다.
Alertmanager -> relay -> DiscordArgoCD Notifications -> relay -> Discorddo4i, palcar, papersens, namanva 우선 적용incident/deploy/observability 로 나눌지critical/high/warning 기준을 어디까지 명시할지아래 순서가 가장 현실적이다.
Alertmanager 와 ArgoCD Notifications 를 먼저 Discord 채널에 연결한다.discord-relay 를 하나 둔다.ElastAlert2 또는 지표화 방식으로 2단계에 편입한다.즉 "기존 k3s 스택 재사용 + 아주 작은 신규 relay 추가"가 현재 최적안이다.