Et check_mk ? Personne en parle. Visuellement, ça semble aussi complet que d’autres, et très rapide, et visuellement relativement cohérent. Et compatible Nagios.
> Le 7 juin 2017 à 16:59, Joël DEREFINKO <joel.derefi...@118218.fr> a écrit : > > Bonjour, > > Je vais rajouter ma pierre à l'édifice (tiens, j'ai quasiment vu mon parcours > dans celui de Wallace, même les dates collaient !). > > Avant de commencer je m'étonne de certaines solutions proposées, en > particulier de monter un stack ELK, Grafana et consors. > Si sur le papier ces solutions sont tout à fait pertinentes, je pense > (peut-être à tort) que c'est "hors de portée" pour un stagiaire qui doit > monter une supervision pour la première fois, d'autant plus sur une petite > infra (d'après le post original). > D'autant que j'imagine que ledit stagiaire doit aussi apprendre/découvrir > SNMP + les notions de client/serveur (remote execution de scripts), etc... Si > on ajoute là-dessus ELK, pas certain que les 6 mois de stage suffisent... ;) > > Tout ceci n'est évidemment que mon strict point de vue est n'est absolument > pas un appel à troll. > > La question qui m'est venue en lisant le premier post, c'est : "quel est > l'objectif ?". > > Si c'est pour avoir des statistiques d'utilisation (= des graphes), je te > conseille de jeter un œil à Cacti et à Munin (dont étrangement personne n'a > parlé, mais qui est orienté système et non équipements réseau). Munin est > extrêmement rapide et facile à mettre en place, et permettra d'avoir une > première idée de ce que tu peux collecter comme données. > L'inconvénient de Munin, c'est que c'est globalement préconfiguré et que ça > remonte tout un tas de métriques sans que tu n'aies besoin de rien faire, > donc pour apprendre quelque chose c'est pas forcément adapté. Et comme dit > précédemment, c'est orienté serveur, pas équipements réseau. > > Si c'est pour de la supervision (donc monitoring + alertes), commencer par > Nagios me semble pas mal, ça te permettra d'appréhender les concepts du > monitoring/alerting et le fait que la configuration passe par des fichiers > devraient t'aider dans ce sens, même si au début ça peut paraitre un peu > fouillis. > Inconvénient de Nagios, de base il ne fait que le monitoring, pas de collecte > de statistiques. Tu peux jeter un œil aux plugins (Cacti plugin for Nagios, > de tête, qui comme son nom l'indique "insère" des graphes cacti dans les > pages de statut de Nagios. > > Sinon, tu as les solutions tout-intégré comme déjà citées (Centreon, Shinken, > etc...). > Aujourd'hui nous fonctionnons avec Centreon qui a un côté usine à gaz qui a > tendance à me rebuter, mais ayant pratiqué Nagios-a-la-mimine par le passé > j'ai rapidement retrouvé mes petits. > S'il est vrai que Centreon avait tendance à consommer beaucoup en DB, ça à > l'air de s'être amélioré car je ne rencontre pas vraiment ce problème (mais > peut-être pas la même échelle d'infra à superviser). > > Bon courage ! > > Joël > > -----Message d'origine----- > De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de > Stéphane Kanschine > Envoyé : mercredi 7 juin 2017 15:50 > À : frnog-t...@frnog.org > Objet : Re: [FRnOG] [TECH] Supervision réseau > > > Hey ! > > Le mer. 7 juin, vers 11:13, Nathan delhaye exprimait : >> >> Si tu veux un truc all-in-one, Shinken est a mon sens bien plus clean que >> l'usine à gaz Centreon. > > Ne pas oublier sensu, qui a un côté monitoring framework sympa. De > base, c'est comme un nagios*, zabbix. Mais pour l'avoir consommé des > messages queue de métrique, tu peux lui injecter à peu près tout ce > que tu veux, chaîner les handler pour faire de la corrélation, > utiliser les aggrégats pour des trucs plus poussés. C'est très souple > en peu de modifications. > > Numériquement, > Stéphane > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
