Edge log analytics begins where origin-only observability stops. A content delivery network can serve a cached response, apply a rule, negotiate a protocol, execute code, route through a shield, contact an origin, or terminate a request before the application sees it. The analytics model must preserve enough of that path to explain what the user experienced and why.
Questions a useful edge dataset should answer
What did the user receive?
Client-facing status, bytes, content class, protocol, and total edge duration describe the visible outcome.
Where was it handled?
Provider, edge location, routing tier, selected origin, and logical service identify the path.
Why did the CDN choose that path?
Cache result, cache eligibility, policy action, rule ID, and configuration version explain the decision.
Where did time accumulate?
Connection, first-byte, origin, transfer, and total timing fields isolate the slow stage.
Can the evidence be trusted?
Observed time, source reference, schema version, sampling, duplicates, and parser status measure data quality.
Who can act on the result?
Service, route group, environment, ownership, and deployment context turn a finding into a response.
Build a canonical event model
Normalize common concepts without erasing provider differences. A canonical envelope should include event time, observed time, provider, account, service, request ID, schema version, source reference, and sampling metadata. The payload can hold HTTP, cache, timing, routing, security, and byte fields. Preserve provider-specific values in a namespaced extension so investigations can return to the original meaning.
Normalization needs semantic discipline. A field called origin_duration_ms should have one documented start and end boundary across every adapter. If two providers expose different boundaries, use different canonical fields rather than pretending they are comparable. Null should mean unavailable or not applicable—not zero.
A repeatable analysis workflow
Confirm data health
Check delivery lag, coverage, sampling, duplicates, parser failures, and schema version before interpreting a trend.
Choose the user-facing population
Filter by service, environment, route group, and intended traffic. Exclude probes and unrelated workloads explicitly.
Split by delivery path
Separate cache hits, misses, bypasses, revalidations, edge-generated failures, and origin responses.
Rank explanatory dimensions
Compare region, provider, origin pool, route, status, object size, protocol, and configuration version.
Sample request IDs
Validate the aggregate explanation against individual events and correlated origin or trace data.
Make one controlled change
Define the expected metric movement, safety limit, and rollback condition before changing cache, routing, or policy.
High-value analytical views
| View | Primary dimensions | Decision supported |
|---|---|---|
| Edge outcome matrix | result source, status class, cache class, service | Separate CDN, origin, policy, and client outcomes |
| Latency decomposition | route, cache state, region, origin pool, size | Locate where response time changed |
| Cache efficiency | eligibility, outcome, content class, key version | Reduce avoidable origin work without harming freshness |
| Security action review | rule ID, action, route, client network, result | Find attacks, drift, and false positives |
| Pipeline quality | provider, schema, adapter, lag, parse result | Know whether every other chart is trustworthy |
Control cardinality without losing evidence
Dashboards and metrics should use bounded dimensions such as route group, result class, cache class, region, service, and provider. Keep request ID, raw path, client address, user agent, and exact rule values in an event store for investigation. Creating permanent time-series labels from raw values makes monitoring expensive and unstable.
Normalize route patterns at ingestion with versioned application-owned logic. Store sensitive raw values only where an approved use case requires them, with separate access and retention. A useful analytical model is intentional about both information and omission.
Treat data quality as part of the answer
Every edge dashboard should surface freshness and coverage. A missing stream can make error rate appear to drop, and a parser failure can move records into an “unknown” class that hides impact. Track unknown enum values, null-rate changes, record-size anomalies, and provider-to-routing share differences. Annotate or suppress automated comparisons when the source data is unhealthy.
Start with the CDN logging fundamentals guide, then use the reference event schema to build a field contract. The objective is not a larger log index. It is a reliable explanation that leads to a safer configuration, faster incident response, or clearer service decision.
Turn edge events into a governed analytical model.
Use the reference schema to align provider adapters, dashboards, investigations, and retention.