-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update OTLP exporter configuration to conform to the specification #1085
Comments
I'll try to push it forward. |
This is waiting on a review & merge from @MrAlias |
The code for this issue and #1121 and #1122 is here: https://github.com/krnowak/opentelemetry-go/tree/otlp-conn |
This seems to be unblocked. I would be great if the Golang version adheres to the spec 😄 I was investigating how the 2021 way of doing metrics should be, found OpenTelemetry, and following the DataDog guide they mention using The saddest part is that every individual developer needs to discover this from the source (I searched for |
@hermanbanken we are happy to accept contributions if you are looking to work on this issue. Please let me know if I can assign it to you. Also, please take a look at the linked project. It contains all the things the contributors of this project are working hard to resolve and release a compliant implementation of the 1.0.1 specification. |
I came across some questions when implementing this. The specs defines that one could configure the exporter protocol, i.e., one could change between gRPC, http/proto and http/json via a config or env variable. But, currently, we have separated exporters implementation for gRPC and HTTP ( Since both exporters do implements the OTLP exporter interface, we could unify the configurations and choose which implementation should be used based on Would it be a problem to have configurations that only works when a specific implementation used? We could see this the same as some configs that overrides others, e.g, the |
@paivagustavo it looks like that environment variable and configuration option moved to a "reserved" status, making the current requirements (1.1.0 of the spec):
I think this means we can punt on answer this question for now. |
At least, that is my reading of this section. |
I'm confused... |
@calbot Check the package documentation of the OTLP exporters. |
Thanks for your response... |
The following configuration options and the interpreted environment variables need to be implemented to support the specification
example.com/v1/traces
).localhost:55680
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_SPAN_ENDPOINT
OTEL_EXPORTER_OTLP_METRIC_ENDPOINT
grpc
,http/json
,http/proto
.grpc
OTEL_EXPORTER_OTLP_PROTOCOL
OTEL_EXPORTER_OTLP_SPAN_PROTOCOL
OTEL_EXPORTER_OTLP_METRIC_PROTOCOL
grpc
orhttp
connection.false
OTEL_EXPORTER_OTLP_INSECURE
OTEL_EXPORTER_OTLP_SPAN_INSECURE
OTEL_EXPORTER_OTLP_METRIC_INSECURE
insecure
is set tofalse
.OTEL_EXPORTER_OTLP_CERTIFICATE
OTEL_EXPORTER_OTLP_SPAN_CERTIFICATE
OTEL_EXPORTER_OTLP_METRIC_CERTIFICATE
OTEL_EXPORTER_OTLP_HEADERS
OTEL_EXPORTER_OTLP_SPAN_HEADERS
OTEL_EXPORTER_OTLP_METRIC_HEADERS
gzip
OTEL_EXPORTER_OTLP_COMPRESSION
OTEL_EXPORTER_OTLP_SPAN_COMPRESSION
OTEL_EXPORTER_OTLP_METRIC_COMPRESSION
OTEL_EXPORTER_OTLP_TIMEOUT
OTEL_EXPORTER_OTLP_SPAN_TIMEOUT
OTEL_EXPORTER_OTLP_METRIC_TIMEOUT
Tasks
The text was updated successfully, but these errors were encountered: