Monitoring : Nagios, Icinga, Shinken, mod_gearman, scalabilité...

Monitoring : Nagios, Icinga, Shinken, mod_gearman, scalabilité... - Linux et OS Alternatifs

Marsh Posté le 07-01-2015 à 12:15:28    

Hello,

 

Actuellement on tourne dans ma société sur du Nagios 4.x sur un serveur très musclé avec 2000+ hosts et 20000+ checks. Il y a un paquet de choses qui sont désagréables actuellement avec cette solution mais d'un autre côté on aimerait rester dans cette voix (communauté importante pour les plugins/checks, opensource, non payant).

 

Les choses chiantes :
- Scalabilité
- Lenteur
- Lenteur de l'interface et CGI ancestral
- Configuration d'un contact d'escalade au bout de X min de non retour du service
- Configuration des checks (templates par type de host, etc)
- Distribution des tâches
- fichier plat pour le statut des checks

 

Du coup je jette un oeil sur différentes choses qui tournent autour de Nagios actuellement :
- Icinga
- Shinken
- mod_gearman pour distribuer les checks (semble mieux que DMX)
- Thruk

 

Je me rends compte que beaucoup de forks ont été fait, qu'il y a une espèce de guerre sans fin entre plein de gens autour de l'évolution de Nagios, que gearman semble prévu pour Nagios 3 mais que Nagios 4 est plus performant, etc, etc.

 

Mes priorités :
- Distribuer les checks sur plusieurs machines sans devoir maintenir X confs différentes
- Rendre l'interface plus rapide et efficace
- Gérer la notion d'escalade (bon à la limite s'il est simple de récupérer les états des alertes on peut le générer par un script maison)
- Pouvoir rapidement déployer la conf d'un host sur un modèle/template par type de host (ça aussi éventuellement je pourrais le scripter)
- Pouvoir facilement avoir des vues en fonction de groupes (hardware, sites, etc)

 

Je me doute qu'un truc tout fait n'existe pas forcément, mais si vous avez de l'expérience sur ça, je suis preneur d'orientations et conseils pour pas trop perdre de temps sur des options qui n'iront pas et pour me concentrer sur le plus adapté/proche de mon besoin :)

 

Merci de votre aide :jap:


Message édité par Sly Angel le 07-01-2015 à 15:39:02

---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

Marsh Posté le 07-01-2015 à 12:15:28   

Reply

Marsh Posté le 07-01-2015 à 13:58:23    

plusieurs pistes :  
* check_mk pour distribuer le load
* thruk pour l'interface
* je passerai sur du naemon à ta place ( c'est =~ nagios4 mais licence différente, l'auteur de nagios etant un sombre c**)
* shinken :vomi:
* pour le routing des alertes and co : flapjack (cf https://speakerdeck.com/auxesis/fla [...] x-may-2014 par exemple) doit faire l'affaire.  
 
toute notre conf nagios est générée, via chef, on peut en causer en MP si tu veux :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-01-2015 à 14:04:16    

Petite question: pk cet avis sur shinken? me semble que grao l'utilise à une bonne échelle

Reply

Marsh Posté le 07-01-2015 à 14:11:47    

c'est pas une question d'échelle, mais de design et de conception


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-01-2015 à 14:29:56    

c'est pas ce que je voulais dire, mais tu n'as pas l'air de l'apprécier et je soulignais le fait qu'il soit utilisé à une bonne échelle, du coup qu'est-ce que tu lui repproche?

Reply

Marsh Posté le 07-01-2015 à 14:45:21    

son design et sa conception : moi un soft avec des paths hardcodés, qui utilise des features experimentales de python c'est non.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-01-2015 à 14:51:56    

https://laur.ie/blog/2014/02/why-il [...] very-much/ en passant


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-01-2015 à 15:20:02    

okay merci :jap:

Reply

Marsh Posté le 07-01-2015 à 18:59:32    

black_lord a écrit :

plusieurs pistes :  
* check_mk pour distribuer le load
* thruk pour l'interface
* je passerai sur du naemon à ta place ( c'est =~ nagios4 mais licence différente, l'auteur de nagios etant un sombre c**)
* shinken :vomi:
* pour le routing des alertes and co : flapjack (cf https://speakerdeck.com/auxesis/fla [...] x-may-2014 par exemple) doit faire l'affaire.  
 
toute notre conf nagios est générée, via chef, on peut en causer en MP si tu veux :o


Merci pour ce retour et cette piste intéressante :jap:
 
check_mk ? Naemon fait du distribué déjà non de ce que je vois ?


---------------
Fan et séquestrateur de Deprem De Prel Photographie, célèbre photographe de tuning automobile :o
Reply

Marsh Posté le 08-01-2015 à 08:52:58    

@blacklord,  
> feature expérimentale ? ou ça ?  
> problème de design et de conception ? peut tu expliquer ?  
 
Un argumentaire est nécessaire il me semble pour étayer vos propos non ?  
 
David
 

Reply

Marsh Posté le 08-01-2015 à 08:52:58   

Reply

Marsh Posté le 08-01-2015 à 09:56:52    

tetsuo44 a écrit :

@blacklord,  
> feature expérimentale ? ou ça ?  
> problème de design et de conception ? peut tu expliquer ?  
 
Un argumentaire est nécessaire il me semble pour étayer vos propos non ?  
 
David
 


 
1/ je ne les ai plus en tete, je me souviens des warnings dans les logs
2/ je vais pas y passer des heures mais des tonnes de paths hardcodés, des morceaux qui failent à se lancer sans logs etc... c'etait il y a ~2 ans et j'espère que ça c'est amélioré depuis.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 09-01-2015 à 18:30:22    

ol donc tu te bases sur un avis d'il y a deux ans sur un produit qui a l'époque venait tout juste de sortir de l'oeuf. Il serait peut être malin de se faire un avis sur une version récente de l'outil avant de le dénigrer.

 

"Moi j'ai eu une volvo y a 20 ans qui était pourri alors aujourd'hui volvo c'est fini" ce genre de raisonnement fermé est particulièrement agacant.

Reply

Marsh Posté le 14-01-2015 à 16:35:00    

ici on est sous shinken + thruk.
honnetement c'est pas moi qui ai mis en place le truc et ya quelques hosts dont j'ai aucune idée ce qu'ils foutent
je sais qu'on a 2 poller en VM (et tout en VM globalement)
 
on a fait une surcouche maison pour gérer, automatiser la conf (qui globalement ne fait qu'écrire desz fichiers de conf type nagios)
 
aucun soucis de perfs à constater
 


Monitoring Performance
Service Check Execution Time: 0.00 / 30.99 / 1.929 sec
Service Check Latency: 0.00 / 7.00 / 0.345 sec
Host Check Execution Time: 0.01 / 10.09 / 0.817 sec
Host Check Latency: 0.03 / 3.60 / 0.865 sec
# Active Host / Service Checks: 698 / 13495
# Passive Host / Service Checks: 0 / 0


ne pas me demander, je ne sais pas interpréter ces temps d'execution :o  
 
 :)  

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed