> ## 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.

# Getting Started with Profiling

> Enable Out of the box, dynamic, and in-memory continuous CPU profiling for your applications.

## Prerequisites

* Odigos **v1.25.0** or newer installed on the cluster
* The workload you want to profile must already be a [Source](/enterprise/pipeline/sources/introduction)

## Step 1: Enable Profiling

Profiling is an **opt-in** feature controlled by a single Helm value.
Set `profiling.enabled=true` when installing or upgrading Odigos (enterprise installs also require your on‑prem token, same as a normal Odigos install):

```bash theme={null}
helm upgrade --install odigos odigos/odigos \
  --namespace odigos-system \
  --create-namespace \
  --set onPremToken=$ODIGOS_ONPREM_TOKEN \
  --set profiling.enabled=true
```

Export `ODIGOS_ONPREM_TOKEN` in your shell before running the command (or replace the reference with your token value). For other Helm flags, see [Enterprise installation](/enterprise/setup/installation).

When this flag is set Odigos provisions the following automatically:

* The eBPF profiler receiver is activated on every Data Collector
* A `profiles` pipeline gets enabled in Odigos components and as soon as profile samples start to arrive, Odigos UI buffers start generating the flame graph
* You can export profiling data to destinations that ingest **OTLP Profiles** (see [Destinations](/enterprise/instrumentations/profiling/destinations))

<Info>
  Profiling does not replace or interfere with your existing traces, metrics, or logs pipelines. It runs as a separate pipeline inside the same collector processes.
</Info>

## Step 2: View Profiles in the Odigos UI

Once profiling is enabled on the cluster, you can inspect profiles for any Source directly from the Odigos UI.

<Frame>
  <img src="https://mintcdn.com/odigos/oddsQxX1gl4PNwT6/images/enterprise/profiling/profiling-demo.gif?s=6398bb3dbab0d95397cd95686485a165" alt="Demo of continuous CPU profiling workflow in Odigos — enabling a slot, viewing the flame graph, and inspecting symbols" width="1000" height="569" data-path="images/enterprise/profiling/profiling-demo.gif" />
</Frame>

<Steps>
  <Step title="Open the Profiling tab">
    Navigate to **Sources** in the Odigos UI and click on the workload you want to investigate. This opens the source drawer. Inside the source drawer, click the **Profiling** tab. Click **Enable Profiling** to open a slot for this workload. Odigos will start buffering profile data as it arrives from the node.

    <Frame>
      <img src="https://mintcdn.com/odigos/oddsQxX1gl4PNwT6/images/enterprise/profiling/profiling4.png?fit=max&auto=format&n=oddsQxX1gl4PNwT6&q=85&s=8f5243e52b4dcf78a9d5a8cf11865a46" alt="Source drawer showing the Profiling tab with flame graph and symbol table" width="2378" height="1684" data-path="images/enterprise/profiling/profiling4.png" />
    </Frame>
  </Step>

  <Step title="Inspect the flame graph">
    Send traffic to your service or wait for background activity. The eBPF profiler samples continuously at the kernel level, higher CPU activity means more profiles getting collected for that workload.
    The flame graph updates as profile data accumulates in the buffer. Wider bars represent more CPU time. Click any frame to zoom in.
  </Step>

  <Step title="Inspect the symbols table">
    The symbols table lists every function captured in the profile with its **Self** time (CPU spent exclusively in that function) and **Total** time (including all callees). Use it alongside the flame graph to quickly rank the top CPU consumers without navigating the call tree visually.
  </Step>
</Steps>

<Note>
  Closing the Profiling tab does **not** immediately destroy the slot. The slot and its buffered data persist until the TTL expires or the UI pod restarts. This is intentional, it lets you reopen the tab and see the same data during an ongoing investigation.
</Note>

## Step 3: Send Profiles to a Backend (Optional)

The in-memory UI buffer is great for live investigation, but for long-term retention and cross-service comparison you'll want to route profiles to a profile-capable Destination. Today Odigos supports [Pyroscope](/enterprise/backends/pyroscope); see [Exporting Profiles to Destinations](/enterprise/instrumentations/profiling/destinations) for the full topology and prerequisites.

## Advanced: Buffer Tuning

The in-memory profile store is sized from **environment variables** read by the UI pod at startup.

| Environment variable                | Default           | Description                                                                                                                           |
| ----------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `PROFILES_MAX_SLOTS`                | `24`              | Maximum number of concurrently active profiling slots (one per workload). When the limit is reached the oldest slot is evicted (LRU). |
| `PROFILES_SLOT_TTL_SECONDS`         | `120`             | Seconds of inactivity after which a slot is swept by the background cleanup loop.                                                     |
| `PROFILES_SLOT_MAX_BYTES`           | `8388608` (8 MiB) | Maximum bytes of raw OTLP profile chunks retained per slot. Older chunks are dropped when this cap is reached.                        |
| `PROFILES_CLEANUP_INTERVAL_SECONDS` | `15`              | How often the background TTL sweep runs inside the UI process.                                                                        |

## OTLP Exporter Tuning

If you need to adjust retry behaviour or compression on the profiling OTLP pipelines (node → gateway, gateway → UI), set the nested keys under `profiling.exporter` in your Helm values (defaults live in the chart’s [`values.yaml`](https://github.com/odigos-io/odigos/blob/main/helm/odigos/values.yaml) under the `profiling:` block):

```yaml theme={null}
profiling:
  enabled: true
  exporter:
    enableDataCompression: false
    timeout: 5s
    retryOnFailure:
      enabled: true
      initialInterval: 5s
      maxInterval: 30s
      maxElapsedTime: 300s
```

## Getting Help

If you have any issues, or require our assistance, please open an issue in [GitHub](https://github.com/odigos-io/odigos), or reach out to us in [Odigos Slack](https://join.slack.com/t/odigos/shared_invite/zt-24u91yknm-0fLXu6qnqYfNHS_GSUgTJw)