Wiki du LAMA (UMR 5127) - Contributions [fr]

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T13:31:54Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]
<div style='text-align: center;'>''L'axe des abscisses est le temps et celui des ordonnées le pourcentage d'humidité''</div>

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T13:31:25Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]
<div style='text-align: center;'>''L'axe des abscisses est le temps et celui des ordonnées le pourcentage d'humidité''</div>

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T13:31:12Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T13:30:59Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]
<div style='text-align: center;'>''L'axe des abscisses est le temps et celui des ordonnées le pourcentage d'humidité''</div>

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Comment lancer un serveur Kafka

2023-05-26T13:23:17Z

Franz-maximilien ceron :

=Lancement d'un serveur Kafka=

Dans cette page nous verrons comment lancer un serveur Kafka. J'utiliserais ici une installation Kafka 2.13-3.4.0 sur une machine Windows 10.

''Les commandes pour les machines sous Linux sont presques similaires: par exmeple nos fichiers ne seront pas en .bat mains en .sh''

Dans toute la suite de cette page, on considère que l'archive contenant les fichiers serveurs sont dans un fichier 'kafka' dont la chemin est C:\Tool.

Nous ouvrirons alors des invites de commandes dans le répertoire courants suivants:

: C:\Tool\kafka\bin\windows

==Lancement d'un serveur Zoookeeeper==

Pour lancer un serveur Zookeeper, il suffit d'exécuter la commande suivante:

: zookeeper-server-start.bat ..\..\config\zookeeper.properties

Pour l'arrêter, faire la commande suivante:

: zookeeper-server-stop.bat

==Lancement d'un serveur Kafka==

Pour lancer un serveur Kafka, il suffit d'exécuter la commande suivante:

: kafka-server-start.bat ..\..\config\server.properties

Pour l'arrêter, faire la commande suivante:

: kafka-server-stop.bat

==Recommendation==

Il faut d'abord lancer le serveur Zookeeper, puis Kafka. Et pour éteindre les services, on éffectue l'extinction dans le sens inverse: d'abords Kafka puis Zookeeper.

Si vous voulez lancer de multiples serveurs, il est alors conseillé de créer des copies des fichiers en .properties en changeant les paramètres.

==Commandes utiles==

Dans cette parties, nous verrons des commandes simples pour l'installation d'un service Kafka.

===Topic===

Commande pour créer un topic:

: kafka-topics.bat --create --topic NomTopic --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1

Commande pour lister tous les topics:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --list

Commande pour lister tous les partitions d'un topic:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --describe --topic NomTopic

Commande pour supprimer un topic:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --delete --topic NomTopic

'''Attention''': ''La suppression est désactivée par défaut, il faut rajouter dans le fichier de configuration la ligne suivante:<br>delete.topic.enable=true''

===Création d'un Producer===

Pour créer un producer qui enverra des données dans un topic voulu, il faut exécuter la commande suivante:

: kafka-console-producer.bat --broker-list localhost:9092 --topic NomTopic

===Création d'un Consumer===

Pour créer un consumer qui lira des données dans un topic voulu, il faut exécuter la commande suivante:

: kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic NomTopic

Code de base pour la détection d anomalies

2023-05-26T13:16:42Z

Franz-maximilien ceron : /* Code important */

Dans cette page vous trouverez le code de base pour le producer, et le consumer de détection d'erreurs ainsi que pour l'affichage des données.

=Code du producer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_producer_code.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import serial
from kafka import KafkaProducer
import time
import pickle

## Création d'un fichier pour sauvegarder les données issues du capteur (optionel)
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

## Paramètre de la carte Arduino et de l'ip du serveur Kafka
portArduino = "COM3"
adresseKafka = 'localhost:9092'

##Fonction pour permettre et récupérer le nom du topic ainsi que la valeur (!dépend des données envoyées par la carte Arduino)
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return topic,valeur
return valeur

## Initialisation de la connection avec la carte Arduino
serial_port = serial.Serial(port = portArduino, baudrate = 9600)

## Initialisation de la connection avec le sreveur Kafka
producer = KafkaProducer(bootstrap_servers=adresseKafka)

## On boucle à l'infini pour transmettre continuellement des données
while True:
# Récupération de la donnée issue de la carte Arduino
msg = serial_port.readline()

# convertit le msg de l'ARDUINO en chaine de caractères
msg = msg.decode('utf-8')[:-2] # enlève les \r\n
# Récupération du temps pour la sauvegarde dans un fichier externe (optionel)
temp = time.time()
donnee = (msg, temp)
print(msg)

# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

topic,message = separateur_serial(msg)
# print(topic,message)

# convertit le message en bytes
message_bytes = bytes(message, 'utf-8')

#envoie de la donnée sur le serveur Kafka
producer.send(topic, message_bytes)

## code pour fermeture du producer
## producer.close()
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

Permet l'envoie d'un message à un topic nommé, il est conseillé de d'abord convertir le message en bytes ou en JSON
<nowiki>
message = 'Bonjour'
topic = 'NomPartition'

message_bytes = bytes(message, 'utf-8')

producer.send(topic, message_bytes )
</nowiki>

Permet la fermeture du producer
<nowiki>
producer.close()
</nowiki>

=Code du consumer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_ConsumerErreur.pdf Code en pdf]

<nowiki>
## Bibliotheque
from kafka import KafkaConsumer
from kafka.structs import TopicPartition

from sklearn.ensemble import IsolationForest
import pandas as pd

from sklearn.cluster import DBSCAN
import time

import pickle
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Fonction pour convertir une liste en DataFrame
def convert_list_database(liste):
tableau = []
for i in range(len(liste)-1):
tableau.append(liste[i])
# return tableau
return pd.DataFrame(tableau, columns=['c1'])

## Variable
nomTopic = 'humidite'
bootstrap_servers = 'localhost:9092'
topic = TopicPartition(nomTopic, 0)

## Programme
## Création d'un consumer
consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)

## Assignation au topic que l'on va lire
consumer.assign([topic])

## Permet d'aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)

## Création de la FILE
taille_File = 20 +1
file = []

## Boucle des messages
for msg in consumer:
## Décodage du message, ici en UTF-8
msg = msg.value.decode("utf-8")

##Partie detection

## Partie de détection d'erreur
if len(file) > taille_File:
file.append(msg)
file.pop(0)

print("Erreur ?")
#etat allant de -1 à 1

## on met ci-dessous la fonction de détection d'anomalies
etat = detectionAnomaly(file, taille_File)

## Partie d'initialisation
else:
print("Initialisation", round(len(file)/taille_File,2)) # Pourcentage ?
file.append(msg)
# etat 2 correspond à l'initialisation
etat = -2

## Partie pour sauvegarder les erreurs dans un fichiers externes (optionnel)
temps = time.time()
valeur = msg

donnee = (valeur,temps,etat)
# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE_DBSCAN.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)
</nowiki>

==Code important==

