새벽 2시에 알람이 울릴 때, 가장 비용이 많이 드는 부분은 페이징(paging)이 아닙니다. 바로 보물찾기(scavenger hunt)입니다.

어떤 서비스가 고장 났는가?

어떤 트레이스(trace)가 이를 증명하는가?

어떤 로그(log) 라인이 이를 설명하는가?

지금 무엇이 변했는가?

Incident Sentinel은 SigNoz MCP 서버를 통해 SigNoz 알람을 조사하고, 증거 기반의 보고서(및 사후 분석(postmortem))를 Slack에 게시하며, — 실제 운영에서 중요한 부분인 — 동일한 SigNoz 인스턴스 내에서 **스스로를 관찰(observes itself)**하는 SRE 장애 대응 코파일럿(incident copilot)입니다.

시스템을 디버깅하는 에이전트가 블랙박스(black box)여서는 안 됩니다.

Repo: github.com/Vickyavh7/signoz-sentinel

관측성 격차 (한 단계 위 계층)

현대의 온콜(on-call)은 더 이상 단순히 "결제 API를 감시하는 것"에 그치지 않습니다. AI 에이전트가 루프(loop)에 진입하고 있습니다. 에이전트는 도구를 호출하고, 텔레메트리(telemetry)를 바탕으로 추론하며, 요약문을 작성합니다. 관측성(Observability)은 두 가지 계층을 모두 커버해야 합니다:

두 번째 계층이 없다면, 팀은 흔히 다음과 같은 상황에 직면합니다:

• 조사 스팬(investigation span) 부재
• 토큰 수(token count) 확인 불가
• 비용 신호(cost signal) 부재
• "이것이 얼마나 자주 정확한가?"라고 말할 방법이 없음

이는 우리가 LLM 앱에 대해 말하는 "눈을 가리고 비행하는(flying blind)" 이야기와 동일하며, 이를 장애 대응 에이전트 자체에 적용한 것입니다.

우리가 구축한 것

checkout → payment → inventory     (데모 앱 + 결함 주입(fault injection))
        │ OTLP
        ▼
...

구체적인 구성 요소:

구체적인 구성 요소:

1. SigNoz를 단일 창(single pane)으로 활용 — 트레이스 (traces), 메트릭 (metrics), 로그 (logs), 알람 (alerts), 대시보드 (dashboards).
2. Kubernetes 상의 결함 주입 가능 데모 체인 (Fault-injectable demo chain): checkout-api → payment-svc → inventory-svc.
3. Incident Sentinel — SigNoz MCP 기반의 FastAPI 웹훅 (webhook) + 도구 호출 에이전트 (tool-calling agent).
4. SigNoz로 연결되는 증거 링크가 포함된 Slack 보고서 (Slack reports).
5. 자동 사후 분석 (Auto-postmortems) — 타임라인 (timeline), 영향 (impact), 증거 (evidence), 비용 (cost); 또한 GET /postmortems/{ruleId}를 통해 제공됨.
6. 자기 텔레메트리 (Self-telemetry) — 조사 스팬 (investigation spans), GenAI 채팅 스팬 (GenAI chat spans), 도구 스팬 (tool spans), sentinel_tokens_total, sentinel_cost_usd_total.
7. 측정된 정확도 (Measured accuracy) — 단순한 느낌(vibes)이 아닌 evals/에서의 실제 결함 평가 (fault evals).

우리는 GenAI 속성과 비용 메트릭을 엔드 투 엔드(end-to-end)로 직접 관리하기 위해 핵심 에이전트를 커스텀하게 유지했습니다.

다음은 결함 발생 시간 동안의 라이브 서비스 맵입니다 — 데모 앱과 퍼스트 클래스 서비스(first-class service)로서의 코파일럿(copilot)을 보여줍니다:

그림 1. SigNoz 서비스 — 장애 서비스와 incident-sentinel이 하나의 창에 표시됨.

조사 작동 방식

