[metricbeat]kubernetes kube-state-metrics service

[odacremolbap]

kubernetes Service metrics for kube-state-metrics.

refer to https://github.com/kubernetes/kube-state-metrics/blob/master/docs/service-metrics.md for the expected information.

[odacremolbap]

jenkins, test this

[odacremolbap]

jenkins, test this

[odacremolbap]

jenkins, test this please

[odacremolbap]

issues do not seem related.
reviews are very welcomed.

[odacremolbap]

jenkins test this

although issues are not related

[odacremolbap]

@ChrsMark gracias for the review.

There are 2 of your concerns still open.

• a comment at code, which I hope we agree on easily
• allow for transformation on non-mapped labels. Non mapped labels are something new, they don't feel 100% native to current prometheus helper, since it has a "transform the event" processor that doesn't fit this scenario. My very personal opinion is that adding a second processor function is doable, but the overall design dives into quirkiness. I would like to consider all lessons learned from what we have found fetching kube-state-metrics to revisit the prometheus helper.

[ChrsMark]

@ChrsMark gracias for the review.

There are 2 of your concerns still open.

• a comment at code, which I hope we agree on easily

I'm ok with that just it would be good to add a small sample of input/expected output to make it more clear. I got this insight from the tests but would be nice to have it in the docstring too.

• allow for transformation on non-mapped labels. Non mapped labels are something new, they don't feel 100% native to current prometheus helper, since it has a "transform the event" processor that doesn't fit this scenario. My very personal opinion is that adding a second processor function is doable, but the overall design dives into quirkiness. I would like to consider all lessons learned from what we have found fetching kube-state-metrics to revisit the prometheus helper.

+1 on skipping this for now. Do we have a tracking issue for stuff like that regarding the Prometheus helper where we could add this?

[odacremolbap]

+1 on skipping this for now. Do we have a tracking issue for stuff like that regarding the Prometheus helper where we could add this?

we have some closed ones regarding the unified kube-state-metrics metricset and the changes the prometheus helper needed based on what we were finding. I will create a new issue including all that info so we can discuss.

thanks!

[ChrsMark]

thanks for the changes!

[ChrsMark]

I'm gonna manually test this. Any testing notes @odacremolbap to be added?

[odacremolbap]

@ChrsMark nop,

I'm pretty sure you know how to handle this, but if someone needs a guidance testing, this should help

[ChrsMark]

Tested this manually and works as expected. Only problem found is that the fields' mapping is not updated at https://github.com/elastic/beats/blob/master/metricbeat/module/kubernetes/state_service/_meta/fields.yml#L31 after the changes applied at #15190.

@odacremolbap I will set this one to test-plan-ok once the change in fields.yml is merged to 7.6.