Feature: Add environment variables for OTLP retry configuration

Feature Request: Add environment variables for OTLP retry configuration

Is your feature request related to a problem?

Currently, the OTLP exporter has hardcoded retry parameters (maxRetries = 3, retryDelay = 100ms) defined in OtlpHttpTransportFactory and GrpcTransportFactory. While these defaults work well for most use cases, different environments have different requirements:

• High-traffic production environments may need to reduce retry attempts to fail fast and avoid overwhelming collectors during outages
• Unreliable networks (mobile, edge computing) may benefit from more retries with longer delays
• Testing/development environments might want to disable retries completely for faster feedback

Describe the solution you'd like

Add environment variables to configure retry behavior, following the existing OTLP configuration pattern:

# General retry configuration
OTEL_EXPORTER_OTLP_MAX_RETRIES=3              # default: 3
OTEL_EXPORTER_OTLP_RETRY_DELAY=100            # milliseconds, default: 100

# Per-signal overrides (optional)
OTEL_EXPORTER_OTLP_TRACES_MAX_RETRIES=3
OTEL_EXPORTER_OTLP_TRACES_RETRY_DELAY=100
OTEL_EXPORTER_OTLP_METRICS_MAX_RETRIES=3
OTEL_EXPORTER_OTLP_METRICS_RETRY_DELAY=100
OTEL_EXPORTER_OTLP_LOGS_MAX_RETRIES=3
OTEL_EXPORTER_OTLP_LOGS_RETRY_DELAY=100

Implementation details

1. Keep current hardcoded defaults (3 retries, 100ms delay) for backward compatibility
2. Read environment variables in transport factories
3. Programmatic configuration should take precedence over env vars
4. Document the new options in the OTLP exporter specification

Example use case

Our scenario: We run a high-scale PHP application with an OTLP collector. During collector maintenance or network issues, we observed:

• Default 3 retries can cause request pile-up in PHP-FPM workers
• 100ms delay is too short for our network latency
• We forked the library to customize these values, but would prefer using standard env vars

Alternatives considered

• Programmatic configuration only - requires code changes for each adjustment
• Config file - adds another configuration layer
• Environment variables ✅ - follows existing OTLP patterns, zero-code deployment changes

Additional context

This aligns with the OTLP specification's approach to configuration and would benefit other language implementations as well. The OTLP spec defines retry behavior but doesn't specify configuration mechanism - this is left to language implementations.

Related

• OTLP Specification - Retry
• Similar configuration exists for: endpoint, timeout, headers, compression

Start by reading OtlpHttpTransportFactory and GrpcTransportFactory, then compare how the existing endpoint, timeout, headers, and compression environment settings are handled. Implement the general and per-signal retry options with programmatic settings taking precedence, preserve the current defaults, and document the options in the OTLP exporter specification.