Performance and security monitoring usually run as separate workflows, but they draw on the same CDN log stream, and the signals that matter most only appear when you read them together. This guide shows how to build one log pipeline that serves both teams.
TL;DR
- One log stream feeds both performance and security monitoring. The split is a schema problem.
- P99 latency, cache hit ratio, and IP concentration all live in the same raw CDN log.
- A latency spike before a 4xx surge is the low-and-slow attack signal neither team catches alone.
- Build the composite alert first: P99 rising while 4xx concentrates from a narrow IP range.
- Unified monitoring earns its overhead at multi-CDN, multi-terabyte scale; simpler setups work below 1TB per day.
Performance and security monitoring usually run as separate workflows, but they draw on the same CDN log stream — and the signals that matter most only appear when you read them together. This guide shows how to build one log pipeline that serves both teams.
TL;DR
- One log stream feeds both performance and security monitoring. The split is a schema problem.
- P99 latency, cache hit ratio, and IP concentration all live in the same raw CDN log.
- A latency spike before a 4xx surge is the low-and-slow attack signal neither team catches alone.
- Build the composite alert first: P99 rising while 4xx concentrates from a narrow IP range.
- Unified monitoring earns its overhead at multi-CDN, multi-terabyte scale; simpler setups work below 1TB per day.
The CDN Log Fields That Serve Both Security and Performance
Every CDN log line contains more signal than most teams use. Before separating performance from security, capture all of it.
Capture these fields to support both performance and security queries:
- Status code: The most obvious field. A 200 is a performance data point; a spike in 429s or 403s is a security one.
- Cache status: Hit, miss, expired, or bypass. Performance teams track hit ratio; security teams watch for miss storms on non-cacheable paths, which indicate cache poisoning probes.
- Edge latency and origin latency: Two separate fields. Edge latency is delivery; origin latency is where the problem lives when edge is healthy.
- Client IP: Both a performance routing signal and the variable for IP concentration analysis during a DDoS.
- Request path and referrer: Performance teams ignore referrer; security teams use it to identify hotlinking, scraping, and credential stuffing patterns.
- User agent: Performance teams might parse it to detect DDos attacks; security teams use entropy changes as a bot flood signal.
- Bytes served: Payload bloat proxy for performance; abnormally small responses on normally large resources can indicate cache poisoning.
- Protocol version: HTTP/1.1, HTTP/2, HTTP/3. The W3C Server-Timing header lets CDNs pass performance data directly into the log stream: cache hit or miss, origin latency, edge processing time. Capture it.
- Alt-Svc negotiation fields: CDNs use the Alt-Svc header to advertise HTTP/3 availability. Protocol fallback rates (QUIC to TCP) are now a distinct observable class. An unexpected fallback spike is worth alerting on.
Performance Signals Worth Tracking
Four metrics belong on every CDN performance dashboard. Anything fewer and you’re missing a signal class.
- P99 edge latency by region: Not average latency, not P50. P99 captures the tail that average hides. A region where P99 climbs while P50 holds flat points to a routing anomaly or an edge node under stress. Passive measurement of existing TCP and DNS traffic accurately predicts network latency without synthetic probe overhead. That matters when tracking latency across dozens of edge nodes continuously.
- Cache hit ratio by provider: Target above 95 percent. A sustained drop signals a cache invalidation wave, a configuration change, or a probe pattern you haven’t named yet. Track it per-provider, not as an aggregate, to isolate which CDN is underperforming.
- Error rate, 4xx and 5xx split: A 4xx rise is client-side or access-control behavior; a 5xx rise is origin or edge failure. The split matters because they require different responses and come from different parts of the stack.
- Bytes per request: A proxy for payload bloat. If average bytes served on a specific path rises without a deployment, something changed upstream. If it drops sharply, a cache is serving stale or partial content.
At terabyte scale, these metrics are only useful when queried fast enough to act. During Super Bowl LIX, Hydrolix ingested nearly 200 terabytes of CDN log data from multiple providers in 3.5 hours. Time from ingest to visualization ran 5 to 10 seconds. Sub-second query performance held across petabytes of data and tens of millions of events per second.
Security Signals Worth Tracking
The security signals live in the same fields. You are not adding new data; you are adding new queries.
- 4xx burst rate: A surge in 400-level errors from a narrow set of IPs in a short window is the primary DDoS indicator available in CDN logs. Threshold it on rate per second, not raw count.
- IP concentration ratio: What fraction of requests in a 5-minute window come from fewer than 10 unique IPs? A high concentration ratio with normal total traffic volume is the signature of a low-and-slow attack designed to stay below volumetric thresholds.
- User-agent entropy: In normal traffic, user agents distribute across browser versions, OS combinations, and bots. A sudden drop in entropy (traffic concentrating on one or two user-agent strings) signals a bot flood. Track it as a rolling baseline deviation, not an absolute value.
- Cache miss storms on non-cacheable paths: When requests for non-cacheable resources (API endpoints, authenticated pages) spike in miss volume, someone is systematically probing the cache boundary. Miss volume spikes on those paths are the early signature of cache poisoning attempts.
- Origin TLS error rate: CDN-to-origin back-end communication carries known TLS vulnerabilities in certificate validation. An origin TLS error rate above 0.5 percent is not a certificate expiry problem to queue for next week; it is a monitoring gap that an attacker can exploit.
Two compliance requirements make this data retention non-optional. PCI DSS v4.0 requirements 6.4.3 and 11.6.1 mandate monitoring for unauthorized changes to client-side scripts on e-commerce traffic. CDN logs are the audit trail. DORA, effective January 2025, requires financial entities and their ICT third-party providers to document operational resilience risks and produce incident logs as evidence. CDNs fall within scope as ICT providers. A log pipeline that samples or aggregates destroys both audit trails.
The Elkjøp case makes the detection value concrete. During Black Friday, TrafficPeak identified a DDoS attack from 3,000 IP addresses across 80 countries in real time, with no business impact. That detection speed comes from having the IP concentration and 4xx burst signals queryable in real time, not from a separate security product.
The Combined Dashboard Layout That Works
Arrangement determines whether the cross-domain signal is visible at all.
The Four-Panel Layout
A single dashboard needs four panels:
- P99 edge latency by region: The performance anchor. Color-coded by threshold breach.
- Cache hit ratio by provider: Per-CDN breakdown. Drop below 80 percent triggers a visual flag.
- 4xx burst rate overlaid with IP concentration ratio: This is the panel neither a pure performance dashboard nor a pure security dashboard shows. The overlay is the whole point.
- Origin error rate by type: TLS errors, timeout errors, and 5xx responses in three separate lines on one chart.
The Overlap Panel
Panel 3 is where the two workflows converge. A 4xx burst rate rising while IP concentration ratio climbs means traffic is concentrating, which is a security signal. The same panel shows when concentrated traffic starts driving P99 up. A flooded edge node is both a security event and a performance event.
Watch for P99 latency rising 2 to 5 minutes before the 4xx burst rate crosses threshold. The 2-to-5-minute lead identifies a low-and-slow attack ramping up before it saturates the origin. A performance team running only latency dashboards sees the P99 move and opens an origin ticket. A security team running only 4xx dashboards sees the burst and opens an access-control ticket. Neither sees the 2-to-5-minute lead.
What Unified Visibility Changes Operationally
Paramount consolidated real-time CDN logs from multiple providers into a single monitoring view and cut multi-CDN costs by more than 50 percent while increasing retention 6x. That gave them a single dataset to compare provider performance and shift traffic based on evidence. Navy Federal Credit Union deployed an observability platform across cybersecurity, cloud network engineering, and digital banking teams. Resolution time fell from hours to minutes. Responders stopped cross-referencing two separate systems. The performance degradation and the security event became the same record.
Alerts to Wire Up for Each Side
Performance Alerts
- P99 edge latency > 250ms sustained for 5 minutes
- Cache hit ratio < 80 percent for 10 minutes
- 5xx error rate > 1 percent for 3 minutes
Security Alerts
- 4xx burst rate > 500 per second from fewer than 10 unique IPs
- User-agent entropy drop below 7-day rolling baseline for 15 minutes
- Origin TLS error rate > 0.5 percent
The Cross-Domain Alert
P99 latency increasing while 4xx rate climbs from a narrow IP range, both conditions true simultaneously. Wire this as a composite alert, not two separate ones. The composite condition is the low-and-slow attack signal; the individual conditions are noise.
With 20.5 million blocked attacks in Q1 2025 alone, volume-only thresholds generate alert fatigue by design. The composite condition cuts the false positive rate because it requires the security signal and the performance signal to appear together. A legitimate traffic spike drives P99 up but does not concentrate IP distribution. An attack does both.
Things to Watch Out For Mixing Security and Performance Monitoring
Combining these workflows surfaces three technical problems worth solving before you build.
Schema mismatch across providers. Akamai, Cloudflare, and Fastly use different field names for the same concept. Cache status alone has multiple naming conventions across providers. Normalization must happen at ingest, not at query time. A query-time join across provider-specific schemas adds latency and produces inconsistent results when field definitions drift between provider log versions.
Log volume economics. With solutions that aren’t designed to efficiently handle massive volumes of full-fidelity data, retaining raw CDN logs in high-performance, high-cost storage for security forensics is not viable at 200TB per event window. Aggregating or sampling the data to reduce cost destroys the forensic record that PCI DSS and DORA require. The solution is full-fidelity storage that maintains fast query performance regardless of data age, not a forced choice between retention and cost. Passive measurement of CDN latency using DNS and TCP traffic adds no network overhead and works alongside encrypted QUIC sessions. That matters as HTTP/3 adoption removes fields that deep packet inspection once relied on.
Protocol opacity from QUIC and TLS 1.3. As CDNs migrate from HTTP/2 to HTTP/3, some fields that exist in TCP-era logs disappear or change form. Plan schema versioning before the migration, not after. Know which fields your security queries depend on and verify they survive the protocol upgrade.
For organizations processing under 1TB of CDN logs per day, the normalization and ingest pipeline overhead costs more in engineering time than the correlation value it produces. At that scale, per-provider log forwarding to an existing SIEM is faster to operate. The unified approach earns its complexity at multi-CDN, multi-terabyte volumes.
See Performance and Security in One place With Hydrolix CDN Insights
Teams use Hydrolix CDN Insights to implement what we talk about in this guide. Pre-built dashboards normalized across Akamai, Cloudflare, CloudFront, Fastly, and Tencent cover approximately 80 percent of global CDN traffic in a single schema. The schema mismatch problem is handled at ingest, not pushed to your query layer. Full-fidelity log retention with 20x to 50x compression preserves the complete record. Forensic queries run against months of logs on petabytes of data, with sub-second response, without a separate archival pipeline. That retention posture directly satisfies DORA incident documentation requirements and the PCI DSS audit trail mandated by requirements 6.4.3 and 11.6.1, without a separate compliance storage layer.
How long should I retain CDN logs for DORA and PCI DSS v4.0 compliance?
DORA requires financial entities to maintain incident logs for the duration of the service relationship, while PCI DSS v4.0 mandates a 12-month audit trail with three months immediately available. In Hydrolix, you can retain full-fidelity logs for years using high-density compression to keep storage costs predictable.
How do I normalize field names across Akamai, Cloudflare, and Fastly?
Normalization should happen at the ingest layer rather than during queries to avoid performance lag. Use a unified schema that maps provider-specific terms, such as Cloudflare’s CacheCacheStatus and Akamai’s X-Cache-Remote, into a single cache_status field. Hydrolix CDN Insights provides pre-built collectors that handle this mapping for 80 percent of global CDN traffic.
Does passive measurement replace synthetic probing for tracking edge latency?
Passive measurement supplements synthetic probing by analyzing existing TCP and DNS traffic to predict network latencies without adding overhead. While synthetics provide a clean baseline from specific locations, passive measurement captures the actual experience of every user. This is critical for continuous, on-the-fly monitoring across thousands of edge nodes simultaneously.
How can I reduce false positives in 4xx burst-rate alerts?
To reduce noise, transition from raw count thresholds to a composite alert that requires both a 4xx surge and a high IP concentration ratio. Legitimate traffic spikes typically show a broad distribution of unique IPs, whereas DDoS attacks often concentrate millions of requests into a narrow range of addresses.
What happens to CDN monitoring when migrating from HTTP/2 to HTTP/3?
The migration to HTTP/3 and QUIC reduces the visibility of certain network-layer fields once accessible via deep packet inspection. You must verify that your security queries rely on application-layer headers like Alt-Svc and Server-Timing rather than transport-layer data. Plan schema versioning before the migration to ensure your 4xx and latency signals remain queryable.
