Installation Overview

kprobe runs closest to the machines that execute your workloads. The recorder must observe the host Linux kernel, so the deployment model depends on how much control you have over the compute layer.

Choose an installation path

Environment	Recommended path	Notes
Amazon EKS on EC2 nodes	Install on EKS	Best production experience. kprobe runs as a DaemonSet.
Amazon ECS on EC2	Install on ECS EC2	Run one host agent per ECS container instance.
Bare Linux or VM fleet	Install on Linux	Run the recorder as a system service.
Local evaluation	Local Demo	Start the backend and publish a demo incident.
Fargate-only workloads	Use trace-only integration	Full eBPF capture requires host kernel access.

What gets installed

A full kprobe deployment includes:

recorder agents on nodes or hosts
event pipeline for ingest, validation, and delivery
storage for timelines and causal graphs
API service for queries and replay
web console for incident investigation
service accounts, RBAC, secrets, and configuration
internal health checks and metrics

In production, many teams use managed storage instead of bundled infrastructure. For example, Kafka-compatible streaming, managed ClickHouse, and managed graph storage can be configured through Helm values.

Deployment topology

A standard production topology looks like this:

The kprobe recorder runs on every Linux node that hosts selected workloads.
The recorder emits raw kernel events into the event pipeline.
The pipeline validates, samples, redacts, and enriches events with Kubernetes and OpenTelemetry context.
The timeline store keeps the ordered event log for search and replay.
The graph store keeps causal edges for root-cause traversal.
The API and console expose investigation workflows to engineers.

The recorder is intentionally close to the kernel. Everything after the recorder can run inside the same cluster, in a shared observability cluster, or against managed services.

Requirements

Requirement	Description
Linux kernel	5.15+ with BTF support is recommended for CO-RE eBPF programs.
Host access	The recorder requires permissions to load eBPF programs and read perf/ring buffer data.
Kubernetes	1.26+ for Kubernetes deployments.
Helm	3.x for Kubernetes installation.
OpenTelemetry	Recommended for trace, service, and request correlation.

Install decision matrix

Question	Recommended choice
Do you run Kubernetes with EC2-backed Linux nodes?	Install the Helm chart and run the recorder as a DaemonSet.
Do you need strict separation from application clusters?	Run storage and API in an observability cluster, and run only agents in workload clusters.
Are you evaluating locally?	Use the local demo path and publish synthetic incident events.
Are you Fargate-only?	Use kprobe for trace correlation only, or add an EC2 node group for workloads that need kernel forensics.
Do you already run Kafka or ClickHouse?	Point kprobe at your managed/existing services through Helm values.

Production install pattern

Most production users install kprobe with a values file:

helm install kprobe kprobe/kprobe \
  --namespace kprobe \
  --create-namespace \
  -f values-prod.yaml

The values file defines:

cluster name
namespaces and workloads to observe
storage mode
retention period
OpenTelemetry endpoint
authentication provider
resource requests and limits
dashboard exposure

Post-install smoke test

Run the smoke test from a namespace that kprobe is configured to observe:

kubectl run kprobe-smoke \
  --namespace payments \
  --image=curlimages/curl \
  --restart=Never \
  --command -- sh -c "curl -sS https://example.com >/dev/null"

Then open the console and search for the namespace, pod name, or generated request ID. A healthy install should show:

the pod mapped to a service identity
outbound TCP events
syscall events from the process
an ordered timeline
a correlation status indicating whether an OpenTelemetry trace was attached

If the smoke test produces no events, start with No Events.

Verify installation

After installation, verify these checks:

kubectl get pods -n kprobe
kubectl get daemonset -n kprobe
kubectl logs -n kprobe daemonset/kprobe-agent

The console should show:

connected agents
incoming kernel events
service metadata
trace correlation status
storage health