* 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
* Update api for Must constructors, with SDK helpers
* Update for Must constructors, leaving TODOs about global errors
* Add tests
* Move Must methods into metric.Must
* Apply the feedback
* Remove interfaces
* Remove more interfaces
* Again...
* Remove a sentence about a dead inteface
* change the histogram aggregator to have a consistent but blocking Checkpoint()
* docs
* wrapping docs
* remove currentIdx from the 8bit alignment check
* stress test
* add export and move lockfreewrite algorithm to an external struct.
* move state locker to another package.
* add todos
* minimal tests
* renaming and docs
* change to context.Background()
* add link to algorithm and grammars
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Use an array key to label encoding in the SDK
* Comment
* Precommit
* Comment
* Comment
* Feedback from krnowak
* Do not overwrite the Key
* Add the value test requested
* Add a comment
* drop gauge instrument
* Restore the benchmark and stress test for lastvalue aggregator, but remove monotonic last-value support
* Rename gauge->lastvalue and remove remaining uses of the word 'gauge'
Co-authored-by: Krzesimir Nowak <krzesimir@kinvolk.io>
* 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>
* Refactor SDK Sampler API to conform to Spec
* Sampler is now an interface rather than a function type
* SamplingParameters include the span Kind, Attributes, and Links
* SamplingResult includes a SamplingDecision with three possible values, as well as Attributes
* Add attributes retruned from a Sampler to the span
* Add SpanKind, Attributes, and Links to API Sampler.ShouldSample() parameters
* Drop "Get" from sdk Sampler.GetDescription to match api Sampler
* Make spanID parameter in API Sampler interface a core.SpanID
* Fix types and printf format per PR feedback from krnowak
* Ensure unit test error messages reflect new reality
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* wip: observers
* wip: float observers
* fix copy pasta
* wip: rework observers in sdk
* small fix in global meter
* wip: aggregators and selectors
* wip: monotonicity option for observers
* some refactor
* wip: docs
needs more package docs (especially for api/metric and sdk/metric)
* fix ci
* Fix copy-pasta in docs
Co-Authored-By: Mauricio Vásquez <mauricio@kinvolk.io>
* recycle unused recorders in observers
if a recorder for a labelset is unused for a second collection cycle
in a row, drop it
* unregister
* thread-safe set callback
* Fix docs
* Revert "wip: aggregators and selectors"
This reverts commit 37b7d05aed5dc90f6d5593325b6eb77494e21736.
* update selector
* tests
* Rework number equality
Compare concrete numbers, so we can get actual numbers in the error
message when they are not equal, not some uint64 representation. This
also uses InDelta for comparing floats.
* Ensure that Observers are registered in the same order
* Run observers in fixed order
So the tests can be reproducible - iterating a map made the order of
measurements random.
* Ensure the proper alignment of the delegates
This wasn't checked at all. After adding the checks, the test-386
failed.
* Small tweaks to the global meter test
* Ensure proper alignment of the callback pointer
test-386 was complaining about it
* update docs
* update a TODO
* address review issues
* drop SetCallback
Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io>
Co-authored-by: Rahul Patel <rghetia@yahoo.com>
* Add global propagators
The default global propagators are set to the chained W3C trace and
correlation context propagators.
* Use global propagators in plugins
The httptrace and grpcplugins should also get some API for setting a
propagator to use (the othttp plugin already has such an API), but
that can come in some other PR.
* Decrease indentation in trace propagators
* Drop obsolete TODOs
Now we do "something" with correlation context - it ends up in the
context, and we put the context into the request, so the chained HTTP
handler can access it too.
The other TODO was about tag.Upsert which is long gone.
* Do not unnecessarily update the request context
The request context already contains the span (and we add some
attribute there), so inserting it into context again is pointless.
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>
The `go.opentelemetry.io/otel/exporter/trace/jaeger` package was
mistakenly released with a `v1.0.0` tag instead of `v0.1.0`. This
resulted in all subsequent releases not becoming the default latest,
meaning that `go get`s pulled in the incompatible `v0.1.0` release of
that package when pulling in more recent packages from other otel
packages. Renaming the `exporter` directory to `exporters` fixes this
issue by consequentially renaming the package.
Additionally, this action also renames *all* exporters. This is
understood to be a disruptive action to existing users as they will need
to update any dependencies they currently have on our exporters.
However, it was decided to take this action regardless. The need to
resolve the existing issue explained above is highly important, and
given the Alpha state of this project these kinds of breaking changes
should be expected (though not without reason).
Resolves#331
Co-authored-by: Rahul Patel <rghetia@yahoo.com>
* Add `Span#Error` method to simplify setting an error status and message.
* `Span#Error` should no-op on nil errors
* Record errors as a span event rather than status/attributes.
The implementation in the SDK package now relies on existing API methods.
* Add WithErrorStatus() ErrorOption to allow setting span status on error.
* Apply suggestions from code review
Co-Authored-By: Krzesimir Nowak <qdlacz@gmail.com>
* Address code review feedback
* Clean up RecordError tests
* Ensure complete and unique error type is recorded for defined types
* Avoid duplicating logic under test in tests
* Move TestError to internal/testing package, improve RecordError test scenarios
Co-authored-by: Krzesimir Nowak <qdlacz@gmail.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>
Tracer.WithSpan() will now accept StartOptions as a variadic final parameter `opts`
that will be passed to the Tracer.Start() invocation that creates the Span
wrapping the user-provided function.
* Refactor metric records logic.
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Fix lint errors
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Fix a bug that we try to readd the old entry instead of a new one.
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Update comments in refcount_mapped.
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Remove the need to use a records list, iterate over the map.
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Fix comments and typos
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Fix more comments
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Clarify tryUnmap comment
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Fix one more typo.
Signed-off-by: Bogdan Cristian Drutu <bogdandrutu@gmail.com>
* Move dependencies of tools package to a tools directory
* remove TOOLS_MOD_DIR from ALL_GO_MOD_DIRS in a Makefile.
then run 'go mod tidy' on ALL_GO_MOD_DIRS and TOOLS_MOD_DIR.
Co-authored-by: Rahul Patel <rghetia@yahoo.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.
The methods on the `Float64Gauge`, `Int64Gauge`, `Float64Counter`,
`Int64Counter`, `Float64Measure`, and `Int64Measure` `struct`s do not
need to mutate the internal state of the `struct` and can therefore be
defined with value receivers instead. This aligns closer to the function
signatures of each instruments constructor function. Additionally, this
change means calls to these methods do not need an allocation to the
heap.
Resolves#440
Co-authored-by: Rahul Patel <rghetia@yahoo.com>
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
