J'ai besoin de remplacer munin par quelque chose de plus évolutif [fermé]

J'ai utilisé munin sur plusieurs serveurs pendant de nombreuses années avec beaucoup de succès, mais avec plus de 100 nœuds munin et lorsqu'il y a une charge sur les clients, le traitement arrive à expiration.

J'ai apporté des changements d'échelle au travail cron, au nombre de processus clients et réduit le nombre de plugins en cours d'exécution, etc. mais j'ai décidé de chercher une alternative qui a une architecture plus évolutive.

Toutes suggestions ou expériences seraient les bienvenues. Je suis essentiellement intéressé par les métriques du serveur qui peuvent être utilisées pour la planification de la capacité et le diagnostic de l'utilisation des ressources. (nous avons des nagios pour alerter)

Il semble que vous ayez deux problèmes

1. Sur votre serveur de surveillance, l'enregistrement des métriques pour de nombreux serveurs nécessite plus d'E / S aléatoires que votre stockage ne peut en fournir. Même si toutes vos métriques sont écrites sur le disque, le serveur peut être trop surchargé pour générer réellement des graphiques à partir de celles-ci.
2. Sur vos clients surveillés, les plugins qui collectent les métriques sont trop gourmands en CPU et en mémoire et ne finissent pas de collecter les données à temps lorsque les clients subissent une charge importante.

J'ai utilisé Munin dans le passé, mais j'utilise actuellement collectd . Les auteurs de collectd ont investi beaucoup de réflexion et d'efforts pour résoudre ces problèmes. Ils ont un système bien conçu pour écrire les données dans des fichiers RRD qui vous assure de ne pas perdre de données et de générer des graphiques à jour. Il existe également un support pour RRDCacheD. Le démon et les plugins officiels sont écrits en C, donc ils utilisent peu de mémoire ou de temps CPU. Sur mes systèmes clients, il utilise moins de 2 Mo de RAM et environ un quart de seconde de temps processeur par minute. Sur mon serveur de surveillance, il utilise 20 Mo de RAM et les deux tiers d'une seconde de temps processeur chaque minute. Gardez à l'esprit que toutes mes mesures sont collectées et envoyées à mon serveur de surveillance toutes les dix secondes, plutôt qu'à des intervalles de minutes comme munin.

Bien qu'ils soient d'excellents outils, Munin et d'autres frontaux RRDTool (tels que Cacti ou Ganglia) ont connu des problèmes d'E / S et sont difficiles à mettre à l'échelle lorsque vous surveillez des centaines de nœuds.

Il existe cependant quelques techniques pour gérer ce goulot d'étranglement d'E / S. L'une de ces techniques consiste à répartir les écritures sur un grand nombre de disques pour réduire les E / S sur chaque disque. D'un autre côté, de nombreux administrateurs système utilisent des systèmes de fichiers tmpfs pour résoudre ce problème. RRDCached est également une option récente et efficace pour résoudre ce problème et je vous recommande de jeter un œil à ces diapositives .

Je ne connais pas très bien Munin, mais Cacti a un plugin Boost . Ce plugin met en cache les données en mémoire et effectue des mises à jour de masse et à la demande sur le disque, au lieu d'écritures individuelles, réduisant ainsi les E / S. Je suis presque sûr que Munin a aussi quelque chose comme ça.

Si vous pouvez vous le permettre, les disques SSD sont également de bonnes options.

Enfin, vous pouvez également consulter Reconnoiter . Recconoiter est un tout nouvel outil de détection de défauts et de représentation graphique / tendance. Contrairement à la plupart des outils de tendances, Reconnoiter n'est pas basé sur RRDTool et essaie de résoudre ce problème spécifique. Je n'utilise pas Reconnoiter en production, mais j'ai fait quelques tests, et bien qu'il soit encore un peu "vert", il semble vraiment prometteur, notamment en ce qui concerne son évolutivité.

J'espère que cela t'aides!

Découvrez Zabbix . C'est l'un des meilleurs outils de surveillance des performances Open Source. Il évolue bien et a été utilisé dans des environnements avec des milliers d'ordinateurs.

Marco Ramos donne de bons conseils. Je tiens à ajouter quelques précisions, cependant: le gros problème avec munin est son horaire de collecte fixe de 5 minutes. Si tous les nœuds ne renvoient pas de résultats dans la fenêtre de 5 minutes, vous commencez à obtenir des abandons. C'est le plus gros problème avec munin.

D'autres outils basés sur rrdtool comme Ganglia ne sont pas verrouillés dans cette même fenêtre de mise à jour de 5 minutes car ils n'interrogent pas toutes les sources de données de la même manière séquentielle que Munin.

Je vous recommande de regarder Ganglia car il semble généralement bien évoluer (bien que vous ayez besoin de désactiver la collecte de données de multidiffusion pour une grande installation de ganglia). Je soupçonne que vous pouvez faire beaucoup de chemin avec les ganglions avant de devoir vous inquiéter du fait que rrdtool soit le point d'étranglement. À ce stade, vous pouvez faire le genre de choses que Marco suggère, comme utiliser des disques SSD.

Je remplace Munin w / Ganglia, Munin tue mon serveur donc je vais essayer Ganglia et voir comment il évolue.