Support the OpenTelemetry Profiles signal end-to-end (ingestion, storage, correlation, visualization)

[jplorier]

Cross-filed in ClickHouse/ClickStack#9 — see that issue for parallel discussion on the ClickStack distribution side.

Summary

Add support for the OpenTelemetry Profiles signal to ClickStack/HyperDX so that continuous profiling can be ingested, stored, correlated, and visualized alongside logs, metrics, traces, and session replays in the same backend.

Background

The OpenTelemetry Profiles signal entered public Alpha in March 2026. The current ClickStack OTLP entry point accepts logs, metrics, traces, and session data. Teams that want continuous profiling correlated with their other telemetry currently must deploy a separate backend, which breaks the single-pane-of-glass model that motivates ClickStack adoption.

Requirements

Ingestion

• The ClickStack OTel collector distribution must accept OTLP Profiles over the same gRPC and HTTP endpoints already used for other signals.
• Profile ingestion must not require an additional pipeline, sidecar, or auxiliary process beyond what is required for existing signals.
• Authentication, TLS termination, and any tenancy controls that apply to other OTLP signals must apply equivalently to profiles.

Storage

• Profile data must be persisted in ClickHouse alongside the existing signal tables.
• The storage layer must support the same operational properties as the other signal tables: retention/TTL, secondary indexes, partition strategy, and compression behavior.
• Any ancillary data required to render profiles (for example symbolization mappings) must be persisted such that visualization queries remain efficient at production data volumes.

Correlation

• Profile records must be queryable by trace_id and span_id, so that profile data is reachable from a span and vice versa.
• Profile records must be queryable by OpenTelemetry resource attributes — at minimum the Kubernetes attributes (k8s.cluster.name, k8s.namespace.name, k8s.pod.name, k8s.node.name, k8s.container.name), and the standard service identity attributes (service.name, service.namespace, service.instance.id).
• Cross-signal navigation between profiles and every other signal (logs, traces, metrics, session replays) must work bidirectionally on these correlation keys.

Visualization

• HyperDX must expose a profiles view supporting, at minimum, flame graph rendering of CPU stack samples.
• The profiles view must be reachable as a drill-down from a span context in the trace view.
• The profiles view must be filterable by the resource attributes listed above (pod, node, namespace, cluster, service, etc.) and by arbitrary time range.
• Profile data must be searchable and filterable within HyperDX in a manner consistent with how other signals are filtered today.

Compatibility

• The feature must behave consistently across the supported ClickStack deployment topologies (all-in-one, HyperDX-only, decoupled ingestion).
• Documentation must specify how the feature is enabled (feature-gate state, configuration surface, schema migration steps) for each supported topology.

Upstream references

• OpenTelemetry Profiles Public Alpha announcement
• OTLP Profiles protobuf definitions
• opentelemetry-ebpf-profiler

Testing

We may be able to validate a preview branch against a production-adjacent EKS cluster running ClickStack 1.0.1.