OpenTelemetry Input Plugin #9077
Conversation
![telegraf-tiger[bot]](https://avatars.githubusercontent.com/in/94907?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla
telegraf-tiger
bot
added
feat
|
@jacobmarble Is this plugin blocked on the PRs you linked that you opened in the OpenTelemetry repo? |
Not blocked, ready for your review. |
There was a problem hiding this comment.
Thanks @jacobmarble for submitting this PR! I have some comments in the code. Nothing big, but I agree with @Hipska that we need unit tests for this plugin!
Please keep the plugin name. @Hipska: all plugins passively waiting for the other side to connect and not actively gathering the metric have the _listener suffix, so let's keep it that way.
Oh, okay that is a valid point. Yes keep the name. |
Looks like new artifacts were built from this PR. Get them here!Artifact URLs |
This change adds an exporter for [InfluxData line protocol](https://docs.influxdata.com/influxdb/v2.0/reference/syntax/line-protocol/), the native wire transfer protocol for [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/) and [InfluxDB](https://www.influxdata.com/products/influxdb/). The conversion logic lives in [package `otel2influx`](https://github.com/influxdata/influxdb-observability/tree/main/otel2influx), and is also imported by the [proposed Telegraf OpenTelemetry input plugin](influxdata/telegraf#9077). The objective of this strategy is to create a canonical mapping, and an open-source implementation, of OpenTelemetry <-> Telegraf/InfluxDB translation. I am not proposing that `otel2influx`, in its current state, be the canonical mapping. Let's discuss that topic separate from this exporter. One shortcoming of this approach is that both `otel2influx` and `opentelemetry-collector` package their own generated protocol buffer objects. This means that every OTLP protobuf object is serialized and deserialized in this exporter. I propose that `opentelemetry-collector` instead depend on `opentelemetry-proto-go`, for the benefit of this exporter and other third-party packages. ```golang // r is a protobuf from otel2influx // td is a protobuf wrapper from otelcol var r otlpcollectortrace.ExportTraceServiceRequest if protoBytes, err := td.ToOtlpProtoBytes(); err != nil { return err } else if err = proto.Unmarshal(protoBytes, &r); err != nil { return err } ``` **Link to tracking Issue:** #2951 **Testing:** Little testing so far. The translation logic should be tested in [package `otel2influx`](https://github.com/influxdata/influxdb-observability/tree/main/otel2influx) (but is not currently). **Documentation:** README.md included in new exporter.
Related:
This change adds an input plugin
opentelemetry_listener, which opens a gRPC listener to ingest OTLP signals.OpenTelemetry is an open-source telemetry ecosystem, supporting traces, metrics and logs. The mapping of the OpenTelemetry data model to line protocol is a work-in-progress, and I welcome any feedback to that document.
The core conversion logic lives in influxdata/influxdb-observability/otel2influx, intended to stand as a canonical implementation of OTel->line protocol. That package is also imported by the above-mentioned PR "OTel Collector exporter..."