You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Toshiya Kobayashi <to...@gmail.com> on 2026/03/02 07:24:16 UTC
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Also, having a `contrib/experimental` area can help reduce maintenance
costs. For example, it could include disclaimers such as:
- Experimental APIs may change in future releases.
- Experimental features may be removed in future releases.
- Experimental features must not block a release. For example, if an
issue is found in an experimental feature during the release process,
we may choose to disable that feature for the current release.
This is just a proposal. I’d be happy to hear your thoughts.
Toshiya
On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
<to...@gmail.com> wrote:
>
> Thank you for moving this topic forward, Alex.
>
> I agree that criteria are required.
>
> > What do you think would be reasonable criteria to establish?
>
> Here is a quick draft. Opinions are welcome:
>
> (Creation)
> - A new feature module should default to contrib/experimental (not
> limited to new contributors).
> - If a developer wants to place the module elsewhere from the
> beginning, they should start a thread on the dev mailing list (dev
> ML). If there are no objections, it is accepted. If there are
> objections, a vote will be held (Simple Majority vote:
> https://www.apache.org/foundation/glossary.html#SimpleMajority).
>
> (Promotion)
> - If anyone wants to promote the module to a different location, they
> should start a thread on the dev ML. If there are no objections, it is
> accepted. If there are objections, a vote will be held (Simple
> Majority vote).
>
> * These criteria do not apply to the creation of modules that are not
> new features (e.g., refactoring modules).
>
> Regards,
> Toshiya
>
> On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > Subhanshu,
> >
> > Thank you for the contribution, it's great idea. I'll take some time to
> > review soon.
> >
> > Now I'm sorry to hijack the thread….
> >
> > Toshiya-san,
> >
> > The idea to have contrib/experimental makes total sense, but it misses
> > criteria. Lots of features have been added by new contributors without such
> > experimental or contrib labels.
> >
> > I'm absolutely in favor of exploring this idea, but we need to define a
> > fair criteria for when a thing is flagged as contrib/experimental and
> > what's the criteria to promote it out of that status.
> >
> > Otherwise we risk creating inconsistency in how we treat contributions,
> > especially since we've accepted feature additions at the top level in the
> > recent past.
> >
> > What do you think would be reasonable criteria to establish?
> >
> > -
> > Alex
> >
> > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > toshiyakobayashi@gmail.com> wrote:
> >
> > > 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
> > > <ft...@redhat.com> 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 < subhanshu.bansal5566@
> > > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > > commands, e-mail: dev-help@kie.apache.org
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Toshiya Kobayashi <to...@gmail.com>.
Thank you, Gabriele.
Your points make sense to me. I'm good with the "drools-experimental"
repo and your guidelines.
Does anyone have any thoughts on this?
Toshiya
On Fri, Mar 6, 2026 at 1:49 AM Gabriele Cardosi
<ga...@gmail.com> wrote:
>
> Thanks for the explanation, Francisco!
> Cheers!
>
> On Thu, Mar 5, 2026 at 5:12 PM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > Hi Gabriele,
> > +1 on the contribution repo.
> > Regarding opentelemetry version, one of the first things I did when reading
> > the proposal was to verify that the dependency version depends on quarkus
> > version. Rule engine should use that one. For me the key thing is that
> > OpenTelemetry is attached to a particular engine. The task essentially
> > consists of implementing a listener and using the OpenTelemetry API to
> > "describe" what the engine is doing. So, the implementation depends on
> > internal engine details, it cannot be a Kogito global thing, but a per
> > engine one (of course the dependency version used should be the same
> > across the whole kogito ecosystem)
> >
> > On Thu, Mar 5, 2026 at 4:47 PM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Hi Francisco,
> > > thanks for your question!
> > > To be honest, I personally have not any strong opinion on that
> > > OpenTelemetry feature itself.
> > > The only thing I would like to double check (as soon as I can) is how it
> > > interact with the OpenTelemetry usage inside sonataflow (e.g. are the
> > same
> > > versions ?) and how it can fit in the global schema, i.e.: could it be
> > used
> > > inside kogito applications ? If not, how to make it available there ?
> > And,
> > > in case, what would be the consequence of having such a feature available
> > > in both quarkus and springboot environments ?
> > > I hope this makes sense.
> > >
> > >
> > >
> > > I took the chance of this proposal to (try to) finally address the
> > > underlying issue we have in general terms for this kind of situation
> > (IMO).
> > > I perfectly agree that, eventually, we should define a clear "promotion"
> > > process.
> > >
> > > Side-note: if, ever, we agree on that experimental repo, I would be glad
> > to
> > > adapt the GH scripts.
> > >
> > > Best!
> > >
> > > Gabriele
> > >
> > > On Thu, Mar 5, 2026 at 12:22 PM Francisco Javier Tirado Sarti <
> > > ftirados@redhat.com> wrote:
> > >
> > > > Hi Gabriele,
> > > > Just my 2 cents, because Im not a Drools contributor, and my opinion
> > > should
> > > > not prevent any decision that you guys consider proper.
> > > > In general I agree that having another repository for "experimental"
> > > stuff
> > > > is a good idea. My doubt is whether "open-telemetry" should be
> > > experimental
> > > > or a "regular" add-on to the engine. Perhaps a process for "promotion"
> > > > should be defined. And as a part of that process, a specific add-on can
> > > be
> > > > promoted directly to the "main" repository.
> > > > I have to admit Im "biased" on favour of open-telemetry, which is
> > > becoming
> > > > a very useful tool for audit purposes (till the point that, for many
> > > users,
> > > > might become a replacement to data-index)
> > > >
> > > > On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Toshiya,
> > > > > my idea would be that
> > > > > 1. the "drools-experimental" repo would be built as the other
> > > > "downstream"
> > > > > repos
> > > > > 2. PRs on "main" should not be considered "broken" if only the
> > > > > drools-experimental repo fails to build (maybe just a warning ?)
> > > > > 3. merging PRs in such "drools-experimental" should be very "easy" -
> > > just
> > > > > check that there is not bad or malicious code, and then let the
> > > > > community "decide" if the feature is used/useful or not (*)
> > > > > 4. until the experimental feature is in the drools-experimental repo,
> > > the
> > > > > proposer of such feature should also be responsible for maintaining
> > it
> > > > (*)
> > > > > 5. artifacts built from the drools-experimental should be released to
> > > > maven
> > > > > repo to be publicly available, maybe with some conventional name to
> > > > > indicate they are experimental (and, as such, absolutely no guarantee
> > > in
> > > > > any long term support)
> > > > >
> > > > > (*)
> > > > > I'm aware that behind those very simple statements there could be a
> > lot
> > > > of
> > > > > nuances and disagreement.
> > > > >
> > > > >
> > > > > ////
> > > > > To recap, what I'm driving at is:
> > > > > 1. simplify and encourage contributors to propose features we may not
> > > > even
> > > > > think about
> > > > > 2. avoid our own "bias" to influence the publication of such new
> > > features
> > > > > 3. enforce a sense of "belonging" to the community from the
> > proposers,
> > > > > making them responsible of what they propose until the feature
> > finally
> > > is
> > > > > promoted to main
> > > > > 4. avoid to increase the burden of maintenance of code that, in the
> > > short
> > > > > to long term, may prove to be unused or "dead"
> > > > >
> > > > > I hope to have answered your questions and that all of that makes
> > > sense.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Gabriele
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <
> > > > > toshiyakobayashi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Gabriele,
> > > > > >
> > > > > > Assuming "drools-experimental" repo is created, I think your point
> > is
> > > > > > its maintenance policy and CD/CI policy. Could you share your
> > > thoughts
> > > > > > on this? (e.g., Should the artifacts be released to maven repo?
> > > Should
> > > > > > "drools-experimental" repo CI be executed as downstream CI of
> > > "drools"
> > > > > > PR?)
> > > > > >
> > > > > > Thanks!
> > > > > > Toshiya
> > > > > >
> > > > > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> > > > > > <ga...@gmail.com> wrote:
> > > > > > >
> > > > > > > Alex, TOshiya, from my POV the idea of "experimental folder"
> > > > introduce
> > > > > a
> > > > > > > logical and practical inconsistence, with downfall issues:
> > > > > > > 1. from logical POV, it would mean that there would be "stable"
> > > > (mean -
> > > > > > > production ready) modules and code mixed with "unstable" (mean
> > > > > > > experimental) code experimental
> > > > > > > 2. there would be no way to avoid the latter impacting the
> > former,
> > > > > > whatever
> > > > > > > problem may arise (dependency clashes, CVE, bugs)
> > > > > > > 3. at ci level, the only way to differentiate a "stable" build
> > with
> > > > the
> > > > > > > experimental one would be to create/duplicate CI scripts so that,
> > > > e.g.
> > > > > > > there would be a PR build that excludes the experimental module
> > and
> > > > > > another
> > > > > > > one that include them (or, some similar "hack") that, again,
> > would
> > > be
> > > > > > much
> > > > > > > more cumbersome to maintain
> > > > > > >
> > > > > > > There is no "easy" solution, IMO, but the constant look for "easy
> > > > > > solution"
> > > > > > > always leads to "workarounds" that, soon after being implemented,
> > > > > proved
> > > > > > to
> > > > > > > be problematic to maintain.
> > > > > > > Complex problems require complex solutions to be properly
> > addressed
> > > > > and,
> > > > > > > sorry, but the idea of an "experimental folder" mixed in the very
> > > > same
> > > > > > > "production-ready" code seems very naive to me.
> > > > > > >
> > > > > > > Cheers
> > > > > > >
> > > > > > > Gabriele
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <
> > porcelli@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > The problem of your suggestion Gabriele is the CI complexity it
> > > > > > introduces,
> > > > > > > > being experimental or whatever.. I'd argue once accepted it
> > > should
> > > > be
> > > > > > > > released.. and this also require being part of release
> > > automation.
> > > > > > > >
> > > > > > > > We are already struggling with current complexity in place -
> > see
> > > > the
> > > > > > email
> > > > > > > > I sent early today about 10.2.0 release that I'm sure Kennedy
> > is
> > > > > > fighting
> > > > > > > > hard.
> > > > > > > >
> > > > > > > > +1 for the experimental folder, I think Toshyia provided a very
> > > > good
> > > > > > > > initial framework we can start with.. and probably in a point
> > in
> > > > time
> > > > > > we
> > > > > > > > may want to refine it.
> > > > > > > >
> > > > > > > > Subhanshu, in the meantime while we discuss these topics in
> > > > > parallel, I
> > > > > > > > submitted a PR review… so please continue refining it.. don't
> > get
> > > > > this
> > > > > > > > helpful and healthy discussion distract you from your
> > > contribution.
> > > > > > Thank
> > > > > > > > you again!
> > > > > > > >
> > > > > > > > -
> > > > > > > > Alex
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > > one of the critical aspects with introducing new features,
> > IMO,
> > > > it
> > > > > > is to
> > > > > > > > > avoid that "main" branches ends up containing unused code (we
> > > > > already
> > > > > > > > have
> > > > > > > > > a certain amount of that) that, anyway, we have to maintain,
> > in
> > > > > > terms of
> > > > > > > > > security, library compatibility, etc.; basically, it will
> > also
> > > > > > impact the
> > > > > > > > > CI build, with all consequent issues (see: clashing libraries
> > > > > > versions,
> > > > > > > > > framework upgrade hassle, etc).
> > > > > > > > > Creating a specific directory inside the main branch does not
> > > > solve
> > > > > > any
> > > > > > > > of
> > > > > > > > > such problems (the name of a directory is just a human
> > > > convention).
> > > > > > In
> > > > > > > > the
> > > > > > > > > past I also remember the usage of "experimental" flags but,
> > > > again,
> > > > > > this
> > > > > > > > > won't solve the above.
> > > > > > > > > So, I would like to propose two different approaches, to both
> > > > > > simplify
> > > > > > > > the
> > > > > > > > > introduction of new features from any contributor, on one
> > side,
> > > > and
> > > > > > keep
> > > > > > > > > integrity of our build, on the other side:
> > > > > > > > > 1. a specific branch
> > > > > > > > > 2. a specific repo
> > > > > > > > >
> > > > > > > > > I've not a strong opinion about any of the two. Anyway, with
> > > > either
> > > > > > of
> > > > > > > > > those in place, maybe we would already have, in community,
> > some
> > > > > code
> > > > > > > > that,
> > > > > > > > > in the past, has been pushed back due to lack of clear
> > > > > understanding
> > > > > > and
> > > > > > > > > other uncertainty.
> > > > > > > > > And, again with that in place, that Opentelemetry feature
> > would
> > > > be
> > > > > > easily
> > > > > > > > > included in our domain.
> > > > > > > > > (side-note: this is exactly the approach that has been
> > followed
> > > > by
> > > > > > me, in
> > > > > > > > > the past, after internal discussion with the so-called
> > "drools"
> > > > > > team).
> > > > > > > > >
> > > > > > > > > M2C
> > > > > > > > >
> > > > > > > > > Cheers
> > > > > > > > >
> > > > > > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> > > > > > <toshiyakobayashi@gmail.
> > > > > > > > > com> wrote:
> > > > > > > > >
> > > > > > > > > Also, having a `contrib/experimental` area can help reduce
> > > > > > maintenance
> > > > > > > > > costs. For example, it could include disclaimers such as:
> > > > > > > > >
> > > > > > > > > - Experimental APIs may change in future releases.
> > > > > > > > > - Experimental features may be removed in future releases.
> > > > > > > > > - Experimental features must not block a release. For
> > example,
> > > if
> > > > > an
> > > > > > > > issue
> > > > > > > > > is found in an experimental feature during the release
> > process,
> > > > we
> > > > > > may
> > > > > > > > > choose to disable that feature for the current release.
> > > > > > > > >
> > > > > > > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > > > > > > >
> > > > > > > > > Toshiya
> > > > > > > > >
> > > > > > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > > > > > > <to...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Thank you for moving this topic forward, Alex.
> > > > > > > > >
> > > > > > > > > I agree that criteria are required.
> > > > > > > > >
> > > > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > > > >
> > > > > > > > > Here is a quick draft. Opinions are welcome:
> > > > > > > > >
> > > > > > > > > (Creation)
> > > > > > > > > - A new feature module should default to contrib/experimental
> > > > (not
> > > > > > > > limited
> > > > > > > > > to new contributors).
> > > > > > > > > - If a developer wants to place the module elsewhere from the
> > > > > > beginning,
> > > > > > > > > they should start a thread on the dev mailing list (dev ML).
> > If
> > > > > > there are
> > > > > > > > > no objections, it is accepted. If there are objections, a
> > vote
> > > > will
> > > > > > be
> > > > > > > > held
> > > > > > > > > (Simple Majority vote:
> > > > https://www.apache.org/foundation/glossary.
> > > > > > > > > html#SimpleMajority).
> > > > > > > > >
> > > > > > > > > (Promotion)
> > > > > > > > > - If anyone wants to promote the module to a different
> > > location,
> > > > > they
> > > > > > > > > should start a thread on the dev ML. If there are no
> > > objections,
> > > > it
> > > > > > is
> > > > > > > > > accepted. If there are objections, a vote will be held
> > (Simple
> > > > > > Majority
> > > > > > > > > vote).
> > > > > > > > >
> > > > > > > > > * These criteria do not apply to the creation of modules that
> > > are
> > > > > > not new
> > > > > > > > > features (e.g., refactoring modules).
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Toshiya
> > > > > > > > >
> > > > > > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <
> > > alex@porcelli.me>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Subhanshu,
> > > > > > > > >
> > > > > > > > > Thank you for the contribution, it's great idea. I'll take
> > some
> > > > > time
> > > > > > to
> > > > > > > > > review soon.
> > > > > > > > >
> > > > > > > > > Now I'm sorry to hijack the thread….
> > > > > > > > >
> > > > > > > > > Toshiya-san,
> > > > > > > > >
> > > > > > > > > The idea to have contrib/experimental makes total sense, but
> > it
> > > > > > misses
> > > > > > > > > criteria. Lots of features have been added by new
> > contributors
> > > > > > without
> > > > > > > > >
> > > > > > > > > such
> > > > > > > > >
> > > > > > > > > experimental or contrib labels.
> > > > > > > > >
> > > > > > > > > I'm absolutely in favor of exploring this idea, but we need
> > to
> > > > > > define a
> > > > > > > > > fair criteria for when a thing is flagged as
> > > contrib/experimental
> > > > > and
> > > > > > > > > what's the criteria to promote it out of that status.
> > > > > > > > >
> > > > > > > > > Otherwise we risk creating inconsistency in how we treat
> > > > > > contributions,
> > > > > > > > > especially since we've accepted feature additions at the top
> > > > level
> > > > > in
> > > > > > > > >
> > > > > > > > > the
> > > > > > > > >
> > > > > > > > > recent past.
> > > > > > > > >
> > > > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > Alex
> > > > > > > > >
> > > > > > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > > > > > toshiyakobayashi@
> > > > > > > > > gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > > <ft...@redhat.com> 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 <
> > > > > > > > >
> > > > > > > > > subhanshu.bansal5566@
> > > > > > > > >
> > > > > > > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For
> > > > additional
> > > > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > To
> > > > > > > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For
> > > > additional
> > > > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Gabriele Cardosi <ga...@gmail.com>.
Thanks for the explanation, Francisco!
Cheers!
On Thu, Mar 5, 2026 at 5:12 PM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Hi Gabriele,
> +1 on the contribution repo.
> Regarding opentelemetry version, one of the first things I did when reading
> the proposal was to verify that the dependency version depends on quarkus
> version. Rule engine should use that one. For me the key thing is that
> OpenTelemetry is attached to a particular engine. The task essentially
> consists of implementing a listener and using the OpenTelemetry API to
> "describe" what the engine is doing. So, the implementation depends on
> internal engine details, it cannot be a Kogito global thing, but a per
> engine one (of course the dependency version used should be the same
> across the whole kogito ecosystem)
>
> On Thu, Mar 5, 2026 at 4:47 PM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > Hi Francisco,
> > thanks for your question!
> > To be honest, I personally have not any strong opinion on that
> > OpenTelemetry feature itself.
> > The only thing I would like to double check (as soon as I can) is how it
> > interact with the OpenTelemetry usage inside sonataflow (e.g. are the
> same
> > versions ?) and how it can fit in the global schema, i.e.: could it be
> used
> > inside kogito applications ? If not, how to make it available there ?
> And,
> > in case, what would be the consequence of having such a feature available
> > in both quarkus and springboot environments ?
> > I hope this makes sense.
> >
> >
> >
> > I took the chance of this proposal to (try to) finally address the
> > underlying issue we have in general terms for this kind of situation
> (IMO).
> > I perfectly agree that, eventually, we should define a clear "promotion"
> > process.
> >
> > Side-note: if, ever, we agree on that experimental repo, I would be glad
> to
> > adapt the GH scripts.
> >
> > Best!
> >
> > Gabriele
> >
> > On Thu, Mar 5, 2026 at 12:22 PM Francisco Javier Tirado Sarti <
> > ftirados@redhat.com> wrote:
> >
> > > Hi Gabriele,
> > > Just my 2 cents, because Im not a Drools contributor, and my opinion
> > should
> > > not prevent any decision that you guys consider proper.
> > > In general I agree that having another repository for "experimental"
> > stuff
> > > is a good idea. My doubt is whether "open-telemetry" should be
> > experimental
> > > or a "regular" add-on to the engine. Perhaps a process for "promotion"
> > > should be defined. And as a part of that process, a specific add-on can
> > be
> > > promoted directly to the "main" repository.
> > > I have to admit Im "biased" on favour of open-telemetry, which is
> > becoming
> > > a very useful tool for audit purposes (till the point that, for many
> > users,
> > > might become a replacement to data-index)
> > >
> > > On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > Hi Toshiya,
> > > > my idea would be that
> > > > 1. the "drools-experimental" repo would be built as the other
> > > "downstream"
> > > > repos
> > > > 2. PRs on "main" should not be considered "broken" if only the
> > > > drools-experimental repo fails to build (maybe just a warning ?)
> > > > 3. merging PRs in such "drools-experimental" should be very "easy" -
> > just
> > > > check that there is not bad or malicious code, and then let the
> > > > community "decide" if the feature is used/useful or not (*)
> > > > 4. until the experimental feature is in the drools-experimental repo,
> > the
> > > > proposer of such feature should also be responsible for maintaining
> it
> > > (*)
> > > > 5. artifacts built from the drools-experimental should be released to
> > > maven
> > > > repo to be publicly available, maybe with some conventional name to
> > > > indicate they are experimental (and, as such, absolutely no guarantee
> > in
> > > > any long term support)
> > > >
> > > > (*)
> > > > I'm aware that behind those very simple statements there could be a
> lot
> > > of
> > > > nuances and disagreement.
> > > >
> > > >
> > > > ////
> > > > To recap, what I'm driving at is:
> > > > 1. simplify and encourage contributors to propose features we may not
> > > even
> > > > think about
> > > > 2. avoid our own "bias" to influence the publication of such new
> > features
> > > > 3. enforce a sense of "belonging" to the community from the
> proposers,
> > > > making them responsible of what they propose until the feature
> finally
> > is
> > > > promoted to main
> > > > 4. avoid to increase the burden of maintenance of code that, in the
> > short
> > > > to long term, may prove to be unused or "dead"
> > > >
> > > > I hope to have answered your questions and that all of that makes
> > sense.
> > > >
> > > > Cheers
> > > >
> > > > Gabriele
> > > >
> > > >
> > > >
> > > > On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <
> > > > toshiyakobayashi@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Gabriele,
> > > > >
> > > > > Assuming "drools-experimental" repo is created, I think your point
> is
> > > > > its maintenance policy and CD/CI policy. Could you share your
> > thoughts
> > > > > on this? (e.g., Should the artifacts be released to maven repo?
> > Should
> > > > > "drools-experimental" repo CI be executed as downstream CI of
> > "drools"
> > > > > PR?)
> > > > >
> > > > > Thanks!
> > > > > Toshiya
> > > > >
> > > > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> > > > > <ga...@gmail.com> wrote:
> > > > > >
> > > > > > Alex, TOshiya, from my POV the idea of "experimental folder"
> > > introduce
> > > > a
> > > > > > logical and practical inconsistence, with downfall issues:
> > > > > > 1. from logical POV, it would mean that there would be "stable"
> > > (mean -
> > > > > > production ready) modules and code mixed with "unstable" (mean
> > > > > > experimental) code experimental
> > > > > > 2. there would be no way to avoid the latter impacting the
> former,
> > > > > whatever
> > > > > > problem may arise (dependency clashes, CVE, bugs)
> > > > > > 3. at ci level, the only way to differentiate a "stable" build
> with
> > > the
> > > > > > experimental one would be to create/duplicate CI scripts so that,
> > > e.g.
> > > > > > there would be a PR build that excludes the experimental module
> and
> > > > > another
> > > > > > one that include them (or, some similar "hack") that, again,
> would
> > be
> > > > > much
> > > > > > more cumbersome to maintain
> > > > > >
> > > > > > There is no "easy" solution, IMO, but the constant look for "easy
> > > > > solution"
> > > > > > always leads to "workarounds" that, soon after being implemented,
> > > > proved
> > > > > to
> > > > > > be problematic to maintain.
> > > > > > Complex problems require complex solutions to be properly
> addressed
> > > > and,
> > > > > > sorry, but the idea of an "experimental folder" mixed in the very
> > > same
> > > > > > "production-ready" code seems very naive to me.
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > Gabriele
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <
> porcelli@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > The problem of your suggestion Gabriele is the CI complexity it
> > > > > introduces,
> > > > > > > being experimental or whatever.. I'd argue once accepted it
> > should
> > > be
> > > > > > > released.. and this also require being part of release
> > automation.
> > > > > > >
> > > > > > > We are already struggling with current complexity in place -
> see
> > > the
> > > > > email
> > > > > > > I sent early today about 10.2.0 release that I'm sure Kennedy
> is
> > > > > fighting
> > > > > > > hard.
> > > > > > >
> > > > > > > +1 for the experimental folder, I think Toshyia provided a very
> > > good
> > > > > > > initial framework we can start with.. and probably in a point
> in
> > > time
> > > > > we
> > > > > > > may want to refine it.
> > > > > > >
> > > > > > > Subhanshu, in the meantime while we discuss these topics in
> > > > parallel, I
> > > > > > > submitted a PR review… so please continue refining it.. don't
> get
> > > > this
> > > > > > > helpful and healthy discussion distract you from your
> > contribution.
> > > > > Thank
> > > > > > > you again!
> > > > > > >
> > > > > > > -
> > > > > > > Alex
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > > one of the critical aspects with introducing new features,
> IMO,
> > > it
> > > > > is to
> > > > > > > > avoid that "main" branches ends up containing unused code (we
> > > > already
> > > > > > > have
> > > > > > > > a certain amount of that) that, anyway, we have to maintain,
> in
> > > > > terms of
> > > > > > > > security, library compatibility, etc.; basically, it will
> also
> > > > > impact the
> > > > > > > > CI build, with all consequent issues (see: clashing libraries
> > > > > versions,
> > > > > > > > framework upgrade hassle, etc).
> > > > > > > > Creating a specific directory inside the main branch does not
> > > solve
> > > > > any
> > > > > > > of
> > > > > > > > such problems (the name of a directory is just a human
> > > convention).
> > > > > In
> > > > > > > the
> > > > > > > > past I also remember the usage of "experimental" flags but,
> > > again,
> > > > > this
> > > > > > > > won't solve the above.
> > > > > > > > So, I would like to propose two different approaches, to both
> > > > > simplify
> > > > > > > the
> > > > > > > > introduction of new features from any contributor, on one
> side,
> > > and
> > > > > keep
> > > > > > > > integrity of our build, on the other side:
> > > > > > > > 1. a specific branch
> > > > > > > > 2. a specific repo
> > > > > > > >
> > > > > > > > I've not a strong opinion about any of the two. Anyway, with
> > > either
> > > > > of
> > > > > > > > those in place, maybe we would already have, in community,
> some
> > > > code
> > > > > > > that,
> > > > > > > > in the past, has been pushed back due to lack of clear
> > > > understanding
> > > > > and
> > > > > > > > other uncertainty.
> > > > > > > > And, again with that in place, that Opentelemetry feature
> would
> > > be
> > > > > easily
> > > > > > > > included in our domain.
> > > > > > > > (side-note: this is exactly the approach that has been
> followed
> > > by
> > > > > me, in
> > > > > > > > the past, after internal discussion with the so-called
> "drools"
> > > > > team).
> > > > > > > >
> > > > > > > > M2C
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > >
> > > > > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> > > > > <toshiyakobayashi@gmail.
> > > > > > > > com> wrote:
> > > > > > > >
> > > > > > > > Also, having a `contrib/experimental` area can help reduce
> > > > > maintenance
> > > > > > > > costs. For example, it could include disclaimers such as:
> > > > > > > >
> > > > > > > > - Experimental APIs may change in future releases.
> > > > > > > > - Experimental features may be removed in future releases.
> > > > > > > > - Experimental features must not block a release. For
> example,
> > if
> > > > an
> > > > > > > issue
> > > > > > > > is found in an experimental feature during the release
> process,
> > > we
> > > > > may
> > > > > > > > choose to disable that feature for the current release.
> > > > > > > >
> > > > > > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > > > > > >
> > > > > > > > Toshiya
> > > > > > > >
> > > > > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > > > > > <to...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Thank you for moving this topic forward, Alex.
> > > > > > > >
> > > > > > > > I agree that criteria are required.
> > > > > > > >
> > > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > > >
> > > > > > > > Here is a quick draft. Opinions are welcome:
> > > > > > > >
> > > > > > > > (Creation)
> > > > > > > > - A new feature module should default to contrib/experimental
> > > (not
> > > > > > > limited
> > > > > > > > to new contributors).
> > > > > > > > - If a developer wants to place the module elsewhere from the
> > > > > beginning,
> > > > > > > > they should start a thread on the dev mailing list (dev ML).
> If
> > > > > there are
> > > > > > > > no objections, it is accepted. If there are objections, a
> vote
> > > will
> > > > > be
> > > > > > > held
> > > > > > > > (Simple Majority vote:
> > > https://www.apache.org/foundation/glossary.
> > > > > > > > html#SimpleMajority).
> > > > > > > >
> > > > > > > > (Promotion)
> > > > > > > > - If anyone wants to promote the module to a different
> > location,
> > > > they
> > > > > > > > should start a thread on the dev ML. If there are no
> > objections,
> > > it
> > > > > is
> > > > > > > > accepted. If there are objections, a vote will be held
> (Simple
> > > > > Majority
> > > > > > > > vote).
> > > > > > > >
> > > > > > > > * These criteria do not apply to the creation of modules that
> > are
> > > > > not new
> > > > > > > > features (e.g., refactoring modules).
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Toshiya
> > > > > > > >
> > > > > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <
> > alex@porcelli.me>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Subhanshu,
> > > > > > > >
> > > > > > > > Thank you for the contribution, it's great idea. I'll take
> some
> > > > time
> > > > > to
> > > > > > > > review soon.
> > > > > > > >
> > > > > > > > Now I'm sorry to hijack the thread….
> > > > > > > >
> > > > > > > > Toshiya-san,
> > > > > > > >
> > > > > > > > The idea to have contrib/experimental makes total sense, but
> it
> > > > > misses
> > > > > > > > criteria. Lots of features have been added by new
> contributors
> > > > > without
> > > > > > > >
> > > > > > > > such
> > > > > > > >
> > > > > > > > experimental or contrib labels.
> > > > > > > >
> > > > > > > > I'm absolutely in favor of exploring this idea, but we need
> to
> > > > > define a
> > > > > > > > fair criteria for when a thing is flagged as
> > contrib/experimental
> > > > and
> > > > > > > > what's the criteria to promote it out of that status.
> > > > > > > >
> > > > > > > > Otherwise we risk creating inconsistency in how we treat
> > > > > contributions,
> > > > > > > > especially since we've accepted feature additions at the top
> > > level
> > > > in
> > > > > > > >
> > > > > > > > the
> > > > > > > >
> > > > > > > > recent past.
> > > > > > > >
> > > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > > >
> > > > > > > > -
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > > > > toshiyakobayashi@
> > > > > > > > gmail.com> wrote:
> > > > > > > >
> > > > > > > > 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
> > > > > > > > <ft...@redhat.com> 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 <
> > > > > > > >
> > > > > > > > subhanshu.bansal5566@
> > > > > > > >
> > > > > > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For
> > > additional
> > > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > To
> > > > > > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For
> > > additional
> > > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Hi Gabriele,
+1 on the contribution repo.
Regarding opentelemetry version, one of the first things I did when reading
the proposal was to verify that the dependency version depends on quarkus
version. Rule engine should use that one. For me the key thing is that
OpenTelemetry is attached to a particular engine. The task essentially
consists of implementing a listener and using the OpenTelemetry API to
"describe" what the engine is doing. So, the implementation depends on
internal engine details, it cannot be a Kogito global thing, but a per
engine one (of course the dependency version used should be the same
across the whole kogito ecosystem)
On Thu, Mar 5, 2026 at 4:47 PM Gabriele Cardosi <ga...@gmail.com>
wrote:
> Hi Francisco,
> thanks for your question!
> To be honest, I personally have not any strong opinion on that
> OpenTelemetry feature itself.
> The only thing I would like to double check (as soon as I can) is how it
> interact with the OpenTelemetry usage inside sonataflow (e.g. are the same
> versions ?) and how it can fit in the global schema, i.e.: could it be used
> inside kogito applications ? If not, how to make it available there ? And,
> in case, what would be the consequence of having such a feature available
> in both quarkus and springboot environments ?
> I hope this makes sense.
>
>
>
> I took the chance of this proposal to (try to) finally address the
> underlying issue we have in general terms for this kind of situation (IMO).
> I perfectly agree that, eventually, we should define a clear "promotion"
> process.
>
> Side-note: if, ever, we agree on that experimental repo, I would be glad to
> adapt the GH scripts.
>
> Best!
>
> Gabriele
>
> On Thu, Mar 5, 2026 at 12:22 PM Francisco Javier Tirado Sarti <
> ftirados@redhat.com> wrote:
>
> > Hi Gabriele,
> > Just my 2 cents, because Im not a Drools contributor, and my opinion
> should
> > not prevent any decision that you guys consider proper.
> > In general I agree that having another repository for "experimental"
> stuff
> > is a good idea. My doubt is whether "open-telemetry" should be
> experimental
> > or a "regular" add-on to the engine. Perhaps a process for "promotion"
> > should be defined. And as a part of that process, a specific add-on can
> be
> > promoted directly to the "main" repository.
> > I have to admit Im "biased" on favour of open-telemetry, which is
> becoming
> > a very useful tool for audit purposes (till the point that, for many
> users,
> > might become a replacement to data-index)
> >
> > On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > Hi Toshiya,
> > > my idea would be that
> > > 1. the "drools-experimental" repo would be built as the other
> > "downstream"
> > > repos
> > > 2. PRs on "main" should not be considered "broken" if only the
> > > drools-experimental repo fails to build (maybe just a warning ?)
> > > 3. merging PRs in such "drools-experimental" should be very "easy" -
> just
> > > check that there is not bad or malicious code, and then let the
> > > community "decide" if the feature is used/useful or not (*)
> > > 4. until the experimental feature is in the drools-experimental repo,
> the
> > > proposer of such feature should also be responsible for maintaining it
> > (*)
> > > 5. artifacts built from the drools-experimental should be released to
> > maven
> > > repo to be publicly available, maybe with some conventional name to
> > > indicate they are experimental (and, as such, absolutely no guarantee
> in
> > > any long term support)
> > >
> > > (*)
> > > I'm aware that behind those very simple statements there could be a lot
> > of
> > > nuances and disagreement.
> > >
> > >
> > > ////
> > > To recap, what I'm driving at is:
> > > 1. simplify and encourage contributors to propose features we may not
> > even
> > > think about
> > > 2. avoid our own "bias" to influence the publication of such new
> features
> > > 3. enforce a sense of "belonging" to the community from the proposers,
> > > making them responsible of what they propose until the feature finally
> is
> > > promoted to main
> > > 4. avoid to increase the burden of maintenance of code that, in the
> short
> > > to long term, may prove to be unused or "dead"
> > >
> > > I hope to have answered your questions and that all of that makes
> sense.
> > >
> > > Cheers
> > >
> > > Gabriele
> > >
> > >
> > >
> > > On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <
> > > toshiyakobayashi@gmail.com>
> > > wrote:
> > >
> > > > Hi Gabriele,
> > > >
> > > > Assuming "drools-experimental" repo is created, I think your point is
> > > > its maintenance policy and CD/CI policy. Could you share your
> thoughts
> > > > on this? (e.g., Should the artifacts be released to maven repo?
> Should
> > > > "drools-experimental" repo CI be executed as downstream CI of
> "drools"
> > > > PR?)
> > > >
> > > > Thanks!
> > > > Toshiya
> > > >
> > > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> > > > <ga...@gmail.com> wrote:
> > > > >
> > > > > Alex, TOshiya, from my POV the idea of "experimental folder"
> > introduce
> > > a
> > > > > logical and practical inconsistence, with downfall issues:
> > > > > 1. from logical POV, it would mean that there would be "stable"
> > (mean -
> > > > > production ready) modules and code mixed with "unstable" (mean
> > > > > experimental) code experimental
> > > > > 2. there would be no way to avoid the latter impacting the former,
> > > > whatever
> > > > > problem may arise (dependency clashes, CVE, bugs)
> > > > > 3. at ci level, the only way to differentiate a "stable" build with
> > the
> > > > > experimental one would be to create/duplicate CI scripts so that,
> > e.g.
> > > > > there would be a PR build that excludes the experimental module and
> > > > another
> > > > > one that include them (or, some similar "hack") that, again, would
> be
> > > > much
> > > > > more cumbersome to maintain
> > > > >
> > > > > There is no "easy" solution, IMO, but the constant look for "easy
> > > > solution"
> > > > > always leads to "workarounds" that, soon after being implemented,
> > > proved
> > > > to
> > > > > be problematic to maintain.
> > > > > Complex problems require complex solutions to be properly addressed
> > > and,
> > > > > sorry, but the idea of an "experimental folder" mixed in the very
> > same
> > > > > "production-ready" code seems very naive to me.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Gabriele
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org>
> > > > wrote:
> > > > >
> > > > > > The problem of your suggestion Gabriele is the CI complexity it
> > > > introduces,
> > > > > > being experimental or whatever.. I'd argue once accepted it
> should
> > be
> > > > > > released.. and this also require being part of release
> automation.
> > > > > >
> > > > > > We are already struggling with current complexity in place - see
> > the
> > > > email
> > > > > > I sent early today about 10.2.0 release that I'm sure Kennedy is
> > > > fighting
> > > > > > hard.
> > > > > >
> > > > > > +1 for the experimental folder, I think Toshyia provided a very
> > good
> > > > > > initial framework we can start with.. and probably in a point in
> > time
> > > > we
> > > > > > may want to refine it.
> > > > > >
> > > > > > Subhanshu, in the meantime while we discuss these topics in
> > > parallel, I
> > > > > > submitted a PR review… so please continue refining it.. don't get
> > > this
> > > > > > helpful and healthy discussion distract you from your
> contribution.
> > > > Thank
> > > > > > you again!
> > > > > >
> > > > > > -
> > > > > > Alex
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > > one of the critical aspects with introducing new features, IMO,
> > it
> > > > is to
> > > > > > > avoid that "main" branches ends up containing unused code (we
> > > already
> > > > > > have
> > > > > > > a certain amount of that) that, anyway, we have to maintain, in
> > > > terms of
> > > > > > > security, library compatibility, etc.; basically, it will also
> > > > impact the
> > > > > > > CI build, with all consequent issues (see: clashing libraries
> > > > versions,
> > > > > > > framework upgrade hassle, etc).
> > > > > > > Creating a specific directory inside the main branch does not
> > solve
> > > > any
> > > > > > of
> > > > > > > such problems (the name of a directory is just a human
> > convention).
> > > > In
> > > > > > the
> > > > > > > past I also remember the usage of "experimental" flags but,
> > again,
> > > > this
> > > > > > > won't solve the above.
> > > > > > > So, I would like to propose two different approaches, to both
> > > > simplify
> > > > > > the
> > > > > > > introduction of new features from any contributor, on one side,
> > and
> > > > keep
> > > > > > > integrity of our build, on the other side:
> > > > > > > 1. a specific branch
> > > > > > > 2. a specific repo
> > > > > > >
> > > > > > > I've not a strong opinion about any of the two. Anyway, with
> > either
> > > > of
> > > > > > > those in place, maybe we would already have, in community, some
> > > code
> > > > > > that,
> > > > > > > in the past, has been pushed back due to lack of clear
> > > understanding
> > > > and
> > > > > > > other uncertainty.
> > > > > > > And, again with that in place, that Opentelemetry feature would
> > be
> > > > easily
> > > > > > > included in our domain.
> > > > > > > (side-note: this is exactly the approach that has been followed
> > by
> > > > me, in
> > > > > > > the past, after internal discussion with the so-called "drools"
> > > > team).
> > > > > > >
> > > > > > > M2C
> > > > > > >
> > > > > > > Cheers
> > > > > > >
> > > > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> > > > <toshiyakobayashi@gmail.
> > > > > > > com> wrote:
> > > > > > >
> > > > > > > Also, having a `contrib/experimental` area can help reduce
> > > > maintenance
> > > > > > > costs. For example, it could include disclaimers such as:
> > > > > > >
> > > > > > > - Experimental APIs may change in future releases.
> > > > > > > - Experimental features may be removed in future releases.
> > > > > > > - Experimental features must not block a release. For example,
> if
> > > an
> > > > > > issue
> > > > > > > is found in an experimental feature during the release process,
> > we
> > > > may
> > > > > > > choose to disable that feature for the current release.
> > > > > > >
> > > > > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > > > > >
> > > > > > > Toshiya
> > > > > > >
> > > > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > > > > <to...@gmail.com> wrote:
> > > > > > >
> > > > > > > Thank you for moving this topic forward, Alex.
> > > > > > >
> > > > > > > I agree that criteria are required.
> > > > > > >
> > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > >
> > > > > > > Here is a quick draft. Opinions are welcome:
> > > > > > >
> > > > > > > (Creation)
> > > > > > > - A new feature module should default to contrib/experimental
> > (not
> > > > > > limited
> > > > > > > to new contributors).
> > > > > > > - If a developer wants to place the module elsewhere from the
> > > > beginning,
> > > > > > > they should start a thread on the dev mailing list (dev ML). If
> > > > there are
> > > > > > > no objections, it is accepted. If there are objections, a vote
> > will
> > > > be
> > > > > > held
> > > > > > > (Simple Majority vote:
> > https://www.apache.org/foundation/glossary.
> > > > > > > html#SimpleMajority).
> > > > > > >
> > > > > > > (Promotion)
> > > > > > > - If anyone wants to promote the module to a different
> location,
> > > they
> > > > > > > should start a thread on the dev ML. If there are no
> objections,
> > it
> > > > is
> > > > > > > accepted. If there are objections, a vote will be held (Simple
> > > > Majority
> > > > > > > vote).
> > > > > > >
> > > > > > > * These criteria do not apply to the creation of modules that
> are
> > > > not new
> > > > > > > features (e.g., refactoring modules).
> > > > > > >
> > > > > > > Regards,
> > > > > > > Toshiya
> > > > > > >
> > > > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <
> alex@porcelli.me>
> > > > wrote:
> > > > > > >
> > > > > > > Subhanshu,
> > > > > > >
> > > > > > > Thank you for the contribution, it's great idea. I'll take some
> > > time
> > > > to
> > > > > > > review soon.
> > > > > > >
> > > > > > > Now I'm sorry to hijack the thread….
> > > > > > >
> > > > > > > Toshiya-san,
> > > > > > >
> > > > > > > The idea to have contrib/experimental makes total sense, but it
> > > > misses
> > > > > > > criteria. Lots of features have been added by new contributors
> > > > without
> > > > > > >
> > > > > > > such
> > > > > > >
> > > > > > > experimental or contrib labels.
> > > > > > >
> > > > > > > I'm absolutely in favor of exploring this idea, but we need to
> > > > define a
> > > > > > > fair criteria for when a thing is flagged as
> contrib/experimental
> > > and
> > > > > > > what's the criteria to promote it out of that status.
> > > > > > >
> > > > > > > Otherwise we risk creating inconsistency in how we treat
> > > > contributions,
> > > > > > > especially since we've accepted feature additions at the top
> > level
> > > in
> > > > > > >
> > > > > > > the
> > > > > > >
> > > > > > > recent past.
> > > > > > >
> > > > > > > What do you think would be reasonable criteria to establish?
> > > > > > >
> > > > > > > -
> > > > > > > Alex
> > > > > > >
> > > > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > > > toshiyakobayashi@
> > > > > > > gmail.com> wrote:
> > > > > > >
> > > > > > > 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
> > > > > > > <ft...@redhat.com> 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 <
> > > > > > >
> > > > > > > subhanshu.bansal5566@
> > > > > > >
> > > > > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For
> > additional
> > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > ---------------------------------------------------------------------
> > To
> > > > > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For
> > additional
> > > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Gabriele Cardosi <ga...@gmail.com>.
Hi Francisco,
thanks for your question!
To be honest, I personally have not any strong opinion on that
OpenTelemetry feature itself.
The only thing I would like to double check (as soon as I can) is how it
interact with the OpenTelemetry usage inside sonataflow (e.g. are the same
versions ?) and how it can fit in the global schema, i.e.: could it be used
inside kogito applications ? If not, how to make it available there ? And,
in case, what would be the consequence of having such a feature available
in both quarkus and springboot environments ?
I hope this makes sense.
I took the chance of this proposal to (try to) finally address the
underlying issue we have in general terms for this kind of situation (IMO).
I perfectly agree that, eventually, we should define a clear "promotion"
process.
Side-note: if, ever, we agree on that experimental repo, I would be glad to
adapt the GH scripts.
Best!
Gabriele
On Thu, Mar 5, 2026 at 12:22 PM Francisco Javier Tirado Sarti <
ftirados@redhat.com> wrote:
> Hi Gabriele,
> Just my 2 cents, because Im not a Drools contributor, and my opinion should
> not prevent any decision that you guys consider proper.
> In general I agree that having another repository for "experimental" stuff
> is a good idea. My doubt is whether "open-telemetry" should be experimental
> or a "regular" add-on to the engine. Perhaps a process for "promotion"
> should be defined. And as a part of that process, a specific add-on can be
> promoted directly to the "main" repository.
> I have to admit Im "biased" on favour of open-telemetry, which is becoming
> a very useful tool for audit purposes (till the point that, for many users,
> might become a replacement to data-index)
>
> On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > Hi Toshiya,
> > my idea would be that
> > 1. the "drools-experimental" repo would be built as the other
> "downstream"
> > repos
> > 2. PRs on "main" should not be considered "broken" if only the
> > drools-experimental repo fails to build (maybe just a warning ?)
> > 3. merging PRs in such "drools-experimental" should be very "easy" - just
> > check that there is not bad or malicious code, and then let the
> > community "decide" if the feature is used/useful or not (*)
> > 4. until the experimental feature is in the drools-experimental repo, the
> > proposer of such feature should also be responsible for maintaining it
> (*)
> > 5. artifacts built from the drools-experimental should be released to
> maven
> > repo to be publicly available, maybe with some conventional name to
> > indicate they are experimental (and, as such, absolutely no guarantee in
> > any long term support)
> >
> > (*)
> > I'm aware that behind those very simple statements there could be a lot
> of
> > nuances and disagreement.
> >
> >
> > ////
> > To recap, what I'm driving at is:
> > 1. simplify and encourage contributors to propose features we may not
> even
> > think about
> > 2. avoid our own "bias" to influence the publication of such new features
> > 3. enforce a sense of "belonging" to the community from the proposers,
> > making them responsible of what they propose until the feature finally is
> > promoted to main
> > 4. avoid to increase the burden of maintenance of code that, in the short
> > to long term, may prove to be unused or "dead"
> >
> > I hope to have answered your questions and that all of that makes sense.
> >
> > Cheers
> >
> > Gabriele
> >
> >
> >
> > On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <
> > toshiyakobayashi@gmail.com>
> > wrote:
> >
> > > Hi Gabriele,
> > >
> > > Assuming "drools-experimental" repo is created, I think your point is
> > > its maintenance policy and CD/CI policy. Could you share your thoughts
> > > on this? (e.g., Should the artifacts be released to maven repo? Should
> > > "drools-experimental" repo CI be executed as downstream CI of "drools"
> > > PR?)
> > >
> > > Thanks!
> > > Toshiya
> > >
> > > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> > > <ga...@gmail.com> wrote:
> > > >
> > > > Alex, TOshiya, from my POV the idea of "experimental folder"
> introduce
> > a
> > > > logical and practical inconsistence, with downfall issues:
> > > > 1. from logical POV, it would mean that there would be "stable"
> (mean -
> > > > production ready) modules and code mixed with "unstable" (mean
> > > > experimental) code experimental
> > > > 2. there would be no way to avoid the latter impacting the former,
> > > whatever
> > > > problem may arise (dependency clashes, CVE, bugs)
> > > > 3. at ci level, the only way to differentiate a "stable" build with
> the
> > > > experimental one would be to create/duplicate CI scripts so that,
> e.g.
> > > > there would be a PR build that excludes the experimental module and
> > > another
> > > > one that include them (or, some similar "hack") that, again, would be
> > > much
> > > > more cumbersome to maintain
> > > >
> > > > There is no "easy" solution, IMO, but the constant look for "easy
> > > solution"
> > > > always leads to "workarounds" that, soon after being implemented,
> > proved
> > > to
> > > > be problematic to maintain.
> > > > Complex problems require complex solutions to be properly addressed
> > and,
> > > > sorry, but the idea of an "experimental folder" mixed in the very
> same
> > > > "production-ready" code seems very naive to me.
> > > >
> > > > Cheers
> > > >
> > > > Gabriele
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org>
> > > wrote:
> > > >
> > > > > The problem of your suggestion Gabriele is the CI complexity it
> > > introduces,
> > > > > being experimental or whatever.. I'd argue once accepted it should
> be
> > > > > released.. and this also require being part of release automation.
> > > > >
> > > > > We are already struggling with current complexity in place - see
> the
> > > email
> > > > > I sent early today about 10.2.0 release that I'm sure Kennedy is
> > > fighting
> > > > > hard.
> > > > >
> > > > > +1 for the experimental folder, I think Toshyia provided a very
> good
> > > > > initial framework we can start with.. and probably in a point in
> time
> > > we
> > > > > may want to refine it.
> > > > >
> > > > > Subhanshu, in the meantime while we discuss these topics in
> > parallel, I
> > > > > submitted a PR review… so please continue refining it.. don't get
> > this
> > > > > helpful and healthy discussion distract you from your contribution.
> > > Thank
> > > > > you again!
> > > > >
> > > > > -
> > > > > Alex
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com> wrote:
> > > > >
> > > > > > Hi all,
> > > > > > one of the critical aspects with introducing new features, IMO,
> it
> > > is to
> > > > > > avoid that "main" branches ends up containing unused code (we
> > already
> > > > > have
> > > > > > a certain amount of that) that, anyway, we have to maintain, in
> > > terms of
> > > > > > security, library compatibility, etc.; basically, it will also
> > > impact the
> > > > > > CI build, with all consequent issues (see: clashing libraries
> > > versions,
> > > > > > framework upgrade hassle, etc).
> > > > > > Creating a specific directory inside the main branch does not
> solve
> > > any
> > > > > of
> > > > > > such problems (the name of a directory is just a human
> convention).
> > > In
> > > > > the
> > > > > > past I also remember the usage of "experimental" flags but,
> again,
> > > this
> > > > > > won't solve the above.
> > > > > > So, I would like to propose two different approaches, to both
> > > simplify
> > > > > the
> > > > > > introduction of new features from any contributor, on one side,
> and
> > > keep
> > > > > > integrity of our build, on the other side:
> > > > > > 1. a specific branch
> > > > > > 2. a specific repo
> > > > > >
> > > > > > I've not a strong opinion about any of the two. Anyway, with
> either
> > > of
> > > > > > those in place, maybe we would already have, in community, some
> > code
> > > > > that,
> > > > > > in the past, has been pushed back due to lack of clear
> > understanding
> > > and
> > > > > > other uncertainty.
> > > > > > And, again with that in place, that Opentelemetry feature would
> be
> > > easily
> > > > > > included in our domain.
> > > > > > (side-note: this is exactly the approach that has been followed
> by
> > > me, in
> > > > > > the past, after internal discussion with the so-called "drools"
> > > team).
> > > > > >
> > > > > > M2C
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> > > <toshiyakobayashi@gmail.
> > > > > > com> wrote:
> > > > > >
> > > > > > Also, having a `contrib/experimental` area can help reduce
> > > maintenance
> > > > > > costs. For example, it could include disclaimers such as:
> > > > > >
> > > > > > - Experimental APIs may change in future releases.
> > > > > > - Experimental features may be removed in future releases.
> > > > > > - Experimental features must not block a release. For example, if
> > an
> > > > > issue
> > > > > > is found in an experimental feature during the release process,
> we
> > > may
> > > > > > choose to disable that feature for the current release.
> > > > > >
> > > > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > > > >
> > > > > > Toshiya
> > > > > >
> > > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > > > <to...@gmail.com> wrote:
> > > > > >
> > > > > > Thank you for moving this topic forward, Alex.
> > > > > >
> > > > > > I agree that criteria are required.
> > > > > >
> > > > > > What do you think would be reasonable criteria to establish?
> > > > > >
> > > > > > Here is a quick draft. Opinions are welcome:
> > > > > >
> > > > > > (Creation)
> > > > > > - A new feature module should default to contrib/experimental
> (not
> > > > > limited
> > > > > > to new contributors).
> > > > > > - If a developer wants to place the module elsewhere from the
> > > beginning,
> > > > > > they should start a thread on the dev mailing list (dev ML). If
> > > there are
> > > > > > no objections, it is accepted. If there are objections, a vote
> will
> > > be
> > > > > held
> > > > > > (Simple Majority vote:
> https://www.apache.org/foundation/glossary.
> > > > > > html#SimpleMajority).
> > > > > >
> > > > > > (Promotion)
> > > > > > - If anyone wants to promote the module to a different location,
> > they
> > > > > > should start a thread on the dev ML. If there are no objections,
> it
> > > is
> > > > > > accepted. If there are objections, a vote will be held (Simple
> > > Majority
> > > > > > vote).
> > > > > >
> > > > > > * These criteria do not apply to the creation of modules that are
> > > not new
> > > > > > features (e.g., refactoring modules).
> > > > > >
> > > > > > Regards,
> > > > > > Toshiya
> > > > > >
> > > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > > >
> > > > > > Subhanshu,
> > > > > >
> > > > > > Thank you for the contribution, it's great idea. I'll take some
> > time
> > > to
> > > > > > review soon.
> > > > > >
> > > > > > Now I'm sorry to hijack the thread….
> > > > > >
> > > > > > Toshiya-san,
> > > > > >
> > > > > > The idea to have contrib/experimental makes total sense, but it
> > > misses
> > > > > > criteria. Lots of features have been added by new contributors
> > > without
> > > > > >
> > > > > > such
> > > > > >
> > > > > > experimental or contrib labels.
> > > > > >
> > > > > > I'm absolutely in favor of exploring this idea, but we need to
> > > define a
> > > > > > fair criteria for when a thing is flagged as contrib/experimental
> > and
> > > > > > what's the criteria to promote it out of that status.
> > > > > >
> > > > > > Otherwise we risk creating inconsistency in how we treat
> > > contributions,
> > > > > > especially since we've accepted feature additions at the top
> level
> > in
> > > > > >
> > > > > > the
> > > > > >
> > > > > > recent past.
> > > > > >
> > > > > > What do you think would be reasonable criteria to establish?
> > > > > >
> > > > > > -
> > > > > > Alex
> > > > > >
> > > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > > toshiyakobayashi@
> > > > > > gmail.com> wrote:
> > > > > >
> > > > > > 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
> > > > > > <ft...@redhat.com> 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 <
> > > > > >
> > > > > > subhanshu.bansal5566@
> > > > > >
> > > > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For
> additional
> > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> To
> > > > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For
> additional
> > > > > > commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
Hi Gabriele,
Just my 2 cents, because Im not a Drools contributor, and my opinion should
not prevent any decision that you guys consider proper.
In general I agree that having another repository for "experimental" stuff
is a good idea. My doubt is whether "open-telemetry" should be experimental
or a "regular" add-on to the engine. Perhaps a process for "promotion"
should be defined. And as a part of that process, a specific add-on can be
promoted directly to the "main" repository.
I have to admit Im "biased" on favour of open-telemetry, which is becoming
a very useful tool for audit purposes (till the point that, for many users,
might become a replacement to data-index)
On Thu, Mar 5, 2026 at 9:28 AM Gabriele Cardosi <ga...@gmail.com>
wrote:
> Hi Toshiya,
> my idea would be that
> 1. the "drools-experimental" repo would be built as the other "downstream"
> repos
> 2. PRs on "main" should not be considered "broken" if only the
> drools-experimental repo fails to build (maybe just a warning ?)
> 3. merging PRs in such "drools-experimental" should be very "easy" - just
> check that there is not bad or malicious code, and then let the
> community "decide" if the feature is used/useful or not (*)
> 4. until the experimental feature is in the drools-experimental repo, the
> proposer of such feature should also be responsible for maintaining it (*)
> 5. artifacts built from the drools-experimental should be released to maven
> repo to be publicly available, maybe with some conventional name to
> indicate they are experimental (and, as such, absolutely no guarantee in
> any long term support)
>
> (*)
> I'm aware that behind those very simple statements there could be a lot of
> nuances and disagreement.
>
>
> ////
> To recap, what I'm driving at is:
> 1. simplify and encourage contributors to propose features we may not even
> think about
> 2. avoid our own "bias" to influence the publication of such new features
> 3. enforce a sense of "belonging" to the community from the proposers,
> making them responsible of what they propose until the feature finally is
> promoted to main
> 4. avoid to increase the burden of maintenance of code that, in the short
> to long term, may prove to be unused or "dead"
>
> I hope to have answered your questions and that all of that makes sense.
>
> Cheers
>
> Gabriele
>
>
>
> On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <
> toshiyakobayashi@gmail.com>
> wrote:
>
> > Hi Gabriele,
> >
> > Assuming "drools-experimental" repo is created, I think your point is
> > its maintenance policy and CD/CI policy. Could you share your thoughts
> > on this? (e.g., Should the artifacts be released to maven repo? Should
> > "drools-experimental" repo CI be executed as downstream CI of "drools"
> > PR?)
> >
> > Thanks!
> > Toshiya
> >
> > On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> > <ga...@gmail.com> wrote:
> > >
> > > Alex, TOshiya, from my POV the idea of "experimental folder" introduce
> a
> > > logical and practical inconsistence, with downfall issues:
> > > 1. from logical POV, it would mean that there would be "stable" (mean -
> > > production ready) modules and code mixed with "unstable" (mean
> > > experimental) code experimental
> > > 2. there would be no way to avoid the latter impacting the former,
> > whatever
> > > problem may arise (dependency clashes, CVE, bugs)
> > > 3. at ci level, the only way to differentiate a "stable" build with the
> > > experimental one would be to create/duplicate CI scripts so that, e.g.
> > > there would be a PR build that excludes the experimental module and
> > another
> > > one that include them (or, some similar "hack") that, again, would be
> > much
> > > more cumbersome to maintain
> > >
> > > There is no "easy" solution, IMO, but the constant look for "easy
> > solution"
> > > always leads to "workarounds" that, soon after being implemented,
> proved
> > to
> > > be problematic to maintain.
> > > Complex problems require complex solutions to be properly addressed
> and,
> > > sorry, but the idea of an "experimental folder" mixed in the very same
> > > "production-ready" code seems very naive to me.
> > >
> > > Cheers
> > >
> > > Gabriele
> > >
> > >
> > >
> > >
> > > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org>
> > wrote:
> > >
> > > > The problem of your suggestion Gabriele is the CI complexity it
> > introduces,
> > > > being experimental or whatever.. I'd argue once accepted it should be
> > > > released.. and this also require being part of release automation.
> > > >
> > > > We are already struggling with current complexity in place - see the
> > email
> > > > I sent early today about 10.2.0 release that I'm sure Kennedy is
> > fighting
> > > > hard.
> > > >
> > > > +1 for the experimental folder, I think Toshyia provided a very good
> > > > initial framework we can start with.. and probably in a point in time
> > we
> > > > may want to refine it.
> > > >
> > > > Subhanshu, in the meantime while we discuss these topics in
> parallel, I
> > > > submitted a PR review… so please continue refining it.. don't get
> this
> > > > helpful and healthy discussion distract you from your contribution.
> > Thank
> > > > you again!
> > > >
> > > > -
> > > > Alex
> > > >
> > > >
> > > >
> > > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com> wrote:
> > > >
> > > > > Hi all,
> > > > > one of the critical aspects with introducing new features, IMO, it
> > is to
> > > > > avoid that "main" branches ends up containing unused code (we
> already
> > > > have
> > > > > a certain amount of that) that, anyway, we have to maintain, in
> > terms of
> > > > > security, library compatibility, etc.; basically, it will also
> > impact the
> > > > > CI build, with all consequent issues (see: clashing libraries
> > versions,
> > > > > framework upgrade hassle, etc).
> > > > > Creating a specific directory inside the main branch does not solve
> > any
> > > > of
> > > > > such problems (the name of a directory is just a human convention).
> > In
> > > > the
> > > > > past I also remember the usage of "experimental" flags but, again,
> > this
> > > > > won't solve the above.
> > > > > So, I would like to propose two different approaches, to both
> > simplify
> > > > the
> > > > > introduction of new features from any contributor, on one side, and
> > keep
> > > > > integrity of our build, on the other side:
> > > > > 1. a specific branch
> > > > > 2. a specific repo
> > > > >
> > > > > I've not a strong opinion about any of the two. Anyway, with either
> > of
> > > > > those in place, maybe we would already have, in community, some
> code
> > > > that,
> > > > > in the past, has been pushed back due to lack of clear
> understanding
> > and
> > > > > other uncertainty.
> > > > > And, again with that in place, that Opentelemetry feature would be
> > easily
> > > > > included in our domain.
> > > > > (side-note: this is exactly the approach that has been followed by
> > me, in
> > > > > the past, after internal discussion with the so-called "drools"
> > team).
> > > > >
> > > > > M2C
> > > > >
> > > > > Cheers
> > > > >
> > > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> > <toshiyakobayashi@gmail.
> > > > > com> wrote:
> > > > >
> > > > > Also, having a `contrib/experimental` area can help reduce
> > maintenance
> > > > > costs. For example, it could include disclaimers such as:
> > > > >
> > > > > - Experimental APIs may change in future releases.
> > > > > - Experimental features may be removed in future releases.
> > > > > - Experimental features must not block a release. For example, if
> an
> > > > issue
> > > > > is found in an experimental feature during the release process, we
> > may
> > > > > choose to disable that feature for the current release.
> > > > >
> > > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > > >
> > > > > Toshiya
> > > > >
> > > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > > <to...@gmail.com> wrote:
> > > > >
> > > > > Thank you for moving this topic forward, Alex.
> > > > >
> > > > > I agree that criteria are required.
> > > > >
> > > > > What do you think would be reasonable criteria to establish?
> > > > >
> > > > > Here is a quick draft. Opinions are welcome:
> > > > >
> > > > > (Creation)
> > > > > - A new feature module should default to contrib/experimental (not
> > > > limited
> > > > > to new contributors).
> > > > > - If a developer wants to place the module elsewhere from the
> > beginning,
> > > > > they should start a thread on the dev mailing list (dev ML). If
> > there are
> > > > > no objections, it is accepted. If there are objections, a vote will
> > be
> > > > held
> > > > > (Simple Majority vote: https://www.apache.org/foundation/glossary.
> > > > > html#SimpleMajority).
> > > > >
> > > > > (Promotion)
> > > > > - If anyone wants to promote the module to a different location,
> they
> > > > > should start a thread on the dev ML. If there are no objections, it
> > is
> > > > > accepted. If there are objections, a vote will be held (Simple
> > Majority
> > > > > vote).
> > > > >
> > > > > * These criteria do not apply to the creation of modules that are
> > not new
> > > > > features (e.g., refactoring modules).
> > > > >
> > > > > Regards,
> > > > > Toshiya
> > > > >
> > > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > > >
> > > > > Subhanshu,
> > > > >
> > > > > Thank you for the contribution, it's great idea. I'll take some
> time
> > to
> > > > > review soon.
> > > > >
> > > > > Now I'm sorry to hijack the thread….
> > > > >
> > > > > Toshiya-san,
> > > > >
> > > > > The idea to have contrib/experimental makes total sense, but it
> > misses
> > > > > criteria. Lots of features have been added by new contributors
> > without
> > > > >
> > > > > such
> > > > >
> > > > > experimental or contrib labels.
> > > > >
> > > > > I'm absolutely in favor of exploring this idea, but we need to
> > define a
> > > > > fair criteria for when a thing is flagged as contrib/experimental
> and
> > > > > what's the criteria to promote it out of that status.
> > > > >
> > > > > Otherwise we risk creating inconsistency in how we treat
> > contributions,
> > > > > especially since we've accepted feature additions at the top level
> in
> > > > >
> > > > > the
> > > > >
> > > > > recent past.
> > > > >
> > > > > What do you think would be reasonable criteria to establish?
> > > > >
> > > > > -
> > > > > Alex
> > > > >
> > > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > toshiyakobayashi@
> > > > > gmail.com> wrote:
> > > > >
> > > > > 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
> > > > > <ft...@redhat.com> 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 <
> > > > >
> > > > > subhanshu.bansal5566@
> > > > >
> > > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > > > > commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > --------------------------------------------------------------------- To
> > > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For additional
> > > > > commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Gabriele Cardosi <ga...@gmail.com>.
Hi Toshiya,
my idea would be that
1. the "drools-experimental" repo would be built as the other "downstream"
repos
2. PRs on "main" should not be considered "broken" if only the
drools-experimental repo fails to build (maybe just a warning ?)
3. merging PRs in such "drools-experimental" should be very "easy" - just
check that there is not bad or malicious code, and then let the
community "decide" if the feature is used/useful or not (*)
4. until the experimental feature is in the drools-experimental repo, the
proposer of such feature should also be responsible for maintaining it (*)
5. artifacts built from the drools-experimental should be released to maven
repo to be publicly available, maybe with some conventional name to
indicate they are experimental (and, as such, absolutely no guarantee in
any long term support)
(*)
I'm aware that behind those very simple statements there could be a lot of
nuances and disagreement.
////
To recap, what I'm driving at is:
1. simplify and encourage contributors to propose features we may not even
think about
2. avoid our own "bias" to influence the publication of such new features
3. enforce a sense of "belonging" to the community from the proposers,
making them responsible of what they propose until the feature finally is
promoted to main
4. avoid to increase the burden of maintenance of code that, in the short
to long term, may prove to be unused or "dead"
I hope to have answered your questions and that all of that makes sense.
Cheers
Gabriele
On Thu, Mar 5, 2026 at 8:44 AM Toshiya Kobayashi <to...@gmail.com>
wrote:
> Hi Gabriele,
>
> Assuming "drools-experimental" repo is created, I think your point is
> its maintenance policy and CD/CI policy. Could you share your thoughts
> on this? (e.g., Should the artifacts be released to maven repo? Should
> "drools-experimental" repo CI be executed as downstream CI of "drools"
> PR?)
>
> Thanks!
> Toshiya
>
> On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
> <ga...@gmail.com> wrote:
> >
> > Alex, TOshiya, from my POV the idea of "experimental folder" introduce a
> > logical and practical inconsistence, with downfall issues:
> > 1. from logical POV, it would mean that there would be "stable" (mean -
> > production ready) modules and code mixed with "unstable" (mean
> > experimental) code experimental
> > 2. there would be no way to avoid the latter impacting the former,
> whatever
> > problem may arise (dependency clashes, CVE, bugs)
> > 3. at ci level, the only way to differentiate a "stable" build with the
> > experimental one would be to create/duplicate CI scripts so that, e.g.
> > there would be a PR build that excludes the experimental module and
> another
> > one that include them (or, some similar "hack") that, again, would be
> much
> > more cumbersome to maintain
> >
> > There is no "easy" solution, IMO, but the constant look for "easy
> solution"
> > always leads to "workarounds" that, soon after being implemented, proved
> to
> > be problematic to maintain.
> > Complex problems require complex solutions to be properly addressed and,
> > sorry, but the idea of an "experimental folder" mixed in the very same
> > "production-ready" code seems very naive to me.
> >
> > Cheers
> >
> > Gabriele
> >
> >
> >
> >
> > On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org>
> wrote:
> >
> > > The problem of your suggestion Gabriele is the CI complexity it
> introduces,
> > > being experimental or whatever.. I'd argue once accepted it should be
> > > released.. and this also require being part of release automation.
> > >
> > > We are already struggling with current complexity in place - see the
> email
> > > I sent early today about 10.2.0 release that I'm sure Kennedy is
> fighting
> > > hard.
> > >
> > > +1 for the experimental folder, I think Toshyia provided a very good
> > > initial framework we can start with.. and probably in a point in time
> we
> > > may want to refine it.
> > >
> > > Subhanshu, in the meantime while we discuss these topics in parallel, I
> > > submitted a PR review… so please continue refining it.. don't get this
> > > helpful and healthy discussion distract you from your contribution.
> Thank
> > > you again!
> > >
> > > -
> > > Alex
> > >
> > >
> > >
> > > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com> wrote:
> > >
> > > > Hi all,
> > > > one of the critical aspects with introducing new features, IMO, it
> is to
> > > > avoid that "main" branches ends up containing unused code (we already
> > > have
> > > > a certain amount of that) that, anyway, we have to maintain, in
> terms of
> > > > security, library compatibility, etc.; basically, it will also
> impact the
> > > > CI build, with all consequent issues (see: clashing libraries
> versions,
> > > > framework upgrade hassle, etc).
> > > > Creating a specific directory inside the main branch does not solve
> any
> > > of
> > > > such problems (the name of a directory is just a human convention).
> In
> > > the
> > > > past I also remember the usage of "experimental" flags but, again,
> this
> > > > won't solve the above.
> > > > So, I would like to propose two different approaches, to both
> simplify
> > > the
> > > > introduction of new features from any contributor, on one side, and
> keep
> > > > integrity of our build, on the other side:
> > > > 1. a specific branch
> > > > 2. a specific repo
> > > >
> > > > I've not a strong opinion about any of the two. Anyway, with either
> of
> > > > those in place, maybe we would already have, in community, some code
> > > that,
> > > > in the past, has been pushed back due to lack of clear understanding
> and
> > > > other uncertainty.
> > > > And, again with that in place, that Opentelemetry feature would be
> easily
> > > > included in our domain.
> > > > (side-note: this is exactly the approach that has been followed by
> me, in
> > > > the past, after internal discussion with the so-called "drools"
> team).
> > > >
> > > > M2C
> > > >
> > > > Cheers
> > > >
> > > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi
> <toshiyakobayashi@gmail.
> > > > com> wrote:
> > > >
> > > > Also, having a `contrib/experimental` area can help reduce
> maintenance
> > > > costs. For example, it could include disclaimers such as:
> > > >
> > > > - Experimental APIs may change in future releases.
> > > > - Experimental features may be removed in future releases.
> > > > - Experimental features must not block a release. For example, if an
> > > issue
> > > > is found in an experimental feature during the release process, we
> may
> > > > choose to disable that feature for the current release.
> > > >
> > > > This is just a proposal. I’d be happy to hear your thoughts.
> > > >
> > > > Toshiya
> > > >
> > > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > > <to...@gmail.com> wrote:
> > > >
> > > > Thank you for moving this topic forward, Alex.
> > > >
> > > > I agree that criteria are required.
> > > >
> > > > What do you think would be reasonable criteria to establish?
> > > >
> > > > Here is a quick draft. Opinions are welcome:
> > > >
> > > > (Creation)
> > > > - A new feature module should default to contrib/experimental (not
> > > limited
> > > > to new contributors).
> > > > - If a developer wants to place the module elsewhere from the
> beginning,
> > > > they should start a thread on the dev mailing list (dev ML). If
> there are
> > > > no objections, it is accepted. If there are objections, a vote will
> be
> > > held
> > > > (Simple Majority vote: https://www.apache.org/foundation/glossary.
> > > > html#SimpleMajority).
> > > >
> > > > (Promotion)
> > > > - If anyone wants to promote the module to a different location, they
> > > > should start a thread on the dev ML. If there are no objections, it
> is
> > > > accepted. If there are objections, a vote will be held (Simple
> Majority
> > > > vote).
> > > >
> > > > * These criteria do not apply to the creation of modules that are
> not new
> > > > features (e.g., refactoring modules).
> > > >
> > > > Regards,
> > > > Toshiya
> > > >
> > > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me>
> wrote:
> > > >
> > > > Subhanshu,
> > > >
> > > > Thank you for the contribution, it's great idea. I'll take some time
> to
> > > > review soon.
> > > >
> > > > Now I'm sorry to hijack the thread….
> > > >
> > > > Toshiya-san,
> > > >
> > > > The idea to have contrib/experimental makes total sense, but it
> misses
> > > > criteria. Lots of features have been added by new contributors
> without
> > > >
> > > > such
> > > >
> > > > experimental or contrib labels.
> > > >
> > > > I'm absolutely in favor of exploring this idea, but we need to
> define a
> > > > fair criteria for when a thing is flagged as contrib/experimental and
> > > > what's the criteria to promote it out of that status.
> > > >
> > > > Otherwise we risk creating inconsistency in how we treat
> contributions,
> > > > especially since we've accepted feature additions at the top level in
> > > >
> > > > the
> > > >
> > > > recent past.
> > > >
> > > > What do you think would be reasonable criteria to establish?
> > > >
> > > > -
> > > > Alex
> > > >
> > > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> toshiyakobayashi@
> > > > gmail.com> wrote:
> > > >
> > > > 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
> > > > <ft...@redhat.com> 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 <
> > > >
> > > > subhanshu.bansal5566@
> > > >
> > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > > > commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> --------------------------------------------------------------------- To
> > > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For additional
> > > > commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Toshiya Kobayashi <to...@gmail.com>.
Hi Gabriele,
Assuming "drools-experimental" repo is created, I think your point is
its maintenance policy and CD/CI policy. Could you share your thoughts
on this? (e.g., Should the artifacts be released to maven repo? Should
"drools-experimental" repo CI be executed as downstream CI of "drools"
PR?)
Thanks!
Toshiya
On Wed, Mar 4, 2026 at 5:23 PM Gabriele Cardosi
<ga...@gmail.com> wrote:
>
> Alex, TOshiya, from my POV the idea of "experimental folder" introduce a
> logical and practical inconsistence, with downfall issues:
> 1. from logical POV, it would mean that there would be "stable" (mean -
> production ready) modules and code mixed with "unstable" (mean
> experimental) code experimental
> 2. there would be no way to avoid the latter impacting the former, whatever
> problem may arise (dependency clashes, CVE, bugs)
> 3. at ci level, the only way to differentiate a "stable" build with the
> experimental one would be to create/duplicate CI scripts so that, e.g.
> there would be a PR build that excludes the experimental module and another
> one that include them (or, some similar "hack") that, again, would be much
> more cumbersome to maintain
>
> There is no "easy" solution, IMO, but the constant look for "easy solution"
> always leads to "workarounds" that, soon after being implemented, proved to
> be problematic to maintain.
> Complex problems require complex solutions to be properly addressed and,
> sorry, but the idea of an "experimental folder" mixed in the very same
> "production-ready" code seems very naive to me.
>
> Cheers
>
> Gabriele
>
>
>
>
> On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org> wrote:
>
> > The problem of your suggestion Gabriele is the CI complexity it introduces,
> > being experimental or whatever.. I'd argue once accepted it should be
> > released.. and this also require being part of release automation.
> >
> > We are already struggling with current complexity in place - see the email
> > I sent early today about 10.2.0 release that I'm sure Kennedy is fighting
> > hard.
> >
> > +1 for the experimental folder, I think Toshyia provided a very good
> > initial framework we can start with.. and probably in a point in time we
> > may want to refine it.
> >
> > Subhanshu, in the meantime while we discuss these topics in parallel, I
> > submitted a PR review… so please continue refining it.. don't get this
> > helpful and healthy discussion distract you from your contribution. Thank
> > you again!
> >
> > -
> > Alex
> >
> >
> >
> > On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> > gabriele.cardosi@gmail.com> wrote:
> >
> > > Hi all,
> > > one of the critical aspects with introducing new features, IMO, it is to
> > > avoid that "main" branches ends up containing unused code (we already
> > have
> > > a certain amount of that) that, anyway, we have to maintain, in terms of
> > > security, library compatibility, etc.; basically, it will also impact the
> > > CI build, with all consequent issues (see: clashing libraries versions,
> > > framework upgrade hassle, etc).
> > > Creating a specific directory inside the main branch does not solve any
> > of
> > > such problems (the name of a directory is just a human convention). In
> > the
> > > past I also remember the usage of "experimental" flags but, again, this
> > > won't solve the above.
> > > So, I would like to propose two different approaches, to both simplify
> > the
> > > introduction of new features from any contributor, on one side, and keep
> > > integrity of our build, on the other side:
> > > 1. a specific branch
> > > 2. a specific repo
> > >
> > > I've not a strong opinion about any of the two. Anyway, with either of
> > > those in place, maybe we would already have, in community, some code
> > that,
> > > in the past, has been pushed back due to lack of clear understanding and
> > > other uncertainty.
> > > And, again with that in place, that Opentelemetry feature would be easily
> > > included in our domain.
> > > (side-note: this is exactly the approach that has been followed by me, in
> > > the past, after internal discussion with the so-called "drools" team).
> > >
> > > M2C
> > >
> > > Cheers
> > >
> > > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi <toshiyakobayashi@gmail.
> > > com> wrote:
> > >
> > > Also, having a `contrib/experimental` area can help reduce maintenance
> > > costs. For example, it could include disclaimers such as:
> > >
> > > - Experimental APIs may change in future releases.
> > > - Experimental features may be removed in future releases.
> > > - Experimental features must not block a release. For example, if an
> > issue
> > > is found in an experimental feature during the release process, we may
> > > choose to disable that feature for the current release.
> > >
> > > This is just a proposal. I’d be happy to hear your thoughts.
> > >
> > > Toshiya
> > >
> > > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > > <to...@gmail.com> wrote:
> > >
> > > Thank you for moving this topic forward, Alex.
> > >
> > > I agree that criteria are required.
> > >
> > > What do you think would be reasonable criteria to establish?
> > >
> > > Here is a quick draft. Opinions are welcome:
> > >
> > > (Creation)
> > > - A new feature module should default to contrib/experimental (not
> > limited
> > > to new contributors).
> > > - If a developer wants to place the module elsewhere from the beginning,
> > > they should start a thread on the dev mailing list (dev ML). If there are
> > > no objections, it is accepted. If there are objections, a vote will be
> > held
> > > (Simple Majority vote: https://www.apache.org/foundation/glossary.
> > > html#SimpleMajority).
> > >
> > > (Promotion)
> > > - If anyone wants to promote the module to a different location, they
> > > should start a thread on the dev ML. If there are no objections, it is
> > > accepted. If there are objections, a vote will be held (Simple Majority
> > > vote).
> > >
> > > * These criteria do not apply to the creation of modules that are not new
> > > features (e.g., refactoring modules).
> > >
> > > Regards,
> > > Toshiya
> > >
> > > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > Subhanshu,
> > >
> > > Thank you for the contribution, it's great idea. I'll take some time to
> > > review soon.
> > >
> > > Now I'm sorry to hijack the thread….
> > >
> > > Toshiya-san,
> > >
> > > The idea to have contrib/experimental makes total sense, but it misses
> > > criteria. Lots of features have been added by new contributors without
> > >
> > > such
> > >
> > > experimental or contrib labels.
> > >
> > > I'm absolutely in favor of exploring this idea, but we need to define a
> > > fair criteria for when a thing is flagged as contrib/experimental and
> > > what's the criteria to promote it out of that status.
> > >
> > > Otherwise we risk creating inconsistency in how we treat contributions,
> > > especially since we've accepted feature additions at the top level in
> > >
> > > the
> > >
> > > recent past.
> > >
> > > What do you think would be reasonable criteria to establish?
> > >
> > > -
> > > Alex
> > >
> > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi < toshiyakobayashi@
> > > gmail.com> wrote:
> > >
> > > 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
> > > <ft...@redhat.com> 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 <
> > >
> > > subhanshu.bansal5566@
> > >
> > > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > > commands, e-mail: dev-help@kie.apache.org
> > >
> > > --------------------------------------------------------------------- To
> > > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For additional
> > > commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Gabriele Cardosi <ga...@gmail.com>.
Alex, TOshiya, from my POV the idea of "experimental folder" introduce a
logical and practical inconsistence, with downfall issues:
1. from logical POV, it would mean that there would be "stable" (mean -
production ready) modules and code mixed with "unstable" (mean
experimental) code experimental
2. there would be no way to avoid the latter impacting the former, whatever
problem may arise (dependency clashes, CVE, bugs)
3. at ci level, the only way to differentiate a "stable" build with the
experimental one would be to create/duplicate CI scripts so that, e.g.
there would be a PR build that excludes the experimental module and another
one that include them (or, some similar "hack") that, again, would be much
more cumbersome to maintain
There is no "easy" solution, IMO, but the constant look for "easy solution"
always leads to "workarounds" that, soon after being implemented, proved to
be problematic to maintain.
Complex problems require complex solutions to be properly addressed and,
sorry, but the idea of an "experimental folder" mixed in the very same
"production-ready" code seems very naive to me.
Cheers
Gabriele
On Wed, Mar 4, 2026 at 3:13 AM Alex Porcelli <po...@apache.org> wrote:
> The problem of your suggestion Gabriele is the CI complexity it introduces,
> being experimental or whatever.. I'd argue once accepted it should be
> released.. and this also require being part of release automation.
>
> We are already struggling with current complexity in place - see the email
> I sent early today about 10.2.0 release that I'm sure Kennedy is fighting
> hard.
>
> +1 for the experimental folder, I think Toshyia provided a very good
> initial framework we can start with.. and probably in a point in time we
> may want to refine it.
>
> Subhanshu, in the meantime while we discuss these topics in parallel, I
> submitted a PR review… so please continue refining it.. don't get this
> helpful and healthy discussion distract you from your contribution. Thank
> you again!
>
> -
> Alex
>
>
>
> On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
> gabriele.cardosi@gmail.com> wrote:
>
> > Hi all,
> > one of the critical aspects with introducing new features, IMO, it is to
> > avoid that "main" branches ends up containing unused code (we already
> have
> > a certain amount of that) that, anyway, we have to maintain, in terms of
> > security, library compatibility, etc.; basically, it will also impact the
> > CI build, with all consequent issues (see: clashing libraries versions,
> > framework upgrade hassle, etc).
> > Creating a specific directory inside the main branch does not solve any
> of
> > such problems (the name of a directory is just a human convention). In
> the
> > past I also remember the usage of "experimental" flags but, again, this
> > won't solve the above.
> > So, I would like to propose two different approaches, to both simplify
> the
> > introduction of new features from any contributor, on one side, and keep
> > integrity of our build, on the other side:
> > 1. a specific branch
> > 2. a specific repo
> >
> > I've not a strong opinion about any of the two. Anyway, with either of
> > those in place, maybe we would already have, in community, some code
> that,
> > in the past, has been pushed back due to lack of clear understanding and
> > other uncertainty.
> > And, again with that in place, that Opentelemetry feature would be easily
> > included in our domain.
> > (side-note: this is exactly the approach that has been followed by me, in
> > the past, after internal discussion with the so-called "drools" team).
> >
> > M2C
> >
> > Cheers
> >
> > On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi <toshiyakobayashi@gmail.
> > com> wrote:
> >
> > Also, having a `contrib/experimental` area can help reduce maintenance
> > costs. For example, it could include disclaimers such as:
> >
> > - Experimental APIs may change in future releases.
> > - Experimental features may be removed in future releases.
> > - Experimental features must not block a release. For example, if an
> issue
> > is found in an experimental feature during the release process, we may
> > choose to disable that feature for the current release.
> >
> > This is just a proposal. I’d be happy to hear your thoughts.
> >
> > Toshiya
> >
> > On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> > <to...@gmail.com> wrote:
> >
> > Thank you for moving this topic forward, Alex.
> >
> > I agree that criteria are required.
> >
> > What do you think would be reasonable criteria to establish?
> >
> > Here is a quick draft. Opinions are welcome:
> >
> > (Creation)
> > - A new feature module should default to contrib/experimental (not
> limited
> > to new contributors).
> > - If a developer wants to place the module elsewhere from the beginning,
> > they should start a thread on the dev mailing list (dev ML). If there are
> > no objections, it is accepted. If there are objections, a vote will be
> held
> > (Simple Majority vote: https://www.apache.org/foundation/glossary.
> > html#SimpleMajority).
> >
> > (Promotion)
> > - If anyone wants to promote the module to a different location, they
> > should start a thread on the dev ML. If there are no objections, it is
> > accepted. If there are objections, a vote will be held (Simple Majority
> > vote).
> >
> > * These criteria do not apply to the creation of modules that are not new
> > features (e.g., refactoring modules).
> >
> > Regards,
> > Toshiya
> >
> > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > Subhanshu,
> >
> > Thank you for the contribution, it's great idea. I'll take some time to
> > review soon.
> >
> > Now I'm sorry to hijack the thread….
> >
> > Toshiya-san,
> >
> > The idea to have contrib/experimental makes total sense, but it misses
> > criteria. Lots of features have been added by new contributors without
> >
> > such
> >
> > experimental or contrib labels.
> >
> > I'm absolutely in favor of exploring this idea, but we need to define a
> > fair criteria for when a thing is flagged as contrib/experimental and
> > what's the criteria to promote it out of that status.
> >
> > Otherwise we risk creating inconsistency in how we treat contributions,
> > especially since we've accepted feature additions at the top level in
> >
> > the
> >
> > recent past.
> >
> > What do you think would be reasonable criteria to establish?
> >
> > -
> > Alex
> >
> > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi < toshiyakobayashi@
> > gmail.com> wrote:
> >
> > 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
> > <ft...@redhat.com> 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 <
> >
> > subhanshu.bansal5566@
> >
> > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > commands, e-mail: dev-help@kie.apache.org
> >
> > --------------------------------------------------------------------- To
> > unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For additional
> > commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Alex Porcelli <po...@apache.org>.
The problem of your suggestion Gabriele is the CI complexity it introduces,
being experimental or whatever.. I'd argue once accepted it should be
released.. and this also require being part of release automation.
We are already struggling with current complexity in place - see the email
I sent early today about 10.2.0 release that I'm sure Kennedy is fighting
hard.
+1 for the experimental folder, I think Toshyia provided a very good
initial framework we can start with.. and probably in a point in time we
may want to refine it.
Subhanshu, in the meantime while we discuss these topics in parallel, I
submitted a PR review… so please continue refining it.. don't get this
helpful and healthy discussion distract you from your contribution. Thank
you again!
-
Alex
On Mon, Mar 02, 2026 at 3:32 AM, Gabriele Cardosi <
gabriele.cardosi@gmail.com> wrote:
> Hi all,
> one of the critical aspects with introducing new features, IMO, it is to
> avoid that "main" branches ends up containing unused code (we already have
> a certain amount of that) that, anyway, we have to maintain, in terms of
> security, library compatibility, etc.; basically, it will also impact the
> CI build, with all consequent issues (see: clashing libraries versions,
> framework upgrade hassle, etc).
> Creating a specific directory inside the main branch does not solve any of
> such problems (the name of a directory is just a human convention). In the
> past I also remember the usage of "experimental" flags but, again, this
> won't solve the above.
> So, I would like to propose two different approaches, to both simplify the
> introduction of new features from any contributor, on one side, and keep
> integrity of our build, on the other side:
> 1. a specific branch
> 2. a specific repo
>
> I've not a strong opinion about any of the two. Anyway, with either of
> those in place, maybe we would already have, in community, some code that,
> in the past, has been pushed back due to lack of clear understanding and
> other uncertainty.
> And, again with that in place, that Opentelemetry feature would be easily
> included in our domain.
> (side-note: this is exactly the approach that has been followed by me, in
> the past, after internal discussion with the so-called "drools" team).
>
> M2C
>
> Cheers
>
> On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi <toshiyakobayashi@gmail.
> com> wrote:
>
> Also, having a `contrib/experimental` area can help reduce maintenance
> costs. For example, it could include disclaimers such as:
>
> - Experimental APIs may change in future releases.
> - Experimental features may be removed in future releases.
> - Experimental features must not block a release. For example, if an issue
> is found in an experimental feature during the release process, we may
> choose to disable that feature for the current release.
>
> This is just a proposal. I’d be happy to hear your thoughts.
>
> Toshiya
>
> On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> <to...@gmail.com> wrote:
>
> Thank you for moving this topic forward, Alex.
>
> I agree that criteria are required.
>
> What do you think would be reasonable criteria to establish?
>
> Here is a quick draft. Opinions are welcome:
>
> (Creation)
> - A new feature module should default to contrib/experimental (not limited
> to new contributors).
> - If a developer wants to place the module elsewhere from the beginning,
> they should start a thread on the dev mailing list (dev ML). If there are
> no objections, it is accepted. If there are objections, a vote will be held
> (Simple Majority vote: https://www.apache.org/foundation/glossary.
> html#SimpleMajority).
>
> (Promotion)
> - If anyone wants to promote the module to a different location, they
> should start a thread on the dev ML. If there are no objections, it is
> accepted. If there are objections, a vote will be held (Simple Majority
> vote).
>
> * These criteria do not apply to the creation of modules that are not new
> features (e.g., refactoring modules).
>
> Regards,
> Toshiya
>
> On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me> wrote:
>
> Subhanshu,
>
> Thank you for the contribution, it's great idea. I'll take some time to
> review soon.
>
> Now I'm sorry to hijack the thread….
>
> Toshiya-san,
>
> The idea to have contrib/experimental makes total sense, but it misses
> criteria. Lots of features have been added by new contributors without
>
> such
>
> experimental or contrib labels.
>
> I'm absolutely in favor of exploring this idea, but we need to define a
> fair criteria for when a thing is flagged as contrib/experimental and
> what's the criteria to promote it out of that status.
>
> Otherwise we risk creating inconsistency in how we treat contributions,
> especially since we've accepted feature additions at the top level in
>
> the
>
> recent past.
>
> What do you think would be reasonable criteria to establish?
>
> -
> Alex
>
> On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi < toshiyakobayashi@
> gmail.com> wrote:
>
> 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
> <ft...@redhat.com> 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 <
>
> subhanshu.bansal5566@
>
> gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> commands, e-mail: dev-help@kie.apache.org
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@kie.apache.org For additional
> commands, e-mail: dev-help@kie.apache.org
>
>
Re: [HEADS-UP] Implement Drools Open Telemetry Support
Posted by Gabriele Cardosi <ga...@gmail.com>.
Hi all,
one of the critical aspects with introducing new features, IMO, it is to
avoid that "main" branches ends up containing unused code (we already have
a certain amount of that) that, anyway, we have to maintain, in terms of
security, library compatibility, etc.; basically, it will also impact the
CI build, with all consequent issues (see: clashing libraries versions,
framework upgrade hassle, etc).
Creating a specific directory inside the main branch does not solve any of
such problems (the name of a directory is just a human convention).
In the past I also remember the usage of "experimental" flags but, again,
this won't solve the above.
So, I would like to propose two different approaches, to both simplify the
introduction of new features from any contributor, on one side, and keep
integrity of our build, on the other side:
1. a specific branch
2. a specific repo
I've not a strong opinion about any of the two. Anyway, with either of
those in place, maybe we would already have, in community, some code that,
in the past, has been pushed back due to lack of clear understanding and
other uncertainty.
And, again with that in place, that Opentelemetry feature would be easily
included in our domain.
(side-note: this is exactly the approach that has been followed by me, in
the past, after internal discussion with the so-called "drools" team).
M2C
Cheers
On Mon, Mar 2, 2026 at 8:24 AM Toshiya Kobayashi <to...@gmail.com>
wrote:
> Also, having a `contrib/experimental` area can help reduce maintenance
> costs. For example, it could include disclaimers such as:
>
> - Experimental APIs may change in future releases.
> - Experimental features may be removed in future releases.
> - Experimental features must not block a release. For example, if an
> issue is found in an experimental feature during the release process,
> we may choose to disable that feature for the current release.
>
> This is just a proposal. I’d be happy to hear your thoughts.
>
> Toshiya
>
> On Fri, Feb 27, 2026 at 11:20 AM Toshiya Kobayashi
> <to...@gmail.com> wrote:
> >
> > Thank you for moving this topic forward, Alex.
> >
> > I agree that criteria are required.
> >
> > > What do you think would be reasonable criteria to establish?
> >
> > Here is a quick draft. Opinions are welcome:
> >
> > (Creation)
> > - A new feature module should default to contrib/experimental (not
> > limited to new contributors).
> > - If a developer wants to place the module elsewhere from the
> > beginning, they should start a thread on the dev mailing list (dev
> > ML). If there are no objections, it is accepted. If there are
> > objections, a vote will be held (Simple Majority vote:
> > https://www.apache.org/foundation/glossary.html#SimpleMajority).
> >
> > (Promotion)
> > - If anyone wants to promote the module to a different location, they
> > should start a thread on the dev ML. If there are no objections, it is
> > accepted. If there are objections, a vote will be held (Simple
> > Majority vote).
> >
> > * These criteria do not apply to the creation of modules that are not
> > new features (e.g., refactoring modules).
> >
> > Regards,
> > Toshiya
> >
> > On Fri, Feb 27, 2026 at 2:18 AM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > Subhanshu,
> > >
> > > Thank you for the contribution, it's great idea. I'll take some time to
> > > review soon.
> > >
> > > Now I'm sorry to hijack the thread….
> > >
> > > Toshiya-san,
> > >
> > > The idea to have contrib/experimental makes total sense, but it misses
> > > criteria. Lots of features have been added by new contributors without
> such
> > > experimental or contrib labels.
> > >
> > > I'm absolutely in favor of exploring this idea, but we need to define a
> > > fair criteria for when a thing is flagged as contrib/experimental and
> > > what's the criteria to promote it out of that status.
> > >
> > > Otherwise we risk creating inconsistency in how we treat contributions,
> > > especially since we've accepted feature additions at the top level in
> the
> > > recent past.
> > >
> > > What do you think would be reasonable criteria to establish?
> > >
> > > -
> > > Alex
> > >
> > > On Wed, Feb 25, 2026 at 11:15 PM, Toshiya Kobayashi <
> > > toshiyakobayashi@gmail.com> wrote:
> > >
> > > > 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
> > > > <ft...@redhat.com> 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 <
> subhanshu.bansal5566@
> > > > gmail.com> 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: dev-unsubscribe@kie.apache.org For additional
> > > > commands, e-mail: dev-help@kie.apache.org
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>