• Elasticsearch는 Prometheus 호환 메트릭 백엔드입니다 — Prometheus Remote Write를 지원하며 이제 Kibana에서 PromQL을 네이티브로 지원하므로, 변환 계층이 필요하지 않습니다.

• 메트릭은 Elasticsearch의 컬럼형 TSDS 아키텍처에 저장되며 Prometheus보다 최대 2.5배 ClickHouse보다 2배 더 효율적으로 데이터를 저장할 수 있습니다.

• ES|QL 시계열 쿼리는 카디널리티가 높은 워크로드를 포함하여 게이지 평균값과 카운터 비율을 대상으로 할 때 Prometheus보다 최대 30배 빠릅니다.

• Elastic은 Datadog보다 약 50% 저렴하며, 사용자 지정 메트릭 분류나 카디널리티 기반 과금이 없습니다.

• Grafana는 [네이티브 Prometheus API]를 통해 Elasticsearch를 직접 쿼리할 수 있으므로(https://www.elastic.co/observability-labs/blog/elasticsearch-native-prometheus-api), 시각화 계층은 그대로 유지하면서 백엔드를 교체할 수 있습니다.

• Kubernetes 및 AWS 모니터링에는 사전 구축된 대시보드, 알림 템플릿, ML 이상 탐지 작업 및 인제스트 시점에 바로 사용할 수 있는 에이전틱 조사 콘텐츠가 포함됩니다. 또한 스킬과 MCP 앱 도 이용할 수 있습니다.

• 메트릭, 로그, 트레이스를 위한 통합 백엔드를 제공하므로 도구 간에 컨텍스트를 일일이 취합하지 않고도 에이전틱 조사를 수행할 수 있습니다.

• Discover의 메트릭 탐색을 통해 쿼리 언어에 대한 전문 지식 없이도 누구나 즉시 메트릭을 쿼리하고 분석할 수 있습니다.

• 사용자 지정 대시보드를 빠르고 유연하게 구성할 수 있습니다. 코드로 관리하는 대시보드, AI의 지원을 받아 대시보드 생성, 변수 컨트롤, 접을 수 있는 패널을 통해 대시보드 구축에 드는 시간은 줄이고 조사에 더 많은 시간을 할애할 수 있습니다.

• Datadog 및 Grafana에서 대시보드와 알림 규칙/모니터를 쉽게 마이그레이션할 수 있도록 마이그레이션 도구를 제공합니다.

Elasticsearch 메트릭은 이제 SRE에게 중요한 모든 측면에서 경쟁력을 갖추고 있습니다. 모든 메트릭을 전체 해상도로 유지할 수 있고, Prometheus보다 최대 30배 더 빠르게 쿼리 작업을 할 수 있으며, Datadog 대비 비용을 50% 절감하고, Grafana 또는 Datadog의 대시보드와 경보 규칙을 쉽게 마이그레이션할 수 있으며, 분절된 도구 간에 컨텍스트를 연결할 필요 없이 알림에서 근본 원인까지 바로 파악할 수 있습니다. 이 아티클의 나머지 부분에서 이러한 각 항목을 자세히 살펴보겠습니다.

Elasticsearch 메트릭 성능: Prometheus 및 Mimir보다 30배 더 빠름

Datadog과 Prometheus는 동일한 트레이드오프를 강요합니다. 카디널리티가 높은 데이터를 삭제하거나 비용이 급증하는 것을 지켜봐야 합니다. Kubernetes, AWS 또는 카디널리티가 높은 인프라를 관리하는 SRE는 이러한 문제의 구체적인 양상을 잘 알고 있습니다. 인시던트 발생 시 가장 중요한 Kubernetes 레이블, 임시 파드 데이터, 세분화된 OTel 차원은 예산이 빠듯해지면 가장 먼저 삭제됩니다.

Elastic은 시계열 데이터 저장소와 ES|QL 연산 엔진을 완전한 컬럼형 메트릭 엔진으로 재구축했습니다. 새 Kubernetes 레이블, 새 AWS 인스턴스 태그 또는 새 애플리케이션 차원을 추가해도 시스템에 부담이 되지 않으며, 모든 레이블을 인덱싱하는 시스템보다 비용이 훨씬 적게 듭니다. OTel, Prometheus 및 애플리케이션 정의 메트릭은 모두 전체 해상도로 동일한 컬럼형 백엔드에 저장되며, 로그, 트레이스 및 메트릭은 단일 저장소에 저장됩니다. 데이터를 삭제할 필요도, 보존 기간을 단축할 필요도 없습니다.

Elasticsearch는 Prometheus보다 메트릭을 최대 2.5배 더 효율적으로 저장하며(컴팩션 등의 요인으로 인해 결과는 달라질 수 있음), ClickHouse보다 2배 더 효율적으로 저장합니다. ES|QL을 통한 쿼리 성능은 게이지 평균 및 카운터 비율을 대상으로 Prometheus보다 최대 30배 빠르며 경쟁업체가 정체되는 높은 카디널리티 워크로드도 포함됩니다. 아키텍처 게시물 에서는 TSDS가 구성되는 방식과 컬럼형 레이아웃이 이러한 결과를 만들어 내는 이유를 설명합니다.

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | 차원 | vs. Prometheus | vs. Mimir | vs. ClickHouse | | 쿼리 성능(ES|QL) | 최대 30배 더 빠름 | 최대 30배 더 빠름 | 최대 8배 더 빠름 | | 저장 공간 효율 | 최대 2.5배 우수 | 동등한 수준 | 2배 우수 |

핵심적인 아키텍처 차이는 Elasticsearch 메트릭이 카디널리티에 따라 확장되는 시리즈별 인메모리 상태를 유지 관리하지 않으므로, 수천 개의 새로운 Kubernetes 파드 레이블이나 OTel 차원을 추가해도 메모리 압박이 증가하지 않는다는 점입니다.

OTel, Prometheus 네이티브 및 애플리케이션 정의 메트릭은 모두 전체 해상도로 동일한 방식으로 저장되며, 빠르게 쿼리할 수 있고, Datadog 비용의 절반으로 이용할 수 있습니다.

Datadog와는 달리 사용자 지정 메트릭 할증이 없는 Elastic Observability 메트릭 가격

통합 가시성 비용은 팀이 플랫폼을 전환하는 가장 큰 이유입니다. Datadog 고객의 경우, 문제는 사용자 지정 메트릭이라는 한 가지 가격 책정 방식으로 귀결됩니다. Datadog의 내장 통합 기능 외의 사용자 정의 값은 모두 사용자 지정 메트릭으로 분류되어 할증 요금이 부과됩니다. 여기에는 Kubernetes, OpenTelemetry 및 클라우드 네이티브 워크로드가 기본적으로 생성하는 고카디널리티 데이터가 포함됩니다. 계측이 세분화될수록 청구 요금은 더 빠르게 누적됩니다. 현대적인 인프라를 운영하는 팀은 이러한 한계에 빠르게 도달하며, 그에 따른 대응은 예측할 수 있습니다. 데이터를 삭제하고, 보존 기간을 단축하고, 인시던트 발생 시 가장 중요한 컨텍스트를 잃게 됩니다.

Elasticsearch 메트릭은 이러한 구분을 없앱니다. 모든 메트릭은 동일한 요금으로 책정되며, 메트릭별 추가 요금이나 카디널리티 기반 과금, 강제 롤업이 없습니다. 모든 메트릭을 최고 해상도로 유지할 수 있으며, 월말에 예상치 못한 청구서가 날아올 염려도 없습니다. Elastic은 Datadog보다 가격이 50% 저렴하기 때문에 재무팀과의 대화 주제가 바뀝니다. 예산을 맞추기 위해 어떤 데이터를 포기해야 했는지가 아니라, 모든 데이터를 유지함으로써 무엇을 발견할 수 있었는지에 대해 이야기하게 됩니다. 이것이 바로 AI 조사 방식이 효과적인 이유이기도 합니다. Grafana의 파편화된 LGTM 스택과 달리, 알림이 발생할 때 이미 컨텍스트가 통합되어 있으므로 서로 분리된 도구에서 일일이 컨텍스트를 수작업으로 취합할 필요가 없습니다.

Elasticsearch의 Prometheus 및 PromQL 네이티브 지원

대부분의 SRE 팀은 깔끔한 단일 형식의 텔레메트리 파이프라인을 운영하고 있지 않습니다. Prometheus는 애플리케이션, 서비스, 플랫폼 및 자동화에 깊숙이 통합되어 있습니다. 과거에는 메트릭 백엔드를 마이그레이션하려면 쿼리를 다시 작성하고, 대시보드를 재구축하고, 엔지니어를 재교육해야 했습니다. 이러한 부담 때문에 팀은 마이그레이션을 거치기보다는 이미 한계에 이른 플랫폼에 계속 머뭅니다.

Elasticsearch 메트릭은 이러한 마찰을 대부분 해소했습니다. Prometheus 메트릭은 Prometheus Remote Write를 통해 유입되며 의미 변경 없이 동일한 컬럼형 스토어에 저장되어 처음부터 끝까지 완전한 메트릭 충실도를 유지합니다. Mimir 대신 Elasticsearch를 대상으로 지정하면 데이터가 그대로 흐릅니다. 변환 계층도, 기존 스크레이프 설정 변경도 필요하지 않습니다.

이제 Kibana에서 PromQL이 네이티브로 작동하므로, PromQL을 주로 사용하는 엔지니어는 작업 방식을 변경할 필요가 없습니다. 기존 PromQL 쿼리, 대시보드, 알림 규칙이 Kibana로 직접 마이그레이션됩니다. 

PromQL 쿼리는 Elasticsearch에서 변경 없이 작동합니다

팀에서 이미 PromQL을 사용하고 있다면 변경할 사항이 없습니다. 이러한 쿼리는 백엔드로 사용하는 Elasticsearch에서 그대로 실행됩니다. 복사하여 붙여넣기만 하면 바로 시작할 수 있습니다.

CPU 사용률(컨테이너 수준) 파드별로 그룹화한 컨테이너의 초당 CPU 사용률입니다. 인시던트 발생 시 어떤 파드가 CPU를 많이 사용하고 있는지 파악하는 데 유용합니다.

PROMQL sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

메모리 워킹 세트(컨테이너 수준) 컨테이너당 현재 사용 중인 메모리로, 전체 할당된 메모리가 아닌 OOM 위험을 판단할 때 중요한 수치입니다.

PROMQL sum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))

