Zabbix Server

Prise en charge de l'Auto Scaling # expert

Comment l'Auto Scaling d'AWS fonctionne-t-il avec Zabbix ?

Pour gérer l’Auto Scaling depuis Zabbix, trois points sont à traiter :

1. Ajouter une nouvelle instance dans Zabbix quand elle apparaît. Cela se fait avec l’enregistrement automatique des agents Zabbix actifs (6.4, 6.0, 4.0). Ainsi, dès qu’une nouvelle instance apparaît, Zabbix l’ajoute automatiquement comme nouvel hôte.
2. Stocker l’ID de l’instance dans l’inventaire Zabbix. Quand l’instance disparaît (scale in), nous recevons un message avec son ID : il faut donc l’avoir dans l’inventaire de l’hôte pour le retrouver et le supprimer.
3. Recevoir les messages de scaling d’AWS. Lorsqu’AWS produit un événement de scaling, il publie un message SNS sur un topic que vous avez défini. En connectant ce topic à une file SQS, nous pouvons lire les messages depuis Zabbix et supprimer les instances qui quittent les groupes de scaling.

Configurer le client

Deux étapes sont nécessaires pour préparer vos clients à l’Auto Scaling dans Zabbix : configurer l’agent Zabbix et ajouter un fichier avec un paramètre utilisateur pour l’élément instance_id.

Configuration de l'agent Zabbix

Outre les autres changements dont vous pourriez avoir besoin, six points doivent être modifiés dans le fichier de configuration local de l’agent Zabbix, normalement /etc/zabbix/zabbix_agentd.conf :

• Commenter l’option Server.
• Ajouter ServerActive=YOUR__ZABBIX__IP__ADDRESS pour configurer le serveur actif.
• Commenter l’option Hostname.
• Mettre l’option StartAgents à 0.
• Mettre l’option HostnameItem à system.hostname.
• Mettre l’option HostMetadataItem à system.uname.

Cette configuration place le client Zabbix en mode actif (le client envoie l’information au serveur et ne reçoit pas de contrôles de sa part). Elle fait aussi utiliser le nom de la machine comme nom d’hôte, ce qui évite de le changer à chaque démarrage d’un nouveau serveur. Enfin, elle fait envoyer à Zabbix la sortie de uname comme métadonnées : les instances AWS utilisant un noyau particulier, la valeur aws y apparaît et sert à enregistrer le serveur.

Paramètre instance_id

Par défaut, quand un nouveau serveur issu d’un Auto Scaling apparaît dans Zabbix, il est lié à un modèle spécial appelé AWS EC2 Template, qui contient un élément instance_id associé au champ alias de l’inventaire. Pour l’alimenter, ajoutez un paramètre utilisateur à votre client Zabbix en créant le fichier :

UserParameter=aws.ec2.instance_id,curl -s http://169.254.169.254/latest/meta-data/instance-id

Configurer le serveur

Une fois les clients configurés, l’étape suivante consiste à configurer le serveur pour supprimer les instances retirées. La voie la plus rapide et la plus simple comporte deux étapes : envoyer les messages de scaling vers une file SQS et configurer le serveur pour la lire.

Envoyer les messages de scaling vers une file SQS

Nous voulons que les notifications envoyées par le service d’Auto Scaling soient stockées dans une file SQS, pour la durabilité et la montée en charge. Comme l’Auto Scaling AWS publie les notifications sur un topic SNS, il faut :

• Créer un topic SNS.
• Créer une file SQS.
• Configurer SNS pour livrer les messages à SQS.
• Créer un utilisateur IAM capable de lire les messages.

Cette configuration étant fastidieuse, vous pouvez utiliser notre stack CloudFormation pour créer tous les éléments dans la région de votre choix. Après le déploiement, l’onglet Outputs fournit quatre valeurs à noter :

• SNSTopicARN : l’ARN du topic SNS créé.
• SQSQueueURL : l’URL de la file SQS.
• SQSReadIAMUserAccessKey et SQSReadIAMUserSecretKey : la clé et le secret de l’utilisateur IAM.

Ces valeurs servent à la configuration. Modifiez le fichier /etc/zabbix/zabbix_ami.yml, dans le bloc semblable à :

sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url:
      access_key_id:
      secret_access_key:
      region:

Pour chaque file SQS recevant des notifications de scaling, ajoutez une entrée de tableau semblable à l’existante, avec les valeurs fournies par CloudFormation. Plus d’informations sur ce fichier dans la section fichiers importants.

Fichiers importants # expert

L’AMI Zabbix contient un certain nombre de fichiers particuliers à connaître.

/etc/zabbix/zabbix_ami.yml

C’est le plus important, car il pilote la configuration des fonctionnalités spéciales, comme les contrôles de scaling ou les notifications SNS. Un exemple (avec de fausses données) :

zabbix:
  api:
    user: autoscaler_api_user
    password: i-073672daf01037aea94
