@pkaramol , let me add something else to the previous comments by Peter and Thibault.
What you showed here is a proposal for a Metricbeat
DaemonSet in charge of doing monitoring of each kubernetes host (with an extra
autodiscover section with
hints enabled that in my view should only be added if it's really wanted ()).
What Peter showed is an example of a Metricbeat
Deployment configured to perform monitoring of Elasticsearch pods. In order to scrape specific pods with the specified module the condition is needed, as otherwise you might end up scraping all kubernetes pods even if they are not elasticsearch pods (hence the module
elasticsearch configured in the input would fail).
I would strongly recommend to take a deep look at all the manifest and
docs I share at this repo, as I try to explain and add comments to both of the examples showed here (among other use cases).
It's important to understand every possibility of autodiscover and its implications, because thank to the flexibility it offers we might end up in unwanted configuration or duplicating our metrics retrieval without need.
For example, taking a look at both examples, you could build a single DaemonSet to perform everything (Kubernetes monitoring at host level + scraping elasticsearch pods based on some conditions), but again, the config should be different because Autodiscover when running in a
DaemonSet makes sense at
node level and Autodiscover when running in a
Deployment usually makes sense at
I hope this helps a bit, take a look also at the official autodiscover docs, because there are a lot of ways to achieve the same.