metricbeat

To investigate a slow service, operators need measurements from both the application environment and the machines running it. Metricbeat collects statistics such as resource use and service-specific counters, then forwards them to a configured analysis or storage system. Its Kubernetes deployment combines information from individual workers with cluster-wide information. It is a collector, rather than the dashboard or long-term database, and those collection scopes need to avoid gaps and duplicate data.

Current guidance

The current Kubernetes deployment uses a DaemonSet for node-local collection, while one elected instance handles cluster-wide sources such as Kubernetes events and kube-state-metrics. This is materially different from running every configured metricset independently on every node.

Compare the old Deployment, DaemonSet and ConfigMaps with the target manifests. Elastic specifically warns about redundant components left over from earlier layouts. Confirm kube-state-metrics availability, kubelet connectivity, service-account permissions and certificate trust. Control-plane taints and namespace scheduling rules may prevent the agent from reaching some nodes even when all scheduled Pods are healthy.

Validate a known node, Pod and Deployment against both the Kubernetes API and the resulting events. Check that node-level series cover the intended fleet and that cluster-wide measurements are not multiplied by the number of agent replicas. Review collection periods and metadata labels before expanding scope, since these affect ingestion volume. If adopting Elastic Agent instead, map datasets and dashboards explicitly; a new collector name does not ensure identical fields, permissions or operational coverage.