HTTP 요청률(애플리케이션 수준) 인스턴스별로 그룹화된 초당 요청 처리량입니다. 지연 시간 또는 오류 급증을 조사할 때 첫 번째로 확인하는 표준 신호입니다.

PROMQL sum by (instance) (rate(http_requests_total[5m]))

세 가지 모두 표준 PromQL 구문을 따릅니다. Elasticsearch를 백엔드로 사용하는 경우 수정 없이 실행됩니다. 전체 구문과 지원되는 내용을 확인하려면 PromQL 지원 문서를 참조하세요.

네이티브 Prometheus API를 통해 Elasticsearch는 완전한 Prometheus 호환 백엔드가 됩니다. 모든 Prometheus 호환 프론트엔드(Grafana 포함)는 Elasticsearch를 직접 쿼리할 수 있으므로, Elasticsearch로 통합하면서 Grafana를 시각화 계층으로 유지하려는 팀은 기존 대시보드나 알림 규칙을 수정하지 않고도 바로 그렇게 할 수 있습니다.

SRE가 PromQL로 가능한 것보다 더 심층적인 분석이 필요할 때, ES|QL은 단일 인터페이스에서 메트릭, 로그, 트레이스를 모두 다룰 수 있습니다. TS 명령어는 카운터 비율, 게이지 평균, 윈도우 함수, 그리고 카디널리티가 높은 차원에 대한 다단계 집계 등 시계열 관련 기능을 처리합니다. CPU 카운터 비율을 가져오는 동일한 쿼리는 동일한 호스트의 로그와 조인하여 급증에 앞서 발생한 배포 이벤트를 포착할 수 있습니다. 도구 전환도, 새로운 쿼리 언어도 필요 없습니다. 쿼리 언어, 대시보드, 알림 규칙, 시각화 계층, 이 모든 것이 그대로 유지됩니다. 유일하게 달라지는 점은 Elasticsearch가 모든 기능을 뒷받침하는 단일 백엔드가 된다는 것입니다.

