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
Unify metric name and format in client libraries #572
Comments
Thanks for opening this. Yes, I just recently merged a change to the Go client with renamed metrics. The objective is to change all clients to emit similar metrics. I just booked issues for the other clients. |
@NeoCN , how did you get the output listed under the "java service" on your first comment? |
@jpkrohling impl |
Is it your own implementation of the |
+1 would be great to get this contributed! |
@jpkrohling @objectiser yes, my own implementation; I can make a pull request tomorrow, it is too late to go bed now. |
Some people have complained (#732 and jaegertracing/jaeger-client-java#335 (comment)) that the colon |
@yurishkuro Correct, the colon is "reserved" for end users, and should not be used in metric names as exposed by source. There is no technical namespace separator in Prometheus metrics right now. We've been considering it as part of OpenMetrics, but for now we don't have a solution. |
we just released 1.5 where the colon is no longer used, but that only applies to the backend metrics. |
We still have an issue with consistency across clients - only looking at Golang and Java currently: Baggage
Reporter
Sampler
Spans
Traces
ProposalThere are common metrics across the two languages with consistent tags which is good. The Go client has some additional metrics based on throttling. Haven't looked at the rpc request metrics yet. Therefore this should just be a renaming exercise:
One question would be - should the language be a tag, to enable metrics to be segmented by language if necessary? Thoughts on the proposal? |
Deleted my previous comment, it was redundant. ☕ lacking today. The proposal looks good. I don't see a reason to have different metric names per language. As long as metrics have the same meaning, they can remain the same. If you had something that was java specific, I might namespace the metrics like |
@SuperQ Thanks for the feedback. I was more wondering whether all the metrics produced by each language client should include a tag to identify which language client produced it? Not sure if that would be useful, but just an idea. |
No, I don't think a label for language would make sense. It's not really necessary in the Prometheus ecosystem. |
Discussion at today's team meeting - agreed that we should standardise across languages, using |
What's the current status? Looks like we are only missing C++? |
Jaeger client libraries are officially deprecated |
running both golang and java service, and found out the metric name generated was different, for example, with prometheus:
Java:
Golang
Unify metric name and format in client libraries can help metric collector and monitor
The text was updated successfully, but these errors were encountered: