> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odigos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Continuous Profiling

> Continuous CPU profiling in Odigos: how it works, and how it can helps finding performance bottlenecks without code changes.

> [!NOTE]
>
> This feature is available in Odigos Enterprise tier only. Please contact the
> Odigos team to inquire about access to the Enterprise version.

## What is CPU Profiling?

CPU profiling continuously samples what your processes are spending time on. Every few milliseconds the profiler captures a snapshot of every running thread's call stack. Aggregated over time, these snapshots form a **flame graph** — a visualization that makes it immediately obvious where CPU cycles are going, which functions are hot, and which library call is the unexpected bottleneck.

Unlike traces, which tell you *that* a request was slow, a CPU profile tells you *why*: the exact code path consuming the most time. This makes profiling the natural next step after you've identified a latency problem in your trace data.

![Continuous CPU Profiling in Odigos — symbol table and flame graph view](https://mintcdn.com/odigos/oddsQxX1gl4PNwT6/images/enterprise/profiling/profiling1.png?fit=max\&auto=format\&n=oddsQxX1gl4PNwT6\&q=85\&s=fe4f3617d55ff9b8fce48b902d4b0f29)

## Why Profiling in Odigos?

Continuous profiling in Odigos is built directly into the same pipeline that handles your traces, metrics, and logs:

* **Zero-code changes.** Profiling uses an eBPF kernel agent. No SDK, no agent library, no application restart required.
* **Language-agnostic.** Because collection happens at the OS level, every process on the node is profiled regardless of runtime — Java, Python, Ruby, PHP, Node.js, Perl, Erlang, .NET, Go, and Native executables (including C/C++, Rust, and Zig)
* **No separate infrastructure.** Profiles flow through the Odigos collector pipeline you already run. For quick investigation workflows the Odigos UI holds profiles in memory; for long-term storage you route them to a destination backend.
* **Per-workload, on-demand.** After enabling profiling, it works efficiently by only dynamically enabling in-memory buffer for workloads you are actively investigating, keeping Odigos resource usage predictable and under control.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.