* Move grpc stuff to separate package
* Drop duplicated retryable status code
* Set default port to 4317
This is what the specification says for both gRPC and HTTP.
* Document gRPC option type
* Add an HTTP protocol driver for OTLP exporter
Currently it supports only binary protobuf payloads.
* Move end to end test to a separate package
It also adds some common code mock collectors can use. This will be
useful for testing the HTTP driver.
* Move export data creators to otlptest
It also extends the one record checkpointer a bit. This will be useful
for testing the HTTP driver.
* Add an HTTP mock collector and tests for HTTP driver
* Update changelog
* Do not depend on DefaultTransport
We create our own instance of the transport, which is based on
golang's DefaultTransport. That way we sidestep the issue of the
DefaultTransport being modified/overwritten. We won't have any panics
at init. The cost of it is to keep the transport fields in sync with
DefaultTransport.
* Read the whole response body before closing it
This may help with connection reuse.
* Change options to conform to our style guide
* Add jitter to backoff time
* Test TLS option
* Test extra headers
* Fix a comment
* Increase coverage
* Add a source of the backoff strategy
* Add Tracestate into the SamplingResult struct
Add `trace.Tracestate` field into the SDK `trace.SamplingResult` struct.
Use ParentContext from SamplingParameters to return Tracestate in
`traceIDRatioSampler`, `alwaysOnSampler` and `alwaysOffSampler`.
Add a new test to check that Tracestate is passed.
* Updated CHANGELOG.md for #1432 PR
Added changes description for #1432.
* Update sdk/trace/sampling_test.go
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Rename `otlp.WithAddress` to `otlp.WithEndpoint`
* Unify the term of the endpoint from exporter
* Update CHANGELOG
* Update example/otel-collector/main.go
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Switch to the full word collector
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Co-authored-by: Tyler Yahn <codingalias@gmail.com>
* Add a split protocol driver
This is a wrapper around two other protocol drivers, so it makes it
possible to send traces using a different protocol than the one used
for metrics.
* Add an example and tests for multi GRPC endpoint driver
* Update changelog
* Document the split driver
* Add TraceState to API
* Add tests for TraceState
* Update related tests
- stdout exporter test
- SDK test
* Update OTLP span transform
* Update CHANGELOG
* Change TraceState to struct instead of pointer
- Adjust tests for trace API
- Adjust adjacent parts of codebase (test utils, SDK etc.)
* Add methods to assert equality
- for type SpanContext, if SpanID, TraceID, TraceFlag and TraceState are
equal
- for type TraceState, if entries of both respective trace states are
equal
Signed-off-by: Matej Gera <matejgera@gmail.com>
* Copy values for new TraceState, adjust tests
* Use IsEqualWith in remaining tests instead of assertion func
* Further feedback, minor improvements
- Move IsEqualWith method to be only in test package
- Minor improvements, typos etc.
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Split protocol handling away from exporter
This commits adds a ProtocolDriver interface, which the exporter
will use to connect to the collector and send both metrics and traces
to it. That way, the Exporter type is free from dealing with any
connection/protocol details, as this business is taken over by the
implementations of the ProtocolDriver interface.
The gRPC code from the exporter is moved into the implementation of
ProtocolDriver. Currently it only maintains a single connection,
just as the Exporter used to do.
With the split, most of the Exporter options became actually gRPC
connection manager's options. Currently the only option that remained
to be Exporter's is about setting the export kind selector.
* Update changelog
* Increase the test coverage of GRPC driver
* Do not close a channel with multiple senders
The disconnected channel can be used for sending by multiple
goroutines (for example, by metric controller and span processor), so
this channel should not be closed at all. Dropping this line closes a
race between closing a channel and sending to it.
* Simplify new connection handler
The callbacks never return an error, so drop the return type from it.
* Access clients under a lock
The client may change as a result on reconnection in background, so
guard against a racy access.
* Simplify the GRPC driver a bit
The config type was exported earlier to have a consistent way of
configuring the driver, when also the multiple connection driver would
appear. Since we are not going to add a multiple connection driver,
pass the options directly to the driver constructor. Also shorten the
name of the constructor to `NewGRPCDriver`.
* Merge common gRPC code back into the driver
The common code was supposed to be shared between single connection
driver and multiple connection driver, but since the latter won't be
happening, it makes no sense to keep the not-so-common code in a
separate file. Also drop some abstraction too.
* Rename the file with gRPC driver implementation
* Update changelog
* Sleep for a second to trigger the timeout
Sometimes CI has it's better moments, so it's blazing fast and manages
to finish shutting the exporter down within the 1 microsecond timeout.
* Increase the timeout for shutting down the exporter
One millisecond is quite short, and I was getting failures locally or
in CI:
go test ./... + race in ./exporters/otlp
2020/12/14 18:27:54 rpc error: code = Canceled desc = context canceled
2020/12/14 18:27:54 context deadline exceeded
--- FAIL: TestNewExporter_withMultipleAttributeTypes (0.37s)
otlp_integration_test.go:541: resource span count: got 0, want 1
FAIL
FAIL go.opentelemetry.io/otel/exporters/otlp 5.278s
or
go test ./... + coverage in ./exporters/otlp
2020/12/14 17:41:16 rpc error: code = Canceled desc = context canceled
2020/12/14 17:41:16 exporter disconnected
--- FAIL: TestNewExporter_endToEnd (1.53s)
--- FAIL: TestNewExporter_endToEnd/WithCompressor (0.41s)
otlp_integration_test.go:246: span counts: got 3, want 4
2020/12/14 17:41:18 context canceled
FAIL
coverage: 35.3% of statements in ./...
FAIL go.opentelemetry.io/otel/exporters/otlp 4.753s
* Shut down the providers in end to end test
This is to make sure that all batched spans are actually flushed
before closing the exporter.
* migrating CircleCI jobs to GitHub Actions
* using container matrix instead
* prevent entire workflow from stopping if one go version job fails
* updating github ci to use setup-go
* updating changelog
* Call otel.Handle with non-nil errors
That's what normally happens in other call sites. Those two didn't
check it, but passed the "error" to Handle. The default, delegating
implementation of ErrorHandler was printing the error unconditionally,
which resulted in pointless lines like `2020/12/07 19:51:28 <nil>` in
demos, for example.
* Add tests
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Store span data directly in the span
- Nesting only some of a span's data in a `data` field (with the rest
of the data living direclty in the `span` struct) is confusing.
- export.SpanData is meant to be an immutable *snapshot* of a span,
not the "authoritative" state of the span.
- Refactor attributesMap.toSpanData into toKeyValue and make it
return a []label.KeyValue which is clearer than modifying a struct
passed to the function.
- Read droppedCount from the attributesMap as a separate operation
instead of setting it from within attributesMap.toSpanData.
- Set a span's end time in the span itself rather than in the
SpanData to allow reading the span's end time after a span has
ended.
- Set a span's end time as soon as possible within span.End so that
we don't influence the span's end time with operations such as
fetching span processors and generating span data.
- Remove error handling for uninitialized spans. This check seems to
be necessary only because we used to have an *export.SpanData field
which could be nil. Now that we no longer have this field I think we
can safely remove the check. The error isn't used anywhere else so
remove it, too.
* Store parent as trace.SpanContext
The spec requires that the parent field of a Span be a Span, a
SpanContext or null.
Rather than extracting the parent's span ID from the trace.SpanContext
which we get from the tracer, store the trace.SpanContext as is and
explicitly extract the parent's span ID where necessary.
* Add ReadOnlySpan interface
Use this interface instead of export.SpanData in places where reading
information from a span is necessary. Use export.SpanData only when
exporting spans.
* Add ReadWriteSpan interface
Use this interface instead of export.SpanData in places where it is
necessary to read information from a span and write to it at the same
time.
* Rename export.SpanData to SpanSnapshot
SpanSnapshot represents the nature of this type as well as its
intended use more accurately.
Clarify the purpose of SpanSnapshot in the docs and emphasize what
should and should not be done with it.
* Rephrase attributesMap doc comment
"refreshes" is wrong for plural ("updates").
* Refactor span.End()
- Improve accuracy of span duration. Record span end time ASAP. We
want to measure a user operation as accurately as possible, which
means we want to mark the end time of a span as soon as possible
after span.End() is called. Any operations we do inside span.End()
before storing the end time affect the total duration of the span,
and although these operations are rather fast at the moment they
still seem to affect the duration of the span by "artificially"
adding time between the start and end timestamps. This is relevant
only in cases where the end time isn't explicitly specified.
- Remove redundant idempotence check. Now that IsRecording() is based
on the value of span.endTime, IsRecording() will always return
false after span.End() had been called because span.endTime won't
be zero. This means we no longer need span.endOnce.
- Improve TestEndSpanTwice so that it also ensures subsequent calls
to span.End() don't modify the span's end time.
* Update changelog
Co-authored-by: Tyler Yahn <codingalias@gmail.com>
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Let SynchronizedMove(nil) reset and discard
* Add common test for SynchronizedMove(nil)
* End-to-end test for the Processor and SumObserver
* Implement SynchronizedMove(nil) six ways
* Lint
* Changelog
* Test no reset for wrong aggregator type; Fix four Aggregators
* Cleanup
* imports
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Enable support for externally-defined ID generators
* Moved the SDK's `internal.IDGenerator` interface to the `sdk/trace`
package.
* Added `trace.WithIDGenerator()` `TracerProviderOption`.
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Update CHANGELOG.md with PR info
* Address PR feedback:
* Fix IDGenerator godoc comment
* rename type defaultIDGenerator to randomIDGenerator
* rename defIDGenerator() to defaultIDGenerator()
Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com>
* Rework trace.IDGenerator interface
* NewTraceID() -> NewIDs(ctx)
** Returns both TraceID and SpanID
* NewSpanID() -> NewSpanID(ctx, traceID)
** Returns only SpanID, has access to TraceID
* Both methods now receive a context, from which they may extract
information
* startSpanInternal() updated to receive a context to pass to the ID
generator
* Drop outdated comment from docblock
Co-authored-by: Krzesimir Nowak <qdlacz@gmail.com>
Co-authored-by: Krzesimir Nowak <qdlacz@gmail.com>
* Rework proto generation
The changes here are:
- Fix the default goal (using "default" target is not doing it).
- Bail out with a useful message if proto submodule is not checked
out.
- Replace the use of docker image with downloading the protoc binary
and building the gogofast plugin ourselves. This gives us a greater
control over the invocation of protoc.
- Use rsync to copy the generated code, instead of pax. Pax did not
work for me (it was complaining about the unknown -0 flag).
The control over the protoc invocation will be useful later, when we
will want to generate a code with data structures in one place and the
collector code elsewhere. The collector code may or may not depend on
gRPC, but data structures have no need for it. This split will happen
when we move the gRPC code out of the OTLP exporter module into a
submodule.
Getting rid of docker has the upside that the generated files do not
belong to root, so there is no hassle of changing the ownership of the
files, and it is not requires to use sudo for the `clean` target. And
not using docker is faster.
The downside of this work is that it depends on more tools: rsync,
unzip and wget. I can only hope that macOS users have those tools too,
and that those tools are invoked the same.
* Update protogen workflow
* chore(zipkin-exporter): relay on the status code for the request but still read the response body.
* fix(zipkin-exporter): fix tests.
* chore(zipkin-exporter): adds changelog.
* chore: 202 -> http.StatusAccepted
Co-authored-by: Chris Bandy <bandy.chris@gmail.com>
* chore: 202 -> http.StatusAccepted
Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>
Co-authored-by: Chris Bandy <bandy.chris@gmail.com>
Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Examples are "leaf" packages, that pull some other packages. So build
the other packages first to get and fix all the errors there, before
building the examples.
* Move connection logic into grpcConnection object
If we will need to maintain more than one connection in future, this
splitting off will come in handy.
Co-authored-by: Stefan Prisca <stefan.prisca@gmail.com>
* Make another channel a signal channel
There is another channel that serves as a one-time signal, where
channel's data type does not matter.
* Reorder and document connection members
This is to make clear that the lock is guarding only the connection
since it can be changed by multiple goroutines, and other members are
either atomic or read-only.
* Move stop signal into connection
The stop channel was rather useless on the exporter side - the primary
reason for existence of this channel is to stop a background
reconnecting goroutine. Since the goroutine lives entirely within
grpcConnection object, move the stop channel here. Also expose a
function to unify the stop channel with the context cancellation, so
exporter can use it without knowing anything about stop channels.
Also make export functions a bit more consistent.
* Do not run reconnection routine when being stopped too
It's possible that both disconnected channel and stop channel will be
triggered around the same time, so the goroutine is as likely to start
reconnecting as to return from the goroutine. Make sure we return if
the stop channel is closed.
* Nil clients on connection error
Set clients to nil on connection error, so we don't try to send the
data over a bad connection, but return a "no client" error
immediately.
* Do not call new connection handler within critical section
It's rather risky to call a callback coming from outside within a
critical section. Move it out.
* Add context parameter to connection routines
Connecting to the collector may also take its time, so it can be
useful in some cases to pass a context with a deadline. Currently we
just pass a background context, so this commit does not really change
any behavior. The follow-up commits will make a use of it, though.
* Add context parameter to NewExporter and Start
It makes it possible to limit the time spent on connecting to the
collector.
* Stop connecting on shutdown
Dialling to grpc service ignored the closing of the stop channel, but
this can be easily changed.
* Close connection after background is shut down
That way we can make sure that there won't be a window between closing
a connection and waiting for the background goroutine to return, where
the new connection could be established.
* Remove unnecessary nil check
This member is never nil, unless the Exporter is created like
&Exporter{}, which is not a thing we support anyway.
* Update changelog
Co-authored-by: Stefan Prisca <stefan.prisca@gmail.com>