Importation des bibliothèques Kafka Python
<nowiki>
from kafka import KafkaConsumer
from kafka.structs import TopicPartition
</nowiki>

Création d'un consumer ainsi que son asignation à sa partition
<nowiki>

nomTopic = UnNomDeTopic
bootstrap_servers = AdresseIP:Port
numPartition = LeNuméroDeLaPartition
partition= TopicPartition(nomTopic, numPartition)

consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)
consumer.assign([partition])
</nowiki>

Se rendre à la fin de la partition
<nowiki>
consumer.poll()
consumer.seek_to_end(partition)
</nowiki>

Lecture de la partition, attention on a une boucle for mais elle a le comportement d'une boucle while. Si vous avez encodé votre message alors la première chose à faire est de le décoder.
<nowiki>
for msg in consumer:

msg = msg.value.decode("utf-8")
</nowiki>

Fermeture d'un consumer
<nowiki>
consumer.close()
</nowiki>

=Code pour affichage du résultat de notre code=

Attention cette affichage est pour ce projet. Adapté le pour votre projet selon vos bases de données.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_SHOW_DATA_RESULT.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import matplotlib.pyplot as plt
import pickle

##Fonction pour mise en forme des données
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return valeur

## variable contenant tous les fichiers avec les données
fichier_reference = "saveLISTEDONNEE.txt"
fichier1 = "saveLISTEDONNEE_DBSCAN.txt"
fichier2 = "saveLISTEDONNEE_ISOLATION.txt"

##imporation des fichiers précédants
data_ref = pickle.load( open( fichier_reference, "rb" ) )
data_DBSCAN = pickle.load( open( fichier1, "rb" ) )
data_ISOLATION = pickle.load( open( fichier2, "rb" ) )

##Affichage des nombres de mesures contenues dans les fichiers respectifs
print("DATA ref = ",len(data_ref))
print("DATA DBSCAN = ",len(data_DBSCAN))
print("DATA ISOLATION = ",len(data_ISOLATION))

def modification_dataREF(data):
"""
Remise en forme de notre base de référence
"""
dataBis = []
for elt in data:
valeur = separateur_serial(elt[0], separateur ="!")
donnee = (valeur,elt[1])
dataBis.append(donnee)
return dataBis

## Affichage avec plt des données
data_ref = modification_dataREF(data_ref)
# base de référence
y = [float(elt[0]) for elt in data_ref]
x = [float(elt[1]) for elt in data_ref]
plt.plot(x,y,color = "blue")

#DBSCAN
for elt in data_DBSCAN:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="red")

#Isolation Forest
for elt in data_ISOLATION:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="green")
# Remarque
# si elt[1] == 2 alors on est en itialisation
# si elt[1] == -1 alors on est en anomalie

## Affichage des données
plt.show()
</nowiki>

Code de base pour la détection d anomalies

2023-05-26T13:13:21Z

Franz-maximilien ceron : /* Code important */

Dans cette page vous trouverez le code de base pour le producer, et le consumer de détection d'erreurs ainsi que pour l'affichage des données.

=Code du producer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_producer_code.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import serial
from kafka import KafkaProducer
import time
import pickle

## Création d'un fichier pour sauvegarder les données issues du capteur (optionel)
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

## Paramètre de la carte Arduino et de l'ip du serveur Kafka
portArduino = "COM3"
adresseKafka = 'localhost:9092'

##Fonction pour permettre et récupérer le nom du topic ainsi que la valeur (!dépend des données envoyées par la carte Arduino)
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return topic,valeur
return valeur

## Initialisation de la connection avec la carte Arduino
serial_port = serial.Serial(port = portArduino, baudrate = 9600)

## Initialisation de la connection avec le sreveur Kafka
producer = KafkaProducer(bootstrap_servers=adresseKafka)

## On boucle à l'infini pour transmettre continuellement des données
while True:
# Récupération de la donnée issue de la carte Arduino
msg = serial_port.readline()

# convertit le msg de l'ARDUINO en chaine de caractères
msg = msg.decode('utf-8')[:-2] # enlève les \r\n
# Récupération du temps pour la sauvegarde dans un fichier externe (optionel)
temp = time.time()
donnee = (msg, temp)
print(msg)

# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

topic,message = separateur_serial(msg)
# print(topic,message)

# convertit le message en bytes
message_bytes = bytes(message, 'utf-8')

#envoie de la donnée sur le serveur Kafka
producer.send(topic, message_bytes)

## code pour fermeture du producer
## producer.close()
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

Permet l'envoie d'un message à un topic nommé, il est conseillé de d'abord convertir le message en bytes ou en JSON
<nowiki>
message = 'Bonjour'
topic = 'NomPartition'

message_bytes = bytes(message, 'utf-8')

producer.send(topic, message_bytes )
</nowiki>

Permet la fermeture du producer
<nowiki>
producer.close()
</nowiki>

=Code du consumer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_ConsumerErreur.pdf Code en pdf]

<nowiki>
## Bibliotheque
from kafka import KafkaConsumer
from kafka.structs import TopicPartition

from sklearn.ensemble import IsolationForest
import pandas as pd

from sklearn.cluster import DBSCAN
import time

import pickle
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Fonction pour convertir une liste en DataFrame
def convert_list_database(liste):
tableau = []
for i in range(len(liste)-1):
tableau.append(liste[i])
# return tableau
return pd.DataFrame(tableau, columns=['c1'])

## Variable
nomTopic = 'humidite'
bootstrap_servers = 'localhost:9092'
topic = TopicPartition(nomTopic, 0)

## Programme
## Création d'un consumer
consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)

## Assignation au topic que l'on va lire
consumer.assign([topic])

## Permet d'aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)

## Création de la FILE
taille_File = 20 +1
file = []

## Boucle des messages
for msg in consumer:
## Décodage du message, ici en UTF-8
msg = msg.value.decode("utf-8")

##Partie detection

## Partie de détection d'erreur
if len(file) > taille_File:
file.append(msg)
file.pop(0)

print("Erreur ?")
#etat allant de -1 à 1

## on met ci-dessous la fonction de détection d'anomalies
etat = detectionAnomaly(file, taille_File)

## Partie d'initialisation
else:
print("Initialisation", round(len(file)/taille_File,2)) # Pourcentage ?
file.append(msg)
# etat 2 correspond à l'initialisation
etat = -2

## Partie pour sauvegarder les erreurs dans un fichiers externes (optionnel)
temps = time.time()
valeur = msg

donnee = (valeur,temps,etat)
# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE_DBSCAN.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)
</nowiki>

==Code important==

Importation des bibliothèques Kafka Python
<nowiki>
from kafka import KafkaConsumer
from kafka.structs import TopicPartition
</nowiki>

Création d'un consumer ainsi que son asignation à sa partition
<nowiki>

nomTopic = UnNomDeTopic
bootstrap_servers = AdresseIP:Port
numPartition = LeNuméroDeLaPartition
partition= TopicPartition(nomTopic, numPartition)

consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)
consumer.assign([partition])
</nowiki>

Se rendre à la fin de la partition
<nowiki>
consumer.poll()
consumer.seek_to_end(numPartition)
</nowiki>

Lecture de la partition, attention on a une boucle for mais elle a le comportement d'une boucle while. Si vous avez encodé votre message alors la première chose à faire est de le décoder.
<nowiki>
for msg in consumer:

msg = msg.value.decode("utf-8")
</nowiki>

Fermeture d'un consumer
<nowiki>
consumer.close()
</nowiki>

=Code pour affichage du résultat de notre code=

Attention cette affichage est pour ce projet. Adapté le pour votre projet selon vos bases de données.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_SHOW_DATA_RESULT.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import matplotlib.pyplot as plt
import pickle

##Fonction pour mise en forme des données
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return valeur

## variable contenant tous les fichiers avec les données
fichier_reference = "saveLISTEDONNEE.txt"
fichier1 = "saveLISTEDONNEE_DBSCAN.txt"
fichier2 = "saveLISTEDONNEE_ISOLATION.txt"

##imporation des fichiers précédants
data_ref = pickle.load( open( fichier_reference, "rb" ) )
data_DBSCAN = pickle.load( open( fichier1, "rb" ) )
data_ISOLATION = pickle.load( open( fichier2, "rb" ) )

##Affichage des nombres de mesures contenues dans les fichiers respectifs
print("DATA ref = ",len(data_ref))
print("DATA DBSCAN = ",len(data_DBSCAN))
print("DATA ISOLATION = ",len(data_ISOLATION))

def modification_dataREF(data):
"""
Remise en forme de notre base de référence
"""
dataBis = []
for elt in data:
valeur = separateur_serial(elt[0], separateur ="!")
donnee = (valeur,elt[1])
dataBis.append(donnee)
return dataBis

## Affichage avec plt des données
data_ref = modification_dataREF(data_ref)
# base de référence
y = [float(elt[0]) for elt in data_ref]
x = [float(elt[1]) for elt in data_ref]
plt.plot(x,y,color = "blue")

#DBSCAN
for elt in data_DBSCAN:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="red")

#Isolation Forest
for elt in data_ISOLATION:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="green")
# Remarque
# si elt[1] == 2 alors on est en itialisation
# si elt[1] == -1 alors on est en anomalie

## Affichage des données
plt.show()
</nowiki>

Code de base pour la détection d anomalies

2023-05-26T13:12:40Z

Franz-maximilien ceron : /* Code du consumer */

Dans cette page vous trouverez le code de base pour le producer, et le consumer de détection d'erreurs ainsi que pour l'affichage des données.

=Code du producer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_producer_code.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import serial
from kafka import KafkaProducer
import time
import pickle

## Création d'un fichier pour sauvegarder les données issues du capteur (optionel)
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

## Paramètre de la carte Arduino et de l'ip du serveur Kafka
portArduino = "COM3"
adresseKafka = 'localhost:9092'

##Fonction pour permettre et récupérer le nom du topic ainsi que la valeur (!dépend des données envoyées par la carte Arduino)
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return topic,valeur
return valeur

## Initialisation de la connection avec la carte Arduino
serial_port = serial.Serial(port = portArduino, baudrate = 9600)

## Initialisation de la connection avec le sreveur Kafka
producer = KafkaProducer(bootstrap_servers=adresseKafka)

## On boucle à l'infini pour transmettre continuellement des données
while True:
# Récupération de la donnée issue de la carte Arduino
msg = serial_port.readline()

# convertit le msg de l'ARDUINO en chaine de caractères
msg = msg.decode('utf-8')[:-2] # enlève les \r\n
# Récupération du temps pour la sauvegarde dans un fichier externe (optionel)
temp = time.time()
donnee = (msg, temp)
print(msg)

# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

topic,message = separateur_serial(msg)
# print(topic,message)

# convertit le message en bytes
message_bytes = bytes(message, 'utf-8')

#envoie de la donnée sur le serveur Kafka
producer.send(topic, message_bytes)

## code pour fermeture du producer
## producer.close()
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

Permet l'envoie d'un message à un topic nommé, il est conseillé de d'abord convertir le message en bytes ou en JSON
<nowiki>
message = 'Bonjour'

message_bytes = bytes(message, 'utf-8')

producer.send(topic, message_bytes )
</nowiki>

Permet la fermeture du producer
<nowiki>
producer.close()
</nowiki>

=Code du consumer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_ConsumerErreur.pdf Code en pdf]

<nowiki>
## Bibliotheque
from kafka import KafkaConsumer
from kafka.structs import TopicPartition

from sklearn.ensemble import IsolationForest
import pandas as pd

from sklearn.cluster import DBSCAN
import time

import pickle
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Fonction pour convertir une liste en DataFrame
def convert_list_database(liste):
tableau = []
for i in range(len(liste)-1):
tableau.append(liste[i])
# return tableau
return pd.DataFrame(tableau, columns=['c1'])

## Variable
nomTopic = 'humidite'
bootstrap_servers = 'localhost:9092'
topic = TopicPartition(nomTopic, 0)

## Programme
## Création d'un consumer
consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)

## Assignation au topic que l'on va lire
consumer.assign([topic])

## Permet d'aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)

## Création de la FILE
taille_File = 20 +1
file = []

## Boucle des messages
for msg in consumer:
## Décodage du message, ici en UTF-8
msg = msg.value.decode("utf-8")

##Partie detection

## Partie de détection d'erreur
if len(file) > taille_File:
file.append(msg)
file.pop(0)

print("Erreur ?")
#etat allant de -1 à 1

## on met ci-dessous la fonction de détection d'anomalies
etat = detectionAnomaly(file, taille_File)

## Partie d'initialisation
else:
print("Initialisation", round(len(file)/taille_File,2)) # Pourcentage ?
file.append(msg)
# etat 2 correspond à l'initialisation
etat = -2

## Partie pour sauvegarder les erreurs dans un fichiers externes (optionnel)
temps = time.time()
valeur = msg

donnee = (valeur,temps,etat)
# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE_DBSCAN.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)
</nowiki>

==Code important==

Importation des bibliothèques Kafka Python
<nowiki>
from kafka import KafkaConsumer
from kafka.structs import TopicPartition
</nowiki>

Création d'un consumer ainsi que son asignation à sa partition
<nowiki>

nomTopic = UnNomDeTopic
bootstrap_servers = AdresseIP:Port
numPartition = LeNuméroDeLaPartition
partition= TopicPartition(nomTopic, numPartition)

consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)
consumer.assign([partition])
</nowiki>

Se rendre à la fin de la partition
<nowiki>
consumer.poll()
consumer.seek_to_end(numPartition)
</nowiki>

