Forum Linux.général Supervision: je ne sais lequel choisir

Posté par  . Licence CC By‑SA.
Étiquettes :
1
26
fév.
2013

Bonjour les gens,
alors voilà je vais commencer un projet de supervision et un choix s'offre à moi: Nagios ou Shinken?
Si je connais bien le premier (du moins son moteur et la façon dont il marche) je n'ai pas encore testé le second qui jouit d'une réputation de Nagios-Killer tant il semble performant.
Mon infrastructure se composera d'environ 600 hôtes et 6000 services et on peut compter sur une augmentation d'environ 20%/an de ces indicateurs.
J'aurais bien aimé avoir des retours d'experience sur shinken.
De plus, j'ai toujours installé du Nagios "brut", c'est à dire sans front end (juste couplé avec pnp4nagios pour avoir des graphes) et juste l'interface web de "base" car toujours dans des environnements plutôt restreints et toujours avec un public d'admins systèmes.
Là je vais avoir besoin d'ACL pour une gestion plus fine des vues donc l'interface web de base ne suffira plus.
J'ai jamais été tenté par Centreon, d'ailleurs quel est l’intérêt d'avoir la configuration en base?Quid de la performance comparé au fichiers plats?

Merci.

  • # zabbix !

    Posté par  . Évalué à 3.

    j'aime bien

  • # retour shinken

    Posté par  . Évalué à 2.

    Je suis en train de mettre en place shinken sur mon modeste réseau (on parle d'une ou deux dizaine de serveurs), pour le moment ça tourne bien.

    Si certains ont des retours d'utilisation à plus grande échelle et sur assez longtemps, je suis preneur aussi…

  • # Perf Nagios/Centreon et Shinken

    Posté par  (site web personnel) . Évalué à 3.

    On fait tourner du Nagios/Centreon avec 50k services et 50 utilisateurs simultanés, tu as de la marge donc ;-)

    J'ai testé Shinken sur un environnement avec 24k services, j'ai eu pas mal de problèmes de perf (conso mémoire et temps de redémarrage). C'était il y a 10 mois donc les choses ont du évoluer depuis mais je ne suis pas super enthousiaste quand même.

    • [^] # Re: Perf Nagios/Centreon et Shinken

      Posté par  . Évalué à 1.

      Merci de ton retour paulez.
      Est ce que la charge était réparti sur un seul serveur (j'en doute)?
      Dans le cas contraire quels moyens as tu mis en place pour la repartition? (conf réparti sur plusieurs Nagios et un serveur central qui a vu sur les toutes les alertes, round robin DNS, cluster…)

      • [^] # Re: Perf Nagios/Centreon et Shinken

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 février 2013 à 08:31.

        Il y a besoin d'une architecture distribuée pour Nagios avec 50 000 indicateurs !?
        Ça me semble naturel pour toi…

        Je ne suis plus trop au fait des performances de Nagios… En tout cas avec Zabbix, un serveur d'entrée de gamme actuel (4 coeurs, 8 Go de RAM) permet de superviser jusqu'à 1000 hôtes, pour 300 000 indicateurs (si les indicateurs sont remontés toutes les 5 minutes).

        (pas pour rien que je dis partout que Zabbix est plus performant :) )

        Un test a été fait avec un Raspberry Pi, ce matériel est capable de superviser 100 à 200 hôtes avec Zabbix sans aucun problème.

      • [^] # Re: Perf Nagios/Centreon et Shinken

        Posté par  (site web personnel) . Évalué à 2.

        C'est une architecture distribuée à base de NDOMOD (archi distribuée standard Centreon).

        Elle est distribuée d'abord pour des besoins de localisation (plusieurs datacenters) et aussi de performance (nous montons jusqu'à 25K services sur un serveur Nagios physique, on doit pouvoir faire plus mais il faut mettre un peu les mains dans le cambouis).

        Un autre type d'architecture distribuée peut être d'avoir un seul serveur Nagios, et rajouter avec mod_gearman des "workers" autant que nécessaire.

        Tu peux aussi découper la conf sur plusieurs serveurs et tous les visualiser avec une interface qui le supporte comme Thruk.

        Et Nagios 4 qui devrait arriver un jour supportera nativement le principe de workers (comme avec Shinken ou mod_gearman).

        Tu as donc de multiples possibilités, il ne te reste plus qu'à choisir ;-)

    • [^] # Re: Perf Nagios/Centreon et Shinken

      Posté par  (site web personnel) . Évalué à 1.

      De combien de RAM dans les faits? D'après ce que j'ai vu sur de gros environnements, un simple serveur milieu de gamme absorbe sans aucun soucis 120K checks en 5min. Il est clair qu'il va consommer plus que Nagios (bien qu'en général la vraie consommation vienne des sondes, pas des ordonnanceurs), par contre ses capacités en terme de corrélation sont bien plus étendues. Comme d'habitude ça va donc dépendre de ses besoins :)

      En ce qui concerne les temps de démarrage, tu as comparé avec un nagios + les temps qu'il faut au module NDO pour se charger dans les faits? :)

      Si tu veux de l'aide pour optimiser un Shinken n'hésites pas à me demander, comme pour Nagios il y a pas mal de leviers actionnables et de bonnes pratiques :)

      • [^] # Re: Perf Nagios/Centreon et Shinken

        Posté par  (site web personnel) . Évalué à 1.

        2 x 8 Gio. Ce qui prenait le plus de place était le scheduler et les brokers (livestatus et webui).

        Le temps de redémarrage était de plus de cinq minutes, avec une indisponibilité totale de la supervision pendant ce laps de temps.

        Avec Nagios ça prend bien moins de temps, surtout que dans un archi distribuée je peux redémarrer uniquement le serveur qui le nécessite, et ça va donc beaucoup plus vite, et sans interférer sur le reste.

        Pour info j'ai environ une minute de temps de redémarrage sur un server Nagios avec 30k services, et moins de 10s pour un serveur avec environ 5k services, donc c'est tout de même beaucoup mieux.

  • # En complément

    Posté par  (site web personnel) . Évalué à 2.

    Bonjour,

    en complément, tu peux ajouter Hobbit, moche mais très performant.

    Bonne journée
    G

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.