Voici la suite de l’article présentant les hypothèses de notre comparatif ainsi qu’un bref descriptif de chacun des outils comparés. Je vais maintenant établir une matrice contenant les éléments principaux de décision, selon mon expérience, afin de comparer les outils proposés et d’évaluer la réponse qu’ils apportent sur chacun de ces critères. Pour rappel, les candidats sont des outils opensource gratuits : Zabbix, Centreon, Nagios, Cacti et Munin.
Fromage ou Dessert ?
Métrologie ou Supervision ? C’est la grande question. Il faut bien évidemment que les 2 composants du monitoring soient présents pour assurer le bien-être de votre infrastructure. Cependant, il n’est pas toujours évident de savoir dans quel domaine l’outil assure le service ou bien si il assure les 2. Le schéma ci-dessous indique à quel(s) groupe(s) appartiennent les outils étudiés.
Supervision ou/et Métrologie ?
La Matrice… Enfin ! :o)
La réponse n’est pas 42, rassurez-vous. Vous trouverez-ci dessous les éléments de décision qui permettront de choisir tel ou tel outil pour votre infrastructure.
Matrice – Outils Monitoring
Les + / –
Si je devais retenir un point positif et un axe d’amélioration pour chaque outil qui me feraient pencher pour son utilisation ou non en production, ce seraient ceux là :
Munin
+ : Sa configuration très simple sous forme de fichiers de configuration et de liens symboliques, en font un candidat idéal pour un gestionnaire de configuration centralisé comme Puppet et pour de l’automatisation.
– : L’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante rend son utilisation très difficile pour de la production.
Nagios
+ : Sa configuration sous forme de fichiers, qui peut être assez vite repoussante, en fait cependant un candidat idéal à la « pupettisation » et à l’automatisation. Au delà de cela, c’est, on peut le dire, un outil complet qui a fait ses preuves.
– : L’IHM… Il ne faut pas négliger cet aspect, car une information mise en forme « avec goût » aide aussi à sa compréhension et son interprétation. La forme est importante au delà de la pertinence de l’information.
Cacti
+ : Un outil de métrologie complet avec pas mal de fonctionnalités (Thold, Weathermap, …) apportées au travers de sa Plugin Architecture. La variété et les possibilités de ses tempates complexes sont aussi un atout non négligeable.
– : La création de ses templates peut s’avérer un peu complexe au premier abord avec les différentes couches (Data Queries, Data Input Method, Data Templates, Graph Templates, Host Templates, …). Un autre point quelque peu embêtant est le manque d’homogénéité dans la configuration de ses templates (casse-tête pour l’automatisation).
Centreon
+ : Une IHM agréable et intuitive. Les notions proposées permettent une prise en main intuitive et les templates (hosts, services, commandes, …) sont pratiques et simples à mettre en place.
– : Les graphiques se contentent de tracer les données de performance remontées par Nagios sans offrir la possibilité de les mettre en relation et de les travailler afin d’obtenir des graphes orientés « logiciel/métier » comme des graphes résumant l’utilisation d’un Apache ou d’un MySQL (par exemple).
Zabbix
+ : Un outil complet autant au niveau de la métrologie que de la supervision qui se suffit à lui-même pour monitorer de manière exhaustive une infrastructure. Les fonctionnalités très avancées permettent de gérer pratiquement tous les cas.
– : Un manque de lisibilité de certains écrans (comme celui des déclencheurs par exemple) et de leurs enchaînements et des notions qui manquent parfois de prise en main intuitive. L’interface Web fait également un peu « vieillote ».
Conclusion
Il n’y a pas de mauvaise solution, certaines seront simplement plus adaptées à ce que vous voulez en faire. Voici quelques possibilités afin d’obtenir un monitoring complet de votre infrastructure :
- Si vous voulez privilégier l’automatisation et la gestion centralisée des configurations de votre infrastructure (Cf. Puppet), pensez Munin-Nagios (vous aurez alors accès dans ce cas à 2 IHMs Web pour monitorer votre infrastructure), the « Double tap », the « Buddy system » du monitoring ! :o) Pas besoin d’accéder à des APIs plus ou moins avancées (comme pour leur camarades) pour ajouter/supprimer un host et associer les services à monitorer, tout est sous forme de fichiers de configuration et de symlinks. A noter que Munin n’exploitera pas les données de performances de Nagios mais celles de ses propres sondes et que la grosse lacune de Munin est l’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante qui rend son utilisation très difficile pour de la production.
- Si vous privilégiez une métrologie avancée donnant accès à des possibilités de supervision, pensez Cacti avec sa Plugin Architecture (assortie avec Thold par exemple). Prenez un peu de temps pour comprendre les notions utilisées pour créer les templates de graphes et créez vos propres graphes complexes ! Vous pourrez ensuite utilisez leurs métriques et la connaissance que vous aurez acquis dessus pour lever des alertes via Thold.
- Si vous privilégiez une supervision complète avec des possibilités de métrologie simple, Centreon est fait pour vous ! Surcouche de Nagios proposant un générateur de configuration, l’exploitation des données de performances de Nagios via RRDTool, du reporting agréable sur le statut de votre infrastructure, la possibilité de gérer une architecture distribuée de Nagios via son daemon CentCore qui se connecte sur les Nagios remote en SSH, … Centreon propose un pilotage de Nagios via une interface Web agréable et intuitive et une gestion de templates de hosts, services, commandes, … très pratique.
- Si vous êtes sans concessions, Zabbix vous offre une interface unifiée vous proposant aussi bien de superviser votre infrastructure avec des notions très avancées (mesures, déclencheurs, actions conditionnelles complexes, escalade, scénarii HTTP, …) que de travailler la partie métrologie avec la possibilité de créer des graphes complexes avec les mesures récupérées. A noter qu’au delà de l’aspect séduisant du « No Compromis », la prise en main est moins intuitive qu’un Centreon, par exemple, avec une IHM moins agréable et proposant parfois des enchaînements d’écrans un peu confus à mon sens.
Comme précisé dans la première partie de cet article, il est important de noter que je n’ai pas bien sûr pu tester les dernières versions de chaque outil, puisqu’il s’agit de retours d’expérience (sur plus de 2 ans) sur des environnements de production et qu’on n’en met pas un en place toutes les semaines ! ;ob Je suis donc ouvert à vos remarques sur les évolutions que vous aurez constatées sur vos outils favoris ou bien sur les éléments de décision que vous mettriez en plus dans la balance pour effectuer votre choix.
Tech Blog 
Pingback: Accueil » Zabbix, Centreon, Nagios, Cacti ou Munin ?
Salut Frederic,
Je ne comprends pas bien en quoi, dans ton tableau comparatif, l’utilisation des RRDtool est discriminant?
De plus dans les + Nagios tu mets que la configuration est repoussante 😛 tres positif 🙂
J’aimeJ’aime
Salut !
L’utilisation de RRD peut être un facteur de décision car il s’agit d’un standard. Il a un certain nombre de fonctionnalités appréciables comme le fait que les RRAs (Round Robin Archives) sont des fichiers de taille fixe et prédictible (les anciennes données sont éliminées par consolidation – réduction de la résolution des données sur le temps). De plus, il est possible via les commandes rrd d’exploiter les données (génération d’images, …) même en dehors de l’outil de monitoring en connaissant « simplement » la syntaxe de ce standard de l’exploitation des données de métrologie (oui… Les arguments des commandes rrd, genre rrdgraph, demandent un peu d’entrainement ;ob).
On peut préférer ce moyen à un stockage en base de données qu’il faut surveiller en termes de volumétrie (et optimiser dans certains cas). Il s’agit d’une indication, mineure il est vrai, mais qu’il est intéressant de connaitre.
Concernant Nagios, il faut prendre la phrase dans son ensemble :
Je pense que l’aspect « un peu repoussant » qui peut apparaître sur des infrastructures conséquentes est compensé par les possibilités d’automatisation.
Frédéric FAURE
J’aimeJ’aime
Pingback: Tweets that mention Decrypt » Comparatif outils de monitoring (métrologie et supervision) (2/2) : Zabbix, Centreon, Nagios, Cacti et Munin -- Topsy.com
Je pense que vous devriez regarder Osmius. http://osmius.com
Je suis sûr que vous aimerez
J’aimeJ’aime
On utilisait munin pendant un temps, et la métrologie, c’est bien, mais pour une analyse à posteriori d’un souci quelconque, une résolution de 5 minutes est beaucoup trop élevée, pareil pour les check nagios, trop long entre deux exécutions.
Avec collectd ( http://collectd.org/ ), on a donc une résolution de 10 secondes par défaut, sans soucis de performances, chaque noeud exécutant un service de collection de mtériques et les envoyant à un serveur.
Les plus: open source, installation très simple, utilisation des RRD, multiple plugins, écriture simple de nouvelles commandes pour envoyer de nouvelles métriques, …
Les moins: interface minimale
J’aimeJ’aime
Merci pour les 2 liens.
Je vais regarder les outils !
Frédéric FAURE
J’aimeJ’aime
la version de nagios citée est celle de nagios core pas la XI je présume et encore moins combinée a Fusion car plusieurs point dont le monitoring distribué par exemple serait acquis pour la solution nagios
J’aimeJ’aime
C’est exact !
J’ai utilisé la version Core de Nagios (celle qui, d’ailleurs, est utilisée par Centreon). Je souhaitais comparer des outils opensource gratuits dans cet article.
Il existe effectivement des versions évoluées (et payantes ;ob), en l’occurrence Nagios XI, avec la possibilité d’avoir un dashboard permettant d’agréger un monitoring distribué avec Nagios Fusion, comme vous le précisez.
Je n’ai pas eu l’occasion de les tester. Avez-vous déjà utilisé ces 2 outils ? Et si oui, qu’en avez-vous pensé ?
J’aimeJ’aime
Bonjour Frédéric,
Concernant RRD tu mentionnes : « On peut préférer ce moyen à un stockage en base de données qu’il faut surveiller en termes de volumétrie (et optimiser dans certains cas). »
C’est ce que je pensais moi aussi, mais avec un collègue nous avons découvert que sur zabbix, il y a un mécanisme « housekeeper ». Du coup, la base de données est purgée fréquemment. On peut même choisir la fréquence de purge. Pour notre part, on a choisi de garder en base que les données datant des 6 derniers mois. Et comme option, on a choisi une purge une fois par heure. Cela fait quelques semaines qu’on a mis ce procédé en place sur zabbix et cela fonctionne à merveille !
Voilà pour le retour d’expérience sur zabbix. Pour info, cela fait 3 ans et demi que je travaille avec zabbix et j’en suis très satisfaite 🙂
Fatiha
J’aimeJ’aime
Les tests sont en cours pour nagios XI (nous avions basé nos dev sur nagios core )
Pour fusion je suis en recherche d’informations car nous avons élaboré depuis quelques temps déjà une architecture multiniveaux permettant d’agréger les infos de monitoring et par la même occasion d’attaquer des réseaux de grande taille et on se pose la question de l’apport de Nagios Fusion !!!
je reviens vers vous dès que j’ai une évaluation précise de nagios XI / Fusion
J’aimeJ’aime
@Fatiha
Merci pour l’info !
Il y a effectivement un « housekeeper » activé par défaut dans Zabbix et positionné à une fréquence de 1 heure.
Concernant la volumétrie, il y également la présence de données orphelines qu’il est possible de purger soi-même (directement dans la base Zabbix). Ces données ne sont pas « toujours » correctement supprimées lors de la suppression d’un host. Cela conduit à une volumétrie non négligeable, surtout au démarrage d’un projet quand on crée, puis supprime pas mal d’instances. Il est intéressant de s’occuper de ces données de temps en temps. :o)
Sinon pour la partie optimisation, je pensais plus en termes de performances quand on commence à avoir pas mal de serveurs à monitorer (>100). Outre augmenter la puissance CPU du serveur hébergeant Zabbix (et vérifier qu’on ne récolte que des métriques pertinents pour limiter les écritures ;ob), il y a un peu de travail de tuning au niveau de la base de données. Personnellement, j’utilise MySQL plutôt que PostgreSQL (simplement parce que je connais mieux MySQL ;ob) et il est intéressant de changer le moteur de base de données par défaut MyISAM => InnoDB pour optimiser les performances en écriture (row locking). Il est ensuite possible de passer sur d’autres moteurs à partir de là, comme Percona, un moteur compatible InnoDB (un de mes collègues, Laurent ROUX, pourra vous en dire plus sur le sujet et l’intérêt de ce moteur).
Une fois passé en InnoDB, vous devrez paramétrer un certain nombres d’éléments (innodb_buffer_pool_size, innodb_flush_method, … ). C’est préférable car le paramétrage par défaut est rarement le bon pour sa propre utilisation ! :o)
Tout ça pour dire que RRDTool demande un peu moins de réflexion lors de la mise en place. Cela étant dit, ce n’est pas plus performant pour autant. Je n’ai pas fait de bench entre les différents outils monitoring en forte charge ! ;ob
Mais ceci est un détail et effectivement Zabbix est un très bon outil, complet et qui m’a aussi satisfait. :o)
Frédéric FAURE
J’aimeJ’aime
@Anouar Rachdi
Merci ! Je suis très intéressé par votre retour !
Frédéric FAURE
J’aimeJ’aime
Bonjour merci pour cet article, cela m’a bien aidé pour rédiger un comparatif
Desolé si ce n’est pas le bon endroit, mais ca fait presque une semaine que je cherche une solution a un petit souci concernant le module NDO, pour une installation de centreon
J’en ai vraiment besoin d’aide, si quelqu’un peut m’aider, je serais en attente pour vous fournir les informations que vous voulez
Merci d’avance
Et merci pour l’article
J’aimeJ’aime
Bonjour,
Je suis content que cela vous ait aidé ! :o)
Désolé pour le délai de réponse, mais je suis quelque peu pris en ce moment. Si vous avez toujours un souci avec NDO, vous pouvez décrire votre problème ici (en précisant la version du produit, installation depuis le package d’un repository ou custom, OS, …) et j’essaierai d’y répondre.
Cordialement,
Frédéric FAURE
J’aimeJ’aime
Bonjour,
merci pour ce dossier. Je suis en train de faire un comparatif de solutions de monitoring et il m’est très utile. Est-ce que vous pourriez me dire également pour les différentes solutions présentées s’il y a possibilité de monitorer des scripts personnels (i.e. faire exécuter des scripts shell/ perl /… sur les systèmes monitorés pour tester, par exemple, une application personnelle, en récupérer la valeur de retour et éventuellement le temps d’exécution pour présenter les résultats dans l’IHM)?
Merci d’avance, et encore une fois super dossier.
J’aimeJ’aime
Bien entendu !
Chaque outil se base sur des plugins qui sont en réalité des scripts (shell, php, perl, …) qui sont :
o soit stockés sur le serveur lui-même et exécutés en local pour une interrogation de la cible à distance (via le réseau),
o soit stockés sur chacune des cibles du serveur de monitoring et appelés par un agent situé lui-aussi sur les cibles et qui sert de relais pour le serveur.
Vous pouvez donc développer vos plugins (scripts) vous-même et les ajouter avec les autres, puis les configurer dans le serveur pour qu’il les appelle. C’est prévu pour ! :o)
Vos scripts peuvent récupérer n’importe quel type d’informations. Le tout c’est qu’ils doivent les mettre en forme pour renvoyer des couples de « clés-valeurs » qui seront stockés par le serveur (via RRDtool ou bien directement en base « SQL » dans le cas de Zabbix) puis restitués sous forme de graphiques.
J’aimeJ’aime
Bonjour,
j’utilise depuis de nombreuses années Cacti pour surveiller différentes « appliance sécurité » (Firewalls, Proxies, DNS, relais SMTP, etc) fournies pas les leaders du marché.
Il n’est absolument pas possible avec ce type d’équipements d’utiliser autre chose que les agents SNMP installés dessus et l’aspect très modulaire de Cacti permet de faire face rapidement à de nouvelles valeurs à surveiller, des MIBs qui changent, etc.
Régulièrement je regarde les autres produits que Cacti, comme Nagios, mais je n’arrive pas à comprendre comment je pourrais avec Nagios récupérer toutes les valeurs en SNMP (états CPU, Mémoire, interfaces réseaux, VRRP, status des clusters, nombre de paquets droppés, nombre de requetes diverses, etc) sans passer des années à écrire des scripts et encore des scripts et maintenir des montagnes de lignes de code.
Concernant Cacti, le seul reproche que j’aurai à faire est le plugin d’alerting « thold » qui n’est pas très développé (par exemple le manque de notion d’escalade).
Avez-vous rencontré des architectures où on ne supervise pas des serveurs mais des équipements « appliance » ? Quelles solutions opensource parmi celles que vous avez cité sont utilisées ?
J’aimeJ’aime
Bonjour !
Effectivement concernant les appliances, on est obligé d’utiliser les trap SNMP qui nous sont remontées. Je n’ai pas eu à les utiliser dans les infrastructures que j’ai mises en place, mais j’ai regardé leur fonctionnement, au niveau de Centreon en tout cas, et tout est prévu pour le faire simplement, comme on peut le faire dans Cacti (et même un peu plus simplement je trouve). Il y a même un certain nombre d’équipements/MIBs prédéfinis, ce qui est commode pour s’en servir comme modèle si votre équipement n’est pas dans la liste. Je suppose donc que cela doit être prévu également dans Nagios (de manière intégrée), puisque Centreon génère la configuration pour son moteur Nagios sous-jacent.
Cependant je ne me suis pas penché en détail sur le sujet donc il y a peut-être une difficulté « cachée ».
Concernant Cacti, il s’agit plutôt d’un outil orienté métrologie qui offre via sa « plugin architecture » des capacités de supervision : « Thold » montre effectivement ses limites et il m’a été aussi difficile de l’utiliser seul pour de la supervision comme avec l’exemple des escalades que vous donnez.
Quand on parle de monitoring d’appliances, la connotation est plutôt orientée supervision et les outils qui prévoient/intègrent (aisément) ce genre de chose sont plutôt, à mon avis, Nagios, Centreon et Zabbix. Vous pouvez regarder l’interface de Centreon dédiée aux équipements pour vous donner une idée si cela correspond à vos attentes et générer la configuration pour voir le résultat dans les fichiers de configuration du Nagios sous-jacent.
J’aimeJ’aime
Bonjour, je suis en stage pfe et je devrai faire une étude comparative entre les outils open source libres (Nagios,xymon,cacti,zabbix,centreon,PRTG,MRTG)afin de choisir un parmi eux.
j’ai lu votre article et j’ai pas vraiment bien compris les éléments de décision qui vous ont permis de choisir tel ou tel outil.
Prière de bien vouloir les expliquer et Merci !
J’aimeJ’aime
Bonjour,
La plupart de ces points sont présentés dans la première partie de l’article qui décrit les outils et leur fonctionnement : Comparatif outils de monitoring (métrologie et supervision) (1/2) : Zabbix, Centreon, Nagios, Cacti et Munin. Si vous avez encore une interrogation sur un élément en particulier dites-le moi.
Cordialement,
Frédéric FAURE
J’aimeJ’aime
Félicitation pour cet excellent article.
Juste un retour d’expérience de plus de 10 ans sur ZABBIX. (Number of hosts 216 Number of items 6992 Number of triggers 3422)
IL s’agit d’un produit fabuleux, toujours en recherche d’amélioration, simple d’utilisation, rapide et conviviale.
Le seul point faible est la supervision réseau (Pas de map de topologie réseau automatique) et pas de rafraichissement dynamique des maps.
Mais dans une version future (1.8.11 actuellement), j’espère que cette fonctionnalité sera ajouté.
Cordialement
Bertrand ROY
J’aimeJ’aime
Bonjour,
Voici quelques années que ton message a été posté, et il me semble toujours presque d’actualité.
Les outils ont évolué, c’est sûr… Je pense notamment à Zabbix (celui que je connais le mieux), qui offre une possibilité simple de supervision distribuée (proxies Zabbix… mais ça n’existait pas déjà quand tu as écrit cet article ?) ; je trouve également l’éventuelle intégration à un système automatique de type Puppet assez simple, que ce soit par l’API (qui a évolué dernièrement) ou par l’importation de fichiers…
En tout cas j’aime beaucoup ton diagramme de Venn !
Il explique très simplement ce que parfois on met beaucoup de temps à expliquer aux gens qui hésitent…
J’aimeJ’aime
Bonjour à tous,
A mon tour, un grand Merci pour cette article fort intéressant et très bien amené !
Sébastien indique que l’article semble toujours d’actualité, qu’en pensez-vous ? Les solutions ont-elles beaucoup évoluées et si oui sur quoi ?
Quelqu’un a t-il déjà réfléchie à la solution la plus adaptée pour un monitoring sur du Iaas à haute volumétrie (Openstack) ? Mes premières recherches me poussent vers une solution Shinken + Centreon (performance + gestion des dépendances de shinken cumulé avec le multi-vue et reporting exploitable de centreon). Je vais jeter un oeil à Nagios v4 qui, selon leur propre diagramme à bâton mis en ligne sans explications, à très nettement amélioré ses performances.
L’intégration d’outil de gestion de conf devient à mon sens quasi obligatoire pour gérer l’aspect dynamique du Cloud. A-t-elle évolué depuis 2 ans ?
Merci d’avance pour vos avis/idées…
J’aimeJ’aime
Bonjour !
Je suis content de voir que cet article intéresse toujours, même si il commence à dater un peu ! :o)
Je pense que l’article est toujours d’actualité effectivement, car les solutions présentées n’ont pas changé radicalement de façon de faire, même si je ne doute pas que de nombreuses features ont été ajoutées ! :o)
Déjà je pense qu’il serait intéressant de se baser sur Ceilometer que ce soit en utilisant l’API end-user (polling par Centreon) ou bien en créant un publisher qui permette de récupérer directement les informations sur un pipe pour un stockage/exploitation dans un format ad hoc si cela est nécessaire. Vous pouvez regarder Ceilometer – System Architecture si vous voulez plus d’informations sur le sujet.
Ensuite ce qui a changé depuis quelques temps c’est le nombre de solutions de « Monitoring as a Service » pour les infrastructures IaaS comme par exemple SATELLIZ. Je ne connais pas en particulier celle-là (je l’ai testée très rapidement), mais j’en vois beaucoup qui émergent. Ca peut être une piste.
Sinon si les volumes sont vraiment gros, vous pouvez utiliser du MapReduce pour vous créer un système de stockage/agrégation sur le temps (similaire aux RRAs de RRDTool) à la Netflix (ils utilisent EMR d’AWS) et développer dessus votre couche de rendu dans des dashboards custom. Après il faut avoir les moyens d’investir « un peu » de temps, mais cela peut se faire.
Sinon je n’ai pas eu l’occasion de tester de nouveaux outils de supervision/métrologie depuis cet article : j’essaie déjà de faire avec ceux que je connais. ;ob
En ce moment je regarde 2 choses :
– La virtualisation par containers LXC via Docker, mais cela me sert plus pour mettre en place de l’intégration continue.
– Sinon Juju d’Ubuntu me semble être une évolution intéressante car le produit introduit la notion d’ordonnancement autour de ses recettes (Charms) qui peuvent être « rédigées » en Chef, shell, … et Puppet je crois également. Je n’ai pas encore pu avancé autant que je le voulais sur ce produit, mais il me semble intéressant dans votre cas vu l’intégration forte entre Ubuntu et Openstack.
Cordialement,
Frédéric FAURE
J’aimeJ’aime
Salut,
Sympa ton article Frédéric. La première partie est claire et permet de se faire de bonnes armes pour comprendre les caractéristiques de chacun des outils à comparer. Tu ne te contentes pas de dire « c’est celui la le mieux ». 🙂
Pour information, j’ai finalement choisi d’installer Munin (c’est le nom nordique qui m’a séduit ^^) et on peut maintenant zoomer sur les graphiques. Cela nécessite de configurer fastcgi sur son serveur (je peux envoyer ma configuration Lighttpd si quelqu’un en a besoin).
Bonne journée à tous. 😉
J’aimeJ’aime
Bonjour !
« c’est le nom nordique qui m’a séduit ^^ »
Et bien c’est du beau ! Tout un comparatif pour ça ! ;o)
« on peut maintenant zoomer sur les graphiques »
Merci de l’information, ça manquait vraiment à l’époque.
« je peux envoyer ma configuration Lighttpd si quelqu’un en a besoin »
Volontiers ! Tu peux la mettre dans les commentaires si tu le souhaites.
Bonne journée également.
J’aimeJ’aime
Reuh,
Du voici ce que j’ai fait pour activer les CGI Munin sur un Lighttpd. Les CGI sont nécessaires si vous souhaitez que les pages et les graphiques soient générés à la demande (et dans cas, il faut changer graph_strategy et html_strategy dans votre /etc/munin/munin.conf) et/ou si vous souhaitez que le zoom soit fonctionnel (sinon c’est pas compliqué, à la place de l’image, vous aurez un carré, un triangle et un disque, tous dans un carré, au moins c’est sobre). Ceci dit, j’ai personnellement choisi de rester sur une génération via cron des graphes et des pages et cela ne pose pas de problème (et dans ce cas, l’intérêt de connecter le programme CGI /munin-cgi/munin-cgi-html se limite au débug).
Dans /etc/lighttpd/lighttpd.conf, j’ai juste rajouté un include :
# This is a minimal example config
# See /usr/share/doc/lighttpd
# and http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions
server.port = 80
server.username = "http"
server.groupname = "http"
server.document-root = "/srv/http"
server.errorlog = "/var/log/lighttpd/error.log"
dir-listing.activate = "enable"
index-file.names = ( "index.html" )
mimetype.assign = (
".html" => "text/html",
".txt" => "text/plain",
".css" => "text/css",
".js" => "application/x-javascript",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".gif" => "image/gif",
".png" => "image/png",
"" => "application/octet-stream"
)
include "conf.d/fastcgi.conf"
Et c’est dans /etc/lighttpd/conf.d/fastcgi.conf que les choses se passent :
server.modules += ( "mod_fastcgi" )
$HTTP["url"] =~ "^/munin-cgi/" {
fastcgi.server = (
"/munin-cgi/munin-cgi-graph" =>
((
"bin-path" => "/usr/share/munin/cgi/munin-cgi-graph",
# "bin-environment" => (
# "CGI_DEBUG" => "yes"
# ),
"socket" => "/run/lighttpd/munin-cgi-graph.sock",
"check-local" => "disable",
)),
"/munin-cgi/munin-cgi-html" =>
((
"bin-path" => "/usr/share/munin/cgi/munin-cgi-html",
"socket" => "/run/lighttpd/munin-cgi-html.sock",
"check-local" => "disable",
))
)
}
Pour résumer, il y a deux programmes CGI à connecter: munin-cgi-html et munin-cgi-graph. Le check-local disable est nécessaire car les adresses /munin-cgi/munin-cgi-{html,graph} ne correspondent à aucun fichier [local] sur le serveur web (d’ailleurs, j’ai un répertoire /munin/ mais pas /munin-cgi/, ce dernier n’est pas nécessaire).
Si ça ne marche pas et que vous n’avez aucun journal, vérifiez les droits. En effet, Munin est probablement lancé avec l’utilisateur munin et Lighttpd avec httpd. Dans mon cas, httpd n’avait par défaut pas le droit d’écrire dans les logs de munin et j’ai dû jouer un peu avec les groupes. Il y avait aussi un répertoire temporaire auquel j’ai dû donner les droits d’écritures à httpd: /var/lib/munin/cgi-tmp/.
Je pense que c’est tout.
@+
J’aimeJ’aime
*Du coup
Oups.
J’aurais mieux fait de relire le texte que j’avais écrit et pas uniquement la config.
Désolé pour l’indentation, je n’ai pas dû utiliser la bonne balise.
J’ai mis les fichiers complets à cette adresse :
-> http://ransake.clivia-bleu.eu/2014-11-27/
Bonne soirée !
(Et ne codez pas trop !)
J’aimeJ’aime
Pingback: Monitoring de serveurs auto-hébergés avec Munin | Mossroy
Pingback: Comparatif outils de monitoring (métrologie et supervision) (1/2) : Zabbix, Centreon, Nagios, Cacti et Munin | Tech Blog