Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Bonjour à tous!

Notre société est engagée dans le développement de logiciels et le support technique ultérieur. Le support technique nécessite non seulement de corriger les erreurs, mais aussi de surveiller les performances de nos applications.

Par exemple, si l'un des services tombe en panne, vous devez alors enregistrer automatiquement ce problème et commencer à le résoudre, et ne pas attendre que les utilisateurs insatisfaits contactent le support technique.

Nous sommes une petite entreprise, nous n’avons pas les ressources nécessaires pour étudier et maintenir des solutions complexes de surveillance des applications, il nous fallait trouver une solution simple et efficace.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Stratégie de surveillance

Il n’est pas facile de vérifier les fonctionnalités d’une application, cette tâche n’est pas anodine, on pourrait même dire créative. Il est particulièrement difficile de vérifier un système multi-liens complexe.

Comment peut-on manger un éléphant ? Seulement en partie ! Nous utilisons cette approche pour surveiller les applications.

L’essence de notre stratégie de surveillance :

Décomposez votre application en composants.
Créez des contrôles de contrôle pour chaque composant.

Un composant est considéré comme opérationnel si tous ses contrôles sont effectués sans erreur. Une application est considérée comme saine si tous ses composants sont fonctionnels.

Ainsi, tout système peut être représenté comme un arbre de composants. Les composants complexes sont décomposés en composants plus simples. Les composants simples ont des contrôles.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Les benchmarks ne sont pas destinés à effectuer des tests fonctionnels, ce ne sont pas des tests unitaires. Les contrôles doivent vérifier comment le composant se sent à l'heure actuelle, s'il dispose de toutes les ressources nécessaires à son fonctionnement et s'il y a des problèmes.

Il n’y a pas de miracles ; la plupart des contrôles devront être développés de manière indépendante. Mais n'ayez pas peur, car dans la plupart des cas, une vérification prend 5 à 10 lignes de code, mais vous pouvez implémenter n'importe quelle logique et vous comprendrez clairement comment fonctionne la vérification.

Système de surveillance

Disons que nous divisons l'application en composants, avons imaginé et mis en œuvre des contrôles pour chaque composant, mais que faire des résultats de ces contrôles ? Comment savoir si une vérification a échoué ?

Nous aurons besoin d’un système de surveillance. Elle effectuera les tâches suivantes :

  • Recevez les résultats des tests et utilisez-les pour déterminer l’état des composants.
    Visuellement, cela ressemble à une mise en évidence de l'arborescence des composants. Les composants fonctionnels deviennent verts, ceux qui posent problème deviennent rouges.
  • Effectuez des vérifications générales dès le départ.
    Le système de surveillance peut effectuer lui-même certaines vérifications. Pourquoi réinventer la roue, utilisons-les. Par exemple, vous pouvez vérifier qu'une page de site Web s'ouvre ou que le serveur envoie un ping.
  • Envoyez des notifications de problèmes aux parties intéressées.
  • Visualisation des données de surveillance, fourniture de rapports, graphiques et statistiques.

Brève description du système ASMO

Il est préférable d'expliquer avec un exemple. Voyons comment est organisé le suivi des performances du système ASMO.

ASMO est un système automatisé de support météorologique. Le système aide les spécialistes du service routier à comprendre où et quand il est nécessaire de traiter la route avec des matériaux de déglaçage. Le système collecte des données à partir des points de contrôle routier. Un point de contrôle routier est un endroit sur la route où sont installés des équipements : une station météo, une caméra vidéo, etc. Pour prévoir les situations dangereuses, le système reçoit des prévisions météorologiques provenant de sources externes.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Ainsi, la composition du système est assez typique : site internet, agent, équipement. Commençons par la surveillance.

Décomposer le système en composants

Les composants suivants peuvent être distingués dans le système ASMO :

1. Compte personnel
Il s'agit d'une application Web. Il faut au minimum vérifier que l'application est disponible sur Internet.

2. Base de données
La base de données stocke les données importantes pour la création de rapports et vous devez vous assurer que les sauvegardes de base de données sont créées avec succès.

3. Serveur
Par serveur, nous entendons le matériel sur lequel les applications s'exécutent. Il est nécessaire de vérifier l'état du disque dur, de la RAM et du CPU.

