Requirements

Request

Replace --otel-collector-uri/FLAGD_OTEL_COLLECTOR_URI and --metrics-exporter/FLAGD_METRICS_EXPORTER with well-known OTel SDK configuration environment variables.

• https://opentelemetry.io/docs/concepts/sdk-configuration/
  • https://opentelemetry.io/docs/concepts/sdk-configuration/general-sdk-configuration/
  • https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/

services:
  flagd:
    command:
    - start
    - --debug
    - --uri
    - https://raw.githubusercontent.com/open-feature/flagd/main/docs/assets/demo.flagd.json
    depends_on:
      otel:
        condition: service_started
    environment:
-     FLAGD_METRICS_EXPORTER: otel
-     FLAGD_OTEL_COLLECTOR_URI: otel:4317
+     OTEL_EXPORTER_OTLP_ENDPOINT: http://otel:4318
+     OTEL_EXPORTER_OTLP_PROTOCOL: http/protobuf
+     OTEL_METRICS_EXPORTER: otlp
    image: ghcr.io/open-feature/flagd
    ports:
    - 8013:8013
    - 8014:8014

  otel:
    image: ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector
    ports:
    - 4317:4317
    - 4318:4318

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 by flagd making an opinionated decision about OTEL_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 think flagd intended to be opinionated about this, so hoping there's an appetite for revisiting the current setup.)