a01f63bec4
* Do not expose a slice of labels in export.Record This is really an inconvenient implementation detail leak - we may want to store labels in a different way. Replace it with an iterator - it does not force us to use slice of key values as a storage in the long run. * Add Len to LabelIterator It may come in handy in several situations, where we don't have access to export.Labels object, but only to the label iterator. * Use reflect value label iterator for the fixed labels * add reset operation to iterator Makes my life easier when writing a benchmark. Might also be an alternative to cloning the iterator. * Add benchmarks for iterators * Add import comment * Add clone operation to label iterator * Move iterator tests to a separate package * Add tests for cloning iterators * Pass label iterator to export labels * Use non-addressable array reflect values By not using the value created by `reflect.New()`, but rather by `reflect.ValueOf()`, we get a non-addressable array in the value, which does not infer an allocation cost when getting an element from the array. * Drop zero iterator This can be substituted by a reflect value iterator that goes over a value with a zero-sized array. * Add a simple iterator that implements label iterator In the long run this will completely replace the LabelIterator interface. * Replace reflect value iterator with simple iterator * Pass label storage to new export labels, not label iterator * Drop label iterator interface, rename storage iterator to label iterator * Drop clone operation from iterator It's a leftover from interface times and now it's pointless - the iterator is a simple struct, so cloning it is a simple copy. * Drop Reset from label iterator The sole existence of Reset was actually for benchmarking convenience. Now we can just copy the iterator cheaply, so a need for Reset is no more. * Drop noop iterator tests * Move back iterator tests to export package * Eagerly get the reflect value of ordered labels So we won't get into problems when several goroutines want to iterate the same labels at the same time. Not sure if this would be a big deal, since every goroutine would compute the same reflect.Value, but concurrent write to the same memory is bad anyway. And it doesn't cost us any extra allocations anyway. * Replace NewSliceLabelIterator() with a method of LabelSlice * Add some documentation * Documentation fixes
OpenTelemetry-Go
The Go OpenTelemetry client.
Installation
This repository includes multiple packages. The api
package contains core data types, interfaces and no-op implementations that comprise the OpenTelemetry API following
the
specification.
The sdk package is the reference implementation of the API.
Libraries that produce telemetry data should only depend on api
and defer the choice of the SDK to the application developer. Applications may
depend on sdk or another package that implements the API.
All packages are published to go.opentelemetry.io/otel and is the preferred location to import from.
Additional resources:
Quick Start
Below is a brief example of importing OpenTelemetry, initializing a tracer and creating some simple spans.
package main
import (
"context"
"log"
"go.opentelemetry.io/otel/api/global"
"go.opentelemetry.io/otel/exporters/trace/stdout"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
)
func initTracer() {
exporter, err := stdout.NewExporter(stdout.Options{PrettyPrint: true})
if err != nil {
log.Fatal(err)
}
tp, err := sdktrace.NewProvider(sdktrace.WithConfig(sdktrace.Config{DefaultSampler: sdktrace.AlwaysSample()}),
sdktrace.WithSyncer(exporter))
if err != nil {
log.Fatal(err)
}
global.SetTraceProvider(tp)
}
func main() {
initTracer()
tracer := global.Tracer("ex.com/basic")
tracer.WithSpan(context.Background(), "foo",
func(ctx context.Context) error {
tracer.WithSpan(ctx, "bar",
func(ctx context.Context) error {
tracer.WithSpan(ctx, "baz",
func(ctx context.Context) error {
return nil
},
)
return nil
},
)
return nil
},
)
}
See the API documentation for more detail, and the opentelemetry-example-app for a complete example.
Compatible Exporters
See the Go packages depending upon sdk/export/trace and sdk/export/metric for a list of all exporters compatible with OpenTelemetry's Go SDK.
Contributing
See the contributing file.
Release Schedule
OpenTelemetry Go is under active development. Below is the release schedule for the Go library. The first version of the release isn't guaranteed to conform to a specific version of the specification, and future releases will not attempt to maintain backward compatibility with the alpha release.
| Component | Version | Target Date | Release Date |
|---|---|---|---|
| Tracing API | Alpha v0.1.0 | October 28 2019 | November 05 2019 |
| Tracing SDK | Alpha v0.1.0 | October 28 2019 | November 05 2019 |
| Jaeger Trace Exporter | Alpha v0.1.0 | October 28 2019 | November 05 2019 |
| Trace Context Propagation | Alpha v0.1.0 | Unknown | November 05 2019 |
| OpenTracing Bridge | Alpha v0.1.0 | October | November 05 2019 |
| Metrics API | Alpha v0.2.0 | October 28 2019 | December 03 2019 |
| Metrics SDK | Alpha v0.2.0 | October 28 2019 | December 03 2019 |
| Prometheus Metrics Exporter | Alpha v0.2.0 | October 28 2019 | December 03 2019 |
| Context Prop. rename/Baggage | Alpha v0.3.0 | December 23 2019 | - |
| OpenTelemetry Collector Exporter | Alpha v0.4.0 | January 15 2020 | - |
| Zipkin Trace Exporter | Alpha | Unknown | - |
| OpenCensus Bridge | Alpha | Unknown | - |