Opentelemetry-specification: Define the list of standard exporters that SDK should support

[bogdandrutu]

Proposal for trace:

1. OpenTelemetry exporter (decide if HTTP vs gRPC).
2. Jaeger exporter (decide if the new gRPC or Thrift).
3. Zipkin exporter (probably v2)

Proposal for metrics:

1. OpenTelemetry exporter (decide if HTTP vs gRPC).
2. Prometheus exporter.

Another question is, do we want to have these standard exporters in the SDK artifact/package?

[AdaptiveThinking]

I would suggest also have a simple exporter to stdout (e.g. with JSON, like a Log).
This would make certain scenarios (like PaaS/FaaS), which have default ways for Logs with stdout easyer to operate.

[SergeyKanzhelev]

JSON log can be used for FluentBit. We can consider defining message pack as well for telemetry types.

[bogdandrutu]

I think just for JSON we should use proto to JSON, what do you think? Then we don't need to define anything for this.

[SergeyKanzhelev]

I think just for JSON we should use proto to JSON, what do you think? Then we don't need to define anything for this.

@bogdandrutu let's have it as a primary plan. I have never dealt with proto JSON and not sure if we will discover any issues with this. From the looks of it - must be straightforward

[iredelmeier]

My experience with proto JSON has been subpar:

• The produced JSON is generally verbose and unidiomatic
  
  
  
  • This is especially true for oneof fields, of which we'd often have many - I believe @jmacd has more to say on this
  
  
• Support across languages is spotty
• Documentation for the conversion is sparse. Using something like the grpc-gateway works, but is overkill and requires a lot of overhead

For me, the first point re: verbose and unidiomatic JSON is the biggest concern, and should be sufficient alone to give us pause since one of the biggest values is supposed to be human readability, e.g., for use during development.

[jmacd]

I see a desire expressed here to support a human readable debugging log. One of the challenges there is that in the SpanData exporter model, the exporter doesn't see a span until it finishes. For debugging, I think it's pretty useful to see a log message when the span starts, and to see Span Events logged as they happen. To help demonstrate how we can achieve this outcome without sacrificing the other kinds of exporter, I put together a Golang prototype that supports observing events as they happen, without buffering, with the intention that higher-level exporters could be defined in terms of a lower-level exporter.

https://github.com/open-telemetry/opentelemetry-go/issues/4

I also agree with @iredelmeier that the Protobuf-to-JSON support in Google's protobuf makes for human-unreadable JSON, mainly because of oneof fields.