Revue de code - pratique d'ingénierie en termes de méthodologie de développement flexible. Il s'agit d'une analyse (inspection) du code afin d'identifier les erreurs, les lacunes, les divergences dans le style d'écriture du code et de comprendre si le code résout la tâche.

Aujourd'hui, je vais vous parler de la façon dont nous avons organisé le processus d'examen de la surveillance de la configuration dans Zabbix. L'article sera utile à ceux qui travaillent avec le système de surveillance Zabbix, à la fois dans une grande équipe et seul, même si vous avez «dix hôtes, qu'est-ce qui est à revoir».

Quels problèmes résolvons-nous

Pour surveiller nos services internes et créer une infrastructure, nous utilisons Zabbix. Nous avons des conventions de dénomination - convention de nom (nous utilisons un modèle de rôle avec la mise en évidence des rôles, des modèles de profil pour la surveillance), mais il n'y a pas d'équipe de surveillance dédiée (il y a des ingénieurs seniors qui «ont mangé le chien» en matière de surveillance), il y a des ingénieurs et des ingénieurs juniors, ~ 500 hôtes, ~ 150 modèles (petite mais très dynamique infrastructure).

Cette infrastructure est utilisée pour soutenir et automatiser les processus de développement dans l'entreprise , en plus de son support, nous développons également des outils d'automatisation et d'intégration, nous avons donc peu d'expérience et de compréhension des processus de développement de l'intérieur.

Avec l'augmentation du nombre d'employés et les changements introduits dans le système de surveillance, de plus en plus d'erreurs typiques ont commencé à se produire et étaient difficiles à suivre:

