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

Recherche :

Dernière réponse

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

exeral

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

:)

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

exeral

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

:)

snipereyes

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.

black_lord

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.

tetsuo44

@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

Sly Angel

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 ?

gizmo15

okay merci :jap:

black_lord

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

black_lord

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

gizmo15

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?

black_lord

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

gizmo15

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

black_lord

Sly Angel

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: