☀️

Metric, Trace. Istio vs OpenTelemetry?

Introduction

Kuberetes / Istio 환경에서 traffic metrics와 distributed tracing을 가장 효과, 효율적으로 취하기 방법에 대한 사전 조사이다. 결론부터 말하자면, traffic metrics로는 Istio가 생성하는 metric을, distributed tracing으로는 OpenTelemetry eBPF Instrumentation(OBI) 또는 Grafana Beyla가 생성하는 trace를 사용하는 것이 좋다.

Summary

•

Istio와 OpenTelemetry는 MLT(Metric, Log, Trace) 모두에 대해 자체적인 프로토콜과 측정 runtime을 갖는다. 이는 역할 상 중복으로 결국 하나를 선택해야 하며, Istio의 trace에는 제약이 있다.

•

Otel(OpenTelemetry)의 Distribute tracing 솔루션으로는 eBPF 기반 Zero-code Instrumentation을 선택한다. 이 솔루션에는 OpenTelemetry eBPF Instrumentation(OBI), Beyla가 있지만 양자 모두 사실 상 동일 솔루션이기에 무엇을 쓰건 별 차이가 없다.

•

OBI, Beyla 역시 traffic metric을 생성하지만, 이는 Istio에게 맞기고 trace와 나머지 metric만 사용하는 것이 최선으로 보인다.

Context

•

Istio와 OpenTelemetry는 MLT(Metric, Log, Trace) 모두에 대해 자체적인 프로토콜과 측정 runtime을 갖는다. 이는 역할 상 중복으로 결국 하나를 선택해야 한다. 이 때 Otel의 측정 runtime(instrumentation)은 Istio의 것으로 충분하다면 굳이 운용할 필요가 없다(즉, Otel Collector만 운용한다).

•

Trace(Distributed Tracing)의 경우 Istio는 context propagation을 못한다. 따라서 app에서 이를 수행해야 한다. 자세한 내용은 Trace context propagation  을 참고한다.

•

Istio Ambient Mesh가 생성하는 application level의 trace는 Istio Waypoint의 것 뿐이다. 따라서 제대로 된 app의 trace를 얻을 수 없기에 Waypoint의 trace를 통해 간접적으로만 확인 가능하다. 자세한 내용은 제약 사항: application span 미지원 을 참고한다.

•

위 제약으로 인해 trace는 OpenTelemetry Instrumentation 사용을 고려해야 하는데, OpenTelemetry Instrumentation에는 여러 옵션이 존재하기에 선택이 요구된다. 나아가 OpenTelemetry 역시 자체적으로 traffic metrics를 제공하기에 Istio의 metric과 비교 및 선택이 요구된다. OpenTelemetry Instrumentation에 대한 자세한 내용은 Instrumentation 을 참고한다.

위와 같은 맥락으로 인해 어쨌건 OpenTelemetry Instrumentation을 검토해야하는 상황인데, Code-based Instrumentation은 app에 특화된 무엇이 요구될 때나 쓸 무엇임을 고려하자면, 결국 Zero-code Instrumentation을 먼저 알아보는 것이 자연스럽다.

근래까지의 OTel Zero-code Instrumentation

OpenTelemetry의 언어별 Instrumentation 지원 및 Zero-code Instrumentation 메커니즘. 출처는 바로 밑 설명에 있다.

상기 표는 (시간이 좀 지난 자료이지만) 아래 링크의 KubeCon/CloudNativeCon North America 2024에서 발표된 Auto(Zero-code) Instrumentation 관련 내용의 일부로서, OpenTelemetry의 언어별 Instrumentation 지원 현황 및 Zero-code Instrumentation 메커니즘을 보여준다.

CNCF-hosted Co-located Events North America 2024: Where’s the Auto in Auto-Instrumentation...

View more about this event at CNCF-hosted Co-located Events North America 2024

https://colocatedeventsna2024.sched.com/event/1izqJ/wheres-the-auto-in-auto-instrumentation-a-look-at-current-automation-strategies-with-otel-joshua-lee-altinity

