OTLP exporter should be packaged separately per protocol
See original GitHub issueCurrently the opentelemetry-exporter-otlp
only supports protobufs over gRPC. Once there’s support for protobuf over http and json over http, we should have a separate package for each to ensure the dependencies can be reduced to only the bare minimum for each of those packages.
My proposal is to name the package based on the encoding and protocol:
opentelemetry-exporter-otlp-proto-grpc
opentelemetry-exporter-otlp-proto-http
opentelemetry-exporter-otlp-json-http
Issue Analytics
- State:
- Created 3 years ago
- Comments:16 (16 by maintainers)
Top Results From Across the Web
OpenTelemetry Protocol Exporter
This document specifies the configuration options available to the OpenTelemetry Protocol (OTLP) Exporter as well as the retry behavior. Configuration Options.
Read more >OpenTelemetry: What's a Collector and Why Would I Want One?
In this case, both the receiver and the exporter will be using OpenTelemetry Protocol (OTLP). Let's go through what the above config ...
Read more >Exporting Open Telemetry Data to Jaeger
In this post, I'll show how we can export the Open Telemetry traces, logs and metrics that we've collected to Jaeger and view...
Read more >OpenTelemetry Collector | Dynatrace Docs
A collector is a proxy that can receive, process, and export telemetry data. ... each component (receiver, processor, and exporter) individually in a...
Read more >Using OpenTelemetry - Quarkus
This guide explains how your Quarkus application can utilize ... There are two ways to configure the default OTLP gRPC Exporter within the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@lzchen yes, we should follow the same path there
@codeboten On a related note, do we want to have the same architecture for
zipkin
andjaeger
for their respective protocols as well?