Open tjquinno opened 1 year ago
FWIW, the dependency package is 'helidon-metrics'. Perhaps "Helidon Metrics" is a reasonable title for Quick Start and/or CLI interview. The documentation is clear that the implementation is "... inspired by—but does not fully implement—the MicroProfile Metrics specification."
Conclusion of discussion:
The archetype should offer Helidon metrics as a yes/no choice.
Micrometer metrics integration should be separate yes/no choice.
Helidon and Micrometer metrics should not be presented as peer choices (i.e., not radio buttons).
From the public helidon-users slack channel: https://helidon.slack.com/archives/CCS216A5A/p1674059219702039
The user ran
helidon init
to create a custom SE app, selected yes for observability and yes for metrics.The user was surprised to be given a choice "MicroProfile" while generating an SE app.
There are at least two potential problems with this:
Users might expect that given the two choices that they are two roughly equivalent choices (as with, for example, the JSON library choices offered). That's not the case here.
The Micrometer work is an integration with Micrometer but that is completely parallel to and separate from Helidon's metrics. Perhaps most importantly, the Helidon-provided metrics are not present in the Micrometer meter registry if the user chooses that.
What would be clearer, I think, would be if the user says yes to metrics then that's it--we add the dependency on
helidon-metrics
and create and register the metrics service in the generated Java code.In my mind, it would be fine for users to manually add the Micrometer integration if they want it and not have
helidon init
ask about Micrometer at all.Notes from our group consensus reached on 23 Jan:
We should revise the starter and CLI so that users who choose observability -> metrics will always get the MP metrics-inspired Helidon metrics API and impl. As an option (boolean in Romain's terms) they can also add the Micrometer integration (default = no).