“자동 계측에서 '자동'은 어디에 있을까? OTel을 활용한 현재의 자동화 전략 살펴보기” 란 제목의 프리젠테이션 by Joshua Lee, Altinity

메커니즘 열에서 보이듯이 말이 좋아 Zero-code이지 Go를 제외한 모두는 죄다 code injection 또는 agent를 기반으로 동작한다. 이는 어떤 형태로건 configuration 수정을 요구함과 동시에 design time의 code와 runtime code 간의 불일치를 만들어내는 구조로서, 디버깅이 어려워짐을 의미한다. 경험 상 이러한 구조는 꼭 문제를 일으키기 마련이기에, 나라면 그냥 Code-based Instrumentation을 쓰고 말 것 같다.

더욱 나쁜 건, 언어 별로 기법이 상이함으로 인해, 여러 서비스에 대해 대응을 해야하는 입장에서는 부담이 더욱 가중된다는 점이다.

이러한 와중에 마주친 기쁜 소식이 있었으니…

OpenTelemetry eBPF Instrumentation(OBI)

OpenTelemetry eBPF Instrumentation

Learn how to use OpenTelemetry eBPF Instrumentation for automatic instrumentation.

https://opentelemetry.io/docs/zero-code/obi/

OpenTelemetry eBPF Instrumentation(OBI) root 링크

eBPF 기반의 Zero-code Instrumentation이 OpenTelemetry 공식적으로 출시된 것이다. 상기 링크의 최종 수정일이 금년 8월 11일인 점을 고려하면 이제 고작 3달 밖에 지나지 않았다. 앞선 표에서도 Golang의 경우 이미 eBPF를 지원한다고 나와있지만 이번의 경우 주류 언어 대부분을 지원한다. 아래는 상기 링크에 담긴 feature 내용이다.

•

다양한 언어 지원: Java, .NET, Go, Python, Ruby, Node.js, C, C++, Rust

•

가벼움: 코드 변경이 필요 없고, 라이브러리를 설치할 필요 없고, 재시작이 필요 없습니다.

•

효율적인 계측: 추적 및 측정 항목은 최소한의 오버헤드로 eBPF 프로브에 의해 캡처됩니다.

•

분산 추적: 분산 추적 범위가 캡처되어 수집기에 보고됩니다.

•

Kubernetes-native: Kubernetes 애플리케이션에 대한 구성 없는 자동 계측을 제공합니다.

•

암호화된 통신에 대한 가시성: 복호화 없이 TLS/SSL을 통한 거래 캡처

•

컨텍스트 전파: 서비스 전반에 걸쳐 추적 컨텍스트를 자동으로 전파합니다.

•

프로토콜 지원: HTTP/S, gRPC 및 gRPC-Web

•

낮은 기수 메트릭: 비용 절감을 위한 낮은 기수 메트릭을 갖춘 Prometheus 호환 메트릭

•

네트워크 관찰성: 서비스 간 네트워크 흐름 캡처

•

데이터베이스 추적: 데이터베이스 쿼리 및 연결 캡처

그냥 완벽하다고 할 수 밖에 없다. 이 OBI로 인해 나머지 Zero-code Instrumentation은 이제 무용지물이 되는 것이 아닐까 싶은 정도. 아래는 AI에 의한 eBPF zero code instrumentation과 비 eBPF zero code의 비교이다.

특징	eBPF Zero-Code instrumentation	비 eBPF Zero-Code instrumentation
작동 위치	Kernel space에서 실행	User Space, 즉 애플리케이션 프로세스 내에서 실행
데이터 접근 수준	System call, network, I/O, file 등 kernel-level 접근. Uprobes로 user space 함수 추적	API/라이브러리/함수 호출 등 application-level
성능 오버헤드	매우 낮은 오버헤드이나 워크로드·probe 위치에 따라 1~5% 이상 가능	eBPF보다 상대적으로 높음(bytecode rewrite, context switch 등)
안정성 및 보안	verifier와 sandbox 덕에 상대적으로 안전	애플리케이션과 같은 프로세스에서 실행되므로 crash risk 존재
언어/플랫폼 종속성	언어 비종속적 (Language Agnostic). 리눅스 커널 기반이면 어떤 언어로 작성된 애플리케이션이든 추적 가능.	언어 종속적. 각 언어 런타임(Java, Python 등)에 맞춰 별도의 Agent나 code injection 등이 필요

OBI는 Grafana Beyla로부터

근데 좀 뒤져보니 재밋는 내용이 보인다.

OpenTelemetry eBPF Instrumentation Marks the First Release

Following a significant collaboration between Grafana Labs, Splunk, Coralogix, Odigos and many other community members, we are thrilled to announce the first alpha release of OpenTelemetry eBPF Instrumentation, or OBI for short. This event marks a significant milestone after the project, originally Grafana Beyla, was donated earlier this year by Grafana Labs. The development of eBPF instrumentation has significantly sped up after the project became managed under the OpenTelemetry umbrella. Many new protocols have been added, quality has improved - especially when deploying at scale, and tests are running 10 times faster. It’s a true testament to the value of the OpenTelemetry community.

https://opentelemetry.io/blog/2025/obi-announcing-first-release/

OBI는 Grafana Beyla에 기반한다는 내용 및 OBI의 알파 릴리즈 소식

Building on the foundation of OpenTelemetry eBPF Instrumentation: what’s new in Grafana Beyla 2.5 | Grafana Labs

With Beyla 2.5, we're directly vendoring most of the code from the upstream OpenTelemetry eBPF Instrumentation repository, which Grafana Labs proudly donated to the OpenTelemetry community.

https://grafana.com/blog/2025/08/04/building-on-the-foundation-of-opentelemetry-ebpf-instrumentation-what-s-new-in-grafana-beyla-2-5/

Grafana의 기증으로 Beyla가 공식 OpenTelemetry eBPF Instrumentation(OBI)이 되었다는 Grafana 발 소식. 금년 8월 4일.

OBI는 Grafana에서 Beyla 기증을 통해 만들어진 것이고, 불과 열흘 전인 11월 3일에야 알파 릴리즈를 했던 것이다. Beyla는 이미 일전에 검토했던 제품으로, 사실 앞선 표에서 Golang이 eBPF를 지원한다는 내용에서 Beyla를 생각했던 터였다. 당시 검토 때는 Beyla가 이렇듯 폭넓은 언어 지원을 하지 않았던 기억인데, 거반 1년반이 지난 현 시점에는 많이 바뀐 듯. 작년 3월에 작성된 Beyla 관련 블로그 포스트인

Grafana LabsOpenTelemetry distributed tracing with eBPF: What’s new in Grafana Beyla 1.3 | Grafana Labs 을 보면 Beyla의 Context Propagation 기법을 ‘앞으로’ Golang 이외의 타 언어에도 지원할 것이란 내용이 담겨있다.

OBI vs Beyla

OBI가 OpenTelemetry 공식 솔루션이긴 하지만 알파 버전임을 감안한다면, 이를 운영 환경에서 쓰는 것은 부담이다. 이 글을 쓰는 현재(2025.11.16) OBI는 Helm chart 조차 없다. 하지만 OBI와 Beyla 중 OBI의 repo가 원본 소스코드가 될 것이고 Beyla는 여기에 Grafana에 특화된 기능이 추가된 OBI 배포판이 될 것이라고 하니, 알파 버전 이슈는 그리 중요한 사항이 아니다. 표준이 아닌 무엇을 쓰는 것은 언제나 찝질한 일이기도 하고. 따라서, 현 시점 기준으로 OBI를 쓰건 Beyla를 쓰건 별 차이는 없어 보인다.

