J’ai récemment mis à jour mon instance de zabbix, et tout s’est très bien passé, comme d’habitude. Cependant, quelques jours après, je me suis aperçu par hasard que la plupart de mes hôtes (au sens zabbix du terme), présentaient plusieurs interfaces snmp au lieu d’une seule, toutes semblant être des copies de l’unique interface originelle.

En voulant nettoyer tout ça pour n’avoir qu’une seule interface de ce type par hôte, j’ai constaté qu’il était impossible de supprimer les interfaces snmp en trop suite à la mise à jour, le bouton « supprimer » étant inactif dans l’interface.

En fait, tous mes hôtes étaient concernés, sauf ceux qui ont été intégrés dans zabbix courant 2021. Cela semblait donc correspondre à la mise à jour que j’avais faite l’année dernière, en montant à la version 5.2 depuis la 4.8, avec un passage à la 5.0; et je ne m’en apercevais que maintenant.

Après quelques recherches, je suis tombé sur un rapport de bug décrivant exactement mon problème, qui est lié à la version 5.0.

Le problème

On ne peut pas supprimer les interfaces supplémentaires tant que des items leur sont liés, ce qui semble logique.

Un commentaire dans le rapport de bug suggère donc de mettre à jour les items concernés (ou tous, comme ça pas besoin d’identifier ceux qui en ont vraiment besoin) via la fonction « mass update » pour les rattacher à la seule interface qu’on veut conserver.

Lorsque j’ai voulu appliquer la procédure sur mon premier hôte concerné (il avait 3 interfaces snmp, donc 2 à supprimer), ça a bien fonctionné pour une première, pour laquelle j’ai réussi à détacher tous les items et donc à la supprimer. Mais je n’ai pas réussi à en libérer une deuxième, et il semble que ça n’est pas arrivé qu’à moi puisqu’un autre commentaire de ce même rapport de bug décrit le même problème.

Il semble donc que certains items restent attachés à une interface, malgré l’utilisation de la fonction « mass update » qui semble donc ne pas avoir d’effets sur eux.

J’ai réussi à vaguement identifier les items concernés en modifiant l’adresse IP de l’interface concernée pour mettre une IP qui n’a rien à voir avec mes réseaux internes (j’ai mis 10.10.10.100): l’interface ne répondant plus, je n’obtenais plus de données pour les items lui étant attachés.

Et rebelote, en essayant de faire un « mass update » individuellement sur certains de ces items, ce fut un échec.

Je n’ai aucune idée de la raison qui expliquerait ce comportement.

Ma solution de gros gougnafier

J’ai fini par envisager d’aller tripoter la base de données de zabbix, pour voir si il n’y avait pas moyen de régler le problème en passant par là. Je n’aime pas du tout faire ça : déjà parce que je ne suis vraiment pas à l’aise avec les systèmes de gestion de base de données (quelle que soit la technologie), et en plus, parce que c’est mal de faire ça: la seule entité qui devrait être habilitée à modifier la base de donnée ne devrait être que l’application elle-même, car elle est conçue pour ça. Mais bon…

Dans la base de données zabbix, les interfaces sont stockées dans la table interface. On peut lister les interfaces d’un hôte en faisant une requête filtrée sur le nom de l’hôte par exemple:

MariaDB [zabbix]> select * from interface where dns like 'mon-serveur%';

| interfaceid | hostid | main | type | useip | ip | dns | port | available | error | errors_from | disable_until |

| 49 | 10113 | 1 | 2 | 1 | X.Y.Z.100 | mon-serveur.mondomaine | 161 | 1 | | 0 | 0 |

| 50 | 10113 | 0 | 2 | 1 | 10.10.10.100 | mon-serveur | 161 | 2 | Timeout while connecting to "10.10.10.100:161". | 1640867830 | 1641145944 |

Les deux interfaces de mon hôte remontent bien, et je reconnais facilement celle que je veux supprimer car elle porte l’adresse 10.10.10.100 qui est l’adresse fantaisiste que je lui ai assigné. On remarque qu’elle porte l’identifiant (interfaceid) 50.

Essayer de supprimer cette interface directement serait une mauvaise idée, car ça rendrait orphelins tous les items lui étant rattachés, et il est de toute façon très probable que les contraintes de la base de données ne nous laissent pas faire.

