New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metricbeat host network monitor over docker swarm #8685
Comments
Hi @gianpietro1, I think this is more a limitation on docker swarm than on metricbeat, and indeed there is an open discussion in this project about that. Other container orchestrators as Kubernetes support host network mode. This mode is required to access the same network namespace as the host, what is needed to monitor its network interfaces, so I don't think it is possible to overcome this limitation on our side, this would be breaking namespaces boundaries. One thing you can do if you want to monitor host network interfaces in your docker swarm cluster is to deploy metricbeat directly on all your nodes using some other configuration management solution instead of deploying them on swarm. I am going to close this issue as I don't think we can do much here, if you have more doubts about metricbeat configuration or deployment options, please use the discuss forum. |
Hi @gianpietro1 again, I replied too fast 🙂, after talking with @exekias offline about this issue he pointed that we could indeed obtain the information we use mounting the host proc filesystem into the container. We already do something like that to collect process information from the host. Here it'd be a bit different because we use a different library, but it'd be definitely possible. I'm reopening this. |
@gianpietro1 Did you try something like this ?
|
@jsoriano we tested the solution I proposed it works like a charm. |
Great, thanks for trying it and letting us know! |
@jsoriano @exekias Would you please consider re-opening this feature request? In docker swarm its possible to join a container to the host network, like @OlivierCuyp mentioned, but it makes practical deployment very difficult for a number of reasons. Most critically the container is unable to join any overlay networks, so deploying in this manner means your elastic search instance is not discoverable by metricbeat on the swarm if it is secured behind a standard swarm overlay network. |
Ok, let's reopen it to get the host network information from procfs even when metricbeat is not running from the host network. |
@aldencolerain I don't know your infra but in our case our nodes have a private & a public interface. We put an "elasticsearch" label on the nodes dedicated for Elasticsearch & a service constraint on the elasticsearch service like this: ...
placement:
mode: global
constraints:
- node.labels.elasticsearch == true We also mapped the private ips in our DNS (for the sake of flexibility) like this:
Then in the metricbeat configuration you can just add it like this: ...
output.elasticsearch:
hosts: ["elastic1.my-company.com:9200", "elastic3.my-company.com:9200", "elastic3.my-company.com:9200"] This is not perfect but it works. I hope, it helped. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi! We're labeling this issue as |
This issue has reappeared in discuss, reopening. |
For the record, if possible, I'd like the docker module to support pulling info from a bind mounted host directory. Something like what the system module does. Thanks for reopening this. :) |
Hello,
A containerized Metricbeat requires to use
network_mode: host
to be able to detect and monitor the host's interfaces, however, if deploying a stack in swarm mode with a version 3 compose file, this mode is not available (see: https://docs.docker.com/compose/compose-file/#network_mode)Would like to request the Elastic team to, if possible, implement an enhancement to overcome this limitation.
Thanks,
Gianpietro
The text was updated successfully, but these errors were encountered: