1부에서는 Elastic의 Kubernetes 통합이 EDOT Collector를 통해 텔레메트리를 Elasticsearch로 전송하는 방법을 다뤘습니다. 이번 아티클에서는 MCP(모델 컨텍스트 프로토콜) 앱 서버를 통해 텔레메트리를 AI에서 호출 가능한 도구로 노출하고, 인라인으로 렌더링되는 대화형 React UI를 구현하는 방법을 더 자세히 살펴보겠습니다. 또한 알림부터 문제 해결 제안에 이르기까지 전체 근본 원인 분석 루프를 처리하는 자동화된 런북인 Elastic Workflows를 통해 이를 더욱 확장하는 방법도 다룹니다.

작업하는 곳에서 렌더링되는 Observability MCP 앱

Elastic Observability MCP 앱(기술 프리뷰)은 도구마다 하나씩, 총 6개의 뷰를 제공합니다. 각 뷰는 도구가 반환될 때 인라인으로 렌더링되며, 적절한 후속 조치를 추측할 필요가 없도록 권장된 다음 단계 프롬프트를 클릭 가능한 버튼으로 제공합니다. MCP 앱은 독립형 에이전트 워크플로우보다 한 단계 더 나아가, Kibana로 컨텍스트를 전환하지 않고 채팅 또는 IDE 내부의 대화에 인라인으로 실시간 대화형 뷰를 직접 렌더링합니다.

클러스터 상태 롤업

"뭐가 고장났어?" 또는 "상태 보고서를 줘"라고 요청하면 한 번에 모든 정보를 확인할 수 있습니다. 전반적인 상태 배지, 문제가 있는 서비스와 그 이유, 최상위 파드 메모리 소비자, 이상 심각도 분석, 서비스 처리량 등 모두 하나의 인라인 뷰에서 확인할 수 있습니다.

뷰는 배포에서 지원하는 항목에 따라 조정됩니다. APM은 서비스 상태를 제공합니다. Kubernetes 메트릭에 파드 및 Node 컨텍스트가 추가됩니다. ML 작업은 이상 징후를 탐지합니다. 신호가 없더라도 보기가 실패하는 대신 무엇이 누락되었는지 알려줍니다. 먼저 Kubernetes 클러스터의 현황 보고부터 시작하겠습니다.

상태 요약과 같은 복합 보고서는 데이터를 압축해 보여주면서 세부 정보는 확장해 볼 수 있도록 구성되어 있어, 한 번에 볼 정보의 양을 적절하게 선택할 수 있습니다. 제안된 조사 조치는 반환되는 특정 정보에 대한 지침을 제공할 뿐만 아니라, 사용자가 실행할 다른 도구에 대해서도 안내합니다.

서비스 종속성 그래프

"무엇이 체크아웃을 호출해?" 또는 "토폴로지를 보여줘"라고 물어보면, 업스트림 호출자, 다운스트림 종속성, 프로토콜, 호출량, 에지별 지연 시간 등이 포함된 계층형 종속성 그래프를 확인할 수 있습니다. 에지 위로 마우스를 가져가면 전체 호출 경로가 강조 표시됩니다. Claude에게 "프론트엔드의 서비스 의존성을 보여 줘"라고 요청해 봅시다.

확대/축소, 이동, 마우스오버를 통해 복잡한 서비스 관계를 이해하는 데 필요한 모든 세부 정보를 확인할 수 있습니다.

이상 징후 세부 정보

"어디에서 이상 징후가 나타나고 있어?"라고 질문하거나 또는 "체크아웃에 비정상적인 부분이 있어?"라고 질문하여 자동으로 선택된 두 가지 뷰 중 하나를 확인할 수 있습니다. 여러 엔터티가 영향을 받는 경우, 개요 모드에는 심각도 수, 영향을 받는 엔터티, 작업별 세부 분석이 표시됩니다. 단일 엔터티에 중점을 둔 경우, 상세 모드에는 점수, 비교 막대와 함께 표시되는 실제 값과 일반적인 값의 비교, 편차 백분율, 그리고 가능한 경우 시계열이 표시됩니다. 글머 프론트엔드 서비스를 확인해 보겠습니다.

이것은 ESQL 쿼리가 아니라, 이전에 정의된 이상 징후 탐색 작업 결과에 대한 설명입니다. 이 블로그 시리즈의 1부에서 설명한 대로, Kubernetes 통합에는 활성화할 수 있는 몇 가지 항목이 포함되어 있습니다. 이 도구를 사용하면 이러한 항목을 최대한 활용할 수 있습니다.