4. Agent
Il s'agit d'un service Windows qui effectue de nombreuses tâches différentes selon un planning. Au minimum, vous devez vérifier que le service est en cours d'exécution.

5. Tâche d'agent
Il ne suffit pas de savoir qu’un agent travaille. Un agent peut travailler, mais ne pas accomplir les tâches qui lui sont assignées. Divisons le composant agent en tâches et vérifions si chaque tâche d'agent fonctionne correctement.

6. Points de contrôle routier (conteneur de tous les MPC)
Il existe de nombreux points de contrôle routier, combinons donc tous les MPC en un seul composant. Cela rendra plus pratique la lecture des données de surveillance. Lors de la visualisation de l'état du composant « Système ASMO », il sera immédiatement clair où se trouvent les problèmes : dans les applications, dans le matériel ou dans le système de contrôle maximum.

7. Point de contrôle routier (une limite maximale)
Nous considérerons ce composant comme réparable si tous les appareils de ce MPC sont réparables.

8. Appareil
Il s'agit d'une caméra vidéo ou d'une station météo installée à la limite de concentration maximale. Il est nécessaire de vérifier que l'appareil fonctionne correctement.

Dans le système de surveillance, l'arborescence des composants ressemblera à ceci :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Surveillance des applications Web

Nous avons donc divisé le système en composants, nous devons maintenant proposer des contrôles pour chaque composant.

Pour surveiller une application Web, nous utilisons les vérifications suivantes :

1. Vérification de l'ouverture de la page principale
Ce contrôle est effectué par le système de surveillance. Pour l'exécuter, nous indiquons l'adresse de la page, le fragment de réponse attendu et le temps maximum d'exécution de la requête.

2. Vérification de la date limite de paiement du domaine
Un contrôle très important. Lorsqu'un domaine reste impayé, les utilisateurs ne peuvent pas ouvrir le site. La résolution du problème peut prendre plusieurs jours, car... Les modifications DNS ne sont pas appliquées immédiatement.

3. Vérification du certificat SSL
De nos jours, presque tous les sites Web utilisent le protocole https pour y accéder. Pour que le protocole fonctionne correctement, vous avez besoin d'un certificat SSL valide.

Vous trouverez ci-dessous le composant « Compte personnel » dans le système de surveillance :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Toutes les vérifications ci-dessus fonctionneront pour la plupart des applications et ne nécessiteront aucun codage. C'est très cool car vous pouvez commencer à surveiller n'importe quelle application Web en 5 minutes. Vous trouverez ci-dessous des vérifications supplémentaires qui peuvent être effectuées pour une application Web, mais leur mise en œuvre est plus complexe et spécifique à l'application, nous ne les aborderons donc pas dans cet article.

Que pouvez-vous vérifier d'autre ?

Pour surveiller plus complètement votre application Web, vous pouvez effectuer les vérifications suivantes :

  • Nombre d'erreurs JavaScript par période
  • Nombre d'erreurs côté application web (back-end) sur la période
  • Nombre de réponses d'applications Web infructueuses (codes de réponse 404, 500, etc.)
  • Temps moyen d'exécution des requêtes

Surveillance d'un service Windows (agent)

Dans le système ASMO, l'agent joue le rôle d'un planificateur de tâches, qui exécute les tâches planifiées en arrière-plan.

Si toutes les tâches de l'agent se terminent avec succès, l'agent fonctionne correctement. Il s'avère que pour surveiller un agent, vous devez surveiller ses tâches. Par conséquent, nous divisons le composant « Agent » en tâches. Pour chaque tâche, nous créerons un composant distinct dans le système de surveillance, où le composant « Agent » sera le « parent ».

Nous divisons le composant Agent en composants enfants (tâches) :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Nous avons donc décomposé un composant complexe en plusieurs composants simples. Nous devons maintenant proposer des contrôles pour chaque composant simple. Veuillez noter que le composant parent « Agent » ne fera l'objet d'aucune vérification, car le système de surveillance calculera son statut de manière indépendante en fonction de l'état de ses composants enfants. En d’autres termes, si toutes les tâches sont terminées avec succès, l’agent s’exécute correctement.

