2. Today we could add an extension mechanism exposing metrics and > enabling exports. > > Concretely, takes a dropwizard MetricRegistry in, outputs metrics out. > > The downside is that we enforce the dropwizard choice onto out users, > thus making it harder to change this component when required. >
I'm not sure I understand the enforcing thing. The metrics-api only has 3 implementations - test which is not used for prod - logs not sure how usable that is in production - dropwizard metrics when we have another implementation we can offer choice all I am aiming for is an alternative to metrics-es-reporter-v7 I clearly don't understand the james extension mechanism :D > > I would first attempt to implement the graphite/collectd reporter > binding, > > then look into opentelemetry since the former is supposed to be less work > > than the latter. > A lot less actually > https://metrics.dropwizard.io/4.2.0/manual/collectd.html // > https://metrics.dropwizard.io/3.1.0/manual/graphite/ :-) > > It should be trivial. well my attempt at cloning metrics-es-reporter-v7 into a metrics-influxdb-reporter didn't prove all that trivial but that may be linked to both my lack of understanding of james and/or a particularly poor reporter implementation for influxdb ( it was 3rd party not part of the metrics core as graphite and collectd are) > The hardest would be to keep the classpath of non > collectd users clean, which could be achieved via an extension mechanism > located into > https://github.com/apache/james-project/tree/master/third-party. You > would drop the JAR into extension-jars folder, register your metric > reporter FQDN into extensions.properties and go. Even user supplied Jars > would be supported. > yeh that's something I don´t understand. This is not how the es reporter is implemented, instead it is statically bound at compile time in the guice container configuration again I must be missing something jean
