강력한 기능을 더한 Elasticsearch: 네이티브 Prometheus API 지원 추가

Prometheus 호환 클라이언트를 Elasticsearch로 지정하고 기존 메트릭에 PromQL을 직접 실행하세요. Elasticsearch는 Prometheus Remote Write, OpenTelemetry 또는 벌크 API를 통해 수집된 메트릭에 작동하는 기술 미리 보기로 기본 Prometheus 쿼리, 탐색 및 메타데이터 엔드포인트를 추가합니다. API는 Elasticsearch의 시계열 데이터 스트림(TSDS)에서 실행되므로 별도의 Prometheus 전용 저장 공간 계층을 운영할 필요가 없습니다.

이 게시물은 쿼리, 탐색 및 메타데이터 엔드포인트가 이전의 인제스트 및 쿼리 작업을 기반으로 해당 API 표면을 형성하는 방법을 설명합니다. 동반 게시물에서 개별 항목을 더 깊이 있게 다룹니다.

• ES|QL의 네이티브 PromQL 지원에서는 PromQL 쿼리가 ES|QL 실행 계획으로 변환되는 방법을 설명합니다.
• Remote Write로 Prometheus 메트릭을 Elasticsearch로 전송에서는 수집 설정을 설명합니다.
• Elasticsearch에서 Prometheus Remote Write 수집이 작동하는 방식에서는 Remote Write의 내부 작동 방식을 설명합니다.

이는 여전히 진행 중인 작업입니다. 아래 섹션에서는 현재 지원되는 부분과 계속 발전 중인 부분을 설명합니다.

API 인터페이스 범위

현재 Prometheus와 호환되는 API 인터페이스 범위는 세 가지 그룹으로 나뉩니다.

쿼리 엔드포인트

쿼리 엔드포인트를 통해 Prometheus 호환 클라이언트는 PromQL 표현식을 평가할 수 있습니다.

• GET /_prometheus/api/v1/query_range 시간 범위 내에서 PromQL 표현식을 평가합니다(행렬 결과).
• GET /_prometheus/api/v1/query 특정 시점에서 평가합니다(벡터 결과). 현재는 마지막 샘플을 반환하는 단기 범위 쿼리로 구현되어 있습니다.

현재 쿼리 엔드포인트에는 GET만 지원됩니다. 일부 클라이언트는 기본적으로 POST로 설정되어 있으므로 GET을 사용하도록 구성해야 할 수도 있습니다. Prometheus POST 규칙은 application/x-www-form-urlencoded 본문을 사용하며, Elasticsearch의 HTTP 레이어는 CSRF 보호 조치로 요청이 핸들러에 도달하기 전에 이를 거부합니다.

PromQL 지원 현황에 대한 자세한 내용은 ES|QL의 PromQL 관련 동반 게시물을 참조하세요.

메타데이터 엔드포인트

메타데이터 엔드포인트는 클라이언트가 자동 완성, 가변 드롭다운 및 메트릭 탐색에 필요한 검색 정보를 제공합니다.

시리즈, 레이블 및 레이블 값 엔드포인트는 모두 match[] 선택자와 시간 범위(start/end)을(를) 허용합니다. match[] 매개변수는 http_requests_total{job="api"} 같은 Prometheus 시리즈 선택자를 사용하여 일치하는 시계열로 응답을 제한합니다. 이렇게 하면 많은 수의 메트릭이 있는 클러스터에서 응답을 빠르고 관련성 있게 유지할 수 있습니다. 그 예는 다음과 같습니다.

첫 번째는 job="api", 전체 레이블 세트가 있는 http_requests_total 에 대한 모든 시리즈를 반환합니다. 두 번째는 http_requests_total 시리즈에 존재하는 레이블 이름만 반환합니다. 세 번째는 일치하는 시리즈에 나타나는 instance 값만 반환합니다.

GET /_prometheus/api/v1/metadata 이는 다릅니다. 각 메트릭의 유형과 단위를 반환하며, 선택적으로 metric 매개변수를 통해 이름으로 필터링할 수 있습니다.

