Camel-Tracing: Removing NsqSpanDecorator since component is no more a…

[oscerd]

…vailable

Description

Target

• I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.

• I have run mvn clean install -DskipTests locally and I have committed all auto-generated changes

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟

🐫 Maintainers, please note that first-time contributors require manual approval for the GitHub Actions to run.

⚠️ Please note that the changes on this PR may be tested automatically if they change components.

🤖 Use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot.

If necessary Apache Camel Committers may access logs and test results in the job summaries!

[oscerd]

@marcingrzejszczak I'm looking at the span decorator available and I do think we could add some more. Do you have any suggestions on this particular task? Thanks.

[marcingrzejszczak]

@oscerd I don't exactly follow. What is the concrete question? Are you trying to add more span decorators?

[oscerd]

Yes, I meant to ask if you have idea of what component decorators make more sense in your experience

[marcingrzejszczak]

I mean all components can be interesting to the users. Preferably we should ask the users what are they most interested in or which telemetry data they feel that they are currently missing.

[oscerd]

I think we should start by covering the most used ones (maybe the cloud services or messaging stuff), I will try to add some of them and open PRs. Thanks for your feedback.

[oscerd]

@davsclaus I do think this is could be a good approach (asking users) for improving the decorators' coverage.

[davsclaus]

Yes that would be good to have more of them

[marcingrzejszczak]

Another option would be to go through https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/ to see which conventions are defined today (remember that these are not stable so let's not ever say that we are OTel semantic convention compatible because if we do we will have to keep on doing breaking changes) and try to double check if our instrumentations are setting similar meta data.

[davsclaus]

@marcingrzejszczak that is a great idea - we should make these camel components use same convention if possible. I have created a JIRA: https://issues.apache.org/jira/browse/CAMEL-19812

[marcingrzejszczak]

Be very careful though cause these conventions are NOT stable. That means that they can do a breaking change and if we say that Camel is opentelemetry semantic convention compatible, you would be required to do a breaking change in a non-breaking version. Let's just be very careful about that. We can say that we were using the conventions from the given date and then once they are stable we can provide the users an option to migrate to the new tags and deprecate the old ones but in a non aggressive way (e.g. we would remove the deprecated tags after 3-4 minor releases). Does it make any sense what I'm saying? :P

[davsclaus]

Yes its okay, we will add notes in our upgrade guides if tags are renamed, and can also do dual names to keep the deprecated for a number of releases.

[oscerd]

I think it would be beneficial to have a look at what we have as decorators today and do a little example to what we want to have