Observe

Observe는 Elastic에 대한 에이전트의 핵심 액세스 수단으로, 하나의 도구에서 세 가지 서로 다른 요구 사항을 충족할 수 있도록 두 가지 모드를 제공합니다. "각 Kubernetes 클러스터의 네트워크 처리량은 어떻게 돼?"라고 질문하면 결과가 표 또는 차트로 제공됩니다. "메모리가 80MB 이하로 떨어지면 알려줘" 또는 "다음 10분 동안 프론트엔드 메모리에 이상한 일이 없는지 지켜봐"라고 말하면 조건이 실행되거나 기간이 만료될 때까지 차단됩니다.

뷰는 원샷 쿼리를 위한 결과 테이블, 샘플링 및 임계값 조건에 대한 현재/최고/기준선 통계가 포함된 실시간 트렌드 차트, 이상 징후 모드를 위한 심각도 점수 트리거 카드 등 모드에 맞게 조정됩니다. 여기서는 사용량이 가장 많은 Kubernetes 노드를 식별하는 데 이를 사용합니다.

영향 범위로 위험 평가

"이 노드가 다운되면 어떻게 될까?"라고 물어보면 방사형 영향도 다이어그램이 표시됩니다. 대상 노드가 중앙에 위치하고, 전체 장애가 발생하는 배포는 빨간색, 성능이 저하되는 배포는 주황색, 영향을 받지 않는 배포는 회색으로 표시됩니다. 플로팅 요약 카드는 위험에 처한 파드와 일정 변경 가능성을 보여줍니다. 단일 복제본 배포는 단일 장애 지점으로 플래그가 지정됩니다. 사용량이 많은 노드에 장애가 발생하면 어떻게 될까요?

알림 관리

알림 관리 도구를 사용하면 알림을 생성하고, 목록을 조회하고, 정보를 확인하거나 삭제할 수 있습니다. 다음으로 알림을 생성할 예정이지만, 먼저 Observe를 다시 한 번 사용하여 알림이 타당한지 확인하기 위한 기준선을 빠르게 설정해 보겠습니다.

"프론트엔드 메모리가 75MB를 초과하면 알림을 보내줘"라고 요청하면, 에이전트가 영구적인 Kibana 경보 규칙(대화가 끝난 후에도 계속 실행되는 저장된 객체)을 생성합니다. 해당 뷰는 규칙 이름, 조건, 기간, 확인 간격, KQL 필터, 태그가 포함된 실시간 규칙 카드를 렌더링합니다. 다음 단계 버튼을 통해 규칙을 확인하거나, 메트릭이 안정화되는지 지켜보거나, 현재 클러스터 상태를 확인할 수 있습니다. 에이전트는 생성된 항목과 Kibana에서 해당 항목을 찾을 수 있는 위치를 확인해 줍니다.

MCP 앱 아키텍처

이 앱은 Node.js 서버, 6개의 단일 파일 뷰 리소스에 연결된 6개의 모델용 도구, 재쿼리를 위한 앱 전용 도구, vite-plugin-singlefile 번들링으로 구성됩니다. 도구는 배포 백엔드(범용, APM 종속, K8s 종속, ML 종속)별로 그룹화되므로 에이전트와 사용자 모두 통화 중에 기능 격차를 발견하는 대신 특정 배포에 적용되는 도구를 사전에 알 수 있습니다. 리포지토리에는 에이전트에게 각 도구를 언제 어떻게 호출해야 하는지 알려주는 6개의 스킬이 별도의 .zip 아티팩트로 포함되어 있습니다.

다음 다이어그램은 앱을 구성하는 세 가지 구성 요소를 보여줍니다. LLM 및 도구 사용 방법을 알려주는 Claude 기술을 보유한 MCP 호스트(Claude Desktop, VS Code 등), 도구 레지스트리를 노출하고 React UI 뷰를 번들로 묶으며 Elastic과의 모든 통신을 처리하는 단일 Node.js 프로세스인 MCP 앱 서버, 그리고 Elasticsearch와 Kibana가 실시간 데이터 및 경보 백엔드 역할을 하는 Elastic Stack 자체입니다.

아래 다이어그램은 사용자 요청의 흐름을 보여줍니다. Claude는 호출할 도구와 매개변수를 채우는 방법을 이해하기 위해 관련 스킬 파일을 읽고, Elasticsearch 및 Kibana에 대한 서버 측 쿼리를 트리거하는 도구를 호출하며, 대화형 위젯으로 인라인 렌더링되는 React UI 리소스와 함께 간결한 텍스트 요약을 받습니다.

알림에서 근본 원인까지: 조사 워크플로우

알림 규칙은 무언가 잘못되었음을 알려줍니다. ML 모듈은 패턴을 알려줍니다. Elastic Workflows는 알림이 발생하는 즉시 자동으로 진단을 실행합니다.

Kubernetes 알림에서 트리거되어 단 하나의 대시보드도 열기 전에 구조화된 근본 원인 요약을 반환하는 Kubernetes 조사 워크플로우(기술 프리뷰)를 출시할 예정입니다. 호출을 받은 SRE가 알림을 열면 조사가 이미 완료된 것을 확인할 수 있습니다.

워크플로우는 여러 데이터 소스에서 쿼리 작업을 수행하는 단계의 유향 그래프입니다. 주로 Elasticsearch 쿼리 언어(ES|QL)를 통해 이루어지며, ML 이상 징후 조회에는 Elasticsearch 검색을 사용합니다. if 단계는 쿼리 결과에 따라 분기하여 어떤 확인 작업을 실행할지(ML 메모리 이상 징후 대 로그 분류), 그리고 업스트림 상태를 평가할지(APM 종속성이 존재하는 경우에만) 여부를 선택합니다. AI 단계는 세 지점에서 나타납니다: 비 OOM(non-OOM) 경로에서의 로그 패턴 분류, 업스트림 성능 저하 상태와 정상 상태 분류, 그리고 모든 구조화된 증거를 근본 원인 설명으로 종합하는 최종 ai.summarize입니다.

실제 조사 워크플로우의 모습

아래 실행 예시는 Elastic에서 실행되는 OpenTelemetry Astronomy Shop을 기반으로 하며, 16개의 서비스와 Kafka, PostgreSQL을 사용하고 모든 구성 요소가 OTLP를 통해 사전 계측되어 있습니다. Shop의 실제 텔레메트리와 함께, EDOT 데이터 스트림을 통해 동일한 네임스페이스에 가상 K8s 및 APM 신호를 기록하는 가상 OOMKill 캐스케이드를 주입했습니다. 워크플로우는 당사의 신호와 실제 신호를 구분할 수 없으며, 단지 알림을 조사할 뿐입니다.

알림 발생: CrashLoopBackOff — oteldemo-esyox-default의 app-deployment. 재시작 횟수: 6.

워크플로우 1단계 — 파드 및 컨테이너 컨텍스트 파악

워크플로우는 K8s 메트릭을 조회하여 재시작 횟수, 마지막 종료 이유, 그릐고 선언된 한도 대비 사용률을 확인합니다.

결과: 마지막 종료 이유 OOMKilled, 재시작 횟수 6(참고: 이 파드/기간에 kubeletstats 사용률을 사용할 수 없었지만, 워크플로우는 정상적으로 계속됩니다).

워크플로우 분기: 종료 이유가 OOMKilled이므로 워크플로우는 로그 조사 경로가 아닌 메모리 조사 경로를 따릅니다.

워크플로우 단계 2a — ML 이상 징후 결과 참조

메모리 추세를 다시 계산하는 대신, 워크플로우는 활성 k8s_pod_memory_growth 이상 징후에 대해 ML 이상 징후 인덱스를 쿼리합니다.

결과: 이상 징후 없음 — 해당 급증은 부하 증가로 인한 것이며, 누출 의심 사례는 아닌 것으로 나타났습니다.

워크플로우 3단계 — 업스트림 서비스 상태 점검

워크플로우는 APM service_destination.1m 집계에서 업스트림 종속성을 열거한 후, 현재 오류율과 평균 지연 시간을 7일 전 같은 시간대와 비교합니다. AI 분류 단계에서 업스트림 성능 저하가 알림보다 먼저 발생했는지 여부를 결정합니다. 결과: 업스트림 1개 ― api-gateway. 현재 평균 지연 시간 15.13ms, 오류율 41.26%. 기준(168시간 전): 동일함. 분류: upstream_healthy — 5× 오류 / 3× 대기 시간 임계값 이내. 업스트림은 제외되었습니다.

워크플로우 4단계 — 최근 K8s 변경 사항과의 상관관계 분석

