A cluster does not add a monitoring requirement so much as four extra layers that can be the cause, none of which are your code. Without a platform team, the constraint is that nobody has time to become expert in any of them.
What actually changes
Workloads become short-lived, which breaks the discovery assumptions described in the article on polling and agents: an instance that exists for forty seconds will never be found by a system that goes looking every minute.
Instance names become unique per deployment, which is the quiet cardinality problem: series accumulate at the rate you deploy, and the article on cardinality explains why the count that matters is not how many exist now.
And the question "why is this slow" acquires four new candidate answers: the container was throttled, the scheduler moved it, a node was unhealthy, or the provider's control plane was having a day.
The criteria that follow
Collection must register workloads as they start rather than discovering them on a cycle. Something must monitor the cluster itself, separately from the workloads, because a cluster problem presents as several unrelated application problems. Alerts must be attached to services rather than to instances, since instances are supposed to disappear. And whatever is chosen has to survive being ignored for months.
The most valuable thing to establish early is which layer a symptom belongs to, because a team without a platform engineer will otherwise spend every incident debugging its own application for problems occurring underneath it.
Two failure modes that only appear here
The first is a workload being restarted repeatedly by the scheduler. From outside, the service is responding, because something is always running. From inside, nothing completes any long operation and the application appears intermittently broken for reasons that make no sense in its own logs. A restart counter, watched at the workload level, turns a week of confusion into a glance.
The second is resource throttling. A container held under its limit is not failing and is not idle; it is being slowed in a way that appears nowhere in the application's own view of itself. It presents as latency with no cause, and it is one of the few problems where the cluster's own metrics are the only place the answer exists.
Both are cheap to watch and neither is in a default application dashboard.
Your provider's own cluster monitoring
- Best forManaged clusters, as the baseline nobody should skip
- PricingUsually included, with charges for extended retention
- StandoutKnows about the layers you did not build and cannot see into
- Watch out forStops at the boundary of their responsibility, which is exactly where yours starts
A managed metrics service with a cluster agent
- Best forTeams who want cluster and workload metrics without operating storage
- PricingBilled per series or per host; clusters generate a lot of both
- StandoutDeploys in an afternoon and covers both layers in one place
- Watch out forSeries churn from deployments is the cost driver, and defaults are generous with labels
A self-hosted metrics stack inside the cluster
- Best forTeams with a hard in-house requirement, or existing expertise
- PricingFree to license; the cost is operating storage inside the thing you are watching
- StandoutNo per-series pricing, and it is the ecosystem everything else assumes
- Watch out forIt runs on the cluster it monitors, so a cluster failure removes the evidence
An external check plus the provider's console
- Best forVery small deployments where the cluster was somebody else's decision
- PricingNearly free
- StandoutAnswers the only question that matters at that size: is the service up
- Watch out forNo history, no correlation, and no help at all with why
The default that costs the most
Cluster agents ship with label sets designed to demonstrate capability. Pod name, container id, node name and image tag attached to every metric produce series that turn over with every deployment.
Trimming that set at the collection point, before it reaches storage, is usually the largest single saving available in a cluster deployment, and it is a configuration change rather than a project.
What we cannot verify
Provider inclusions, agent defaults and pricing differ by platform and version, change frequently, and are documented by the providers themselves; we reproduce none and rank nothing. The layer attribution problem is described from practitioner accounts rather than measured. What your own cluster generates is visible in your own series count today.
The short version
- A cluster adds four layers that can be the cause, and none of them are your code.
- Short-lived workloads defeat discovery that goes looking on a cycle.
- Instance labels accumulate series at the rate you deploy.
- Monitor the cluster separately, because its failures present as unrelated app failures.
- Attach alerts to services, since instances are supposed to disappear.
- Trimming default labels at collection is usually the largest saving available.