Elasticsearch: 동급 최고의 로그, 이제는 동급 최고의 메트릭

Store high-cardinality metrics efficiently with time series data streams, and keep your Prometheus and PromQL workflows along for the ride. 

Dig into infrastructure and metrics monitoring. Start a free cloud trial or try Elastic on your local machine now.

지난 몇 달 동안 Elastic은 시계열 데이터를 위해 특수 제작된 Elasticsearch의 컬럼형 스토리지 엔진, 네이티브 Prometheus 인제스트 및 저장 공간, PromQL 지원을 출시했으며, 새로운 메트릭 탐색 환경, 사전 구축된 인프라 대시보드, 에이전트 기반 조사, 그리고 Datadog 및 Grafana로부터의 마이그레이션 경로를 제공했습니다. 이제 다음과 같은 기능이 포함됩니다.

• 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가 구성되는 방식과 컬럼형 레이아웃이 이러한 결과를 만들어 내는 이유를 설명합니다.

핵심적인 아키텍처 차이는 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와 기술 프리뷰에는 무엇이 포함되나요?

본문에 링크된 개별 게시물에서는 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 앱 같은 에이전틱 조사 콘텐츠도 포함되어 있습니다. 이 모든 기능은 별도의 설정 없이 인제스트 시점에 바로 사용할 수 있습니다.