Cloudflare perd 55 % des journaux de ses clients après une mauvaise configuration

2024-11-14 · Éditeur : Cloudflare · Domaine : Cloud & DevOps

Le 14 novembre 2024, un bug de configuration chez Cloudflare surcharge son pipeline de journaux : environ 55 % des journaux normalement envoyés aux clients sont perdus pendant 3 h 30 environ.

Ce qui change

  • Environ 55 % des journaux destinés aux clients ont été perdus, pendant environ 3 h 30.
  • Une configuration vide a fait basculer le composant Logfwdr en mode « fail open » pour tous les clients.
  • Le composant Buftee a créé environ 40 fois plus de tampons que la normale.
  • Cloudflare ajoute des alertes et des tests de surcharge réguliers.

### Ce qui change Le 14 novembre 2024, Cloudflare subit un incident sur ses services **Logs** et **Logpush**, qui acheminent les journaux de trafic vers les outils de ses clients (SIEM, observabilité). L'incident dure environ **3 h 30** et, selon le post-mortem publié le 26 novembre, « environ 55 % des journaux que nous envoyons normalement aux clients n'ont pas été envoyés et ont été perdus » (« about 55% of the logs we normally send to customers were not sent and were lost »). ### Caractéristiques - Cause 1 : un bug dans le système de configuration a produit une configuration vide pour le composant Logfwdr, indiquant qu'aucun client n'avait de journaux à pousser. - Cause 2 : un mécanisme de sécurité « fail open » de Logfwdr a réagi en transférant les journaux de tous les clients, et non des seuls clients configurés. - Cause 3 : le composant tampon Buftee n'avait pas de garde-fou suffisant et a créé environ 40 fois plus de tampons que la normale, jusqu'à saturation. - Remédiation : alertes sur les mauvaises configurations, correction du bug avec tests, et « tests de surcharge » réguliers pour simuler des défaillances en cascade. ### Pourquoi c'est important Les journaux sont la matière première de la détection de sécurité et de la preuve de conformité. Une perte silencieuse de plus de la moitié d'entre eux, côté fournisseur, laisse des trous que le client ne peut pas combler après coup. Pour les équipes SRE, c'est un rappel que la chaîne d'observabilité est elle-même un système à surveiller : des alertes sur les volumes reçus, et pas seulement sur les volumes émis. ### À retenir Un pipeline d'observabilité en panne ne produit pas d'alerte : la perte de données ne se voit que si l'on compare ce qui arrive à ce qui devrait arriver.

Liens

Tags : Incident, Observabilité, Edge, Sécurité