네임스페이스의 이벤트 로그에는 Pulled → Created → Started → Killing → BackOff의 긴밀한 주기가 약 60~90초마다 반복되는 것으로 표시됩니다. 지난 두 시간 동안 배포 또는 확장 이벤트는 없었습니다.

워크플로우 출력:

근본 원인 가설(신뢰도: 높음)

app-deployment가 메모리 부담으로 인해 OOMKilling되고 있습니다. 해당 파드는 OOMKilled를
종료 사유로 6번 재시작했습니다. ML은 메모리 급증을 부하에 따른 현상으로
플래그 지정했습니다(누수 없음). 업스트림 API 게이트웨이는 7일 기준과 비교해 현재
정상 상태입니다. 이는 리소스 할당 문제로, 컨테이너의 메모리 한도가
실제 작업 세트에 비해 너무 낮습니다.

증거:
- 6회 재시작, 마지막 종료 사유 OOMKilled
- ML 메모리 증가 이상 징후 없음 → leak_suspected=false(부하에 따른 현상)
- 업스트림 api-gateway 7일 기준 대비 변경 없음 (15.13ms, 41.26%) → 정상
- K8s 이벤트에는 Pulled/Created/Started/Killing/BackOff가 짧은 주기로 반복되며
  지난 2시간 동안 배포 없음

예상 원인: 부하 상태에서 실제 작업 세트에 비해 메모리 한도가 부족합니다.

권장되는 다음 단계
1. 관찰된 사용량에 따라 앱 배포 메모리 한도를 늘립니다
2. 애플리케이션 코드에서 메모리 최적화 기회를 검토합니다
3. 고부하 경로에서 단계적 성능 저하를 고려합니다

다운스트림 영향: APM의 대상 서비스 관련 메트릭에서 확인된 영향은 없습니다.

위의 출력은 알림을 열었을 때 보이는 모습입니다. 여러 로그나 대시보드로 연결되는 링크가 아니라 답변입니다.

동일한 워크플로우는 Claude Desktop, VS Code 또는 모든 MCP 호환 클라이언트에서 MCP 도구로 액세스할 수 있습니다. 개발자가 IDE에서 "체크아웃에서 왜 오류가 발생해?"라고 질문하면, 에이전트가 워크플로우를 호출하고 편집기를 벗어나지 않은 채 동일한 구조화된 출력을 인라인으로 반환합니다. 즉, 동일한 증거, 동일한 근본 원인을 제공합니다.

다음은 워크플로 실행 과정을 보여주는 애니메이션입니다.

Kubernetes 조사를 위한 Observability 스킬

또한 Kubernetes 워크로드, 노드 및 컨트롤 플레인 문제에 대한 전체 진단 프로토콜을 담고 있는 포괄적인 단일 조사 스킬(observability-k8s-investigation)을 제공합니다. 이는 명확한 원칙을 바탕으로 한 조사 방법론으로, 숙련된 SRE가 직관적으로 적용하지만 좀처럼 문서화하지 않는 사고 과정을 포함합니다. AI 에이전트 스킬에 기본 탑재되어 있으므로, Kibana를 최신 상태로 유지하면 이용할 수 있습니다. 가장 흔한 오진을 방지하는 핵심 원칙부터 시작됩니다.

• 증거가 없다고 해서 문제가 없는 것은 아닙니다. 로그 쿼리 결과가 0개인 경우 no_logs_available을 보고하세요. 결과가 없다는 이유만으로 장애 모드를 추론해서는 안 됩니다.
• OOMKilled가 기본적으로 메모리 누수를 의미하는 것은 아닙니다. 누수라고 단정하기 전에 현재 사용량을 7일 기준과 비교하세요. 한도가 단순히 부족할 수도 있습니다.
• 평균 CPU 메트릭은 스로틀링을 숨깁니다. 파드는 평균 사용률 40～60%로 정상적으로 보여도 p99에서는 심각한 스로틀링이 발생할 수 있습니다. 평균뿐만 아니라 max 및 p95도 확인하세요.
• 동반 증상은 원인이 아닙니다. 동시에 성능이 저하되는 두 서비스는 대개 업스트림 원인을 공유합니다. 한 서비스의 성능 저하가 다른 서비스보다 명확히 먼저 발생하고 두 시점의 차이가 큰 경우에만 인과 관계를 부여하세요.

