CDN logs contain detailed evidence about every edge-handled request, but SRE monitoring needs stable signals that summarize user experience. Paging directly on raw log patterns creates high-cardinality queries, unstable thresholds, and alerts that describe infrastructure activity rather than customer impact. The better pattern is to derive service-level indicators from logs, evaluate them against objectives, and keep the original events for investigation.

The transformation has three layers. First, define which requests and outcomes represent the service. Second, convert those events into bounded metrics such as good requests, total eligible requests, and latency buckets. Third, alert when the service is consuming error budget at a rate that requires action. Each layer needs explicit definitions and data-quality checks.

Define the service boundary

A CDN distribution may serve many products, routes, environments, and asset classes. An SLI should describe one coherent user-facing capability. “All CDN requests” is rarely useful because cached images, login APIs, redirects, health checks, crawlers, and internal traffic have different expectations.

Use stable service and route-group labels. Exclude synthetic probes, known internal jobs, malformed traffic outside the product contract, and requests that never had a chance to succeed because of an intentional policy. Document exclusions carefully so the objective cannot be improved by quietly removing difficult traffic.

Availability from edge outcomes

An availability SLI usually counts successful eligible requests divided by total eligible requests. The hard work is defining success. A 404 may be correct for one route and a failure for another. A 429 can be expected protective behavior or user-visible unavailability. A 503 generated by the edge and a 503 returned by the origin both affect users, but they may route to different owners.

Create an outcome classifier that uses client status, result source, route contract, and policy action. Version it and test it with representative events. Publish the numerator, denominator, and exclusion rules next to the SLO.

Latency as a user-centered indicator

Latency SLIs often count the fraction of eligible requests completed below a threshold rather than alerting on a percentile alone. This turns latency into good and bad events that can share an error budget model. Different route groups may need different thresholds; a cached image and a write API should not use one target.

Choose the edge timing field closest to user experience, but understand its boundary. If it excludes client transfer or includes long-lived streaming, it may not fit every route. Separate cache hits, origin-bound requests, and large transfers when their distributions differ materially.

Freshness and correctness indicators

CDNs can serve fast responses that are stale or incorrect. Content freshness may need an SLI based on object age, purge completion, version propagation, or validation outcomes. Security and routing systems may need correctness indicators such as the percentage of requests processed by the intended policy or origin pool.

These indicators often combine edge logs with deployment, cache, or application data. The SLO should still be expressed in terms of a user-relevant outcome, not internal configuration success alone.

Derive metrics safely

Convert logs into low-cardinality counters and histograms in a controlled aggregation layer. Useful labels include service, environment, route group, outcome class, cache class, provider, and broad region. Avoid client address, raw path, request ID, user agent, and arbitrary rule IDs as metric labels.

Aggregation should use event time, handle late records, and be idempotent. If the stream retries events, duplicate metrics can inflate both good and total counts. A replay should produce the same result as the original processing. Store the aggregation version so historical changes are explainable.

Monitor the SLI data pipeline

An SLO calculated from incomplete logs can look healthier than reality. Track delivery lag, expected coverage, sample rate, parser failures, duplicate rate, unknown outcome classification, and aggregation delay. Define a data-validity state; when coverage falls below a threshold, dashboards and alerts should indicate uncertainty rather than report a confident zero-error result.

Cross-check log-derived request totals against another trustworthy source such as CDN metrics, routing counters, or origin summaries. Exact equality is not always expected, but unexplained divergence needs investigation.

Use error budgets to set urgency

An objective allows a defined amount of bad service. The remaining error budget converts a raw failure rate into operational context. A short spike may be tolerable for a service with ample budget but urgent when the service has already consumed most of its allowance.

Burn rate expresses how quickly the service is spending budget relative to the objective. Multi-window alerts can combine a fast window that detects severe incidents with a slower window that confirms sustained impact. This improves precision compared with a single static error-rate threshold.

Separate pages from tickets

Page when immediate human action can reduce meaningful user impact. Create a ticket or review when the condition is important but not urgent, such as a gradual cache-efficiency decline, a low-volume regional tail, or a policy that is consuming budget slowly. Dashboard-only signals can support investigation without creating notification debt.

Every alert needs an owner, impact statement, evidence, and runbook. Include affected service, route groups, regions, cache outcomes, provider, result source, current burn rate, and links to representative request searches. Avoid attaching dozens of charts with no decision path.

Use logs for incident context, not the page condition alone

The page condition should usually come from a pre-aggregated SLI because it is fast and stable. Once it fires, logs answer why: which routes changed, whether failures came from the edge or origin, which regions and providers are affected, whether cache misses increased, and which request IDs connect to traces.

Prepare investigation views before an incident. A standard dashboard can show status, latency, cache, origin, and data-quality splits for the exact SLI population. This prevents responders from rebuilding filters while the service is degraded.

Test alerts and objectives

Replay historical incidents through proposed rules to measure detection time, precision, and reset behavior. Run controlled failure tests where safe. Verify that low traffic, missing data, deploys, and provider failover do not create misleading alerts. Review alerts that fired without action and incidents that should have fired but did not.

SLOs should evolve when the product contract changes, not whenever a target is hard to meet. Version definitions, record approvals, and keep historical calculations reproducible. A change in route classification or latency threshold can otherwise appear as a sudden reliability improvement.

A practical implementation sequence

Before paging anyone, run the proposed SLI beside existing monitoring for a full traffic cycle. Compare incidents, planned maintenance, low-volume periods, and telemetry gaps. This parallel period exposes classification mistakes before the new alert becomes an operational dependency.

  1. Choose one user-facing service and define eligible requests.
  2. Write explicit success, failure, and exclusion rules.
  3. Create low-cardinality good and total counters from edge logs.
  4. Validate coverage, duplication, freshness, and classification quality.
  5. Set an objective based on user needs and business commitments.
  6. Implement multi-window burn-rate alerts with page and ticket severities.
  7. Attach a runbook and investigation dashboard using the same request population.
  8. Review alert performance after incidents and at a regular cadence.

The CDNLog.com monitoring guide covers the underlying metric families, while the origin latency guide provides a detailed investigation workflow. The key distinction is simple: logs explain individual events; SLIs summarize user outcomes; SLO alerts decide when those outcomes require action.

Related field guides