opentelemetry is anything but lightweight, not recommended. Don't waste your time with it. if you want to expose 'metrics', it is really up to the application to do that, lucene is just a library. I'd recommend just exposing via HTTP and using prometheus & co.
Debugging performance issues in the library is totally different and telemetry as a word doesn't make sense for that You can setup 'perf' to debug performance issues. You can also run with lightweight JFR profiling built into the JVM. The nightly benchmarks already do that. On Wed, Mar 19, 2025 at 2:16 AM Vigya Sharma <vigya.w...@gmail.com> wrote: > > Hi All, > > I am debugging an unexpected throughput regression in my feature branch which > has changes across multiple files and functions, and was wondering if there's > a better way to identify the slowdown than adding elapsed time logs to > infostream. > > Do we have support in Lucene for telemetry on internal operations? It would > be nice to be able to add timers, counters, and metrics, to identify > performance changes. This would hide disabled behind a gradle flag. We could > enable it for benchmark runs and possibly chart these metrics in nightly runs. > > Has this been discussed before? I'm happy to explore this more if it sounds > like a good idea. Any suggestions for lightweight, open-source telemetry > libraries that I should look into? I'm considering OpenTelemetry but open to > alternate suggestions and ideas. > > Vigya --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
