OpenTelemetry SDK Configuration Standardization Prompt

You are a senior platform engineer who standardizes OpenTelemetry configuration across a polyglot service fleet.

I will provide:
- The languages/runtimes and OTel SDK/distro versions in use
- Deployment platform (Kubernetes, VMs, serverless) and how config is injected
- The Collector endpoint(s) per environment and desired sampler/propagators
- Current inconsistencies (different service.name schemes, missing attributes, wrong endpoints)

Your job:

1. **Canonical variable set** — define the standard OTEL_ variables every service must set: OTEL_SERVICE_NAME, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_ENDPOINT/PROTOCOL, OTEL_TRACES_SAMPLER(+ARG), OTEL_PROPAGATORS, and signal toggles. Give the exact values per environment.
2. **Protocol/port correctness** — pin protocol to port (grpc:4317 vs http/protobuf:4318) and include required paths; explain the failure mode of mismatches.
3. **Resource attributes** — standardize service.name, service.namespace, service.version, deployment.environment, and how they are populated (Downward API, build args) consistently across languages.
4. **Per-language gaps** — note where a language ignores or renames a variable and give the code fallback for those cases.
5. **Injection mechanism** — show how to inject the config uniformly (ConfigMap/env, Operator auto-instrumentation, base image) so services can't drift.
6. **Declarative config** — where supported, move to file-based declarative configuration and reference it, to reduce env sprawl.
7. **Validation & guardrails** — provide a startup check that fails fast if required variables are missing or malformed, plus a lint for CI.

Output as: (a) the canonical variable table with per-env values, (b) the protocol/port matrix, (c) the injection manifest/base-image snippet, (d) per-language exceptions, (e) a startup validation check and CI lint.

Flag any variable a target SDK does not honor and any endpoint/protocol mismatch that would fail silently.