Infrastructure Monitoring
Infrastructure Monitoring tests hosts, containers, Kubernetes, and cloud services as entities with metrics, tags, and alerts. The exam focuses on choosing the right telemetry layer and explaining why a host-level average can disagree with what a container or application experiences.
Core rules
- The infrastructure agent runs on a host and sends system metrics such as system.cpuUtilization plus memory, disk, and network data. On-host integrations collect service metrics (for example web server or database metrics) through Flex or packaged integrations.
- Cloud integrations collect provider telemetry, commonly AWS CloudWatch metrics, Azure Monitor, and Google Cloud Monitoring. They are agentless but can lag and may aggregate away container detail.
- Kubernetes monitoring adds cluster, node, pod, deployment, and namespace context. The Kubernetes cluster explorer is the starting point for pod restarts, pending pods, and resource pressure; application traces supply the request-level view.
- Tags and labels drive entity search, dashboards, and alert scoping. High-cardinality labels increase cost and make aggregation noisy.
Worked example
A node reports 95% CPU and the application reports latency. The host average is not enough: filter to the namespace and pod, then compare CPU requests and limits with actual usage. One pod has a 500m limit and is being throttled while the node still has idle capacity. Raising the limit or fixing a busy loop resolves the latency; adding more nodes would not.
Traps
Host averages can hide core saturation and noisy neighbors. A missing entity is often an agent or integration installation issue. Cloud metrics may be delayed or pre-aggregated. Do not alert on raw CPU without a baseline or a service-level symptom.