Surveillance des volumes NetApp via SSH

Bonjour à tous, je m'appelle Igor Sidorenko. La surveillance est l'un des principaux domaines de mon travail et aussi mon hobby. Je parlerai de Zabbix et de la manière de l'utiliser pour surveiller les informations dont nous avons besoin sur les volumes NetApp, en n'ayant accès que via SSH. Qui est intéressé par le sujet de la surveillance et Zabbix, s'il vous plaît, sous cat.



Au départ, nous surveillions les volumes en les montant sur un serveur spécifique, sur lequel un modèle spécial était suspendu, en capturant les montages NFS sur le nœud et en les mettant sous surveillance, par analogie avec les systèmes de fichiers du modèle de base Linux. Le support devait être enregistré dans fstab et monté manuellement - à cause de cela, beaucoup de choses ont été perdues et oubliées.



Puis une idée géniale m'est venue à l'esprit: nous devons automatiser tout cela. Il y avait plusieurs options:

• Il existe des modèles prêts à l'emploi qui fonctionnent avec SNMP, mais sans accès.
• Obtenir une liste de volumes et monter automatiquement sur un nœud: il faut créer un dossier, enregistrer fstab, monter, c'est tout, trop d'hémorroïdes.
• Il existe une excellente API , mais comme nous ne louons que de l'espace, dans notre version d'ONTAP, il est réduit et ne fournit pas à l'utilisateur les informations nécessaires.
• Utilisez l'accès SSH pour obtenir des volumes et les configurer pour la surveillance.

Le choix s'est porté sur l' agent SSH .

Découverte de bas niveau (LLD)

Tout d'abord, nous devons créer une découverte de bas niveau (LLD) , ce seront les noms de nos volumes. Tout cela est nécessaire pour obtenir des informations spécifiques sur le volume dont nous avons besoin. Les données brutes ressemblent à ceci (114 au moment de la rédaction):

set -unit B; volume show -state online

Eh bien, comment pouvons-nous nous passer de béquilles: écrivons un script bash d'une ligne qui affichera les noms des volumes au format JSON (puisqu'il s'agit d'une vérification externe , les scripts sont sur le serveur Zabbix dans le répertoire /usr/lib/zabbix/externalscripts):









Vous devez maintenant créer un modèle et créer des éléments de données en fonction des données reçues:

Éléments de données

Pour créer automatiquement des éléments de données, vous devez prototyper les éléments : nous utiliserons des éléments principaux et quelques éléments dépendants . Ainsi, pour chaque volume, un élément maître est créé dans lequel un ensemble de commandes est exécuté via SSH:

set -unit B; df -i -volume {#VOLUME_NAME}; volume show-space {#VOLUME_NAME}; statistics volume show -volume {#VOLUME_NAME}

Nous obtenons une telle feuille:





À partir de cette feuille, nous devons sélectionner les métriques dont nous avons besoin.

La magie des expressions régulières

Au départ, je voulais utiliser JavaScript pour le prétraitement , mais je ne l'ai pas maîtrisé, cela n'a pas fonctionné. Par conséquent, je me suis arrêté chez les habitués, et je les utilise presque partout.

Nombre d'inodes utilisés

Nous sélectionnerons les informations uniquement sur les inodes pour chaque volume en deux étapes: Tout d'abord, toutes les informations:

\/vol\/\w+\/.*

Ensuite, plus précisément par métrique:

(\d+)\s+(\d+)\s+(\d+)

Sortie - Modèle de formatage de sortie. \N ( N=1..9)- la séquence d'échappement est remplacée par le Nième groupe d'appariement. La séquence d'échappement \0est remplacée par le texte correspondant:

• \1 - Inode used on {#VOLUME_NAME} - le nombre d'inodes utilisés;
• \2 - Inode free on {#VOLUME_NAME} - nombre d'inodes libres;
• \3 - Inode used percentage on {#VOLUME_NAME} - inodes utilisés en pourcentage;
• Inode total on {#VOLUME_NAME}- élément calculé , le nombre d'inodes disponibles.

last(inode_free[{#VOLUME_NAME}])+last(inode_used[{#VOLUME_NAME}])

Espace utilisé

Tout est plus simple ici, les données et les habitués sont dans un format plus agréable: on sort la métrique dont on a besoin et on ne prend que le nombre:

(?<=Logical Available:\s)\d+

Métriques collectées:

• Logical available on {#VOLUME_NAME} - la quantité d'espace logique disponible;
• Logical used percent on {#VOLUME_NAME} - place logique utilisée en pourcentage;
• Logical used size on {#VOLUME_NAME} - la quantité d'espace logique utilisé;
• Physical used percentage on {#VOLUME_NAME} - l'espace physique utilisé en pourcentage;
• Total physical used size on {#VOLUME_NAME} - la quantité d'espace physique utilisé;
• Total used on {#VOLUME_NAME} - l'espace total utilisé;
• Total used percent on {#VOLUME_NAME} - nombre total de places utilisées en pourcentage;
• Logical size on {#VOLUME_NAME}- élément calculé , la quantité d'espace logique disponible.

last(logical_available[{#VOLUME_NAME}])+last(total_used[{#VOLUME_NAME}])

Performances volumiques

Après avoir lu la documentation et fouillé avec différentes commandes, j'ai découvert que nous pouvions obtenir des métriques sur les performances de nos volumes. Un petit morceau est responsable de ceci:

statistics volume show -volume {#VOLUME_NAME}

À partir de la feuille commune avec le premier standard, nous sélectionnons les mesures de performance:

.DOMCLIC_SVM.*

Deuxièmement, nous regroupons les nombres:

(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)

Où:

• \1 - Total number of operations per second on {#VOLUME_NAME} - le nombre total d'opérations par seconde;
• \2 - Read operations per second on {#VOLUME_NAME} - lire les opérations par seconde;
• \3 - Write operations per second on {#VOLUME_NAME} - écrire des opérations par seconde;
• \4 - Other operations per second on {#VOLUME_NAME} - d'autres opérations par seconde (je ne sais pas ce que c'est, mais pour une raison quelconque je tire);
• \5 - Read throughput in bytes per second on {#VOLUME_NAME} - vitesse de lecture en octets par seconde;
• \6 - Write throughput in bytes per second on {#VOLUME_NAME} - vitesse d'écriture en octets par seconde;
• \7 - Average latency for an operation in microseconds on {#VOLUME_NAME} - latence moyenne des opérations en microsecondes.

Alerte

L'ensemble des déclencheurs est standard, place et inodes:

• Espace disque libre inférieur à 1% sur {#VOLUME_NAME}
• Espace disque libre inférieur à 5% sur {#VOLUME_NAME}
• Espace disque libre inférieur à 10% sur {#VOLUME_NAME}
• Inodes gratuits à moins de 1% sur {#VOLUME_NAME}
• Inodes gratuits à moins de 5% sur {#VOLUME_NAME}
• Inodes gratuits à moins de 10% sur {#VOLUME_NAME}

Visualisation

La visualisation se fait principalement sur Grafana , c'est beau et pratique. Par exemple, un volume ressemble à ceci: dans le coin supérieur droit, il y a un bouton Afficher dans Zabbix , avec lequel vous pouvez tomber dans Zabbix et voir toutes les métriques pour le volume sélectionné.

Résultat

• Réglage automatique des volumes pour la surveillance.
• Suppression automatique des volumes de la surveillance, si le volume est supprimé de NetApp.
• Nous nous sommes débarrassés de la liaison à un serveur et du montage manuel des volumes.
• Ajout de mesures de performances pour chaque volume. Maintenant, nous sommes moins susceptibles de retirer le support du centre de données pour le bien des graphiques de NetApp.

Bientôt, ils promettent de mettre à jour ONTAP et d'apporter une API étendue, le modèle passera à un agent HTTP .

Modèle, script et tableau de bord

github.com/domclick/netapp-volume-monitoring

Liens utiles

docs.netapp.com/ontap-9/index.jsp

www.zabbix.com/documentation/current