Hello Matthieu, Le 12/03/2021 à 21:14, Matthieu Baechler a écrit : > Hi, > > My answers below. > > On Thu, 2021-03-11 at 15:17 +0200, Juhan Aasaru wrote: >> Hi! >> >> There is currently ongoing work to upgrade James to Elasticsearch 7.x >> See https://github.com/apache/james-project/pull/328 >> >> Current James can be configured to save James metrics to a separate >> index >> in Elasticsearch. >> And then Grafana dashboards can be configured to display the history >> of >> these saved metrics. >> For more detailed documentation refer the configuration parameter >> "elasticsearch.metrics.reports.enabled" here: >> https://james.apache.org/server/config-elasticsearch.html >> >> This functionality that gathers and publish metrics is provided by an >> unmaintained library: >> https://github.com/linagora/elasticsearch-metrics-reporter-java >> This library is not compatible with Elasticsearch 7.x > > It doesn't support ES7, that's true. However, this support could be > added.
If that is the way to go we then need to find someone devoting himself for this maintenance... > >> >> We are proposing to remove this functionality from James as >> the industry standard is to use external tools that are purpose built >> for >> pulling and storing the metrics. > > I don't think it's the industry standard, it's prometheus standard. The > debate never settled as far as I know. > >> >> Users currently relying on this functionality would have to configure >> some >> monitoring tool (like Prometheus) to regularly pull and store these >> metrics >> if they want to continue displaying history of various James related >> metrics over time. > > I don't like that idea. > > If we talk about the root of the problem: dropwizard-metrics is quite > rigit and we decided to include ElasticSearch appender in the product > to have it working out of the box > > Now, micrometer is doing much better: it works with an SPI much like > slf4 is doing for logging and allows to choose your implementation by > dropping the right jar. Reading the documentation... ...about Prometheus integration we still end up with some custom code, that really looks like the one we had written on top of dropwizard: https://micrometer.io/docs/registry/prometheus ...looking at the Elastic integration, we still need to start a metric registry https://micrometer.io/docs/registry/elastic I fail at seeing the benefits compared to dropwizard metrics reporters... A ctrl+f in https://micrometer.io/docs for the term "SPI" yields no result, what makes you say "we just need to drop a JAR"? > > I suggestion we just port James to micrometer and let people choose how > they want their metrics exposed. > > WDYT? More flexibility on the metric side would be IMO nice to have. I would be happy to see such contributions happens. (Can you give a precise link explaining how and why you think micrometer is more flexible than dropwizard?) Benoit Tellier > > -- Matthieu Baechler > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
