skywalking
skywalking copied to clipboard
apache
[Feature] [Java] OpenTracing APIs have deprecated
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Description
The OpenTracing project is deprecated. Please use OpenTelemetry, which provides backwards compatibility with OpenTracing.
The above statement is from the official channel, https://opentracing.io/
Use case
OpenTracing bridge existed for years, but we don't have very positive user feedback. Most are using agent + our native SDK(APIs and annotations).
We should consider removing the OpenTracing bridge, evaluating the OpenTelemetry APIs, to see whether it is necessary to adopt them.
Eventually, we need to remove the OpenTracing bridge as we never upgraded to the latest release due to not suitable anymore.
Related issues
No response
Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
@wu-sheng Hello, will skywalking implement opentelemetry API in the future?
It depends on how the community react. I don't know. I could only say, most likely I wouldn't do that.
@wu-sheng hello! i wish to instrument a java application, using the native Skywalking agent. however, i have the need to be able to open and close custom spans programmatically, and in my application i can't use 'apm-toolkit-trace', since in my scenario is not possible to alterate the code adding @Trace annotations. So i gave a try to your 'apm-toolkit-opentracing' module, but i'm not able to see any of the custom spans in Skywalking-UI. I also noticed that the module depends on an old version of OpenTracing APIs, and some of the features seem to be not implemented (SpanContext instance appears to be always the same, baggageItems are always null...).
If the module 'apm-toolkit-opentracing' is still supported, is available somewhere a detailed guide to configure it? If the module 'apm-toolkit-opentracing' is deprecated, will it ever be replaced with something similar based on OpenTelemetry APIs? I think that would be very useful to have a Skywalking OpenTelemetry Tracer implementation that could work together with your native agent, even with minimum functionalities (opening/closing spans, adding tags, adding logs/events). Thank you!
The OT API bridge is still there. We wouldn't move on to the latest OT APIs, as they are not compatible with SkyWalking concepts. We asked them not to do so, but OT team was not listening. So, that left us no choice but to keep everything stale.
Also, OTEL tracer is not, because no one in the community wants to do the work. So, from SkyWalking's open-source understanding, it is not important at all.
All docs are in the doc already, https://skywalking.apache.org/docs/skywalking-java/v8.11.0/en/setup/service-agent/java-agent/opentracing/ Others about how to use tracer, that is OpenTracing's doc part. Not ours.
No matter what issue you would face, you should know, that this is why user never prefers SDK integration, considering SkyWalking's agent and plugin system are so powerful. If you want to use SDK, no matter our tracing APIs, or OT APIs, you have to learn more. All these are not simply out-of-box
We're evaluating APMs at the moment. You don't support Open Telemetry, so you're out of the running. Is your protocol so much better you can ignore it?
You could skip the project, if it doesn't fit your requirements. Nothing more.
We're evaluating APMs at the moment. You don't support Open Telemetry, so you're out of the running. Is your protocol so much better you can ignore it?
Who are u?
An update, in the next 8.15.0(will release soon), we have the complete native tracer APIs to bridge user codes and agent kernel.
ref doc, https://skywalking.apache.org/docs/skywalking-java/next/en/setup/service-agent/java-agent/application-toolkit-tracer/
Users could adopt these APIs if they feel OK to change their source codes. I am closing this issue until anyone feels still he/she still wants to work on this. From a feature perspective, we are all good.