On Fri, 2021-03-12 at 21:50 +0700, Tellier Benoit wrote: > 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...
I agree, if nobody cares, we'll drop it anyway. > > > > > > > > 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 For sure, pull-based means exposing a endpoint and you have to integrate that with your existing routes. > > ...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"? SPI is written here : https://micrometer.io/docs/installing But you are right that they didn't implement the ServiceLoader thing that would allow to dynamically pick the implementation jar. It's a bit surprising to me because they claim to be "the slf4j for metrics" and slf4j is handling the dynamic loading. So in the end you are right: dynamic loading would require some work from us. Yet, as many modern frameworks use this metrics library, at least we would have up-to-date plugins. > > > > 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?) In fact, projects including micrometer (like spring boot) implement their own dynamic loading. That would make sense to contribute that to micrometer but it's probably too much work for me. Sorry, it probably didn't help much. -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
