484258eb36
* Added Linux-specific detector for the os.description attribute * Generalized OS description detector with placeholder function for unimplemented OSes * Extended osDescription function to *nix OSes based on golang.org/x/sys/unix * Added WithOS resource configuration function to configure all of the OS resource attributes * Implemented osDescription funtion for Windows OS * Improved documentation header for *nix version of the osDescription function * Added support for reading os-release file * Added/updated documentation headers for *nix implementation of osDescription and related functions * Changelog update * Added support for reading macOS version information * Mock approach to test OS description attribute * Extracted common function getFirstAvailableFile to read the first available file from a list of candidates * Upgraded golang.org/x/sys * Changelog update * Fixed wrong function name in documentation header for WithOSDescription * Updated documentation header for platformOSDescription function * Renamed restoreProcessAttributesProviders test helper function The function restoreProcessAttributesProviders was renamed to simply restoreAttributesProviders to better reflect its broader scope, which not only applies to process attribute's providers. * Fixed os_linux.go overriding build tags defined inside the file The suffix on os_linux.go was overriding the build tags already defined in that file. The file was renamed to os_release_unix.go, reflecting the main function defined in the file. For consistency, os_darwin.go was renamed to os_release_darwing.go, as its primary purpose is to also define the osRelease function. * Removed use of discontinued function resource.WithoutBuiltin * Added PR number to changelog entries * Updated go.sum files after run of make lint * Linux implementation: ignore lines with an empty key * Linux implementation: avoid unquoting strings less than two chars * WIP: added tests for Linux support functions * WIP: added tests for charsToString and getFirstAvailableFile functions * Replaced os.CreateTemp with ioutil.TempFile as the former only exists in Go 1.16 * Added unameProvider type to decouple direct reference to unix.Uname function inside Uname() * Added tests for Uname() function * Replaced *os.File with io.Reader in parseOSReleaseFile to ease testing * Added tests for parseOSReleaseFile function * Darwin implementation: added tests for buildOSRelease function * Replaced *os.File with io.Reader in parsePlistFile to ease testing * Darwin implementation: added tests for parsePlistFile function * Type in documentation header for Linux osRelease function * Extracted logic for reading specific registry values into helper functions * Added basic tests for Windows version of platformOSDescription and helper functions * Manually formatted uint64 to strings to have an uniform interface for test assertions * Asserts there's no error when opening registry key for testing Co-authored-by: Robert Pająk <pellared@hotmail.com> * Simplified subtests by using a single test with multiple asserts * go.sum update after running make * Fix typo Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com> * WIP: added placeholder implementation of platformOSDescription for unsupported OSes * Fixed typo on osRelease documentation header Co-authored-by: Chris Bandy <bandy.chris@gmail.com> * Fixed typo on test case name for ParsePlistFile tests Co-authored-by: Chris Bandy <bandy.chris@gmail.com> * Linter fix in changelog * go.sum updates after running make * Used strings.Replacer instead of multiple strings.ReplaceAll calls * Optimized implementation of charsToString * Safer temporary file deletion with t.TempDir() * Used t.Cleanup() for safer mocking of runtime providers in OS resource tests * Handled optionality of DisplayVersion registry key. For example, CI machine runs on: Windows Server 2019 Datacenter (1809) [Version 10.0.17763.1999] So, to not add an extra white space due to missing DisplayVersion, this value is checked to be not empty, and only in such case a trailing space is added for that component. * Workaround to handle the case of DisplayVersion registry key not present * Excluded unsupported GOOSes by negation of supported ones * go.sum update after running make Co-authored-by: Anthony Mirabella <a9@aneurysm9.com> Co-authored-by: Robert Pająk <pellared@hotmail.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com> Co-authored-by: Chris Bandy <bandy.chris@gmail.com> |
||
---|---|---|
.. | ||
utils | ||
aggregation_test.go | ||
aggregation.go | ||
bridge_test.go | ||
bridge.go | ||
doc.go | ||
exporter_test.go | ||
exporter.go | ||
go.mod | ||
go.sum | ||
README.md |
OpenCensus Bridge
The OpenCensus Bridge helps facilitate the migration of an application from OpenCensus to OpenTelemetry.
Caveat about OpenCensus
Installing a metric or tracing bridge will cause OpenCensus telemetry to be exported by OpenTelemetry exporters. Since OpenCensus telemetry uses globals, installing a bridge will result in telemetry collection from all libraries that use OpenCensus, including some you may not expect. For example (#1928), if a client library generates traces with OpenCensus, installing the bridge will cause those traces to be exported by OpenTelemetry.
Tracing
The Problem: Mixing OpenCensus and OpenTelemetry libraries
In a perfect world, one would simply migrate their entire go application --including custom instrumentation, libraries, and exporters-- from OpenCensus to OpenTelemetry all at once. In the real world, dependency constraints, third-party ownership of libraries, or other reasons may require mixing OpenCensus and OpenTelemetry libraries in a single application.
However, if you create the following spans in a go application:
ctx, ocSpan := opencensus.StartSpan(context.Background(), "OuterSpan")
defer ocSpan.End()
ctx, otSpan := opentelemetryTracer.Start(ctx, "MiddleSpan")
defer otSpan.End()
ctx, ocSpan := opencensus.StartSpan(ctx, "InnerSpan")
defer ocSpan.End()
OpenCensus reports (to OpenCensus exporters):
[--------OuterSpan------------]
[----InnerSpan------]
OpenTelemetry reports (to OpenTelemetry exporters):
[-----MiddleSpan--------]
Instead, I would prefer (to a single set of exporters):
[--------OuterSpan------------]
[-----MiddleSpan--------]
[----InnerSpan------]
The bridge solution
The bridge implements the OpenCensus trace API using OpenTelemetry. This would cause, for example, a span recorded with OpenCensus' StartSpan()
method to be equivalent to recording a span using OpenTelemetry's tracer.Start()
method. Funneling all tracing API calls to OpenTelemetry APIs results in the desired unified span hierarchy.
User Journey
Starting from an application using entirely OpenCensus APIs:
- Instantiate OpenTelemetry SDK and Exporters
- Override OpenCensus' DefaultTracer with the bridge
- Migrate libraries individually from OpenCensus to OpenTelemetry
- Remove OpenCensus exporters and configuration
To override OpenCensus' DefaultTracer with the bridge:
import (
octrace "go.opencensus.io/trace"
"go.opentelemetry.io/otel/bridge/opencensus"
"go.opentelemetry.io/otel"
)
tracer := otel.GetTracerProvider().Tracer("bridge")
octrace.DefaultTracer = opencensus.NewTracer(tracer)
Be sure to set the Tracer
name to your instrumentation package name instead of "bridge"
.
Incompatibilities
OpenCensus and OpenTelemetry APIs are not entirely compatible. If the bridge finds any incompatibilities, it will log them. Incompatibilities include:
- Custom OpenCensus Samplers specified during StartSpan are ignored.
- Links cannot be added to OpenCensus spans.
- OpenTelemetry Debug or Deferred trace flags are dropped after an OpenCensus span is created.
Metrics
The problem: mixing libraries without mixing pipelines
The problem for monitoring is simpler than the problem for tracing, since there are no context propagation issues to deal with. However, it still is difficult for users to migrate an entire applications' monitoring at once. It should be possible to send metrics generated by OpenCensus libraries to an OpenTelemetry pipeline so that migrating a metric does not require maintaining separate export pipelines for OpenCensus and OpenTelemetry.
The Exporter "wrapper" solution
The solution we use here is to allow wrapping an OpenTelemetry exporter such that it implements the OpenCensus exporter interfaces. This allows a single exporter to be used for metrics from both OpenCensus and OpenTelemetry.
User Journey
Starting from an application using entirely OpenCensus APIs:
- Instantiate OpenTelemetry SDK and Exporters.
- Replace OpenCensus exporters with a wrapped OpenTelemetry exporter from step 1.
- Migrate libraries individually from OpenCensus to OpenTelemetry
- Remove OpenCensus Exporters and configuration.
For example, to swap out the OpenCensus logging exporter for the OpenTelemetry stdout exporter:
import (
"go.opencensus.io/metric/metricexport"
"go.opentelemetry.io/otel/bridge/opencensus"
"go.opentelemetry.io/otel/exporters/stdout"
"go.opentelemetry.io/otel"
)
// With OpenCensus, you could have previously configured the logging exporter like this:
// import logexporter "go.opencensus.io/examples/exporter"
// exporter, _ := logexporter.NewLogExporter(logexporter.Options{})
// Instead, we can create an equivalent using the OpenTelemetry stdout exporter:
openTelemetryExporter, _ := stdout.New(stdout.WithPrettyPrint())
exporter := opencensus.NewMetricExporter(openTelemetryExporter)
// Use the wrapped OpenTelemetry exporter like you normally would with OpenCensus
intervalReader, _ := metricexport.NewIntervalReader(&metricexport.Reader{}, exporter)
intervalReader.Start()