Qu'est-ce que NEL, le network error logging du navigateur

Vos logs serveur ont un angle mort : ils ne peuvent enregistrer que les requêtes qui ont atteint votre serveur. Les requêtes qui ont échoué à la résolution DNS, pendant le handshake TLS, ou parce que la connexion a été réinitialisée n'arrivent jamais, donc vous ne les enregistrez jamais, même si l'utilisateur a subi une erreur. Network Error Logging (NEL) comble ce manque. Il demande au navigateur de rapporter ces échecs côté client à un endpoint que vous contrôlez, depuis le seul endroit qui peut les voir : le navigateur de l'utilisateur.

Ce que NEL vous apporte

NEL collecte le résultat des requêtes réseau, les échecs DNS, les erreurs TLS et de connexion, les réinitialisations, et les réponses HTTP en erreur, et les rapporte à votre endpoint. C'est de l'observabilité, pas de l'application : il ne bloque ni ne modifie jamais une requête, il vous dit seulement ce qui s'est passé. Cela en fait le compagnon, au niveau réseau, des rapports de politique comme la CSP, et la référence complète est la page de la politique NEL.

Le hic, c'est que les données vivent sur le client, donc vous n'apprenez les échecs que depuis les navigateurs qui prennent en charge NEL et seulement au taux d'échantillonnage que vous configurez. Considérez-le comme un large signal d'alerte précoce, pas comme un décompte complet de chaque requête échouée.

Comment l'activer

NEL est la seule fonctionnalité de reporting qui utilise encore le header Report-To historique plutôt que Reporting-Endpoints, donc il faut deux headers qui fonctionnent ensemble. Report-To définit un groupe nommé et l'endroit où il envoie ; le header NEL active le logging, pointe vers ce groupe, et définit les taux d'échantillonnage.

Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}

NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0}

Les deux fractions contrôlent le volume. Mettez failure_fraction à 1.0 pour rapporter chaque échec, puisque les échecs sont ce qui vous intéresse et restent relativement rares. Gardez success_fraction à 0 ou très bas : un site fréquenté a bien plus de succès que d'échecs, et les échantillonner à un taux significatif inonde votre endpoint. max_age définit combien de temps le navigateur mémorise la politique, et include_subdomains l'étend à vos sous-domaines.

À quoi ressemble un rapport

Le navigateur envoie un rapport network-error qui nomme la phase de la requête qui a échoué (dns, connection, ou application) et un type d'erreur précis, ainsi que des détails de timing et de protocole.

{
  "type": "network-error",
  "body": {
    "phase": "application",
    "type": "http.error",
    "status_code": 400,
    "protocol": "http/1.1",
    "server_ip": "192.0.2.172",
    "elapsed_time": 338
  }
}

Le champ phase est le tri le plus rapide : un échec dns pointe vers la résolution de nom, connection vers le TCP ou le TLS, et application vers une erreur de niveau HTTP renvoyée par votre serveur (ou un CDN devant lui).

Quand cela en vaut la peine

NEL gagne sa place en faisant remonter des problèmes que votre propre supervision ne peut pas voir : une mauvaise configuration TLS qui n'affecte que l'edge CDN d'une région, un souci DNS sur un résolveur particulier, ou des réinitialisations de connexion depuis un réseau précis. Comme les rapports viennent d'utilisateurs réels, vous découvrez un edge cassé avant qu'il n'apparaisse sous forme de ticket de support. Un pic soudain d'échecs TLS ou de connexion depuis une même zone peut aussi être le signe d'une interception ou d'un portail captif qui altère le trafic.

NEL est expérimental et ne fonctionne actuellement que dans les navigateurs basés sur Chromium, Firefox et Safari ne l'implémentent pas. Considérez-le comme un signal utile sur une partie de votre trafic, pas comme une image complète.

Le collecter sans backend

Les rapports NEL utilisent le même mécanisme de livraison que vos autres rapports navigateur, donc ils arrivent dans un seul flux. Pointez l'endpoint Report-To vers CentralCSP pour collecter et visualiser les erreurs réseau à côté de vos rapports CSP et autres, au lieu de monter un pipeline distinct rien que pour NEL.

Les requêtes en échec groupées par type d'erreur et par phase, avec des lignes dns, connection et application et leur nombre de rapports

Étapes suivantes

Comprenez les deux headers de reporting dans Report-To vs Reporting-Endpoints.
Voyez le rapport network-error complet.
Mettez le reporting en place de bout en bout : comment configurer la Reporting API.

Surveillez les échecs réseau côté client.