Lecture de la partition, attention on a une boucle for mais elle a le comportement d'une boucle while. Si vous avez encodé votre message alors la première chose à faire est de le décoder.
<nowiki>
for msg in consumer:

msg = msg.value.decode("utf-8")
</nowiki>

Fermeture d'un consumer
<nowiki>
consumer.close()
</nowiki>

=Code pour affichage du résultat de notre code=

Attention cette affichage est pour ce projet. Adapté le pour votre projet selon vos bases de données.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_SHOW_DATA_RESULT.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import matplotlib.pyplot as plt
import pickle

##Fonction pour mise en forme des données
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return valeur

## variable contenant tous les fichiers avec les données
fichier_reference = "saveLISTEDONNEE.txt"
fichier1 = "saveLISTEDONNEE_DBSCAN.txt"
fichier2 = "saveLISTEDONNEE_ISOLATION.txt"

##imporation des fichiers précédants
data_ref = pickle.load( open( fichier_reference, "rb" ) )
data_DBSCAN = pickle.load( open( fichier1, "rb" ) )
data_ISOLATION = pickle.load( open( fichier2, "rb" ) )

##Affichage des nombres de mesures contenues dans les fichiers respectifs
print("DATA ref = ",len(data_ref))
print("DATA DBSCAN = ",len(data_DBSCAN))
print("DATA ISOLATION = ",len(data_ISOLATION))

def modification_dataREF(data):
"""
Remise en forme de notre base de référence
"""
dataBis = []
for elt in data:
valeur = separateur_serial(elt[0], separateur ="!")
donnee = (valeur,elt[1])
dataBis.append(donnee)
return dataBis

## Affichage avec plt des données
data_ref = modification_dataREF(data_ref)
# base de référence
y = [float(elt[0]) for elt in data_ref]
x = [float(elt[1]) for elt in data_ref]
plt.plot(x,y,color = "blue")

#DBSCAN
for elt in data_DBSCAN:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="red")

#Isolation Forest
for elt in data_ISOLATION:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="green")
# Remarque
# si elt[1] == 2 alors on est en itialisation
# si elt[1] == -1 alors on est en anomalie

## Affichage des données
plt.show()
</nowiki>

Code de base pour la détection d anomalies

2023-05-26T13:06:24Z

Franz-maximilien ceron :

Dans cette page vous trouverez le code de base pour le producer, et le consumer de détection d'erreurs ainsi que pour l'affichage des données.

=Code du producer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_producer_code.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import serial
from kafka import KafkaProducer
import time
import pickle

## Création d'un fichier pour sauvegarder les données issues du capteur (optionel)
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

## Paramètre de la carte Arduino et de l'ip du serveur Kafka
portArduino = "COM3"
adresseKafka = 'localhost:9092'

##Fonction pour permettre et récupérer le nom du topic ainsi que la valeur (!dépend des données envoyées par la carte Arduino)
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return topic,valeur
return valeur

## Initialisation de la connection avec la carte Arduino
serial_port = serial.Serial(port = portArduino, baudrate = 9600)

## Initialisation de la connection avec le sreveur Kafka
producer = KafkaProducer(bootstrap_servers=adresseKafka)

## On boucle à l'infini pour transmettre continuellement des données
while True:
# Récupération de la donnée issue de la carte Arduino
msg = serial_port.readline()

# convertit le msg de l'ARDUINO en chaine de caractères
msg = msg.decode('utf-8')[:-2] # enlève les \r\n
# Récupération du temps pour la sauvegarde dans un fichier externe (optionel)
temp = time.time()
donnee = (msg, temp)
print(msg)

# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

topic,message = separateur_serial(msg)
# print(topic,message)

# convertit le message en bytes
message_bytes = bytes(message, 'utf-8')

#envoie de la donnée sur le serveur Kafka
producer.send(topic, message_bytes)

## code pour fermeture du producer
## producer.close()
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

Permet l'envoie d'un message à un topic nommé, il est conseillé de d'abord convertir le message en bytes ou en JSON
<nowiki>
message = 'Bonjour'

message_bytes = bytes(message, 'utf-8')

producer.send(topic, message_bytes )
</nowiki>

Permet la fermeture du producer
<nowiki>
producer.close()
</nowiki>

=Code du consumer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_ConsumerErreur.pdf Code en pdf]

<nowiki>
## Bibliotheque
from kafka import KafkaConsumer
from kafka.structs import TopicPartition

from sklearn.ensemble import IsolationForest
import pandas as pd

from sklearn.cluster import DBSCAN
import time

import pickle
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Fonction pour convertir une liste en DataFrame
def convert_list_database(liste):
tableau = []
for i in range(len(liste)-1):
tableau.append(liste[i])
# return tableau
return pd.DataFrame(tableau, columns=['c1'])

## Variable
nomTopic = 'humidite'
bootstrap_servers = 'localhost:9092'
topic = TopicPartition(nomTopic, 0)

## Programme
## Création d'un consumer
consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)

## Assignation au topic que l'on va lire
consumer.assign([topic])

## Permet d'aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)

## Création de la FILE
taille_File = 20 +1
file = []

## Boucle des messages
for msg in consumer:
## Décodage du message, ici en UTF-8
msg = msg.value.decode("utf-8")

##Partie detection

## Partie de détection d'erreur
if len(file) > taille_File:
file.append(msg)
file.pop(0)

print("Erreur ?")
#etat allant de -1 à 1

## on met ci-dessous la fonction de détection d'anomalies
etat = detectionAnomaly(file, taille_File)

## Partie d'initialisation
else:
print("Initialisation", round(len(file)/taille_File,2)) # Pourcentage ?
file.append(msg)
# etat 2 correspond à l'initialisation
etat = -2

## Partie pour sauvegarder les erreurs dans un fichiers externes (optionnel)
temps = time.time()
valeur = msg

donnee = (valeur,temps,etat)
# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE_DBSCAN.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

=Code pour affichage du résultat de notre code=

Attention cette affichage est pour ce projet. Adapté le pour votre projet selon vos bases de données.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_SHOW_DATA_RESULT.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import matplotlib.pyplot as plt
import pickle

##Fonction pour mise en forme des données
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return valeur

## variable contenant tous les fichiers avec les données
fichier_reference = "saveLISTEDONNEE.txt"
fichier1 = "saveLISTEDONNEE_DBSCAN.txt"
fichier2 = "saveLISTEDONNEE_ISOLATION.txt"

##imporation des fichiers précédants
data_ref = pickle.load( open( fichier_reference, "rb" ) )
data_DBSCAN = pickle.load( open( fichier1, "rb" ) )
data_ISOLATION = pickle.load( open( fichier2, "rb" ) )

##Affichage des nombres de mesures contenues dans les fichiers respectifs
print("DATA ref = ",len(data_ref))
print("DATA DBSCAN = ",len(data_DBSCAN))
print("DATA ISOLATION = ",len(data_ISOLATION))

