One of the things we discussed with Matthieu as a possible contrib after
the pulsar mailqueue based assembly was implementing metrics-api using
opentelemetry[8] and to drop the need for custom reporter integration in
favor of configuration based reporters[9] ( don't hesitate to beat us to
it ! :p )
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?
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
