Guide d'observabilité

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.

Publié le: 15 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 13 min de lecture

Sur cette page

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.

Overview

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

Événements sources
Les signaux DNS, requêtes edge, WAF, bots, origine et configuration arrivent.
Preuves brutes
Les charges utiles source immuables restent contrôlées par les accès.
Enveloppe normalisée
Les horodatages, routes, résultats, fournisseurs et identifiants sont mappés.
Corrélation
Les ID exacts et les inférences bornées reçoivent des niveaux de confiance.
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

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.

Telecharger:PNG SVG

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.

Troubleshooting

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

Références faisant autorité

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.

Examiner votre visibilité sur les incidents