---
title: "Construire une chronologie d'incident unifiée entre CDN, WAF, DNS et origine"
description: "Corrélez les preuves CDN, WAF, DNS, bots, DDoS et origine dans une chronologie d'incident défendable, avec provenance, niveaux de confiance, contrôles de confidentialité et workflow SRE."
canonical_url: https://optimi.com/fr/guides/unified-incident-timeline-cdn-waf-dns-origin
md_url: https://optimi.com/fr/guides/unified-incident-timeline-cdn-waf-dns-origin.md
last_updated: 2026-07-15
---

# Construire une chronologie d'incident unifiée entre CDN, WAF, DNS et origine

Une chronologie unifiée préserve les preuves sources tout en indiquant quelles relations sont exactes, déduites ou seulement proches dans le temps. Cette distinction empêche un tableau de bord d'inventer une cause racine.

Des consoles fournisseurs distinctes transforment une panne en récits concurrents. Un CDN peut montrer des manques de cache, un WAF des blocages, le DNS un changement de réponse et l'origine des délais d'attente. L'objectif n'est pas un flux de journaux unique et plat. C'est un dossier d'incident attribué à ses sources, capable de montrer ce qui s'est produit, quand cela a été observé et avec quel niveau de confiance les événements sont liés.

## Résultat

Définissez un modèle de preuves respectueux de la confidentialité pour les événements DNS, CDN, WAF, bots, DDoS et origine, puis utilisez-le pour investiguer un impact visible par les utilisateurs, de l'edge jusqu'à l'application.

## Préservez la provenance avant de normaliser les champs

Conservez l'événement original, l'horodatage source, l'horodatage de collecte, le fournisseur, le compte et la version du schéma. Le modèle de journaux OpenTelemetry distingue `Timestamp` de `ObservedTimestamp` ; cela compte lorsque les retards de streaming ou la dérive d'horloge modifient l'ordre dans lequel un opérateur voit les preuves.

**Le chemin des preuves d'incident**

1. Événements sources — Les signaux DNS, requêtes edge, WAF, bots, origine et configuration arrivent.
2. Preuves brutes — Les charges utiles source immuables restent contrôlées par les accès.
3. Enveloppe normalisée — Les horodatages, routes, résultats, fournisseurs et identifiants sont mappés.
4. Corrélation — Les ID exacts et les inférences bornées reçoivent des niveaux de confiance.
5. Chronologie d'incident — Impact, changements, hypothèses et preuves de reprise restent ensemble.

*Les preuves brutes restent accessibles tandis qu'un flux normalisé permet les questions inter-fournisseurs et un niveau explicite de confiance dans la corrélation.*

**Une chronologie unifiée rend explicite la confiance dans les preuves**

![Un organigramme montrant les événements DNS, CDN, WAF, origine et changements de configuration conservés comme preuves brutes contrôlées par les accès, mappés dans une enveloppe normalisée, puis reliés à une chronologie d'incident par des relations exactes, de forte inférence ou de contexte temporel.](/diagrams/unified-incident-timeline-cdn-waf-dns-origin/evidence-confidence.svg)

*Préserver la provenance avant la corrélation permet aux opérateurs de combiner les preuves fournisseurs sans présenter une inférence comme une causalité établie.*

## Corrélez sans inventer de causalité

Utilisez un ID de requête applicatif avec espace de noms ou un `traceparent` W3C pour une jointure exacte. Un ID de requête fournisseur peut créer un lien fort au sein du même fournisseur. Les preuves DNS ne peuvent généralement pas être rattachées à une requête HTTP unique ; associez-les par nom interrogé, périmètre de résolveur ou de client, réponse et fenêtre temporelle bornée, puis qualifiez-les de contextuelles plutôt que d'exactes.

| Confiance | Preuve | Affirmation sûre |
| --- | --- | --- |
| Exacte | Même ID de trace ou ID de requête immuable avec espace de noms | « Ces événements décrivent la même requête. » |
| Forte inférence | Même ID fournisseur, zone et service | « La décision WAF est liée à cette requête edge. » |
| Contexte temporel | Même nom d'hôte et fenêtre d'incident bornée | « La défaillance DNS a précédé l'augmentation des erreurs edge. » |
| Agrégat | Tendance régionale correspondante uniquement | « Ces signaux ont changé ensemble ; l'investigation se poursuit. » |

**Événement normalisé représentatif**

```
{
  "event.type": "waf.decision",
  "event.time": "2026-07-15T10:12:08Z",
  "event.observed_time": "2026-07-15T10:12:10Z",
  "source.vendor": "edge-provider",
  "correlation.request_id": "edge:req_01...",
  "correlation.confidence": "strong_inference",
  "http.route": "/checkout/confirm",
  "security.action": "block",
  "raw.reference": "restricted://incident/INC-42/event/991"
}
```

## Donnez au DNS sa propre logique

Ne qualifiez pas toute absence d'enregistrement de panne DNS. La RFC 2308 distingue `NXDOMAIN` de `NODATA` ; `SERVFAIL`, le délai d'attente, l'état du cache, le TTL et le point de vue faisant autorité ou récursif modifient également le diagnostic. Les journaux de requêtes de résolveur peuvent omettre les répétitions servies depuis le cache ; la couverture et la fraîcheur doivent donc figurer dans la chronologie avec le code de réponse.

## Exécutez un workflow d'incident centré sur l'impact

Partez d'un parcours utilisateur segmenté par nom d'hôte, route, région, état de cache et statut. Déclarez tôt lorsque l'impact client est visible ou que davantage d'équipes sont nécessaires. Attribuez les responsabilités de conduite, opérations, communication et planification ; consignez les changements de configuration et les atténuations sur la même chronologie UTC ; préservez les preuves avant l'expiration des fenêtres de conservation.

MYO peut être décrit sans risque comme apportant des journaux edge quasi temps réel, à fidélité complète, dans des tableaux de bord inter-fournisseurs avec des alertes personnalisées et une visibilité sur WAF, bots et DDoS. Il ne rend pas chaque événement fournisseur joignable à une requête ; les preuves d'incident ont donc toujours besoin du modèle de confiance ci-dessus.

## Contrôles de qualité de la chronologie

- Suivez la fraîcheur de la télémétrie comme `heure observée - heure source`, pas seulement la disponibilité du tableau de bord.
  - Restreignez les en-têtes bruts, cookies, jetons, URL complètes et identifiants clients ; utilisez des modèles de routes et des listes d'autorisation.
  - Considérez les en-têtes de trace publics comme non fiables à l'edge et ne placez jamais de données personnelles dans le contexte de trace.
  - Alertez lorsque les mappages échouent, que le volume source diminue ou que la couverture de corrélation exacte s'effondre.

## Guides associés

- [Plan de réponse aux incidents de sécurité d'un site web](/fr/guides/website-security-incident-response)
- [Observabilité Kubernetes](/fr/guides/kubernetes-observability)
- [Architecture edge mondiale](/fr/guides/global-edge-architecture)

## Références faisant autorité

- [OpenTelemetry Logs Data Model](https://opentelemetry.io/docs/specs/otel/logs/data-model/)
- [W3C Trace Context](https://www.w3.org/TR/trace-context/)
- [Google SRE Book: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [RFC 2308: Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308.html)
- [Cloudflare Logpush HTTP requests fields](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/zone/http_requests/)

[Examiner votre visibilité sur les incidents](/fr/contact): Fondez les incidents inter-fournisseurs sur les preuves — Optimi aide les équipes à assembler une vue opérationnelle unique à partir des signaux edge, sécurité, DNS et origine, sans masquer le contexte source.