def modification_dataREF(data):
"""
Remise en forme de notre base de référence
"""
dataBis = []
for elt in data:
valeur = separateur_serial(elt[0], separateur ="!")
donnee = (valeur,elt[1])
dataBis.append(donnee)
return dataBis

## Affichage avec plt des données
data_ref = modification_dataREF(data_ref)
# base de référence
y = [float(elt[0]) for elt in data_ref]
x = [float(elt[1]) for elt in data_ref]
plt.plot(x,y,color = "blue")

#DBSCAN
for elt in data_DBSCAN:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="red")

#Isolation Forest
for elt in data_ISOLATION:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="green")
# Remarque
# si elt[1] == 2 alors on est en itialisation
# si elt[1] == -1 alors on est en anomalie

## Affichage des données
plt.show()
</nowiki>

Code de base pour la détection d anomalies

2023-05-26T13:05:33Z

Franz-maximilien ceron : /* Code du producer */

Dans cette page vous trouverez le code de base pour le producer, et le consumer de détection d'erreurs ainsi que pour l'affichage des données.

=Code du producer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_producer_code.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import serial
from kafka import KafkaProducer
import time
import pickle

## Création d'un fichier pour sauvegarder les données issues du capteur (optionel)
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

## Paramètre de la carte Arduino et de l'ip du serveur Kafka
portArduino = "COM3"
adresseKafka = 'localhost:9092'

##Fonction pour permettre et récupérer le nom du topic ainsi que la valeur (!dépend des données envoyées par la carte Arduino)
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return topic,valeur
return valeur

## Initialisation de la connection avec la carte Arduino
serial_port = serial.Serial(port = portArduino, baudrate = 9600)

## Initialisation de la connection avec le sreveur Kafka
producer = KafkaProducer(bootstrap_servers=adresseKafka)

## On boucle à l'infini pour transmettre continuellement des données
while True:
# Récupération de la donnée issue de la carte Arduino
msg = serial_port.readline()

# convertit le msg de l'ARDUINO en chaine de caractères
msg = msg.decode('utf-8')[:-2] # enlève les \r\n
# Récupération du temps pour la sauvegarde dans un fichier externe (optionel)
temp = time.time()
donnee = (msg, temp)
print(msg)

# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE.txt", "wb" ) )

topic,message = separateur_serial(msg)
# print(topic,message)

# convertit le message en bytes
message_bytes = bytes(message, 'utf-8')

#envoie de la donnée sur le serveur Kafka
producer.send(topic, message_bytes)

## code pour fermeture du producer
## producer.close()
</nowiki>

==Code important==

Importation de la bibliothèquue Kafka Python
<nowiki>
from kafka import KafkaProducer
</nowiki>

Permet l'envoie d'un message à un topic nommé, il est conseillé de d'abord convertir le message en bytes ou en JSON
<nowiki>
message = 'Bonjour'

message_bytes = bytes(message, 'utf-8')

producer.send(topic, message_bytes )
</nowiki>

Permet la fermeture du producer
<nowiki>
producer.close()
</nowiki>

=Code du consumer=

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_ConsumerErreur.pdf Code en pdf]

<nowiki>
## Bibliotheque
from kafka import KafkaConsumer
from kafka.structs import TopicPartition

from sklearn.ensemble import IsolationForest
import pandas as pd

from sklearn.cluster import DBSCAN
import time

import pickle
listeDonnee = []
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Fonction pour convertir une liste en DataFrame
def convert_list_database(liste):
tableau = []
for i in range(len(liste)-1):
tableau.append(liste[i])
# return tableau
return pd.DataFrame(tableau, columns=['c1'])

## Variable
nomTopic = 'humidite'
bootstrap_servers = 'localhost:9092'
topic = TopicPartition(nomTopic, 0)

## Programme
## Création d'un consumer
consumer = KafkaConsumer(bootstrap_servers = bootstrap_servers)

## Assignation au topic que l'on va lire
consumer.assign([topic])

## Permet d'aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)

## Création de la FILE
taille_File = 20 +1
file = []

## Boucle des messages
for msg in consumer:
## Décodage du message, ici en UTF-8
msg = msg.value.decode("utf-8")

##Partie detection

## Partie de détection d'erreur
if len(file) > taille_File:
file.append(msg)
file.pop(0)

print("Erreur ?")
#etat allant de -1 à 1

## on met ci-dessous la fonction de détection d'anomalies
etat = detectionAnomaly(file, taille_File)

## Partie d'initialisation
else:
print("Initialisation", round(len(file)/taille_File,2)) # Pourcentage ?
file.append(msg)
# etat 2 correspond à l'initialisation
etat = -2

## Partie pour sauvegarder les erreurs dans un fichiers externes (optionnel)
temps = time.time()
valeur = msg

donnee = (valeur,temps,etat)
# sauvegarde des données dans un fichier de sauvegarde !consomme du temps si le fichier est trop grand
listeDonnee = pickle.load( open( "saveLISTEDONNEE_DBSCAN.txt", "rb" ) )
listeDonnee.append(donnee)
pickle.dump( listeDonnee, open( "saveLISTEDONNEE_DBSCAN.txt", "wb" ) )

## Aller à la fin de la partition
consumer.poll()
consumer.seek_to_end(topic)
</nowiki>

=Code pour affichage du résultat de notre code=

Attention cette affichage est pour ce projet. Adapté le pour votre projet selon vos bases de données.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Fichier:CFM_SHOW_DATA_RESULT.pdf Code en pdf]

<nowiki>
## Importation des bibliothèques
import matplotlib.pyplot as plt
import pickle

##Fonction pour mise en forme des données
def separateur_serial(chaine, separateur ="!"):
indice = -1

for i in range (len(chaine) -1, -1 , -1):
if chaine[i] == separateur:
indice = i
break
topic = chaine[:indice]
valeur = chaine[indice +1:]
return valeur

## variable contenant tous les fichiers avec les données
fichier_reference = "saveLISTEDONNEE.txt"
fichier1 = "saveLISTEDONNEE_DBSCAN.txt"
fichier2 = "saveLISTEDONNEE_ISOLATION.txt"

##imporation des fichiers précédants
data_ref = pickle.load( open( fichier_reference, "rb" ) )
data_DBSCAN = pickle.load( open( fichier1, "rb" ) )
data_ISOLATION = pickle.load( open( fichier2, "rb" ) )

##Affichage des nombres de mesures contenues dans les fichiers respectifs
print("DATA ref = ",len(data_ref))
print("DATA DBSCAN = ",len(data_DBSCAN))
print("DATA ISOLATION = ",len(data_ISOLATION))

def modification_dataREF(data):
"""
Remise en forme de notre base de référence
"""
dataBis = []
for elt in data:
valeur = separateur_serial(elt[0], separateur ="!")
donnee = (valeur,elt[1])
dataBis.append(donnee)
return dataBis

