The moment a second CDN carries production traffic, your observability has a schema problem: two log formats, two delivery mechanisms, two definitions of the same metric. The unification layer is unglamorous engineering that decides whether multi-CDN is operable or merely configured.
The schema mapping problem
Every provider logs the same physics under different names, with different units, timestamp formats, and cache-status vocabularies (one vendor’s HIT taxonomy is another’s four distinct states). Build a canonical schema, request time, edge POP, cache status normalized to a small enum, timing breakdown, bytes, status, and map every provider into it at ingest. Resist enriching with provider-specific extras in the core schema; park them in vendor-namespaced fields so queries stay portable.
Delivery mechanics and lag
Log transport ranges from real-time streaming (seconds) to batched object-storage drops (minutes to much worse), and mixed lag is operationally poisonous: your unified dashboard shows one provider’s incident and the other’s history. Normalize on the slowest common freshness for comparative views, keep a real-time lane per provider for incident response, and alarm on log-delivery lag itself, silent log stoppage during an incident is a second incident.
The quiet payoff of unified logs is contractual, not just operational: when you can produce provider-comparable percentiles from your own pipeline, every vendor conversation changes register. Performance disputes stop being dashboard-versus-dashboard theology and become queries against neutral data; SLA claims get verified rather than trusted; and renewal negotiations open with your measurements on the table, which our commercial articles keep identifying as the posture that moves prices. Observability engineering rarely makes the procurement business case, but in multi-CDN estates it is procurement infrastructure, and the estates that treat it that way negotiate from a different altitude.
Sampling and honesty
At volume you will sample; the sin is sampling differently per provider and comparing the results as equals. Fix sampling rates centrally, sample deterministically (hash of request ID, not random per pipeline) so cross-provider joins survive, and always retain full-fidelity error and slow-request lanes, the tails are where decisions live, and tails are what naive sampling amputates first.
In practice
Stand the pipeline up before the second provider takes real traffic, not after: canonical schema, per-provider mappers, freshness monitors, one dashboard where hit ratio and p95 read identically regardless of who served. Then run a weekly cross-provider report from it, per-region percentiles, cache efficiency, error taxonomy, because that report is the steering data your DNS layer and your renewal negotiations both feed on.
Our multi-CDN engagements ship the canonical schema and mappers as deliverables. The dashboard is the deliverable.