Skip to content
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

Add option for global kubernetes autodiscover #10578

Closed
jsoriano opened this issue Feb 5, 2019 · 6 comments
Closed

Add option for global kubernetes autodiscover #10578

jsoriano opened this issue Feb 5, 2019 · 6 comments
Labels
containers Related to containers use case discuss Issue needs further discussion. enhancement libbeat Team:Integrations Label for the Integrations team

Comments

@jsoriano
Copy link
Member

jsoriano commented Feb 5, 2019

Currently, beats in kubernetes are thought to be run as a daemon set where each beat collects information from the pods running in the same node, and from the node itself.

Autodiscover is built on this premise and it only discovers pods running in the same node.

Running the beat in the same node as the observed pods is necessary for example in filebeat because it needs access to local files, but it doesn't need to be necessary in metricbeat modules, that could be connecting to network endpoints.

(The kubernetes module is an exception to that, it collects information from the API and don't need to be associated to any node, and is actually recommended to be run from a single Deployment per cluster)

The proposal is to add an option to remove this dependency between autodiscover and the node where the beat is running, so, when possible, pods are discovered from a different node. This would allow different deployment architectures in special cases:

  • Monitoring services from an endpoint external to the cluster, this can be quite interesting for heartbeat for example.
  • Collect metrics from a single metricbeat pod. For example to collect prometheus metrics from all the cluster from a single metricbeat pod.
@jsoriano jsoriano added enhancement discuss Issue needs further discussion. libbeat containers Related to containers use case labels Feb 5, 2019
@beckjim
Copy link

beckjim commented Feb 7, 2019

👍
This is actually a requirement for #10292 which is very similar to this one and is for collecting logs from the kubernetes API.

@exekias exekias added the Team:Integrations Label for the Integrations team label May 28, 2019
@exekias
Copy link
Contributor

exekias commented Jul 3, 2019

👍 to doing this, I would add a new parameter to add_kubernetes_metadata and kubernetes autodiscover provider, how about scope, with possible values of node (default) or cluster?

@beckjim
Copy link

beckjim commented Jul 4, 2019

👍 yes, such a scope would be very helpful. Actually I can see the following scope/namespace patterns (obviously requiring appropriate permissions):

  • node / all namespaces
  • node / single namespace
  • cluster / all namespaces
  • cluster / single namespace

At the moment I use a simple hack to the source code to disable (comment out) the check for the current node to get the cluster scope working for me, because I urgently needed it.
Unfortunately I'm not quite sure about side effects. I'm not familiar with the k8s library being used ...

@exekias
Copy link
Contributor

exekias commented Jul 4, 2019

namespace scope is a fair request. I wonder how you would use a theoretical node+namespace request. I wonder if for this case it would be better just to use node scope and then filter on namespace.

@nithril
Copy link

nithril commented Aug 30, 2019

It would make sense too for heartbeat. IMHO having a daemonset is not really necessary.

@exekias
Copy link
Contributor

exekias commented Jan 14, 2020

#14738 added the scope parameter that should provide this feature starting with 7.6

@exekias exekias closed this as completed Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
containers Related to containers use case discuss Issue needs further discussion. enhancement libbeat Team:Integrations Label for the Integrations team
Projects
None yet
Development

No branches or pull requests

4 participants