Contrairement à bon nombre d'interfaces alternatives aux CGI originaux de Nagios, Thruk a été écrit pour les remplacer de manière isofonctionnelle avant de s'enrichir. Par isofonctionnelle, il faut comprendre que l'interface reprend pratiquement trait pour trait l'interface originale de Nagios. De plus, Thruk est écrit en Perl et utilise le framework Catalyst.
Cependant, de nombreuses et nouvelles fonctionnalités ont déjà fait leurs apparitions au fil de son développement :
- Plusieurs sources possibles (grâce au support de MKLiveStatus) ;
- Plusieurs moteurs possibles (Nagios, Icinga ou même Shinken) ;
- Indépendance vis-à-vis de Nagios Core : il est possible de l'installer sur un autre hôte ;
- Recherches étendues ;
- Export vers Excel (NdM : un export dédié au logiciel propriétaire Excel ou un export au format XLS ?);
- Interface pour mobile (iPhone, iPad et Android) ;
- Interface personnalisable via des thèmes (Nuvola, Exofolation, Vautour, etc.).
Depuis la version 0.70, toutes fonctions internes relatives à MKLiveStatus ont fait l'objet d'un module, ce qui prépare la possibilité d'avoir plusieurs sources, alternatives à MKLiveStatus.
Si Centreon, OP5 et autres Opsview vous paraissent avoir souffert d'un trop-plein de fonctionnalités, ou que vous souhaitez pouvoir améliorer l'interface de Nagios sans trop changer les habitudes de vos utilisateurs, alors, une chose est sûre, Thruk est certainement fait pour vous !
Aller plus loin
- Thruk (51 clics)
- Screenshots (33 clics)
- Blog de Sven Nierlein (17 clics)
- MKLiveStatus (21 clics)
# Interface de nagios
Posté par j_kerviel . Évalué à 3.
http://www.icinga.org/screenshots/
[^] # Re: Interface de nagios
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
# Thruk
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 7.
Mahchin ou Thruk, c'est du pareil au même, hein…
# Export vers Excel
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
# Et la base de données?
Posté par FantastIX . Évalué à 4.
Ce que je trouve malheureux, c'est que les données de métrologie sont par défaut enregistrées dans une base de données à jeton circulaire mais que, pour des besoins de reconstruction des graphiques, l'on ait adjoint une base de données MySQL. Toute la pertinence de RRDB est ainsi anéantie.
En résumé, ce qui m'intéresse c'est à quoi sert la base de données. Est-elle là pour stocker des informations (p.ex. de configuration) dont le volume reste stable au cours du temps? Ou bien est-elle aussi utilisée pour mémoriser les données de métrologie? Dans ce dernier cas, existe-t'il une fonctionnalité (facile d'accès, de préférence) pour purger les données obsolètes?
[^] # Re: Et la base de données?
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Mais en effet de toute manière l'utilisation d'une bdd dans ce cas là n'est pas si utile. Concernant Thruk c'est que justement il utilise le module LiveStatus qui est en fait un moyen pour le daemon Nagios d'écouter sur un port des requêtes (format spécial mais très simple d'utilisation) et de répondre. Point de bdd ici (en fait si, le daemon se transforme en bdd sans rétention finalement).
De plus en plus d'outils gravitant autour de Nagios font le choix de livestatus (plus de base MySQL à installer/gérer) lorsqu'il ne s'agit que de voir les infos en temps réels comme par exemple NagVis qui est un moyen d'avoir de jolies cartes agrégées et qui n'a clairement pas besoin de la rétention d'information sur le long terme.
Centreon n'a pas encore franchi le pas, et s'oriente plutôt pour l'instant vers un nouveau schéma de base bien plus léger et performant que le classique de Nagios (NDO) avec leur nouveau module d'export (CentreonBroker).
Bref ça bouge pas mal ces temps-ci dans le domaine, les idées fusent c'est cool :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.