match[] 선택자나 시간 범위는 허용하지 않습니다. Prometheus에서 메타데이터는 활성 스크랩 대상( 해당 대상이 노출하는 HELP, TYPE, UNIT 줄)에서 수집되므로 응답에는 데이터 스캔이 포함되지 않습니다. Elasticsearch에는 이와 같은 전용 메타데이터 저장소가 없기 때문에 현재 구현에서는 지난 24시간 동안의 시계열 데이터를 방문하여 메트릭 메타데이터를 검색합니다. 이렇게 하면 전체 인덱스 스캔 없이도 쿼리를 빠르게 처리할 수 있습니다. 24시간 룩백은 현재 수정되었습니다. Prometheus 메타데이터 API는 Elasticsearch가 사용자 조정을 위해 사용할 수 있는 start 또는 end 매개변수를 노출하지 않습니다.

메타데이터 엔드포인트가 내부적으로 작동하는 방식, 그리고 이를 구동하는 TS_INFO 및 METRICS_INFO 명령을 포함하여 자세한 내용은 아래에서 설명합니다.

인덱스 사전 필터링

모든 쿼리 및 메타데이터 엔드포인트는 /_prometheus/ 뒤에 {index} 경로 세그먼트(선택 사항)를 허용합니다.

이렇게 하면 표현식 평가가 시작되기 전에 쿼리가 실행되는 Elasticsearch 인덱스가 제한됩니다. 팀이나 환경 전체에 걸쳐 많은 데이터 스트림이 있는 클러스터에서 이렇게 하면 관련 없는 인덱스를 스캔하는 것을 방지할 수 있으며 쿼리 지연 시간을 크게 줄일 수 있습니다. 인덱스 패턴별로 별도의 데이터 소스를 구성하여 팀에 자체 메트릭에 대한 범위 지정 액세스를 제공할 수 있습니다.

Remote Write 참고 사항

수집을 위해 다음과 같이 Elasticsearch는 표준 Prometheus Remote Write 엔드포인트도 노출합니다.

• POST /_prometheus/api/v1/write Prometheus Remote Write v1 프로토콜을 통해 시계열 데이터를 수집합니다.

Remote Write는 별도의 Prometheus 전용 저장 공간 레이어가 아닌 Elasticsearch의 기존 시계열 데이터 스트림(TSDS)에 씁니다. Prometheus 레이블은 TSDS 차원이 되고 메트릭 이름은 인덱스 매핑에서 필드가 됩니다. Remote Write 아키텍처 게시물에서는 메트릭 유형이 추론되는 방법과 labels. 접두사로 레이블을 저장하는 방법을 포함해 전체 매핑을 자세히 설명합니다.

참여 방법

내부적으로 모든 엔드포인트는 동일한 방식으로 작동합니다. 수신되는 HTTP 매개변수를 구문 분석하고, ES|QL 쿼리 계획을 수립하고, 시계열 데이터 스트림에 대해 쿼리를 실행한 다음, 열 형식의 결과를 Prometheus 클라이언트가 예상하는 JSON 형식으로 다시 변환합니다.

TS_INFO 및 METRICS_INFO

메타데이터 엔드포인트는 모든 데이터 요소를 스캔하지 않고도 수백만 개의 시계열 데이터에 걸쳐 "어떤 레이블이 존재합니까?" 또는 "어떤 메트릭 유형이 정의되어 있습니까?"와 같은 질문에 답해야 합니다.

내부적으로 Prometheus 메타데이터 엔드포인트는 METRICS_INFO 와(과)TS_INFO 라는 두 가지 새로운 처리 명령을 중심으로 ES|QL 계획을 수립하여 이러한 질문에 답합니다. 이러한 명령은 Prometheus API를 사용하기 위해 직접 사용할 필요는 없지만 메타데이터 응답의 핵심 실행 단위입니다. 두 명령 모두 모든 샘플을 스캔하는 대신 시계열당 하나의 문서만 방문하여 메타데이터를 추출하는 방식으로 작동합니다. 즉, 데이터 요소의 수가 아니라 고유한 시계열의 수에 따라 비용이 달라집니다.

