Closed dlmarion closed 2 weeks ago
Another thing to consider would be to auto-generate markdown for publishing to the docs on the website to document the available metrics on each release, like we do with system and client properties.
I am trying to think of what the best solution here is. For the amount of metrics that we have, it seems like a table might get too big (have to scroll back up to check the column titles).
Another option would be to have just a "list" of the metrics each with its own header and have the info about each one under that. That way we could also break the metrics up into sections like general server metrics
or compactor metrics
like we do now with the comments. This might make things more readable.
Here is what that might look like as an example:
I am not sure the best way to structure the raw text for this list though. It may end up that having it in a table for development might work better and then that is rendered out to this list. Not too sure.
I am interested in hearing others thoughts on the table vs. list argument though.
@DomGarguilo I like the sections with list example. I think this better than a table because it allows more information per metric (like the recommended action and related properties sections). The table view encourage authors to be really terse.
Another thing to consider would be to auto-generate markdown for publishing to the docs on the website to document the available metrics on each release, like we do with system and client properties.
This is a good idea. I modeled #4850 after the way Property
uses an enum to store all the info that is rendered out into a markdown file.
@DomGarguilo - can this be closed now?
Closed via #4850
The javadoc table in MetricsProducer was added in 2.1 to aid in the metric usage from prior versions. Micrometer replaced Hadoop Metrics2 in version 2.1.0, which changed the format of the metrics. Post 2.1 we can change the javadoc table such that is no longer an aid for metric conversion and more of a user guide to the metrics. The table could be modified to include a description of what the metric indicates, what properties could be related that might influence the behavior of the code being monitored, what conditions to look for, and what actions to take.