Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,415 1 commento 3 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
clickhouse, kubernetes, typescript
Ambito
backend, databases, distributed-systems, documentation, frontend, observability

Direzione di ricerca

Inizia tracciando l’attuale punto di ingresso OTLP di ClickStack, le tabelle dei segnali esistenti e la visualizzazione delle tracce di HyperDX, quindi esamina le definizioni protobuf di OTLP Profiles upstream. Il lavoro sarà completo solo quando i profiles saranno acquisiti, archiviati, correlati e visualizzati con flame graph, supportati in tutte le topologie di deployment e documentati con i passaggi di configurazione e migrazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Testing

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

Lingua principale
TypeScript
Stelle
10k
Fork
494
Merge medio
2g 7h
PR unite (30g)
153

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyperdxio/hyperdx

Tutte le issue di hyperdxio/hyperdx

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.