Elastic Observability: 기본 제공 대시보드, 알림 및 인프라 콘텐츠

대부분의 통합 가시성 공급업체는 모든 것을 처음부터 구축하도록 요구합니다. Elastic Observability는 세 가지 영역에서 이러한 필요성을 줄였습니다.

Discover에서의 메트릭 탐색. 새로운 Elasticsearch 메트릭 탐색 환경을 통해 SRE는 탭을 전환하거나 쿼리를 중복해서 실행할 필요 없이 로그에 사용하는 것과 동일한 인터페이스에서 메트릭을 탐색할 수 있습니다. OTel 파이프라인 또는 Prometheus 스크레이프 설정을 연결하고 Streams를 열면, 데이터 스트림의 모든 메트릭이 즉시 시계열 차트로 렌더링됩니다. 구축할 대시보드도, 작성할 쿼리도 없습니다. 여기서 팀은 유입되는 흐름의 실시간 뷰를 통해 데이터를 검증하고 패턴을 파악하며 알림 및 SLO 구축을 시작하고, Elasticsearch의 로그, 트레이스 및 기타 색인된 데이터와 교차 상관 분석도 수행할 수 있습니다.

대시보드. Kibana 대시보드에 지연 로딩을 지원하는 접이식 패널이 추가되어 즉시 표시되지 않는 패널은 필요할 때까지 쿼리를 생성하지 않으며, SRE가 새 쿼리를 작성하지 않고도 드롭다운을 통해 시각화를 조작할 수 있는 ES|QL 제어 변수도 추가되었습니다. 또한 코드로 관리하는 대시보드가 제공되어, 여러 환경에서 템플릿화하고 공유하며 프로그래밍 방식으로 배포할 수 있는 버전 관리 대시보드를 구성할 수 있습니다.

