Erreurs réseau
Les requêtes vers votre site qui ont échoué, signalées par le navigateur. Des échecs que vos logs serveur ne peuvent pas contenir, faute de requête arrivée.
Dernière mise à jour:
Les requêtes en échec vers votre site, signalées via Network Error Logging.
La raison d'y prêter attention, vos logs serveur ne contiennent que les requêtes qui ont atteint votre serveur. Voici celles qui ne l'ont pas atteint.
Colonnes
| Colonne | Signification |
|---|---|
| Type | Le type d'erreur retenu par le navigateur |
| Phase | Où la requête a échoué, DNS, connexion ou application |
| Origine de la requête | L'origine demandée |
| Navigateurs | Les navigateurs qui l'ont signalée |
| Reports | Les reports regroupés dans cette ligne |
| Dernière occurrence | L'occurrence la plus récente |
Pas de colonne Disposition, une erreur réseau n'est pas le résultat d'une politique.
Le détail donne directement des lignes au niveau requête, avec URL de la requête, IP du serveur, Protocole, Méthode et Code de statut. Un code de statut vide signifie que la réponse n'est jamais allée assez loin pour en avoir un.
Utiliser Phase pour orienter le problème
Le filtre Toutes les phases a trois valeurs fixes, et chacune désigne une équipe différente.
| Phase | A échoué à | Signifie en général |
|---|---|---|
dns | La résolution de nom | Une erreur de configuration DNS, un enregistrement expiré, ou un résolveur en difficulté dans une région |
connection | TCP ou TLS | Des erreurs de certificat, une négociation de protocole, un pare-feu ou un souci de peering |
application | Après la connexion | La réponse elle-même a échoué ou a été tronquée |
Filtrez d'abord par phase. Un groupe dns et un groupe application n'ont rien à voir l'un avec l'autre et vont à des personnes différentes.
Lire la géographie
Des erreurs réseau concentrées sur une région ou un réseau ne sont en général pas à vous de les corriger directement, mais elles sont à vous de les connaître. Un résolveur en panne dans un pays produit une panne totale pour ces utilisateurs et un silence complet dans votre propre monitoring.
Recoupez avec IP du serveur dans la vue de détail quand vous exploitez plusieurs points de présence. Une seule IP à l'origine de tous les échecs restreint immédiatement la recherche.
Les compteurs sont des planchers
Un navigateur ne peut livrer un report que lors d'une connexion réussie ultérieure. Les utilisateurs qui ne reviennent jamais ne remontent rien, le nombre réel d'échecs est donc supérieur à ce que vous voyez, et l'écart est maximal pendant une panne totale, quand le reporting lui-même ne passe plus.
Les tendances ont du sens, les totaux absolus non. Un trou dans le graphique pendant un incident est une preuve de l'incident, pas la preuve qu'il a cessé.
Ajuster le volume
NEL ne remonte quoi que ce soit que si NEL et Report-To sont bien présents sur la réponse du document. Le vérificateur de configuration de la Reporting API les relit depuis une URL publique, c'est le moyen le plus rapide d'écarter cette cause quand cette page reste vide.
failure_fraction dans votre header NEL contrôle la proportion des échecs que les navigateurs signalent. Le header généré la fixe à 1.0, c'est-à-dire tous :
NEL: {"report_to":"default","max_age":10886400,"failure_fraction":1.0}Sur un site à fort trafic, cela peut consommer l'essentiel de votre quota de reports. Baissez-la pour échantillonner les échecs au niveau du navigateur plutôt qu'à l'ingestion. Voir Consommation et limites.