Add "Sunsetting OpenCensus" blog post #2629
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,92 @@ | ||
| --- | ||
| title: Sunsetting OpenCensus | ||
| linkTitle: Sunsetting OpenCensus | ||
| date: 2023-05-01 | ||
| author: '[Aaron Abbott](https:/aabmass) (Google)' | ||
| --- | ||
|
|
||
| In 2019, we announced that OpenTracing and OpenCensus would be merging to form | ||
| the OpenTelemetry project. From the start, we considered OpenTelemetry | ||
| [to be the next major version of both OpenTracing and OpenCensus](https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/). | ||
|
|
||
| We are excited to announce that OpenTelemetry has reached feature parity with | ||
|
There was a problem hiding this comment. Doesn't OpenCensus have a stable logging story? There was a problem hiding this comment. Otel's logging data model is stable, could you give an example of what you mean in opencensus? There was a problem hiding this comment. If you go to OTel-Python repo the logs API and SDK files both have underscores before them. In the OTel-Spec, the Logs/Events API (if/when it comes into being) is not stable. Just a having a stable data model doesn't guarantee customers won't be broken in the future. We should be up front that there is a caveat about this "feature parity" claim. Customers could take a bet on OpenCensus Logging, whereas I don't see that same level of confidence with OTel logging yet. There was a problem hiding this comment. OpenCensus does not include any logging API whatsoever. It was just "stats(metrics) + traces". There was a problem hiding this comment. If OTel would make the same decision and call it done, then I'd feel comfortable with the "feature parity" claim. IMO, we should make customers aware that the OTel logging pillar is still WIP. There was a problem hiding this comment. @mattmccleary maybe I'm misunderstanding your point, but if OC only supported metrics and traces then doesn't feature parity with OTel only rely on metrics and traces? I am confused how the addition of logging in OTel isn't compatible with OC There was a problem hiding this comment. Exactly. OpenCensus users don't need to migrate OC logging because there was nothing to migrate, it didn't exist. We're asking OC users to migrate their metrics + traces to OpenTelemetry. I don't understand the point you're making at all. There was a problem hiding this comment. Azure customers have taken a production dependency on an Azure-specific OpenCensus Logs Exporter: If they migrate to OTLP Python Exporter for Logging, are you guaranteeing it's stable and they will not be broken in the future? I just want to make sure we're properly setting customer expectations for this cohort. There was a problem hiding this comment. I see. OpenCensus extensions are NOT part of this transition plan, nor will we be transitioning existing OpenCensus exporters. The module you list would be considered both. For the extension you mention, I'd suggest Azure could provide such a module to an OpenTelemetry Contrib component. From what I can tell, it's very Azure specific (and does not even require the user to interact with OpenCensus to install it). Additionally, you could still recommend Azure customers use that log exporter while they transition Metrics/Traces to OpenTelemetry via the OpenCesnus shim and I bet nothing breaks. There are other extensions/contrib in opencensus, e.g. https:/census-instrumentation/opencensus-java/tree/master/contrib/log_correlation/log4j2. These will not break when using the OpenCensus-shim. There was a problem hiding this comment.
Awesome. As long as this is clear to customers, great. It wasn't to me. Many of the customers I work with are not deeply versed in the communities like we are. They do not understand (or care to understand) the difference between extensions vs core components. It's all OpenCensus to them. |
||
| OpenCensus in C++, .NET, Go, Java, JavaScript, PHP and Python. | ||
| [Stable releases](/docs/instrumentation/#status-and-releases) of both the | ||
| Tracing and Metrics SDKs are available in most of these languages with Go and | ||
| PHP soon to follow. This means that OpenTelemetry can collect and export | ||
| telemetry data with the same level of functionality as OpenCensus. Beyond that, | ||
| OpenTelemetry offers a [richer ecosystem](/ecosystem) of instrumentation | ||
| libraries and exporters, and an | ||
| [active open source community](https://www.cncf.io/blog/2023/01/11/a-look-at-the-2022-velocity-of-cncf-linux-foundation-and-top-30-open-source-projects/). | ||
|
|
||
| As a result, we will be archiving all OpenCensus GitHub repositories (with the | ||
| exception of [census-instrumentation/opencensus-python][][^python-timeline]) on | ||
| July 31st, 2023. We are excited to see the | ||
| [long term plan for OpenTelemetry](https://medium.com/opentracing/a-roadmap-to-convergence-b074e5815289) | ||
| coming to fruition and encourage all users of OpenCensus to migrate to | ||
| OpenTelemetry. | ||
|
|
||
| ## How to Migrate to OpenTelemetry | ||
|
|
||
| One of the | ||
| [key goals](https://medium.com/opentracing/merging-opentracing-and-opencensus-f0fe9c7ca6f0) | ||
| of the OpenTelemetry project is to provide backward compatibility with | ||
| OpenCensus and a migration story for existing users. | ||
|
|
||
| To help ease the migration path, we have provided backward compatibility bridges | ||
| in [Go][go shim], [Java][java shim], [JavaScript][js shim][^shim-next-release], | ||
| and [Python][python shim][^shim-next-release]. Installing these bridges allows | ||
|
There was a problem hiding this comment. Can we be clear about the current status of these shims and if/when they will be stable? There was a problem hiding this comment. Agree. Would be good to provide a current status of these bridges and how long they will be maintained (whats the LTS plan). There was a problem hiding this comment. LTS is under https:/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#long-term-support. As far as stability, now that the specification is marked as stable, we can get each component to be marked as stable. There was a problem hiding this comment. added a footnote re: stability and support, linking to the docs Josh provided |
||
| OpenCensus and OpenTelemetry instrumentation to smoothly interoperate, with all | ||
| of your telemetry flowing out of OpenTelemetry exporters. This lets OpenCensus | ||
| users incrementally transition all of their instrumentation from OpenCensus to | ||
|
There was a problem hiding this comment. Can we expand out the steps of how/why we consider this incremental? There was a problem hiding this comment. Details about migration plans are included in the compatibility specification linked below this https://opentelemetry.io/docs/reference/specification/compatibility/opencensus/#migration-plans, as well as language-specific outlines in the documentation for each shim. There was a problem hiding this comment. @mattmccleary given the overhead you'd find from double-o11y solutions, side-by-side running would not be recommended. Far better to A:B test different configurations in different running binaries. Even then, it's an expensive user proposition. As @damemi points out, the justification behind the incremental approach is in the migration plan. |
||
| OpenTelemetry, and finally remove OpenCensus libraries from their applications. | ||
|
|
||
| While OpenTelemetry was never intended to be a strict superset of OpenCensus, | ||
| most of the APIs and data models are compatible. Migration should be considered | ||
| a "major version bump" and you may notice some changes in your telemetry. | ||
|
|
||
|
|
||
| More details on what to expect and some suggested workflows for migration are | ||
| outlined in the | ||
| [OpenCensus Compatibility specification](/docs/reference/specification/compatibility/opencensus#migration-path)[^spec-next-release]. | ||
|
|
||
| ## What to Expect After July 31st, 2023 | ||
|
There was a problem hiding this comment. Is there intention to mention the support lifecycle for shims or we want to separate the concern? There was a problem hiding this comment. LTS and support plans would be good to share - see my comment above. There was a problem hiding this comment. The Shims are in OpenTelemetry and subject to https:/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#long-term-support. Currently, that's one year support (from OTEL's side). |
||
|
|
||
| After July 31st, 2023, the OpenCensus project will no longer be maintained. This | ||
|
There was a problem hiding this comment. except Python, right? Can we be consistent with langauge above? There was a problem hiding this comment. That is included in this section, https:/open-telemetry/opentelemetry.io/pull/2629/files#diff-3f663d56dad3c82fc67e741b0ed70e07ed18d2ac9661fd947d562b8d1be4db54R64-R65 There was a problem hiding this comment. I see it now...just didn't catch my eye because it seemed separate. |
||
| means that there will be no new features added to the project, and any security | ||
| vulnerabilities that are found will not be patched. | ||
|
|
||
| However, the OpenCensus repositories will remain archived on GitHub. This means | ||
| users will still be able to download the OpenCensus code and use it in their | ||
| projects. Existing releases of OpenCensus will remain available in public | ||
| package repositories like NPM and PyPI. **We encourage all OpenCensus users to | ||
| begin planning your migration to OpenTelemetry now.** | ||
|
|
||
| One exception to this is the | ||
| [census-instrumentation/opencensus-python][][^python-timeline] repo. | ||
|
|
||
| [go shim]: | ||
| https:/open-telemetry/opentelemetry-go/tree/main/bridge/opencensus | ||
| [java shim]: | ||
| https:/open-telemetry/opentelemetry-java/tree/main/opencensus-shim | ||
| [python shim]: | ||
| https:/open-telemetry/opentelemetry-python/tree/main/shim/opentelemetry-opencensus-shim | ||
| [js shim]: | ||
| https:/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-shim-opencensus | ||
| [census-instrumentation/opencensus-python]: | ||
| https:/census-instrumentation/opencensus-python | ||
|
|
||
| [^python-timeline]: | ||
| A number of projects within this repository are still being used as | ||
| recommended production solutions. These projects will continue to be | ||
| maintained. Please reach out to the individual maintainers for details | ||
| regarding maintenance timeline, next steps for migration and general support | ||
| questions. | ||
|
|
||
| [^shim-next-release]: | ||
| Python and JavaScript shim packages are currently unreleased but will be | ||
| available in future releases. | ||
|
|
||
| [^spec-next-release]: | ||
| The | ||
| [OpenCensus Compatability specification](https://opentelemetry.io/docs/reference/specification/compatibility/opencensus/) | ||
| is marked stable for the next specification release. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any announcement from the OpenCensus official site? It'll be great to have the cross reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're planning to update the banner on the OpenCensus website to announce the date and point with a link to this blog post.