-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] flagd should use standard OTel SDK env vars #1141
Comments
Thanks @austindrenski, I'll take a look tomorrow. Using the officially supported environment variables makes sense to me. |
Hey @austindrenski, thanks for the suggestion. You are right, currently we are opinionated and we force gRPC as protocol to dispatch OTel data to its collector. I think it was a reasonable opinion since FlagD talks gRPC already. I agree that we should support both, http and gRPC :) having just gRPC should not be our opinion :)
|
@thisthat How could a user set the protocol if the logic exits the flow if a URI is present? Wouldn't you need the URI and the protocol for this to work propertly? I was thinking something like this:
|
@beeme1mr I was thinking of parsing the schema part of the URI to determine grpc vs http |
Requirements
Request
Replace
--otel-collector-uri
/FLAGD_OTEL_COLLECTOR_URI
and--metrics-exporter
/FLAGD_METRICS_EXPORTER
with well-known OTel SDK configuration environment variables.IMO this approach would provide a better telemetry story overall for
flagd
since one of the main tenants of the OTel project is to avoid re-inventing the wheel on configuration, but more specifically, I'm opening this issue after running into a pinch-point caused byflagd
making an opinionated decision aboutOTEL_EXPORTER_OTLP_PROTOCOL=grpc
.In my specific use case, supporting the standard OTel SDK env vars would mean that I could, for example, set
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
in order to communicate with an existing OTel Collector gateway cluster that doesn't accept gRPC traffic.(I could, of course, work around this by making my existing
otelcol
gateway cluster listen for gRPC traffic too, but (1) there are genuine, non-trivial DevSecOps considerations involved, and more importantly, (2) I don't thinkflagd
intended to be opinionated about this, so hoping there's an appetite for revisiting the current setup.)The text was updated successfully, but these errors were encountered: