Lors de la création d'une solution pour un client, 2 tâches se sont posées que je voulais résoudre magnifiquement et avec les fonctionnalités régulières de Zabbix.
Tâche 1. Suivi de la version actuelle du firmware sur les routeurs Mikrotik.
La tâche est résolue facilement - en ajoutant un agent au modèle HTTP. L'agent reçoit la version actuelle du site Web Mikrotik, et le déclencheur compare la version actuelle avec la version actuelle et émet une alerte en cas de divergence.
Quand on a 10 routeurs, un tel algorithme n'est pas critique, mais que faire avec 3000 routeurs ? Envoyer 3000 requêtes au serveur ? Bien sûr, un tel schéma fonctionnera, mais l'idée même de 3000 requêtes ne me convenait pas, je voulais trouver une autre solution. De plus, il y avait toujours un inconvénient dans un tel algorithme : l'autre côté peut compter un tel nombre de requêtes d'une adresse IP pour une attaque DoS, ils peuvent simplement l'interdire.
Tâche 2. Utilisation d'une session d'autorisation dans différents agents HTTP.
Lorsqu'un agent a besoin de recevoir des informations de pages "fermées" via HTTP, un cookie d'autorisation est nécessaire. Pour ce faire, il existe généralement un formulaire d'autorisation standard avec un couple "login / mot de passe" et la définition de l'identifiant de session dans le cookie.
Mais il y a un problème, il est impossible d'accéder aux données d'une autre rubrique à partir d'une rubrique de l'agent HTTP pour substituer cette valeur dans le Header.
Il existe également un "script Web", il a une autre limitation, il ne vous permet pas d'obtenir du contenu pour analyse et sauvegarde ultérieure. Vous pouvez uniquement vérifier la présence des variables nécessaires sur les pages ou transmettre des variables précédemment reçues entre les étapes de script Web.
Après avoir un peu réfléchi à ces tâches, j'ai décidé d'utiliser des macros parfaitement visibles dans n'importe quelle partie du système de surveillance : dans les modèles, les hôtes, les déclencheurs ou les éléments. Et vous pouvez mettre à jour les macros via l'API de l'interface Web.
Zabbix a une documentation API bonne et détaillée. Pour l'échange de données via api, le format de données Json est utilisé. Les détails peuvent être trouvés dans .
La séquence d'actions pour obtenir les données dont nous avons besoin et les enregistrer dans une macro est illustrée dans le schéma ci-dessous.
Étape 1
La toute première étape peut consister en une seule action ou en plusieurs actions. Toute la logique principale est posée dans les premières étapes, et les 3 dernières étapes sont les principales.
Dans mon exemple, la première étape consistait à obtenir des cookies d'autorisation sur le PBX pour la première tâche. Pour la deuxième tâche, j'ai obtenu le numéro de la version actuelle du firmware Mikrotik.
URL des versions actuelles du firmware Mikrotik
- - Adresse URL de la version stable actuelle
- — Adresse URL de la version LTS actuelle
Ces adresses sont accessibles par l'équipement Mikrotik lui-même lorsque la dernière version disponible du micrologiciel est reçue.
La première étape est complètement individuelle pour chaque cas et la logique de son travail peut être différente. Tout dépend de votre tâche.
Lorsque vous travaillez avec des scripts Web, gardez une trace de la méthode de réponse dont vous avez besoin. Les rubriques Réponse HTTP ou auto тело réponse sans en-tête ?
Si des cookies d'autorisation sont nécessaires, définissez la méthode de réponse Les rubriques comme dans le cas d'Astérisque.Si vous avez besoin de données, comme dans le cas de la réponse du serveur mikrotik, mettez Corps réponse sans en-tête.
Étape 2
Passons à la deuxième étape. Obtenir une session d'autorisation :
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin"
"password": "zabbix"
},
"id": 1,
"auth": null
}jsonrpc est la version du protocole JSON-RPC qui est utilisée ;
Zabbix implémente JSON-RPC version 2.0 ;
- method - la méthode qui est appelée ;
- params - paramètres passés par la méthode ;
- id est un identifiant de requête arbitraire ;
- auth - clé d'authentification de l'utilisateur ; puisque nous ne l'avons pas encore, définissons-le sur null.
Pour travailler avec l'API, j'ai créé un compte séparé avec des droits limités. Premièrement, vous n'avez pas besoin de donner accès là où vous n'en avez pas besoin. Et deuxièmement, avant la version 5.0, le mot de passe défini via la macro pouvait être lu. Par conséquent, si vous utilisez le mot de passe administrateur Zabbix, le compte administrateur est facile à voler.
Cela sera particulièrement vrai lorsque vous travaillez avec l'API via des scripts tiers et que vous stockez les informations d'identification sur le côté.
Depuis la version 5.0, il existe une option pour masquer le mot de passe enregistré dans la macro.
Lors de la création d'un compte séparé pour la mise à jour des données via l'API, assurez-vous de vérifier si les données dont vous avez besoin sont disponibles via l'interface Web et s'il est possible de les mettre à jour. Je n'ai pas vérifié, puis pendant longtemps je n'ai pas compris pourquoi la macro dont j'avais besoin n'était pas visible dans l'API.
Après avoir reçu l'autorisation dans l'API, nous procédons à l'obtention d'une liste de macros.
Étape 3
L'API ne vous permet pas de mettre à jour une macro hôte par son nom, vous devez d'abord obtenir l'ID de la macro. De plus, pour obtenir une liste de macros pour un hôte spécifique, vous devez connaître l'ID de cet hôte, et c'est une demande supplémentaire. Utiliser la macro par défaut {ID HÔTE} dans la demande n'est pas autorisé. J'ai décidé de contourner la restriction comme ceci:
J'ai créé une macro locale avec l'ID de cet hôte. Trouver l'ID de l'hôte est très facile à partir de l'interface Web.
Une réponse avec une liste de toutes les macros sur un hôte donné peut être filtrée par un modèle :
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Ainsi, nous obtenons l'ID de la macro dont nous avons besoin, où MIKROTIK_VERSION est le nom de la macro que nous recherchons. Dans mon cas, la macro est recherchée MIKROTIK_VERSIONLe qui a été attribué à l'hôte.
La requête elle-même ressemble à ceci :
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.get",
"params":{
"output":"extend",
"hostids":"{$HOST_ID}"
},
"auth":"{sid}",
"id":1
}
Variable {côté} obtenu dans la deuxième étape et sera utilisé en permanence, où vous devez travailler avec l'interface API.
Final 4 STEP - mise à jour de la macro
Nous connaissons maintenant l'ID de macro qui doit être mis à jour, le cookie d'autorisation ou la version du micrologiciel du routeur. Vous pouvez mettre à jour la macro elle-même.
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.update",
"params":{
"hostmacroid":"{hostmacroid}",
"value":"{mikrotik_version}"
},
"auth":"{sid}",
"id":1
}
{version_mikrotik} est la valeur obtenue à la première étape. Dans mon exemple, la version du firmware mikrotik actuel
{hôtemacroid} - la valeur a été obtenue à la troisième étape - l'identifiant de la macro que nous mettons à jour.
résultats
L'approche pour résoudre le problème avec les fonctionnalités standard est beaucoup plus compliquée et plus longue. Surtout si vous connaissez la programmation et pouvez rapidement ajouter la logique nécessaire dans le script.
L'avantage évident de cette approche est la "portabilité" de la solution entre différents serveurs.
Pour moi personnellement, il est étrange que l'agent HTTP ne puisse pas accéder aux données d'un autre élément et les remplacer dans le corps ou les en-têtes de la requête [ ].
Le modèle fini peut .
Source: habr.com