1. Élément de liaison, déclenchez directement sur les hôtes, en dehors des modèles (et certains hôtes ne sont pas surveillés).
2. Valeur incorrecte des déclencheurs (sorte d'accord sur un espace disponible de 3 Go, mais une faute de frappe, nous obtenons un déclencheur jamais fonctionnel de 34 Go).
3. Non-respect de la convention de nom - et nous obtenons le nom incompréhensible du déclencheur d' échec du script (bien que cela signifie que le système de mise à jour ne fonctionne pas) ou le modèle de modèles Gitlab (surveillance de quel serveur ou agent?).
4. Désactiver un déclencheur, temporaire, pour les tests. En conséquence, nous avons manqué l'avertissement sur l'infrastructure et nous nous sommes levés.

Dans le monde des programmeurs, tous ces problèmes sont résolus tout simplement: linter, codereview. Alors pourquoi ne pas prendre ces meilleures pratiques pour un examen de la configuration de Zabbix? Prenez-le!

Nous avons déjà écrit plus tôt sur les avantages et les exemples de révision de code: Implémentation des inspections de code dans le processus de développement , Un exemple pratique de mise en œuvre de l'inspection de code, Inspection de code . Résumé

Pourquoi vous pourriez avoir besoin d'un examen des configurations Zabbix:

• Vérifiez que les hôtes et les modèles sont nommés comme acceptés dans la commande ( convention de nom ).
• Former de nouveaux employés et vérifier qu'ils ont accompli la tâche comme indiqué.
• Transférer des connaissances entre employés expérimentés.
• Les déclencheurs de notification sont désactivés accidentellement ou temporairement.
• Remarquez des valeurs incorrectes dans l'élément ou le déclencheur - dernier (0) au lieu de min (5m) .

Ajoutez vos problèmes dans les commentaires, essayez de trouver ensemble comment les résoudre avec un examen.

Comme Zabbix avec suivi des modifications

Zabbix dispose d'un sous-système d' audit , avec son aide, nous examinons qui a apporté des modifications à la configuration. Son inconvénient majeur est le grand nombre d'événements enregistrés, car il enregistre chaque événement utilisateur.

Imaginez que toute modification du code reste dans l'historique git, vous avez essayé de choisir le nom de la variable pendant une heure, vous avez essayé 40 options et toutes sont maintenant enregistrées, chaque modification est un commit séparé, puis soumettez l'historique de ces validations à la revue, sans pouvoir comparer le début et la fin version. Horrible, non?

Et dans Zabbix Audit, c'est vrai. Il peut être utilisé pour suivre les changements, mais il ne vous permet pas de voir rapidement la différence (diff) entre les deux états du système (au début de la semaine et à la fin). De plus, toutes ses actions sont divisées par type: ajouter, modifier, supprimer doit être affiché dans différentes fenêtres. Un exemple peut être trouvé dans votre Zabbix sur l'onglet Audit (ou regardez la capture d'écran). Il est difficile de comprendre quel état est initial, ce qui est courant, quels changements ont été au cours de la semaine. La situation est compliquée lorsque nous avons des dizaines de changements par semaine.

Je veux un mécanisme qui permettra:

1. Une fois par semaine ou après avoir terminé la tâche de modification de la logique de surveillance, effectuez un cast de l'état du système.
2. Comparez le nugget de configuration actuel avec le nugget précédent (diff).
3. Vérifiez automatiquement la convention de nom.
4. Vérifier la qualité de la tâche, donner des recommandations, des conseils, discuter des solutions.
5. Vérifiez que les modifications sont légitimes - toutes sont effectuées conformément à la tâche.
6. Utilisez des outils familiers pour les développeurs - git, diff, mergerequest.
7. Revenez à un état du système, mais ne perdez pas de données (par conséquent, la sauvegarde ne convient pas).
8. Contrôlez les entités Zabbix - hôte, modèles, action, macros, écran, carte.

Voyons maintenant comment nous avons implémenté le mécanisme et comment il peut vous être utile pour votre infrastructure Zabbix.

Faire une revue de configuration de Zabbix

Pour stocker la configuration Zabbix, nous utilisons les formats suivants:

1. XML d' origine - exporté à l'aide de l' exportation Zabbix d' origine. Utiliser pour l'hôte, le modèle, les objets d'écran. Il y a des fonctionnalités:
   
   • XML est difficile à lire et à visualiser les modifications;
   • contenir tous les champs, y compris ceux vides;
   • contient la date du champ - la date d'exportation, nous la coupons.
2. JSON brut - certains types d'objets que Zabbix ne sait pas exporter (actions, types de médiation), mais ils sont importants et je veux voir les changements, nous prenons donc les données brutes de ZabbixAPI et les enregistrons dans JSON.
3. YAML lisible - Nous traitons le XML exporté et le JSON brut et l'enregistrons dans un YAML vanille lisible par l'homme et pratique. Avec lui, il est facile de gérer de grands volumes de changement avec vos yeux. Ajoutez-y un petit traitement:
   
   • La suppression de champs sans valeurs est un point discutable, nous pouvons donc ignorer un champ vide, bien qu'il devrait être rempli, par exemple, un champ avec une description du problème au déclencheur (trigger.description). Après discussion, il a été décidé qu'il serait préférable de supprimer les champs vides, ils sont trop nombreux. Si vous le souhaitez, vous pouvez mettre une exception sur certains champs vides et ne pas les supprimer.
   • Nous supprimons les dates - elles changent à chaque fois et lorsque les demandes de fusion sont affichées comme des modifications pour chaque hôte.
   • Vous pouvez éventuellement ajouter d'autres opérations pour remplir les informations - l'ID utilisateur est écrit en action au lieu d'utilisateurs, par exemple.

Nous distinguons trois référentiels git (nous utilisons gitlab pour le stockage, mais n'importe quel VCS fera l'affaire):

1. zabbix-review-export - cela stockera le code d'exportation (scripts Python) et les paramètres pour les travaux gitlab-ci.
2. zabbix-xml - nous stockons XML + JSON, le tout dans une seule branche. La révision de cette entreprise est difficile et prend du temps. Utilisé pour restaurer l'état de configuration de Zabbix pour une durée spécifique.
3. zabbix-yaml est notre référentiel principal, ici nous faisons des demandes de fusion, voyons les changements, discutons les décisions prises, fusionnons en master s'il n'y a pas de commentaires.

Dans ces référentiels, nous enregistrons les données de configuration, les règles y sont les suivantes:

• regroupement par type d'objet par dossier - liste complète: https://gitlab.com/devopshq/zabbix-review-export#supported-objects
• un objet - un fichier.

Maintenant, nous voyons clairement quel type d'objet a changé, et il est clair quel objet a changé; Dans l'exemple ci-dessous, le modèle de profil a changé . Scmdev. FlusContinuousTest .

Montrer des exemples

Pour afficher les modifications, nous utilisons le mécanisme de demande de fusion dans gitlab.

Modification du modèle de profil. DevOps. Test - a modifié l'expression du déclencheur. Modèle, tel qu'il se trouve dans le dossier des modèles :

Modification de l'expression dans le déclencheur et la priorité:

Lien vers un autre modèle:

Modification de l'action - ajout d'une nouvelle ligne à la fin du texte par défaut:

Un exemple de discussions dans les demandes de fusion (tout comme les programmeurs!) - on peut voir qu'ils ont connecté le modèle standard directement à l'hôte, mais il convient de souligner un rôle distinct pour l'avenir. Capture d'écran de l'ancienne revue, puis toujours en utilisant la représentation XML de la configuration.

En général, tout est simple:

1. Ajout d'un nouvel hôte ou d'un autre objet - un nouveau fichier a été créé.
2. Changé l'hôte ou un autre objet - semblait différent.
3. Supprimé - le fichier a été supprimé.

Supposons que vous ayez terminé une tâche et que vous vouliez demander à un collègue de voir si vous avez oublié quelque chose. Nous demandons un examen: pour cela, dans le référentiel zabbix-review-export , exécutez le travail gitlab-ci avec un démarrage manuel.

Nous attribuons une demande de fusion à un collègue qui regarde, discute et corrige l'infrastructure de surveillance de code.

Une fois par semaine, une nouvelle revue est lancée pour suivre les petits changements, pour cela, selon le planning ( Schedule ), la configuration est exportée et enregistrée dans le référentiel git (avec un nouveau commit), et le gourou de la surveillance passe en revue les changements.

Vous vous étalez doucement, mais vous devez essayer

Nous allons maintenant vous expliquer comment configurer ce système pour passer en revue les configurations Zabbix ( nous aimons l'open source et essayons de partager nos meilleures pratiques avec la communauté).

Il y a deux utilisations possibles:

1. Exécutez simplement le script d'exportation à la main - exécutez le script, voyez les modifications, faites git add * && git commit && git push . Cette option convient aux changements rares ou lorsque vous travaillez avec un système de surveillance seul.
2. Utilisez gitlab-ci pour l'automatisation - il vous suffit alors de cliquer sur le bouton de démarrage (voir capture d'écran ci-dessus). L'option est plus adaptée aux grands paresseux équipes ou avec des changements fréquents.

Les deux options sont décrites dans le référentiel https://gitlab.com/devopshq/zabbix-review-export , tout ce dont vous avez besoin y est stocké - scripts, paramètres gitlab-ci et README.md, comment mettre dans votre infrastructure.

Tout d'abord, essayez la première option (ou si vous n'avez pas l'infrastructure gitlab-ci): utilisez le mode manuel - exécutez le script zabbix-export.py pour exporter (sauvegarder) la configuration, faites git add * && git commit && git push sur votre machine de travail. Lorsque vous êtes fatigué, passez à la deuxième option - automatisez l'automatisation!

Problèmes et améliorations possibles

Maintenant, les changements sont dépersonnalisés et pour savoir qui a fait les changements, vous devez utiliser le système d' audit , ce qui provoque des douleurs et des souffrances. Mais tout n'est pas si effrayant, et l'audit est rarement nécessaire, généralement un message dans le chat d'équipe suffit pour trouver le bon employé.

Autre problème: lorsqu'un hôte modifie un élément ou un déclencheur, il n'est pas contenu en XML. Autrement dit, nous pouvons désactiver tous les déclencheurs sur un hôte spécifique ou changer leur priorité sur un hôte inférieur - et personne ne le saura et ne nous corrigera! Nous attendons une solution à ce problème sur https://support.zabbix.com/browse/ZBX-15175

Jusqu'à ce qu'ils trouvent un mécanisme de récupération automatique. Supposons qu'un modèle ou un hôte soit fortement modifié, nous comprenons que les modifications sont incorrectes et que vous devez tout retourner tel quel. Maintenant, nous recherchons le XML nécessaire pour l'hôte approprié, en l'important manuellement dans l'interface utilisateur, mais nous voulions simplement cliquer sur le bouton "Restaurer le modèle TemplateName à l'état de validation commit-hash".

Vous pouvez implémenter la synchronisation bidirectionnelle - lorsque des modifications sont apportées à la configuration Zabbix lorsque des modifications sont apportées à YAML, vous n'avez pas besoin d'accéder à l'interface Web du système Zabbix. Sur github, nous avons rencontré un projet similaire, mais d'une manière ou d'une autre, il s'est rapidement évanoui et la communauté n'a pas accepté l'idée; apparemment, il n'est pas si facile d'implémenter dans YAML ce que vous pouvez cliquer avec la souris dans l'interface Web. Par conséquent, nous avons opté pour une interaction à sens unique.

L'option idéale est d'incorporer ce système pour enregistrer la configuration sous forme de code, même au format XML, dans Zabbix. Comment cela se fait sur le serveur TeamCity CI : les configurations configurées via l'interface utilisateur effectuent des validations au nom de l'utilisateur qui a modifié la configuration. Il s'avère être un outil très pratique pour visualiser les modifications et élimine également le problème de dépersonnalisation des modifications.

Essayez

Commencez à exporter votre configuration Zabbix, validez dans un référentiel (assez local), attendez une semaine et exécutez à nouveau. Maintenant, les changements sont sous votre contrôle! https://gitlab.com/devopshq/zabbix-review-export

Qui serait intéressé par cette fonctionnalité dans la boîte Zabbix - veuillez voter pour le problème https://support.zabbix.com/browse/ZBXNEXT-4862

Tous 100% disponibilité!