## Affichage avec plt des données
data_ref = modification_dataREF(data_ref)
# base de référence
y = [float(elt[0]) for elt in data_ref]
x = [float(elt[1]) for elt in data_ref]
plt.plot(x,y,color = "blue")

#DBSCAN
for elt in data_DBSCAN:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="red")

#Isolation Forest
for elt in data_ISOLATION:
if elt[2] == 2:
plt.axvline(x=elt[1],color="k")
elif elt[2] == -1:
plt.axvline(x=elt[1],color="green")
# Remarque
# si elt[1] == 2 alors on est en itialisation
# si elt[1] == -1 alors on est en anomalie

## Affichage des données
plt.show()
</nowiki>

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:57:51Z

Franz-maximilien ceron : /* Cas anormal */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:57:14Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe se qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:56:27Z

Franz-maximilien ceron : /* Limites de DBSCAN */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

Ces limites sont ces paramètres:

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:55:54Z

Franz-maximilien ceron : /* Limites d'Isolation Forest */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:55:37Z

Franz-maximilien ceron : /* Limites d'Isolation Forest */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:55:20Z

Franz-maximilien ceron : /* Limites d'Isolation Forest */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:52:47Z

Franz-maximilien ceron : /* Conclusion */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies ou nécessiteront sinon des paramètres qui dépendront de la situation. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:50:54Z

Franz-maximilien ceron : /* Démarche pour la détection d’anomalies */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:50:22Z

Franz-maximilien ceron : /* Limite des deux algorithmes */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:50:15Z

Franz-maximilien ceron : /* Rechherche d'anomalies */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====

[[Fichier:CFM_humidite_5.png|center]]
<div style='text-align: center;'>''Ici on voit un dérèglement de notre graphe en bleu''</div>

Sur la figure ci-dessus, nous voyons que nos données ne sont pas stables, ce qui a été détecter comme anomalie par nos deux algorithmes.

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]
<div style='text-align: center;'>''Ici on voit non plus un dérèglement mais plusieurs''</div>

Dans le ce cas, nos programmes peuvent détecter la première variation mais n'indiquent cependant pas les autres. En effet la File est alors "parasitée" par des données anormales, il devient alors plus compliqué voire impossible de détecter d'autres variations.

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]
<div style='text-align: center;'>''On est différent de l'état initiale mais ce n'est pas une anomalies ?''</div>

Dans ce dernier cas, nous sommes d'abors dans une situation stable puis survint une variation qui estt détecter puis nos données redeviennent stables. Cependant les données finales sont différents que celles de débuts, ne devraient-elles pas être considérées comme des anomalies ? Ce comportement est du à la File qui possède une taille fixe et qui se remplie de nouveaux éléments continuellement. Au final si l'erreur devient constante alors elle se transforme une donnée normal.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:40:28Z

Franz-maximilien ceron : /* Phase d'initialisation */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation, sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

===Rechherche d'anomalies===

====Cas normal====
[[Fichier:CFM_humidite_5.png|center]]

====Cas anormal====
[[Fichier:CFM_humidite_6.png|center]]

====Cas d'un surplus d'anomalies====
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:39:00Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]
<div style='text-align: center;'>''Vous pouvez voir que le graphe bleu n'est pas constant donc normalement une anomalie''</div>

La figure ci-dessus représente la partie d'initialisation. Sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

[[Fichier:CFM_humidite_5.png|center]]
[[Fichier:CFM_humidite_6.png|center]]
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:37:48Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une (petite) différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]

Dans la suite nous verrons les cas particuliers de nos programmes:

===Phase d'initialisation===

[[Fichier:CFM_humidite_4.png|center]]

La figure ci-dessus représente la partie d'initialisation. Sur cette période toutes les anomalies ne seront pas détectés car on remplira pour la première fois notre File.

[[Fichier:CFM_humidite_5.png|center]]
[[Fichier:CFM_humidite_6.png|center]]
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:35:00Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une différence de vitesse entre nos deux algorithmes.

Ensuite on peut représenter nos données sous forme d'un graphe ce qui donne la figure suivante:

[[Fichier:CFM_humidite_2.PNG|center]]

On superpose au graphique précédant des barres verticales qui auront chacune leur particularités:
: En noir les données de l'initialisation
: En rouge les anomalies détectées par DBSCAN
: En vert celles détectées par Isolation Forest

[[Fichier:CFM_humidite_3.png|center]]
[[Fichier:CFM_humidite_4.png|center]]
[[Fichier:CFM_humidite_5.png|center]]
[[Fichier:CFM_humidite_6.png|center]]
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:32:08Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

On peut déjà voir que sur toutes les mesures du capteurs, seulement une partie a été analysé (à peu près la moitié). On voit également une différence de vitesse entre nos deux algorithmes.
[[Fichier:CFM_humidite_2.PNG|center]]
[[Fichier:CFM_humidite_3.png|center]]
[[Fichier:CFM_humidite_4.png|center]]
[[Fichier:CFM_humidite_5.png|center]]
[[Fichier:CFM_humidite_6.png|center]]
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:29:44Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

Dans un premiers temps, vous pouvez voir ci-dessous sur quel ensemble nous a fourni notre montage sur environ une trentaine de minutes.

[[Fichier:CFM_humidite_1.PNG|center]]