1. SigNoz 알람이 발생합니다 (에러, 지연 시간, 또는 우리의 비용 메타 알람).
2. 웹훅 (webhook)이 Incident Sentinel에 도달합니다 (빠르게 수신 확인(ack)을 하며, 작업은 백그라운드에서 계속됩니다).
3. LLM이 MCP 도구를 선택합니다 — 트레이스 검색 (search traces), 트레이스 상세 정보 가져오기 (pull trace details), 로그 검색 (search logs), 메트릭 쿼리 (query metrics).
4. 여러 신호(signals)를 교차 상관 분석(correlate)하고 의존성 체인(dependency chain)을 따라갑니다.
5. 요약, 근본 원인 (root cause), 영향 (impact), 타임라인 (timeline), 그리고 제안된 후속 조치 (suggested follow-ups)와 함께 결론을 내립니다.
6. Slack으로 보고서가 전송되며, 마크다운(markdown) 형식의 사후 분석 보고서가 생성됩니다.
7. 전체 실행 과정은 incident-sentinel 서비스로서 SigNoz에 다시 트레이스(traced)됩니다.

우리는 의도적으로 자동 복구(auto-remediate)를 수행하지 않습니다. 코파일럿은 진단하고, 실행 버튼은 인간이 유지합니다. 이 경계는 신뢰를 위한 기능이지, 누락된 체크박스가 아닙니다.

알람 규칙 (Alert rules)은 진입점이며, 여기에는 코파일럿 자체의 지출에 대한 메타 알람 (meta-alert)도 포함됩니다:

그림 2. 알람 규칙 (Alert Rules) — 서비스 장애와 sentinel-cost-budget (kind: meta-alert).

그리고 모든 조사(investigation)는 온콜(on-call) 담당자가 열어볼 수 있는 실제 OpenTelemetry 트레이스(trace)를 남깁니다:

그림 3. sentinel.investigate 트레이스 (~50초) — LLM 단계와 MCP 도구 호출로, 블랙박스가 아닙니다.

실제 사후 분석(postmortem) 발췌 내용 (체크아웃 오류 급증 시 자동 생성):

# Postmortem: checkout-error-spike
- Primary service: checkout-api · Confidence: 0.8
- Investigation duration: 192.3s · Cost: $0.0112
...

설계 결정: 감시자도 감시당한다 (the watcher is watched)

우리는 sentinel_cost_usd_total에 **비용 예산 메타 알람(cost-budget meta-alert)**을 설정했습니다.

만약 코파일럿이 조사하는 데 너무 많은 비용을 지출하면, _그것_이 당신에게 페이지를 보냅니다. (알림을 울립니다.)

이것은 슬라이드웨어 아이디어가 아닙니다. 테스트 도중, 더 큰 호스팅 모델을 사용한 몇몇 조사는 아주 작은 데모 예산을 초과했습니다. SigNoz는 sentinel-cost-budget을 발동시키고, 이를 코파일럿 자체의 웹훅(webhook)으로 라우팅했으며, 코파일럿은 자신의 비용 초과를 조사하고 그 보고서를 Slack에 게시했습니다.

완벽한 순환: 인시던트 에이전트 자체가 인시던트가 된 것입니다.

코파일럿 자체의 운영 텔레메트리:

그림 4. 코파일럿 운영 현황 — 조사량, GenAI 호출 및 MCP 도구 사용.

이것이 단 하나의 문장으로 요약되는 관측 가능성(observability) 사용 사례입니다: 서비스 장애와 그 조사를 동일한 OpenTelemetry 네이티브 백엔드에서 계측합니다.

에이전트 측정하기 (신뢰하는 대신)

AI 기반 SRE 시스템의 공통적인 격차: 아무도 에이전트가 얼마나 자주 맞는지를 묻지 않습니다.

저희 평가 환경(evals/run_evals.py)은 실제 장애 상황을 주입합니다:

최신 실행 결과: 3/3 (evals/RESULTS.md 참조).

가장 솔직했던 실패 사례들이 통과 사례보다 더 많은 것을 가르쳐 주었습니다:

• 에이전트가 한때 incident-sentinel 자체를 지연 장애의 원인으로 지목했습니다. 이는 에이전트 자신의 스팬(span)이 쿼리하는 SigNoz와 같은 곳에 존재하기 때문입니다. 자가 관측성(Self-observability)은 금지하지 않으면 자체 조사 과정까지 오염시킬 수 있습니다.
• 연쇄 장애(Cascade faults)는 근본 원인이 인벤토리였음에도 불구하고 미드체인 서비스(예: 결제)를 탓하게 만들었습니다. 저희는 연쇄 정제(cascade refinement) 기능을 추가했습니다: 경고가 발생한 서비스의 _상위 스트림(upstream)_을 절대 탓하지 않고, checkout → payment → inventory에서 가장 깊이 에러를 일으킨 단계를 선호합니다.

