OpenTelemetry eBPF Instrumentation / Beyla 동작 구조. 출처: https://opentelemetry.io/docs/zero-code/obi/
Introduction
Kuberetes / Istio 환경에서 traffic metrics와 distributed tracing을 가장 효과, 효율적으로 취하기 방법에 대한 사전 조사이다. 결론부터 말하자면, traffic metrics는 Istio의 것을, (distributed) trace는 Grafana Beyla의 것을 사용하는 것이다.
Summary
•
eBPF 기반의 Instrumentation을 Zero-code Instrumentation 주력 솔루션으로 사용할만하다.
•
해당 솔루션에는 OpenTelemetry eBPF Instrumentation(OBI), Beyla가 있지만 Beyla가 현 시점에는 더 나아 보인다.
•
Beyla 역시 traffic metric을 생성하지만, 이는 Istio에게 맞기고 trace와 나머지 metric만 사용하는 편이 좋아 보인다.
Context
•
Istio는 traffic metrics와 trace 모두를 생성하지만 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은 이제 무용지물이 되는 것이 아닐까 싶은 정도. 근데 좀더 뒤져보니 재밋는 내용이 보인다.
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년반이 지난 현 시점에는 많이 바뀐 듯.
OBI가 OpenTelemetry 공식 솔루션이긴 하지만 알파 버전임을 감안한다면, 이를 운영 환경에서 쓰는 것은 부담이다. 자연스럽게 Beyla로 넘어갈 타이밍이다.
OpenTelemetry distributed tracing with eBPF: What’s new in Grafana Beyla 1.3 | Grafana Labs
Beyla 1.3 delivers OpenTelemetry distributed tracing support through two approaches: automatic header injection and black-box context propagation.
https://grafana.com/blog/2024/03/21/opentelemetry-distributed-tracing-with-ebpf-whats-new-in-grafana-beyla-1.3/
작년 3월에 작성된 Beyla의 Context Propagation 관련 문서. Context Propagation을 ‘앞으로’ Golang 이외의 타 언어에도 지원할 것이란 내용이 담겨있다.
Grafana Beyla
Grafana Beyla | Grafana Beyla documentation
Learn how to use Grafana Beyla, an eBPF based application auto-instrumentation tool.
https://grafana.com/docs/beyla/latest/
Grafana Beyla root 문서
아직 실제로 써본 것이 아니라 많은 것을 논할 수는 없고, 간단히 문서를 검토한 내용 중 일부만 적어둔다.
•
앞선 OBI의 features 그대로: OBI가 Beyla를 기반으로 하기 때문에 너무도 당연하다.
•
Daemonset 지원: node에 있는 전체 process에 대한 instrument를 위한 구조이다. Daemonset 이외에 sidecar 모드를 지원하는데 이는 일부 특정 process에 대해서만 instrument를 위한 것인 듯
•
OTLP 지원: 당연하지만 OpenTelemetry 프로토콜(OTLP)을 지원한다. OBI 건 뿐 아니라 OpenTelemetry 주요 contributor에는 항상 Grafana 직원이 들어가고 Grafana의 opensource 진영에서의 위치를 생각해보자면…
•
Helm chart 지원: Kubernetes 환경을 역시나 당연스럽게 잘 지원하는 듯
이렇게 해서 distributed tracing에 대한 최종 솔루션은 Beyla로 확정을 지을 수 있겠다. 참고로, trace는 Beyla를 통해 얻으므로 Istio의 trace 기능은 역할 및 데이터 중복으로 인한 혼란 제거를 위해 꺼두어야 하겠다.
Kubernetes, Istio 환경에서 Beyla에서 사용할 metrics
당연스럽게도 OBI와 마찬가지로 Beyla 역시 metric을 생성하는데, 여기에는 Istio가 담당하는 traffic metrics 역시 포함된다.
Beyla exported metrics | Grafana Beyla documentation
Learn about the HTTP/gRPC metrics Beyla can export.
https://grafana.com/docs/beyla/latest/metrics/
Beyla가 노출하는 전체 metric 목록
위 링크의 Beyla가 노출하는 metric은 크게 HTTP, RPC/gRPC, Database, Messaging, CPU, Memory, Disk IO, Beyla 특화 metric으로 나눌 수 있는데, 이중 HTTP, RPC/gRPC metrics는 Istio/Envoy metrics와 용도가 겹친다. 하지만, 내용 상 Istio/Envoy metrics가 훨씬 더 상세하므로 굳이 이를 사용할 필요는 없다. 따라서, HTTP/gRPC를 제외한 나머지 metric만 생성하도록 하면 될 듯 하다. 이외에 CPU, Memory의 경우 Kubernetes 환경에서는 일반적으로 kubelet(cAdvisor)가 생성하는 metric을 사용하기에 이 역시 제외해도 무방해보인다.
하지만 exemplar를 Beyla가 생성한다면?
Beyla가 trace와 metric을 연결짓는 exemplar를 HTTP, RPC/gRPC metrics에 생성한다면 다시 생각해볼 사안이기는 하다. 근데 딱히 Beyla가 exemplar를 생성한다는 문서를 찾지 못했다.
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에 대해서만 수행한다고 전한다. 하지만 상식적으로는 Beyla 입장에서 app과 Istio-proxy (sidecar mode의 경우)를 구분 못할 터인데 어떻게 app만 instrument한다는 것인지 잘 이해가 안가는 지점이다.
•
특히나 mTLS 환경에서 어떻게 동작하는지가 궁금한데, Beyla라고 암호화된 데이터를 마음대로 복호화할 수는 없어 보이기 때문이다. app과 Istio-proxy 또는 app과 Ztunnel 간 구간에서는 plaintext로 트래픽이 전달되기에 이를 이용하면 가능할 수도 있겠다는 생각은 든다.
Trace를 통한 metric 생성 필요 여부
•
Otel의 spanmetrics connector라던가 Tempo의 Metrics-generator는 trace에서 metric을 만들어내는데, 이를 통해 trace와 metric 간의 연계 분석이 가능하다. 특히나 이들은 exemplars(trace ID 등)를 생성할 수 있는데(
spanmetricsconnector package - github.com/open-telemetry/opentelemetry-collector-contrib/connector/spanmetricsconnector - Go Packages, Grafana LabsUse the span metrics processor | Grafana Tempo documentation 참조), 이를 통해 trace와 metric간의 관계를 특정 가능하다.
Grafana LabsUse the span metrics processor | Grafana Tempo documentation 참조), 이를 통해 trace와 metric간의 관계를 특정 가능하다.•
문제는 exemplars를 Istio metric에 실어 보낼 수 없다는 점이다. 하지만 이러한 특정 없이도, trace에 담긴 속성(e.g. 시간, service name)과 metric label 및 timestamp을 매핑하면 원리적으로는 얼추 매핑이 가능하고 이를 통해 연계 분석이 가능할 것이다. 나아가 이는 기존 metric을 그대로 활용한다는 측면에서 앞선 trace를 통한 metric 생성 방식보다 여러모로 유리하다.
•
AI는 exemplars 없이도 위 설명과 같이 타 속성 기반으로 trace와 metric 간 연계 분석, 특히 Grafana가 이를 지원한다고 주장하는데 이는 실험을 통해 확인해보아야 할 부분이다.