Très loin des dashboard cacti fastidieux à réaliser et limités en scalabilité, nous avons voulu une appliance la simple possible : deploy, add vcenter, relax!

MAJ 30/07/2014 : VMware vient de nous informer de la prise en compte du bug (PR 1286205) et que le correctif sera dispo Q4 2014 dans le patch 3 d’ESXi 5.5 :

Customer observed ESXi PSOD when polling IP-MIB. snmpd calling NetVsi_TcpipSysctlGet

Hormis la fameuse commande crashMe de vsish, il est généralement très difficile de reproduire un PSOD à la demande. Pourtant, nous avons trouvé un cas assez violent où l’utilisation de SNMPv3 via cacti fait crasher l’ESX de façon systématique et ce sur toutes les version depuis la 5.1 :

Evidemment, VMware est sur le coup. Pour info, nous avons utilisé le “walk through” de William pour la configuration.

The Global Positioning System (GPS) is a space-based satellite navigation system that provides location and time information in all weather conditions, anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites.

[...]

About nine satellites are visible from any point on the ground at any one time, ensuring considerable redundancy over the minimum four satellites needed for a position.

[...]

GPS time is theoretically accurate to about 14 nanoseconds. However, most receivers lose accuracy in the interpretation of the signals and are only accurate to 100 nanoseconds

C’est sur le blog de Peter Mount que nous avons pu trouver un howto des plus simples au quel nous avons ajouté un dongle wifi usb :

Le tout monitoré grâce à un template cacti :

Et en prime, un module GPIO LedBorg RGB pour savoir de visu si la source GPS du serveur NTP est ok :

Enfin, pour les fanatiques de la précision, il y a le GPS/PPS sur Raspberry Pi détaillé par David Taylor.

Tout comme pour notre post sur le monitoring smart, le tout se fait uniquement dans le fichier snmpd.conf sans script annexe. Pour rappel, l’édition de la config snmp sous nexenta se fait via la nmc avec la commande suivante :

setup network service snmp-agent edit-settings snmpd.conf

Pour chaque graphique, il faudra ajouter une ou plusieurs lignes à la config snmp et importer le template dans cacti.

extend .1.3.6.1.4.1.2021.85 arc_meta_max /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_max|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_used /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_used|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_size /bin/bash -c "echo ::arc | mdb -k| grep -w size|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_limit /bin/bash -c "echo ::arc | mdb -k| grep arc_meta_limit|tr -cd '[:digit:]'"
extend .1.3.6.1.4.1.2021.85 arc_meta_c_max /bin/bash -c "echo ::arc | mdb -k| grep c_max|tr -cd '[:digit:]'"

Graph template à importer dans cacti : ZFS – ARC Usage

extend .1.3.6.1.4.1.2021.89 arc_hits /bin/bash -c "kstat -p ::arcstats:hits| cut -s -f 2"
extend .1.3.6.1.4.1.2021.89 arc_misses /bin/bash -c "kstat -p ::arcstats:misses| cut -s -f 2"

Graph template à importer dans cacti : ZFS – ARC Stats

extend .1.3.6.1.4.1.2021.89 arc_l2_hits /bin/bash -c "kstat -p ::arcstats:l2_hits| cut -s -f 2"
extend .1.3.6.1.4.1.2021.89 arc_l2_misses /bin/bash -c "kstat -p ::arcstats:l2_misses| cut -s -f 2"

Graph template à importer dans cacti : ZFS – L2ARC Stats

extend .1.3.6.1.4.1.2021.90 vopstats_zfs_nread /bin/bash -c "kstat -p ::vopstats_zfs:nread | cut -s -f 2"
extend .1.3.6.1.4.1.2021.90 vopstats_zfs_nwrite /bin/bash -c "kstat -p ::vopstats_zfs:nwrite | cut -s -f 2

Graph template à importer dans cacti : ZFS – VFS IOPS

extend .1.3.6.1.4.1.2021.90 vopstats_zfs_read_bytes /bin/bash -c "kstat -p ::vopstats_zfs:read_bytes | cut -s -f 2"
extend .1.3.6.1.4.1.2021.90 vopstats_zfs_write_bytes /bin/bash -c "kstat -p ::vopstats_zfs:write_bytes | cut -s -f 2"

Graph template à importer dans cacti : ZFS – VFS Throughput

extend .1.3.6.1.4.1.2021.88 zpool_name /bin/bash -c "zpool list -H -o name"
extend .1.3.6.1.4.1.2021.88 zpool_snap /bin/bash -c "zpool list -Ho name|for zpool in `xargs`;do zfs get -rHp -o value usedbysnapshots $zpool|awk -F: '{sum+=$1} END{print sum}';done"
extend .1.3.6.1.4.1.2021.88 zpool_used /bin/bash -c "zpool list -Ho name|xargs zfs get -Hp -o value used"
extend .1.3.6.1.4.1.2021.88 zpool_data_used /bin/bash -c "zpool list -Ho name|for zpool in `xargs`;do snap=`zfs get -rHp -o value usedbysnapshots $zpool|awk -F: '{sum+=$1} END{print sum}'`;pool=`zfs get -Hp -o value used $zpool`; echo $pool $snap|awk '{print (\$1-\$2);}';done"
extend .1.3.6.1.4.1.2021.88 zpool_available /bin/bash -c "zpool list -Ho name|xargs zfs get -Hp -o value available"
extend .1.3.6.1.4.1.2021.88 zpool_capacity /bin/bash -c "zpool list -H -o capacity|cut -d % -f 1"

Script à copier dans le répertoire ”/resource/snmp_queries/” : ZFS – zpool usage
Graph template à importer dans cacti : ZFS – zpool usage
Ce dernier graph est similaire à celui que nous avions posté il y a quelques temps mais permet de distinguer la consommation des data de celle des snapshot.

extend .1.3.6.1.4.1.2021.84 busy /bin/bash -c "iostat -xrn 1 3|grep -E 'c2t'|grep -vE c2t15d0|tail -\$((\$(paste -d= <(iostat -x | tail -n +3 | awk '{print \$1}') <(iostat -nx | tail -n +3 | awk '{print \"/dev/dsk/\"\$11}')|grep -E 'c2t'|grep -vE c2t15d0|wc -l)*2))| awk -F',' 'BEGIN { n=0; sum=0; } { n++; sum += \$(NF-1); } END { printf (\"%.2f\",sum / n); }'|awk '{ printf (\"%d\", (\$1 > 100) ? 0 : \$1); }'"

Graph template à importer dans cacti : ZFS – disk busy
Ce graph est expérimentale et spécifique dans la mesure où il représente la charge estimée des disk filtrés par les differents grep de la commande, à ajuster en fonction de la cible. Le scénario cible idéal est un système avec un seul zpool (mis à part celui du système). Dans notre exemple, nous avons limité à tous les disques dont les noms commencent par “c2t” et exclu “c2t15d0″ (hot spare dans ce cas).

Nous avons donc fait 2 fichiers xml (check_vmware_cluster.xml et check_vmware_datastore.xml à copier dans resource/script_queries) pour la partie “data queries” et un script bash (check_esx3_helper.sh à copier dans scripts) pour faire l’intermédiaire entre cacti et le script check_vmware_api.pl (à copier dans scripts).

Selon la version de votre vCenter, il est possible que vous ayez à tuner la variable $vi_timeshift dans check_esx3_helper.sh (il nous a fallu parfois jongler entre 300 et 600) à cause d’un bug vmware.

Une fois les fichiers copiés, il faut importer les templates (cacti_data_query_vmware_vpx_-_cluster_usage.xml et cacti_data_query_vmware_vpx_-_vmfs_usage.xml) dans cacti et les associer à votre vCenter :

Nous avons utilisé les credentials snmp v3 pour éviter de mettre un login/password dans les scripts donc si vous utiliser snmp sur votre vCenter, créez un compte équivalent ou créez un device dédié.

En ce qui concerne l’autentification, le fichier de session /tmp/check_esx3_session.dat, généré automatiquement, évite les logon/logoff à répétition et soulage le proxy mob.

Il ne vous reste plus qu’à choisir les clusters et les datastores que vous voulez monitorer (la dénomination VMFS est uniquement cosmétique, les datastores NFS sont évidement supportés) :

Vous pouvez ensuite regrouper vos graph par cluster :

Les graph on une fonction de remplissage automatique qui reprend la dernière bonne valeur connue pour éviter les vilains trous qui ne plaisent pas aux managers…

vi_host package

Chez nous, à Hypervisor.fr, cacti c’est une grande passion ! Il y a presque 3 ans, quelques mois après la GA d’ESXi 3.5 (aka ESX 3i), nous avions publié un template cacti basé sur le fameux script check_esx3. Il permettait à l’époque de s’affranchir de SNMP, grand absent d’ESX 3i. Malheureusement ce script est très coûteux en ressources cpu et pouvait faire augmenter significativement le temps de polling de cacti si vous aviez de nombreux check à effectuer.

Il y a peu de temps, nous avons découvert check_vmware, une alternative (utilisable avec NAGIOS et MRTG) nettement plus efficace, developée par Steve Shipway. Cela nous a permis de finaliser notre template de monitoring de cluster et de dépoussiérer notre vieux template d’ESX.

Pour les utiliser, il vous faudra bien évidement le package vSphere SDK for Perl (aka vi perl toolkit), le script check_vmware.pl placé dans le répertoire ”scripts” de cacti, des scripts fournis dans notre package placés dans le même répertoire et du template xml à importer dans cacti. Le chemin d’accès au répertoire “scripts” est “/var/www/cacti/scripts” mais peut être changé dans les scripts.

Voici le rendu du template de cluster, suivit du lien pour le télécharger (gratuitement & légalement, vous n’aurez par de problème avec l’HADOPI) :

vi_cluster package

Et voici le rendu du template host, suivit du lien pour le télécharger :

vi_host package

Happy monitoring !

Tout à commencé à partir d’un post qui traite de la customization du snmpd.conf en vue de faire un joli graph de l’ARC de ZFS avec cacti et d’un autre au sujet de smartmontools sous Solaris. En mixant les 2, nous sommes arrivé à un moyen simple de remonter la moyenne des températures des disques d’un Nexenta dans cacti via SNMP.

• Installez smartmontools en mode expert : “apt-get install smartmontools”
• Ajoutez la ligne suivante dans la configuration snmp de Nexenta (“setup network service snmp-agent edit-settings snmpd.conf” dans la NMC) :

extend .1.3.6.1.4.1.2021.87 smart_temp /bin/bash -c "find /dev/rdsk/ -name \"*p0\" -exec /usr/sbin/smartctl -a -d scsi {} \\;|grep -E \"Temperature:.*C\"| awk 'BEGIN { n=0; sum=0; } { n++; sum += \$(NF-1); } END { printf (\"%.2f\",sum / n); }'"

• Importez notre template dans cacti et créez le graphique sur votre Nexenta

]]> http://www.hypervisor.fr/?feed=rss2&p=3335 2