Three of the most-requested integrations shipped as native receivers this quarter, no community collector config required.

For a year, the top integration request in our feedback board was some version of "just make the Kubernetes/Postgres/Kafka metrics show up correctly without me hand-writing a fifty-line OpenTelemetry collector config and guessing at label names." We took that seriously enough to build and maintain these three ourselves rather than pointing customers at generic community exporters.

Why we didn't just document the community collectors

Community OTel receivers are good, but they're generic by design — they expose whatever the underlying exporter gives them, with label names that don't match Helix's schema conventions. Every customer using them ended up writing the same relabeling rules to make cardinality sane and route metrics into the right service tags. We decided to ship that normalization ourselves.

Installing the Kubernetes receiver

helm install helix-k8s-receiver helix/k8s-receiver \
  --set apiKey=$HELIX_API_KEY \
  --set cluster=prod-us-east

It auto-discovers pods, applies your existing namespace and label conventions as Helix tags, and ships pod-level CPU, memory, and restart metrics alongside kube-state-metrics equivalents, pre-mapped to the same service tag your traces already use — so a Kubernetes OOM-kill and the trace errors it caused show up under the same service without extra config.

Postgres and Kafka

The Postgres receiver pulls from pg_stat_statements and exposes query-level latency without needing a sidecar; the Kafka receiver reads broker and consumer-group lag metrics directly from the JMX exporter most clusters already run. Both auto-tag by cluster and topic/query fingerprint respectively.

What's next in the receiver lineup

These three came first because they showed up most often in support tickets asking "why don't the labels match," not because they were the easiest to build — the Kafka receiver in particular took longer than expected because JMX exposure varies enough between managed Kafka providers that we ended up shipping three slightly different discovery paths under one Helm flag. Redis and Elasticsearch receivers are next, using the same normalization approach, based on how often they showed up in the same feedback thread.

  • Native Kubernetes, Postgres, and Kafka receivers, maintained by Helix
  • Auto-mapped to existing service tags, no manual relabeling
  • Kubernetes receiver installs via Helm in one command
  • Query-level Postgres latency without a sidecar