May 2026 Summaries

Dash0, an observability platform based on OpenTelemetry, has been recognized in Redpoint Ventures' 2026 InfraRed 100, an annual list that highlights promising private companies advancing cloud infrastructure for AI innovation. This accolade underscores Dash0's mission to provide an open, vendor-independent platform for engineering teams to manage data signals, aiming to evolve into autonomous operational intelligence by using AI agents for proactive issue resolution. Founded in Germany and headquartered in New York, Dash0 serves over 600 clients, including notable companies like Zalando and Taco Bell, and is supported by investors such as Balderton Capital and Accel. Redpoint Ventures, known for backing transformational companies like Snowflake and Netflix, created the InfraRed 100 in 2023 to spotlight firms building the infrastructure crucial for AI adoption, with plans to celebrate this year's honorees at an event in SFMOMA.

Ingress controllers play a critical role in Kubernetes architecture, serving as key points for distributed traces, access logs, and request-level metrics. The observability at this layer is crucial for understanding and managing operational issues like latency and traffic handling. A recent series of evaluations applied a draft OpenTelemetry Support Maturity Framework to several widely used ingress controllers, including Contour, Emissary, Istio Gateway, kgateway, and Traefik. These projects were assessed across seven dimensions, revealing that while tracing is generally strong due to a shared foundation on Envoy, semantic conventions and metrics often lag behind OpenTelemetry standards. The evaluations highlighted that metrics remain predominantly Prometheus-native, requiring significant pipeline work for multi-signal observability. Traefik stood out for its commitment to OpenTelemetry in logging and metrics, despite being outside the CNCF umbrella. The framework was effective in identifying strengths and gaps, indicating a need for further alignment with OpenTelemetry semantics and stability. As OpenTelemetry adoption grows, especially with 75% of organizations using or evaluating it, the refinement of telemetry practices in ingress controllers is essential for simplifying and standardizing observability across the cloud-native ecosystem.

Istio is a prominent service mesh in the Kubernetes ecosystem, and its gateway components are crucial for managing traffic and security policies, serving as the entry point into service mesh environments. With the retirement of ingress-nginx, alternatives like Gateway API–based implementations and service mesh gateways are being considered, making the integration of Istio Gateway with OpenTelemetry increasingly relevant. Istio Gateway's integration with OpenTelemetry is examined through a proposed maturity model that assesses dimensions like semantic conventions, trace modeling, and multi-signal observability. Although Istio's telemetry is robust and operationally effective, it relies on deprecated semantic conventions and Prometheus-native metrics, necessitating the use of the OpenTelemetry Collector for achieving coherent observability. This integration is crucial for understanding and improving long-term platform decisions and observability in cloud-native environments, highlighting the importance of aligning with evolving OpenTelemetry standards.

Dash0 enhances observability by offering a seamless integration with Prometheus Query Language (PromQL) to enable users to drill down from aggregated metrics directly to the underlying raw telemetry data, such as logs, spans, and web events. This capability addresses the challenge of correlating high-level metrics with the detailed events that generated them, eliminating the traditional split-brain workflow where users had to manually switch between metrics, logs, and traces. By parsing PromQL expressions and extracting relevant data matchers, Dash0 allows users to explore and triage telemetry with filters and time scopes automatically applied, simplifying the process of understanding and troubleshooting system performance. The development of this feature involved complex computer science techniques and collaboration with Prometheus founder Julius Volz, showcasing Dash0's commitment to advancing observability tools.

Emissary Ingress, an Envoy-based ingress controller with roots in the Kubernetes ecosystem, has evolved from its original Ambassador form to focus on flexibility and extensibility, especially in integrating with OpenTelemetry for cloud-native observability. As ingress controllers are pivotal in Kubernetes architectures for handling incoming traffic and enforcing routing and policy decisions, they are crucial for assessing OpenTelemetry's practical application. The analysis provided explores Emissary's integration with OpenTelemetry, using a proposed maturity model to evaluate how telemetry is produced and integrated, with a focus on tracing, where Emissary uses OpenTelemetry but has semantic issues with span types. Logs and metrics collection depends heavily on the OpenTelemetry Collector for normalization and alignment, highlighting a reliance on pipeline configuration rather than source-level integration. Despite its comprehensive telemetry capabilities, Emissary's current OpenTelemetry implementation has limitations in correctness and stability, necessitating a deeper alignment with modern OpenTelemetry standards to enhance interoperability and operational efficacy. The evaluation underscores the importance of semantic accuracy and signal consistency as ingress controllers increasingly become strategic infrastructure components.

Traefik serves as a prominent ingress controller and edge router in the Kubernetes ecosystem, distinguished by its dynamic configuration, protocol support, and community engagement. Unlike many ingress controllers built on Envoy, Traefik is implemented in Go and offers a unique approach to request handling and telemetry. Its integration with OpenTelemetry is crucial for operational visibility, especially as Kubernetes teams reassess ingress options following the retirement of ingress-nginx. Traefik's OpenTelemetry integration uses a proposed maturity model to evaluate how telemetry is produced and processed, emphasizing an OpenTelemetry-native approach for tracing, logging, and metrics. The maturity model assesses dimensions such as integration surface, semantic conventions, and multi-signal observability, highlighting Traefik’s strengths and areas for improvement. Tracing is well-integrated, preserving trace context and emphasizing synchronous request flows, while logs and metrics are exported via OTLP, showing a commitment to interoperability and simplicity in observability pipelines. Although Traefik's telemetry is not yet fully optimized to OpenTelemetry standards, it provides valuable insights for platform teams managing shared ingress controllers. The evaluation underscores the role of the OpenTelemetry Collector in enriching and routing telemetry, demonstrating Traefik’s potential for flexible and future-proof observability with low operational complexity.

vLLM, an inference server with built-in OpenTelemetry instrumentation, requires specific configurations for effective observability in production environments. Unlike standard Application Performance Monitoring (APM) that indicates slow requests, vLLM's observability identifies distinct latency causes such as KV cache preemptions or decode bottlenecks through inference-specific signals like cache utilization and queue depth. This setup uses the OTel Collector and Dash0 as the observability backend to capture these signals for capacity planning and latency debugging. The architecture involves setting up a trace and metrics pipeline using Docker Compose with a FastAPI RAG app, vLLM server, and OTel Collector. This setup allows for detailed distributed tracing and metrics collection, helping differentiate between latency causes in LLM inference and standard HTTP services. The system provides insights into phases of LLM latency, such as scheduling, prefill, and decode, which require different tuning strategies. The integration with Dash0 enables monitoring of metrics related to GPU cache usage and queue depth, facilitating proactive capacity management and debugging.

Observability in agentic applications, particularly when incorporating large language models (LLMs), is crucial due to their non-deterministic nature, as demonstrated through the Spring Merch Store—a Spring Boot 4 application where users engage with an AI agent to navigate a merchandise catalog. The application integrates Spring AI and employs OpenTelemetry for comprehensive observability, capturing traces, metrics, and logs seamlessly via a single dependency, spring-boot-starter-opentelemetry, which simplifies the configuration process compared to earlier versions. By leveraging OpenTelemetry's GenAI semantic conventions, developers gain insights into LLM token usage, tool calls, and conversation flows without custom instrumentation, while the integration with Dash0 enhances data visibility. The application also highlights advanced configurations like logging prompt and completion text, and ensuring trace context continuity across asynchronous operations using Project Reactor, which enriches the debugging process and refines user interactions with the AI.

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.