In my previous blog, we discussed about eBPF and a few tools using this technology. This raises the question of whether eBPF will replace OpenTelemetry. To answer this, we need to understand eBPF and OpenTelemetry's roles better. eBPF and OpenTelemetry both are powerful tools built with different approaches having distinct advantages. So I believe eBPF will not replace OpenTelemetry or other existing solutions. Instead, it complements them. Let's discuss how.

Open telemetry

Open telemetry is an open-source library and standards for collecting, managing, and exporting telemetry data like Logs, Metrics, and Traces from different environments and programming languages.But OpenTelemetry doesn't have an analytical capability or an alerting module.There are multiple projects and agents created using OpenTelimetry as a agent or built their agents on top of it. OpenTelimetry have 3 major components

API : Defines data types and operations for generating and correlating tracing, metrics, and logging data

SDK : Language specific implementation of APIs for Configuration, data processing and exporting telemetry data

Collectors : OpenTelimetry have four components together for creating a telemetry pipeline including Receivers, Processors, Exporters and Connectors

opentelimetry-2

So OpenTelemetry is basically an all-in-one telemetry agent and specifications supporting multiple sources, destinations and few processing capacity used to collect and ship telemetry data. It requires some storage to store and analyze this telemetry data. OpenTelimetry have different SDK, Libraries for each programming language and platform this makes instrumenting open telemetry agent a overhead. Since there is a good number of open source/paid software supports OpenTelimetry this can be used as a common pipeline for all telemetry data for multiple tools and use-cases

opentlimetry-arch

eBPF

eBPF is a kernel technology allows user to attach a custom program to varius linux kernal hooks and collect data from there. This is often used for low-level observability usecases realtime monitoring of system events, networks traffic and any low level information. EBPF is most efficient for collecting events, logs, and telemetry data from the kernel even at run time. Agents are installed directly to the kernel for collecting data from both host and application without any other integrations so it is less overhead for intrumentation compared to OpenTelimetry. eBPF can even collect logs, metrics and events from containers. eBPF can do more real-time analysis by interpreting or analysing keranal sys calls. Since there are no code-level changes to the application distributed tracing is still not fully done with eBPF even though some tools do it to some extent.

ebpf-arch

Event though eBPF have wide variety of use-case other than Observability like Networking, Load-balancing and Security. Lets have a quick comparison on eBPF and OpenTelimetry use-cases based on observability

eBP vs OpenTelimetry

In short, eBPF will be used widely in container environments to collect data directly from kernel agents and when it's required to have low-level or real-time observability use cases. meanwhile, OpenTelimetry will remain where logs or metrics have to be shipped from sources and to built custom use-cases.At the same time eBPF-based tool will be widely used in use-cases like code profiling and security as well.