Infrastructure, Host, and Container Monitoring Administration
This domain tests infrastructure, host, and container monitoring administration: what the agent collects, how container and Kubernetes visibility is enabled, and how to interpret gaps.
What is monitored
Host monitoring covers CPU, memory, disk, filesystem, network, processes, and host metadata. Container monitoring uses cgroup data plus container metadata; Kubernetes adds cluster, node, namespace, pod, deployment, and service context. The Infrastructure map and host and container views depend on agent coverage and correct metadata.
Placement and permissions
Install one host agent per host. For containers, the agent may run on the host or as a container; it needs access to host filesystems and container runtime metadata. In Kubernetes, the operator DaemonSet must run on every node, and its service account needs read access to the Kubernetes API. Do not schedule agents only on a subset of nodes unless that is intentional.
Worked example
Pods from one namespace are absent, but node metrics are present. Check that the DaemonSet pod is Running on the affected nodes, then verify the Kubernetes sensor is enabled and the agent can reach the API server. Finally confirm namespace filters or RBAC are not hiding the workload.
Traps
Missing host PID or filesystem mounts, an agent running in a restricted namespace, and assuming container metrics equal host metrics all cause blind spots. Also check that the monitoring agent is not counted as an application container by your own filters.