.svg)
%201.svg)
%201.svg){kind=icon}
담당자가 프로모션 코드를 발송해 드립니다.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
WhaTap AI를 경험해 보세요.
OpenMetrics, Prometheus, OpenTelemetry 차이와 관계 한눈에 정리
OpenMetrics, Prometheus, OpenTelemetry. 모니터링을 들여다보면 이 세 이름을 자주 만납니다. 그런데 막상 셋이 무엇이 같고 무엇이 다른지, 서로 어떤 관계인지 물으면 선뜻 답하기 어렵습니다.
이 글에서는 세 표준의 정의와 실제 차이, 그리고 함께 쓰이는 방식을 차례로 짚습니다. 다 읽고 나면 셋을 또렷하게 구분할 수 있습니다.
OpenMetrics, Prometheus, OpenTelemetry란?
세 이름은 비슷해 보이지만 서로 다른 층을 맡습니다. OpenMetrics는 메트릭을 적는 형식이고, Prometheus는 그 메트릭을 모아 보관하고 조회하는 도구이며, OpenTelemetry는 메트릭뿐 아니라 트레이스·로그까지 함께 실어 나르는 더 넓은 프레임워크입니다. 서로 경쟁하는 대체재가 아니라 역할이 다르다고 보면 됩니다.
OpenMetrics 정의
OpenMetrics는 시계열 메트릭을 텍스트로 노출하기 위한 전송 형식(wire format) 표준입니다. Prometheus가 쓰던 exposition format을 바탕으로, 모호한 부분을 다듬고 규칙을 엄격하게 명문화한 사양입니다.
OpenMetrics 1.0은 2020년 11월에 공개됐습니다. 애초 목표는 이 형식을 특정 도구에 종속되지 않는 중립 표준으로 만들고, 나아가 인터넷 표준을 개발하는 IETF의 공식 표준으로 올리는 것이었습니다.
핵심만 추리면 이렇습니다. OpenMetrics는 Prometheus 형식을 대체하려고 만든 것이 아니라, 그 형식을 더 정밀하게 규격화한 상위 호환 버전입니다. 그래서 둘은 사실상 같은 뿌리를 공유합니다.
Prometheus 정의
Prometheus는 메트릭을 시계열로 수집·저장하고 PromQL이라는 자체 쿼리 언어로 조회하는 오픈소스 모니터링 시스템입니다. 2012년에 처음 만들어졌고 지금은 CNCF가 관리합니다.
Prometheus는 모니터링 도구이면서, 메트릭을 노출하는 텍스트 형식(exposition format)의 이름이기도 합니다. 이 형식이 워낙 널리 퍼지면서 수많은 도구가 같은 모양으로 메트릭을 내보내게 됐고, 사실상의 업계 표준으로 자리 잡았습니다. OpenMetrics는 바로 이 형식에서 갈라져 나온 사양입니다.
OpenTelemetry 정의
OpenTelemetry(줄여서 OTel)는 트레이스·메트릭·로그를 하나의 규격으로 수집하고 전송하기 위한 벤더 중립 관측 프레임워크입니다. 역시 CNCF 프로젝트로, 특정 모니터링 제품에 묶이지 않는 공통 표준을 지향합니다.
핵심은 OTLP(OpenTelemetry Protocol)라는 전송 규격과 여러 언어용 계측 라이브러리입니다. 메트릭 노출 형식에 집중하는 Prometheus·OpenMetrics와 달리, 세 종류의 관측 데이터를 함께 묶어 다룬다는 점이 가장 큰 차이입니다.
OpenMetrics와 Prometheus는 무엇이 다른가
Prometheus exposition format은 오랫동안 사실상의 표준 역할을 해왔지만, 사양 문서보다 구현이 먼저 자리 잡은 형식이었습니다. 같은 형식을 두고 도구마다 미묘하게 다르게 처리하는 일이 생긴 배경입니다.
OpenMetrics는 이 느슨함을 줄였습니다. 카운터 메트릭 이름에 _total 접미사를 강제하고, 노출 본문의 끝을 # EOF 마커로 명확히 닫도록 정했습니다. 파싱하는 쪽이 데이터가 어디서 끝나는지 추측하지 않아도 됩니다.
타입도 늘렸습니다. 기존 Gauge·Counter·Histogram·Summary에 더해, 변하지 않는 메타데이터를 담는 Info, 여러 불리언 상태를 한데 표현하는 StateSet, 누적이 아닌 현재 분포를 나타내는 GaugeHistogram을 추가했습니다. 콘텐츠 타입도 application/openmetrics-text로 분리해, 클라이언트가 어떤 형식을 받는지 협상할 수 있게 했습니다.
아래 표는 두 형식의 차이를 항목별로 정리한 것입니다.
다음은 OpenMetrics 형식으로 카운터 하나를 노출한 간단한 예시입니다. 마지막 줄의 # EOF가 본문의 끝을 명시합니다.
타입과 설명을 주석으로 선언하고, 데이터 줄 끝에 초 단위(소수점 허용) 타임스탬프를 붙이며, # EOF로 닫는 구조를 그대로 확인할 수 있습니다.
OpenMetrics, Prometheus, OpenTelemetry는 어떤 관계인가
OpenMetrics와 Prometheus를 같은 계보로 보면, 남는 질문은 OpenTelemetry를 어디에 놓아야 하느냐입니다. 셋의 관계를 정리해두면 표준 지형이 한결 또렷해집니다.
Prometheus 형식과 OpenMetrics는 메트릭을 어떤 모양의 텍스트로 노출할지를 정하는 형식이고, OpenTelemetry는 트레이스·메트릭·로그를 함께 다루는 더 넓은 규격이라는 점에서 둘과 구분됩니다. 세 표준을 한눈에 비교하면 다음과 같습니다.
실제로는 어떻게 함께 쓰일까
세 표준은 경쟁 관계가 아니라 한 파이프라인 안에서 역할을 나눠 맡습니다. 흔한 흐름은 이렇습니다.
- 애플리케이션이나 익스포터가 메트릭을 Prometheus·OpenMetrics 형식으로 노출합니다.
- Prometheus 서버나 OpenTelemetry 수집기가 그 엔드포인트를 풀 방식으로 스크랩합니다.
- OpenTelemetry 수집기를 거치는 경우, 스크랩한 메트릭을 OTLP로 변환해 백엔드로 보냅니다. 이때 Prometheus 카운터는 OTLP에서 단조 증가하는 Sum으로 변환됩니다.
덕분에 지금 쓰던 방식을 바꾸지 않아도 됩니다. 애플리케이션이 Prometheus·OpenMetrics 형식으로 메트릭을 내보내던 부분은 그대로 두고, 그 메트릭을 OpenTelemetry 쪽으로도 함께 흘려보낼 수 있습니다. 나중에 트레이스·로그까지 한곳에서 보고 싶어졌을 때, 메트릭을 처음부터 다시 만들 필요가 없는 셈입니다. 내보내는 형식은 손대지 않고, 필요한 표준으로 옮겨 담기만 하면 됩니다.
그래서 셋은 어느 하나를 고르는 문제가 아니라, 메트릭을 어떤 형식으로 적고 어떤 도구로 모으고 무엇으로 실어 나를지를 각각 맡기는 구도에 가깝습니다.
자주 묻는 질문
OpenMetrics가 Prometheus에 병합됐는데, 지금도 알아야 하나요.
알아두는 편이 좋습니다. 프로젝트는 아카이브됐지만 형식 자체가 사라진 것이 아닙니다. 여기서 아카이브란 프로젝트를 더 이상 따로 개발하지 않고 보존 상태로 둔다는 뜻이지, 형식이 폐기됐다는 의미가 아닙니다. 코드와 문서는 읽기 전용으로 그대로 남고, 규격은 Prometheus 안으로 옮겨가 계속 쓰입니다. CNCF 발표는 OpenMetrics가 "원래 자리인 Prometheus 형식으로 돌아갔다"고 표현했습니다. 별도 프로젝트라는 껍데기만 정리됐을 뿐, 규격은 Prometheus 안에서 계속 살아 있습니다. 카운터 _total 규칙이나 # EOF 같은 약속은 여전히 유효합니다.
기존 Prometheus 형식과 호환되나요.
OpenMetrics는 Prometheus 형식의 상위 호환이 되도록 설계됐습니다. 그래서 기존 Prometheus 노출을 읽던 수집기 대부분이 OpenMetrics 노출도 큰 문제 없이 처리합니다. 다만 Info나 StateSet 같은 OpenMetrics 고유 타입은 수신 쪽이 이를 지원해야 의도대로 해석됩니다.
왜 두 형식이 따로 존재했던 건가요.
CNCF 발표에 따르면, 한 프로젝트가 도구이면서 동시에 사양일 수 있다는 점이 분리의 명분을 약하게 만들었습니다. 형식을 두 이름으로 부르다 보니 사용자에게 혼란만 늘었고, 결국 하나로 합치는 쪽이 합리적이라는 판단이었습니다.
마치며
OpenMetrics는 사라진 표준이 아니라 Prometheus 형식 안으로 흡수된 규격이며, 카운터 접미사·종료 마커·타입 확장 같은 약속은 지금도 메트릭을 다루는 기준으로 남아 있습니다. 메트릭 표준의 계보를 이해하면 어떤 형식으로 노출하고 무엇으로 수집할지 판단하기가 수월해집니다.
여러 시스템의 OpenMetrics·Prometheus 메트릭을 한곳에서 수집하고 분석하려는 단계라면, 와탭의 OpenMetrics 수집 기능과 공식 문서를 함께 살펴보시기 바랍니다.
더 읽을거리
