Quelqu'un utilise-t-il check_mk pour Nagios? Quelque chose que je devrais savoir avant d'envisager?


11

http://mathias-kettner.de/check_mk.html

Je l'ai testé sur quelques machines de développement et cela semble assez astucieux. Je ne trouve cependant pas beaucoup d'informations sur ses déploiements. Quelqu'un gère-t-il cela activement? Quelqu'un a-t-il écarté cela comme une option pour une raison quelconque?


Merci pour le lien! Je vais certainement essayer ça. Semble idéal pour les chèques locaux et un remplacement pour NRPE.
Wouter de Bie

Je ne l'ai pas utilisé, mais il fonctionne à l'OMI, il s'intègre dans ce paysage de devops flous. Dans chef / puppet, vous utiliseriez ohai / facter pour faire ce que cela ressemble à ce plugin mk, vous exporteriez une configuration nagios qui câblerait un statut ohai / facter. Cela semble peut-être moins détourné. Merci pour le lien, je vais certainement y jeter un œil!
dsummersl

Réponses:


3

Avertissement: J'ai l'habitude de travailler sur ce projet parce que je pensais qu'il était extrêmement puissant. (et je le pense toujours)

Je l'utilise depuis 2009ish et à l'exception des configurations héritées, je n'ai plus jamais touché à une configuration Nagios "normale" (on peut dire ancienne). Ce serait une perte de temps.

La plus grande configuration que je connaisse est d'environ 1 200 serveurs de surveillance. (pas: serveurs surveillés) Celui-ci est également publié, mais la question d'origine le précède.

Il est maintenant utilisé dans de nombreux endroits qui n'étaient pas satisfaits des nagios simples par opposition aux NMS à plus grande échelle comme OpenView et ont changé d'avis.

La principale différence n'est pas l'évolutivité (comme 37 signaux semblent très appréciés), ni la détection automatique des éléments contrôlables dans un système distant, ce qui en fait un nobrainer et vous alerte même si quelque chose de nouveau est ajouté mais n'est pas surveillé.

Non, la chose vraiment importante à long terme est la configuration, qui est strictement basée sur des règles (et écrite en python). Quelques 100 lignes de configuration Check_MK suffisent pour lui permettre de générer 200K lignes de l'ancienne syntaxe ennuyeuse de nagios que vous ne regarderez jamais en arrière.

  • Il dispose également d'un éditeur de configuration basé sur le Web. Avec héritage. Et la validation.
  • L'interface graphique est, entre autres, optimisée pour les liaisons WAN. Et c'est en fait un framework web complet, c'est pourquoi il existe également des tableaux de bord et un moteur de classification des journaux qui peuvent prendre en charge syslog ou snmp pour le traitement de Nagios avec des ensembles de règles flexibles.
  • Tous les chèques sont rédigés selon des normes de qualité élevées et cela montre un gain de temps pour l'utilisateur.

Mais il n'y a pas de poneys.

  • Les gens sont souvent confus à propos de l'interaction entre Check_MK et Nagios, qui n'est pas anodine mais en fait bien séparée: il écrit la configuration, Nagios s'exécute avec cette configuration et appelle Check_MK pour surveiller les systèmes.
  • Si quelqu'un n'utilise pas l'éditeur de configuration graphique "WATO", il est supposé être à un niveau expert dans Nagios.
  • Il n'y a pas de manuel d'OPS GUI! (mais: aide en ligne qui peut être activée à la volée)
  • Les correctifs de support IPv6 fonctionnant parfaitement flottent depuis des années et ne sont encore allés nulle part.

Il y a beaucoup plus d'avantages et d'inconvénients à aborder, mais je pense que j'ai déjà assez bien montré les deux côtés. Personnellement, j'aime l'efficacité des configurations Check_MK et je suis vraiment ennuyé si je dois travailler avec des configurations Nagios oldskool. Même s'ils utilisent de beaux cadres de modèles ou sont réquisitionnés auprès de Puppet, cela me semble toujours vieilli et impuissant par rapport à moi.

Avertissement: voir ci-dessus;)


1
À droite, j'ai aimé check_mk mais je n'ai pas pu l'utiliser en raison du manque de prise en charge d'IPv6. Je suis dans un environnement 100% dual stack.
Michael Hampton

mon idée originale est d'utiliser NAT64 sur la boîte de surveillance ou sa passerelle et de faire la surveillance à 100% via v6; le noyau icinga est très prêt pour la v6 par exemple. tant pis. bien assez tôt, seules les personnes v4 commenceront à voir les problèmes que leur relâche leur apporte :)
Florian Heigl

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.