-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overview of Major blockers for GA/Stable Release #1572
Comments
This was referenced Apr 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A lot has happened over last few months in this repo - We added support for Logs signal, Metrics was rewritten to match new spec, plenty of performance improvements were achieved, spun up contrib repo and lot more. Big thanks to
everyone who made it happen!
Still, we are not in a position to declare stable for any signal yet, and this issue is meant to highlight the challenges/issues that is blocking a stable release. This is not a comprehensive list of all the issues, but rather an overview, only highlighting key challenges, organized by signal. The potential timelines are also not discussed in this issue, but will be separately announced.
Logs
API:
opentelemetry
crate does not provide an end-user-facing logging API but instead offers a logging-bridge API. This approach simplifies the process of stabilizing the logging signal, although it requires addressing issues related to the API making overly opinionated decisions.tracing
crate is recommended for logging, and a logging-bridge fortracing
is planned to be maintained within the repository itself, though the final decision can be influenced by the outcome of OTel Tracing API vs Tokio-TracingAPI.
SDK:
to using
tracing
with a custom subscriber that publishes to OTLP, bypassing OTel SDK.with traces, especially when the
tracing
crate is used instead of the OTel Tracing API. This issue also affects the Traces signal and will likely be resolved with a unified solution. OTel Tracing API vs Tokio-Tracing API is intermixed with this to a certain extent.Metrics
API:
SDK:
Traces
API:
tracing
crate. Addressing this interoperability issue is a top priority before the Tracing API can be considered stable. OTel Tracing API vs Tokio-TracingAPI describes this in detail.
SDK:
OTLP Exporter (All Signals)
Context API
There were performance concerns raised about this API, we may need to special case a lot to make sure this won't become a bottleneck. Baggage may need some attention as
well, but I believe it can be treated as lower priority - though OTel's Baggage API is stable, the W3C Baggage propagation format is not yet final.
The text was updated successfully, but these errors were encountered: