Déduplication d'événements similaires par période

L'orientation événementielle est géniale !

Que vous utilisiez GCP Pub/Sub, Kafka, Kinesis, RabbitMQ, NATS JetStream, Redis Pub/Sub ou l'une des innombrables alternatives, les modèles que vous apprenez s'appliquent à tous.

Déduplication d'événements similaires par période

Même si vous bénéficiez d'une livraison unique, vous recevrez toujours des événements similaires auxquels vous ne voulez pas vraiment réagir plusieurs fois.

Les alertes exploitables en sont un bon exemple. La première fois que quelque chose remarque un problème, c'est formidable de le faire remonter pour attirer l'attention de quelqu'un sur le fait qu'une action est nécessaire. La 700ème fois n'est que du bruit.

Si vous envoyez un événement, vous avez des champs (qu'il s'agisse de JSON/protobuf/struct peu importe), et il vous suffit d'identifier les champs par lesquels regrouper les éléments pour les trier dans le même compartiment pour votre période.

Vous pouvez prendre un hachage de n'importe quel ensemble arbitraire de ces champs d'événement et calculer un hachage d'entre eux comme clé d'une source de persistance (stockage de valeur de clé, SQL, peu importe). Par exemple, dans Go : https://go. dev/play/p/Ain8FIJiDit

Ensuite, stockez ce hachage avec un horodatage d'expiration et. Si vous rencontrez d'autres événements « similaires » avant l'horodatage d'expiration, ignorez-les, car ils ont déjà été portés à l'attention de quelqu'un.

Exemple réel

Au travail, nous traitons avec les districts scolaires, et ils nous fournissent leur liste, qui se synchronise régulièrement (tous les soirs). Mais parfois, un humain du district scolaire commet une erreur, comme supprimer accidentellement tous les élèves de sa liste. Oups ! Cependant, s’ils n’ont pas résolu le problème, nous n’avons pas besoin de recevoir un rappel plus d’une fois.

Le district, et la raison pour laquelle nous n'avons pas pu le répertorier, sont les clés uniques composites.

Chaque fois que nous déposons un ticket JIRA (ou envoyons une alerte à Slack), nous calculons d'abord le hachage de ces deux clés et voyons si un hachage correspondant a déjà été envoyé, et si oui, si la dernière alerte a expiré (24 heures ou quelque chose) avant d'en envoyer un nouveau et de remplacer l'ancien. Ainsi, par exemple, un échec de liste pour un district pourrait avoir quelque chose de générique comme :

v := map[string]any{
        "district":  "00be2b9c-ef18-4c27-8fa9-087dd5f39f27",
        "attention": "rosterops",
        "reason": "roster change exceeds threshold",
    }

et vous n’entendrez pas parler de l’échec de ce district avant le lendemain. Mais si quelqu'un essayait manuellement de se synchroniser et que ce district présentait un type d'échec différent (la réexécution donne désormais "service indisponible" au lieu de dépasser le seuil de tolérance de changement :

v := map[string]any{
        "district":      "00be2b9c-ef18-4c27-8fa9-087dd5f39f27",
        "attention": "rosterops",
        "reason": "roster provider is unavailable",
    }

Encore une fois, nous pouvons prendre un hachage de n'importe quel ensemble arbitraire de ces champs et en faire un champ de banque de données indexé sur une entité d'alerte. https://go.dev/play/p/Ain8FIJiDit

Bonus supplémentaire

Si vous conservez également un autre champ comme « statut », vous pouvez voir si quelqu'un le gère déjà et en faire un joli outil de suivi des éléments d'action pour tout système d'alerte arbitraire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!