Script dans le Low-Level-Discovery - Sans zabbix_agent ni SNMP

[sycoweb]

Bonjour,
je me permets de cross-poster ici, en Français, car sur "ZABBIX Help", c'est silence complet ...

bon ... y aurait-il vraiment quelqu'un qui utilise Zabbix de façon plus poussée qu'avec son Zabbix_agent, ou SNMP ?
Pour utiliser des scripts dans les découvertes (et LLD), la doc est tout simplement inexistante, et inutilisable car incompréhensible.

Quelqu'un a-t-il une expérience dans l'utilisation de scripts retournant des listes de valeurs ?

Merci d'avance.
Syco

[tiramiseb]

Salut,

J'utilise pas mal les LLD, j'ai créé nos propres découvertes selon nos besoins.

J'ai fait cela en m'appuyant exclusivement sur la doc officielle, que j'ai trouvée parfaitement claire.

Que ne comprends-tu pas ?

[sycoweb]

Salut,

J'utilise pas mal les LLD, j'ai créé nos propres découvertes selon nos besoins.

J'ai fait cela en m'appuyant exclusivement sur la doc officielle, que j'ai trouvée parfaitement claire.

Que ne comprends-tu pas ?

Bonjour Tiramiseb, et merci d'essayer de m'aider.
J'ai personnellement réussi uniquement à utiliser des scripts ne renvoyant qu'une seule valeur.

