Understanding OpenTelemetry Support in Contour
Blog post from Dash0
Contour, a CNCF-graduated ingress controller built on Envoy, is increasingly important in Kubernetes environments as OpenTelemetry becomes a standard for observability. Ingress controllers like Contour are critical for managing incoming traffic and understanding latency and failure modes, making OpenTelemetry integration vital for long-term platform decisions. As the Kubernetes ecosystem evolves, and with the retirement of ingress-nginx, many users are evaluating alternatives such as Contour. This evaluation focuses on how Contour integrates with OpenTelemetry, using various dimensions to assess telemetry production, integration, and downstream processing. Contour's strength lies in its OpenTelemetry-native tracing, which uses OTLP as its primary export path, ensuring predictable and consistent traces that align with Envoy's execution model. Access logs, while not automatically correlated with traces, rely on an OpenTelemetry Collector for parsing and enriching logs to enable trace correlation. Metrics remain Prometheus-native, requiring downstream alignment rather than a unified OpenTelemetry approach. The maturity model used in this evaluation highlights that Contour's OpenTelemetry support is functional and pragmatic, with strong tracing and log quality, though metrics and resource identity rely on downstream processing. Overall, Contour's integration reflects both the progress and the areas for future improvement in OpenTelemetry adoption, particularly in achieving a more unified multi-signal design.