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!