Je pensais faire de la découverte par script renvoyant des listes de valeurs, en une fois, et utiliser ces valeurs de façon similaire à SNMP (discovery[...], {#SNMPINDEX}, #{SNMPVALEUR], ...)

Dans la doc j'ai seulement compris que le script devait renvoyer les données au format JSON (pas de problème), mais je ne vois pas comment récupérer et utiliser les résultats.
NB : je comprends peut-être mal le fonctionnemement car je suis en pleine découverte de Zabbix.

Merci.
Syco

[tiramiseb]

Les "sources" de LLD doivent retourner une donnée JSON formatée de la manière suivant :

{
  "data": [
    {
      "{#NOM_DE_MACRO_1}": "valeur_1_pour_element_1",
      "{#NOM_DE_MACRO_2}": "valeur_2_pour_element_1"
    },
    {
      "{#NOM_DE_MACRO_1}": "valeur_1_pour_element_2",
      "{#NOM_DE_MACRO_2}": "valeur_2_pour_element_2"
    }
  ]
}

... où tu remplaces NOM_DE_MACRO_1 et NOM_DE_MACRO_2 par les noms de macros (ou de variables, si tu préfères) adaptées à ton cas.
... et où tu remplaces bien sûr valeur_1_pour_element_1, valeur_2_pour_element_1, valeur_1_pour_element_2 et valeur_2_pour_element_2 par les valeurs correspondantes.

Tu peux bien sûr mettre plus de 2 macros différentes dans un même élément et il peut y avoir autant d'éléments que tu veux dans la liste.

Par contre, le nom "data" doit rester comme ça.

Par exemple, j'ai fait un script qui liste les fichiers récursivement dans un répertoire et qui retourne par exemple :

{
  "data": [
    {
      "{#NAME}": "toto",
      "{#PATH}": "/mon/repertoire/toto"
    },
    {
      "{#NAME}": "titi",
      "{#PATH}": "/mon/repertoire/titi"
    },
    {
      "{#NAME}": "tata",
      "{#PATH}": "/mon/repertoire/sousrepertoire/tata"
    }
  ]
}

À partir du moment où tu as quelque chose qui retourne des données sous ce format, tu l'utilises comme clé d'une nouvelle règle de découverte, puis dans la règle de découverte tu crées des prototypes d'éléments, des prototypes de déclencheurs, etc, qui utilisent les noms de macros (variables) remontées par ton script sous ce format.



Par exemple, avec ma liste de fichiers ci-dessus...

- je mets le script qui remonte ça sur un pc supervisé
- je mets un UserParameter dans la conf de l'agent zabbix pour exécuter cette commande
- j'utilise la clé de ce userparameter comme règle de découverte
- je mets des prototypes d'éléments qui utilisent ça, ce qui pourrait faire par exemple :
- Nom : Somme MD5 de {#NAME}
- Type : Agent Zabbix
- Clé : vfs.file.md5sum[{#PATH}]


... mais tu peux faire ça avec n'importe quel type d'item, pas seulement avec les agent zabbix...

[sycoweb]

Les "sources" de LLD doivent retourner une donnée JSON formatée de la manière suivant :
...
... où tu remplaces NOM_DE_MACRO_1 et NOM_DE_MACRO_2 par les noms de macros (ou de variables, si tu préfères) adaptées à ton cas.
... et où tu remplaces bien sûr valeur_1_pour_element_1, valeur_2_pour_element_1, valeur_1_pour_element_2 et valeur_2_pour_element_2 par les valeurs correspondantes.
...
Par exemple, j'ai fait un script qui liste les fichiers récursivement dans un répertoire et qui retourne par exemple :

{
  "data": [
    {
      "{#NAME}": "toto",
      "{#PATH}": "/mon/repertoire/toto"
    },
    {
      "{#NAME}": "titi",
      "{#PATH}": "/mon/repertoire/titi"
    },
    {
      "{#NAME}": "tata",
      "{#PATH}": "/mon/repertoire/sousrepertoire/tata"
    }
  ]
}

...
... mais tu peux faire ça avec n'importe quel type d'item, pas seulement avec les agent zabbix...

J'appliquais effectivement tout ce que tu décris ici, avec le bon format et tout (comme je le décrivais sur mon threads dans "Zabbix Help" : https://www.zabbix.com/forum/showthread.php?t=57056 )

Mais je relève LE détail important que tu mentionnes :
"- je mets un UserParameter dans la conf de l'agent zabbix pour exécuter cette commande"

... et ça, je n'en ai pas eu le détail, je n'avais vu ça nulle part.
Ce doit être ça qui me manque, et sur quoi la doc LLD ne porte pas forcément l'attention.

////// Ligne INUTILE, j'ai localisé dans la doc ! : Tu peux m'expliquer ce 'UserParameter', ou me dire où on peut le *comprendre* ? //////

Je vais essayer de comprendre seul ,merci beaucoup.

Ce qui m'a sûrement égaré, c'est qu'on parle d'un "Agent" dans ce cadre ! Donc ça ne concernait pas à priori les scripts locaux ! ? :|

Ca m'inquiète d'ailleurs un peu : ça veut dire que c'est exécuté par Zabbix_agentd ? Et qu'il faut donc que ce Zabbix_agentd tourne forcément en local ?



Syco

[tiramiseb]

Ca m'inquiète d'ailleurs un peu : ça veut dire que c'est exécuté par Zabbix_agentd ? Et qu'il faut donc que ce Zabbix_agentd tourne forcément en local ?

Bah non, car comme je l'ai mis à la fin de mon message que tu as cité :

... mais tu peux faire ça avec n'importe quel type d'item, pas seulement avec les agent zabbix...

Il te faut juste un item, quel que soit son type, qui retourne des données sous cette forme.


-----

PS : pas besoin de citer tout mon message, je sais ce que j'ai écrit : tu peux simplement répondre sans citer

[sycoweb]

OK, plus de QUOTE inutiles (c'était pour les autres lecteurs, sans reprendre le fil )

"... mais tu peux faire ça avec n'importe quel type d'item, pas seulement avec les agent zabbix..."

Bien compris, grace à toi; car la doc laisse douter quand on arrive juste dans le produit

Par contre, au chapitre "User Parameters" de la doc, le tuto dit :
(https://www.zabbix.com/documentation...xtending_agent)
...... "Type of the item must be either Zabbix Agent or Zabbix Agent (active)."

Or, j'aurais tendance à utiliser "External Check"
Je comprends encore mal ?

[tiramiseb]

Les "user parameters", c'est une manière d'ajouter des clés à un agent zabbix, pour que l'agent exécute des commandes que tu veux. Donc c'est normal que ce chapitre parle des agents Je t'en ai parlé car je t'ai donné un exemple complet, c'est tout.

Si tu veux exécuter une commande sur le serveur Zabbix pour cette LLD, alors en effet les "external checks" c'est la possibilité la plus logique.

Si nécessaire tu peux faire un trapper (auquel cas c'est le script qui utilise la commande zabbix_sender pour remonter les infos dans zabbix) mais personnellement je préfère toujours que ce soit zabbix lui-même qui déclenche le script...

[sycoweb]

Ca s'éclaircit un peu,
Effectivement mes scripts tournent sur le serveur zabbix local.

donc ce que j'ai compris :
- j'utilise le type "Vérification Externe" car j'utilise un script perso.
- on ajoute un 'UserParameter', qui sert de point d'entrée pour ce qu'on décrit dans les Items, dans la conf de l'Agent Zabbix : zabbix_agent.conf
- [Et là j'ai peut être pas tout pigé] ... c'est zabbix_agentd qui traite ? (Puisque c'est sa conf qui est visée par UserParameter="

... ou bien on doit configurer l'équivalent dans la conf de zabbix_server ?

[tiramiseb]

- j'utilise le type "Vérification Externe" car j'utilise un script perso.

Oui, si j'ai bien compris ta situation...

- on ajoute un 'UserParameter'

Euh non.
Je répète encore une fois : Les userparameters c'est pour ajouter des clés de supervision à un agent zabbix. Si tu n'as pas d'agent, tu n'utilises pas de userparameter.



À mon avis, si tu disais ce que tu veux faire plus précisément je pourrais mieux t'aider, plutôt que de naviguer à vue...

[sycoweb]

Je veux faire ce que je dis au début :
Je pensais faire de la découverte par script renvoyant des listes de valeurs, en une fois, et utiliser ces valeurs de façon similaire à SNMP (discovery[...], {#SNMPINDEX}, #{SNMPVALEUR], ...)

Comme récupérer d'une fois la taille de Plusieurs databases (ou autres), et établir des graphes automatiquement, par un LLD, avec les Prototypes qui vont bien.
Exactement comme c'est fait pour les graphes des interfaces de routeurs avec SNMP.

Ou d'autres utilisations basées sur des tables variables où ne peut se baser que sur des index/valeurs.

[tiramiseb]

Houla mais c'est pas de la LLD qu'il faut !


La LLD, c'est pour générer une liste de machins, et à partir de cette liste, créer un ou plusieurs items pour chacun de ces machins. Et ensuite, les items créés vont chercher les infos, chacun dans son coin.



On ne peut pas remonter plusieurs éléments en même temps avec une seule interrogation à partir de Zabbix. Dans Zabbix, 1 item = 1 interrogation.

Si tu veux absolument remonter plusieurs données en une seule action, je ne vois que deux possibilités :

- soit tu crées des items de type trapper (un pour chaque donnée que tu veux remonter) puis tu lances un script qui remonte les infos en exécutant zabbix_sender autant de fois qu'il le faut, et ce script s'exécute par exemple dans un crontab
- soit tu fais un item "classique" pour chaque donnée à remonter et tu lances à chaque fois un script qui, lui, garde les données en cache pendant un certain temps (histoire de ne pas interroger une base de données trop souvent par exemple) [moi je choisis cette approche quand c'est nécessaire]


Tout ce que peut faire la LLD, c'est générer automatiquement les éléments (par exemple, ça peut détecter la liste des bases de données et mettre en place les items pour chacune des bases de données), mais PAS remonter des valeurs dans les éléments.

Comme le dit son nom, c'est de la découverte, low-level discovery, pas de la remontée d'info.

[sycoweb]

Houla mais c'est pas de la LLD qu'il faut !

Ah, bon, dommage.
Mais en SNMP c'est la solution que j'ai adopté :
- 4750 routeurs à superviser
- répartis sur 16 modèles de routeurs différents selon la morphologie matérielle
- une seule découverte par modèle, décrite sur chaque Template, avec prototypes d'Items et de Graphes qui vont bien, et un filtre sur les Nom d'interfaces à retenir
... et ça marche, tous les graphes se font; indépendemment des changements matériels (ajouts de cartes ou ordre des interfaces, ...)

Je m'attendais à une possibilité similaire avec un script de collecte (au lieu des SNMPWalk).
Peut être avec un peu de maturité de Zabbix ...
Je vais réviser ma stratégie. Dommage.
Merci.
Syco.

[tiramiseb]

Mais en SNMP c'est la solution que j'ai adopté [...]

Oui, tu décris parfaitement le fonctionnement de la LLD : la requête de découverte remonte la liste des éléments à superviser, ensuite Zabbix crée les éléments qu'il faut et ensuite Zabbix fait une requête supplémentaire pour chaque élément à superviser.

Ce n'est pas la requête de découverte qui remplit les données des éléments.

-----

Mais ce que tu appelles « un script de collecte » n'est pas du tout ce fonctionnement-là. Avec ton « script de collecte », tu remontes les informations que tu veux voir apparaître dans les différents items. Ce n'est pas ce qu'il se passe avec ce que tu as fait en SNMP.

Tu peux tout à fait faire un script de découverte (ce que j'ai écrit plus haut), les choses se peupleront en effet de manière dynamique et ça créera des items qui, eux, vont faire des requêtes indépendantes (une requête pour chaque item) pour remonter les informations.

Comme pour le SNMP que tu as décrit, ce n'est pas la requête de découverte qui remplira le contenu des items.

[ Et il ne s'agit pas du tout de maturité de Zabbix (qui, rappelons-le, a plus de 15 ans et est utilisé dans des sociétés avec des milliers d'équipements supervisés...), c'est inhérent au fonctionnement même de Zabbix ]



... cela étant dit, je trouve moi aussi dommage de ne pas pouvoir faire remonter nativement des infos dans plusieurs items en une seule requête : j'ai certains items qui interrogent les mêmes choses (en l'occurrence des sockets UNIX) pour obtenir des informations différentes ; les performances seraient meilleures s'il y avait une seule interrogation. Cela peut passer, comme je l'ai décrit, par un script/programme qui met en cache les réponses afin de ne pas refaire des requêtes lourdes plusieurs fois inutilement.

[sycoweb]

D'accord, incompréhension de ma part sur la façon de faire de Zabbix.
Il y a donc une issue possible
Mais alors, comparé à la façon de faire avec SNMP Discovery, etc ..., quelle serait la formulation (la "syntaxe" à utiliser dans la partie 'Key' notamment) pour exploiter ces possibilités ?
Car je crois vraiment que c'est là que je ne comprends pas tout.

NB : pour la maturité de Zabbix, ma remarque n'est pas du tout négative. J'ai juste plus de 25 ans de réseaux ,et plus de 10 ans de NAGIOS/NAGVIS/CACTI/CENTREON/VIGILO derrière moi : donc supervisions essentiellement Réseaux/SNMP/sans agents. J'ai juste eu un regard de total néophyte sur Zabbix, vu uniquement avec mon vécu sur le reste.
Je le trouve plein d'intérêt, et il attise ma curiosité. Au premier abord, on sent bien d'où il vient et ça laisse espérer un peu de mieux côté supervision des réseaux.
Je ne souhaite froisser personne, et ne demande qu'à être adepte convaincu de Zabbix.

Merci.
Syco.