Le développement industriel de systèmes logiciels nécessite une grande attention à la tolérance aux pannes du produit final, ainsi qu'une réponse rapide aux pannes et aux pannes si elles se produisent. La surveillance, bien sûr, aide à réagir aux pannes et aux défaillances plus efficacement et plus rapidement, mais pas suffisamment. Premièrement, il est très difficile de suivre un grand nombre de serveurs - il faut un grand nombre de personnes. Deuxièmement, vous devez bien comprendre le fonctionnement de l’application afin de prédire son état. Par conséquent, nous avons besoin de beaucoup de personnes ayant une bonne compréhension des systèmes que nous développons, de leurs performances et de leurs fonctionnalités. Supposons que même si vous trouvez suffisamment de personnes prêtes à le faire, leur formation prend encore beaucoup de temps.
Ce qu'il faut faire? C’est là que l’intelligence artificielle vient à notre secours. L'article parlera de (maintenance prédictive). Cette approche gagne activement en popularité. De nombreux articles ont été écrits, notamment sur Habré. Les grandes entreprises exploitent pleinement cette approche pour maintenir les performances de leurs serveurs. Après avoir étudié un grand nombre d’articles, nous avons décidé d’essayer cette approche. Qu’en est-il arrivé ?
introduction
Le système logiciel développé entre tôt ou tard en service. Il est important pour l'utilisateur que le système fonctionne sans panne. Si une urgence survient, elle doit être résolue dans les plus brefs délais.
Pour simplifier le support technique d'un système logiciel, en particulier s'il existe de nombreux serveurs, on utilise généralement des programmes de surveillance qui prennent des mesures d'un système logiciel en cours d'exécution, permettent de diagnostiquer son état et aident à déterminer exactement la cause de la panne. Ce processus est appelé surveillance du système logiciel.
Figure 1. Interface de surveillance Grafana
Les métriques sont divers indicateurs d'un système logiciel, de son environnement d'exécution ou de l'ordinateur physique sous lequel le système s'exécute, avec un horodatage du moment où les métriques ont été reçues. En analyse statique, ces métriques sont appelées séries chronologiques. Pour surveiller l'état du système logiciel, les métriques sont affichées sous forme de graphiques : le temps est sur l'axe X et les valeurs sont sur l'axe Y (Figure 1). Plusieurs milliers de métriques peuvent être extraites d'un système logiciel en cours d'exécution (de chaque nœud). Ils forment un espace de métriques (séries temporelles multidimensionnelles).
Étant donné qu’un grand nombre de mesures sont collectées pour des systèmes logiciels complexes, la surveillance manuelle devient une tâche difficile. Pour réduire la quantité de données analysées par l'administrateur, les outils de surveillance contiennent des outils permettant d'identifier automatiquement d'éventuels problèmes. Par exemple, vous pouvez configurer un déclencheur pour qu'il se déclenche lorsque l'espace disque disponible tombe en dessous d'un seuil spécifié. Vous pouvez également diagnostiquer automatiquement un arrêt du serveur ou un ralentissement critique de la vitesse du service. Dans la pratique, les outils de surveillance réussissent bien à détecter les pannes déjà survenues ou à identifier les symptômes simples de pannes futures, mais en général, prédire une éventuelle panne reste pour eux une tâche difficile. La prédiction par l'analyse manuelle des métriques nécessite l'implication de spécialistes qualifiés. C'est une faible productivité. La plupart des échecs potentiels peuvent passer inaperçus.
Récemment, la maintenance dite prédictive des systèmes logiciels est devenue de plus en plus populaire parmi les grandes sociétés de développement de logiciels informatiques. L’essence de cette approche est de détecter les problèmes conduisant à une dégradation du système dès les premiers stades, avant qu’il ne tombe en panne, grâce à l’intelligence artificielle. Cette approche n'exclut pas complètement la surveillance manuelle du système. Il est auxiliaire du processus de suivi dans son ensemble.
Le principal outil de mise en œuvre de la maintenance prédictive est la tâche de recherche d'anomalies dans les séries chronologiques, car lorsqu'une anomalie survient dans les données, il y a une forte probabilité qu'après un certain temps il y aura un échec ou un échec. Une anomalie est un certain écart dans les performances d'un système logiciel, tel que l'identification d'une dégradation de la vitesse d'exécution d'un type de requête ou d'une diminution du nombre moyen de requêtes traitées à un niveau constant de sessions client.
La tâche de recherche d'anomalies pour les systèmes logiciels a ses propres spécificités. En théorie, pour chaque système logiciel, il est nécessaire de développer ou d'affiner les méthodes existantes, car la recherche d'anomalies est très dépendante des données dans lesquelles elle est effectuée, et les données des systèmes logiciels varient fortement en fonction des outils de mise en œuvre du système. , jusqu'à l'ordinateur sur lequel il fonctionne.
Méthodes de recherche d'anomalies lors de la prévision des pannes des systèmes logiciels
Tout d'abord, il convient de dire que l'idée de prédire les échecs a été inspirée par l'article . Pour tester l'efficacité de la démarche de recherche automatique d'anomalies, le système logiciel Web-Consolidation a été choisi, qui est l'un des projets de la société NPO Krista. Auparavant, une surveillance manuelle était effectuée sur la base des métriques reçues. Le système étant assez complexe, un grand nombre de métriques sont prises en compte : indicateurs JVM (charge du garbage collector), indicateurs du système d'exploitation sous lequel le code est exécuté (mémoire virtuelle, % de charge CPU du système d'exploitation), indicateurs réseau (charge réseau ), le serveur lui-même (charge CPU, mémoire), les métriques Wildfly et les propres métriques de l'application pour tous les sous-systèmes critiques.
Toutes les métriques sont extraites du système utilisant du graphite. Initialement, la base de données Whisper était utilisée comme solution standard pour grafana, mais à mesure que la base de clients augmentait, graphite ne pouvait plus faire face, ayant épuisé la capacité du sous-système de disque DC. Après cela, il a été décidé de trouver une solution plus efficace. Le choix s'est porté en faveur , ce qui a permis de réduire la charge sur le sous-système disque d'un ordre de grandeur et de réduire l'espace disque occupé de cinq à six fois. Vous trouverez ci-dessous un schéma du mécanisme de collecte de métriques à l'aide de graphite+clickhouse (Figure 2).
Figure 2. Schéma de collecte de métriques
Le diagramme est tiré de la documentation interne. Il montre la communication entre grafana (l'interface utilisateur de surveillance que nous utilisons) et graphite. La suppression des métriques d'une application est effectuée par un logiciel distinct - . Il les met en graphite.
Le système Web Consolidation possède un certain nombre de fonctionnalités qui créent des problèmes pour prédire les échecs :
- La tendance change souvent. Différentes versions sont disponibles pour ce système logiciel. Chacun d'eux apporte des modifications à la partie logicielle du système. En conséquence, les développeurs influencent ainsi directement les métriques d'un système donné et peuvent provoquer un changement de tendance ;
- la fonctionnalité de mise en œuvre, ainsi que les finalités pour lesquelles les clients utilisent ce système, provoquent souvent des anomalies sans dégradation préalable ;
- le pourcentage d'anomalies par rapport à l'ensemble des données est faible (< 5 %) ;
- Il peut y avoir des lacunes dans la réception des indicateurs du système. Sur de courtes périodes de temps, le système de surveillance ne parvient pas à obtenir des mesures. Par exemple, si le serveur est surchargé. Ceci est essentiel pour former un réseau neuronal. Il est nécessaire de combler les lacunes de manière synthétique ;
- Les cas présentant des anomalies ne sont souvent pertinents que pour une date/mois/heure spécifique (saisonnalité). Ce système a des règles claires pour son utilisation par les utilisateurs. En conséquence, les mesures ne sont pertinentes que pour une période précise. Le système ne peut pas être utilisé en permanence, mais seulement pendant quelques mois : de manière sélective selon les années. Des situations surviennent où le même comportement des métriques dans un cas peut conduire à une défaillance du système logiciel, mais pas dans un autre.
Pour commencer, les méthodes de détection des anomalies dans les données de surveillance des systèmes logiciels ont été analysées. Dans les articles sur ce sujet, lorsque le pourcentage d'anomalies est faible par rapport au reste de l'ensemble de données, il est le plus souvent proposé d'utiliser des réseaux de neurones.
La logique de base pour la recherche d'anomalies à l'aide des données du réseau neuronal est illustrée à la figure 3 :
Figure 3. Recherche d'anomalies à l'aide d'un réseau de neurones
Sur la base du résultat de la prévision ou de la restauration de la fenêtre du flux actuel de métriques, l'écart par rapport à celui reçu du système logiciel en cours d'exécution est calculé. S'il existe une grande différence entre les métriques obtenues à partir du système logiciel et du réseau neuronal, nous pouvons conclure que le segment de données actuel est anormal. La série de problèmes suivants se pose pour l’utilisation des réseaux de neurones :
- pour fonctionner correctement en mode streaming, les données d'entraînement des modèles de réseaux neuronaux doivent inclure uniquement des données « normales » ;
- il est nécessaire d'avoir un modèle à jour pour une détection correcte. L'évolution des tendances et la saisonnalité des métriques peuvent provoquer un grand nombre de faux positifs dans le modèle. Pour le mettre à jour, il est nécessaire de déterminer clairement l'heure à laquelle le modèle est obsolète. Si vous mettez à jour le modèle plus tard ou plus tôt, il est fort probable qu'un grand nombre de faux positifs suivront.
Nous ne devons pas non plus oublier la recherche et la prévention de l’apparition fréquente de faux positifs. On suppose qu’ils se produiront le plus souvent dans des situations d’urgence. Cependant, ils peuvent également être la conséquence d’une erreur du réseau neuronal due à une formation insuffisante. Il est nécessaire de minimiser le nombre de faux positifs du modèle. Sinon, de fausses prédictions feront perdre beaucoup de temps à l'administrateur destiné à vérifier le système. Tôt ou tard, l'administrateur cessera tout simplement de répondre au système de surveillance « paranoïaque ».
Réseau neuronal récurrent
Pour détecter des anomalies dans des séries chronologiques, vous pouvez utiliser avec mémoire LSTM. Le seul problème est qu’il ne peut être utilisé que pour des séries chronologiques prévisionnelles. Dans notre cas, toutes les mesures ne sont pas prévisibles. Une tentative d'application de RNN LSTM à une série chronologique est illustrée à la figure 4.
Figure 4. Exemple de réseau neuronal récurrent avec des cellules mémoire LSTM
Comme le montre la figure 4, RNN LSTM a été en mesure de faire face à la recherche d'anomalies au cours de cette période. Lorsque le résultat présente une erreur de prédiction élevée (erreur moyenne), une anomalie dans les indicateurs s'est effectivement produite. Utiliser un seul RNN LSTM ne sera clairement pas suffisant, puisqu’il s’applique à un petit nombre de métriques. Peut être utilisé comme méthode auxiliaire pour rechercher des anomalies.
Encodeur automatique pour la prédiction des pannes
– essentiellement un réseau de neurones artificiels. La couche d'entrée est l'encodeur, la couche de sortie est le décodeur. L’inconvénient de tous les réseaux neuronaux de ce type est qu’ils localisent mal les anomalies. Une architecture d'auto-encodeur synchrone a été choisie.
Figure 5. Exemple de fonctionnement de l'auto-encodeur
Les auto-encodeurs sont formés sur des données normales, puis trouvent quelque chose d'anormal dans les données fournies au modèle. Juste ce dont vous avez besoin pour cette tâche. Il ne reste plus qu'à choisir quel auto-encodeur est adapté à cette tâche. La forme architecturale la plus simple d'un auto-encodeur est un réseau neuronal direct et non-retour, très similaire à (perceptron multicouche, MLP), avec une couche d'entrée, une couche de sortie et une ou plusieurs couches cachées les reliant.
Cependant, les différences entre les auto-encodeurs et les MLP sont que dans un auto-encodeur, la couche de sortie a le même nombre de nœuds que la couche d'entrée, et qu'au lieu d'être entraîné à prédire une valeur cible Y donnée par une entrée X, l'auto-encodeur est entraîné pour reconstruire ses propres X. Par conséquent, les auto-encodeurs sont des modèles d’apprentissage non supervisés.
La tâche de l'auto-encodeur est de trouver les indices temporels r0 ... rn correspondant aux éléments anormaux dans le vecteur d'entrée X. Cet effet est obtenu en recherchant l'erreur quadratique.
Figure 6. Encodeur automatique synchrone
Pour l'auto-encodeur a été sélectionné . Ses avantages : la possibilité d'utiliser le mode de traitement streaming et un nombre relativement réduit de paramètres de réseau neuronal par rapport aux autres architectures.
Mécanisme pour minimiser les faux positifs
En raison du fait que diverses situations anormales surviennent, ainsi qu'une éventuelle situation de formation insuffisante du réseau neuronal, pour le modèle de détection d'anomalies en cours de développement, il a été décidé qu'il était nécessaire de développer un mécanisme permettant de minimiser les faux positifs. Ce mécanisme s'appuie sur une base de modèles classée par l'administrateur.
(algorithme DTW, de l'anglais Dynamic Time Warping) permet de trouver la correspondance optimale entre des séquences temporelles. Utilisé pour la première fois en reconnaissance vocale : utilisé pour déterminer comment deux signaux vocaux représentent la même phrase parlée originale. Par la suite, des applications ont été trouvées dans d’autres domaines.
Le principe principal de la minimisation des faux positifs est de collecter une base de données de normes avec l'aide d'un opérateur qui classe les cas suspects détectés à l'aide des réseaux de neurones. Ensuite, la norme classifiée est comparée au cas détecté par le système et une conclusion est tirée quant à savoir si le cas est faux ou conduit à un échec. L'algorithme DTW est utilisé précisément pour comparer deux séries temporelles. Le principal outil de minimisation reste la classification. On s'attend à ce qu'après avoir collecté un grand nombre de cas de référence, le système commence à demander moins à l'opérateur en raison de la similitude de la plupart des cas et de l'apparition de cas similaires.
En conséquence, sur la base des méthodes de réseau neuronal décrites ci-dessus, un programme expérimental a été construit pour prédire les pannes du système « Web-Consolidation ». L'objectif de ce programme était, en utilisant les archives existantes de données de surveillance et d'informations sur les pannes précédentes, d'évaluer la compétence de cette approche pour nos systèmes logiciels. Le schéma du programme est présenté ci-dessous dans la figure 7.
Figure 7. Schéma de prédiction des défaillances basé sur une analyse de l'espace métrique
Dans le diagramme, deux blocs principaux peuvent être distingués : la recherche de périodes de temps anormales dans le flux de données de surveillance (métriques) et le mécanisme de minimisation des faux positifs. Remarque : À des fins expérimentales, les données sont obtenues via une connexion JDBC à partir de la base de données dans laquelle graphite les enregistrera.
Ce qui suit est l'interface du système de surveillance obtenue à la suite du développement (Figure 8).
Figure 8. Interface du système de suivi expérimental
L'interface affiche le pourcentage d'anomalie en fonction des métriques reçues. Dans notre cas, la réception est simulée. Nous disposons déjà de toutes les données depuis plusieurs semaines et les chargeons progressivement pour vérifier le cas d'une anomalie conduisant à une panne. La barre d'état inférieure affiche le pourcentage global d'anomalies de données à un moment donné, qui est déterminé à l'aide d'un encodeur automatique. En outre, un pourcentage distinct est affiché pour les métriques prédites, qui sont calculées par le RNN LSTM.
Un exemple de détection d'anomalies basée sur les performances du processeur à l'aide du réseau neuronal RNN LSTM (Figure 9).
Figure 9. Découverte RNN LSTM
Un cas assez simple, essentiellement une valeur aberrante ordinaire, mais conduisant à une défaillance du système, a été calculé avec succès à l'aide de RNN LSTM. L'indicateur d'anomalie sur cette période est de 85 à 95 % ; tout ce qui dépasse 80 % (le seuil a été déterminé expérimentalement) est considéré comme une anomalie.
Un exemple de détection d'anomalie lorsque le système n'a pas pu démarrer après une mise à jour. Cette situation est détectée par l'auto-encodeur (Figure 10).
Figure 10. Exemple de détection d'auto-encodeur
Comme vous pouvez le voir sur la figure, PermGen est bloqué à un niveau. L’auto-encodeur a trouvé cela étrange car il n’avait jamais rien vu de pareil auparavant. Ici, l'anomalie reste à 100 % jusqu'à ce que le système revienne à un état de fonctionnement. Une anomalie est affichée pour toutes les métriques. Comme mentionné précédemment, l'auto-encodeur ne peut pas localiser les anomalies. L'opérateur est appelé à assurer cette fonction dans ces situations.
Conclusion
Le PC "Web-Consolidation" est en développement depuis plusieurs années. Le système est dans un état assez stable et le nombre d'incidents enregistrés est faible. Cependant, il était possible de détecter des anomalies conduisant à une panne 5 à 10 minutes avant que la panne ne se produise. Dans certains cas, la notification préalable d'une panne permettrait de gagner du temps prévu pour effectuer les travaux de « réparation ».
Sur la base des expériences réalisées, il est trop tôt pour tirer des conclusions définitives. Jusqu’à présent, les résultats sont contradictoires. D’une part, il est clair que les algorithmes basés sur les réseaux de neurones sont capables de trouver des anomalies « utiles ». En revanche, il reste un pourcentage important de faux positifs et toutes les anomalies détectées par un spécialiste qualifié dans un réseau neuronal ne peuvent pas être détectées. Les inconvénients incluent le fait que le réseau neuronal nécessite désormais une formation avec un enseignant pour un fonctionnement normal.
Pour développer davantage le système de prédiction des pannes et l’amener à un état satisfaisant, plusieurs voies peuvent être envisagées. Il s'agit d'une analyse plus détaillée des cas d'anomalies qui conduisent à un échec, en raison de cet ajout à la liste des métriques importantes qui influencent grandement l'état du système, et de l'élimination des métriques inutiles qui ne l'affectent pas. De plus, si nous avançons dans cette direction, nous pouvons tenter de spécialiser les algorithmes spécifiquement pour nos cas présentant des anomalies conduisant à des échecs. Il existe une autre façon. Il s’agit d’une amélioration des architectures de réseaux neuronaux et augmente ainsi la précision de la détection avec une réduction du temps de formation.
J'exprime ma gratitude à mes collègues qui m'ont aidé à rédiger et à maintenir la pertinence de cet article : et Sergueï Finogenov.
Source: habr.com