How to Use Groundcover: The Beginner’s Guide (First Install, the Zero-Code Lesson, First Trace, and the Sensor Arc)
CodexFuse Team · 2026-11-02T03:32:32.841Z · 14 min read
Learn how to use Groundcover, the eBPF-based Kubernetes observability platform: install the Flora sensor on your cluster, watch your first trace arrive with zero code changes, and master monitors, dashboards, and per-node pricing.
What Is Groundcover, Exactly?
Groundcover is an observability platform for Kubernetes that watches your cluster from inside the Linux kernel using eBPF — and if you are learning how to use Groundcover, start with the mental model the makers use: instead of injecting code into your application, groundcover's sensor attaches directly to the Linux kernel and observes everything that passes through it — every network call, every HTTP request, every system event — without touching your application at all. Say it once and keep it: no SDK, no restart, no sampling decision.
The maker's one-line headline calls it "the full-stack observability platform for engineers & agents" that lets you "monitor everything you run in the cloud, without compromising on data, control, or cost," deployed in your cloud. The sensor — named Flora — runs as a single DaemonSet, one pod per node, which means the node is the unit of both coverage and billing. This groundcover tutorial walks you from zero to your first trace in about thirty minutes, and it never asks you to change a line of application code.
This guide is written for platform engineers running Kubernetes (EKS, AKS, and GKE are all supported) who refuse to instrument every application by hand. If you do not have a cluster yet, the Kubernetes beginner guide covers getting one running — and if you want to look before you install, the vendor runs a hosted Playground that lets you click through the whole product with no infrastructure at all. One boundary, drawn once here and held for the whole page: Groundcover is the eBPF-sensor lane — observing clusters at the kernel layer with zero code changes — which is a different lane from SDK-based OpenTelemetry setups. The comparison section draws that line exactly once.
Why Do Platform Engineers Choose eBPF Observability?
Engineers searching for eBPF observability Kubernetes guides usually find vendor whitepapers first — this article is the independent beginner walkthrough that is missing from the field.
The old observability deal was expensive in two ways: engineering time (an SDK or agent in every app, restarts to roll it out, sampling rules to tune) and CPU (agents that tax every node). eBPF — the extended Berkeley Packet Filter — is a Linux kernel technology that lets approved programs observe network calls, system events, and process activity from kernel space without modifying application code. Because the program runs in the kernel, it is hyper-efficient, and because it attaches at the system-call layer, it sees every request whether or not the app was written to be observed.
The vendor's own argument, stated in their words so you can weigh the source: "Research by groundcover, however, shows that conventional solutions can increase CPU utilization by up to 249 percent (whereas eBPF monitoring, which we discuss below, increases CPU by a mere 9 percent, and has no detectable impact on memory)." That figure comes from groundcover's own research, published in their August 2024 post "Reduce System Load with eBPF Observability in Kubernetes." Their 2023 Flora launch benchmarks put numbers on the comparison: the Flora sensor at +9% CPU and +0% memory versus Datadog at +249% CPU and +227% memory, OpenTelemetry at +59% / +27%, and Pixie at +32% / +9%. Treat these as the vendor's measurements, not independent lab results — the durable lesson is the mechanism (kernel-space collection is cheaper than user-space agents), and that holds regardless of whose numbers you trust.
That is the promise of eBPF observability for Kubernetes in one sentence: you get distributed traces, service maps, logs, and metrics without touching application code, and the overhead argument means you do not have to ration which services get observed. That is the whole pitch of this groundcover for beginners arc — visibility first, instrumentation never.
What Do You Need Before Installing Groundcover?
Three prerequisites, stated once: Linux kernel version 5.3 or higher (anything since 2020 — the official requirements page is explicit, and older guides citing 4.16 are out of date), nodes that allow privileged containers (loading eBPF code requires it; check yours with ls -la /sys/kernel/btf/vmlinux), and a Kubernetes cluster on a supported distribution.
Supported environments per the official requirements page: EKS, AKS, and GKE, plus a long distro list — Debian 11+, RHEL 8.2+, Ubuntu 20.10+, CentOS 7.3+, Fedora 31+, BottlerocketOS 1.10+, Amazon Linux, Google COS, Azure Linux, and Talos 1.7.3+ — on x86 and ARM. Two exclusions to know before you start: the coverage policy excludes the control plane and Fargate nodes, because Fargate's shared kernel does not grant the access eBPF needs.
The privileged-container requirement deserves one honest sentence instead of hand-waving: you are granting the sensor deep kernel access, which is a real security trade-off you should approve deliberately — in exchange, the sensor sees everything without ever touching your application code. If that trade-off makes you uncomfortable, the hosted Playground lets you explore the UI with zero installation.
| Requirement | Official minimum (checked 2026-11-02) | How to check |
|---|---|---|
| Linux kernel | v5.3 or higher (anything since 2020) | uname -r |
| Container privilege | Privileged containers allowed (eBPF loading needs it) | ls -la /sys/kernel/btf/vmlinux (CO:RE/BTF support) |
| Kubernetes | EKS, AKS, GKE and other distributions | kubectl cluster-info |
| Excluded nodes | Control plane and Fargate are not covered | Use EC2-backed node groups, not Fargate |
| CPU architecture | x86 and ARM both supported | kubectl get nodes -o wide |
How Do You Install Groundcover?
A groundcover install has two supported paths, and both end with the same Flora sensor running on your cluster. The CLI path is the fastest: install the groundcover binary with sh -c "$(curl -fsSL https://groundcover.com/install.sh)", then deploy with groundcover deploy -f values.yaml. The Helm path adds the repo and upgrades into a namespace: helm repo add groundcover https://helm.groundcover.com && helm repo update groundcover, then helm upgrade groundcover groundcover/groundcover -i --create-namespace -n groundcover -f values.yaml. If those Helm flags are new to you, the Helm beginner guide walks through exactly this install pattern.
One step both paths share: the CLI generates your ingestion key (groundcover auth get-ingestion-key sensor), which the Helm values consume — so even the Helm route touches the CLI once. Removal is symmetric: groundcover delete for the CLI path, or helm uninstall groundcover -n groundcover plus kubectl delete ns groundcover for Helm.
No cluster to install into? The vendor's Playground (play.groundcover.com) gives you a live environment to click through the Traces, Dashboards, and Monitors views with no install at all — it is the honest zero-cost first step if you are still deciding whether groundcover belongs in your stack.
sh -c "$(curl -fsSL https://groundcover.com/install.sh)" groundcover deploy -f values.yaml
helm repo add groundcover https://helm.groundcover.com && helm repo update groundcover helm upgrade groundcover groundcover/groundcover -i --create-namespace -n groundcover -f values.yaml
How Do You See Your First Trace?
The maker's own groundcover EKS walkthrough uses a single nginx pod as the demo workload, and this groundcover tutorial follows the same arc because it is the documented beginner path: you deploy nginx, generate traffic, and watch the traces arrive with zero lines of instrumentation.
- Create the namespace:
kubectl create namespace anais - Deploy nginx:
kubectl create deployment nginx --image=nginx --replicas=1 -n anais - Expose it:
kubectl expose deployment nginx --port=80 -n anais - Exec into the pod and fire ten successful requests (
curl -s localhost) and ten failures (curl -s localhost/doesnotexist) - Open the Traces view and filter
namespace:anais
The result the vendor promises — and the moment the lesson lands: all 20 requests are waiting for you (ten HTTP 200s, ten HTTP 404s), every one tagged Source: eBPF. The sensor captured the successes, the errors, and the difference between them, and a new service appears in your service map the moment it starts receiving traffic. Open one trace and you will see the full request and response payloads, including headers — that payload visibility is the eBPF bonus, and it is what turns "monitoring" into actual debugging.
What Arrives Automatically After the Sensor Deploys?
The beginner's confusion is usually "what did I just get for free?" — the answer is a table, because five things arrive with zero configuration the moment the DaemonSet is healthy.
| Signal | What you get | Where you look |
|---|---|---|
| Distributed traces (HTTP/gRPC) | Every request with full request/response payloads, including headers | Traces view, filtered by namespace or service |
| Service map | Each service appears the moment it starts receiving traffic | Service map |
| Infrastructure metrics | CPU, memory, disk, and network per node, pod, and container — no scrape config | Workloads page and Dashboards |
| Logs | Collected from your workloads automatically; enrich unstructured lines through the Logs Pipeline | Logs view (test parsing rules in the Parsing Playground first) |
| API catalog | Every observed endpoint cataloged from live traffic | API catalog |
The vendor's own five-step getting-started list confirms the order beginners should explore: 1. the Workloads page, 2. Traces with full payloads, 3. Dashboards, 4. Monitors, 5. inviting the team. The apps you observe are ordinary container images — if that phrase is fuzzy, the Docker beginner guide explains what the sensor is actually watching at the node layer.
How Much Does Groundcover Cost?
Groundcover pricing is built on one rule, stated once: "predictable price based on hosts, not data." You are billed on the monthly average of Kubernetes nodes actively monitored by the eBPF sensor — any node size, any machine type — so adding more telemetry volume costs you nothing, while adding a node does.
The official pricing page lists Free, Team, and Enterprise plans. The page's own calculator and indexed figures put Pro at $30 per host per month, Enterprise at $35, and an on-prem tier at $50 — but the plan-card numbers are JavaScript-rendered and third-party directories conflict on the Enterprise figure, so treat the exact dollars as current-today and re-check the pricing page before you budget. The mechanism (per-host monthly average) is the stable fact, and the site's TCO calculator lets you model your own node count.
The deployment models matter as much as the dollars. BYOC ("bring your own cloud") means a single centralized backend instance for all your environments, deployed and hosted in your cloud and fully managed by groundcover — your observability data stays "within the walls of your own Virtual Private Cloud (VPC)." Fully On-Prem goes further for regulated shops. And the node-count billing is why beginners practice on the smallest cluster they can: if you run your own practice cluster, the VPS hosting guide explains the cheapest way to rent that capacity.
How Do You Create Your First Monitor and Dashboard?
Monitors start from the Monitor List or Issues view with Create Monitor, and the beginner path is the plain-English Agent: describe what you want — the docs' own example is "Alert with S2 severity when the checkout service's error rate exceeds 5% for 10 minutes, and notify #payments-alerts in Slack" — hit Generate monitor, and review the wizard (Query: data source and thresholds; Monitor Details: name and S1–S4 severity; Issue Details) before saving. Prefer to drive? Start from scratch, pick a template from the Monitor Catalog, or import YAML; notifications go out through routes to Slack, PagerDuty, or OpsGenie.
Dashboards follow the same two-lane pattern: the Dashboards page offers Create Dashboard, then either Create with the Agent (describe the goal, @-mention what to include — the natural-language dashboard creation the vendor added in 2026) or manual Create widget, where the Widget Builder gives you the Agent, a visual builder, or raw MetricsQL/gcQL. Ready-made dashboards live in the Dashboard Catalog, and dashboards auto-save as you build.
One beginner rule the docs imply but never headline: alerts answer "wake me when it breaks" and dashboards answer "show me how it is doing" — build the dashboard first (it teaches you what normal looks like), then write the monitor that fires when normal breaks.
Groundcover vs Datadog: What Is the Real Difference?
The honest comparison is architectural, not a feature list: Datadog's classic path instruments your applications with agents and libraries; Groundcover's eBPF sensor observes the kernel and needs nothing in the app. The vendor's own benchmark numbers — attributed once more, because they are the vendor's: Flora at +9% CPU and no detectable memory impact versus Datadog at +249% CPU and +227% memory in their 2023 launch research. No independent verification exists for those figures, so decide on the mechanism (no instrumentation, per-node pricing, BYOC data residency) rather than the headline numbers.
The lane line, drawn once: SigNoz — covered in the SigNoz beginner guide — is the OpenTelemetry-backend lane: you instrument with OTel SDKs and SigNoz receives the telemetry. Groundcover is the eBPF-sensor lane: the cluster is observed with zero code changes. Different collection layers, never rivals — and this page never splits the cluster's keywords across two articles.
What Are the 7 Beginner Mistakes?
Every groundcover install tutorial should carry a failure catalog, so here is one computed from the docs' sharp edges rather than invented from thin air.
| Mistake | Why it bites | The fix |
|---|---|---|
| Assuming kernel 4.16 is enough | The docs require 5.3+; the sensor pods crash-loop on older kernels | Run uname -r and check the BTF path before installing |
| Installing on Fargate or expecting control-plane coverage | Both are explicitly excluded from the coverage policy | Use EC2-backed node groups, not Fargate |
| Forgetting privileged mode | Loading eBPF code requires privileged containers | Approve the trade-off deliberately; verify CO:RE/BTF support first |
| Skipping the ingestion key | The Helm path still needs groundcover auth get-ingestion-key sensor | Generate it before helm upgrade |
| Searching traces without the namespace filter | The demo's 20 requests hide in cluster noise | Filter namespace:anais first, then broaden |
| Treating the 9%-vs-249% figures as independent science | They are the vendor's own research | Cite them as such; decide on the mechanism, not the numbers |
| Budgeting per data volume | Billing is per host — the monthly average of monitored nodes | Count nodes, not gigabytes, in your cost model |
Sources
- Groundcover homepage (groundcover.com) — "the full-stack observability platform for engineers & agents" headline, BYOC description, August 2026 product news (natural-language dashboard creation, ClickHouse/PostgreSQL monitoring, Slack/Linear connectors, AI Observability), and the $100M Series C announcement (July 29, 2026).
- "Zero-Code EKS Observability with groundcover" (groundcover.com/blog/eks-observability-zero-code-instrumentation, March 24, 2026) — the sensor-kernel quote, the nginx demo flow, the
Source: eBPFtags, the Logs Pipeline, and the Playground option. - "Connect a Kubernetes Cluster" (docs.groundcover.com) — the
groundcoverCLI install,groundcover deploy -f values.yaml, the Helm repo commands, the ingestion-key step, and the uninstall commands. - "Kernel requirements for the eBPF sensor" and "Requirements" (docs.groundcover.com) — kernel 5.3+, privileged containers, the distro list, EKS/AKS/GKE support, x86/ARM, and the control-plane/Fargate exclusions.
- "5 quick steps to get you started" (docs.groundcover.com) — the Workloads → Traces → Dashboards → Monitors → team order, full payloads with headers, and the automatic service map.
- "Reduce System Load with eBPF Observability in Kubernetes" (groundcover.com/blog, August 22, 2024) — the "9 percent vs 249 percent" research quote.
- "Create a new monitor" and "Create a dashboard" (docs.groundcover.com) — the plain-English Agent, the monitor wizard sections, S1–S4 severities, notification routes, the Widget Builder, and the Dashboard Catalog.
- Groundcover pricing (groundcover.com/pricing) — Free, Team, and Enterprise plans, "predictable price based on hosts, not data," the monthly-average-node billing, the $30/$35/$50 figures, the TCO calculator, and the BYOC vs Fully On-Prem modes.
- "Groundcover Raises $100M Series C to Create the Observability Platform Built for the AI Era" (groundcover.com/blog, July 29, 2026) — funding led by One Peak with Morgan Stanley Expansion Capital, $160M total raised, 250+ companies, tripled prior-year revenue.
- HPCWire and SiliconANGLE coverage (July 29, 2026) — Series C reporting; one outlet reports a $500M valuation, stated here as reported, not as a confirmed fact.
Frequently Asked Questions
Does Groundcover require changing my application code?
No — that is the entire point. The Flora sensor runs as a DaemonSet and attaches eBPF programs to the Linux kernel, so it observes network calls, HTTP requests, and system events with no SDK, no restart, and no sampling decision. You deploy the sensor; traces, metrics, logs, and the service map appear on their own.
What Kubernetes platforms does Groundcover support?
EKS, AKS, and GKE are explicitly supported, along with a long distro list (Debian 11+, RHEL 8.2+, Ubuntu 20.10+, CentOS 7.3+, Fedora 31+, BottlerocketOS, Amazon Linux, Google COS, Azure Linux, Talos 1.7.3+) on x86 and ARM, with kernel 5.3 or higher. The control plane and Fargate nodes are excluded from coverage.
How much does Groundcover cost?
Plans are Free, Team, and Enterprise, billed per host — the monthly average of Kubernetes nodes actively monitored by the sensor, any size. The site's calculator lists Pro at $30 per host per month, Enterprise at $35, and on-prem at $50, but re-check the pricing page before budgeting since the figures move; the per-host mechanism is the stable fact.
Can I try Groundcover without a cluster?
Yes — the hosted Playground (play.groundcover.com) lets you click through Traces, Dashboards, and Monitors with no installation, and it is the honest first step if you are still evaluating. The full install needs a real cluster and about thirty minutes following the nginx demo arc in this guide.
Should I use Groundcover or Datadog?
Different architectures: Datadog instruments applications with agents and libraries; Groundcover observes the kernel with eBPF and zero code changes. The vendor's own benchmarks claim 9% versus 249% CPU overhead — vendor research, not independent science — so decide on the mechanism (no instrumentation, per-node pricing, BYOC data residency) rather than the headline numbers.