그다음 Skill은 워크로드, Node, 컨트롤 플레인, 오토스케일링, 네트워킹 계층 전반에 걸친 16가지 서로 다른 K8s 장애 패턴을 포괄하는 장애 모드 분류 체계를 인코딩합니다. 여기에는 OOMKilled 및 CFS 스로틀링부터 어드미션 웹훅 차단과 StatefulSet 스플릿 브레인까지 포함됩니다. 각 모드에는 이를 식별하는 핵심 신호와 이를 확인하는 검증 체크리스트가 있습니다.

조사 흐름은 다음과 같은 구조화된 단계를 따릅니다. 상황 파악(대상 파드, 네임스페이스, 배포 확인), 특성 파악(재시작 횟수, 종료 이유, 사용량 확인), 분류(분류 체계를 기준으로 매칭), 입증(이벤트, 로그, APM, 기준선 비교 가져오기), 종합(명시적인 증거 및 권장 다음 단계를 제시하고 높음·중간·낮음으로 보정된 신뢰도와 함께 근본 원인 가설 생성).

두 가지 장애 모드가 증거에 부합하는 경우, Skill은 둘 다 명시하고 어떤 모드가 인과적이라고 판단하는지와 그 이유를 설명합니다. 증거가 모호할 경우, 모호하다고 명시합니다. "서로 다른 가설을 함께 제시하는 것도 유효한 결과입니다"라는 것이 명시적인 설계 원칙이며, 잘못된 확신을 심어주는 것은 조사 자체의 장애 모드로 간주됩니다.

시작하기

이러한 기능은 1부에서 설명한 Kubernetes 통합을 기반으로 합니다. 대시보드 및 데이터 수집이 실행되면, 다음과 같이 진행됩니다.

1단계 — 조사 워크플로우 활성화(기술 프리뷰). Kibana의 워크플로우 페이지에서 Kubernetes Crashloop Investigation Workflow를 가져오고, 필요에 따라 알림 규칙에 의해 트리거되도록 구성합니다.

2단계 ― MCP 호환 클라이언트에 MCP 앱 설치(기술 프리뷰). MCP App for Observability 리포지토리는 GitHub에서 확인할 수 있습니다. 다운로드하려면 릴리스 페이지를 참조하세요. 앱을 설치할 때 포함된 스킬도 함께 설치하고 활성화하는 것을 잊지 마세요. 선호하는 에이전틱 클라이언트에서 Example MCP App 도구에 액세스하세요. 관련 지침은 위의 GitHub 링크에 있는 README에서 확인할 수 있습니다.

3단계 — K8s 조사 스킬 활용(기술 프리뷰). Agent Builder를 사용하는 경우 AI Agent Skills에 기본으로 포함되어 있어 무료로 이용할 수 있습니다. 스킬은 에이전트에게 기본 도구 및 워크플로우를 언제 어떻게 호출해야 하는지 알려주어 대화형 컨텍스트에서 일관된 진단을 보장합니다.

다음 단계

조사 워크플로우는 모니터링 중인 서비스에서 무엇이 문제인지 진단합니다. 다음 질문은 더 어렵습니다. 모니터링하지 않는 서비스는 어떻게 해야 할까요?

저희는 토폴로지 기반 커버리지 인텔리전스를 구상하고 있습니다. Kubernetes API를 통해 클러스터에 배포된 모든 워크로드를 자동으로 검색하고, Elastic으로 유입되는 텔레메트리와 상호 참조하여 격차를 파악하는 것입니다. "47개의 서비스가 있습니다. 11개에는 분산 트레이스가 없습니다. 가장 위험한 사각지대는 여기입니다." 해당 기능은 현재 검토 중이며, 향후 별도의 아티클에서 다룰 예정입니다.

이와 동시에, 단순한 진단뿐만 아니라 조치에 이르는 문제 해결 영역으로 워크플로우를 확장하고 있습니다. 조사 요약이 첨부된 케이스 생성, 담당자의 승인을 위한 롤백 제안, 또는 근본 원인이 해결되는 동안 시간을 벌기 위한 워크로드 확장 등의 조치가 포함됩니다.

현재 Elastic에서 Kubernetes를 운영하고 있다면 인시던트가 발생할 때마다 수동으로 반복하는 조사 단계, 워크플로우가 제안해도 신뢰할 수 있는 해결 방안, 그리고 다음에 개발했으면 하는 MCP 도구가 무엇인지 알려주세요. [여기에서 Elastic 커뮤니티 토론]에 참여할 수 있습니다(https://discuss.elastic.co/c/observability).