Créer un "check interne" pour opentsdb

[othyus]

Après avoir testé icinga2 et shinken, avec notre volumétrie on préfère se tourner vers une solution qui ne génère pas 1fork/check.

En passant par un process externe pour récupérer les données, je vais pouvoir traiter des paquets d'informations plutôt que des informations unitaires.

[tiramiseb]

Au final les informations seront de toute manière unitaires : les items ne supportent rien d'autre. Par contre en effet si tu implémentes le protocole de Zabbix (donc que tu n'utilises pas zabbix_sender), ça peut faire gagner sur cette histoire de forks si tu remontes plusieurs infos du même serveur (si tu utilises zabbix_sender, alors tu feras de toute façon un fork à chaque fois).

Mais encore une fois, s'il s'agit de lancer un check toutes les X secondes sur chacun des serveurs, ce n'est à mon sens pas un fork qui va poser problème.

Si l'idée c'est que tu ne veux pas lancer plusieurs fois une même commande gourmande pour remonter des indicateurs différents, tu voudras peut-être te pencher sur runcached avant d'implémenter un truc complexe.

[othyus]

Je ne veux pas installer un agent zabbix sur chaque serveur, mais avoir un pool d'agent zabbix.

Donc quand tu dis :

Mais encore une fois, s'il s'agit de lancer un check toutes les X secondes sur chacun des serveurs, ce n'est à mon sens pas un fork qui va poser problème.

Il ne s'agit pas d'un check mais bien de plusieurs checks.

Je vais regarder runcached , ca peut me servir et commencer à bencher la solution avec les trappers, au moins pour avoir des statistiques de référence.

[tiramiseb]

Je ne veux pas installer un agent zabbix sur chaque serveur

Ce serait à mon sens l'approche la plus souple. Mais c'est toi qui décides