Créer un "check interne" pour opentsdb

[othyus]

Bonjour à tous,
nous souhaiterions utiliser Zabbix pour monitorer différents services et notamment via opentsdb.

J'ai vu qu'il était possible via un "external check" d'appeler un script qui fait le taf. Seulement voilà, d'après la documentation (https://www.zabbix.com/documentation...rnal&s[]=check) l'utilisation de "checks externes" a pour effet de faire baisser les performances de Zabbix.

J'aurai voulu savoir s'il était possible de créer un nouveau "check interne" pour ne pas voir les performances empathir.

Merci d'avance pour vos retours

[EDIT] Afin d'utiliser les termes de Zabbix, il s'agit de définir un nouveau type d'item

[tiramiseb]

Salut,

Bien sûr, un check "externe" peut être négatif en terme de performances vu qu'il faut alors appeler un autre programme, script ou autre... C'est pour ça qu'il faut utiliser ça avec parcimonie, mais quand il n'y a pas le choix on le fait.

Cela dit, il me semble que ce n'est pas cela qu'il te faut. Un "external check", c'est l'exécution par le serveur d'un script (ou autre) sur lui-même. Tu veux probablement plutôt que la vérification en question se passe sur un autre serveur, qui a un agent Zabbix installé.
Dans ce cas, ce qu'il faut définir c'est un UserParameter, côté agent. Au niveau des performances, l'impact sera sur l'agent et non sur le serveur : un agent qui exécute un script une fois toutes les 30 secondes (par exemple), ça ne va pas faire s'écrouler les performances du serveur supervisé... Et si vraiment ton check a besoin de faire des calculs complexes, tu peux l'implémenter dans un langage rapide (En C par exemple).

[othyus]

Merci pour ta réponse,

mon problème c'est qu'on n'est pas sur 1 check/30 secondes, mais plutôt plusieurs milliers de checks à exécuter toutes les minutes.
Si un process est créé à chaque check, cela va poser un gros problème puisque les checks vont passer en attente de libération de process.

Ce n'est pas tant que les calculs sont complexes, mais qu'il faut aller chercher les données et que cela prend quelques secondes.

C'est pour cela que ce que je cherche à faire, ce n'est pas d'appeler un script, mais bien de développer un "check" qui sera intégré directement dans Zabbix.

[safpsr]

Salut,

Bien sûr, un check "externe" peut être négatif en terme de performances vu qu'il faut alors appeler un autre programme, script ou autre... C'est pour ça qu'il faut utiliser ça avec parcimonie, mais quand il n'y a pas le choix on le fait.

Cela dit, il me semble que ce n'est pas cela qu'il te faut. Un "external check", c'est l'exécution par le serveur d'un script (ou autre) sur lui-même. Tu veux probablement plutôt que la vérification en question se passe sur un autre serveur, qui a un agent Zabbix installé.
Dans ce cas, ce qu'il faut définir c'est un UserParameter, côté agent. Au niveau des performances, l'impact sera sur l'agent et non sur le serveur : un agent qui exécute un script une fois toutes les 30 secondes (par exemple), ça ne va pas faire s'écrouler les performances du serveur supervisé... Et si vraiment ton check a besoin de faire des calculs complexes, tu peux l'implémenter dans un langage rapide (En C par exemple).

C'est la bonne solution. On peut aussi utiliser la clé d'item "system.run[/opt/...]"

[tiramiseb]

Attention aux risques de sécurité si on autorise "system.run"...

[safpsr]

J'ai réglé le problème avec sudo: system.run[sudo /usr/bin/du -sb ...

[tiramiseb]

Non, je ne parle pas de ça. Rien à voir.

En autorisant system.run, tu autorises ton serveur zabbix à exécuter n'importe quelle commande sur ton client zabbix. Les flux Zabbix ne sont pas (encore) chiffrés ni authentifiés, donc n'importe qui sur le réseau peut se faire passer pour ton serveur zabbix et faire exécuter des commandes sur ton agent.

C'est une faille importante qui fait que de mon côté je n'autorise pas l'exécution distante de commandes.

[safpsr]

C'est vrai.

Mais là, la solution est de faire fonctionner l'agent Zabbix avec un user Zabbix aux droits limités et d'utiliser sudo pour toutes les commandes ou droits d'accès particuliers.

Du coup, le seul truc qui peut être hacké est un user aux droits limités. Sachant que le user Zabbix ne peut pas faire de su -

[tiramiseb]

Sauf que c'est loin d'être suffisant car l'utilisateur a tout de même plein de droits, il peut voir plein de choses sur la machine. Permettre à n'importe qui de facilement rentrer dans une machine, même si ce n'est pas en tant que root, ce n'est pas acceptable dans un environnement sérieux.
D'autant plus qu'il peut très bien y avoir quelque chose de mal configuré ou une faille non corrigée qui permet de gagner des privilèges...

Non, autoriser l'exécution distante d'une commande n'est pas sécurisé.

Dans ma société, même si le flux était sécurisé on ne l'autoriserait pas.

[tiramiseb]

mon problème c'est qu'on n'est pas sur 1 check/30 secondes, mais plutôt plusieurs milliers de checks à exécuter toutes les minutes.

Plusieurs milliers toutes les minutes sur une même machine ? vraiment !?
Un millier par minute, ça ferait 16 par seconde... alors "plusieurs"......

Si un process est créé à chaque check, cela va poser un gros problème

Dans ce cas, oui, c'est une évidence. Mais c'est à mon avis le nombre de checks qui poserait un problème.
N'y a-t-il pas un problème dans ton approche ?


Peux-tu préciser le contexte histoire qu'on puisse bien comprendre ?

C'est pour cela que ce que je cherche à faire [c'est] de développer un "check" qui sera intégré directement dans Zabbix.

Autre possibilité, plus facile à gérer que de forker l'agent Zabbix, ce serait de créer un autre démon qui effectue les requêtes nécessaires en conservant une connexion active à ta base et qui stockerait au fur et à mesure les données récupérées... la récupération par Zabbix serait alors une simple connexion sur cet autre démon.

[othyus]

Il s'agit de déployer Zabbix dans l'entreprise pour laquelle je travaille.

Notre parc informatique représente plus de 32000 serveurs

Nous avons commencé à déployer des Tcollector sur ces serveurs qui collectent alors plusieurs dizaines de métriques sur chaque serveur.
En plus de cela, nous comptons également surveiller nos services (nombreux également).

Même en déployant plusieurs agents Zabbix, il est nécessaire que chaque agent puisse faire tourner beaucoup de surveillances sans avoir de perte de performances.

La récupération de données se fait en REST sur opentsdb.

J'ai vu la possibilité d'utiliser des trappeurs, mais je ne trouve pas ça satisfaisant de devoir passer par un process externe pour effectuer les surveillances.

Voila pour les infos

[tiramiseb]

Donc on parle bien de plusieurs milliers de checks sur toute l'infra, pas sur un seul agent.

Je reviens donc sur ma réponse en #2 pour la confirmer : tu implémentes votre vérification côté agent sur chacun des serveurs, tu auras donc une très légère charge supplémentaire sur chaque serveur.


Imaginons que tu fais ce check toutes les 30 secondes comme je l'ai évoqué : côté agent, sur chaque machine, ça correspond bien à l'exécution de la commande en question une fois toutes les 30 secondes. La charge sur chacune des machines reste donc largement acceptable et il n'y a pour le moment aucune surcharge côté serveur.


Enfin, pour remonter les infos, côté serveur tu définis juste un item supplémentaire sur les machines (enfin, sur le template commun : tu ne vas pas créer 32000 items à la main). Que l'agent exécute une grosse commande de 10 secondes ou que ce soit un check rapide de 10ms, cela ne change rien côté serveur : il reçoit une valeur, c'est tout.

Côté serveur, la réflexion est donc uniquement une question de dimensionnement par rapport au nombre de métriques remontées par seconde, indépendamment de la façon dont ces métriques sont récupérées (vu que la charge de la récupération des données, tu la répartis sur tes 32000 serveurs).

Imaginons que sur chacune des machines tu aies 50 métriques, 50 items, et que chacun de ces items est remonté toutes les 30 secondes, cela signifie 32000×50×2/60 = 53333 items par seconde. C'est bien sûr énorme et, pour un parc comme ça, je te conseillerais de te rapprocher de Zabbix SIA pour avoir du conseil professionnel sur les gros parcs.
Ce que je peux te dire, c'est qu'il y a des parcs de plusieurs centaines de milliers de machines supervisés par Zabbix (Alexei Vladishev lui-même m'en a parlé lorsque je l'ai rencontré il y a 5 ans) et que ça marche bien. Il faut juste correctement dimensionner les machines, définir intelligemment les métriques, peut-être ajouter des proxies, etc...

L'un des aspects peut être la méthode de communication : les checks actifs demandent moins de performances au serveur que les checks passifs.

Autre aspect, je reviens sur les 50 métriques : si au lieu de les remonter chacune "bêtement" toutes les 30 secondes, tu les remontais à une fréquence moyenne moindre, les perfs nécessaires côté serveur seraient moindres également. Imaginons que tu aies 40 métriques que tu peux remonter une fois toutes les 5 minutes et 10 métriques à remonter toutes les 30 secondes, ça descend le besoin à 32000×(40/5+10×2)/60 = 14933 items par seconde.

Il faut aussi voir le dimensionnement de la base de données, utiliser un serveur solide qui sait gérer de très grosses bases, etc.

Enfin voilà, quand on est sur des gros parcs comme ça il y a plein d'aspects à affiner, là où un petit parc de quelques dizaines ou centaines de machines peut se contenter de la config par défaut.

Quoi qu'il en soit et pour revenir à ta question de base, si tu implémentes tes vérifications côté agent sur chacun des agents de chacun de tes serveurs, la "surcharge" sera distribuée et ne posera pas de problème.

[tiramiseb]

J'ajouterais que, concernant la charge de chacun des agents, il n'y a pas lieu de s'inquiéter.

Par exemple, un agent qui remonterait 100 checks "système" (donc implémentés en interne dans l'agent Zabbix) n'a pas d'impact visible sur les perfs du système. L'impact en terme de perfs serait uniquement celui généré par ta procédure de check complémentaire.

Et que ton check soit implémenté dans l'agent ou qu'il soit implémenté à part, cela ne change pas grand chose. Dans l'agent c'est obligatoirement en C et tu peux le programmer en C de manière externe aussi. La seule différence entre les deux serait alors un fork à chaque fois que l'agent appelle ton check : l'impact d'un fork toutes les 30 secondes est quasi-nul.

[othyus]

Merci pour tes réponses,

je vais regarder pour utiliser des trappers avec un process de remontée dans Zabbix.
Merci encore pour toutes ces infos

[tiramiseb]

!?

Je te conseille de faire des userparameters dans des agents.
Je ne parle pas des trappers parce que je suis comme toi opposé à des choses qui tournent en parallèle.
Alors pourquoi te tourner vers les trappers ?