이로서 Kubernetes, Istio 환경에서 distributed tracing은 OBI 또는 Beyla를 쓰는 것으로 정리할 수 있다. 이와 함께, Istio의 trace 기능은 역할 및 데이터 중복으로 인한 혼란 제거를 위해 끄는 것이 좋겠다.

OBI / Beyla의 trace, metric 처리 구조

아래는 맨 윗 그림에 대한 AI 도움을 받은 ‘내 이해 기반의’ 설명이다(내가 eBPF를 뒤져본게 아닌 상태에서 OBI / Beyla 처리 구조를 ‘빠르게’ 이해하려다 보니 이런 수식어를..). 공식 문서에 해당 그림에 대한 설명이 없어서리

구성 요소	위치	역할
Instrumented Process	User Space	모니터링 대상 애플리케이션 프로세스
Instrumenter Process (OBI / Beyla)	User Space	eBPF 관리 및 최종 trace, metric에 대한 backend 전송 등의 후처리
Uprobes	User Space	L7 등 application 계층의 이벤트 hooking
Kprobes	Kernel Space	L4 이하 계층의 이벤트 hooking
eBPF program	Kernel Space	이벤트 발생 시 실행되는 커널 코드
eBPF map	Kernel Space	커널 내 키-밸류 저장소

Istio metric과 OBI / Beyla metric의 중복 이슈는 어떻게

이제 남은 것은 Istio metric과 OBI / Beyla가 노출하는 metric 간 중복 문제, 즉 이들 두 metric 중 무엇을 사용할지의 선택만 남았다. 아래는 OBI / Beyla가 노출하는 metric 목록인데, 여기에는 Istio가 담당하는 traffic metrics (HTTP, gRPC, network) 역시 포함된다.

OBI exported metrics

Learn about the HTTP/gRPC metrics OBI can export.

https://opentelemetry.io/docs/zero-code/obi/metrics/

OBI가 노출하는 metric 목록

Beyla exported metrics | Grafana Beyla documentation

Learn about the HTTP/gRPC metrics Beyla can export.

https://grafana.com/docs/beyla/latest/metrics/

Beyla가 노출하는 metric 목록. OBI가 Beyla에서 비롯된 것임을 보이듯이 OBI의 것과 사실 상 동일하다.

위 링크의 OBI, Beyla가 노출하는 metric은 크게 HTTP, gRPC, Database, Messaging, CPU, Memory, Disk IO, OBI / Beyla 특화 metric으로 나눌 수 있는데, 이중 HTTP, gRPC, network metrics는 Istio metrics와 용도가 겹친다.

HTTP(5개), gRPC(2개), network(2개) metrics는 총 7개로, Istio의 20개(metric 자체는 10개이나, 비교를 위해 동일하게 client, server metric으로 분리할 경우)로 내용 상 유사하기는 하나 차이가 좀 있다. 근데 갯수 차이보다도 더 중요한게, 가장 많이 사용하는 request counting metric이 없다는 점이다(Istio의 경우 istio_requests_total). 나아가 OBI / Beyla metrics로 교체할 경우 기존 Istio metric에 의존하는 응용 환경(dashboard, alert, WASM 등을 이용한 custom labeling 등)을 전면 수정해야 한다는 큰 약점이 있다. 하지만 Istio metric에도 약점이 없는 것은 아닌지라, Istio가 trace와 metric 간 연결의 핵심인 exemplar를 생성 못한다는 점이다(Metrics에 대응하는 Istio의 signal backend는 Prometheus로서, logs와 traces와는 달리 OpenTelemetry 지원이 없다. OpenTelemetry 환경에서 조차 일반적으로 Prometheus가 metric backend로 사용됨을 감안하면 이는 큰 문제가 아니나, traces와 metric과의 연계 분석을 위한 exemplars 지원이 없다는 점은 상당히 아쉬운 점이다(‣ 참고). 참고).

OBI / Beyla가 exemplar를 생성하는지 여부는? OBI / Beyla가 trace와 metric을 연결짓는 exemplar를 HTTP, RPC metrics에 생성하는지 여부는 확인 안되었다. exemplar를 생성한다는 명시화한 문서를 찾지 못했기 때문이다.

그렇다고 OTel 규격의 metric을 생성하는 상황에서 생성 안할 이유도 없어보인다. OTel은

OpenTelemetryMetrics Data Model에서 보듯 exemplar를 명시적 규격으로 다루며 trace와 metric을 모두 계측하는 이상 exemplar 생성은 전혀 어려운 일이 아니다.

따라서, OBI / Beyla가 exemplar를 생성 못한다면 더 논할 필요도 없이 Istio metric을 유지하겠지만, exemplar를 생성한다면, 아래에서 논하듯 exemplar 없이 trace와 metric 간의 연계 분석이 어떤 수준에서 가능한지 추가 검토해볼 필요는 있어 보인다.

그럼에도 불구하고, 앞서 논한 Istio metric 대비 여러 약점이 exemplar 기반의 trace / metric 간 연계 분석의 중요성보다 상당히 커 보이므로, Istio metric을 traffic metric의 주력으로 쓰는 것이 좋겠다. exemplar 기반 연계 분석이 그리도 중요하다면 이 metric도 사용하면 그만이다(중복으로 인해 metric 사용성은 떨어지겠지만).

이외에 CPU, Memory의 경우 Kubernetes 환경에서는 일반적으로 kubelet(cAdvisor)가 생성하는 metric을 사용하기에 이 역시 제외해도 무방해보인다.

참고로,

Grafana LabsConfigure Beyla Prometheus and OpenTelemetry data export | Grafana Beyla documentation은 필요한 metrics만 노출하도록 하는 옵션을 나타내고 있다.

기타

다음은 아직 다루지 못한 trace와 metric 관련 몇 가지 확인 필요 사항이다.

Istio mTLS 환경에서 어떻게 instrumentation이 가능한지

•

일단 Gemini AI는 Istio mTLS 환경에서의 instrumentation이 가능하고, 특히 app과 Istio-proxy 중 app에 대해서만 수행한다고 전한다. 하지만 상식적으로는 OBI / Beyla 입장에서 app과 Istio-proxy (sidecar mode의 경우)를 구분 못할 터인데 어떻게 app만 instrument한다는 것인지 잘 이해가 안가는 지점이다.

•

특히나 mTLS 환경에서 어떻게 동작하는지가 궁금한데, OBI / Beyla라고 암호화된 데이터를 마음대로 복호화할 수는 없어 보이기 때문이다. app과 Istio-proxy 또는 app과 Ztunnel 간 구간에서는 plaintext로 트래픽이 전달되기에 이를 이용하면 가능할 수도 있겠다는 생각이 든다.

Exemplar가 trace - metric 간 연계 분석에 반드시 필요한가

앞서 논했듯, Istio metric은 exemplar를 포함하지 못한다. 문제는 Exemplar가 trace - metric 간 연계 분석에 반드시 필요한지 여부이다.

•

Exemplar 없이도 trace에 담긴 속성(e.g. 시간, service name)과 metric label 및 timestamp을 매핑하면 원리적으로는 얼추 매핑이 가능하고 이를 통해 연계 분석이 가능하다.

•

AI는 exemplars 없이도 위 설명과 같이 타 속성 기반으로 trace와 metric 간 연계 분석, 특히 Grafana가 이를 지원한다고 주장하는데 이는 실험을 통해 확인해보아야 할 부분이다.

•

참고로, Otel의 spanmetrics connector라던가 Tempo의 Metrics-generator는 trace에서 metric을 만들어내는데, 이들은 모두 exemplar를 생성한다(spanmetricsconnector package - github.com/open-telemetry/opentelemetry-collector-contrib/connector/spanmetricsconnector - Go Packages, Grafana LabsUse the span metrics processor | Grafana Tempo documentation 참조). 하지만 위 논의의 환경에서는 이들을 사용할 일은 없어 보인다(특히 Beyla가 exemplar를 생성할 경우).