평가 지표는 SigNoz로 내보내지며 (sentinel_eval_*), 에이전트 품질(Agent Quality) 대시보드에 표시됩니다. 이는 정확도를 일급 관측성 신호(first-class observability signal)로 다루는 것입니다:

그림 5. 에이전트 품질 — SigNoz 내의 비용, 조사량 및 평가 통과 비율.

구축 과정에서 문제가 된 것

인프라와 인증(auth)은 모든 실제 관측성 설정에 포함되는 부분입니다:

• 이전 버전의 Linux 호스트 (Older Linux hosts) 및 툴링의 glibc 불일치 — 호스트 Docker 소켓을 사용하여 Debian 컨테이너에서 Foundry 툴링을 실행했습니다.
• 특정 이미지 핀(image pin)에서의 ClickHouse Keeper 불안정성; 이전 버전의 keeper 이미지를 고정하여 스택을 안정화했습니다.
• 인증(Auth) 관련 실수(footguns): 서비스 계정(Service Account) API 키와 사용자 JWT는 MCP와 상호 교환될 수 없습니다. 잘못된 헤더 사용 → "MCP가 고장 났다"라고 오해할 수 있는 401/403 오류 발생.
• 대규모 모델은 느림: 웹훅(webhook) 전달은 즉시 승인(ack)되어야 합니다. 조사는 타임아웃(timeout) 및 재시도(retry)와 함께 백그라운드에서 실행됩니다.
• 우아한 성능 저하 (Graceful degradation): LLM이 유효한 결론을 반환하지 못할 경우, 보고서는 MCP 증거로만 작성되며 degraded로 표시됩니다 — 미리 정해진 가짜 근본 원인(root cause)을 제공하지 않습니다.

운영에 최적화된 가드레일 (Guardrails)

• 알람/규칙별 중복 제거(Dedupe) 윈도우
• 동시성 제한(Concurrency cap) 및 제한된 조사 단계
• Kubernetes Secret 내에 범위가 지정된 SigNoz 서비스 계정(Service Account) 키
• 매 실행 시 토큰(Token) + USD 비용 + 소요 시간 측정
• 모델 실패 시 증거 기반의 폴백(fallback) 처리

실험실 환경에서 신뢰할 수 있는 수준입니다. 이것이 내일 당장 프로덕션 SaaS가 될 것이라는 주장은 아닙니다.

워크플로우 실행하기

1. ./demo/break.sh errors
2. 알람 (또는 POST /investigate) → Slack 보고서 + 사후 분석(postmortem)
3. SigNoz → 서비스 incident-sentinel → 조사 트레이스(investigation trace)
4. 대시보드: Copilot Operations + Agent Quality
5. evals/RESULTS.md 확인
6. sentinel-cost-budget 확인 — 감시자를 감시합니다

핵심 요약 (Takeaways)

1. AI 에이전트를 위한 관측성(Observability)은 단순히 "LLM 앱을 추적하는 것"만이 아닙니다. 때로는 에이전트 자체가 SRE 워크플로우가 됩니다.
2. 양쪽 모두에 계측(Instrument)하십시오 — 장애 상황과 조사 과정 모두를 하나의 OpenTelemetry 네이티브 백엔드에서 처리해야 합니다.
3. 정확도를 측정하십시오. 실제 결함(fault)을 통해 측정하지 않으면, 당신은 역량이 아닌 자신감만을 배포하게 됩니다.
4. **에이전트 비용에 대한 메타 알람(Meta-alerts)**은 셀프 텔레메트리(self-telemetry)를 운영자가 실제로 페이지(page)를 띄울 수 있는 유의미한 정보로 바꿉니다.

링크

링크

• Repo: github.com/Vickyavh7/signoz-sentinel
• SigNoz MCP: github.com/SigNoz/signoz-mcp-server

개발 과정에서 AI 코딩 어시스턴트가 사용되었습니다.