Kuberneteswithout a sidecarper service.
One DaemonSet enrols into Fleet Management and the pipelines arrive from the portal. Nodes, pods, namespaces and workloads report CPU, memory, network and disk, with no code changes and no per-language agent to keep current.
18 nodes, 214 pods, 6 databases, all reporting without an exporter per service.
Included on every plan, including the free tier.
Node, pod and namespace resource metrics, with the Kubernetes object state alongside them.
RED metrics and server and client spans from eBPF, which attaches to sockets rather than to your code.
Trace auto-instrumentation for workloads you cannot rebuild, injected at admission for Java, Python, Node.js, .NET and Go.
Pipeline changes pushed over OpAMP, so turning a receiver on does not mean editing a chart and redeploying.
Three steps, then it is reporting.
What that looks like as a query.
sum by (namespace) (container_memory_working_set_bytes)
Which namespace is holding the memory.
kube_pod_container_status_restarts_total > 3
Containers stuck in a restart loop.
sum by (node) (kube_pod_info) / on(node) kube_node_status_allocatable{resource="pods"}
Nodes approaching their pod ceiling.
What platform teams ask before the rollout.
Something not here? Book thirty minutes with an engineer who works on the platform. Book a call →
- Do we have to replace Prometheus?
- No. Point its remote_write at us and kube-state-metrics plus kubelet cAdvisor keep scraping exactly as they do today. ServiceMonitors, recording rules and PromQL are unchanged, and Grafana Alloy forwards the same way.
- What does eBPF need on the node?
- Loading eBPF programs into the kernel needs hostPID, a privileged security context and root, so one Helm flag reconfigures the node DaemonSet with all three. It is opt-in, amd64 and arm64 only, and the flag on its own collects nothing until the portal pushes the receiver config.
- Do pods restart when we turn tracing on?
- eBPF attaches to sockets, so nothing restarts and nothing gets rebuilt. Operator auto-instrumentation injects a language SDK at admission, so those pods are recreated once. Both layers run together.
- Will pod labels wreck our cardinality?
- Pod IDs and request IDs are the usual cause. A topk query in the docs ranks your metrics by series count, then write_relabel_configs drops the label or coarsens it to a deployment name before it leaves the cluster. Nothing dropped at the source is billed.
Start on the free tier.
20K active series, 50 GB of logs and 50 GB of traces a month, 90-day retention, and the whole of Insights.