Sending OpenTelemetry to ClickStack with Odigos

What is Odigos?

Odigos is an instrumentation control plane for Kubernetes and VMs that instruments applications from the kernel using eBPF. Because collection runs in the kernel, app overhead stays low while visibility stays high. You get production-grade OpenTelemetry traces, metrics, logs, and profiles without shipping new agents in application code or waiting on library upgrades across every service.

That eBPF layer is what makes deep, consistent telemetry possible at scale. Odigos can automatically turn on and off deeper instrumentation when needed to help debug or troubleshoot problems:

• Code-level context — attributes tied to functions and runtime behavior
• HTTP traffic — requests and responses across your services
• Messaging systems — payloads and messages from Kafka and similar brokers
• Errors in detail — stack traces when things fail
• Custom instrumentation — extend coverage where auto-instrumentation stops without requiring code changes or restarts

Behind the scenes, Odigos creates and manages a full OpenTelemetry pipeline for your cluster: collectors that scale with load, routing to the backends you choose, and pipeline logic you control in the UI. Define sampling to manage volume, PII masking to keep sensitive data out of exports, and OTTL rules to filter, transform, or enrich telemetry before it leaves the cluster.

Why Odigos + ClickStack?

Rolling out OpenTelemetry across many services is often time consuming and only provides surface-level visibility in applications. Odigos handles eBPF instrumentation for deeper telemetry and collector operations on Kubernetes; ClickStack provides ClickHouse-backed storage and the HyperDX UI for querying telemetry at scale.

Prerequisites

• ClickStack installed and reachable from your Kubernetes cluster. See Getting started with open source ClickStack or Getting started with managed ClickStack.
• Your ClickStack OTLP HTTP endpoint (port 4318) and the authentication value Odigos will pass in the Authorization header. With open source ClickStack this is the API ingestion key from Team Settings → API Keys in the HyperDX UI. With Managed ClickStack this is the OTLP_AUTH_TOKEN you set when starting your own standalone ClickStack collector.
• A Kubernetes cluster (Linux nodes with kernel 4.18 or later for eBPF instrumentation)
• Helm, kubectl, and cluster credentials to install into odigos-system namespace
• An Odigos Enterprise on-prem token — contact the Odigos team for access

Integrate ClickStack with Odigos

export ODIGOS_ONPREM_TOKEN="<your-enterprise-token>"

helm repo add odigos https://odigos-io.github.io/odigos/
helm repo update

helm upgrade --install odigos odigos/odigos \
  --namespace odigos-system \
  --create-namespace \
  --set onPremToken=$ODIGOS_ONPREM_TOKEN

kubectl get pods -n odigos-system

kubectl port-forward svc/ui -n odigos-system 3000:3000

Advanced configuration

HyperDX log normalizer

If you export directly to ClickHouse with Odigos’s native ClickHouse destination (instead of OTLP HTTP to ClickStack), enable HyperDX log normalizer (HYPERDX_LOG_NORMALIZER: true). It parses JSON log bodies and normalizes attributes for better querying in the ClickStack UI.

Native ClickHouse destination

When ClickHouse is directly reachable from your cluster, you can use Odigos’s native ClickHouse destination instead of OTLP HTTP. Configure the ClickHouse endpoint, database name, and schema options in the UI or with a manifest — see Odigos ClickHouse destination.

• Production schema: Set CLICKHOUSE_CREATE_SCHEME to false and apply your own DDL.
• TLS / auth: Use CLICKHOUSE_TLS_ENABLED, CLICKHOUSE_USERNAME, and a Kubernetes Secret for the password.

Configure destinations with Kubernetes manifests

OTLP HTTP (ClickStack)

apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
  name: clickstack
  namespace: odigos-system
spec:
  type: otlphttp
  destinationName: otlphttp
  signals:
    - TRACES
    - METRICS
    - LOGS
  data:
    OTLP_HTTP_ENDPOINT: 'http://clickstack.example.com:4318'
    # API ingestion key for open source ClickStack, or OTLP_AUTH_TOKEN for Managed ClickStack
    OTLP_HTTP_HEADERS: 'Authorization:<YOUR_AUTHORIZATION_VALUE>'

ClickHouse (direct)

apiVersion: odigos.io/v1alpha1
kind: Destination
metadata:
  name: clickhouse
  namespace: odigos-system
spec:
  type: clickhouse
  destinationName: clickhouse
  signals:
    - TRACES
    - METRICS
    - LOGS
  data:
    CLICKHOUSE_ENDPOINT: 'http://clickstack.example.com:8123'
    CLICKHOUSE_DATABASE_NAME: 'otel'
    CLICKHOUSE_CREATE_SCHEME: 'true'

Apply the manifest:

kubectl apply -f destination.yaml

Odigos VM Agent

The Odigos VM Agent instruments Linux processes, systemd services, and/or docker containers using eBPF. Telemetry exports to the same destinations as cluster-based Odigos, including ClickStack over OTLP HTTP.

The VM Agent is part of Odigos Pro. See the VM Agent overview for setup, sources, and destination configuration.

Odigos Central

Odigos Central is a centralized control plane for managing instrumentation, destinations, and pipeline configuration across multiple Kubernetes clusters from one UI - instead of configuring each cluster separately.

Odigos Central is available in Odigos Enterprise. See the Central overview for multi-cluster management, SSO, and unified sampling rules.

Next steps

• Explore traces across instrumented services in ClickStack
• Build dashboards for metrics Odigos exports
• Tune ClickHouse schema and TTL for your retention and query patterns

Read more

• Odigos Enterprise installation
• Odigos ClickHouse destination
• Odigos VM Agent overview
• Odigos Central overview
• Stop guessing in production: Full fidelity tracing at scale with ClickHouse and Odigos
• Getting started with open source ClickStack