Par contre, maintenant que l’on connaît la valeur de son identifiant, on peut lister les items lui étant rattachés. Les items sont stockés dans la table items. On peut donc la requêter en filtrant avec le numéro de l’interface à shooter:

MariaDB [zabbix]> select * from items where interfaceid=50;
| itemid | type | snmp_oid | hostid | name | key_ | delay | history | trends | status | value_type | trapper_hosts | units | formula | logtimefmt | templateid | valuemapid | params | ipmi_sensor | authtype | username | password | publickey | privatekey | flags | interfaceid | description | inventory_link | lifetime | evaltype | jmx_endpoint | master_itemid | timeout | url | query_fields | posts | status_codes | follow_redirects | post_type | http_proxy | headers | retrieve_mode | request_method | output_format | ssl_cert_file | ssl_key_file | ssl_key_password | verify_peer | verify_host | allow_traps | discover | uuid |

| 24268 | 20 | HOST-RESOURCES-MIB::hrProcessorLoad.{#SNMPINDEX} | 10113 | Utilization of processor #$1 | hrProcessorLoad[{#SNMPINDEX}] | 30s | 1w | 365d | 0 | 3 | | % | | | 22797 | NULL | | | 0 | | | | | 2 | 50 | The average, over the last minute, of the percentage of time that this processor was not idle. Implementations may approximate this one minute smoothing period if necessary. | 0 | 0 | 0 | | NULL | 3s | | | | 200 | 1 | 0 | | | 0 | 1 | 0 | | | | 0 | 0 | 0 | 0 | |

| 24269 | 20 | HOST-RESOURCES-MIB::hrStorageAllocationUnits.{#SNMPINDEX} | 10113 | Allocation units for storage $1 | hrStorageAllocationUnits[{#SNMPVALUE}] | 30s | 1w | 365d | 0 | 3 | | B | | | 22768 | NULL | | | 0 | | | | | 2 | 50 | The size, in bytes, of the data objects allocated from this pool. If this entry is monitoring sectors, blocks, buffers, or packets, for example, this number will commonly be greater than one. Otherwise this number will typically be one. | 0 | 0 | 0 | | NULL | 3s | | | | 200 | 1 | 0 | | | 0 | 1 | 0 | | | | 0 | 0 | 0 | 0 | |

| 24270 | 20 | HOST-RESOURCES-MIB::hrStorageDescr.{#SNMPINDEX} | 10113 | Description of storage $1 | hrStorageDescr[{#SNMPVALUE}] | 1h | 1w | 0 | 0 | 1 | | | | | 22769 | NULL | | | 0 | | | | | 2 | 50 | A description of the type and instance of the storage described by this entry.

[...]

Effectivement, il y a un certain nombres de lignes dans le résultat (pour moi ici, 12 lignes, donc 12 items).

Du coup on doit pouvoir mettre à jour ces items directement dans la base de données, en modifiant ces 12 lignes pour leur modifier la valeur de la colonne interfaceid, ici en modifiant la valeur 50 en 49 (49 est l’identifiant de l’interface que je veux conserver).

MariaDB [zabbix]> update items set interfaceid=49 where interfaceid=50;

Query OK, 12 rows affected (0.002 sec)
Rows matched: 12 Changed: 12 Warnings: 0

Voilà, les 12 items ont été modifiés.

On peut donc normalement aller supprimer l’interface en trop de l’hôte directement dans sa configuration dans zabbix:

J’ai alors répété les 4 manipulations suivantes sur la vingtaine d’hôtes concernés:

• Mettre une IP bidon aux interfaces que je veux supprimer.
• Requêter la table interface en filtrant avec le nom de l’hôte, pour repérer l’identifiant des interfaces à supprimer ainsi que l’identifiant de l’interface à garder, en repérant l’IP bidon.
• Modifier tous les items qui font référence à l’interface à supprimer pour qu’ils fassent référence à l’interface à conserver.
• Supprimer les interfaces en trop depuis zabbix.

Ok, c’est un peu fastidieux, mais ça se fait vite dans un cas comme le mien où il n’y a que quelques hôtes à traiter. Pour le gars qui en a des centaines, voire des milliers, il va peut-être falloir trouver autre chose de mieux…

o/