METRICS_INFO 각 고유 메트릭별로 이름, 유형, 단위 및 관련 차원 필드를 포함하는 행을 하나씩 반환합니다. TS_INFO은(는) 더 세분화되어 (메트릭, 시계열) 조합별로 행을 하나씩 반환하며, 실제 차원 값은 JSON 객체로 포함됩니다.

TS_INFO 및 METRICS_INFO에 대한 자세한 블로그 게시물이 곧 올라올 예정이며, 2단계 실행 모델, 확장 방법, Prometheus API를 넘어 ES|QL 쿼리에서 직접 사용하는 방법을 설명합니다.

메타데이터 엔드포인트의 사용하는 방법

각 메타데이터 엔드포인트는 이러한 명령 중 하나를 핵심으로 사용하여 ES|QL 실행 계획을 구성합니다.

/api/v1/labels 그리고 /api/v1/series 은(는) 시계열별 세부 정보(어떤 레이블이 있는지, 어떤 차원 값이 각 시리즈를 식별하는지)가 필요하므로 TS_INFO 을(를) 사용하고, /api/v1/metadata 와 /api/v1/label/__name__/values 은(는) 메트릭별 정보(메트릭 이름, 유형, 단위)만 필요하므로 METRICS_INFO 을(를) 사용합니다.

/api/v1/label/{name}/values 일반 레이블( __name__ 이외의 모든 레이블)은 두 명령을 사용하지 않습니다. job 또는 instance 같은 일반 레이블은 인덱스의 실제 차원 필드이므로 엔드포인트에서 그룹별 집계를 사용하여 직접 쿼리할 수 있습니다. match[] 선택자가 제공되면 집계가 실행되기 전에 시계열을 필터링하는 WHERE 절로 변환됩니다.

__name__ 레이블은 항상 차원 필드로 존재하는 것은 아니므로 다른 전략이 필요합니다. Prometheus Remote Write는 labels.__name__ 을(를) 저장하지만, 다른 경로(OpenTelemetry, 벌크 API)를 통해 수집된 메트릭에는 이 레이블이 없습니다. 메트릭 이름은 필드 이름 자체에 인코딩됩니다(예: metrics.http_requests_total). 인덱스 매핑을 보고 필드 이름을 열거할 수 있지만, 매핑만으로는 어떤 메트릭에 어떤 차원이 있는지 알 수 없으며 match[] 선택자의 레이블 값으로 필터링할 수 없습니다. METRICS_INFO 은(는) 두 가지 모두 가능합니다. 즉, 업스트림 WHERE 필터를 준수하면서 인덱스 전체에서 메트릭 이름을 열거합니다.

모든 경우에 API 레이어는 labels. 및 metrics. 저장 공간 접두사를 제거하고, 해당 접두사가 없는 Prometheus가 아닌 메트릭의 경우__name__ (으)로 합성하는 등 Prometheus 규칙으로 다시 변환을 처리합니다.

결론

결과: 모든 Prometheus 호환 클라이언트는 이미 이해하고 있는 엔드포인트를 통해 Elasticsearch 메트릭을 쿼리하고 탐색할 수 있습니다. Remote Write 메트릭, OpenTelemetry 메트릭, 다른 경로를 통해 인덱싱된 지표는 모두 동일한 API를 통해 표시되며, 동일한 TSDS 인덱스로 뒷받침됩니다.

여기서 언급된 모든 Prometheus API는 오늘 Elasticsearch Serverless에서 기술 미리 보기로 제공됩니다. 자체 관리 클러스터 및 Elastic Cloud Hosted 배포의 경우, GET /_prometheus/api/v1/metadata을(를) 제외하고 Elasticsearch 9.4에서 기술 미리 보기로 제공됩니다. 로컬에서 실험하려면 start-local을 사용하세요.

자주 묻는 질문