7d92434295
* Fail in RunEndToEndTest if collector stop fails * Use testing T.Cleanup to check shut downs * Add goroutine leak detection * Fix TestExporterShutdown go leak The shutdown tests checking if a context error is honored did not completely clean up the resources used by the client after the error was evaluated. Update the connection client to handle multiple calls to shutdown and make a second call to these clients that must succeed so the test does not have abandoned goroutines. * Fix leak in TestNew_WithTimeout The mockTraceService did not delay with its lock being held. This resulted in the mockCollector stopping and being able to acquire the lock. It was assumed that no export was taking place because of this and the mockTraceService was abandoned without cleaning up resources it held and goroutines it had spawned. This reworks the export blocking logic to block on a channel read. This will make the block more deterministic and not depend on the scheduler timing. Additionally, this blocking is moved inside the lock acquire. Meaning code will deadlock if the block is not released before a shutdown (something the developer will immediately be aware of when they submit a bad patch), and will ensure all resources are released before shutdown. Replace TestNew_WithTimeout with TestExportSpansTimeoutHonored which directly tests if a span export errors when the timeout is reached. This is the only unique thing that TestNew_WithTimeout, but it also tests the non-error path. That non-error path is tested in many other tests. * Guard otlptracehttp client stopCh when stopping In normal operations the exporter is guaranteed to only ever call the client Stop method once. However in testing we need to call this multiple times when checking it returns an error in particular context. Add a lightweight sync.Once to the closing of the stopCh to ensure tests do not panic when cleaning up. * Release export block after export Prevent deadlock in TestExportSpansTimeoutHonored. |
||
|---|---|---|
| .github | ||
| attribute | ||
| baggage | ||
| bridge | ||
| codes | ||
| example | ||
| exporters | ||
| internal | ||
| metric | ||
| propagation | ||
| schema | ||
| sdk | ||
| semconv | ||
| trace | ||
| website_docs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .golangci.yml | ||
| .markdown-link.json | ||
| .markdownlint.yaml | ||
| CHANGELOG.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| doc.go | ||
| error_handler.go | ||
| get_main_pkgs.sh | ||
| go.mod | ||
| go.sum | ||
| handler_test.go | ||
| handler.go | ||
| LICENSE | ||
| Makefile | ||
| pre_release.sh | ||
| propagation.go | ||
| README.md | ||
| RELEASING.md | ||
| tag.sh | ||
| trace_test.go | ||
| trace.go | ||
| verify_examples.sh | ||
| version_test.go | ||
| version.go | ||
| VERSIONING.md | ||
| versions.yaml | ||
OpenTelemetry-Go
OpenTelemetry-Go is the Go implementation of OpenTelemetry. It provides a set of APIs to directly measure performance and behavior of your software and send this data to observability platforms.
Project Status
| Signal | Status | Project |
|---|---|---|
| Traces | Stable | N/A |
| Metrics | Alpha | N/A |
| Logs | Frozen [1] | N/A |
- [1]: The Logs signal development is halted for this project while we develop both Traces and Metrics. No Logs Pull Requests are currently being accepted.
Progress and status specific to this repository is tracked in our local project boards and milestones.
Project versioning information and stability guarantees can be found in the versioning documentation.
Compatibility
This project is tested on the following systems.
| OS | Go Version | Architecture |
|---|---|---|
| Ubuntu | 1.17 | amd64 |
| Ubuntu | 1.16 | amd64 |
| Ubuntu | 1.15 | amd64 |
| Ubuntu | 1.17 | 386 |
| Ubuntu | 1.16 | 386 |
| Ubuntu | 1.15 | 386 |
| MacOS | 1.17 | amd64 |
| MacOS | 1.16 | amd64 |
| MacOS | 1.15 | amd64 |
| Windows | 1.17 | amd64 |
| Windows | 1.16 | amd64 |
| Windows | 1.15 | amd64 |
| Windows | 1.17 | 386 |
| Windows | 1.16 | 386 |
| Windows | 1.15 | 386 |
While this project should work for other systems, no compatibility guarantees are made for those systems currently.
Getting Started
You can find a getting started guide on opentelemetry.io.
OpenTelemetry's goal is to provide a single set of APIs to capture distributed traces and metrics from your application and send them to an observability platform. This project allows you to do just that for applications written in Go. There are two steps to this process: instrument your application, and configure an exporter.
Instrumentation
To start capturing distributed traces and metric events from your application it first needs to be instrumented. The easiest way to do this is by using an instrumentation library for your code. Be sure to check out the officially supported instrumentation libraries.
If you need to extend the telemetry an instrumentation library provides or want to build your own instrumentation for your application directly you will need to use the go.opentelemetry.io/otel/api package. The included examples are a good way to see some practical uses of this process.
Export
Now that your application is instrumented to collect telemetry, it needs an export pipeline to send that telemetry to an observability platform.
All officially supported exporters for the OpenTelemetry project are contained in the exporters directory.
| Exporter | Metrics | Traces |
|---|---|---|
| Jaeger | ✓ | |
| OTLP | ✓ | ✓ |
| Prometheus | ✓ | |
| stdout | ✓ | ✓ |
| Zipkin | ✓ |
Additionally, OpenTelemetry community supported exporters can be found in the contrib repository.
Contributing
See the contributing documentation.