partnerships

Varnish CDN Observability with OpenTelemetry & Oodle AI

Sai Prameela Konduru

03 Nov 2025 • 7 min read

This post explores what effective CDN observability looks like. It explains how Varnish, the content-delivery software trusted by Tesla, Walgreens, Emirates, Sky, etc., exposes telemetry through OpenTelemetry and why it built its standard dashboards on Oodle AI (see Varnish’s integration post).
It highlights key metrics, shows how they appear in dashboards, and describes how this integration simplifies observability for distributed CDN and edge environments.

TL;DR: Varnish observability with OpenTelemetry.

Varnish emits detailed cache, latency, backend and error telemetry by design. The varnish-otel exporter turns varnishstat and varnishlog data into standard OpenTelemetry metrics, logs and traces, so you can send it anywhere, no custom agents, no lock-in.

Point it at Oodle AI and you get prebuilt Varnish dashboards across five pillars (Overview, Traffic, Saturation, Errors, Latency), the key metrics that matter, and PromQL-based alerting, connected in about two commands.

What is Varnish observability with OpenTelemetry?

Varnish observability is the practice of collecting Varnish's built-in cache, backend, saturation, error and latency signals and exporting them over OpenTelemetry so any backend can visualise and alert on them. Varnish already tracks this data internally through varnishstat and varnishlog; the varnish-otel exporter reads those, renames the counters to follow OpenTelemetry conventions, and emits standard metrics, logs and traces.

Because the output is plain OpenTelemetry, you choose the destination, Oodle AI, Grafana, Datadog, Splunk or New Relic, without vendor-specific agents.

The Challenge of Observability for CDNs

CDN observability isn’t just about tracking requests per second or cache hit ratios. At the edge, engineers deal with high concurrency, global latency variance, backend failures, and dynamic cache churn often all at once.

A small configuration change can shift terabytes of traffic or trigger cache invalidations across multiple points of presence. To manage that safely, you need visibility into every layer: client requests, cache behavior, backend fetches, queue lengths, and resource saturation.

How Varnish Enables Deep Observability by Design

Varnish’s architecture exposes detailed, structured data about its internal state. Its observability isn’t bolted on; it’s built in.

Here's why engineers value Varnish's Observability:

Sustained high-throughput performance: Handles hundreds of TBs of traffic daily with stable tail latency exposing queue depth, thread utilization, and cache efficiency so engineers can tune for consistent speed at scale.

Programmable edge control: Fully programmable caching and routing via VCL, with instant feedback through built-in metrics like backend latency, hit ratio, and invalidation frequency.

Bandwidth efficiency through visibility: Makes origin offload measurable. The detailed cache metrics let teams verify bandwidth savings and detect regressions as workloads change.

Hardware-level insight: Surfaces CPU and NIC counters that power 100 Gbps-class throughput, giving rare visibility into how hardware performance affects edge latency.

Hybrid and private-CDN readiness: Often used as an origin shield or private CDN tier; telemetry spans edge and origin for unified visibility across multi-CDN or hybrid setups.

Together, these characteristics make Varnish observability-ready without additional instrumentation.

From Varnish to OpenTelemetry

Varnish’s built-in tools: varnishstat, varnishlog, and extensions like vmod_accounting provide deep insight into cache behavior. With the varnish-otel exporter, this data becomes portable and standardized. By emitting metrics, logs, and traces over OpenTelemetry, Varnish gives operators the freedom to choose their observability destination without lock-in or custom agents.

Oodle AI complements that perfectly by natively supporting OpenTelemetry ingestion. This makes observability easier to use, eliminates vendor lock-in, and lets engineers focus on improving their systems rather than managing tools.That flexibility is what makes the Oodle integration so straightforward: you can point varnish-otel at Oodle and start visualizing data immediately - as detailed in Brian Stewart’s blog post.

Where varnish-otel stands in 2026. varnish-otel has moved well beyond its early-2025 tech preview: v1.0 shipped June 2025 and it reached v2.5 (June 2026), now on a steady release cadence (changelog). Three things worth knowing before you deploy it today:

