-
Notifications
You must be signed in to change notification settings - Fork 566
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
Metrics are in in camelCase #8422
Comments
|
|
Thanks for the pointer. I blindly tried but cannot build the customer app because tests fail with data source problems, I assume because That said, I will see about using the way the |
If the developer's annotation does not specify a description then although the I suppose Helidon could generate a description if none is provided, but I don't think that's a good idea. I think we have to accept what the developer tells us...if the description is omitted or is specified as an empty string (which is the default value) then we take the developer at her word and use that, regardless of what Of course if the developer cares about |
Some additional background info:
Two options come to mind for addressing this:
The first option seems problematic because there are cases where the mapping will do a poor job. The second option seems more reasonable. |
Can anything be done at Helidon level? Consequence is Helidon users will have to convert metric names in order to get them collected by Prometheus. |
The MP metrics-prescribed naming might not conform to Prometheus recommendations but in my experience the Prometheus server scrapes them successfully. If you are seeing actual errors please share them and whatever set-up you are using. |
Sorry for the delay. Finally got round to testing this. Adding the description in each annotation as @tjquinno suggested helps fix the "no help text". I agree with Tim, we should not generate the help text here. I wonder whether we should make the description as mandatory. If the annotation is added, then the description must also be added. |
On another note, I see 2 additional issues:
I don't see the need for adding method signature in the label. |
hikari units are in milliseconds:
This is probably coming from the hikari lib itself. Would it be possible to submit a PR to hikari so it also uses seconds?
|
Re: snake vs camel cases, I agree with @barchetta. If we can have a configuration option to use snake case, that would be preferable. |
This issue has morphed into a collection of several different notes/comments/requests. (And thanks to @hyder for reminding me this issue is still open.) I will try to sort some of this out. The main action item for the Helidon team from this issue: look into adding a metrics config setting so the built-in system metrics can be registered using snake_case names instead of camelCase. Original DescriptionProblem Statement 1 - camelCase vs. snake_caseAs Joe pointed out in his 4 Mar post, the MP Metrics spec does not require translation of camelCase to snake_case. If users want to register their metrics using snake_case they can. Helidon can add a metrics config option users could set so Helidon would register the built-in vendor metrics using snake_case. (If users set this then their server would no longer be MP Metrics-compliant, but this would be their choice.) Problem Statement 2 - Missing HELPThis was an omission in the application as noted in @hyder 's first 21 April note. @hyder 's second 21 Apr note"If the user provides a name, then the metric should use that name."The metric naming Helidon uses follows the spec: https://download.eclipse.org/microprofile/microprofile-metrics-5.0.0/microprofile-metrics-spec-5.0.0.html#annotated-naming-convention . The "I don't see the need for adding method signature in the label."Including the method name is required by the spec. The spec mandates that potentially several metrics be registered when you annotate the type, one for each method and constructor. The spec chose to require the method name in the metric name to distinguish these metrics from each other. @hyder 's 22 Apr note - Hikari connections creation unitsAny solution to this is entirely separate from the other concerns described in this issue. I've opened #9290. |
@tjquinno re: naming in 21 Apr note. Got it. Reading the specs, it seems that the default value for re: method signature in labels, I don't have any issue with including the method name itself, but do we need to also add the types of parameters of the method to the labels? |
TL;DR - Yes, we must include the parameter types in the Longer explanation... We have to be very specific as to which measured methods we are talking about here, because the spec mandates different behavior depending on how the metrics arise.
|
Environment Details
Problem Description 1
Metrics created by Helidon are in camelCase. Prometheus community prefers snake_case. To reproduce:
Problem description 2
No help text is generated. See above.
The text was updated successfully, but these errors were encountered: