Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

Hi @ChrsMark

Thank you for contributing to this! Few things are needed before merging this module, let's start with field count and naming conventions:

• The field count is way too high. While we understand that it's easy to just "parse all", later a detailed description of each field must be written in the docs and no field has any description. We try to maintain just the fields that are key to understand the health of a system and detail them well in the docs. This way the index is also smaller in size and the dashboards aren't huge. If it helps, try to think what will you place in a Kibana dashboard and remove everything else. Less is more 😉
• Fields must follow this naming conventions. For example, out_bytes must be an object called out with a sub-object called bytes

Let's start with those 2 things and keep pushing from there.

Any chance we could split up this PR in 4 PR's? First PR introducing the module and 1 metricset and then 3 follow up PR's with 1 metricset each. This would make the review easier and should get each PR in quicker.

Could you also add a changelog entry?

Hey @ruflin,

we will go along with your proposal on splitting the PR in 4 smaller.
Is there any standard process you use to do such things, or we can just open the 4 new and abandon this one?

No standard way on doing this, whatever works best for you. You could also keep this one as the "foundation" PR for the module + 1 metricset and open 3 new ones.

Hi @ruflin, the PR seems to be ready for review.

So far:

1. @sayden's comments have been addressed
2. this PR refers to the module and 1 metricset. 3 PRs will follow after this one is accepted to avoid having similiar comments/requested-changes

@ruflin we are done with the changes, could you check again?

I know I'm coming a bit late but I suggest to change the name of the metricset from varz to general or stats as you can read in the description here. What I want is to have a meaningful metricset name instead of the path of the endpoint you request to fetch the data. This will also protect the module from a potential change in the path of the endpoint.

What do you think @ruflin ?

@sayden, @ruflin great loop so far! Apart from the minors you guys mentioned, should we check the change from varz to stats regarding the name of the metricset? To my mind stats is more meaningful, and we should spend the time on it, making it more robust and future proof.

I'm on board with renaming the metricset. The goal is to make the end document as easy as possible to consume.

@ChrsMark To get CI green, I think you have to run make update again.

jenkins, test this

Is this failure relevant @ruflin?

@ChrsMark It's not, just merged it. Thanks a lot for your contribution.

I also created #10071 as a follow up issue to track the completion of the module: #10071

Cool @ruflin!
Follow up PRs (3) will come soon from @skatsaounis, @MichaelKatsoulis and me.

Great, looking forward to it.