* Do not put span context into go context if extraction failed
This causes problems if multiple trace propagators are chained,
because the first propagator in chain may extract a valid span
context, then next propagator will overwrite it with an empty span
context when required headers in supplier are missing.
* Test for clobbering propagators
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Bump golangci-lint to 1.25
* Skip the "unused" linter when running golangci-lint in --fix mode
This linter seems to provide bogus fix-up information to
golangci-lint, which results in file corruption instead of fixing the
issue. Since we are going to run the linter again anyway, but without
the --fix mode, skip the "unused" linter explicitly for the first run
- it will still have a chance to report errors on the second run.
* Point to the convenience functions in api/key package
This is to increase the visibility of the api/key package through the
api/core package, otherwise developers often tend to miss the api/key
package altogether and write `core.Key(name).TYPE(value)` and complain
at the verbosity of such a construction. The api/key package would
allow them to write `key.TYPE(name, value)`.
* Use the api/key package where applicable
This transforms all the uses of `core.Key(name).TYPE(value)` to
`key.TYPE(name, value)`. This also should help increasing the
visibility of the api/key package for developers reading the otel-go
code.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Make pre_release.sh script work with GNU
The `-i` sed flag is for doing in-place updates of the file. On some
systems it requires a parameter, on other (GNU) the parameter is
optional, but should be "glued" to the flag (`-i.bak` for example).
That's is problematic, so just emulate the in-place updates with
copies and removals.
* Update the version string in sdk with the pre-release script
This was a missing step, which is why we still have a version string
"0.2.3" while in reality it should be "0.3.0". Hopefully it will be
something to fix in "0.3.1" or what the next release version will be.
* Ensure clean git state when doing a release
The script does `git add .` which adds everything in the tree, even
the untracked files. Make sure that there are none of those.
* Temporarily opt-out export.Labels from label encoding stuff
* Stop passing label encoding stuff to export.Labels
* Drop label encoding stuff from SDK
* Dogstatd exporter does not need to implement label exporter anymore
* more dogstatd exporter fixes
* export labels get back to encoding stuff
in a lame way, but improvements are coming in following commits
* Get encoded labels through export.Labels
* make SDK to provide its own implementation of export.Labels
* drop dead code
* add noop label exporter
* make export simple labels immutable
* Move the default label encoder to export package
* Simplify the simple export labels a bit
* Reserve some label exporter IDs
* Document and shuffle the code a bit
* Prepare for bring the iterator benchmark test back
We can install a callback to the Batcher's process function - this is
the place where we can access the labels, and thus test the label
iterator.
* Bring back the iterator benchmarks
* Simplifications and docs
* Fix copyright to be consistent with the rest
* Fix typo
* Put reserved label encoder IDs into constants
We get fewer comments about magic numbers that way.
* Fix the label encoder as label exporter thinko
The `checkpoint` function is executed in a single thread so we can do
the encoding lazily before passing the encoded version of labels to
the exporter. This is a cheap and quick way to avoid encoding the
labels on every collection interval.
Co-authored-by: Rahul Patel <rahulpa@google.com>
* 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
* Add zipkin exporter
The zipkin exporter implements the SpanBatcher interface. It follows
the current-at-the-time-of-writing document about conversion from
OpenTelemetry span data to Zipkin spans. Which means that endpoint
information is not yet filled.
* Fix typo in docs
* Add a zipkin example
This sends span information to a locally running zipkin collector.
Currently I have a problem getting the collector to show me the spans
after accepting them with HTTP 202. Not sure if this is because of
missing endpoint information.
* Make gitignore consistent
The fixed paths should be prefixed with a slash. The "relative" paths
mean that git will ignore all the files that end with the path.
* Add tests for zipkin exporter
* Propagate context changes in mix tests
We will need this for testing the correlation context and baggage
items propagation between the APIs.
* Add baggage interoperation tests
The test adds a baggage item to active OT span and some correlation
key value to current Otel span. Then makes sure that the OT span
contains both the baggage item and some translated version of the
correlation key value its Otel sibling got, and that the Otel span
contains both the correlation key value and the baggage item its OT
sibling got.
* Add hooks functionality to baggage propagation
This introduces two kinds of hooks into the correlation context
code.
The set hook gets called every time we set a Map in the context. The
hook receives a context with the Map and returns a new context.
The get hook gets called every time we get a Map from the context. The
hook receives the context and the map, and returns a new Map.
These hooks will be used for correlation context and baggage items
propagation between the Otel and OT APIs.
* Warn on foreign opentracing span
* fixup for using otel propagators
* Add utility function for setting up bridge and context
This prepares the context by installing the hooks, so the correlation
context and baggage items can be propagated between the APIs.
* Add bridge span constructor
So I do not need to remember about initializing a newly added member
in several places now.
* Propagate baggage across otel and OT APIs
This uses the set hook functionality to propagate correlation context
changes from Otel to OT spans by inserting keys and values into the
baggage items. The get hook functionality is used to propagate baggage
items from active OT span into the otel correlation context.
* Use correlation Map for baggage items
We will put this map into the context with correlation context
functions, and that is easier if we have correlation.Map, not
map[string]string.
* Use otel propagators in bridge
The otel propagators are now kinda sorta usable for opentracing
bridge. Some more work is needed to make it fully work, though -
correlation context set with the otel API is not propagated to OT
spans as baggage items yet.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Drop bogus comment, fix typo
A result of copy-pasting.
* Unexport HTTP header constants
* Rename instruments in tests
"ajwaj" is my favourite placeholder text, but seems like I forgot to
replace its occurences with proper names.
Co-authored-by: Rahul Patel <rghetia@yahoo.com>
It would be nice to follow a single schema for naming context
functions. In the trace package we followed the form FooFromContext
and ContextWithFoo. Do the same in the correlation package. The schema
WithFoo is mainly used for functions following the options pattern.
Not sure about a name of the NewContext function, though. For now I
have left it alone.
Co-authored-by: Rahul Patel <rghetia@yahoo.com>
This bumps the tools we use during build and linting to latest
versions in hope of fixing an annoying warning I was often getting
during linting.
The warnings I was getting were for example:
WARN [runner] Can't run linter goanalysis_metalinter: ctrlflow: failed
prerequisites: inspect@go.opentelemetry.io/otel/exporter/metric/stdout
[go.opentelemetry.io/otel/sdk/metric.test]
WARN [runner] Can't run linter goanalysis_metalinter: fact_purity:
failed prerequisites:
buildssa@go.opentelemetry.io/otel/internal/metric
[go.opentelemetry.io/otel/api/metric.test]
* Test for a panic inside global internal meter instrument's Unbind
* Fix a possible nil-dereference crash
There is a nil dereference crash if we perform some operations in
certain order:
- get a global meter
- create an instrument
- bind it
- set the delegate
- unbind the instrument
- call some recording function on the not-really-bound-anymore
instrument
Unbind will run the no op run-once initialization routine, so the
follow-up RecordOne call will not run it's initialization
routine. Which RecordOne's initialization routine being skipped, the
delegate to bounded instrument is not set, but the code is still
trying to get a pointer to it and then unconditionally dereference it.
Add an extra check for a nil pointer - if this is true, then Unbind
was first and RecordOne should effectively be a no op.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
Correlation context propagation shouldn't be a part of the trace
package - it is a different aspect of the propagation cross-cutting
concern.
This commit also adds a DefaultHTTPPropagator function for correlation
context propagation and makes the plugins use it.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
When during determining a parent for a new span, we find out that
there is a current span in the context, we are putting a remote span
context into links as an ignored on demand. A problem with this
approach is that the remote span context will end up in links of every
descendant span. Another problem is that jaeger exporter currently
treats all links as span contexts with a "child of" relationship and
that likely confuses the jaeger visualization.
* Remove binary propagators
They are in process of being dropped from the specification and we
haven't be using them anywhere in the project. Can reintroduce them
later.
* Rename Supplier to HTTPSupplier
The supplier is used only in HTTP propagators currently. It's not
clear if it will be useful for binary propagators if they get to be
specified at some point.
* Rework propagation interfaces
The biggest change here is that HTTP extractors return a new context
with whatever information the propagator is able to retrieve from the
supplier. Such interface does not hardcode any extractor's
functionality (like it was before by explicitly returning a span
context and correlation context) and makes it easy to chain multiple
propagators.
Injection part hasn't changed.
* Add Propagators interface
This interface (and its default implementation) is likely going to be
the propagation API used the most. Single injectors, extractors or
propagators are likely going to be used just as parameters to the
Option functions that configure the Propagators implementation.
* Drop noop propagator
It's rather pointless - just create an empty Propagators instance.
* Fix wrong name in docs
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
CircleCI has golang images without the patch versions which contain
the latest patch version of golang. That way we do not need to
remember to update the CI config on every patch release.
This PR removes the non-compliant ChildOf and FollowsFrom interfaces
and the Relation type, which were inherited from OpenTracing via the
initial prototype. Instead allow adding a span context to the go
context as a remote span context and use a simple algorithm for
figuring out an actual parent of the new span, which was proposed for
the OpenTelemetry specification.
Also add a way to ignore current span and remote span context in go
context, so we can force the tracer to create a new root span - a span
with a new trace ID.
That required some moderate changes in the opentracing bridge - first
reference with ChildOfRef reference type becomes a local parent, the
rest become links. This also fixes links handling in the meantime. The
downside of the approach proposed here is that we can only set the
remote parent when creating a span through the opentracing API.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Drop entry from correlation map
Entry used to contain stuff like TTL, but right now the notion of
entry was dropped from the spec.
* Compute exact size of the correlations map
The map will be immutable, so spend some more time to ensure that we
will not unnecessarily waste some memory on a basically read-only map.
* Allow dropping keys from correlations map
This is to follow the spec. Before this change it was possible in an
awkward way by using Foreach to gather and filter the key-value pairs,
and then calling NewMap with a MultiKV MapUpdate.
* Document the correlation package
* Add missing license blurbs in correlation package
* Add tests for deleting items in correlations
* Factor out getting map size and test it
This is an implementation detail that can't be tested in a black-box
manner.
* Fix copyright dates
* Simplify/disambiguate keySet function parameters/return values
* Fix typo in Apply docs
* Fix test names
* Explain the nonsense of dropping keys from new map
* Remove Vendor constants from tracing plugins
Unused. And confusing, since "ot" may mean "opentracing" as well.
* Simplify current span key declaration
No need for a block.
* Fix typo
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Rename distributedcontext package to correlation
Correlation is the name we agreed upon.
* Move trace propagators to api/trace
The trace propagators tests had to be moved to a testtrace subpackage
to avoid import cycles between api/trace and internal/trace.
Needed to shut up golint about stutter in trace.TraceContext -
TraceContext is a name of a W3C spec, so this stutter is
expected. It's certainly still better than golint's suggestion of
having trace.Context.
* Rename api/propagators to api/propagation
This package will not contain any propagators in the long run, just
the interface definitions.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Generate and build before linting
Generated files may require some formatting that happens during
linting. Also missing generated files may result in linter failures.
Building can shake out any syntax/semantic errors and report them in a
much nicer way than the linter does. Which is exactly the reason the
build was running before linters before the Makefile simplification.
* Make stringer tool a dep of generate target, not lint
Lint target does not use the stringer utility - it is being used by go
generate.
* shrink the value type
went down from 40 bytes to 24
* add missing license blurb
* stringify value type
* print string value types in stdout exporter
* make Value function take a pointer receiver
golangci-lint runs its checks also on tests files, so make sure that
they build properly before running the linter. there is no obvious
solution to just build all the test without running them, so to work
that around, we specify a -run flag with a value that surely isn't
going to match any test function any time soon. that way we build all
the tests, but no test is run.
also, `go list ./...` returns only packages in the module, but no
packages within submodule, so exporter/trace/jaeger (which is a
submodule) was never on the list. so go test with those packages never
ran the jaeger trace exporter tests. fix this by visiting every
directory with the go.mod file and calling go test [options]
./... therein.
golangci-lint just issues an unreadable warning and quits with a
successful exit status on compilation error. just run a round of go
build ./... to catch those as hard errors.
* automate building all the examples
the EXAMPLES variable was out of date - the stackdriver example wasn't
even built
let's automate it, so we don't need to remember about updating the
variable after adding a new example to the examples directory
* move jaeger example to example directory
this should be in the examples directory, so it can be built by the
make test during CI.
* switch to go 1.13
circle ci uses go 1.12 (which is the oldest 1.12 release) that
contains some bugs with module handling
let's switch to go 1.13.3, the latest go currently
* use a single valid revision of the project in go.mod files
this probably shouldn't be a problem since the switch to go 1.13 in
circle ci, but cleans up the mess and the use of bogus releases
* move bridge out of the experimental directory
* drop a leftover from experimental stuff in gitignore
found by accident when doing `git grep experimental`.
Jaeger exporter was replaced with stdout exporter in the example, so
update the README to reflect that. Also drop the screenshot - it's not
referenced anywhere.
* Update metrics API to match current spec
* update options to match the spec
* drop the global meter API
* more docs
* get rid of leftover mentions about descriptor
* Add a document about contributing
It is shamelessly stolen from opentelemetry-python and edited to be
relevant to opentelemetry-go. This file should explain some less
obvious things about the development of the project, like running
linters and regenerating the files.
* Force the use of go modules
Until go 1.13 modules were disabled by default if the repository was
inside GOPATH. This was causing issues when running `make precommit`
for the first time, as it could not find sources for any of the tools
used in `make precommit` under `${GOPATH}/src`. With setting the
`GO111MODULE` environment variable to `on`, we tell `go` to behave
differently, just like go 1.13 does by default.
* Drop dead event type
* Replace EventType from reader with one from exporter
* Do not concat the strings for string buffer
* Fill scope ID in events
That required renaming a variable, because it had the same name as the
type we wanted to assert later.
* Do not fail quietly when span context is busted
* Allow specifying custom timestamps for events
Adding event with timestamp is not yet a part of the OpenTelemetry
specification, but this function will come in handy when implementing
the OpenTracing bridge.
* Add opentracing bridge, wrapper tracer and migration interfaces
There are some features missing - setting up links and span kind;
context propagation will only work between two OpenTracing bridges.
* Add some tests for the opentracing bridge
The tests mostly check various aspects of the cooperation between
OpenTracing and OpenTelemetry APIs.
This is to shrink the PR #100.
The only place where the registry.Variable type was used was metrics,
so just inline that type into its only user. The use of the
registry.Variable type in core.Key was limited to the Name field.
The stats package also used the registry.Variable type, but seems that
also only the Name field was used and the package is going to be
dropped anyway.
* Merge two event methods in span API
There was an agreement to get rid of the Event interface and
consolidate the two methods for adding events into one. See #57.
* Eliminate the use of the Event interface
There is no need for the SDK to provide the implementation of the
Event interface - it is used nowhere.
* Drop the Event interface
It's dead code now.
* Make it possible to override a finish timestamp through options
Opentracing to opentelemetry bridge will certainly use this feature.
* Obey the start time option
* Add tests for events and custom start/end times
This is to make tag.Map an immutable type, so it is safe to use
concurrently. The safety is not yet fully achieved because of the
functions returning contents of the map (Value and Foreach). The
functions give callers an access to core.Value objects, which contain
a byte slice, which has pointer like semantics. So to avoid accidental
changes, we will need to copy the value if it is of BYTES type.
Fixes#59
It was printing an ID of the created span instead. Also drop the if
clause checking if span has a parent span ID - we know at this point
that the condition is always true.
* Run go generate in the precommit target
So we should always get an updated version of a file generated by a
stringer utility.
* Update the generated file
* Make CI to fail if working tree has uncommited changes
The uncommitted changes may come from the golang linter (that formats
our code among other things) and from stringer (when updated some
enumeration).
Krzesimir Nowak
