Kubernetes Monitoring Without Prometheus and Grafana: What You Actually Need

Every Kubernetes monitoring guide starts the same way: install Prometheus, wire it up to Grafana, add Alertmanager for paging, and maybe Thanos or Cortex once retention becomes a problem. It’s the default answer, and for a platform team of six people it might even be the right one. For a five-person startup running two or three clusters, it’s usually the wrong one — not because the tools are bad, but because “free” software doesn’t mean free to operate.

The stack nobody budgets for

Prometheus itself is a single binary and a config file. That’s the part everyone quotes. What actually ships to production looks more like this:

• Prometheus, scraping every namespace, tuned so cardinality doesn’t blow up the TSDB
• Grafana, with dashboards someone has to build, and then rebuild every time a workload’s labels change
• Alertmanager, with routing rules that inevitably page the wrong person until someone spends an afternoon fixing them
• A remote-write target (Thanos, Cortex, or Mimir) once you need more than 15 days of history, because local Prometheus storage was never meant to be permanent
• Someone who understands PromQL well enough to write histogram_quantile correctly under pressure at 2 a.m.

None of this is exotic. All of it is upkeep. A small team without a dedicated SRE ends up spending its scarcest resource — engineering time — running an observability platform instead of running the product it’s meant to observe.

What you actually need, day to day

Strip away the tooling and ask what a small team actually checks in a given week. It’s a shorter list than the stack above implies:

Live resource metrics. CPU, memory, and network per node, namespace, and workload — recent enough to be useful during an incident, not averaged over a five-minute scrape interval that hides the spike you’re chasing.

Issue detection that doesn’t cry wolf. A pod restarting twice in ten minutes and settling down is noise. A pod stuck in CrashLoopBackOff for twenty minutes is a page. The difference is debounce logic — open and resolve states with a delay — which is exactly the kind of thing that’s easy to describe and tedious to implement correctly in raw Alertmanager rules.

A readable events feed. kubectl get events is a firehose sorted by timestamp with almost no deduplication. What you actually want is the same data grouped by workload, with repeats collapsed, so a scheduling failure doesn’t scroll past you between two hundred identical Pulled image events.

Cost mapped to something real. Not a monthly cloud bill divided evenly across namespaces — actual node utilization, so you can see that the staging cluster is costing more than production because nothing ever right-sized its requests.

An ongoing architecture read. Not a one-time consulting engagement that goes stale the week after it’s delivered, but a running check against the same Well-Architected-style questions: are you single-AZ where you shouldn’t be, are PodDisruptionBudgets missing, is anything running as root that doesn’t need to.

Notice what’s not on that list: dashboard-building, retention tuning, or PromQL literacy. Those are implementation details of the Prometheus/Grafana path, not requirements of the problem.

Where the self-hosted path actually earns its keep

To be fair to Prometheus: if you’re running dozens of clusters, need custom exporters for a proprietary system, or have compliance requirements that mandate metrics never leave your infrastructure, self-hosting is often the right call and the ecosystem around it is enormous. The tradeoff is real, not imaginary — you’re trading operational overhead for total control. The question is whether a five-to-fifteen-person engineering team gets enough back from that control to justify the maintenance tax.

For most teams in that size range, the answer is no. They don’t need custom exporters. They need to know when something’s broken, what it’s costing, and — increasingly — why it broke, without becoming part-time observability engineers.

The lightweight-agent alternative

VantraOps takes a different default: a single read-only agent, installed with one Helm command, that streams metrics, health state, and cost signals to a hosted control plane. There’s no Prometheus TSDB to size, no Grafana instance to patch, and no Alertmanager routing tree to maintain — the debounced health checks, the deduplicated events feed, and the cost-to-utilization mapping described above are the product, not something you configure on top of it.

helm repo add vantraops https://charts.vantraops.com
helm install vantraops-agent vantraops/agent \
  --set enrollmentToken=<generated-in-portal> \
  --set apiBaseUrl=https://api.vantraops.com

The agent’s ServiceAccount is read-only by default — get, list, watch — and enrollment tokens are single-use with a 15-minute TTL, so there’s no standing credential exposed during setup. See the full breakdown on the platform overview or how credentials are isolated per tenant on the security page.

Frequently asked questions

Do I need to rip out Prometheus entirely to use this approach? No. If you already export Prometheus-format metrics for a specific workload, that’s orthogonal to fleet-level monitoring — the two can coexist. The question this post is really asking is whether you need to operate the full stack just to get baseline visibility across your clusters, and for most small teams the answer is no.

What happens to dashboards I’ve already built in Grafana? Nothing — they keep working if you keep Grafana running for that purpose. The tradeoff is whether maintaining them is worth it once fleet-wide health, cost, and AI-assisted root cause analysis are available without dashboard upkeep.

Is a hosted agent-based model less secure than self-hosted Prometheus? It depends on your threat model, but the relevant design choices are: read-only RBAC by default, single-use enrollment tokens, and hard tenant isolation enforced server-side on every query — not just filtered in the UI. Details are on the security page.

How does this compare on cost to running Kubecost or OpenCost alongside Prometheus? Cost-only tools solve one piece of this puzzle. See our breakdown of Kubecost alternatives for small teams for how the two approaches compare directly.

Ready to see it on your own cluster? Start free with one cluster — no card required, and no dashboards to build first.