New `opentelemetry` source and sink

[binarylogic]

OpenTelemetry is a specification for collecting observability data.

Their collector and libraries are of questionable quality. We'd like Vector to support OT through their various protobufs and become the best OT collector.

We should break this down into smaller tasks, likely around their various data type (logs, metrics, and traces). I'd like to start with tracing, if possible, to introduce that type into our data model.

• Support ingesting OpenTelemetry logs #13551
• Support ingesting OpenTelemetry metrics #17309
• Support ingesting OpenTelemetry traces #17307
• Support sending OpenTelemetry logs #13622
• Support sending OpenTelemetry metrics #17310
• Support sending OpenTelemetry traces #17308

[loony-bean]

Looks relevant #576

[szibis]

As OpenTracing merged with OpenCensus in one OpenTelemetry project it is considered to support that feature on in and / out ??
It is important to make a Vector replacement for Datadog on the Tracing layer. https://www.datadoghq.com/blog/opentelemetry-instrumentation/ and may also help to build one layer for logs, metrics, and traces.
This also may help to build an architecture that is not vendor locked and allow to switch to other providers easily.

[binarylogic]

Thanks @szibis. Agree, that's the idea with thee OpenTelemetry components. We also want them to enforce our tracing data model when we start to implement it.

This also may help to build an architecture that is not vendor locked and allow to switch to other providers easily.

Agree! That's the primary idea behind Vector. Although, Vector wants to acknowledge current state and help users migrate towards open standards.