즉시 사용 가능한 인프라 콘텐츠.  Elastic은 두 가지 새로운 인프라 OOTB 경험을 제공합니다.

• 새로운 Kubernetes 통합은 계층형 대시보드, 알림 규칙 템플릿, ML 이상 징후 탐색 작업, AI 지원 근본 원인 분석에 필요한 컨텍스트 및 프롬프트를 함께 제공하며, 데이터가 유입되기 시작하는 순간 모두 사전 구성되어 바로 사용할 수 있습니다. 

• AWS 인프라 모니터링도 동일한 패턴을 따릅니다. 인제스트 시 핵심 AWS 서비스를 위한 OOTB 콘텐츠가 활성화되므로, 새로운 서비스나 계정이 온라인 상태가 될 때마다 팀은 처음부터 다시 시작할 필요가 없습니다. 동일한 접근 방식이 데이터베이스 및 기타 핵심 인프라로 확장되어, 플랫폼은 빈 상태가 아니라 적절히 구성된 상태로 제공됩니다.

Elastic Observability를 통한 인프라 전반의 에이전틱 조사

Elasticsearch는 단일 백엔드에서 메트릭, 로그, 트레이스의 상관관계를 분석하므로 엔지니어가 호출되기 전에 조사 컨텍스트가 구성됩니다.

진짜 어려운 순간은 새벽 2시입니다. RDS 인스턴스가 연결 한도에 도달하여 업스트림 서비스의 리소스를 고갈시키고, 오토 스케일링 그룹이 애플리케이션 로그 속에 묻힌 원인으로 상태 확인에 실패하는가 하면, 파드 재시작이 네임스페이스 전체로 연쇄 확산되기도 합니다.

Grafana LGTM 스택에서는 가설을 세우기 위한 충분한 컨텍스트를 확보하기도 전에 3개의 탭을 열어야 합니다.

Datadog에서는 컨텍스트가 통합되어 있지만 AI는 블랙박스입니다. BYO-LLM이나 데이터 레지던시 옵션이 지원되지 않습니다.

