[wildfly-dev] Re: Supporting OpenTelemetry in Reactive Messaging connectors

On Wed, Oct 9, 2024 at 3:01 PM Kabir Khan <kkhan(a)redhat.com&gt; wrote: > Hi, > > This is about the following RFEs: > > https://issues.redhat.com/browse/WFLY-19835 > https://issues.redhat.com/browse/WFLY-19836 > > They are about integrating the AMQP and Kafka connectors used by Reactive > Messaging with OpenTelemetry tracing. I'd just like to brainstorm a bit > before jumping in. > > The code is already there in SmallRye but is totally disabled in WildFly > via this ConfigSource setting the > mp.messaging.connector.smallrye-amqp.tracing-enabled and > mp.messaging.connector.smallrye-kafka.tracing-enabled MP Config properties > to false. > > > https://github.com/wildfly/wildfly/blob/main/microprofile/reactive-messag... > > This config source has the max ordinal > <https://github.com/wildfly/wildfly/blob/main/microprofile/reactive-messag...;, > so it cannot be overridden at the moment. > > I think to enable this I need to: > 1) Add optional module dependencies from the connector modules to the > Otel module providing Tracer > 2) Adjust the properties to allow for tracing to happen > > I think it makes sense to keep the default behaviour as not enabling > tracing for backwards compatibility? > > To be able to enable tracing via MP Config, we would need to lower the > ordinal of the config source providing these properties. This way > deployments will be able to opt in to using tracing. > > However, if tracing is enabled and the OTel modules are not present, the > SmallRye connectors will fail. > > So it seems I need to add an attribute to the currently empty subsystem > to allow for tracing, and then do some capability/Galleon wiring to > provision OTel if it indicates that we allow tracing. The value of the > attribute would then influence the value of the ConfigSource properties > behind the scenes. > > Since OTel being present is a yes/no situation, we could get away with > one attribute - but perhaps it makes sense to allow configuration for this > for each connector separately. Not sure how that works with the > provisioning, but I guess if both of these depend on OTel, and one of them > is set to indicate Otel is needed, we're good. > > As for the values of the attributes, I am thinking: > * never - this sets the properties in the config source as it does at > present, where it is set to false with a max ordinal so deployments can not > override it > * off - this would set the config source properties to false again, but > with an ordinal value that can be overridden in the deployment (and system > properties, env vars etc). So it is off by default but can be turned on > * on - this would set the config source properties to true, but with an > ordinal value that can be overridden in the deployment (and system > properties, env vars etc). So it is on by default but can be turned off > * always - this is like 'never' so the config source ordinal is the > maximum, and the properties are set to true. Thus deployments can not opt > out. > > Does the capability stuff work so that if the value of the subsystem > attributes are *off*, *on* or *always* I add the requirement? And I > don't if it is *never*? > > Any other thoughts/suggestions/objections? > Galleon can't make provisioning decisions based on attribute values, other than understanding the dynamic part of capability references a la a socket binding name. The management API in general can't express that kind of "require capability X is value is Y" thing. Which is why Galleon can't figure out the requirements and provision accordingly. s/is value is Y/if value is Y/g

I think you need a resource, with your 'never' concept not being an attribute value but rather the absence of the resource. AIUI the other options all allow for the possibility of turning it on and thus require provisioning of the required stuff. The resource expresses the capability requirement. > Thanks, > > Kabir > > > > > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His