hi, I did not read much about the topic, but I got the impression that using > OpenTelemetry requires to use OpenTelemetry server and integrations > happens in there. > > > https://grafana.com/blog/2022/05/10/how-to-collect-prometheus-metrics-with-the-opentelemetry-collector-and-grafana/ > > This do not sounds like a friendly SPI, and I would be personally > reluctant to enforce usage of an external service in such a core feature... >
> Am I missing something? > The article you refer to is about how to configure the opentelemetry collector, that's an independant proxy process that can collect metrics using multiple protocols, process them and push them using multiple protocols, it's kind of like a logstash on steroids. or as if the push gateway and "retrieval" components of a prometheus install had been extracted and merged in a single tool. what would end up in james is the opentelemetry library https://opentelemetry.io/docs/instrumentation/java/ which if I understood the documentation properly is able to export using 4 fiarily common modern protocols (oltp based on grpc, prometheus, zipkin and jaeger) based on configuration only. If you are worried by the "alpha status" listed for metrics in the java lib documentation, you may want to read this article : https://opentelemetry.io/blog/2022/metrics-announcement/ the metrics components should reach general availabitliy soon. Jean > Regards > > > > > Cheers > > jean > > > > PS while writing this message I realized that 3.7.0 is not listed on > > https://james.apache.org/server/release-notes.html despite having a blog > > announcement > > https://james.apache.org/james/update/2022/03/21/james-3.7.0.html > > > > [1] https://github.com/logfellow/logstash-logback-encoder > > [2] > > > https://www.elastic.co/guide/en/observability/master/monitor-java-app.html > > [4] https://james.apache.org/server/monitor.html > > [5] > > > https://james.apache.org/server/manage-guice-distributed-james.html#Basic_Monitoring > > [6] https://metrics.dropwizard.io/4.2.0/manual/graphite.html > > [7] https://hub.docker.com/r/graphiteapp/graphite-statsd/ > > [8] https://opentelemetry.io/ > > [9] > > > https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md#exporters > > > > On Thu, Jun 9, 2022 at 9:21 AM Rene Cordier <rcord...@apache.org> wrote: > > > >> I would like to add that it seems this module has been deprecated when > >> James migrated from es6 to es7, as stated in the documentation of the > >> configuration here for example: > >> > >> > https://github.com/apache/james-project/blob/master/src/site/xdoc/server/config-elasticsearch.xml#L137 > >> > >> For likely all the reasons given below. > >> > >> So it makes sense to remove it now that we are migrating to es8. > >> > >> Regards, > >> Rene. > >> > >> On 09/06/2022 14:13, Benoit TELLIER wrote: > >>> +1 > >>> > >>> We IMO need to add that direct reporting (for logs or metrics) from the > >>> application to ElasticSearch is an anti-pattern, and pretty uncommon. > >>> > >>> It's usage led, at least at Linagora, to metrics/logs loss. The code > >>> quality of these extensions was low and proved several time > problematic. > >>> > >>> Alternatives: > >>> - Anything compatible with prometheus (pretty much all of metrics > >>> ecosystem) > >>> - Things like fluentbit to scrap logs from the container/a file and > >>> move it to your analytic stack > >>> > >>> Regards, > >>> > >>> Benoit > >>> > >>> On 09/06/2022 11:02, Rene Cordier wrote: > >>>> Hello guys, > >>>> > >>>> As working on the upgrade to ElasticSearch 8.2, I've been wondering if > >>>> it was still worth it to keep the elasticsearch metrics reporter > module. > >>>> > >>>> Since we expose a metrics endpoint that tools like prometheus can just > >>>> call to scrap metrics out of James, I think the es metrics reporter > >>>> has not been really maintained and/or used since es v6. > >>>> > >>>> As such, we decided to remove it. It allows to reduce the number of > >>>> modules loaded by James and also reduce the cost of maintenance. > >>>> > >>>> But maybe other people are still using it? If a part of the community > >>>> still want to use it with the switch to ES8, they can put it back and > >>>> migrate it, but we would appreciate that they can assume the > >>>> maintenance of it as well. > >>>> > >>>> Also removed the logback-elasticsearch-appender. It's not correlated > >>>> to our code and easy to add the JAR back on the classpath if needed. > >>>> > >>>> The PR in question: https://github.com/apache/james-project/pull/1018 > >>>> > >>>> Don't hesitate to answer this thread if you have any concerns. > >>>> > >>>> Cheers, > >>>> Rene. > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >>>> For additional commands, e-mail: server-dev-h...@james.apache.org > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >>> For additional commands, e-mail: server-dev-h...@james.apache.org > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >> For additional commands, e-mail: server-dev-h...@james.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