Elastic에서는 메트릭, 로그, 트레이스가 단일 백엔드와 공통 스키마를 공유하므로 알림이 발생할 때 조사 컨텍스트가 이미 취합되어 있습니다. 즉 도구 간 수동으로 상관관계를 파악할 필요도 없으며, 쿼리 언어 간 변환 과정에서 컨텍스트가 유실되지도 않습니다. ML 이상 징후 탐색은 인프라 메트릭(Kubernetes, AWS, 데이터베이스)을 대상으로 자동으로 실행되므로, 조사는 단순한 원시 임계값 위반이 아니라 일반적인 상태, 변경된 사항 및 편차의 심각도에 대한 컨텍스트가 포함된 점수화된 이상 징후로부터 시작됩니다.

알림이 발생하면 Elastic의 조사 워크플로우는 담당자에게 호출이 전달되기 전에 신호 간 상관관계를 분석하고, 근본 원인 컨텍스트를 취합하며, 권장되는 다음 단계를 제시합니다. 에이전틱 Kubernetes 통합 가시성 아티클에서는 하나의 완전한 예시를 처음부터 끝까지 단계별로 살펴봅니다. EKS 문제 해결 가이드에서는 Agent Builder와 MCP가 어떻게 협력하여 EC2, EKS 및 관련 AWS 서비스 전반에서 전체 근본 원인 분석 루프를 구현하는지 보여줍니다.

Elastic Observability에서 문제를 조사하는 것 외에도 Claude, Cursor, VS Code 또는 선호하는 도구를 사용하여 Elastic의 MCP 앱과 에이전트 스킬로 문제를 분석할 수 있습니다. Observability MCP 앱은 팀이 이미 작업하는 모든 곳으로 분석 기능을 확장합니다. 팀이 Claude, Cursor 또는 VS Code에서 문제를 조사하는 경우, 동일한 조사 기능(인프라 상태 롤업, 서비스 종속성 그래프, 이상 징후 세부 정보, 영향 범위 분석)이 대화에서 직접 대화형 뷰로 렌더링됩니다. Grafana와 Datadog 모두 이를 제공하지 않습니다.

• Observability MCP 앱 — Claude, Cursor, VS Code 또는 MCP 호환 도구를 Elasticsearch 데이터에 직접 연결하면, 선택한 도구를 벗어나지 않고도 인프라 상태, 서비스 종속성 및 이상 징후 컨텍스트가 대화 내 대화형 뷰로 표시됩니다. Kubernetes에서 어떻게 작동하는지 확인해 보세요.

• 에이전트 스킬 — Kubernetes, AWS 및 기타 핵심 인프라를 위한 사전 구축된 스킬을 통해 Elastic의 에이전트든 사용자가 직접 만든 에이전트든 모든 에이전트가 맞춤형 프롬프트 엔지니어링 없이도 통합 가시성 데이터를 대상으로 구조화된 조사를 실행할 수 있습니다. Claude, Cursor 또는 직접 만든 에이전트 파이프라인에 추가하면 즉시 사용할 수 있습니다. 통합 가시성 스킬에 대해 자세히 알아보거나 GitHub에서 스킬 라이브러리를 둘러보세요.

Datadog 또는 Grafana에서 Elastic Observability로 마이그레이션

SRE 팀이 통합 가시성 플랫폼을 전환하지 않는 가장 일반적인 이유는 마이그레이션입니다. 수년간의 알림 규칙, 수백 개의 대시보드, 런북에 포함된 PromQL 쿼리를 이전하는 것은 매우 힘든 운영 작업이며, 이 작업을 진행하는 동안 기존 스택과 새 스택을 동시에 운영하는 비용도 날이 갈수록 커집니다.