[[Fichier:CFM_humidite_2.PNG|center]]
[[Fichier:CFM_humidite_3.png|center]]
[[Fichier:CFM_humidite_4.png|center]]
[[Fichier:CFM_humidite_5.png|center]]
[[Fichier:CFM_humidite_6.png|center]]
[[Fichier:CFM_humidite_7.png|center]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:27:55Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

[[Fichier:CFM_humidite_1.PNG]]
[[Fichier:CFM_humidite_2.PNG]]
[[Fichier:CFM_humidite_3.png]]
[[Fichier:CFM_humidite_4.PNG]]
[[Fichier:CFM_humidite_5.PNG]]
[[Fichier:CFM_humidite_6.PNG]]
[[Fichier:CFM_humidite_7.PNG]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Fichier:CFM humidite 3.png

2023-05-26T12:27:18Z

Franz-maximilien ceron : Franz-maximilien ceron a téléversé une nouvelle version de Fichier:CFM humidite 3.png

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:26:52Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

[[Fichier:CFM_humidite_1.PNG]]
[[Fichier:CFM_humidite_2.PNG]]
[[Fichier:CFM_humidite_3.PNG]]
[[Fichier:CFM_humidite_4.PNG]]
[[Fichier:CFM_humidite_5.PNG]]
[[Fichier:CFM_humidite_6.PNG]]
[[Fichier:CFM_humidite_7.PNG]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:26:30Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

[[Fichier:CFM_humidite_1.PNG]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:25:56Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

[[Fichier:CFM_humidite_1.png]]

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Fichier:CFM humidite 7.png

2023-05-26T12:25:41Z

Franz-maximilien ceron :

Fichier:CFM humidite 6.png

2023-05-26T12:25:31Z

Franz-maximilien ceron :

Fichier:CFM humidite 5.png

2023-05-26T12:25:22Z

Franz-maximilien ceron :

Fichier:CFM humidite 4.png

2023-05-26T12:25:15Z

Franz-maximilien ceron :

Fichier:CFM humidite 3.png

2023-05-26T12:25:07Z

Franz-maximilien ceron :

Fichier:CFM humidite 2.PNG

2023-05-26T12:25:00Z

Franz-maximilien ceron :

Fichier:CFM humidite 1.PNG

2023-05-26T12:24:49Z

Franz-maximilien ceron :

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:16:51Z

Franz-maximilien ceron : /* Test de notre montage */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

Pour tester le fonctionnement de nos algorithmes de détections d'erreurs, nous avons fait le montage suivant:

Un capteur d'humidité relié à une carte ARDUINO qui sera notre producer.

Un ordinateur qui sera l'hébergeur de notre serveur Kafka

Un consumer qui sera un script Python avec nos algorithmes.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:13:34Z

Franz-maximilien ceron :

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Test de notre montage==

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Comment lancer un serveur Kafka

2023-05-26T12:12:05Z

Franz-maximilien ceron : /* Topic */

=Lancement d'un serveur Kafka=

Dans cette page nous verrons comment lancer un serveur Kafka. J'utiliserais ici une installation Kafka 2.13-3.4.0 sur une machine Windows 10.

''Les commandes pour les machines sous Linux sont presques similaires: par exmeple nos fichiers ne seront pas en .bat mains en .sh''

Dans toute la suite de cette page, on considère que l'archive contenant les fichiers serveurs sont dans un fichier 'kafka' dont la chemin est C:\Tool.

Nous ouvrirons alors des invites de commandes dans le répertoire courants suivants:

: C:\Tool\kafka\bin\windows

==Lancement d'un serveur Zoookeeeper==

Pour lancer un serveur Zookeeper, il suffit d'exécuter la commande suivante:

: zookeeper-server-start.bat ..\..\config\zookeeper.properties

Pour l'arrêter, faire la commande suivante:

: zookeeper-server-stop.bat

==Lancement d'un serveur Kafka==

Pour lancer un serveur Kafka, il suffit d'exécuter la commande suivante:

: kafka-server-start.bat ..\..\config\server.properties

Pour l'arrêter, faire la commande suivante:

: kafka-server-stop.bat

==Recommendation==

Il faut d'abord lancer le serveur Zookeeper, puis Kafka. Et pour éteindre les services, on éffectue l'extinction dans le sens inverse: d'abords Kafka puis Zookeeper.

Si vous voulez lancer de multiples serveurs, il est alors conseillé de créer des copies des fichiers en .properties en changeant les paramètres.

==Commandes utiles==

Dans cette parties, nous verrons des commandes simples pour l'installation d'un service Kafka.

===Topic===

Commande pour créer un topic:

: kafka-topics.bat --create --topic NomTopic --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1

Commande pour lister tous les topics:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --list

Commande pour lister tous les partitions d'un topic:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --describe --topic NomTopic

Commande pour supprimer un topic:

: kafka-topics.bat --bootstrap-serveur=localhost:9092 --delete --topic NomTopic

'''Attention''': ''La suppression est désactivée par défaut, il faut rajouter dans le fichier de configuration la ligne suivante:<br>delete.topic.enable=true''

==Création d'un Producer==

Pour créer un producer qui enverra des données dans un topic voulu, il faut exécuter la commande suivante:

: kafka-console-producer.bat --broker-list localhost:9092 --topic NomTopic

==Création d'un Consumer==

Pour créer un consumer qui lira des données dans un topic voulu, il faut exécuter la commande suivante:

: kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic NomTopic

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:08:16Z

Franz-maximilien ceron : /* Limites de DBSCAN */

L’objectif de ce projet était de pouvoir mettre en place un serveur Kafka et de détecter des anomalies dans le flux de données envoyé au serveur.

=Qu'est-ce qu’un serveur Kafka et l’utilité de détecter des anomalies.=

Un serveur Apache Kafka est une plateforme de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs. Apache Kafka est de type d’intégration asynchrone se qui signifie que les données envoyées et consultées seront stockées dans un magasin intermédiaire (des fichiers topics).

Apache Kafka permet donc des utilisations pour lesquels le débit de données est élevée, avec une latence réduite à quelques millisecondes. Les utilisateurs peuvent ainsi accéder les données en temps réel ce qui est primordial avec l’avènement de l’Internet des Objets.

Cependant des erreurs peuvent apparaître dans les sources pourraient autant être les capteurs initiaux qu’un défaut de transmission. C’est pourquoi nous allons coupler à notre seurveur Apache Kafka, des algorithmes de détection d’anomalies Python pour mettre en évidence d’éventuelles anomalies qui pourraient apparaître et ainsi prévenir notre utilisateur.

=Infrastructure d’un serveur Kafka=

Vous pouvez télécharger les fichiers nécessaires avec le lien ci-dessous:

[https://kafka.apache.org/downloads Site d'Apache Kafka]

==Zookeeper==

[[Fichier:CFM_Zookeeper_logo.png|200px|center]]

Avant de lancer notre serveur Kafka, nous allons d’abord déployer un autre service complémentaire nommé Apache Zookeeper.

''Les dossiers pour exécuter Zookeeper sont normalement déjà présent dans l'archive téléchargée.''

Ce service permet gérer, coordonner un cluster de machines et fournit un service de configuration. Il a un rôle de surveillance, il va pouvoir organiser la gestion des broker (voir Apache Kafka) ainsi que le stockage lié aux informations de configurations (configuration des topics, nombre de partition, …).

[[Fichier:CFM_Zookeeper_schema.jpg|400px|center]]

<div style='text-align: center;'>''Exemple d'une installation de serveur Zookeepers avec des serveurs Kafkas''</div>

'''Remarque''' : ''L’utilisation d’un serveur Zookeeper tend à disparaître pour permettre une utilisation individuelle de serveur Apache Kafka.''

==Kafka==

[[Fichier:CFM_Kafka_logo.png|200px|center]]

Nous pouvons maintenant lancer notre serveur Kafka qui pourra être intégré dans un cluster. Pour être précis nous lançons un broker dont l’id est unique.
Ce broker possède en lui différents topics, il sert à regrouper des données entre elles, qui eux-mêmes sont composés de partitions où seront stockés nos données.
Il n’y a théoriquement aucune limite au nombre de topics ou de partitions créés. Cela permet d’avoir plusieurs consumers sur le même topic avec différent stade de lecture.
Pour envoyer des données à notre topic, nous allons utiliser un producer et pour les lire dans nos partitions, nous allons utiliser un consumer.
On peut faire des producers/consumers mixtes.

[[Fichier:CFM_Kafka_schema.png|500px|center]]

==Lancement du serveur==

Pour effectuer le lancement d'un serveur Kafka suivez le lien ci-dessous:

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Comment_lancer_un_serveur_Kafka Comment lancer un service Apache Kafka]

=Démarche pour la détection d’anomalies=

Pour trouver des anomalies, nous nous sommes d'abord appuyés sur le travail de [https://www.lama.univ-savoie.fr/mediawiki/index.php/D%C3%A9tection_d%E2%80%99anomalies_par_Isolation_Forest_:_application_pour_l%E2%80%99industrie_4.0 Mila DESMET] sur l'algorithme d'Isolation Forest, cependant celui-ci avait des limites et nous avons alors exploré la détection avec un autre algorithme qui est le DBSCAN.

Pour faire notre détection d'erreurs, nous allons faire faire un montage à partir d'une carte Arduino munie d'un capteur d'humidité dont les mesures seront envoyées sur un serveur Kafka. Ces mêmes données seront ensuite lues par un consumer qui lira les mesures et pourra dès lors détecter les anomalies.

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_de_base_pour_la_d%C3%A9tection_d_anomalies Explication du code de base pour la détection d'erreurs]

==Isolation Forest==

Pour la détection d’anomalies, nous allons mettre en place un producer qui va lire les dernières données inscrites dans le topic.
Nous allons insérer les valeurs extraites dans une FILE d’une taille n puis nous allons nous servir de l’algorithme de détection d’anomalie Isolation Forest. Cet algorithme nécessite une base de donnée de référence qui vont être les n -1 premiers éléments de la FILE puis nous allons comparer les n -1 derniers éléments à notre référence. Seul le dernier élément peut changer, c’est sur celui-ci que l’on regarde s’il n’est pas anormal.
Cette méthode permet de commencer notre programme en ayant aucune valeur, cependant à chaque lancement une période d’initialisation sera nécessaire dont la durée dépendra de la taille de la FILE.

[[Fichier:CFM_exemple_file.PNG|center]]

<div style='text-align: center;'>''Exemple de la File avec en rouge l'élément observé''</div>

''La FILE doit être particulière car tous ces éléments doivent être lisibles ; soit on la dépile et on la repile, soit notre structure permet directement de la parcourir.''

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_Isolation_Forest Lien code Isolation Forest]

===Limites d'Isolation Forest===

: La taille de la FILE : il faut choisir arbitrairement la taille de la FILE mais ces limites : si la taille est trop grande, alors des anomalies pourraient être cachées par d’autres postérieurs ; si la taille est trop petite, alors le taux de faux positifs risque d’augmenter.

: Les faux positifs : l’algorithme Isolation Forest nécessite un taux de contamination par défaut, pour régler ce problème j’ai décidé que le taux serait un élément de la FILE parmi tous cela permet de réduire le nombre de faux positif mais pas de le supprimer. Plus le taux sera haut, plus notre algorithme de détection sera sensible, mais il y aura plus de faux positif.

: Les faux négatifs : tous comme les faux positifs, les faux négatifs peuvent apparaître de part les mêmes raisons.

==DBSCAN==

DBSCAN est un algorithme fondé sur la densité de clusters: c'est à dire que les points sont réunis dans des clusters, les points qui peuvent être atteindre sont alors reliés aux clusters les plus proches et si un point est trop éloigné alors si les conditions nécessaires sont réunis alors il devient un autre cluster sinon il est considéré comme une anomalie.

Les deux paramètres importants de cet algorithme sont:

: ε: la distance de l'influence d'une donnée
: N: le nombre de points pour qu'une donnée soit considérée comme appartenant à un cluster

[https://www.lama.univ-savoie.fr/mediawiki/index.php/Code_DBSCAN Lien code DBSCAN]

===Limites de DBSCAN===

: ε : l'algorithme se repose sur la distance ε qui sépare nos données, il faut alors déterminer à l'avance ce chiffre, plus il augmente plus le taux d'erreur s'élève.

: N : l'algorithme se repose sur un nombre N qui est la distance qui sépare nos données, si N est trop grand alors aucun cluster ne sera créé donc toutes nos données seront considérées comme des anomalies.

====Explication du fonctionnement de DBSCAN====

Dans cet exemple, nous allons représenter le fonctionnement de l'algorithme DBSCAN à l'aide d'un ensemble de points, un ε arbitraire ainsi qu'un N de 2.

En premier, nous allons représenter toutes les sphères d'influences de tailles ε.

[[Fichier:CFM_figure_1.PNG|600px|center]]

Ensuite, nous sélectionnons aléatoirement un point et nous regardons si il possède des voisins permettant la création d'un cluster.

[[Fichier:CFM_figure_2.PNG|600px|center]]

Tous les points qui satisfont la condition de N alors peuvent à leurs tours "propager" le cluster jusqu'à insatisfaction des conditions initiales.

[[Fichier:CFM_figure_3.PNG|600px|center]]

Dès que l'on ne peut plus propager le cluster alors on répète la première étape avec un point qui n'a pas déjà été visité.

[[Fichier:CFM_figure_4.PNG|600px|center]]

Ainsi dans notre exemple, nous voyons deux clusters: le vert et le bleu, ainsi qu'une anomalie: le point rouge.

==Limite des deux algorithmes==

: L’initialisation : si le temps entre chaque données est élevé alors la période initialisation le sera aussi et toutes les données d’initialisation ne sont pas testées, s’il y a une anomalie dans ces données, elle ne sera pas pointée.

: Trop d’anomalies : si nos données sont remplies d’anomalies et qu’elles sont constantes alors elles deviennent la normalité.

: Le temps de détection : les algorithmes mettent du temps à s’exécuter donc des données peuvent être insérées dans le topic pendant. Nous avons choisi de regarder toujours le dernier message mais cela implique d’en ignorer certains.

=Conclusion=

On peut déduire de ce projet que l'utilisation des bibliothèques de Sklearn, que sont Isolation Forest et DBSCAN, ne sont pas les plus adaptées pour la détection en temps réel d'anomalies. Pour résoudre ce problème, il faudra alors explorer d'autres bibliothèques disponibles ou bien la créer.

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:01:33Z

Franz-maximilien ceron : /* Explication du fonctionnement de DBSCAN */

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:00:45Z

Franz-maximilien ceron : /* Explication du fonctionnement de DBSCAN */

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T12:00:24Z

Franz-maximilien ceron : /* DBSCAN */

Fichier:CFM figure 4.PNG

2023-05-26T11:58:44Z

Franz-maximilien ceron :

Fichier:CFM figure 3.PNG

2023-05-26T11:58:36Z

Franz-maximilien ceron :

Fichier:CFM figure 2.PNG

2023-05-26T11:58:28Z

Franz-maximilien ceron :

Fichier:CFM figure 1.PNG

2023-05-26T11:58:17Z

Franz-maximilien ceron :

Détection d’anomalies en « temps réel » via la plateforme de streaming d’évènements Kafka

2023-05-26T11:54:06Z

Franz-maximilien ceron : /* DBSCAN */