How to Monitor Traditional Infrastructure Alongside Kubernetes

Inventory what must be observed

Traditional infrastructure may include physical servers, virtual machines, network appliances and vendor-managed systems with limited interfaces. Kubernetes adds dynamic workloads, service discovery and control-plane dependencies. Start with the operational questions for each group rather than forcing every asset through the same collector.

For each service, list its supporting assets, owner, environment, available protocol and expected lifetime. Separate ephemeral pods from persistent dependencies. A replaced pod can be normal, while a missing database host may represent an immediate coverage failure.

Choose collectors by capability and access

Use supported host, application or network collectors appropriate to the target. Node exporter (opens in a new tab) is one example for machine metrics; it does not replace application instrumentation or every platform-specific collection method.

For Kubernetes, verify the service-discovery permissions and label selection that determine which targets are observed. Prometheus configuration (opens in a new tab) documents multiple discovery approaches. Keep credentials scoped to the required inventory and avoid treating network reachability as unrestricted collection permission.

Normalize response identity

Map incoming conditions to stable service, environment and owning-team fields. Preserve the original source and resource identifier for investigation. The same service can have host saturation, pod errors and an external availability check without those being duplicate observations.

Define which condition deserves a page and which belongs in a work queue. A shared receiver should not convert every low-level hardware warning into an urgent service incident. Google's monitoring guidance (opens in a new tab) distinguishes operational symptoms from supporting diagnostic signals.

Use the ownership guide to define fallback for a new or unknown resource. An unrecognized device should not disappear merely because no application team label was attached.

Show coverage as well as health

Compare the expected inventory with recently observed targets. Keep “not monitored,” “stale” and “healthy” separate. A dashboard containing only discovered systems cannot reveal an asset that was never discovered.

Record the level of visibility per service. A network ping, host metrics and an authenticated business transaction answer different questions. Displaying them all as equivalent green checks hides meaningful limitations.

Exercise both environments

Use controlled test assets to simulate a failed host collector, an unreachable network device, a removed Kubernetes discovery label and a workload rollout. Confirm that each condition appears with the right owner and source context.

Then test a failure in a shared dependency that affects both environments. Verify whether grouping reduces duplicate notifications without suppressing an independent service failure. Record the detection and delivery timing rather than checking only that a dashboard changes color.

Finally, have an incoming responder trace one alert from each environment to its source and first safe check. Keep the collection-specific runbooks behind the common service view, and review inventory changes alongside deployment and infrastructure changes so coverage does not drift silently.