Observability Migration Platform은 변환을 자동으로 처리합니다. CLI 또는 Elastic의 에이전트 스킬이 포함된 Claude/Cursor를 Datadog 조직이나 Grafana 인스턴스를 대상으로 실행하면, 지원되는 대시보드, 알림 규칙 및 PromQL 쿼리를 Kibana 네이티브 형식의 출력으로 변환합니다. 이 도구를 사용하면 완전히 마이그레이션된 항목, 일부 수정이 필요한 항목, 모든 항목을 마이그레이션하기 위해 필요한 작업을 확인할 수 있습니다. 이미 구축한 것을 그대로 이전할 수 있습니다.

인제스트 측면에서는 Prometheus Remote Write를 사용하므로 파이프라인을 변경할 필요가 없습니다. 스크레이프 설정에서 다른 Prometheus 호환 백엔드 대신 Elasticsearch를 대상으로 지정하며, 데이터는 동일한 컬럼형 스토어에 저장됩니다. 워크플로우, 쿼리 및 알림 설정이 변경 없이 그대로 유지됩니다. 마이그레이션 중이나 그 이후에도 Grafana를 시각화 계층으로 유지하려는 팀은 Kibana의 Prometheus API 및 PromQL 네이티브 지원을 통해 한 번에 전체를 전환하지 않고 단계적으로 전환할 수 있습니다.

Grafana의 백엔드로 사용하는 Elasticsearch

Grafana를 떠날 준비가 되지 않은 팀에게 백엔드 교체는 그 자체로 마이그레이션 경로이며, 워크플로우에 따라 두 가지 방법으로 진행할 수 있습니다.

현재 팀에서 Prometheus를 사용하고 있다면, 가장 부담 없는 방법은 Grafana의 Prometheus 데이터 소스를 사용하는 것입니다. 이제 Elasticsearch는 네이티브 Prometheus 호환 API를 제공하므로, Grafana의 기존 Prometheus 플러그인이 직접 Elasticsearch를 가리키도록 설정할 수 있습니다. 사이드카도, 어댑터도 필요 없으며 파이프라인을 변경할 필요도 없습니다. Grafana의 Metrics Drilldown 탐색기를 비롯하여 기존 PromQL 대시보드, 알림 규칙, 변수 드롭다운을 수정 없이 그대로 사용할 수 있습니다. Prometheus 설정에서 Elasticsearch를 remote_write 대상으로 추가하고 데이터 소스 URL을 교체하세요. 대부분의 팀에서는 이것으로 마이그레이션이 완료됩니다. 전체 설정 가이드를 참조하세요.

한 걸음 더 나아가 단일 Grafana 쿼리 편집기에서 로그, 메트릭 및 트레이스를 함께 쿼리하려는 팀을 위해, 이제 공식 Grafana Elasticsearch 플러그인에서 ES|QL을 지원합니다. 이를 통해 Grafana에서 직접 교차 신호 상관 분석을 수행할 수 있으며, Elasticsearch는 통합 컬럼형 백엔드에서 세 가지 데이터 유형을 모두 처리합니다. 설정 방법을 확인해 보세요.

어떤 방법을 선택하든, Grafana는 그대로 유지하고 Mimir와 Loki를 교체하면 Elasticsearch의 컬럼형 저장 공간과 쿼리 성능이 제공하는 모든 이점을 누릴 수 있습니다. 수년간의 운영 작업이 그대로 보존되고, 팀들이 계속 미뤄 오던 마이그레이션을 백엔드 교체만으로 해결할 수 있습니다.

GA와 기술 프리뷰에는 무엇이 포함되나요?

| 기능 | 상태 | | ----------------------------------------- | ------------ | | 컬럼형 메트릭 엔진(TSDS) | GA | | ES|QL 시계열 지원 | GA | | Kibana의 PromQL 지원 | GA | | Prometheus Remote Write 인제스트 | GA | | Kubernetes 인프라 OOTB 경험 | GA | | AWS 인프라 OOTB 경험 | 기술 프리뷰 | | Observability MCP 앱 | 기술 프리뷰 | | 에이전트 스킬 | 기술 프리뷰 | | Observability Migration Platform | 기술 프리뷰 |

본문에 링크된 개별 게시물에서는 GA와 프리뷰의 구체적인 세부 사항 및 알려진 제한 사항을 다룹니다.

