🔒 🥋 😠 Comment nous avons mis à jour Zabbix 💏 🤚🏿 👨🏾‍⚖️

Pourquoi aimons-nous Prométhée ? Il a une configuration - il a regardé et tout est clair, le programme fait ce qu'on lui a dit. Vous pouvez automatiser les paramètres de surveillance, les stocker dans VCS et revoir la commande. Resserré votre MR , travaillé pipeline, une nouvelle configuration appliquée à prometheus. En général, l' IaC dans toute sa splendeur.

En parlant de prométhée. L'utilisez-vous pour votre infrastructure de fer? Nous n'utilisons donc pas.

Comme beaucoup de ceux qui surveillent depuis longtemps et qui ont du matériel «nu», nous utilisons Zabbix , qui, soit dit en passant, se trouve sur ce matériel. Hélas, pour le moment, Zabbix et IaC sont des choses indépendantes. Zabbix peut être configuré manuellement ou via l'API.

Contexte

En octobre 2018, Zabbix-4.0 est sorti - une nouvelle branche LTS . Et à la mi-mars, nous avons commencé à planifier la mise à niveau de notre installation de la version 3.4 vers celle-ci.

Il n'y a eu pratiquement aucun problème particulier avec la 3.4:

Parfois, certains LLD ne fonctionnaient pas quelque part et l' impossible s'est produit, ce qui n'est pas clair comment déboguer sur une version non prise en charge par le développeur
La mémoire des extracteurs HTTP coulait constamment - à la suite de quoi le système soigneusement configuré a cloué la surveillance et a recommencé. Le problème a été masqué par une quantité décente de mémoire serveur. Le problème est bien connu, documenté .

Et dans la version 4.0, il y avait des fonctionnalités intéressantes comme les éléments HTTP natifs et les périodes de service pas pour tout l'hôte.

Et où est-il vu, assis sur une version non pertinente de la surveillance, pas même sur LTS? Nous devons rester à jour.

De plus, lors de la planification de la mise à jour, un détail intéressant a été découvert: les progrès ne s'arrêtent pas, vous pouvez prendre des voitures plus rapides à un prix inférieur. Et en cours de route, j'ai trouvé un moyen d'économiser sur le service d'hébergement déjà inutile dans plusieurs projets de collègues. Comme on dit, nous y sommes entrés avec succès.

Mise à jour du front

Il n'y a rien de particulièrement compliqué à mettre à jour le zabbix maintenant. Commandez un serveur, configurez-le, fusionnez une copie de la base de données. Mettez des packages de surveillance et montrez-leur la base, exécutez des zabbiks - et il mettra à jour tout pour vous, roulera toutes les migrations. Eh bien, oui, vous savez probablement à quel point la mise à niveau de Zabbix est devenue facile.

Au total, la migration de la base de données a pris environ 15 minutes, et même sans trop d'abus. Et tout semble aller bien. Hein? Peu importe comment! Malgré le fait que l'IP du nouveau serveur ne figure pas dans les listes blanches d'agents et qu'il ne collecte des données que de quelques hôtes de test, l' impossible se produit toujours dessus.

Au crédit des développeurs de Zabbix, je dois dire qu'ils tiennent parole - la version 4.2 est prise en charge à cette époque. Après avoir parlé dans le suivi de projet, nous découvrons que la raison de l'impossible est qu'elle ne coïncide pas avec la structure attendue de l'une des tables de base de données.

De vagues doutes se glissent. Il sera utile de rappeler que, historiquement, les tables de base de données Zabbix les plus «épaisses» ont été partitionnées. Tout d'abord, pour des raisons de performances, afin de couvrir en quelque sorte votre calque zabbix préféré - supprimer les données historiques dans le SGBDR . Nous comparons les structures de toutes les tables d'affilée dans une base de données fraîchement mise à jour et une base de contrôle - créée par le serveur lui-même à partir de zéro. Les craintes se sont confirmées. En plus de l'absence de certaines constantes dans la base de données, dans de nombreuses tables, de nombreuses colonnes numériques sont du mauvais type.

Autrement dit, nous n'avons pas de schéma de base pris en charge par les développeurs, mais notre propre «fork». Un autre type de données de colonne est potentiellement:

autre coût de stockage métrique
précision différente des nombres
différentes vitesses d'échantillonnage / d'enregistrement des métriques

Pensez pour le mieux? C'est douteux. Selon l'expérience passée avec le support technique et les développeurs zabbix, ils peuvent régler les SGBD.

Et ce type de données de colonne est possible, mais difficile et long à modifier. Et c'est impossible sans une longue surveillance des temps d'arrêt. Sans garantie de succès, sans soutien du développeur à l'avenir. Besoin d'une autre façon.

Et Zabbix l'a. Parce qu'en avril 2019, zabbix-4.2 sort

La deuxième approche du projectile

La principale caractéristique de 4.2 pour nous est la prise en charge du partitionnement prêt à l' emploi à l'aide de TimescaleDB . Après avoir discuté avec les représentants de Zabbix et nous être familiarisés avec les résultats du test de son support technique pour cette fonctionnalité ( traduction sur le hub), nous décidons de tester l'installation avec timescaledb et, sur la base des résultats, de prendre une décision sur la transition. Plus précisément: pendant un certain temps, toutes les données de surveillance seront écrites en parallèle à l'ancienne et à la nouvelle version. Et puis nous commutons simplement l'entrée DNS.

Bien sûr, cette approche ne vous permet pas d'enregistrer les données et les tendances historiques - la nouvelle base de données est remplie à partir de zéro. Mais sont-ils vraiment nécessaires? L'histoire n'a d'importance qu'ici et maintenant, elle s'accumulera à nouveau assez rapidement (regardez le même prométhée). Seule l'utilité incontestable des tendances pour la planification des capacités demeure. Dans tous les cas, l'archive avec les données déjà collectées reste avec nous (pour l'avenir - cela a été utile pour certains clients). Une autre caractéristique de la prise en charge de l'échelle de temps dans zabbix est que les périodes individuelles de stockage d'historique / de tendance ne sont plus valides.

Nous avons des clients qui insistent à tout prix sur le stockage «éternel» de toutes les données collectées. Nous pouvons leur proposer d'envisager l'installation / le support d'une installation de surveillance distincte avec des paramètres spécifiques. Notre tâche principale est d'assurer le fonctionnement stable des projets / serveurs des clients tout en maintenant un coût de services acceptable, qui comprend également le suivi.

Au total, les étapes suivantes seront requises pour la migration:

Installer et configurer une deuxième installation de surveillance
Obtenez-le tout comme dans la première installation
Switch!

Cela semble facile, non? En effet, le premier n'est pas très difficile, car lors de l'approche précédente nous avons écrit un rôle pour installer un serveur zabbix, il suffit juste de télécharger la configuration. Le troisième élément semble également simple - changer de DNS et tous les agents zabbiks, les proxys, les clients API et les personnes en direct arrivent à la nouvelle version. Mais comment faire le deuxième point?

Au début, nous avons essayé une approche naïve. Importé de la surveillance actuelle quelques-uns des modèles les plus couramment utilisés. En utilisant les scripts déjà écrits pour travailler avec l'API, nous avons commencé les mêmes projets dans la nouvelle surveillance que dans la surveillance actuelle, poussé les modifications à travers les systèmes SCM , ajoutant l'IP de la nouvelle machine au filtre de paquets et aux directives des agents Server / ServerActive . Cela a même fonctionné - de nombreux hôtes ont commencé à s'enregistrer dans deux systèmes de surveillance à la fois, le nouveau leur a attribué des modèles et a commencé à collecter des données en parallèle avec le modèle actuel.

Hélas, c'est précisément l'approche naïve de la migration, adaptée uniquement au test. La charge résultante (en nvps ) n'a pas pu être comparée à l'installation actuelle, étant inférieure de plusieurs ordres de grandeur. C'est compréhensible. Dans notre cas, la surveillance est littéralement les années de travail de nombreuses personnes et scripts, la quintessence de l'expérience dans l'exploitation de projets hétérogènes.

Par exemple, qu'en est-il des utilisateurs liquidés manuellement et de leurs mots de passe, qui sont générés de manière aléatoire lors de la création de projets, des modèles de surveillance accrochés aux hôtes (avec leurs valeurs de macro personnalisées), des éléments créés manuellement, des écrans complexes, des graphiques, des tableaux de bord, des périodes de service, des proxys? Tout cela et bien d'autres doivent être transférés pour une migration en douceur.

Heureusement, le zabbix a une fonctionnalité intégrée pour exporter / importer des objets - également disponible via l'API. Hélas, il ne couvre pas plus de la moitié de toutes les installations existantes. Et le code d'utilisation doit également être écrit. En général, vous ne pouvez pas simplement prendre et importer la configuration d'un zabbik dans un autre.

Ou est-ce possible?

Ici, le cerveau rappelle utilement la tâche du backlog qu'il serait bien d'organiser le stockage de l'historique de configuration de surveillance par des moyens externes. Hélas, c'est un point sensible de Zabbix. En référence à l' article sur le hub et le référentiel avec le code. Mais il y a des nuances:

le code n'exporte pas tous les objets de surveillance vers des fichiers YAML lisibles par l'homme (en particulier, pas tout ce dont nous avons besoin)
le code ne prend pas en charge l'importation d'objets

Heureusement, il y a des gens qui connaissent un peu le langage du projet (python) et qui ont de l'expérience avec l'API Zabbix. La seule activité consiste à importer des objets à partir de vidages YAML prêts à l'emploi. Pour combien de temps, pour faire court, mais après trois semaines de travail et cent et demi commits, une fourchette était tout à fait adaptée à nos besoins. En fait, dans l'intérêt de la présentation de laquelle l'article entier est écrit:

https://github.com/centosadmin/zabbix-review-export-import

Ce qui a été fait:

Prise en charge de nombreux nouveaux objets
Le format d'exportation YAML de la plupart des objets existants a été modifié pour pouvoir être importés
Ajout de la possibilité d'importer la plupart des objets exportés
Ajout d'une fonctionnalité limitée pour convertir des objets entre différentes versions de zabbix (comme dans notre cas)

L'importation est prise en charge presque exclusivement par la création de nouveaux objets. Si un objet existe, il ne sera pas modifié. Cela nous a permis de conserver la complexité du code au moins dans certains frameworks, de gagner du temps et d'augmenter froidement la vitesse de travail - lors de l'importation de milliers d'objets. L'utilisation de l'importation est très simple:

./zabbix-import.py /path/to/file.yaml

(on suppose que les paramètres de surveillance cible sont spécifiés dans les variables d'environnement, pour plus de détails, voir la sortie --help )

En général, vous pouvez spécifier n'importe quel nombre de fichiers YAML d'entrée - et tous seront traités. Mais compte tenu du fait qu'il existe de nombreuses dépendances entre les objets, il est plus logique d'importer des objets type par type, en commençant par les plus simples et les plus basiques. De plus, si vous importez un objet à partir d'un fichier, il peut être judicieux de spécifier explicitement son type afin d'accélérer un peu l'importation - tous les caches ne sont pas chargés, mais uniquement les nécessaires.

Ainsi, deux référentiels sont apparus dans notre hitlab avec des vidages YAML périodiquement mis à jour de deux versions de surveillance, la version actuelle et la nouvelle. Et, bien sûr, la possibilité de restaurer presque n'importe quel objet de surveillance à tout moment.

Surveillance continue du déploiement et de la migration proprement dite

En conséquence, nous sommes arrivés à la conclusion que le gitlab on schedule lance un pipeline sur le référentiel de la nouvelle surveillance, qui, étape par étape, importe hiérarchiquement un type d'objets après l'autre de l'ancienne surveillance. Cela nous a permis d'importer la grande majorité des objets et de donner à nos équipes d'administrateurs le temps de régler calmement les problèmes qui se sont posés - et ils ne se sont pas tellement accumulés au fil des ans. Les objets "supplémentaires" n'ont pas été supprimés.

Le problème avec les mots de passe utilisateur - ils sont également exportés / importés, mais un mot de passe aléatoire est attribué lors de la création - pourrait être résolu en convertissant le vidage SQL de la table avec les informations d'identification de la surveillance actuelle en instructions SQL pour définir les mots de passe corrects dans la nouvelle surveillance.

Afin de ne pas recevoir une double portion de tâches pendant le fonctionnement en parallèle, toutes les actions de la nouvelle surveillance ont été immédiatement désactivées et n'ont plus été supprimées.

Ainsi, le changement était assez facile et se résumait aux points suivants:

supprimer tous les hôtes de la nouvelle surveillance (deux scripts sur l'API sont écrits pour cela)
tirer des SCM pour mettre à jour la version du proxy zabbix et basculer les proxys vers un nouveau serveur
attendre l'importation des hôtes depuis le vidage de l'ancienne surveillance
changer les enregistrements DNS

(plan raccourci pour simplifier)

Et ensuite?

Bien sûr, le code n'est pas parfait et pas particulièrement beau. Il n'importe pas tout, en particulier, il y a des problèmes avec certains modèles - recherchez FIXME dans le code. Mais cela nous a suffi. Peut-être que cette fourchette est utile à quelqu'un d'autre. Une extension logique est le développement d'une opération similaire de l'utilitaire Terraform , lorsque la surveillance cible est complètement réduite à la forme spécifiée, par exemple, par un répertoire avec des vidages YAML. Y compris avec la réduction des installations existantes à la forme souhaitée.

Cela vous permettra d'attendre calmement la prise en charge HA "native" dans zabbix, ayant deux serveurs, les paramètres sont synchronisés automatiquement entre eux. Vous devez maintenant conserver une réplique, des proxys et écrire des scripts.

Camo à venir?

Après avoir étudié le matériel des conférences et réunions, la feuille de route officielle, le tracker d'erreur et l'expérience (modeste) de communication personnelle avec les développeurs du zabbix, il semble qu'ils comprennent parfaitement la situation dans laquelle ils se trouvent actuellement. Lorsque le zabbix a commencé, les auteurs n'ont pensé à aucun IaC lors de la résolution de leurs problèmes. Une décennie plus tard, le produit a mûri et s'est épanoui. Le revers du succès était la masse de clients de l'entreprise, dont le suivi résout leurs problèmes. Et qui n'aime pas vraiment la révolution. Dans les conditions modernes, ils sont d'une part contre tout casser et partir de zéro. D'un autre côté, ils manquent parfois de capacités de surveillance et regardent «de côté», sans oublier d'exprimer la liste de souhaits aux développeurs du Zabbix. L'entreprise ne va pas les risquer, malgré toute sympathie pour la jeunesse nouvelle, pratique et à la mode.

Nous ne verrons pas de nouveau prométhée correct de Zabbix dans un avenir proche. Peu importe comment je voudrais. Mais le travail est clairement en cours - et si vous, comme le zabbix, êtes minutieux et patient, l'avenir attend également un avenir sans nuage.

Comment nous avons mis à jour Zabbix