Hi Subhanshu, Thank you for the contribution!
The module looks good and will add value to the use cases you mentioned. My concern is that `drools-opentelemetry` looks like a feature built on top of the Drools engine, so it may not be appropriate to place it at the top level of the `drools` repository. Maybe we could have an umbrella directory like `drools-contrib` or `drools-experimental`. Does anyone have thoughts? Toshiya On Wed, Feb 25, 2026 at 8:42 PM Francisco Javier Tirado Sarti <[email protected]> wrote: > > Hi, > Nice addition. > Although not completely related, I think it is worth mentioning that there > is already some OpenTelemetry usage in the kogito-runtimes repository. > Here > <https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/quarkus/addons/opentelemetry> > node > listeners are used to trace the progress of the Workflow. > I do not think it will conflict with what you are planning to do (If I > understood correctly, you are adding OpenTelemetry only to the rule engine) > Also, since Quarkus's POM handles OpenTelemetry dependencies, we are good > on that too. > > > > On Wed, Feb 25, 2026 at 12:37 AM Subhanshu Bansal < > [email protected]> wrote: > > > Hi Everyone, > > > > I have opened a PR to implement support for OpenTelemetry for Drools. > > > > PR: https://github.com/apache/incubator-kie-drools/pull/6595 > > > > This is a separate module and why I used Open Telemetry specifically is > > because it gives you production visibility into how your Drools rules are > > actually behaving in a running system. Here’s what that means concretely > > for this project:Distributed TracingWhen rules execute inside a > > microservice, the TracingAgendaEventListener creates spans that connect to > > your existing traces. If a REST request hits your service, triggers rule > > evaluation, and then calls a downstream service, you get one unified trace > > showing exactly which rules fired, how long each took, and what facts were > > involved. Without this, Drools is a black box inside your trace — you see > > the request enter and leave, but nothing about the decision logic in > > between.Metrics for Production MonitoringThe MetricsAgendaEventListener > > exposes counters and histograms that flow into whatever backend you already > > use (Prometheus, Datadog, Grafana, etc.). This lets you: > > > > - Alert when a rule suddenly fires 10x more than usual (possible data > > issue or regression) > > - Dashboard rule firing latency to catch performance degradations before > > users notice > > - Compare rule firing patterns across deployments (did the new rule > > version change behavior?) > > > > Why OpenTelemetry specifically (vs. the existing Micrometer in > > drools-metric)The existing drools-metric module focuses on internal > > node-level constraint evaluation metrics via Micrometer. OpenTelemetry adds > > a different dimension with metrics and tracing. > > > > The key differentiator is correlation. When a customer complaint comes in, > > an SRE can search traces by the request ID, see exactly which rules fired > > during that request, how long each took, and what facts were inserted — all > > without adding any logging or redeploying. That’s the operational benefit > > that the existing drools-metric module doesn’t address. > > > > I am open to all the suggestions. Feel free to reach out. > > > > Thanks! > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