이 모든 기능(컬럼형 메트릭 엔진, 네이티브 PromQL, 에이전트 기반 조사, 마이그레이션 도구)은 Elastic의 세 가지 배포 모드인 서버리스, Elastic Cloud, 자체 관리형에서 모두 실행됩니다. Datadog에는 온프레미스 옵션이 없으며, Grafana Cloud는 가장 유용한 기능을 호스팅된 배포로 제한합니다. Elastic을 사용하면 데이터가 저장되는 위치를 직접 선택할 수 있습니다.

Elastic Observability: 데이터 누락 없이 비용 절감

현대적인 클라우드 인프라는 개별 신호에 따라 별도의 도구로 구축된 통합 가시성 모델을 무너뜨렸습니다. 실제로 비용이 발생합니다. 중복되는 도구 비용, 인시던트 발생 시 수작업으로 상관관계를 분석하는 작업, 예산을 맞추기 위해 어쩔 수 없이 삭제되는 데이터 등이 그 예입니다.

모든 신호를 효율적으로 저장하는 단일 백엔드를 사용하면 일반적으로 발생하는 비용 부담 없이 필요한 테이터를 유지할 수 있습니다. 재무 부서와는 다른 대화를 나누게 됩니다. "예산을 지키기 위해 데이터를 삭제해야 했습니다"가 아니라 "이런 내용을 발견했습니다"라고 이야기할 수 있습니다. AI는 하나의 그림만을 보기 때문에 전체 상황을 파악할 수 있으며, 플랫폼은 충분한 사전 구축 콘텐츠를 제공하므로 몇 주 동안 대시보드를 구축하는 수고를 들이지 않아도 첫날부터 유용하게 사용할 수 있습니다.

이는 Elasticsearch가 여러분이 교체하려는 기존 플랫폼과는 다르게 구축되었기 때문에 가능한 것입니다.

• 컬럼형 메트릭 저장 공간은 TSDS 인덱스 모드에서 메트릭 데이터를 매우 효율적으로 저장합니다. 

• 네이티브 Prometheus 호환성을 통해 기존 스크레이프 설정, PromQL 쿼리 및 대시보드를 재작성하지 않고 그대로 사용할 수 있습니다.

• 단일 백엔드에서 통합된 메트릭, 로그 및 트레이스를 사용하면 조사 컨텍스트가 여러 탭에서 수동으로 구성되는 것이 아니라 쿼리 시점에 구성됩니다.

• 동일한 엔진에서 검색 및 분석 — 로그에는 역 인덱스를, 메트릭에는 컬럼형 인덱스를 사용하며 ES|QL을 통해 함께 쿼리할 수 있습니다.

• 담당자에게 호출이 전달되기 전에 신호 간 상관관계를 분석하고, 이상 징후를 파악하며, 해결 방안을 제시하는 에이전틱 조사.

• 서버리스, Elastic Cloud 또는 자체 관리형 — 데이터가 저장되는 위치를 직접 선택할 수 있으며, Datadog에서는 이를 제공하지 않습니다.

재무 부서와의 비용 관련 논의는 지출액이 아니라 발견한 내용에 초점을 맞추게 됩니다.

시작하기

• 무료 체험판 시작하기

• Elastic Observability 문서

• Elastic Observability Labs

자주 묻는 질문

Elasticsearch는 이제 프로덕션 환경에서 사용할 수 있는 메트릭 플랫폼인가요?

네. 2026년 6월 기준, Elasticsearch는 시계열 데이터 전용으로 설계된 컬럼형 저장 공간 엔진, 네이티브 Prometheus Remote Write 인제스트, Kibana에서의 PromQL 지원, ES|QL 시계열 쿼리 기능, Kubernetes 및 AWS용 기본 인프라 대시보드를 제공합니다. 컬럼형 메트릭 엔진, ES|QL 시계열 지원, PromQL 및 Prometheus 인제스트 기능은 모두 Elastic Serverless에서 정식 출시되었으며, Elastic Cloud Hosted에서도 곧 정식 출시될 예정입니다.

Elasticsearch와 Datadog의 메트릭 비용은 어떤 차이가 있나요?

