Describe the feature
Adopt opencensus for metrics and tracing
Additional context
https://opencensus.io/
@h7kanna Could you elaborate a bit on why you want this? Also, would you like to work on it?
Hi, Opencensus is vendor neutral metrics, tracing facade. similar to Micrometer.
Yes, I would like to contribute to this.
@h7kanna Any update on this?
Hi, OpenCensus is undergoing change in spec, there is a plan to merge it with Opentracing. May be this feature should be worked upon once that is done.
https://medium.com/opentracing/merging-opentracing-and-opencensus-f0fe9c7ca6f0
Sounds fair, let's put this on hold until that's resolved.
@h7kanna any update on this?
Hi sorry for the delayed response. I am following the development of https://opentelemetry.io/ https://github.com/open-telemetry/opentelemetry-java is still in development.
https://github.com/open-telemetry/opentelemetry-specification/blob/master/milestones.md
This feature request should wait for it.
Thanks
For what it's worth I'm unconvinced by the metrics part of opentelemetry.
We believe the three metric kinds Counter, Gauge, and Measure form a sufficient basis for expression
For myself I think this is a weak statement, I'll be very interested to see how this ends up in practice. One of the key metrics we are generally interested in is execution time of endpoints (and the rollup/aggregation of that for all endpoints). As I see it this isn't properly addressed by opentelemetry as it currently stands.
For myself, as I see it there are 2 schools of thought wrt "timing metrics implementation". Histogram & percentile based approaches vs simple metrics (count, total, max, mean) approaches. If you collect metrics frequently enough like every minute or better then simple metrics have the strengths of being much cheaper and easily aggregated (aggregate all pods/instances of a given service each 1 min + rollup by time).
I'm in the "simple timed metrics" camp. I have a metrics plugin that I use that automatically adds metrics timing to all Javalin controllers (via AOP). It collects timings on all controller method calls with the intention that metrics are collected every minute (or better but generally every minute is good). The documentation for this approach needs updating, I'll look to do that and post back here.
Note that there is no required change for Javalin to support these metrics (they work via AOP on any API via a @Timed annotation. Generally we want add metrics to time services as well as endpoints).
In my opinion it would be good to have side by side examples showing the use and results of each of the metrics libraries.
Hi again @h7kanna, this has been open for a year now. Maybe we should close it and rather re-open the issue if/when opentelemetry-java is ready?
yes. I am closing this. Will reopen when opentelemetry-java is GA
Most helpful comment
For what it's worth I'm unconvinced by the metrics part of opentelemetry.
For myself I think this is a weak statement, I'll be very interested to see how this ends up in practice. One of the key metrics we are generally interested in is execution time of endpoints (and the rollup/aggregation of that for all endpoints). As I see it this isn't properly addressed by opentelemetry as it currently stands.
For myself, as I see it there are 2 schools of thought wrt "timing metrics implementation". Histogram & percentile based approaches vs simple metrics (count, total, max, mean) approaches. If you collect metrics frequently enough like every minute or better then simple metrics have the strengths of being much cheaper and easily aggregated (aggregate all pods/instances of a given service each 1 min + rollup by time).
I'm in the "simple timed metrics" camp. I have a metrics plugin that I use that automatically adds metrics timing to all Javalin controllers (via AOP). It collects timings on all controller method calls with the intention that metrics are collected every minute (or better but generally every minute is good). The documentation for this approach needs updating, I'll look to do that and post back here.
Note that there is no required change for Javalin to support these metrics (they work via AOP on any API via a
@Timedannotation. Generally we want add metrics to time services as well as endpoints).In my opinion it would be good to have side by side examples showing the use and results of each of the metrics libraries.