sns:
  aws:
    access_key_id: AKK4L6A3OXZZ5HE2POQRU7V
    secret_access_key: cICycAg26hSDpsJwbhZjbaaYlt4Tz3n1xqE7Oxp6X2Hf
    region: us-east-1
  topics:
    not_classified: arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    information:    arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    warning:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    average:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    high:           arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    disaster:       arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url: https://sqs.us-east-1.amazonaws.com/000000000/zabbix-pro-sqs-queue
      access_key_id: AKIA3OXZZ5HEWUR5A16CNWH
      secret_access_key: 8ttYO3Ba9K6p0C+aj3fH5cDt2eRLHmlkHbMtlrpv18S7KRbC
      region: us-east-1

Ce fichier comporte actuellement trois sections distinctes :

• zabbix : comme nous devons dialoguer avec le serveur Zabbix pour supprimer les hôtes obsolètes, il nous faut un accès API. Nous créons un utilisateur dédié, dont les identifiants figurent ici.
• sns : la configuration nécessaire à l’envoi d’alarmes via SNS. On y renseigne les identifiants de l’utilisateur IAM et les topics SNS utilisés.
• sqs : la configuration qui pilote les messages de scaling AWS. On y définit la fréquence d’interrogation de la file (delay_seconds) et les différentes files à consulter.

/var/log/zabbix-sqs-reader/zabbix-sqs-reader.log

Ce fichier consigne les différents événements d’Auto Scaling lus depuis SQS.

Avant toute configuration, vous verrez le message Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — c’est normal, et il disparaît une fois zabbix_ami.yml configuré.

Mises à jour de l'AMI # expert

Zabbix publiant régulièrement de nouvelles versions avec de nouvelles fonctionnalités, la meilleure option est de mettre à jour votre AMI de temps en temps. Malheureusement, ces mêmes nouveautés impliquent des changements en base de données et internes qui peuvent poser problème lors de la mise à jour d’une installation existante.

Notre AMI Zabbix est le meilleur moyen d’éviter ces problèmes, car nous proposons un chemin entre versions majeures plus rapide, plus simple et plus sûr que l’habituel.

La mise à jour en bref

Le processus de mise à jour de notre AMI est plutôt simple :

• Faire un dump de votre base de données actuelle.
• Lancer une nouvelle AMI dans la dernière version stable.
• Téléverser le dump vers la nouvelle instance.
• Exécuter notre script de migration.

Ainsi, vous conservez en parallèle la version actuelle et la nouvelle, et vous pouvez tester autant que nécessaire avant de déplacer les EIP associées à cette instance, ou de migrer les clients progressivement.

Processus de mise à jour

Étape 1 : sauvegarder le serveur source

La première étape consiste à créer une image du serveur source, pour éviter toute perte accidentelle de données. Vous pouvez suivre le manuel AWS pour créer une AMI.

Étape 2 : dump de la base et version de Zabbix

On se connecte en SSH à l’instance et on passe root :

sudo /bin/su -

Puis on exporte la base de données dans un fichier :

mysqldump zabbix > zabbix_origin_database.sql

Enfin, on télécharge ce fichier sur sa machine pour le téléverser ensuite sur le nouveau serveur. Notez également la version de Zabbix en cours : elle est visible dans l’interface web, et ressemble à 4.0, 4.2, 4.4 ou 5.4.

Étape 3 : lancer une nouvelle instance Zabbix

L’étape suivante consiste à créer une nouvelle instance Zabbix, avec la dernière version stable de l’AMI disponible sur notre profil vendeur AWS Marketplace. Il faut au minimum la version 6.0 de notre AMI Zabbix.

Cette nouvelle instance sera le serveur cible où nous déplacerons les données, et elle embarque déjà la dernière version installée et à jour. Une fois démarrée, copiez-y le dump de la base du serveur source.

Étape 4 : mettre à jour la base de données

Pour importer votre base actuelle, la migrer vers la nouvelle version et ajouter les configurations nécessaires, utilisez le script /opt/tools/bin/zabbix-ami-upgrade.sh, à exécuter en tant qu’utilisateur ubuntu en lui indiquant la version d’origine de Zabbix et le fichier de dump. Par exemple, depuis Zabbix 4.0 :

/opt/tools/bin/zabbix-ami-upgrade.sh 4.0 zabbix_origin_database.sql

Le processus indique chaque étape effectuée et, une fois terminé, vous pouvez travailler avec votre nouveau serveur Zabbix.

Étape 5 : accéder à l'interface web

Une fois la migration terminée, vous pouvez ouvrir l’interface web et vérifier l’état général du serveur. Attention : il faut utiliser les mêmes utilisateurs et mots de passe que sur le serveur précédent.

Étape 6 : migrer les configurations spéciales et pointer les clients

Une fois la base opérationnelle, tenez compte des autres configurations éventuellement installées sur le serveur, par exemple :

• Scripts de supervision.
• Paquets système supplémentaires.
• Certificats SSL installés.

Il faudra également déplacer l’EIP associée à cette instance, afin que les clients n’aient rien à changer.

Si vous n’utilisez pas d’EIP, c’est le bon moment pour commencer : sinon il faudra changer l’IP du nouveau serveur sur tous les clients.