(feature) OpenTelemetry exporter

[thomaspoignant]

Requirement

As of Today, we have a bunch of data exporter to export at different location, but the format is owned by GO Feature Flag.
To integrate better with other tools it will be great to have a OpenTelemetry data exporter that will add a span for each evaluation.

• Develop a new exporter in the exporter folder.
• Create a span for each evaluation.
• Let user configure this exporter in the relay proxy.
• Update the documentation with this exporter.

[bearrito]

I haven't contributed before, I can grab this if thats okay.

[thomaspoignant]

Hey @bearrito feel free to take it.

[bearrito]

Just so I can confirm scope

1. I see that the other exporters all take a featureEvents []exporter.FeatureEvent. This needs to be converted into a trace. I need to learn more about Features and Evaluations. But would each FeatureEvent correspond to a span within the trace?
2. OpenTelemetry itself supports exporters. I assume you want support for all these? Is there one to prioritize?
3. Do I need to worry about context propagation? (I don't think so)
4. Do you want resources (metadata) included. ( I think so)

Edit:
I'm not familiar with the relay proxy so I'll deal with that when I encounter it, I'll get to what I think is an 80% solution with unit-tests first.

[thomaspoignant]

Hello @bearrito let me try to answer your questions.

1. I see that the other exporters all take a featureEvents []exporter.FeatureEvent. This needs to be converted into a trace. I need to learn more about Features and Evaluations. But would each FeatureEvent correspond to a span within the trace?

Yes, you can emit 1 span for each featureEvent, but since this can be a synchronous exporter I recommend to set the IsBulk function at false (like in the example below), this will ensure that you will never have more than 1 event in the array for each call.

go-feature-flag/exporter/sqsexporter/exporter.go

Lines 73 to 75 in add7232

	func (f *Exporter) IsBulk() bool {
	return false
	}

2. OpenTelemetry itself supports exporters. I assume you want support for all these? Is there one to prioritize?

Since this is meant to be used by anyone, I would say that we should export to OTLP so the users can decide on their side which one to use.

3. Do I need to worry about context propagation? (I don't think so)

No, we can start without that for now.

4. Do you want resources (metadata) included. ( I think so)

Yes, ideally we should have them.