Nutanix dans Zabbix par HTTP, quatre pièges du template officiel

Les templates Zabbix officiels « Nutanix by HTTP » remplacent une supervision SNMP en interrogeant l’API REST de Prism Element, sans script externe. Mais quatre détails du YAML trompent dès qu’on y reporte ses habitudes SNMP ; tous ont été vérifiés dans le template officiel et observés sur AOS 7.3.

Ce qu’on installe

Trois templates : « Nutanix Prism Element by HTTP », le porteur qui découvre, puis « Nutanix Cluster Prism Element by HTTP » et « Nutanix Host Prism Element by HTTP ». La découverte crée un hôte Zabbix par cluster et un par nœud. Les master items appellent l’API Prism Element v2.0 :

/PrismGateway/services/rest/v2.0/{clusters|hosts|storage_containers}

Les items sont classés par tags component (notamment application, storage, cpu, memory, network, disk, alert, health, status, raw) : il n’y a plus d’« Applications ». Le README indique des tests sur Prism Element 6.5.5.7.

Côté version de Zabbix, les sources ne disent pas la même chose selon la branche : le README de la branche master annonce 8.0 et plus, celui de la branche release/7.0 indique 7.0 ou plus, et la page d’intégration de zabbix.com affiche des variantes 7.2 et 7.4 (la 7.2 sans templates cluster et hôte séparés). Prenez le YAML de la branche de votre serveur.

Piège 1 : Host state n’est pas l’état de la CVM

L’item General: Host state (nutanix.host.general.state) lit le champ state de l’API /hosts. C’est la position du nœud dans le cycle de vie du cluster, pas l’état de sa CVM. La valuemap :

0 = New
1 = Normal      (valeur API : NORMAL)
2 = Marked for removal but not detachable
3 = Detachable
4 = Unknown

Un nœud sain renvoie 1, et 0 veut dire New. Un panel ou un trigger qui le lit comme un booléen « CVM up » affiche n’importe quoi.

Piège 2 : aucun item CVM

Le template n’a aucun item dédié à la CVM : pas d’équivalent au « Status of CVM » du SNMP. Il n’a pas non plus de découverte de VM, ni de compteurs de drops Rx/Tx par nœud.

Piège 3 : le heartbeat de 12 h de la version

L’item General: Version se termine par ce prétraitement dans le YAML officiel :

preprocessing:
  - type: JSONPATH
    parameters:
      - $.version
    error_handler: DISCARD_VALUE
  - type: DISCARD_UNCHANGED_HEARTBEAT
    parameters:
      - 12h

Une version inchangée n’est donc enregistrée qu’au battement de 12 h. Sur une fenêtre de dashboard de 12 h, le panel tombe aléatoirement en « No data », selon que le dernier battement est dedans ou juste avant.

Piège 4 : les latences sont en secondes

Exemple avec la latence I/O du cluster :

name: 'General: IO, latency'
key: nutanix.cluster.general.io.latency
value_type: FLOAT
units: s

Le template applique un multiplicateur 1.0E-6 à la valeur brute et stocke des secondes, pas des millisecondes. Un seuil pensé en millisecondes s’écrit donc divisé par mille : 5 ms deviennent 0.005.

Ce qu’il faut retenir

• Trois templates officiels, un hôte Zabbix par cluster et par nœud, tags component ; vérifiez la version requise dans la branche qui correspond à votre serveur.
• Host state décrit le cycle de vie du nœud (1 = Normal), pas la CVM.
• Pas d’item CVM, pas de découverte de VM, pas de drops Rx/Tx : à inventorier avant de couper le SNMP.
• General: Version bat toutes les 12 h : fenêtre d’au moins 2 jours.
• Latences en secondes : convertissez vos seuils.

In English

Host state is not the CVM, there is no CVM item, the version item has a 12 h heartbeat, and latencies are in seconds. Four things to know about the official Zabbix HTTP templates for Nutanix before leaving SNMP behind. Host state is the node's lifecycle state, a healthy node returns 1, and the template has no VM discovery either.

Sources & vérification

Testé sur : AOS 7.3

• Template Nutanix by HTTP (GitHub zabbix) github.com
• Zabbix integrations Nutanix zabbix.com
• Expérience directe de l’auteur, en production (versions ci-dessus)

Comment les billets sont vérifiés et corrigés