-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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] Better document default metricsets #12648
[Metricbeat] Better document default metricsets #12648
Conversation
Thank you for starting this! Docs are currently collected by https://github.com/elastic/beats/blob/b99ff2b20e5385ba72013b513d3e48a29d9f94c5/metricbeat/scripts/docs_collector.py, while at some point we should move that logic to |
Ah, that's the thing that's run by |
The ideal way to do this, and I don't think it'll be too hard, is to have some mage rule that generates the docs and inserts it into the |
Yes, this is one of the TODOs in #10238, feel free to create and link an specific issue for that.
These files are edited by the user, and never modified by make/mage as of today. How about doing that on |
@exekias That makes much more sense. I wonder if this is a good opportunity to just tear out the old python2 docs scripts and replace them while we're at it. |
That would be awesome! as long as it doesn't get too complex. Another approach would be adding this to the existing script and create an issue to replace it with Go |
@@ -13,3 +13,9 @@ The ZooKeeper metricsets were tested with ZooKeeper 3.4.8 and are expected to wo | |||
The Zookeeper module comes with a predefined dashboard: | |||
|
|||
image::./images/metricbeat-zookeeper.png[] | |||
|
|||
== Default Metricsets | |||
The following Metricsets are default: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
metricsets should be lowercase
That seems like it would be duplicating a lot of work? I've started digging into my mage stuff and I don't think it would be adding too much complexity to just port it over. |
Finally making headway on this now that we have two more PRs merged. Plan is still to have a separate go script that actually imports the registry code and generates the list, then to have the 'main' mage doc role actually generate the asciidoc. |
0cdc11f
to
5e15220
Compare
Okay, so, I pushed a PR that adds an Still undecided about how to actually document the default metricsets. This just adds a conditional line to the metricset-level docs. Do we want to add something to the module docs? Or the complete module list page? |
@@ -7,6 +7,7 @@ This file is generated! See scripts/mage/docs_collector.go | |||
|
|||
include::../../../module/aerospike/namespace/_meta/docs.asciidoc[] | |||
|
|||
This is a default metricset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will users know what we mean when we say that it is a default metricset? I wonder if it might be better to say something like "This metricset is enabled by default."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yah, I was debating about the language here. In this case, default means "This metricset will be enabled if the module is not configured" which seems...subtly different? Maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's still some ambiguity though. Precise and concise are always at odds. :-)
Let's just leave it as you have it for now (This is a default metricset) and see if users are confused by the language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also link to the page that explains what a default module is too.
metricbeat/scripts/msetlists/main.go
Outdated
_ "github.com/elastic/beats/metricbeat/include" | ||
"github.com/elastic/beats/metricbeat/mb" | ||
_ "github.com/elastic/beats/x-pack/metricbeat/include" | ||
xpackmb "github.com/elastic/beats/x-pack/metricbeat/mb" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we can import code from x-pack in OSS code 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh bah, I didn't even think of that. You're probably right. We need that to make sure we can add the light modules to the list. Is there a reason that code is in the x-pack dir? Are light modules going to be a basic-and-up thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not only about light modules, native modules in x-pack won't be listed if we don't include github.com/elastic/beats/x-pack/metricbeat/include
.
Okay, I put in a quick commit to demonstrate two scripts each for OSS and x-pack. Yes, the scripts are nearly identical, but they're also < 30 LoC before the license header. |
} | ||
|
||
return masterMap, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's go with this approach, it'd be similar to other x-pack scripts being called from OSS build scripts.
Okay, this moves the bulk of the logic to a new little library. The actual main functions are just little 5-line shims now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems this needs a mage update fmt
.
9668f21
to
9334a67
Compare
Changed the wording a bit, since I liked @Titch990 's version. Lets see if CI is green now. |
Also, @Titch990 , Yah, there's tons of manually added metricset lists in the modules doc, and we need to figure out how to address those. We'd probably have to go through and remove the hand-written ones, then add the template code to do the lists in the generator. That's a big enough undertaking on its own, and we might wanna do it as a separate PR. |
So, I had to make some changes so this is bypassed if we're running inside a generator. I'm not sure if a metricbeat-custombeat can have a concept of "default metricsets" but that'll...probably have to be its own PR. |
jenkins, test this |
@@ -11,6 +11,7 @@ This file is generated! See scripts/mage/docs_collector.go | |||
{{end -}} | |||
include::../../../{{.Mod.Path | basePath}}/{{.Mod.Base}}/{{.Metricset.Title}}/_meta/docs.asciidoc[] | |||
|
|||
{{if .Metricset.IsDefault}}This is a default metricset. If the host module is unconfigured, this metricset is enabled by default.{{end}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit. It should be possible to avoid the empty lines added when metricset is not default with something like this:
{{if .Metricset.IsDefault}}This is a default metricset. If the host module is unconfigured, this metricset is enabled by default.{{end}} | |
{{if .Metricset.IsDefault -}} | |
This is a default metricset. If the host module is unconfigured, this metricset is enabled by default. | |
{{end -}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh, those newlines get me every time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, all this seems to do is remove the newline when the metricset is default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, it somehow removes two newlines as opposed to one.
Okay, that should fix the newline issues. |
jenkins, test this |
See #12502
This is a change to better document the idea of 'default metricsets' and to add a section to each module asciidoc saying what the default metricsets are, as the logic is buried in code.
The reason this is a draft is, obviously, that there's a doc change for only one module. I figured before I ran this change on everything we should look it over and decide if we're happy with format/everything else.
I wrote a simple bash script to extract the default modules and add the blurb you see in the draft PR. Is this how we want to do it? Do we want to create some make/mage recipe?