Comment créer un système d'alerte pour votre application IoT ?

Database
Jan. 22, 2024
photo_elie
Auteur
Elie Terrien
Retour d'expérience sur la conception d'un système d'alerte pour IoT.

Cet écrit relate mon expérience dans la conception d'un système d'alerte pour mon projet de plateforme IoT. L'objectif principal de ce système est de surveiller les données et de déclencher une alerte si elles dépassent un seuil prédéfini. Ma recherche visait une solution d'alerte nécessitant une administration minimale et facile d'utilisation.

Au fil de cet article, je présenterai trois solutions que j'ai examinées pour mon projet, en expliquant les raisons qui m'ont conduit à choisir la solution finalement mise en place.

1. Utiliser un outil externe pour mettre en place un système d'alerte

Un système d'alerte externe représente un outil indépendant qui se connecte à une source de données afin de définir des règles d'alerte. Des exemples de tels outils incluent Signoz Alerts et Grafana Alerting. Grafana offre une API permettant la configuration d'accès et la création d'alertes directement depuis son application. En revanche, contrairement à Signoz, qui semble disposer d'une API uniquement dédiée à la récupération des journaux (conformément à la documentation officielle).

Avantages d'un outil externe

Connectivité avec plusieurs sources de données : Ces outils d'alerte sont généralement équipés pour se connecter à diverses sources de données, facilitant ainsi la centralisation des alertes au sein d'une seule plateforme.

Fonctionnalités avancées spécialisées : Étant spécifiquement conçus pour la gestion des alertes, ces outils offrent des fonctionnalités avancées telles que la gestion des utilisateurs, des notifications multicanaux, des requêtes sophistiquées combinant plusieurs sources de données, etc.

Rapidité de déploiement : Ces outils sont prêts à l'emploi, nécessitant simplement une configuration pour s'adapter à votre application IoT, ce qui réduit considérablement les délais de développement.

Inconvénients d'un outil externe

Coût d'exploitation de l'outil : implique une gestion et une maintenance, que ce soit pour une solution open source nécessitant une administration continue ou pour une solution propriétaire exigeant un abonnement financier.

Exigence de compétences techniques : demande l'acquisition de connaissances sur un nouvel outil ainsi que sur son langage de requête spécifique.

Lien de dépendance : l'outil devient une composante incontournable de votre application IoT, limitant la flexibilité pour l'adapter à vos besoins particuliers.

2. Controller les données entrantes directement dans l'application IoT

Une alternative consiste à gérer de manière proactive les données entrantes au sein de l'application. Lorsqu'une requête API est reçue, une fonction effectue une vérification pour déterminer si une alerte est configurée et si la donnée en question peut déclencher une alerte.

Avantages de la gestion proactive des données entrantes

Intégration : Cette approche s'intègre directement à l'application IoT, offrant ainsi une maîtrise complète du système.

Flexibilité : Il est possible de créer un système d'alerte personnalisé, indépendant des outils externes, offrant ainsi une flexibilité accrue.

Inconvénients de la gestion proactive des données entrantes

Développement additionnel : La mise en place de cette approche nécessite la création d'un système d'alerte personnalisé, ce qui peut demander un certain investissement en temps.

Multiples protocoles : Bien que cette approche fonctionne efficacement avec un unique protocole d'échange de données, sa complexité augmente lorsque plusieurs protocoles sont utilisés.

3. Exploiter les fonctionnalités natives de votre base de données

La dernière approche consiste à exploiter les fonctionnalités avancées de votre base de données.

Par exemple, InfluxDB propose une fonctionnalité intégrée d'alerte qui permet de déclencher des alertes en fonction de la valeur d'un champ. Les alertes ainsi générées peuvent être envoyées à un canal Slack ou déclencher une requête HTTP.

MongoDB offre la possibilité de créer des **triggers qui peuvent être activés par des événements CRUD ou planifiés à une fréquence donnée. Ces déclencheurs peuvent être utilisés pour générer des alertes. Il est important de noter que cette fonctionnalité est disponible uniquement pour les clusters MongoDB gérés par MongoDB Atlas.

De même, des triggers sont disponibles dans PostgreSQL. Ils peuvent être déclenchés par des événements CRUD ou invoquer des fonctions. PostgreSQL étant une base de données open source, son utilisation ne génère aucun coût additionnel.

Avantages de l'exploitation des fonctionnalités natives de votre base de données

Performance : Cette approche réduit la latence en évitant le transfert des données vers un outil externe.

Facilité : Les alertes sont déclenchées directement au niveau de la source de données, et le système peut gérer plusieurs protocoles d'échange sans complexité supplémentaire.

Inconvénients de l'exploitation des fonctionnalités natives de votre base de données

Langage de requête : L'utilisation des fonctionnalités natives de la base de données nécessite la maîtrise du langage de requête spécifique de celle-ci.

Dépendance : Cette approche rend l'application dépendante de la base de données, ce qui peut restreindre sa flexibilité.

Développement additionnel : La mise en œuvre de cette approche nécessite un outil capable de vérifier si un déclencheur a été activé et d'envoyer une alerte en conséquence.

Conclusion : Quelle approche ai-je choisie ?

Après avoir examiné attentivement ces trois approches, ma décision s'est portée sur l'exploitation des fonctions natives de ma base de données. Dans mon cas, j'ai opté pour TimescaleDB, une extension de PostgreSQL.

Pourquoi cette approche ?

La première raison réside dans l'utilisation de plusieurs protocoles d'échange de données. Bien que la possibilité de contrôler les données entrantes directement dans mon application ait été envisagée initialement, cela aurait introduit une complexité supplémentaire dans le système.

La deuxième raison est liée à ma préférence pour une solution nécessitant un minimum d'administration. Étant seul sur ce projet, ce critère revêtait une importance particulière.

Enfin, l'adoption de cette approche m'a offert l'opportunité d'acquérir des compétences dans l'utilisation des triggers de PostgreSQL, une fonctionnalité avancée. Cette compétence peut être appliquée à d'autres cas d'utilisation, tels que la mise à jour d'un champ lors de modifications de données ou l'historisation des données.

Return to blog

Recevez notre newsletter