Kubernetes autodiscover - multiple ports

[anyasabo]

Describe the enhancement:
For ECK we have multiple exposed ports on our Elasticsearch containers -- http and transport. When using autodiscover, it would be helpful to be able to specify which port we want to use for metricbeat. @exekias did some looking for me, and currently $data.port sets up events for all of the defined ports, but the transport one will not work and generate errors. If we could specify which port we want to use in our autodiscover configuration it would be helpful.

Maybe referencing the name of the port (e.g. $data.ports.http), the index of the port ($data.ports[1]), or maybe with a hint telling autodiscover which port name to use (co.elastic.metrics/metrics_port: http)?

[exekias]

This is a fair request, thank you for opening!

The issue comes from the fact that we spawn an autodiscover event for every port in the Pod. Configs like ${data.host}:${data.port} would end up in several instances of the module, which is probably not what the user wants.

I think offering data.ports in the events makes sense, as it would allow users to pin the port they are interested on. I'm leaning towards allowing for named ports only, through ${data.ports.<port_name>}. Port names are guaranteed to unique per Pod. Unnamed ports would not be available in that dict.

thoughts @odacremolbap @ChrsMark @vjsamuel ?

[ChrsMark]

+1 for the ${data.ports.<port_name>} approach. Sounds reasonable.

[exekias]

@anyasabo would named ports only be useful for you? I'm worried about using the index number for this, as a slight change can result on unexpected behaviors

[ChrsMark]

@exekias @anyasabo wondering if this one is still valid after the changes happened at #18979 and #19052.

cc: @vjsamuel @jsoriano

[anyasabo]

Ah sorry I missed your earlier question @exekias , yes specifying the named port would be helpful.

@ChrsMark if I understand the description correctly, the first PR linked only changes behavior when ports are not exposed. In this case multiple ports are exposed but we only want to scrape one.

Ditto with the second one it's definitely possible I'm misunderstanding, but it looks like that fixes a bug in how we were doing substring matching (e.g. 80 matched port 8000), so I also don't think that helps here.

[ChrsMark]

👍 @anyasabo thanks ! I will provide a patch to support ${data.ports.<port_name>} too 🙂 .

[jsoriano]

If the port is known, setting it in the configuration, without using data.port, should work, something like this:

co.elastic.metrics/module: elasticsearch
co.elastic.metrics/hosts: ${data.host}:9200

I think that this recent fix #18979 by @vjsamuel will prevent that configurations like these ones start unexpected modules, so this could work to avoid starting a module for the transport port in this case.

In any case having support for ${data.ports.<port_name>} sounds good.

[vjsamuel]

You should just be able to do ${data.host}:8080 and it should work out of the box right? If you have multiple configurations on the container then you can use the multiple hints support that was recently merged as well.

[ChrsMark]

What @jsoriano and @vjsamuel mention, using directly sth like ${data.host}:8080, was what made me thinking about this one initially.

However I think that what @anyasabo requests is slightly different and it comes to @jsoriano 's In any case having support for ${data.ports.<port_name>} sounds good.

In any case I drafted sth for the shake of this discussion: #19398

[ChrsMark]

Closed via #19398