Il y a plus d'une centaine de tâches dans le système ASMO, est-il vraiment nécessaire de proposer des contrôles uniques pour chaque tâche ? Bien sûr, le contrôle sera meilleur si nous proposons et mettons en œuvre nos propres contrôles spéciaux pour chaque tâche d'agent, mais dans la plupart des cas, il suffit d'utiliser des contrôles universels.

Le système ASMO utilise uniquement des contrôles universels pour les tâches, ce qui est suffisant pour surveiller les performances du système.

Vérifier la progression
Le contrôle le plus simple et le plus efficace est le contrôle d’exécution. Le contrôle vérifie que la tâche est terminée sans erreurs. Toutes les tâches ont cette vérification.

Vérifier l'algorithme

Après chaque exécution de tâche, vous devez envoyer le résultat de la vérification SUCCÈS au système de surveillance si l'exécution de la tâche a réussi, ou ERREUR si l'exécution s'est terminée avec une erreur.

Cette vérification peut détecter les problèmes suivants :

  1. La tâche s'exécute mais échoue avec une erreur.
  2. La tâche a cessé de s'exécuter, par exemple, elle s'est gelée.

Examinons plus en détail comment ces problèmes sont résolus.

Problème 1 – La tâche s'exécute mais échoue avec une erreur
Vous trouverez ci-dessous un cas où la tâche s'exécute mais échoue entre 14h00 et 16h00.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

La figure montre que lorsqu'une tâche échoue, un signal est immédiatement envoyé au système de surveillance et l'état du contrôle correspondant dans le système de surveillance devient une alarme.

Veuillez noter que dans le système de surveillance, l'état du composant dépend de l'état de vérification. L'état d'alarme du contrôle fera passer tous les composants de niveau supérieur en alarme, voir la figure ci-dessous.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Problème 2 - La tâche a cessé de s'exécuter (gelée)
Comment le système de surveillance comprendra-t-il qu’une tâche est bloquée ?

Le résultat du contrôle a une durée de validité, par exemple 1 heure. Si une heure s'écoule et qu'il n'y a pas de nouveau résultat de test, le système de surveillance définira l'état du test sur alarme.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Sur la photo ci-dessus, les lumières ont été éteintes à 14h00. A 15h00, le système de surveillance détectera que le résultat du test (à partir de 14h00) est pourri, car Le temps de pertinence a expiré (une heure), mais il n'y a pas de nouveau résultat et le contrôle passera à l'état d'alarme.

À 16h00, les lumières ont été rallumées, le programme terminera la tâche et enverra le résultat de l'exécution au système de surveillance, l'état du test deviendra à nouveau un succès.

Quel délai de pertinence de vérification dois-je utiliser ?

Le temps de pertinence doit être supérieur à la période d'exécution de la tâche. Je recommande de définir le temps de pertinence 2 à 3 fois plus long que la période d'exécution de la tâche. Ceci est nécessaire pour éviter de recevoir de fausses notifications lorsque, par exemple, une tâche a pris plus de temps que d'habitude ou que quelqu'un a rechargé le programme.

Vérifier la progression

Le système ASMO dispose d'une tâche « Load Forecast », qui tente de télécharger une nouvelle prévision à partir d'une source externe une fois par heure. L'heure exacte à laquelle une nouvelle prévision apparaît dans le système externe n'est pas connue, mais on sait que cela se produit 2 fois par jour. Il s'avère que s'il n'y a pas de nouvelles prévisions depuis plusieurs heures, c'est normal, mais s'il n'y a pas de nouvelles prévisions depuis plus d'une journée, alors quelque chose s'est cassé quelque part. Par exemple, le format des données dans un système de prévision externe peut changer, c'est pourquoi ASMO ne verra pas de nouvelle publication de prévisions.

Vérifier l'algorithme

La tâche envoie le résultat du contrôle SUCCÈS au système de surveillance lorsqu'elle réussit à progresser (téléchargement d'une nouvelle prévision météo). S'il n'y a aucun progrès ou qu'une erreur se produit, rien n'est envoyé au système de surveillance.

