Support absence of OTEL_* config variables injected in containers

[cyrille-leclerc]

Changes

Ensure the docker container can start in the absence of OTEL_* config variables injected in containers by Docker Compose or K8s.

Rationale:

• OTEL SDKs don't fail if no config is passed to them thanks to sensible defaults, e.g. no env var like OTEL_EXPORTER_OTLP_ENDPOINT is passed to them
• It will help for injection of OTEL_* config through the Otel Operator if the container supports absence of those ev vars.

Merge Requirements

For new features contributions, please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the docs
• Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[cyrille-leclerc]

this parameter is the instrumentation scope nam, not the service name.

[cyrille-leclerc]

@puckpuck FYI a first step heading toward OTLP-protocol agnostic instrumentation.

[julianocosta89]

@cyrille-leclerc I don't understand the need of this PR.
Could you elaborate a bit?

If the user forgets to set an env var, this will just mask the error.

I'd rather have the service fail to start with a message saying Env Var OTEL_XYZ is required, than the service starting and not working as expected.

[cyrille-leclerc]

Initially, I wanted this behaviour because the when combining the otel-kube-stack with the otel-demo components within the same chart, the demo components first starts without being injected the OTEL_* env variables and I didn't want some of the components to report failure to start when some other did start with sensible defaults.

Then I did somecresearch and found that most apm agent don't fail the process when misconfigured which made a lot of sense to me and I came to the conclusion that the demo should exhibit the same behaviour: if monitoring config is missing, don't fail the service, just report the failure in a non blocking manner.

Does it clarify?

I'd rather have the service fail to start with a message saying Env Var OTEL_XYZ is required, than the service starting and not working as expected.

My understanding is that OTel SDKs gracefully degrade if not provided configuration, like setting the export to the OTLP endpoint on http://localhost:4318 service name to unknown_service

[julianocosta89]

the demo should exhibit the same behaviour: if monitoring config is missing, don't fail the service, just report the failure in a non blocking manner.

I'd love to have more opinions on this. (@rogercoll, @puckpuck and @mviitane, wdyt?!)

To me, the main goal of the OTel Demo is to demonstrate OTel. If a service starts successfully, but without OTel configured, then the service is not showcasing what was supposed to.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.