Varnish Cache 9.0.1+ is required for current releases (since v2.4.0, April 2026).
Metrics and logs work out of the box; distributed tracing additionally needs vmod-otel, a Varnish Enterprise feature.
As of v2.5, varnish-otel ships a native Prometheus exporter (OTEL_METRICS_EXPORTER=prometheus) alongside OTLP, though Oodle alerts on either.

Why Oodle AI is a Natural Fit

Oodle AI is an AI-native observability platform designed for modern, high-cardinality telemetry, the exact kind of data Varnish generates at scale.It provides enterprise-grade performance at open-source cost, unifying metrics, logs, traces, and anomaly detection in one place.

Here’s why it fits CDN workloads particularly well:

Scales effortlessly across distributed caches and POPs without dropping tags or sampling data.
AI-native debugging correlates anomalies across metrics, logs and traces in one place. Ex: It can connect a latency spike with backend saturation or cache misses.
Familiar Grafana + OpenSearch UI lets engineers explore data instantly with no learning curve.
Fast setup: Connect in two commands and get pre-built dashboards in < 5min.

5× cost efficiency: Makes high-cardinality metrics and logs affordable and sustainable. (See pricing calculator)

Standard Dashboards and Key Metrics

The varnish team created a standard dashboard organized around the five pillars most teams rely on. These sections help SREs and platform engineers focus on the metrics that actually move the needle balancing visibility with clarity.

Overview: request throughput, cache hit ratio, backend health, panic indicators.
Traffic: ESI subrequests, invalidations, pass ratio, origin requests.
Saturation: thread utilization, queue depth, session drops.
Errors: backend fetch failures, compression or ESI errors, sick backends.
Latency: client, fetch, and delivery timings across cache layers.

What Varnish metrics should you monitor?

Focus on the handful of Varnish metrics that reveal demand, offload, saturation, errors and latency, the five pillars above map directly to specific varnish-otel signals.

Pillar	What to watch	Metric in Oodle	Why it matters
Overview / Throughput	Requests/sec, cache hit ratio	varnish_main_client_requests , varnish_main_cache_hits/misses	Demand and how much you serve from cache vs origin
Latency	Backend TTFB, backend total, client total	varnish_backend_duration_ttfb , varnish_backend_duration_total , varnish_client_duration_total	Tail latency and where delay is introduced
Saturation	Thread queue length, live threads	varnish_main_thread_queue_length , varnish_main_thread_live	Early warning Varnish is running out of capacity
Errors	Backend fetch / session failures	varnish_backend_failed , varnish_main_session_failed	Reliability, sick backends, dropped sessions
Backend health	Connection setup time	varnish_backend_duration_connection	Slow origins and connection-pool problems

Exact names vary by version, see the varnish-otel metric reference.

How do you monitor Varnish latency?

Monitor Varnish latency by separating backend latency from delivery latency, because the two point to very different problems. Track varnish_backend_duration_ttfb and varnish_backend_duration_total for how long origin fetches take, and varnish_client_duration_total for what the end user experiences. When client latency rises but backend latency is flat, the delay is in delivery or saturation (check thread queue length); when both rise together, the origin or backend connection is the cause. Because varnish-otel builds latency histograms from Varnish's log data, you can chart p50/p95/p99 tails per domain, POP or backend, not just averages, since tail latency is where CDN problems usually surface.

For more details, check out this blogpost by Varnish.

Alerts: Turning Visibility into Action

Dashboards show you what’s happening; alerts make sure you know when it matters. Using Oodle’s native PromQL-based alerting, teams can define precise thresholds or anomaly rules for backend latency, cache efficiency, and error rates scoped by domain, POP, or backend label.

Example: Trigger an alert when p95 backend TTFB crosses 500 ms over five minutes: histogram_quantile(0.95, sum(rate(varnish_backend_duration_ttfb_bucket[5m])) by (le)) > 500 (the duration buckets are in milliseconds).

Because Oodle is AI-native, related anomalies are automatically surfaced so when a latency spike occurs, Oodle can highlight linked metrics such as rising queue length or degraded cache hit ratio.This transforms alerting from simple thresholding into actionable diagnosis.Pro-tip: You can configure alerts through Terraform.[docs]

How do you set up Varnish alerts?

Set up Varnish alerts on the three failure modes that hurt users first, rising backend latency, falling cache hit ratio, and climbing error rates, each scoped by domain, POP or backend label. With Oodle's PromQL-based alerting you define these as thresholds or anomaly rules on the metrics above. A practical starter set:

Backend latency: page when p95 backend TTFB crosses your SLO (the example above fires above 500 ms over five minutes).
Cache hit ratio drop: warn when the hit ratio falls below your baseline (~90%) over 10 minutes, usually a bad invalidation or a VCL change shifting traffic to origin.
Backend errors: alert on any sustained rise in backend fetch failures (varnish_backend_failed) or sick backends.
Saturation: alert when thread queue length stays above zero, the earliest sign Varnish is out of headroom.

Because Oodle is AI-native, a single latency alert also surfaces the linked signals, rising queue length or a degraded hit ratio, so you get the diagnosis, not just the symptom.

Frequently asked questions

What is varnish-otel?

varnish-otel is Varnish Software's official OpenTelemetry exporter. It runs varnishstat and varnishlog under the hood and emits Varnish's metrics, logs and traces as standard OpenTelemetry data, so you can send Varnish telemetry to any OpenTelemetry-compatible backend, Oodle AI, Grafana, Datadog, Splunk or New Relic, from a single binary.

Does varnish-otel work with open-source Varnish Cache?

Yes. Current releases support Varnish Cache 9.0.1 and later, and metrics and logs work without any Enterprise add-on. Distributed tracing is the exception: it requires vmod-otel, a Varnish Enterprise feature.

What Varnish metrics matter most for CDN performance?

Cache hit ratio and request throughput (is the CDN serving from cache?), backend and client latency (where is delay introduced?), thread queue length (is Varnish saturated?), and backend/session failures (what's breaking?). These map to the five dashboard pillars above.

Can I send Varnish telemetry to Prometheus or Grafana instead of a hosted tool?

Yes, the output is standard OpenTelemetry, so the destination is your choice. As of v2.5 (June 2026), varnish-otel also ships a native Prometheus exporter, so you can scrape Varnish metrics directly or forward them via OTLP to Grafana, Oodle or another backend.

How is Varnish observability different from ordinary web-server monitoring?

Varnish is a caching layer at the edge, so the signals that matter are cache-centric, hit/miss ratios, origin offload, ESI subrequests, invalidations and per-POP tail latency, not just CPU and request counts. Varnish exposes these by design, which is why it's often called observability-ready without extra instrumentation.

Trusted for CDN Observability

Oodle is now one of the trusted destinations for Varnish telemetry alongside Datadog, Grafana, Splunk, and New Relic giving CDN and edge operators flexibility without complexity.Our experience with Varnish’s data model and high-cardinality metrics ensures smooth ingestion, clean dashboards, and meaningful alerting from day one.

And for Oodle users exploring caching or edge acceleration, Varnish itself is worth a closer look, it’s one of the rare systems engineered with observability as a core principle.

Get Started in Minutes

Varnish users can explore a preconfigured dashboard and example alerts on Oodle’s playground, or follow the integration guide in Oodle’s documentation to connect varnish-otel.

You can reach us at support@oodle.ai.

Varnish Software is a global leader in high-performance caching and content delivery. Trusted by leading streaming services and enterprises worldwide, Varnish optimizes the delivery of digital content, APIs, and applications. Its customizable platform empowers businesses to scale efficiently, reduce costs, and deliver outstanding user experiences across video, web, and cloud environments.

Related reading

Building a high-performance, low-cost metrics observability system, how Oodle keeps high-cardinality metrics affordable.
Scaling Prometheus from single node to enterprise-grade observability, the Prometheus/PromQL foundation behind Oodle alerting.
Dashboards are dead: why static dashboards fall short, the case for AI-native, correlation-first observability.