Le contrôle doit avoir un intervalle de pertinence tel que pendant ce temps il soit garanti de recevoir de nouveaux progrès.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Veuillez noter que nous prendrons connaissance du problème avec un certain retard, car le système de surveillance attend que la période de validité du dernier résultat d'analyse expire. Il n’est donc pas nécessaire que la durée de validité du chèque soit trop longue.

Surveillance de base de données

Pour contrôler la base de données dans le système ASMO, nous effectuons les vérifications suivantes :

  1. Vérification de la création de la sauvegarde
  2. Vérification de l'espace disque libre

Vérification de la création de la sauvegarde
Dans la plupart des applications, il est important de disposer de sauvegardes de base de données à jour afin de pouvoir déployer le programme sur un nouveau serveur en cas de panne du serveur.

ASMO crée une copie de sauvegarde une fois par semaine et l'envoie au stockage. Lorsque cette procédure est terminée avec succès, le résultat du contrôle de réussite est envoyé au système de surveillance. Le résultat de la vérification est valable 9 jours. Ceux. Pour contrôler la création des sauvegardes, le mécanisme de « contrôle de progression », dont nous avons parlé ci-dessus, est utilisé.

Vérification de l'espace disque libre
S'il n'y a pas assez d'espace libre sur le disque, la base de données ne pourra pas fonctionner correctement, il est donc important de contrôler la quantité d'espace libre.

Il est pratique d'utiliser des métriques pour vérifier les paramètres numériques.

Métrique est une variable numérique dont la valeur est transmise au système de surveillance. Le système de surveillance vérifie les valeurs seuils et calcule l'état de la métrique.

Vous trouverez ci-dessous une image de ce à quoi ressemble le composant « Base de données » dans le système de surveillance :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Surveillance du serveur

Pour surveiller le serveur, nous utilisons les contrôles et métriques suivants :

1. Espace disque libre
Si l'espace disque est épuisé, l'application ne pourra pas fonctionner. Nous utilisons 2 valeurs seuils : le premier niveau est AVERTISSEMENT, le deuxième niveau est ALARME.

2. Valeur moyenne de la RAM en pourcentage par heure
Nous utilisons la moyenne horaire parce que... nous ne sommes pas intéressés par les races rares.

3. Pourcentage moyen de CPU par heure
Nous utilisons la moyenne horaire parce que... nous ne sommes pas intéressés par les races rares.

4. Vérification du ping
Vérifie que le serveur est en ligne. Le système de surveillance peut effectuer cette vérification ; il n’est pas nécessaire d’écrire du code.

Vous trouverez ci-dessous une image de ce à quoi ressemble le composant « Serveur » dans le système de surveillance :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Surveillance des équipements

Je vais vous dire comment les données sont obtenues. Pour chaque point de contrôle routier (MPC), il existe une tâche dans le planificateur de tâches, par exemple « Survey MPC M2 km 200 ». La tâche reçoit les données de tous les appareils MPC toutes les 30 minutes.

Problème de canal de communication
La plupart des équipements sont situés en dehors de la ville ; pour la transmission des données, un réseau GSM est utilisé, qui ne fonctionne pas de manière stable (il y a un réseau, ou il n'y en a pas).

En raison de pannes de réseau fréquentes, au début, la vérification de l'enquête MPC dans la surveillance ressemblait à ceci :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Il est devenu évident que cette option ne fonctionnait pas, car il y avait de nombreuses fausses notifications concernant des problèmes. Ensuite, il a été décidé d'utiliser un « contrôle de progression » pour chaque appareil, c'est-à-dire Seul le signal de réussite est envoyé au système de surveillance lorsque l'appareil est interrogé sans erreur. Le temps de pertinence a été fixé à 5 heures.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Désormais, la surveillance envoie des notifications sur les problèmes uniquement lorsque l'appareil ne peut pas être interrogé pendant plus de 5 heures. Avec un degré de probabilité élevé, il ne s’agit pas de fausses alarmes, mais de problèmes réels.

Vous trouverez ci-dessous une image de ce à quoi ressemble l'équipement dans le système de surveillance :

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Important!
Lorsque le réseau GSM cesse de fonctionner, tous les appareils MDC ne sont pas interrogés. Pour réduire le nombre d'e-mails du système de surveillance, nos ingénieurs s'abonnent aux notifications sur les problèmes de composants avec le type « MPC » plutôt que « Device ». Cela vous permet de recevoir une notification pour chaque MPC, plutôt que de recevoir une notification distincte pour chaque appareil.

Programme final de surveillance de l'ASMO

Rassemblons tout et voyons quel type de système de surveillance nous avons.

Nous mangeons l'éléphant en morceaux. Stratégie de surveillance de l’état des applications avec exemples

Conclusion

Résumons.
Que nous a apporté le suivi des performances d’ASMO ?

1. Le temps d'élimination des défauts a diminué
Nous avons déjà entendu parler de défauts de la part des utilisateurs, mais tous les utilisateurs ne signalent pas de défauts. Il est arrivé que nous ayons appris un dysfonctionnement d'un composant du système une semaine après son apparition. Désormais, le système de surveillance nous informe des problèmes dès qu'un problème est détecté.

2. La stabilité du système a augmenté
Étant donné que les défauts ont commencé à être éliminés plus tôt, le système dans son ensemble a commencé à fonctionner de manière beaucoup plus stable.

3. Réduire le nombre d'appels au support technique
De nombreux problèmes sont désormais résolus avant même que les utilisateurs ne s’en rendent compte. Les utilisateurs ont commencé à contacter moins souvent le support technique. Tout cela a un effet positif sur notre réputation.

4. Augmenter la fidélité des clients et des utilisateurs
Le client a remarqué des changements positifs dans la stabilité du système. Les utilisateurs rencontrent moins de problèmes lors de l'utilisation du système.

5. Réduisez les coûts de support technique
Nous avons arrêté d'effectuer des contrôles manuels. Désormais, tous les contrôles sont automatisés. Auparavant, nous étions informés des problèmes par les utilisateurs ; il était souvent difficile de comprendre de quel problème l'utilisateur parlait. Désormais, la plupart des problèmes sont signalés par le système de surveillance ; les notifications contiennent des données techniques, qui indiquent toujours clairement ce qui n'a pas fonctionné et où.

Important!
Vous ne pouvez pas installer le système de surveillance sur le même serveur sur lequel vos applications s'exécutent. Si le serveur tombe en panne, les applications cesseront de fonctionner et personne ne pourra en informer.

Le système de surveillance doit fonctionner sur un serveur distinct dans un autre centre de données.

Si vous ne souhaitez pas utiliser de serveur dédié dans un nouveau centre de données, vous pouvez utiliser un système de surveillance cloud. Notre société utilise le système de surveillance cloud Zidium, mais vous pouvez utiliser n'importe quel autre système de surveillance. Le coût d'un système de surveillance cloud est inférieur à celui de la location d'un nouveau serveur.

Recommandations:

  1. Décomposez les applications et les systèmes sous la forme d'une arborescence de composants de manière aussi détaillée que possible, afin qu'il soit pratique de comprendre où et ce qui est cassé, et que le contrôle soit plus complet.
  2. Pour vérifier la fonctionnalité d'un composant, utilisez des tests. Il est préférable d’utiliser plusieurs contrôles simples plutôt qu’un seul complexe.
  3. Configurez des seuils de métriques du côté du système de surveillance, plutôt que de les écrire dans le code. Cela vous évitera d'avoir à recompiler, reconfigurer ou redémarrer l'application.
  4. Pour les contrôles personnalisés, utilisez une marge de temps de pertinence pour éviter de recevoir de fausses notifications car certaines vérifications ont pris un peu plus de temps que d'habitude.
  5. Essayez de faire en sorte que les composants du système de surveillance deviennent rouges uniquement lorsqu'il y a définitivement un problème. S'ils deviennent rouges pour rien, alors vous cesserez de prêter attention aux notifications du système de surveillance, leur signification sera perdue.

Si vous n'utilisez pas encore de système de surveillance, commencez ! Ce n'est pas aussi difficile qu'il y paraît. Amusez-vous en regardant l’arbre d’ingrédients verts que vous avez vous-même cultivé.

Bonne chance.

Source: habr.com

Ajouter un commentaire