Odigos Documentation

The deviceplugin module is a standalone, pluggable Kubernetes device plugin designed specifically for the Odigos observability platform. It exposes instrumentation-related virtual devices to Kubernetes nodes. These virtual devices facilitate automatic runtime configuration of applications by:

1. Mounting required files into containers.
2. Injecting OpenTelemetry environment variables.

This allows Odigos to automate the instrumentation process at the Kubernetes level.

Odigos is an observability control plane that uses OpenTelemetry and eBPF to provide automatic application instrumentation. It eliminates the need for manual code changes and manual collector management by automatically deploying and scaling collectors based on application traffic.

Key capabilities include:

• Automatic instrumentation: Produces distributed traces and metrics without requiring code changes.
• Collector management: Automatically handles the deployment and scaling of collectors according to traffic demands.
• Vendor flexibility: Produces data in the OpenTelemetry format (OTLP), allowing you to use any observability tool that supports OTLP and switch vendors easily.

Odigos supports a wide variety of managed and self-hosted backends for exporting observability data, including Traces, Metrics, Logs, and Profiles.

If your required backend is not listed, you can follow the add new destination guide to submit a pull request and add a new integration.

Odigos Central is a centralized management layer designed for multi-cluster observability. It provides a single UI to manage observability configurations across multiple Kubernetes clusters, replacing the need to configure instrumentation, sampling rules, and destinations individually in each cluster.

Note: This feature is exclusive to the Odigos Enterprise tier. Access requires contacting the Odigos team.

Odigos provides continuous CPU profiling using an eBPF kernel agent. This allows you to capture snapshots of running thread call stacks to generate flame graphs, helping you identify exactly which code paths or library calls are consuming CPU cycles.

Key benefits include:

• Zero-code changes: No SDKs, agent libraries, or application restarts are required.
• Language-agnostic: Profiles processes regardless of runtime (e.g., Java, Python, Ruby, Node.js, Go, C/C++, Rust, etc.) because collection happens at the OS level.
• Unified Pipeline: Profiles are emitted as OTLP Profiles signals and travel through your existing Odigos collector pipeline.
• Efficient Resource Usage: Profiling works by dynamically enabling in-memory buffers for workloads you are actively investigating.

The Odigos Pipeline is a multi-stage system designed to collect, process, and export OpenTelemetry signals. It consists of three main segments:

1. Instrumentation: Injects OpenTelemetry agents (native or eBPF) into workloads to record signals and export them from the process boundary.
2. Pipeline: Consists of a Node Collector (DaemonSet) that receives data from agents, enriches it with node-level attributes, and forwards it to the Cluster Gateway Collector (Deployment), which performs heavy processing, applies Odigos Actions, and exports data to final destinations.
3. Odigos Management: Orchestrates the entire system via Kubernetes Operators and provides a UI for configuration and monitoring.

The servicegraphconnector package in Odigos is a patched version of the opentelemetry-collector-contrib module. Odigos modifies the connector to ensure that all configured peer attributes are captured and correctly mapped to metric labels, which is essential for the Odigos UI to display server_* labels for virtual-node and database peers.

If you upgrade the vendored upstream tree, you must re-apply these specific behavioral changes to maintain observability functionality.

Odigos supports the production and correlation of three primary telemetry types: Traces, Metrics, and Logs.

To collect any telemetry type, you must satisfy two requirements:

1. Configure a destination that accepts that specific telemetry type.
2. Ensure the telemetry type is enabled for the target application (users can enable or disable collection on a per-application basis). If no applications are configured to collect a specific type, Odigos will not collect it.

Odigos collects non-sensitive, non-personally identifiable information to help maintainers improve the project. The following anonymous data points are collected:

• Whether traces, metrics, or logs are enabled
• The types of selected destinations (e.g., Jaeger, Prometheus, etc.)
• The number of instrumented applications categorized by programming language
• The number of unrecognized applications
• The number of nodes