Lorsqu'il s'agit de la gestion de propriétés Internet, la différence entre un petit souci technique et un incident majeur est souvent une affaire de rapidité. La diffusion proactive d'alertes joue un rôle crucial ; c'est pourquoi nous sommes ravis de lancer les notifications HTTP Error Rate, qui permettent aux administrateurs d'être informés des erreurs que rencontrent les utilisateurs finaux.
Mais qu'en est-il des problèmes qui ne se manifestent pas sous forme d'erreurs, à l'image d'une baisse soudaine du trafic ou d'un pic de trafic ?
Aujourd'hui, nous sommes ravis d'annoncer la disponibilité des notifications d'anomalies de trafic pour les clients Enterprise. Ces notifications se déclenchent lorsque Cloudflare détecte des changements inattendus du trafic, vous offrant ainsi une précieuse nouvelle perspective de l'intégrité de vos systèmes.
Des changements inattendus du trafic peuvent être révélateurs d'un certain nombre de choses. Si vous gérez un site d'e-commerce et vous constatez un pic de trafic, c'est peut-être une bonne nouvelle : les clients affluent vers votre site de vente, ou votre publicité vient d'être diffusée pendant une émission de télévision très regardée. Toutefois, cela peut aussi signifier qu'un problème est survenu : un utilisateur a peut-être accidentellement désactivé une règle de pare-feu, et ce que vous observez maintenant est un afflux de trafic malveillant. Quoi qu'il en soit, peut-être souhaitez-vous être informé qu'un changement s'est produit.
De même, une baisse soudaine du trafic peut avoir de nombreuses significations. Peut-être est-ce le vendredi après-midi, et vos collaborateurs se déconnectent et n'accèdent plus au site web de votre entreprise. En revanche, peut-être qu'un lien vers votre site ne fonctionne plus, empêchant vos clients potentiels d'y accéder. Chaque minute pendant laquelle le trafic est faible pourrait entraîner une perte de revenus potentielle ; vous avez donc tout intérêt à être informé le plus rapidement possible de la situation, afin de mener l'enquête.
Comment savons-nous quand vous alerter ?
Calculer efficacement des anomalies dans des séries de données temporelles est une tâche difficile. La méthode la plus simple consiste à utiliser des seuils de base. Toutefois, comme nous l'avons mentionné dans un précédent article de blog, les seuils simples s'avèrent peu précis lorsqu'il s'agit de déterminer l'existence avérée d'un problème. Le nombre de cas limites est trop élevé pour que cette approche soit efficace.
En revanche, calculer les anomalies dans les erreurs HTTP est une tâche relativement facile. Nous savons qu'en règle générale, le nombre d'erreurs devrait être très faible ; aussi, tout pic constitue un problème et doit donc faire l'objet d'une alerte. C'est pourquoi nous utilisons les objectifs de niveau de service (Service Level Objectives, SLO) pour calculer les anomalies pour nos notifications HTTP Error Rate.
Cependant, le déroulement de l'analyse du trafic HTTP est semblable à l'approche mise en œuvre par les événements de sécurité Cloudflare : il existe une base de référence générale d'événements qui est calculée à partir des tendances historiques. Tout écart par rapport à cette base de référence peut faire l'objet d'une alerte. En raison de ces similitudes, nous avons décidé d'utiliser les mêmes calculs pour les notifications d'anomalies de trafic que pour les notifications d'événements de sécurité : les cotes z. Il s'agit d'une comparaison de la valeur actuelle avec la moyenne sur une période donnée. La cote z correspond au nombre d'écarts-types par rapport à la moyenne de la valeur actuelle.
Pour les notifications d'anomalies de trafic, nous comparons le trafic au cours des 5 dernières minutes (l'intervalle court) à la moyenne du trafic des 4 dernières heures (l'intervalle long). Des cotes z positives indiquent un pic, et des cotes z négatives indiquent une baisse. Si la valeur actuelle s'écarte de plus de 3,5 écarts-types de la moyenne, nous transmettons une alerte. Nous effectuons des mesures toutes les 5 minutes, ce qui nous permet d'être alertés en temps utile en cas de hausse ou de baisse du trafic.
Si nos notifications d'événements de sécurité se déclenchent uniquement en présence d'un pic d'événements de sécurité (une baisse est presque toujours une bonne nouvelle), dans le cas des anomalies du trafic, nous transmettons des notifications à la fois pour les pics et pour les baisses. En effet, une baisse du trafic HTTP est probablement révélatrice d'un problème, tandis qu'un pic peut être une bonne ou mauvaise nouvelle.
À l'instar des événements de sécurité, les notifications d'anomalies de trafic prennent en charge des seuils minimaux. Ainsi, même si nous déterminons qu'un événement se situe au-delà de 3,5 écarts-types, si le nombre d'événements est insignifiant, nous ne transmettons pas d'alerte. Un pic doit être constitué d'au moins 200 requêtes, et une baisse doit représenter une chute d'au moins 200 requêtes. Cela permet d'éliminer le bruit des notifications, puisque nous ne transmettons pas d'alerte en cas de pics ou de baisses de moindre importance.
Approfondissons un peu
Cloudflare stocke des statistiques échantillonnées sur les requêtes qui transitent sur son réseau dans Clickhouse. Toutes les minutes, nous échantillonnons le trafic HTTP dans Clickhouse et le stockons dans une instance de VictoriaMetrics, une solution de stockage de données chronologiques. VictoriaMetrics nous fournit gratuitement des fonctions algorithmiques prêtes à l'emploi et s'est avérée être bien adaptée à notre scénario d'utilisation. Nous avons choisi VictoriaMetrics pour plusieurs raisons.
Premièrement, la solution est simple à configurer et utiliser. En tant qu'équipe, nous aspirons à optimiser nos processus afin de réduire notre charge opérationnelle, et VictoriaMetrics s'est montrée excellente jusqu'à présent. Deuxièmement, VictoriaMetrics a la capacité d'évoluer horizontalement, ce qui signifie que nous pouvons l'utiliser dans un mode à haute disponibilité. Pour un système tel que celui-ci, où nous recherchons une solution fiable pour calculer des informations temporellement sensibles pour nos clients, l'exigence de haute disponibilité est essentielle. Enfin, pendant nos tests, nous avons constaté que VictoriaMetrics utilisait environ un tiers de la mémoire que consommait Prometheus, un produit alternatif similaire, dans le même scénario d'utilisation.
Une fois que nous disposons de données dans VictoriaMetrics, nous pouvons exécuter des requêtes sur celles-ci et déterminer si nous devons alerter ou non nos clients, en fonction des configurations de notification qu'ils ont préalablement définies. À cette fin, nous utilisons notre système de notification d'alertes existant, auquel nous avons consacré un premier article de blog en 2019. Nous savons que nous pouvons compter, pour le dernier kilomètre, sur notre système de notification actuel pour transmettre ces notifications critiques à nos clients.
Setting up the Notification
Pour configurer cette notification, accédez à l'onglet « Notifications » du tableau de bord. Sélectionnez le type de notification « Anomalies de trafic ». Comme pour toutes les notifications de Cloudflare, vous pouvez nommer et décrire votre notification et choisir de quelle manière vous souhaitez être informé.
Vous pouvez choisir les domaines que vous souhaitez surveiller afin d'identifier d'éventuelles anomalies de trafic, si vous souhaitez inclure le trafic ayant déjà été atténué par les produits de protection contre les attaques DoS ou de pare-feu WAF de Cloudflare, ainsi que la présence de codes d'état spécifiques que vous souhaitez inclure ou exclure. Vous pouvez également choisir d'être alerté en cas de pics de trafic, de baisses de trafic ou de ces deux événements.
Nous sommes ravis d'utiliser ce système pour permettre à nos clients Enterprise de recevoir de précieuses notifications concernant l'intégrité générale de leurs systèmes. Accédez à l'onglet Notifications du tableau de bord pour découvrir dès maintenant cette nouvelle notification !