유사한 메트릭 워크로드에서 Elastic Observability Serverless는 Datadog보다 비용이 훨씬 적게 듭니다. 공개된 정가를 기준으로 한 예시에서는 50% 이상 저렴하며, 대개 3분의 2에 가까운 수준으로 저렴합니다. 이러한 격차는 과금 구조에서 비롯됩니다. Datadog은 주로 호스트별로 요금을 청구하며, 계측 범위가 확대되면 커스텀 메트릭 및 컨테이너 요금을 추가로 부과합니다. 비용 차이는 Datadog가 가장 많은 요금을 청구하는 워크로드, 즉 Kubernetes 및 OTel과 같이 카디널리티가 높고 계측이 촘촘하게 적용된 환경에서 가장 큽니다.

Elasticsearch 메트릭 성능은 Prometheus 및 Grafana Mimir와 어떻게 다른가요?

Elasticsearch에서 ES|QL 쿼리는 높은 카디널리티 워크로드를 포함하여 게이지 평균 및 카운터 비율에서 Prometheus 및 Mimir보다 최대 30배 더 빠르게 실행됩니다. Elasticsearch는 데이터 요소당 3.75바이트로 OTel 메트릭을 저장하며, 이는 Prometheus보다 최대 2.5배, ClickHouse보다 2배 더 효율적입니다.

팀은 모든 것을 처음부터 다시 구축하지 않고 Datadog 또는 Grafana에서 Elasticsearch로 마이그레이션할 수 있나요?

네. Elastic의 Observability Migration Platform은 Datadog 및 Grafana 대시보드와 알림 규칙을 변환하고, PromQL 쿼리를 있는 그대로 Kibana로 마이그레이션합니다. 팀은 Kibana의 기본 Prometheus API 및 PromQL 지원을 활용하여 백엔드를 Elasticsearch로 교체하면서 Grafana를 시각화 계층으로 유지할 수도 있습니다.

메트릭 통합 가시성 측면에서 Elasticsearch와 Grafana는 어떻게 다른가요?

Elasticsearch는 하나의 쿼리 언어(ES|QL)를 사용하여 메트릭, 로그 및 트레이스를 단일 통합 백엔드에 저장하는 반면, Grafana의 LGTM 스택은 메트릭(Mimir/Prometheus)과 로그(Loki)를 별도의 백엔드로 분리하므로 별도의 쿼리 언어가 필요합니다. Elasticsearch는 AI 에이전트, 워크플로우, MCP App, 에이전트 스킬을 포함하는 에이전틱 조사 기능도 제공하며, 이는 Grafana보다 더 포괄적인 기능 집합입니다. 

Elasticsearch는 Prometheus 및 PromQL을 네이티브로 지원하나요?

네, 두 가지 방식으로 지원됩니다. 첫째, Elasticsearch는 Prometheus Remote Write를 통해 Prometheus 메트릭을 수용하고 기본 Prometheus 호환 API를 노출하므로, Grafana를 비롯한 모든 Prometheus 호환 프런트엔드의 백엔드 역할을 할 수 있습니다. 둘째, Kibana는 PromQL을 기본적으로 지원하므로 기존 쿼리, 대시보드, 알림 규칙을 변환 계층이나 수정 없이 Kibana에서 직접 실행할 수 있습니다.

Elastic Observability에는 어떤 인프라 모니터링 콘텐츠가 기본으로 제공되나요?

Elastic은 호스트, 컨테이너, 클라우드 서비스, 데이터베이스, 네트워크 장치 등을 포괄하는 수백 개의 인프라 통합 전반에 걸쳐 사전 구축된 대시보드, 알림 템플릿 및 ML 이상 징후 탐색 작업을 제공합니다. 특히 Kubernetes 및 AWS의 경우, 이 플랫폼에는 팀이 Claude, Cursor 또는 VS Code에서 직접 조사를 실행할 수 있도록 하는 에이전트 스킬, Observability MCP 앱 같은 에이전틱 조사 콘텐츠도 포함되어 있습니다. 이 모든 기능은 별도의 설정 없이 인제스트 시점에 바로 사용할 수 있습니다.

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).