Replies: 2 comments
-
Just a progress update on this. We have effectively switched the preferred way of getting metrics out of NB to using a prom-push mechanism, which we prefer to use with victoria metrics due to it just being built-in. Graphite registry structure is still present, although it will be replaced by a label-set inventory registry ASAP, since the naming structure used with the dropwizard approach breaks cardinality unless you serialize the whole labelset into a name, and if you do that, it is unwieldy to use as a dynamic registry at all. In the mean time, both graphite core semantics as well as labelset semantics are simultaneously supported. This will not endure, as there is not much reason to keep the graphite structure around. Further, the service interface for most of the metrics instruments has been moved effectively behind facade types at least, and the boundary between the dropwizard library and core NB logic will continue to be marked out for modularity. Docs for the labeling system and other features will be forthcoming as soon as we catch up. |
Beta Was this translation helpful? Give feedback.
-
Current main branch on Java 21 (5.21/main) supports dimensional metrics lables natively now. It also builds on the instrument types which are extended versions of the core dropwizard metrics types to provide additional capabilities. The preferred way to get metrics from 5.21 is by using the --report-prompush-to option, which alignes metric reporting patterns to client behavior and timing. |
Beta Was this translation helpful? Give feedback.
-
The way NB integrates metrics is non-trivial, given that it is a flexible testing tool where instrumentation is one of the primary features. However, the library that it has been based on historically (dropwizard, nee codahale metrics) has not kept up with metrics or observability tech. This was ok for awhile, but there is now a limitation which is affecting integration robustness in other places: The lack of proper labeling or tagging support for instruments.
The support and community around dropwizard metrics has waned in lieu of other options. It is now officially being maintained in version 4 while version 5 is "on hold": see the status here. This puts the dropwizard metrics ecosystem squarely in the same bucket as Ye Olde Graphite.
While we would ideally be able to help the dropwizard metrics project move forward, the scope of NB development needs to remain focused, using what tools are established and trusted in the ecosystem. The effort of pulling the metrics library forward and maintaining it for the current and future NB requirements would likely eclipse much of the work in the NB project.
Rather than wrap the dropwizard metrics library further, there needs to be a plan to refactor an alternative in place.
Here's a sketch for how to approach it:
Given that NB uses several types of customization around the dropwizard metrics core, this will be an incremental process.
Beta Was this translation helpful? Give feedback.
All reactions