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! >
