Nagios 3

pour la supervision et la mtrologie

Dploiement, conguration et optimisation

Jean Gabs
Prface de Cdric Temple (du projet FAN) Avec la contribution de Nat Makarvitch

Nagios 3
pour la supervision et la mtrologie
Dploiement, configuration et optimisation

Chez le mme diteur Dans la collection des Cahiers du programmeur Le livre de Packet Filter (PF), (coll. Cahiers de lAdmin). P. Hansteen, adapt par M. DercHe. N12516, 2009, 200 pages. Debian Lenny. Gnu/Linux . r. Hertzog, r. Mas. dirig par n. MakarvitcH. n12443, 2009, 442 pages avec dVd-rom. BSD, 2e dition (coll. Cahiers de lAdmin). e. Dreyfus. N11463, 2004, 300 pages. Scuriser un rseau Linux. B. BoutHerin, B. Delaunay. N11960, 3e dition, 2007, 250 pages. Le petit manuel des routeurs Cisco, (coll. Cahiers de lAdmin). M. lucas, adapt par M. DercHe. N12602, paratre. Asterisk. tudes de cas. (coll. Cahiers de lAdmin). P. sultan, dirig par N. MakarvitcH. N12434, paratre. Chez le mme diteur Scurit PHP 5 et MySQL. D. sguy, P. gaMacHe. N12554, 2e dition 2009, 286 pages. Scurit informatique. Principes et mthode lusage des DSI, RSSI et administrateurs. l. BlocH, C. WolfHugel. N12525, 2009, 292 pages. Adminsys. Grer son temps t. liMoncelli, adapt par S. BlonDeel. N11957, 2006, 274 pages. SSL VPN. Accs web et extranets scuriss. J. steinBerg, t. sPeeD, adapt par B. sonntag. N11933, 2006, 220 pages. Authentification rseau avec Radius. 802.1x. EAP. FreeRadius. s. BorDres, dir. n. MakarvitcH. N12007, 2007, 220 pages. Scuriser enfin son PC. Windows XP et Windows Vista. P. leganD. N12005, 2007, 500 pages. Mmento VMware Server. Virtualisation de serveurs. f. Manzano. N12320, 2008, 14 pages. Mmento Cisco. IOS Configuration gnrale. r. Bergoin, c. Bourg. N12347, 2008, 14 pages. Linux Administration. J.-f. BoucHauDy, g. gouBet. N12074, 2007, 800 pages. Mmento Unix/Linux. i. HurBain, avec la contribution de. Dreyfus. N11954, 2006, 14 pages. Debian. Administration et configuration avances. M. krafft, adapt par r. Hertzog et r. Mas. N11904, 2006, 674 pages. Management de la scurit de linformation. Implmentation ISO 27001. a. fernanDez-toro. N12218, 2008, 350 pages. Management de la continuit dactivit. e. Besluau. N12346, 2008, 256 pages.

ITIL pour un service informatique optimal. c. DuMont. N12102, 2e dition, 2007, 378 pages. Tableaux de bord de la scurit rseaux. c. llorens, l. levier, D. valois. N11973, 2e dition, 2006, 560 pages. Collection Accs Libre Linux aux petits oignons. K. Novak. N12424, 2009, 546 pages. Ubuntu efficace. l. Dricot. N12362, 3e dition 2009, 350 pages avec Cd-rom. MediaWiki efficace. D. Barrett. N12466, 2009, 372 pages. conomie du logiciel libre. f. elie. N12463, 2009, 195 pages. Freemind Boostez votre efficacit. X. Delengaigne, P. Mongin. N12448, 2009, 272 pages. Spip 2 Premiers pas pour crer son site avec Spip 2.0.3. A.-l. QuatravauX, d. QuatravauX. N12502, 2009, 300 pages. Russir son site web avec XHTML et CSS. M. neBra. N12307, 2e dition, 2008, 306 pages. Russir un site web dassociation avec des outils libres ! a.-l. QuatravauX et D. QuatravauX. N12000, 2e dition, 2007, 372 pages. Russir son site e-commerce avec osCommerce. D. Mercer. N11932, 2007, 446 pages. Open ERP Pour une gestion dentreprise efficace et intgre. f. Pinckaers, g. garDiner. N12261, 2008, 276 pages. PGP/GPG Assurer la confidentialit de ses mails et fichiers. M. lucas, ad. par d. garance , contrib. J.-m. tHoMas. N12001, 2006, 248 pages. Hackez votre Eee PC Lultraportable efficace. c. guelff. N12437, 2009, 306 pages. Monter son serveur de mails Postfix sous Linux M. Bck et al., adapt par P. tonnerre. N11931, 2006, 360 pages. Ergonomie web Pour des sites web efficaces. a. BoucHer. N12479, 2e dition 2009, 440 pages. Joomla et VirtueMart Russir sa boutique en ligne. v. isaksen, avec la contribution de t. tarDif. N12381, 2008, 306 pages. La 3D libre avec Blender. o. saraJa. N12385, 3e dition, 2008, 456 pages avec dVd-rom. Dessiner ses plans avec QCad Le DAO pour tous. A. Pascual N12397, 2009, 278 pages. Inkscape. Premiers pas en dessin vectoriel. n. Dufour, collab. e. De castro guerra. N12444, 2009, 376 pages. Inkscape efficace c. gMy N12425, 2009, 280 pages. Gimp 2.6 Dbuter en retouche photo et graphisme libre. d. roBert. N12480, 4e dition, 2009, 350 pages.

Nagios 3
pour la supervision et la mtrologie
Dploiement, configuration et optimisation
Jean Gabs
Prface de Cdric Temple (du projet FAN) Avec la contribution de Nat Makarvitch

ditiONS eYrOlleS 61, bd Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com

Remerciements Isabelle Hurbain et Sandrine Burriel pour leurs prcieuses relectures.

le code de la proprit intellectuelle du 1er juillet 1992 interdit en effet expressment la photocopie usage collectif sans autorisation des ayants droit. Or, cette pratique sest gnralise notamment dans les tablissements denseignement, provoquant une baisse brutale des achats de livres, au point que la possibilit mme pour les auteurs de crer des uvres nouvelles et de les faire diter correctement est aujourdhui menace. en application de la loi du 11 mars 1957, il est interdit de reproduire intgralement ou partiellement le prsent ouvrage, sur quelque support que ce soit, sans autorisation de lditeur ou du Centre Franais dexploitation du droit de Copie, 20, rue des Grands-Augustins, 75006 Paris. Groupe eyrolles, 2009, iSBN : 978-2-212-12473-6

Prface
sa naissance, Netsaint (renomm plus tard en Nagios) entre dans les entreprises par la petite porte . Il sagit alors, pour les administrateurs de systmes dinformation, dinstaller un outil de supervision pour se faciliter la vie. Install sur un petit serveur reconverti, voire sur un ancien poste bureautique promu en serveur de supervision, Nagios ncessite peu de ressources : il se contente dans un premier temps de dtecter les serveurs et quipements rseau qui ne rpondent plus aux pings . Commence alors lvolution de Nagios au sein du SI. Sa mission stend en effet la vrification des services importants qui ne rpondent plus : services web (HTTP/HTTPS), services dinfrastructure (DNS, SMTP/POP/IMAP, DHCP, LDAP, etc.). Dans le mme temps, les administrateurs ne souhaitent plus tre avertis par les coups de tlphone de leurs utilisateurs... Ils mettent donc en place le principe de notification par e-mail, SMS ou messagerie instantane.
HUMOUR Le meilleur outil de supervision reste...
Le couple Utilisateur-Tlphone reste loutil de supervision le plus fiable... si on omet les faux positifs et lavalanche dalertes simultanes !

Pour une meilleure lisibilit, la supervision est ensuite couple un outil de tendances, gnralement bas sur RRDTool ou MRTG comme Cacti, par exemple. ce stade, seuls les administrateurs systme et rseau et ventuellement leurs responsables directs ont connaissance de lexistence doutils de supervision. Ces derniers restent donc trs techniques, et ne sont simples ni installer, ni utiliser. Ils sont mis en uvre par des administrateurs pour des administrateurs.

VI

Nagios 3

La tendance sinverse ensuite vers les annes 2003-2004. De nouvelles lois (Sarbanes/Oxley) imposent de garder trace des modifications sur le systme dinformation et, par voie de consquence, de superviser les quipements informatiques. De plus, la notion de production informatique commence enfin entrer dans les murs (mieux vaut tard que jamais !) : les directions informatiques souhaitent soutiller pour la mise en uvre dITIL, notamment. Ds lors, la communaut Nagios commence voir apparatre de nouveaux outils pour ces nouveaux publics ; ces outils ne sont plus installs par les administrateurs mais par des socits de services en ingnierie informatique (SSII) ou socits de services en logiciels libres (SS2L). Cest alors que Nagios commence entrer par la grande porte, en barrant la route aux logiciels de supervision historiques (Patrol, HP Open View). Dans un premier temps, il sagit de rendre Nagios plus attrayant. Finie la configuration en mode texte complexe et source derreurs, finie linterface web un peu austre : des thmes et des outils de configuration graphiques font leur apparition. Oreon (devenu Centreon comme Netsaint fut renomm Nagios avant lui) prend son essor grce une vritable rvolution dans le monde Nagios : la tendance est la centralisation de toutes les interfaces. Une seule interface est ncessaire dsormais pour faire la fois : la supervision ( visualisation en temps rel de ltat du SI ), la configuration de celle-ci, les graphiques de tendance et le reporting. En dehors de Centreon, qui a rellement pour but de mettre disposition toutes les fonctionnalits lies la supervision via une seule interface, il est aussi possible de btir une supervision qui semble pour lutilisateur unifie, mais qui reste btie sur de nombreuses briques. Par exemple, la supervision construite sur lensemble Nagios, NDOUtils, NagVis et Pnp4Nagios, une fois savamment configure, permet davoir un point unique dauthentification base sur le serveur LDAP du systme dinformation, tout en offrant la sensation dune interface unique. Ltape de dmocratisation suivante a consist fournir un ensemble intgr prconfigur, combinant de nombreux logiciels, mais pour autant dot dun systme dinstallation simple et efficace. Cest le but des projets comme EON (Eyes of Network) ou FAN (Fully Automated Nagios). Dautres ont choisi une voie lgrement diffrente mais avec les mmes buts en proposant des images de machines virtuelles prconfigures.

Prface

VII

tant lun des crateurs de FAN et responsable de ce projet, je ne peux gager de mon impartialit. Tous ces outils ont nanmoins pour but de proposer une supervision prte lemploi, fournie sur un systme dexploitation enrichi dapplicatifs de supervision. Par exemple, FAN est une distribution GNU/Linux totalement ddie la supervision Nagios. Toutes les mises jour sont intgres directement dans la distribution afin que ladministrateur se concentre sur ce quil doit superviser et non sur linstallation et les mises jour des outils. Aussi incroyable que cela paraisse, Nagios est donc bien lorigine de la cration de distributions dont il est le centre ! Peu doutils peuvent se targuer de cela. Tout cela vous est prsent dans ce livre avec de trs nombreux dtails. Vous apprendrez installer, configurer et administrer tous les outils. Les trs gros points forts de ce livre sont la progressivit et lexhaustivit du contenu. Tous les thmes importants y sont abords : pourquoi superviser, et quels lments superviser, les aspects psychologiques (plus importants quil ne paraissent et trop souvent ngligs), des conseils sur les bonnes pratiques, des points techniques trs dtaills (je conseille notamment le chapitre 14 sur la charge dun systme Unix/Linux !). La progression dans la difficult des lments abords est trs bien pense et satisfera tous les profils de lecteurs, du dbutant lexpert. Cest simple, si javais eu ce livre entre les mains mes dbuts, jaurais gagn un temps trs prcieux. Jean Gabs a ainsi crit le livre que jaurais toujours voulu avoir entre les mains. Outre ses connaissances techniques trs avances, son exprience et son talent dcrivain, il est dune gentillesse et dune simplicit rares. Il vous fait partager sa passion pour le monde de Nagios avec un regard prcis et intelligent, tout en gardant la distance et le recul ncessaires pour une analyse impartiale. Cdric Temple Responsable du projet FAN, Fully Automated Nagios Chef de projet chez MERETHIS, socit ditrice du logiciel Centreon

Table des matires

Avant-propos ................................................................................. 1
qui sadresse ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Ce que ce livre nest pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Progression dans le livre et ordre de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Les diffrentes parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Guide de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

PREMIRE PARTIE

Introduction la supervision et Nagios avec une mise en place simple ......................................5

CHAPITRE 1 Intrt de la supervision et de la mtrologie ............................. 7
tre alert en temps rel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Les problmes sont invitables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Les utilisateurs : un moyen de supervision peu fiable et pas toujours agrable . . . 8 Pouvoir remonter la source des problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 viter leffet domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Un historique pour remonter la source des problmes . . . . . . . . . . . . . . . . . . . 9 tre proactif face aux problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Les signes annonciateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Les problmes nattendent pas les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 10 Une demande frquente de la direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Amliorer la disponibilit effective des applications . . . . . . . . . . . . . . . . . . . . . . . 11 Les diffrents ressentis vis--vis des performances . . . . . . . . . . . . . . . . . . . . . . 11 Grer les priorits : la production avant tout . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Tailler au plus juste le systme dinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Surveiller plus que le systme dinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Un ordonnanceur ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Nagios 3

Supervision physique dune salle machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

CHAPITRE 2 Grandes lignes de ltude et de la mise en place dune solution de supervision .................................................... 15
Plus quun outil : un projet part entire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Revoir ses processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Une rpartition de la charge de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 La supervision doit voluer avec le SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Un outil faisant le lien entre les services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Une mise en place progressive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 La tentation de tout superviser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Faire accepter le projet de supervision ses suprieurs . . . . . . . . . . . . . . . . . . . 18 Faire accepter loutil par le plus grand nombre . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intrt de faire adhrer toute lquipe loutil . . . . . . . . . . . . . . . . . . . . . . . . . 19 Limiter le nombre dalertes et les hirarchiser . . . . . . . . . . . . . . . . . . . . . . . . . 19 Labandon face un trop grand nombre dalertes : une raction naturelle . . . . . 19 Rendre trs clair le niveau dimportance de chaque alerte . . . . . . . . . . . . . . . . 20 Alerter uniquement les bonnes personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Pour un problme donn, une alerte, et une seule . . . . . . . . . . . . . . . . . . . . . 20 Lautomatisation complte : rgler automatiquement les problmes? . . . . . . . . 21 Des indicateurs aussi simples et clairs que possible . . . . . . . . . . . . . . . . . . . . . 22 Le problme du messager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Big Brother is watching you ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 La conduite du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Beaucoup dindicateurs de performance, est-ce utile ? . . . . . . . . . . . . . . . . . . . 24 Le nombre dindicateurs est important . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Quelle dure de conservation des donnes ? . . . . . . . . . . . . . . . . . . . . . . . . . 25 Des chelles simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Superviseur mais galement hyperviseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 La dure ralit de la supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Une seule console de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Mthodes dobtention des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 La modularit : rduire si possible le nombre de superviseurs . . . . . . . . . . . . . . 27 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CHAPITRE 3 Choix dune solution de supervision : atouts et fonctionnement de Nagios......................................... 29

Table des matires

XI

Choix dune licence open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Le besoin dadaptabilit et de modularit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Transparence du mcanisme de remonte dalerte . . . . . . . . . . . . . . . . . . . . . . 30 De trs bonnes performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Mise en commun des expriences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Critres de slection dun projet open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Un monde particulier, avec ses propres rgles . . . . . . . . . . . . . . . . . . . . . . . . . 31 Importance de la communaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Assistance aux entreprises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Le choix de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Histoire de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Nagios ne fait rien sans ses plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Position de Nagios par rapport la mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Atouts de Nagios par rapport aux autres outils open source . . . . . . . . . . . . . . . . . 34 Zabbix : la supervision simplement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Cacti : la mtrologie avec SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 OpenNMS : la supervision trs SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Ganglia : la mtrologie des clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Zenoss : trs bonne supervision, mais pas compltement libre . . . . . . . . . . . . . 35 Orientation vers une totale modularit : tout est plug-in . . . . . . . . . . . . . . . . . 35 La modularit de Nagios : le rle des plug-ins . . . . . . . . . . . . . . . . . . . . . . . 35 Des plug-ins pour avertir ou ragir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Capacit grer un parc important de machines . . . . . . . . . . . . . . . . . . . . . . . 36 Performances de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Gestion de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pertes massives : la solution des dpendances . . . . . . . . . . . . . . . . . . . . . . . . 37 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Mthodes dobtention dinformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Mthode active les alertes linitiative de Nagios . . . . . . . . . . . . . . . . . . . . . 38 Obtention sans rebond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Obtention avec rebond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Mthode passive : les alertes linitiative des lments distants . . . . . . . . . . . . 39 Donnes dfinir dans Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Commandes de vrification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Arguments des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Priodes de temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Dfinition des priodes de temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Version simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Version plus complte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Commandes de notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 De simples commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

XII

Nagios 3

Une grande libert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 tats dun nud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Dfinition dun hte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Exemple de dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 tats des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Dfinition dun service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Exemple de dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Importance des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contacts : qui et comment ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Dfinition dun contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Exemple de dfinition de contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Plus dune manire de notifier un mme contact . . . . . . . . . . . . . . . . . . . . . . 50 Groupes de contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Plug-ins dobtention dinformations : les sondes . . . . . . . . . . . . . . . . . . . . . . . . . 51 Intrt des codes retour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Une vrification simple du bon fonctionnement dun programme . . . . . . . . . . 52 Exemple de code retour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Codes retour recommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Positionner nos propres codes retour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Aspect supervision de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Interprtation des codes retour par Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Affichage des informations de retour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Conception dun script de vrification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Codes retour non prvus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 lments complexes des plug-ins de vrification . . . . . . . . . . . . . . . . . . . . . . 56 Communication entre les Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Partie mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Spcifier des donnes de performances dans les plug-ins . . . . . . . . . . . . . . . . . 58 Exemple de donnes de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Arguments, macros et variables denvironnement . . . . . . . . . . . . . . . . . . . . . . 59 Arguments des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Variables denvironnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Ordonnancement des vrifications et des notifications . . . . . . . . . . . . . . . . . . . . 61 Ordonnancement initial des vrifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 taler la charge sur les machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 taler les vrifications sur le serveur Nagios . . . . . . . . . . . . . . . . . . . . . . . . 61 taler les vrifications sur les machines distantes . . . . . . . . . . . . . . . . . . . . . 62 Types dtat SOFT et HARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Table des matires

XIII

Exemple de changement de type dtat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Un tat SOFT un peu particulier : SOFT-RECOVERY . . . . . . . . . . . . . . . . 65 Notifications de problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Notifications : le but des types dtat SOFT et HARD . . . . . . . . . . . . . . . . . 65 Renvoi de notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Exemple dordonnancement des notifications . . . . . . . . . . . . . . . . . . . . . . . . 66 Notifications : la configuration des contacts prime . . . . . . . . . . . . . . . . . . . . 67 En cas de problme persistant : lescalade des notifications . . . . . . . . . . . . . . . 68 Lorsque les problmes perdurent : on appelle un ami . . . . . . . . . . . . . . . . . . . 68 Bien penser laspect psychologique dune telle mise en place . . . . . . . . . . . . . . 68 Dfinition dans Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Exemple descalade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Cas des notifications de type recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Destination de toutes les informations rcoltes . . . . . . . . . . . . . . . . . . . . . . . . . 70 Informations dtat, dalerte et de notification . . . . . . . . . . . . . . . . . . . . . . . . . 70 En cas de redmarrage : le fichier status.sav . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Un module dexport de donnes : NDOUtils . . . . . . . . . . . . . . . . . . . . . . . . . 71 Comment donner un ordre Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Fonctionnement de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Ce quon peut lui demander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Prise en compte dun tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Forcer un rsultat de vrification dun service . . . . . . . . . . . . . . . . . . . . . . . 72 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

CHAPITRE 4 Premier niveau de test : rponse dun nud sur le rseau ..... 75
Tests directs sur le rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Tests applicatifs simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Test des ports rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Un test simple et lger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Test dun port TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Un test suffisant pour la disponibilit dun hte . . . . . . . . . . . . . . . . . . . . . . 78 Test des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Principe des tests HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Le plug-in check_http . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Cas des services web accs scuriss : authentification, HTTPS... . . . . . . . . . 81 Jouer un scnario plus complexe avec Webinject . . . . . . . . . . . . . . . . . . . . . . 83 Test des services DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Mthode de supervision des DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Exemple de test DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Test des annuaires LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

XIV

Nagios 3

Mthode de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Exemple dinterrogation LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Supervision du DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Un lment indispensable pour les clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Sonde check_dhcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Problmes de droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 La commande sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Le bit SUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Supervision de la messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Supervision dune base MySQL ou PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . 92 Lorsque de simples vrifications rseau ne suffisent pas : les agents . . . . . . . . . . . 93 Rle des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Principaux agents disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 NRPE : lancer des plug-ins distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Fonctionnement de NRPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Configuration du dmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Fichier de configuration principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Grer les exceptions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Lancement de lagent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Exemple dinterrogation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 SSH peut galement faire laffaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Lancement de commandes travers SSH . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Problme de lauthentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Utilisation de SSH la place de NRPE . . . . . . . . . . . . . . . . . . . . . . . . . . 100 SNMP : une liste de donnes exportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Le protocole SNMP et les OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Exemple dinterrogation SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 SNMP sur les serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 NSClient++ : des plug-ins et des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Mise en place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Un peu plus que des valeurs immdiates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Importance de WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

CHAPITRE 5 Installation et configuration : premier test de quelques serveurs web.............................................................................. 107

Objectifs de cette mise en place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Premire installation : simplicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Choix du systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Table des matires

XV

Installation par le gestionnaire de paquetages . . . . . . . . . . . . . . . . . . . . . . . . 108 Avantages de linstallation par paquetage . . . . . . . . . . . . . . . . . . . . . . . . . 108 Quelques dsavantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Installation des paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Principaux fichiers de configuration de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . 111 Mise en place de la vrification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Description de lenvironnement supervis . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Configuration des contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Commandes denvoi de-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Configuration des priodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Configuration des contacts dans contacts.cfg . . . . . . . . . . . . . . . . . . . . . . . . 115 Configuration des htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Commande de vrification des htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Configuration des htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Configuration des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Commande de vrification des services web . . . . . . . . . . . . . . . . . . . . . . . . 119 Configuration des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Dfinition des fichiers de configuration dans nagios.cfg . . . . . . . . . . . . . . . . 121 Lancement de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Test de dtection dun problme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Complexifions un peu larchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Supervision des systmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Importance de la supervision systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Supervision du serveur de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Prise en compte de localhost par Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Supervision des systmes distants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Mise en place de la console de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Une brique utile dans la solution de supervision . . . . . . . . . . . . . . . . . . . . . 133 Une interface qui volue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Mise en place de linterface web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Implications dune augmentation du nombre dlments . . . . . . . . . . . . . . . . . . 135 Une augmentation invitable du nombre de nuds . . . . . . . . . . . . . . . . . . . . 135 Une augmentation dangereuse du nombre de notifications . . . . . . . . . . . . . . 135 Une lourdeur croissante de la configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 136 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

DEUXIME PARTIE

Options avances de Nagios .....................................139

XVI

Nagios 3

CHAPITRE 6 Trier les alertes et amliorer leur pertinence ......................... 141

De lintrt de filtrer correctement les alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Concision des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Concision et prcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Exemple de-mail dalerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Exemple de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Bien choisir le niveau derreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Criticit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Difficult de dfinir les niveaux de criticit . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Des niveaux voluent amens voluer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Une seule alerte par erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Diminuer encore le nombre dalertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Les diffrentes supervisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Raction de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Dpendances rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Problmatique des pertes rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Solution : les dpendances rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Dfinition dune relation de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Dpendances applicatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Dpendances entre services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Plusieurs dpendances pour un mme service . . . . . . . . . . . . . . . . . . . . . . . 153 Hritage des dpendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Se concentrer sur les vraies alertes : la production . . . . . . . . . . . . . . . . . . . . . . . 155 Les notifications : rserves la production . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Les diffrents environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Astreintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Du rouge dans la console de supervision : rserver la production . . . . . . . . 156 Tirer avantages des priodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Des allies prcieuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Priodes de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Priodes de notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Que faire dans le cas de simples pertes de connexion ? . . . . . . . . . . . . . . . . . . . . 158 Des pertes invitables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Dans la peau dun utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Des sur-couches pour viter la prolifration de plug-ins . . . . . . . . . . . . . . . . . . 160 Moins de plug-ins, plus de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Diminuer de niveau dalerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Pour se limiter la mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Supprimer la mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Table des matires

XVII

Comment obtenir le rsultat inverse dune commande . . . . . . . . . . . . . . . . . . 163 gayer (un peu) les alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Le fond et la forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Un peu de couleur dans un monde de brutes . . . . . . . . . . . . . . . . . . . . . . . . . 165 Alertes en flux RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Un vecteur dinformation trs employ et pratique . . . . . . . . . . . . . . . . . . . 166 Mise en place de rss-multiuser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Exemple de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Alertes par SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Canaux dalerte non conventionels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Des moyens dalerte originaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Lecture dun son . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Alerte sur lcran LCD du clavier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Le lapin qui chante et qui danse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Le lance-roquettes USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Les ractions sur alertes, ou comment rgler automatiquement les problmes . 173 Une solution sduisante double tranchant . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Gestionnaires dvnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Gestion de leffet yoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Une tempte de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Mthode de dtection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Exemple de dtection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Gestion des priodes de maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

CHAPITRE 7 Services particuliers : journaux, alertes SNMP... .................... 181

Comment vrifier les fichiers journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Mthode de vrification des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Une supervision primordiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Une analyse par morceaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Exemple de plug-in de vrification des journaux . . . . . . . . . . . . . . . . . . . . . . 183 Problme des tests conscutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Tests suivants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Test en tat OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Erreur de moindre importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Erreur de mme criticit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Configuration au sein de Nagios : la volatilit . . . . . . . . . . . . . . . . . . . . . . . . 185 Quand chaque changement est important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Lorsque la volatilit est de trop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

XVIII

Nagios 3

Suivi prcis des tats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Exemple de paramtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Services passifs : exemple de gestion des alertes SNMP (traps) . . . . . . . . . . . . . 187 Intrt des services passifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Les vrifications actives ne peuvent pas tout . . . . . . . . . . . . . . . . . . . . . . . 187 Donner linformation dtat Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Notion de fracheur dun tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Limites des alertes passives simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Comme pour le poisson, la fracheur est importante . . . . . . . . . . . . . . . . . . . 189 Un plug-in toujours en erreur pour prvenir les administrateurs . . . . . . . . . 190 Exemple de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Positionnement correct du seuil de fracheur . . . . . . . . . . . . . . . . . . . . . . . . 191 Comment grer les traps SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Configuration de SNMPTRAPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Configuration de SNMPTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Configuration du service TRAP pour la rception des alertes . . . . . . . . . . . . 194 Exemple de rception dune alerte SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 195 Rception et traitement des alertes passives distantes . . . . . . . . . . . . . . . . . . . 195 Un moyen efficace de rcolter les tats distants : NSCA . . . . . . . . . . . . . . . . 195 Son fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Configuration du dmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Configuration du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Lancement du dmon et du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Exemple dapplication : traitement des journaux par un service distant . . . . . 199 Un type de vrification particulier : surveiller un cluster . . . . . . . . . . . . . . . . . . . 201 Des clusters varis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Supervision des services rels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 En actif / actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 En actif / passif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Avoir une vue agrge du cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Plug-in check_cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Macros la demandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Exemple de tests du cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Ne pas oublier la vue utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

CHAPITRE 8 Lhritage de configuration pour les grands environnements ...... 209

Techniques de gestion de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Factoriser pour traiter les nuds similaires . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Grer les exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Table des matires

XIX

Grer simplement une configuration complexe . . . . . . . . . . . . . . . . . . . . . . . 211 Hritage de mme type : dfinition de modles . . . . . . . . . . . . . . . . . . . . . . . . . 213 Factorisation simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Factorisation par modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Mise en place dans Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Gestion des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Hritage sur les services et les contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Cascade dhritages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Arbre dhritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Exemple darbre dhritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Hritages multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Avoir plus dun modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Dfinition au sein de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Exemple de dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Ordre dhritage entre modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Priorit la premire valeur assigne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Exemple dordre dhritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Rduction de la configuration : application des services sur les groupes de nuds . . . 223 Groupes de machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Ajout de services un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Dfinir un service sur un groupe de nuds . . . . . . . . . . . . . . . . . . . . . . . . . 224 Dfinition et exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Gestion des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Hritage implicite : hriter dun autre type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Problmes soulevs par lassociation des services aux groupes . . . . . . . . . . . . . 228 chaque problme sa solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Rechercher les informations dupliques . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Raction de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Exemple dhritage implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Une solution ne pas utiliser systmatiquement . . . . . . . . . . . . . . . . . . . . . . 231 Hritages des macros variables : gnralisation de lhritage implicite . . . . . . 232 Lintrt des macros variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Exemple dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Hritage additif : ajouter une valeur au lieu de lcraser . . . . . . . . . . . . . . . . . . . 233 Limites des modles simples et solution de Nagios . . . . . . . . . . . . . . . . . . . . 234 Hritage additif sur hritage implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Hritages : ordre de succession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Impact de cette puissance de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

XX

Nagios 3

CHAPITRE 9 Pousser Nagios dans ses derniers retranchements ................ 239

Les performances : une problmatique complexe . . . . . . . . . . . . . . . . . . . . . . . . 239 Des besoins divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Un ordonnancement coupable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Une rtention trop leve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Observer les performances de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Latence : Nagios nous montre sil tourne au ralenti . . . . . . . . . . . . . . . . . . . . 242 Latence des ordonnanceurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Mesure de la latence : nagiostats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Exemple de sortie de nagiostats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Supervision de la latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Mthodologie de test de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Une myriade de services sur un nud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Configuration ncessaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Une situation idale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 volution de la latence en fonction du nombre de services . . . . . . . . . . . . . . . 247 Tampon de traitement des informations passives . . . . . . . . . . . . . . . . . . . . . . 249 Une charge machine atypique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Revoir lordonnancement de ses vrifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Diminuer le nombre de vrifications lances . . . . . . . . . . . . . . . . . . . . . . . . . 251 Suivre les conseils de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Amliorer les plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Impact du type de sondes sur les performances . . . . . . . . . . . . . . . . . . . . . . . 253 Un impact fort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Scripts contre excutables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Utilisation de linterprteur Perl intgr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Un interprteur intgr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Exemple dutilisation dePN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Tester un script avec linterprteur intgr . . . . . . . . . . . . . . . . . . . . . . . . . 257 Spcifier Nagios dutiliser ou non ePN . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Mise en place progressive dePN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 NRPE ou SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Des vrifications actives aux passives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 La virtualisation malheureusement encore dconseille . . . . . . . . . . . . . . . . . 260 Options de configuration augmentant les performances . . . . . . . . . . . . . . . . . . 261 Mcanismes de cache de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Vrifications supplmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Rutilisation des tats en mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Performances contre prcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Table des matires

XXI

Trouver un bon cache hit ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Options spcifiques aux environnements trs tendus . . . . . . . . . . . . . . . . . . 263 Suppression des variables denvironnement . . . . . . . . . . . . . . . . . . . . . . . . 264 Nettoyage de lespace mmoire des plug-ins . . . . . . . . . . . . . . . . . . . . . . . . 265 Suppression de la double duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Utilisation conjointe des trois techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Positionnement des fichiers intermdiaires . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Systmes de fichiers en mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Fichier status.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Rpertoire checkresults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Impact des fichiers temporaires en mmoire . . . . . . . . . . . . . . . . . . . . . . . . 270 Consommation de RAM de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Architectures distribues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

CHAPITRE 10 Haute-disponibilit et rpartition de charge .......................... 273

Haute-disponibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Un Nagios dans lombre dun autre : la voie active/active . . . . . . . . . . . . . . . . 273 Deux Nagios actifs la fois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Superviser un Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Raction face la perte du Nagios matre . . . . . . . . . . . . . . . . . . . . . . . . . 275 Limiter la priode de brouillard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Synchroniser les deux Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Un Nagios dormant de secours : la mthode active/passive . . . . . . . . . . . . . . 278 Un seul Nagios actif la fois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Problme des tats prcdents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Relais par le Nagios secondaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 parpillement des donnes de mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Rpliquer NSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Rpartition de charge : chaque Nagios sa tche . . . . . . . . . . . . . . . . . . . . . . . . 283 Centraliser les informations, pas la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Une architecture distribue avec les commandes externes . . . . . . . . . . . . . . . . 283 Simplification de la rpartition avec NDO . . . . . . . . . . . . . . . . . . . . . . . . . . 285 NDOMOD : un nouveau type de module . . . . . . . . . . . . . . . . . . . . . . . . . 285 Le module Ndomod : exporter les donnes . . . . . . . . . . . . . . . . . . . . . . . . . 286 Ndo2db : recevoir les donnes et les placer dans une base . . . . . . . . . . . . . . . 289 Architecture de supervision distribue avec NDOUtils . . . . . . . . . . . . . . . . 291 Rpartition de charge par Worker (DNX) . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Une nouvelle utilisation de levent broker . . . . . . . . . . . . . . . . . . . . . . . . . 294 Module serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

XXII

Nagios 3

Clients DNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Avantages et inconvnients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Utilisation de DNX et NDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Rpartition de charge haute-disponibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Le besoin accru de disponibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 chaque Nagios son ombre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Haute-disponibilit pour NDO2DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Un service important doubler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Mise en place de HeartBeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Adresse virtuelle pour NSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Supervision de HeartBeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

TROISIME PARTIE

cosystme de Nagios et mise en place de la solution ...309

CHAPITRE 11 Outils daide la configuration : lexemple de Centreon ...... 311
Intrt de tels outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Une configuration longue et fastidieuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 La gestion simultane des aspects de mtrologie . . . . . . . . . . . . . . . . . . . . . . 312 La solution Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Mise en garde : limites des outils de gestion de configuration . . . . . . . . . . . . . . 313 Les outils ne font pas tout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Nagios avance vite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Des fonctionnalits utiliser avec parcimonie . . . . . . . . . . . . . . . . . . . . . . . . 314 Centreon, le meilleur ami de votre Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Un outil incontournable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Une volution constante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Une nouvelle gestion de la mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Une gestion simple des alertes SNMP (traps) . . . . . . . . . . . . . . . . . . . . . . . 316 Des architectures distribues enfin simples . . . . . . . . . . . . . . . . . . . . . . . . . 316 Aspect configuration : le cur de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . 316 Les configurations passes ne sont pas oublies . . . . . . . . . . . . . . . . . . . . . . 318 Des possibilits de configuration bien connues . . . . . . . . . . . . . . . . . . . . . . . 319 Dautres un peu plus particulires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Moins dutilisation du shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Aspect supervision des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Une console trs pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Obtention de toutes ces informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Table des matires

XXIII

Un historique des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Restrictions daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Des informations prives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Diminuer le nombre dlments affichs . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Des accs en modification surveiller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Gestion des accs selon Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Centreon, gestionnaire de la mtrologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 CentStorage : le gestionnaire des donnes de performances . . . . . . . . . . . . . . 328 Destination des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Accs aux courbes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Des informations sur les performances de Nagios . . . . . . . . . . . . . . . . . . . . 330 Centreon facilite la gestion des alertes SNMP . . . . . . . . . . . . . . . . . . . . . . . . 331 Un chargement et une compilation automatique . . . . . . . . . . . . . . . . . . . . . 331 Remonte dalertes de SNMPTT vers Nagios . . . . . . . . . . . . . . . . . . . . . . 332 Centreon pour grer Nagios en distribu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Une configuration complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Les Nagios distants : des pollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Associations poller / htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Envoi des configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Des Nagios presque indpendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Mtrologie issue des satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Des notifications repenser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

CHAPITRE 12 Au-del de la supervision : cartographie et reporting........... 337

Agrgation de vues avec NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Mise en relief des informations importantes . . . . . . . . . . . . . . . . . . . . . . . . . 337 Des consoles qui ne se vident pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Des alertes plus ou moins critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 crans publics et crans privs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Choisir les informations afficher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Slection des alertes sur les crans publics . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Slection des alertes sur les crans privs des administrateurs . . . . . . . . . . . . 341 Lutter contre la tentation de multiplier les indicateurs . . . . . . . . . . . . . . . . 342 Des vues hirarchises dindicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Vues de diffrents types : logique, physique, gographique . . . . . . . . . . . . . . . 343 Reprsenter graphiquement la prise en compte des erreurs . . . . . . . . . . . . . . 344 Localiser et illustrer les erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Fonctionnement de NagVis pour cartographier les erreurs . . . . . . . . . . . . . . . . 345 Disposition des indicateurs sur une carte de supervision . . . . . . . . . . . . . . . . 345

XXIV

Nagios 3

Choix des images par ladministrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Images des lments superviss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Bibliothque dimages libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Rcupration des tats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Ndomy : lecture depuis une base MySQL (ndo2db) . . . . . . . . . . . . . . . . . . . 348 Ndo2fs : lecture depuis des fichiers plats . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Rotation des vues dans NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Mise jour automatique des cartes lajout dun noeud . . . . . . . . . . . . . . . . . 352 Reporting dans Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 De limportance dune analyse plus globale et dans le temps . . . . . . . . . . . . . . 352 Dfinir les indicateurs : une mission dlicate . . . . . . . . . . . . . . . . . . . . . . . . . 353 Le module de reporting de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

CHAPITRE 13 Compilation et installation de Nagios, Centreon et NagVis.. 357

Les diffrentes possibilits de mise en place . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Installation partir de paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Compilation depuis les sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Mise en place complte automatique avec FAN . . . . . . . . . . . . . . . . . . . . . . 358 Installation manuelle complte titre didactique . . . . . . . . . . . . . . . . . . . . . . 359 Compilation et installation de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Rcupration du programme Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Pr-requis de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Phases de linstallation de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Compilation de NDOUtils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Rcupration et compilation de NDOUtils . . . . . . . . . . . . . . . . . . . . . . . . 363 Cration de la base pour NDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Installation de NDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Installation des sondes de Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Installation de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Pr-requis linstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Rcupration et installation de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Configuration de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Mise en place de NagVis pour lagrgation de vues . . . . . . . . . . . . . . . . . . . . . . 374 Installation de NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Configuration de NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Configuration des droits sur NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Mise en place de la base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Un wiki comme gestionnaire de base de connaissance . . . . . . . . . . . . . . . . . . 376 Installation de MediaWiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Table des matires

XXV

Mise en place de la sauvegarde avec mysqldump . . . . . . . . . . . . . . . . . . . . . . . . 377 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

CHAPITRE 14 Aide linterprtation des indicateurs classiques ................. 381

Obtention des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Sur les systmes Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Informations globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Informations relatives aux processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Analyse des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Sur les systmes Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Lexistence dun indicateur de charge globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Une question rcurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Dfinition de la charge moyenne, ou load average . . . . . . . . . . . . . . . . . . . . . 385 Processus pris en compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Moyennes exponentielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Exemples de courbes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Reprsentation visuelle du load average . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Systmes typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Systme sous-dimensionn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Systme bien dimensionn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Systme sur-dimensionn ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Changement de point de vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Analyse contradictoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Attentes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Une analyse variable de la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Deux indicateurs valent mieux quun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Limites du load average considr seul . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Analyse du load average . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Charge des processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Un indicateur important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Plusieurs types de charge CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Rcupration effective de la charge CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Sous les Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Superviser la mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Un indicateur un peu particulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Mthode nave de supervision de la mmoire . . . . . . . . . . . . . . . . . . . . . . . . 402 Le pige des caches disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Des caches bien pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Un espace disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

XXVI

Nagios 3

Sous Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Sous les systmes Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Cas des gestionnaires de bases de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Espace dchanges sollicit non vide malgr la mmoire disponible . . . . . . . . 405 Relation de dpendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Problme des I/O disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Une ressource trs limitative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Une supervision complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Supervision de la charge rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Des liens parfois insuffisants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Systmes dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Sous Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 lments rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Le reste de la supervision systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Espace disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Une ressource importante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Seuils dalerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Sondes de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Montages NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Agrgats rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 tat des imprimantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Sous Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Services lancs automatiquement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Redmarrage des machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Indicateurs physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Alertes prioritaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Temprature et humidit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 La temprature : une valeur trs variable . . . . . . . . . . . . . . . . . . . . . . . . . 417 Lhumidit : variable suivant la saison . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Consommation lectrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

CHAPITRE 15 Configuration applique un systme imaginaire ................ 419

Rcupration des informations sur le systme superviser . . . . . . . . . . . . . . . . 419 Conception de larchitecture de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Regroupement par type : systme, rseau, applicatifs... . . . . . . . . . . . . . . . . . 420 Procder par tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Groupes dadministrateurs et contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Table des matires

XXVII

Groupes de machines superviser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Packs de sondes mettre en place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Lindispensable base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Configuration de Nagios dans Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Un ou plusieurs Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Configuration dun Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Fichiers journaux et autres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Options de vrification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Options de timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Interaction avec NDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Options de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Pages de dbogage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Configuration de NDO dans Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Accs la base de donnes (NDO2DB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 NDOMOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Application des techniques dhritage dans Centreon . . . . . . . . . . . . . . . . . . . . 429 Choix de la mthode de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Configuration des commandes et des contacts . . . . . . . . . . . . . . . . . . . . . . . . 429 Des commandes dj configures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Facilits de configuration apportes par Centreon . . . . . . . . . . . . . . . . . . . . 430 Configuration des sondes check_nrpe et check_nt . . . . . . . . . . . . . . . . . . . . . 431 Commande denvoi des e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Configuration des contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Configuration des htes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Commencer par les modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Dfinir les groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Configuration fastidieuse des nuds . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Configuration des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Quelques principes de bon sens : nommage et parcimonie . . . . . . . . . . . . . . . 435 Commencer encore par les modles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Les packs dabord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Les particularits de la supervision systme ensuite . . . . . . . . . . . . . . . . . . . 437 Les applications pour finir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 Ne pas oublier la base de connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Configuration des ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Gnration de la configuration par Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Cration des vues agrges dans NagVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Sparation des diffrents types de cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Mise en place dune nouvelle carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Choix des indicateurs reprsents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Une hirarchie de cartes respecter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

XXVIII

Nagios 3

Des exemples de cartes pour les administrateurs . . . . . . . . . . . . . . . . . . . . . . 444 En un mot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

CHAPITRE 16 Conclusion et perspectives ....................................................... 445

Une solution pleinement fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Nagios, une solution en constante volution . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

ANNEXE A Les principales sondes .............................................................. 447

Supervision des ressources systme locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 La supervision de ltat physique de la machine . . . . . . . . . . . . . . . . . . . . . . . . . 449 La supervision des applications locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 La supervision des services distants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 La supervision des systmes distants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 Les sondes utilitaires pour Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

ANNEXE B Options de configuration de nagios.cfg .................................. 457

Dclaration des fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 Configuration de la supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Chargement des modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Options de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Configuration de lordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Options de localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Options de dbogage et de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Index........................................................................................... 477

Avant-propos
Ce livre est un guide pour ltude et la mise en place dune solution de supervision Open Source base sur Nagios. Il voque les principes fondamentaux de la supervision et de la mtrologie. Loutil qui sera utilis est Nagios, et louvrage tente de dcrire ce que les administrateurs seront amens utiliser dans une mise en uvre en conditions relles. Nous y voquons les cueils classiques de la mise en place dun outil de supervision et nous proposons des mthodes afin de les viter. Enfin, nous tudions tout laspect projet de cette mise en place afin que les administrateurs puissent grer au mieux les possibles rticences qui ne manqueront pas de faire surface de la part de leurs collgues.

qui sadresse ce livre

Cet ouvrage est destin tous les administrateurs sintressant la supervision Open Source. Ils y trouveront les avantages quoffre une solution libre, ainsi que toutes les informations ncessaires relatives aux solutions bases sur Nagios. Ce dernier naura plus de secret pour eux, tant au niveau de son fonctionnement que des mthodes avances de configuration. Les administrateurs ayant dj des connaissances sur ladministration de Nagios y trouveront des informations utiles sur des fonctionnalits peu connues ou sur une bonne gestion de la configuration.

Nagios 3

Ce que ce livre nest pas

Ce livre ne vise pas rfrencer toutes les sondes qui existent pour Nagios ni toutes ses interfaces de configuration possibles et imaginables. Le choix sest limit aux solutions les plus mres et les plus utiles pour les administrateurs. Certaines fonctionnalits de Nagios sont passes sous silence pour la simple raison que la quasitotalit des administrateurs de la plante nen ont pas lutilit. Ce choix permet aux lecteurs de se concentrer sur les algorithmes de supervision importants mis en place par Nagios. Il respecte en ce sens le principe fondamental dUnix : ne faire quune chose, mais la faire bien.

Progression dans le livre et ordre de lecture

Le cheminement suivi par cet ouvrage est celui de tout administrateur lorsquil rencontre une nouvelle problmatique : il commence par tudier les grands principes qui sous-tendent la supervision, puis tente une premire mise en place. Dans ce contexte, il rencontre des difficults lorsquil sagit daugmenter sensiblement le nombre de machines surveilles. Les mthodes de la deuxime partie permettent de rgler ces soucis. Enfin, une fois le socle Nagios pleinement matris, il peut mettre en place le reste de la solution avec, par exemple, des outils de gestion de configuration. Partir dune solution complte pour tenter de la redimensionner pour coller au besoin de dpart est lune des erreurs les plus coteuses que peut faire un administrateur. Sans de bons principes de dpart, la mise en place sera bancale et ladministrateur naura aucune matrise de son installation. Dans ce genre de situation, le projet de supervision est vou lchec plus ou moins long terme.
AVERTISSEMENT Un lecteur avec plusieurs casquettes
Que le lecteur se rassure sur ce cheminement, une seule personne suffit grer une solution base sur Nagios, mme si dans ce livre, nous faisons rfrence ladministrateur, ladministrateur Nagios, voire lutilisateur... Bien sr, pour des raisons de disponibilit, il est conseill dtre au moins deux... mais ceci sera discut dans un prochain chapitre.

Les diffrentes parties

Louvrage est divis en trois grandes parties : 1 introduction la supervision et Nagios avec une mise en place simple ; 2 tude des options avances de Nagios ;

Avant-propos

3 tude de lcosystme gravitant autour de Nagios et mise en place finale.

La premire partie permet de familiariser le lecteur avec les problmatiques de la supervision des systmes modernes. La solution propose pour y rpondre repose sur Nagios, dont les grands principes sont analyss. Les aspects projet de la mise en uvre sont tudis afin dalerter le lecteur sur les points importants considrer avant de proposer loutil au reste de lquipe. Cette partie se termine par une premire mise en place o le lecteur pourra observer Nagios en action, mais galement les problmes que soulve une augmentation du nombre dlments surveills, notamment en matire de gestion de configuration. La deuxime partie approfondit le fonctionnement de Nagios. Ses possibilits pour grer un parc important de machines sont tudies, tant en termes de performance quen termes de gestion de configuration. Cette partie traite galement des mthodes permettant de faire accepter la solution auprs des autres administrateurs. Sans adhsion de leur part, le projet est vou lchec, mme sil est techniquement pertinent. La troisime partie concerne lcosystme de Nagios. Les outils daide la configuration sont tudis et nous en prsentons les avantages et inconvnients afin que le lecteur puisse faire ses choix en connaissance de cause. Un chapitre est ddi linterprtation des indicateurs classiques sur les systmes et rseaux. Enfin, la mise en place finale permet ladministrateur de disposer dune solution complte prte lemploi.

Guide de lecture
Les diffrentes parties de cet ouvrage sont relativement indpendantes. Lordre de lecture conseill pour une personne nayant aucune connaissance en matire de supervision est de suivre tout simplement les chapitres les uns aprs les autres. Les principes lui seront prsents, suivis de leur application dans le monde rel. Les administrateurs ayant dj des connaissances sur la mise en place dune solution de supervision peuvent sauter les deux premiers chapitres. Ceux qui connaissent dj bien Nagios peuvent, sils le souhaitent, passer la premire partie. La seconde partie constitue le cur de ltude. Sa lecture est fortement conseille, mme pour ceux qui ont dj des connaissances au sujet de Nagios. Enfin, les chapitres finaux sont conseills, y compris pour les administrateurs qui souhaitent utiliser des mthodes automatiques de mise en place de Nagios. Ils y verront les problmes les plus courants concernant la configuration de loutil aprs installation. Le chapitre 14 sur les indicateurs de supervision et leur interprtation est un passage oblig pour les administrateurs systme.

Nagios 3

Remerciements
Je tiens remercier Ethan Galstad sans qui Nagios naurait pas exist. Il assure depuis de nombreuses annes le suivi de loutil, ne cesse de lamliorer et de faciliter la vie des administrateurs. Merci aux auteurs de Centreon ainsi qu la communaut forme autour de cet outil. Jai une pense toute particulire pour Guigui2607 et Vcarp pour leur aide dans la comprhension de la latence de Nagios et dans les nombreuses tentatives que nous avons menes pour lamliorer. Merci Cdric Temple davoir accept dcrire la prface et de tester mes programmes pas toujours bien finis. Jai une pense pour les administrateurs de la socit Lectra qui mont permis de mettre en place une solution base sur Nagios. Tout particulirement Jean-Philipe Leroy pour avoir cru en ce projet, Laurent Audoin pour ses intressants changes sur la charge des machines et enfin ric Beaulieu pour ses demandes toujours plus varies et son aide dans le dur travail de relecture de mes crits. La taille et les particularits de lenvironnement de Lectra, ainsi que les demandes de supervision diverses et varies, mont permis de tester toujours plus loin les possibilits de Nagios. Je tiens galement remercier lquipe des ditions Eyrolles et en particulier Muriel Shan Sei Fan et Nat Makarvitch pour leur soutien et leurs remarques toujours constructives, ainsi quIsabelle Hurbain et Sandrine Burriel, mais aussi Gal Thomas et Sophie Hincelin. Mes remerciements les plus nourris vont indiscutablement ma femme Caroline qui, outre le fait de supporter un mari qui passe ses soires le nez sur un portable, ma gentiment propos de soccuper des diagrammes. Sans son aide, ils nauraient pas t aussi clairs et agrables regarder. Je remercie enfin notre petit William qui je ddicace ce livre. Ne me voyant pas donner le biberon et crire en mme temps, il ma permis de fixer simplement les chances de rdaction et dtre tout particulirement motiv pour les respecter.

PREMIRE PARTIE

Introduction la supervision et Nagios avec une mise en place simple

Cette premire partie introduit la supervision et en prsente un exemple simple. Constitue de cinq chapitres, elle accompagne le lecteur dans sa premire mise en place de Nagios. Le chapitre 1 est une introduction la problmatique de la supervision, laquelle est confront tout administrateur de systmes dinformation. Il prsente les avantages quun administrateur peut retirer en mettant en place une solution de supervision et de mtrologie. Le chapitre 2 prsente, quant lui, les grandes lignes de ltude de la solution et de sa mise en place. Nous y tudions les dfis qui attendent les administrateurs, tout comme les parades pour viter les principaux cueils. Au chapitre 3, nous abordons les critres rgissant le choix dune solution de supervision. Nagios, star de la supervision libre, en sort vainqueur. Nous verrons son mode de fonctionnement global. Le chapitre 4 prsente les mthodes de supervision des lments distants comme les serveurs ou les quipements rseau. Aprs cela, les termes de tests sur le rseau ou d interrogation dagent nauront plus de secret pour vous.

Nagios 3

Le chapitre 5, enfin, propose de mettre en place une premire solution de supervision avec un objectif simple : surveiller quelques serveurs web. Bien que cette premire exprience soit facultative, il est fortement conseill au lecteur de sy confronter afin de mieux comprendre les limites dune utilisation sommaire de Nagios. Les informations prsentes dans la seconde partie de louvrage nous serviront prcisment dpasser ces limites.

1
Intrt de la supervision et de la mtrologie
Le mtier dadministrateur devient de plus en plus complexe, do limportance pour lquipe de gagner en temps et en efficacit grce un bon outil de supervision.

tre alert en temps rel

Les systmes dinformation tant par nature complexes, leur supervision est indispensable.

Les problmes sont invitables

Les systmes dinformation sont tous diffrents de par leur taille, leur nature, leur criticit. Ils ont cependant pour point commun dtre le thtre dincidents, un moment ou un autre. Ils ont beau tre grs par les meilleurs administrateurs du globe et tre jour, la loi de Murphy est immuable. Si quelque chose peut mal tourner, alors elle finira infailliblement par mal tourner. Un des rles des administrateurs est justement de grer cela. Ils doivent concevoir larchitecture du systme dinformation de telle manire quune panne ait un impact minimal sur le reste du systme. Ils doivent aussi grer les ventuels problmes ce qui reste une part importante de leur charge de travail. Mme

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

avec des architectures robustes, on estime gnralement 80% de lactivit dun administrateur la rsolution de problmes. Voil pourquoi il vaut la peine de chercher diminuer cette part qui, il faut bien lavouer, est loin dtre la plus intressante, et de surcrot najoute aucune valeur aux systmes.

Les utilisateurs : un moyen de supervision peu fiable et pas toujours agrable

Les systmes dinformation ont pour but final de servir des utilisateurs et dtre employs par eux. Ceux-ci ne manquent pas de signaler aux administrateurs les problmes quils y rencontrent problmes qui surviennent soit par manque de formation des utilisateurs, soit par relle carence du systme. Dans ce dernier cas, il nest pas agrable, pour ladministrateur, de lapprendre de la bouche dun utilisateur car celui-ci nest gnralement ni tendre ni trs prcis. Cette imprcision peut faire perdre un temps prcieux lors de la rsolution du problme. Ladministrateur, faute dinformations pertinentes, cherche le problme au mauvais endroit. Une solution de supervision permet justement dviter ce genre de soucis. Ladministrateur est prvenu rapidement dune situation anormale, bien souvent en moins de temps quil nen faut un utilisateur pour venir se plaindre. Il dispose, de plus, dinformations pertinentes et peut immdiatement satteler la rsolution du problme. Si ce dernier est mineur, sa rsolution est rapide. Lutilisateur qui tente de nouveau daccder la ressource y parvient et nappelle pas le support. Il y a gain de temps, de part et dautre, sans compter que lutilisateur finit par se faire une meilleure opinion du service informatique quil appelle moins souvent. En outre, certaines ressources ne sont utilises quoccasionnellement cest le cas par exemple des applications de dclaration au trsor public. En cas de souci en priode de non-utilisation, sans outil de supervision, lerreur nest pas remonte ; ce nest que lors de lutilisation de lapplication que les utilisateurs sen aperoivent et sont bloqus. Avec un outil de supervision, les administrateurs auraient eu tout le temps ncessaire pour rsoudre le problme en priode creuse. Ils ne subiraient pas les foudres des utilisateurs dune application comptable en priode de clture...

Pouvoir remonter la source des problmes

Les systmes tant de plus en plus imbriqus, une simple erreur peut en produire un nombre incalculable dautres.

Intrt de la supervision et de la mtrologie CHAPITRE 1

viter leffet domino

Bien souvent, une ressource fait partie dune architecture plus large. En cas de problme, cette ressource peut emporter avec elle tout un pan de la construction, mme si cela peut prendre du temps. Cest l que la vitesse de dtection et de raction face au problme reste primordiale pour viter un effet domino dvastateur. Si ladministrateur arrive rsoudre le problme rapidement, les autres lments peuvent tre pargns. Il gagne donc doublement du temps en prvenant lapparition dautres problmes. Prenons, par exemple, le cas dun disque o seffectuent des sauvegardes, et qui serait plein. Suivant la manire dont se fait la sauvegarde, limpossibilit dcrire les fichiers sur le disque peut empcher lapplication de redmarrer ensuite soit un problme bien plus grave que le problme de disque au dpart. Avec une alerte adquate, ladministrateur serait au courant de ltat du disque au bon moment, pourrait procder un nettoyage, et permettre la sauvegarde de seffectuer correctement.

Un historique pour remonter la source des problmes

Lorsquun administrateur tente de rsoudre un problme, il saperoit parfois que celui-ci est caus par un autre lment dfaillant, et ainsi de suite. Cest notre fameux effet domino. Aucun utilisateur ne permet de remonter cette chane derreurs. Un outil de supervision permet de conserver un historique des alertes. Ladministrateur peut alors regarder les incidents qui se sont produits juste avant le problme constat et ainsi facilement remonter la source. On peut reprendre ici le cas de notre sauvegarde bloquante. Ladministrateur arrive le matin avec une application non disponible. Il regarde dans loutil de supervision depuis quelle heure elle est dans cet tat. Il saperoit alors que, peu de temps auparavant, il y a eu sur ce mme serveur une alerte de disque plein. Il fait alors le lien et rsout le problme rapidement.

tre proactif face aux problmes

Vritable leitmotiv des administrateurs, la proactivit passe bien sr par la supervision.

10

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Les signes annonciateurs

Certains problmes sont prcds de signes avant-coureurs avant de devenir bloquants. Reprer ces signes est une plus-value non ngligeable des outils de supervision. Les administrateurs peuvent ainsi rgler le problme avant mme quil ne se produise. Bien entendu, il nen est pas ainsi pour chaque problme mais beaucoup dapplications mettent des avertissements lors dune situation anormale. Ceux-ci doivent tre remonts aux administrateurs. Seul un outil de supervision peut accomplir cela. Pour reprendre notre exemple de disque de sauvegarde, avant dtre plein, il a bien d se remplir. Les administrateurs auraient d tre alerts avant le moment critique pour faire du nettoyage et viter lchec de la sauvegarde et la chute conscutive de lapplication...

Les problmes nattendent pas les utilisateurs

Surveiller le systme dinformation y compris pendant les priodes non ouvres prsente bien des avantages. Durant ces priodes, aucun utilisateur nest prsent pour relever les ventuels problmes. Cela ne signifie pas que le systme en est exempt. Ils peuvent tre annonciateurs de problmes futurs, voire en tre la cause. Reprenons, par exemple, le cas dune sauvegarde qui choue faute de place sur le disque, mais qui arrive bien relancer lapplication par la suite ; sans outil de supervision, ladministrateur ne saperoit de rien. Pire, il pense avoir une sauvegarde, ce qui nest pas le cas. Plus grave encore, il peut tre tent deffectuer des manipulations dangereuses en pensant pouvoir revenir en arrire...

Une demande frquente de la direction

tre proactif face aux problmes est une demande croissante de la part des directions des systmes dinformation. On ne peut tre proactif, cest--dire rsoudre les problmes avant mme quils ne se prsentent, qu condition dtre bien inform. Comme on vient de le voir, les outils de supervision sont cruciaux pour atteindre cet objectif. Les administrateurs ont donc tout intrt en utiliser un, qui facilitera leur travail et leur permettra de passer plus de temps sur des actions ayant une vritable valeur ajoute, comme la conception darchitectures plus robustes. Les ressources ncessaires pour mettre en place une telle solution se justifient parce quelle permet, dune part, de rpondre la demande de proactivit et, dautre part, de raliser des gains de temps importants sur lensemble du systme dinformation.

Intrt de la supervision et de la mtrologie CHAPITRE 1

11

Amliorer la disponibilit effective des applications

Les administrateurs ne doivent pas oublier leur rle premier : fournir aux utilisateurs des applications exploitables dans les meilleures conditions.

Les diffrents ressentis vis--vis des performances

Le ressenti utilisateur est trs diffrent de celui des administrateurs quand on parle de performances. Sil est bien connu que les systmes dinformation ne sont jamais assez rapides pour ceux qui les utilisent, il en va tout autrement pour ceux qui les administrent. Certains utilisateurs se plaignent de la lenteur des applications. Si, dans bien des situations, cela est d une mauvaise utilisation du systme (comme une fonction de reporting sur un jeu de valeurs trop important), dans dautres cas, ces problmes sont rels. Sans outil, ladministrateur a beaucoup de mal faire la diffrence entre les plaintes abusives des utilisateurs et les vritables soucis de performance. Un outil de supervision met tout ce beau monde daccord. Il peut remonter des valeurs objectives. Il est possible de reprer trs simplement sil y a une dgradation de la situation par rapport une priode o tout fonctionnait bien ou bien si le ressenti des utilisateurs est en cause. Sans un tel outil, les administrateurs campent sur leurs positions et maintiennent que tout va bien du ct des performances. Les utilisateurs font de mme concernant les lenteurs. Ce genre de situation peut senvenimer trs rapidement. Les utilisateurs peuvent facilement gnraliser toute une application une lenteur ressentie sur seulement quelques crans particuliers.

Grer les priorits : la production avant tout

Les administrateurs ont un objectif clair : le maintien en production du systme dinformation. Cependant, tous les lments ne sont pas logs la mme enseigne en ce qui concerne la criticit. Certaines parties sont vitales pour lentreprise, dautres beaucoup moins. Les utilisateurs auront tendance considrer que tout est critique, ce qui empche dtablir des hirarchies par priorit : si tout est prioritaire, plus rien ne lest. Or les administrateurs doivent traiter en priorit les problmes qui surviennent sur les systmes critiques. Sans outil de supervision, il est quasi impossible pour un administrateur de garder en tte ces diffrents niveaux de criticit. Lorsquun problme survient, ladministrateur doit pouvoir accder cette information trs rapidement et facilement. Il ne peut

12

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

malheureusement pas sen remettre aux utilisateurs pour cela, car ces derniers nont pas de vision globale du systme dinformation et tendent considrer que leur souci est le plus critique de tous. Loutil de supervision peut ainsi aider mettre des priorits sur les interventions des administrateurs et leur permettre de se concentrer sur lessentiel. Avec un taux de disponibilit des applications ainsi pondr par leur criticit, la disponibilit globale du systme dinformation est amliore.

Tailler au plus juste le systme dinformation

Un des rles de ladministrateur est galement de prvoir les besoins futurs afin de dimensionner au mieux le systme dinformation. Sil prvoit trop large, il dpense trop ; sil ne prvoit pas assez, on arrive une situation de contention. Celle-ci peut dboucher sur de trs graves problmes de disponibilit du systme dinformation. Pour effectuer correctement ce travail de dimensionnement au plus juste, il a besoin de connatre ltat rel de la consommation des ressources et une estimation, de la part des utilisateurs, de lvolution des demandes. Cette dernire information est malheureusement une denre extrmement difficile obtenir. Ladministrateur doit tudier lvolution des besoins en ressources sur une priode significative afin dextrapoler et de prvoir au mieux leur volution future. Il a besoin deffectuer des mesures prcises sur diffrents lments du systme dinformation, grce un outil de mtrologie. Cet outil est, dans la plupart des cas, intgr la solution de supervision. Beaucoup dalertes de supervision sont bases sur des mesures du systme dinformation, mesures que lon compare avec des seuils prdfinis. Elles sont utilises pour la supervision, mais peuvent tre rcupres en mme temps par loutil de mtrologie de sorte quune seule interrogation est ncessaire. Linvestissement ralis dans la mise en place dun outil de mtrologie nest jamais perdu puisquil permet, via un dimensionnement juste, doptimiser les investissements. Ce simple gain peut justifier lui seul la mise en place dune solution de supervision / mtrologie. En outre, lamlioration de la disponibilit des applications et donc des performances de lentreprise, sajoute dans la balance en faveur dune telle installation.

Intrt de la supervision et de la mtrologie CHAPITRE 1

13

Surveiller plus que le systme dinformation

Les outils de supervision ont souvent un champ daction qui stend au-del du seul primtre du systme dinformation.

Un ordonnanceur ?
Un outil de supervision nest rien de plus quun ordonnanceur un peu spcial. En gnral, il neffectue pas daction mais juste des vrifications. Il est cependant possible de linstrumenter pour ordonnancer des traitements mais avec des limites vite atteintes puisque ordonnancer des traitements nest pas sa vocation premire. Par exemple, un outil de supervision est spcialis dans le lancement de nombreux petits programmes, chacun rcuprant une valeur, tandis que les ordonnanceurs lancent en gnral un nombre restreint de traitements, mais qui peuvent durer plusieurs heures. Le paramtrage et le comportement de lapplication sont inadapts face une telle utilisation. Cela dit, face au cot important dun outil dordonnancement, il est tentant de laisser cette tche loutil de supervision. Mais cest au risque davoir un service de pitre qualit et de mettre en pril certains traitements, ce qui peut au final se rvler plus coteux. Autre phnomne galement observable sur bien des outils de supervision, leur primtre de surveillance dpasse les limites du systme dinformation. De tels dpassements peuvent tre justifiables ou au contraire ne pas tre pertinents du tout.

Supervision physique dune salle machine

Prenons lexemple de la supervision physique dune salle machine. Celle-ci contient en gnral un systme daccs la salle, une climatisation et un groupe lectrogne autant de systmes en eux-mmes indispensable lensemble du systme dinformation. Il va sans dire que si une personne parvient accder la salle, le systme est en pril puisquil suffirait lintrus de prendre un disque ou une bande pour obtenir des informations confidentielles, en passant outre tous les pare-feux possibles et imaginables. Dans le cas de la climatisation, une trop forte temprature ou une humidit trop leve peuvent tre catastrophiques et rendre le systme indisponible. Il en va de mme pour llectricit. Les lments physiques sont donc cruciaux pour le bon fonctionnement du systme. Ils peuvent ou doivent mme tre surveills par loutil de supervision. Cette surveillance dpend, bien sr, de la manire dobtenir les informations importantes comme la temprature ou ltat des batteries du groupe lectrogne. On verra par la suite des exemples dobtention de telles informations.

14

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
Formes dalertes De telles informations (accs, humidit, temprature, panne courant) sont critiques et doivent tre remontes de toute urgence aux responsables de la salle machine. Un simple courrier lectronique nest bien souvent pas suffisant peu de chances en effet que ladministrateur aille consulter ses messages 4 heures du matin. Un SMS envoy sur un tlphone dastreinte aura plus dimpact. Ainsi diffrentes faons davertir sont prvoir dans une solution de supervision. Elles doivent tre tudies avec soin. Des SMS envoys tort nauront pour effet que dinciter les personnes dastreinte ne pas les lire, voire teindre le tlphone.

En un mot
Pour ceux qui ntaient pas dj convaincus, les outils de supervision et de mtrologie sont indispensables la bonne administration dun systme dinformation. Sans eux, ladministrateur est priv de moyens fiables et rapides de vrifier que les lments de linfrastructure et les applications sont oprationnels.

2
Grandes lignes de ltude et de la mise en place dune solution de supervision
La mise en place dun outil de supervision est un projet complexe, dont il faut prvoir et prvenir les plus gros cueils.

Plus quun outil : un projet part entire

Un dfaut courant dans la mise en place dune solution de supervision est de la traiter comme une opration purement technique.

Revoir ses processus

Si la seule mise en place technique de Nagios est rapide, elle limite les avantages que lon peut en tirer. Il ne suffit pas en effet dobserver rapidement les problmes, encore faut-il diminuer leur nombre sur le long terme. Pour cela, il faut coupler loutil de supervision une base de connaissances, qui doit tre renseigne ds quun nouveau problme est rsolu. Ainsi, quelle que soit la personne alerte, elle trouvera depuis loutil de supervision

16

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

un lien vers la mthode de rsolution du problme. Sans cela, les administrateurs risquent fort de perdre du temps rsoudre un incident qui sest dj produit sans oublier que cela prive lquipe dans son ensemble dun moyen de progresser. Il en est de mme concernant la mtrologie. Si les administrateurs ne lutilisent que pour observer les ressources sur les dernires minutes, elle perd son intrt face la supervision. Il faut que les administrateurs lutilisent dans son vrai rle, savoir celui dun outil permettant dobserver lvolution des ressources sur des priodes longues de plusieurs mois. De manire gnrale, loutil de supervision permet doptimiser une grande partie des processus des quipes. Il faut que la mise en place dun tel outil soit prcde dune vritable analyse de ces processus et, en tout premier lieu, ceux qui concernent la gestion de la base de connaissances ou le calcul des besoins futurs.
REMARQUE Une entreprise complexe
Les administrateurs de doivent pas se leurrer : la russite du projet de supervision sera autant technique quorganisationnelle. Si ce dernier point nest pas lactivit prfre de la majorit des amoureux de la technique, ce projet pourrait les rconcilier avec cet aspect de leur mtier.

Une rpartition de la charge de travail

Avec la mise en place dun systme de supervision, les administrateurs de back office peuvent dlguer une partie des rsolutions au front office . Ils rdigent les mthodes de dtection de problmes dans loutil de supervision et leur rsolution dans la base de connaissances. Une fois quun problme est dtect, les autres administrateurs ont alors toutes les informations pour le rsoudre. Cela dcharge les administrateurs de dernier niveau qui peuvent alors rdiger des rgles de dtection de plus en plus prcises afin damliorer le systme dinformation. Cest un cercle vertueux qui prend sa source dans la mise en place de la supervision et la refonte des processus.

La supervision doit voluer avec le SI

Un systme informatique, tout comme un tre vivant, volue. Le systme de supervision doit voluer avec lui. Pour ce faire, dans chaque futur projet, ou la mise en place de tout nouvel outil, une partie ddie la supervision doit tre prvue. Elle permettra de reprer rapidement les nouveaux problmes que vont devoir affronter les administrateurs.

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

17

Ainsi le processus de mise en place des outils doit tre adapt. Si tous les outils ne ncessitent pas une supervision, les plus importants doivent tre sous surveillance, mme sommairement. Il est cependant prfrable de superviser lensemble de son portefeuille dapplications et linfrastructure qui le sous-tend.

Un outil faisant le lien entre les services

Les relations avec la matrise douvrage peuvent galement samliorer grce la mtrologie. Il est possible de mesurer les temps de disponibilit des applications et les temps de rponse. On peut alors rdiger un contrat entre services. Bien entendu, un tel contrat doit se faire avec laval de la direction et sans prcipitation. Ce sont des dcisions fortes qui peuvent influer sur lavenir et sur le budget dun service informatique.

Une mise en place progressive

Il est conseill de surveiller lensemble du systme dinformation. Il est cependant vivement dconseill de mettre en place la totalit de la supervision en une seule opration. Faire accepter loutil sera srement plus complexe que le mettre en place. Il faut commencer par une partie restreinte du systme dinformation et tendre la porte de loutil petit petit au reste du systme. Chaque tape prend en charge de nouveaux lments, de nouvelles applications et enfin de nouveaux utilisateurs. Si la mise en place est trop brutale, les initiateurs du projet risquent de se mettre dos les administrateurs ce qui terait tout son intrt au projet. Nous verrons par la suite des mthodes pouvant amliorer lintgration de loutil au sein de lquipe et faire du projet un vritable succs. Il nest pas possible de prvoir tous les incidents que les administrateurs peuvent rencontrer ds la mise en place. Certaines erreurs passeront entre les mailles du filet de la supervision pendant toute la dure de vie de la solution. Il faut alors que le processus damlioration joue son rle : loutil doit tre mme de dtecter cette erreur si elle se reproduit. Une fois la rgle de supervision ajoute, si lerreur refait surface, elle est dtecte rapidement. Il est ncessaire que les bonnes personnes soient averties. Lorsquun nouveau problme est rencontr, il est examin par diffrents administrateurs avant dtre rgl. Il faut quun groupe en prenne la responsabilit et soit averti sil se reproduit. Si la base de connaissances est correctement remplie, le problme peut tre rgl trs rapidement voire de faon automatise, si cest possible. Cest alors tout le service informatique qui sest amlior, et ce principalement grce aux nouveaux processus rendus possibles par la mise en place de la supervision.

18

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

La tentation de tout superviser

Avec un outil performant et souple, il est trs tentant de superviser des lments qui ne lauraient pas t en temps normal. Cela peut tre bnfique dans certains cas. On a vu que lon ne peut pas prvoir toutes les erreurs possibles qui peuvent survenir sur un systme dinformation. Il vaut mieux alors avoir trop dindicateurs que pas assez. En cas de problme inconnu, lun des indicateurs pourrait savrer utile pour lidentification du problme. Il ne faut cependant pas exagrer. En plus de consommer des ressources de calcul et de lespace, cela demande du temps de mise en place. Si un indicateur napporte aucune information par rapport un autre dj en place, il ne faut tout simplement pas le surveiller. On verra par la suite des exemples dindicateurs indispensables sur les principaux systmes et comment on peut en tirer des informations prcieuses.

Faire accepter le projet de supervision ses suprieurs

Nous insistons sur la ncessit davoir laccord de la direction avant toute mise en place ou revue des processus de lquipe dadministration. En effet, rappelons que la solution de supervision est trs structurante en termes de processus pour le service informatique. Le premier objectif est donc de trouver des arguments permettant de faire accepter cette mise en place. Nous avons dj voqu les amliorations des processus et de la disponibilit des applications. Il sera bon de rappeler les possibilits de rduction de cot grce la mtrologie. Si tout cela parat trop abstrait ou trop complexe quantifier, il reste la possibilit dtre plus explicite et de proposer la mise en place dcrans de supervision pour lassistance de premier niveau le cas chant. En cas de soucis importants, les administrateurs de niveaux 2 et 3 ont rarement le temps davertir le premier niveau quun incident est en cours. Les personnes de lassistance de premier niveau sont alors dmunies face aux questions des utilisateurs. Grce des crans de supervision en revanche, elles peuvent sapercevoir directement des problmes et peuvent indiquer aux utilisateurs que le problme est pris en compte. Il faut rappeler galement le gain de productivit quapportera loutil aux administrateurs, qui pourront, grce la base de connaissances, dlguer dautres une partie de leur charge rcurrente de rsolution de problmes. Enfin, pour la mise en place de priodes dastreinte, loutil de supervision vite davoir faire appel un prestataire externe qui peut se rvler trs onreux un dernier argument pour achever de convaincre les directions les plus frileuses.

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

19

Faire accepter loutil par le plus grand nombre

Une fois que le projet est dot dun budget et de lappui de la direction, il faut le faire accepter par les quipes dadministrateurs. Ce nest pas aussi simple quil y parat. Mme si loutil permet damliorer leurs conditions de travail et leur efficacit, il souffre principalement de son image : en tant quoutil de supervision, il peut tre interprt comme un outil pour superviser... les administrateurs plutt que les systmes ! Abordons les points risquant dtre un frein une forte adhsion autour de loutil, et voyons comment les contourner.

Intrt de faire adhrer toute lquipe loutil

Il est crucial de faire participer le plus dadministrateurs possibles au projet. Seul un administrateur responsable dune partie du systme dinformation peut identifier correctement les causes et consquences dun problme. Sil ne prend pas part la vie de loutil, il ne rentrera pas dans le processus damlioration et gardera pour lui tout ce quil administre. Il peut ainsi y avoir, cause dune personne hostile au projet, un pan entier du systme mal, voire non supervis. Cela met en danger la capacit remonter efficacement la source des problmes, mme si les autres parties sont supervises.
MTHODE Amener et conduire le projet
La mise en place de la solution de supervision ne doit pas tre impose aux autres membres de lquipe. Plus que pour nimporte quel projet, celui-ci doit tre annonc trs tt et inclure le plus de participants possible.

Limiter le nombre dalertes et les hirarchiser

Labandon face un trop grand nombre dalertes : une raction naturelle
Il est primordial dans une solution de supervision de chercher limiter au maximum les alertes que reoivent les administrateurs. Personne naime arriver le matin et dcouvrir dans sa boite plus de 200 messages dalertes. Si, au dmarrage, un administrateur courageux cherche tous les lire, mme sil fait partie des plus persvrants, il finira par tre dcourag et par supprimer lensemble des messages. Il faut prvoir et prvenir cette raction bien humaine.

20

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Rendre trs clair le niveau dimportance de chaque alerte

Il faut galement quun administrateur sache, au premier coup dil, si les informations du message sont importantes ou pas. Il nest pas agrable de devoir tout lire pour avoir une ide de la situation. Un administrateur ne lit quune partie des messages, et ne lit que le titre des autres. Si le sujet du message est bien pens, la personne est informe rapidement et sans risque de perdre dinformations importantes. Il faut que loutil puisse noncer dans le titre les informations principales : ce sur quoi porte lalerte, et sa criticit. Ladministrateur press dispose ainsi des informations les plus importantes pour choisir les messages quil doit lire.

Alerter uniquement les bonnes personnes

Chaque alerte doit tre rapporte aux administrateurs intresss, et uniquement ceux-l. Dans le but de rduire le nombre dalertes reues par chacun, il est normal de nenvoyer que ce qui est ncessaire chaque administrateur. Cela leur permet de se sentir moins observs par loutil. Sils sont les seuls recevoir linformation, ils ont le sentiment de mieux pouvoir la contrler. Ils ne partiront pas en guerre contre loutil. Les responsables saffolent ds quils voient une couleur rouge sur un cran, mme si en fait lalerte nest pas si importante que a. Ils ne cherchent pas, en gnral, les causes profondes du problme, quils veulent rsolu au plus vite. Il faut donc passer en priorit par les administrateurs qui peuvent qualifier correctement le problme. Il sera rapport si besoin aux autres membres de lquipe dadministration.

Pour un problme donn, une alerte, et une seule

Toujours dans le but de diminuer le nombre dalertes reues, il faut mettre en place un filtre qui permet de navoir quune seule alerte par problme. Si un problme engendre dautres soucis, les administrateurs risquent de recevoir une cascade dalertes dclenches par un seul incident. En plus dencombrer leur messagerie, cela ne peut que ralentir considrablement la recherche de la cause initiale du problme, noye parmi un nombre incalculable derreurs. Ladministrateur risque alors dabandonner la masse dinformations, inexploitable en raison de sa taille, et de sen remettre aux anciennes mthodes de dpistage de problmes, bien plus chronophages. Do limportance de bien configurer loutil pour quil ne reoive quune seule alerte qualifie, indiquant directement o et comment rsoudre le problme. La facult signaler rapidement lorigine des problmes est un critre primordial dans le choix dun outil de supervision. dfaut, les quipes risquent de ne pas utiliser les informations remontes et dabandonner doucement loutil, rduisant nant tous les investissements raliss dessus.

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

21

DANS LA VRAIE VIE Cas des pannes dquipements rseau

Le cas des pertes rseau est tout particulirement important ici. Si on prend le cas dun systme dinformation rparti sur plusieurs lieux, la perte dun quipement distant met en erreur toutes les vrifications de la zone. Cela gnre potentiellement un nombre important dalertes. Il faut donc que loutil de supervision soit prpar ce genre de situations et quil signale uniquement le problme de connexion en omettant les autres alertes qui en dcoulent. Bien sr, ces dernires doivent quand mme tre signales sur la console dadministration. Mais loutil ne doit pas avertir ladministrateur dun problme auquel il ne peut rien.

Lautomatisation complte : rgler automatiquement les problmes?

Une des possibilits offertes par les outils de supervision consiste lancer une action correctrice lors des problmes. Bien sr, cest ladministrateur de fournir la commande de rsolution. Cette fonctionnalit semble trs allchante. Bien employe, elle permet de diminuer sensiblement les tches rcurrentes de rsolution de problmes. Malheureusement, elle a galement des inconvnients qui peuvent se rvler de taille, pouvant anantir en un rien de temps lconomie ralise prcdemment. En effet, si laction correctrice est mal adapte, elle peut gnrer de gros dgts. Mme si ce genre de situation narrive pas frquemment, au final les effets de bord nfastes peuvent excder de loin les gains attendus... Supposons quun arrt de service soit prvu et que ladministrateur ait oubli davertir loutil de supervision. Ce dernier va tenter de rparer la situation et faire redmarrer le service. Suivant les actions que sont en train deffectuer les administrateurs, le redmarrage inopin peut au minimum se rvler ralentissant, au pire provoquer de graves pertes de donnes.
DANS LA VRAIE VIE Pas de rparation automatique sur les clusters !
Le cas des montages de systmes de fichiers en cluster actif/passif est un exemple o il ne faut surtout pas mettre en place un tel systme. On peut imaginer que, si un systme de fichiers tombe, on demande loutil de le remonter automatiquement. Cela peut se rvler catastrophique ! Le nud passif prend la main, monte le systme de fichiers et lance ses applications. Le systme de supervision voit un problme sur le nud qui tait actif, et prend la dcision de remonter le systme de fichiers. Si celui-ci prend en charge le montage simultan par deux systmes, cela ne porte pas consquence. Mais dans le cas contraire, ce sont toutes ses donnes qui sont perdues... (Certes, ce cas est extrme, car personne naura lide de mettre un tel systme en place, esprons-le...).

Il faut donc toujours bien rflchir avant dutiliser la possibilit de rsolution de problmes. Si les effets nfastes sont potentiellement plus importants que les gains, il

22

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

faut renoncer la mise en place, mme si leffet nfaste peut ne se produire quune fois dans la vie de loutil. Noubliez pas quen informatique, est une loi immuable du nom de Murphy...

Des indicateurs aussi simples et clairs que possible

Si un administrateur ne comprend pas une alerte, dans la majorit des cas, il la supprimera au lieu de chercher la comprendre. Il faut donc que les messages derreur soient le plus explicites possible. Les titres donns aux alertes sont donc primordiaux.
PSYCHOLOGIE Mnagez ladministrateur au rveil...
Dans le feu de laction, ou le matin avant davoir pris son caf, un administrateur peut avoir du mal comprendre les erreurs. Des alertes trop complexes risquent fort de le mettre de mauvaise humeur, et il risque de maudire loutil ainsi que celui qui la mis en place...

Prenons le cas dun redmarrage de serveur. Lindicateur observer est uptime , disponible sur tous les systmes. Il permet de voir depuis combien de temps le systme est lanc. Si la valeur est infrieure cinq minutes, cest que le serveur vient tout juste de redmarrer. Il faut alors lever une alerte. Mais comment nommer cette alerte ? On pourrait lappeler Uptime , mais ce nom nest pas parlant. Il vaudrait mille fois mieux la nommer simplement Reboot . Un tel message derreur sera directement compris, mme par le plus endormi des administrateurs...
BONNE PRATIQUE Limiter le nombre de caractres des titres dalertes et parler le langage de
ladmin Ce nest pas tant par une contrainte physique de nombre de caractres que par la capacit instantane de ladministrateur embrasser le sens dun titre quil faut en limiter la longueur. Il faut aussi viter lexcs inverse et ne pas hsiter allonger lgrement un titre pour le rendre plus explicite. Dautre part, il faut bien reconnatre que les administrateurs ont leur langage. Pour preuve le cas dune coupure rseau massive due une boucle cause par un quipement dfaillant : la personne qui a lu lalerte a couru vers les administrateurs en pause caf, en criant simplement : Boucle la logistique ! . Autant dire que les administrateurs ont laiss l leur caf et ont couru vers le lieu en question. La formule tait lapidaire mais efficace, les moindre secondes gagnes tant bonnes prendre pour viter que le feu ne se propage davantage.

Bien entendu, tout nest pas simple synthtiser, surtout dans le cas des erreurs. Il faut alors, tout le moins, que ladministrateur ait accs simplement aux informations complmentaires sur les erreurs dtectes. Loutil de supervision doit tre reli la base de

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

23

connaissances de lentreprise. Ladministrateur peut alors simplement regarder la documentation et traduire lerreur en quelque chose quil matrise mieux. Rappelons que cette base de connaissances doit absolument tre remplie rgulirement, y compris pour les indicateurs les plus simples. En effet, ce qui est trivial pour ladministrateur qui soccupe tous les jours de ces environnements ne lest pas forcment pour un nouvel arrivant dans lquipe.
PRATIQUE Un wiki est idal !
Pour la base de connaissances, un simple Wiki fait trs bien laffaire. Commodes et ludiques, les wikis ont le soutien de la plupart des administrateurs. Le logiciel libre MediaWiki, utilis notamment par Wikipedia, est trs simple mettre en uvre et offre un excellent cadre pour constituer une base de connaissances. Il faut cependant veiller la validit des informations dans le temps. Un wiki, par son fonctionnement mme, peut voir cohabiter sur la mme page des informations jour et obsoltes. De manire gnrale, dater la documentation est une pratique encourager. R Barrett, MediaWiki efficace, Eyrolles 2009

Le problme du messager
Il est dans la nature humaine de confondre le message et le messager. Cela peut poser problme dans le cas dune solution de supervision. Celle-ci va en rgle gnrale annoncer de bien mauvaises nouvelles : une application est arrte, un disque est en panne sur un serveur, ou bien ladministrateur na pas prvu assez de ressources sur les serveurs. Le message ntant pas trs flatteur, les administrateurs prennent parfois mal les alertes quils reoivent et considrent alors loutil de supervision comme un oiseau de mauvais augure. Cela peut dgnrer et arriver une situation o ils ne veulent plus couter ce que leur dit loutil et le dlaissent ce qui nest pas souhaitable. Il faut faire comprendre aux administrateurs que loutil est l pour les aider dterminer ce qui ne va pas dans le systme dinformation. Il faut bien leur rappeler que quels que soient leurs efforts, il y aura toujours quelque chose qui ne fonctionnera pas correctement. Il y aura toujours des alertes. Il faut leur faire sentir le plus tt possible les effets bnfiques de loutil, en leur rapportant par exemple les amliorations des taux de disponibilit. Ils verront alors le bon ct de loutil, cens les aider amliorer le systme tout en facilitant leur travail.

Big Brother is watching you ?

Autre problme courant des outils de supervision : tre peru comme un surveillant permanent, un vritable Big Brother des systmes dinformation. Certains adminis-

24

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

trateurs peuvent se sentir mal laise avec ce genre de projet, et feront tout pour faire chouer sa mise en place. Aussi est-il ncessaire de donner un peu despace priv ladministrateur : en ne rendant pas les informations publiques, ce dernier ne se sentira pas surveill et ne freinera pas son bon fonctionnement. Il faut, de plus, lui faire prendre conscience que loutil est en place pour laider et non le superviser, lui. Il est une arme donne ladministrateur contre les soucis quil rencontre tous les jours. Il faut chercher limpliquer davantage dans la dcision de la mise en place, afin quil ne ressente pas quon lui impose un outil, mais plutt quon lui propose une aide lamlioration du systme dans son entier.

La conduite du changement
Autre habitude fcheuse des utilisateurs : voir tout changement comme nfaste. Les administrateurs sont, sur ce point, des utilisateurs comme les autres. La gestion du changement est au cur de chaque projet. Elle doit tre accompagne correctement. Dans le cas contraire, le projet choue ou arrive dans la douleur. Un moyen classique de grer cette situation consiste limiter au maximum les diffrences entre lancien et le nouveau systme. Les utilisateurs retrouvant certains repres, ils sont moins enclins pester contre le changement. Dans le cas du systme de supervision, il faut regarder ce quil y avait avant. Il est rare que des administrateurs naient aucun outil pour observer ltat de fonctionnement des systmes. Si ces outils sont sommaires et disparates, il faut tout de mme en tenir compte et chercher les intgrer au systme de supervision. Grce cela, les administrateurs se sentiront en terrain connu. Ils nauront pas apprendre un nouvel indicateur et ils rsisteront moins larrive du nouvel outil.

Beaucoup dindicateurs de performance, est-ce utile ?

Les indicateurs de mtrologie sont comme les pices dans un plat : sil ny en a pas assez, cest fade ; sil y en a trop, cest curant.

Le nombre dindicateurs est important

Un nombre insuffisant dindicateurs ne permet pas coup sr que lun dentre eux claire sur la cause probable dun problme. Sil y en a trop, les informations risquent dtre en double et, outre le fait que cela prend plus despace et de capacit de calcul, cela fait perdre du temps aux administrateurs lorsquils tentent de chercher des informations prcises. Trouver un juste milieu est ncessaire.

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

25

Quelle dure de conservation des donnes ?

Une autre question se pose quant la dure de conservation des donnes de mtrologie car une telle masse dinformations peut tre complexe grer sur le long terme. On peut faire remarquer quon na pas forcment besoin que les informations soient aussi prcises sur une donne trs rcente (de la journe qui vient de passer) que sur une donne ancienne (du mois dernier). Inutile de revenir sur une valeur prcise du mois prcdent. Si elle ntait pas correcte, cest le rle de lhistorique de la supervision de le dtecter, pas de la mtrologie. En revanche, les volutions sur de longues priodes nous en apprennent beaucoup sur la consommation des ressources et sur leur volution et permettent de tailler correctement les ressources futures en extrapolant partir des variations passes. Les donnes rcentes, quant elles, doivent tre conserves avec une granularit trs fine afin dobserver les valeurs expliquant une alerte rcente. Linformation intresse fortement les administrateurs quand ils cherchent rsoudre un problme par exemple dans le cas dune sauvegarde interrompue car trop longue cause des performances dun serveur. La granularit de conservation doit voluer avec lge de la donne : les valeurs rcentes doivent tre conserves avec un grand niveau de dtail. Concernant les anciennes, la granularit peut tre grossire, car seules les volutions globales nous intressent. Il faut pour cela mettre en place un mcanisme dagrgation des valeurs qui doit tre gr par la solution choisie, sous peine de devoir acheter beaucoup de disques durs lors de sa mise en place.

Des chelles simples

Toujours dans le but de faire adhrer le plus grand nombre dadministrateurs, il faut que la lecture des courbes de mtrologie soit la plus naturelle possible. Les indicateurs doivent tre clairs. Pour cela, les units des axes des courbes doivent tre les plus naturelles possible. Cette solution simple permet aux administrateurs de lire facilement les courbes et de retrouver trs rapidement des indications sur leur pertinence.
PIGE Le rseau, un monde part
Les administrateurs rseau sont des tres particuliers : lorsque tout le monde compte en octets, eux parlent en bits. Ce dtail nen est plus un lorsquil sagit de restituer des courbes ou, pire, de placer des seuils dalertes.

26

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Superviseur mais galement hyperviseur

Les outils de supervision ne doivent pas se contenter dun rle de supervision. Ils doivent galement tre lcoute des autres outils afin de centraliser les informations.

La dure ralit de la supervision

Les discours marketing cherchent tous vous convaincre du contraire, mais la ralit est infaillible : aucun outil de supervision ne peut superviser parfaitement lintgralit de votre systme. Certaines parties ne peuvent tre supervises que par un outil particulier, fourni en gnral par lditeur des applications concernes. Dans cette situation, votre superviseur doit obtenir les informations de loutil en question, qui doit exporter ses informations vers la plateforme. Pour dsigner ce rle de supervision dautres outils de supervision, on parle alors dhyperviseur .

Une seule console de supervision

Il est particulirement peu commode de devoir faire le tour dune dizaine de consoles de supervision diffrentes. La mise en place dun hyperviseur permet de navoir surveiller quune seule console. Dans cette dernire, les informations sont sommaires mais permettent aux administrateurs dtre avertis dun problme. Si besoin est, ils peuvent alors se rfrer aux outils ddis lapplication, la recherche dinformations plus pousses.

Mthodes dobtention des informations

Lobtention des informations de supervision ne peut se faire que de deux manires : soit loutil rcupre activement linformation ; soit il attend passivement quon la lui envoie. Dans le premier cas, la demande peut passer par des intermdiaires, mais cest bien loutil de supervision qui en est linstigateur. Dans le second, loutil nest l que pour recevoir des informations. Il ne contrle ni lenvoi, ni les frquences de rception. Concernant la configuration ncessaire pour ces deux cas, dans la mthode active, loutil a toutes les informations ncessaires, notamment la frquence laquelle faire les demandes. Dans la mthode passive, il ne contrle pas grand-chose. Une partie de la configuration, notamment lordonnancement denvoi, est situe sur les lments distants. Ceci alourdit la configuration car elle est distribue.

Grandes lignes de ltude et de la mise en place dune solution de supervision CHAPITRE 2

27

Cette solution de laisser linitiative loutil tiers ne doit donc tre choisie que si une mthode active nest pas possible.

La modularit : rduire si possible le nombre de superviseurs

Il est prfrable de tout regrouper au sein dun mme outil lorsquil est question de supervision, ne serait-ce que pour limiter la configuration. On privilgie donc une solution qui soit la plus modulaire possible. Elle peut sadapter un maximum de situations. Si elle ne peut pas se substituer parfaitement aux outils ddis, elle renferme peut-tre suffisamment de fonctionnalits pour quils ne soient plus ncessaires. Il nauront alors plus tre maintenus. En rgle gnrale, un nombre restreint dapplications fournissant des informations standard qui sagencent bien, fonctionneront mieux quun grand nombre dapplications avances qui dialoguent mal. Les administrateurs nont pas le temps de se former exhaustivement sur lensemble des outils. Il est alors prfrable de nen matriser quun nombre restreint et den tirer le maximum, plutt que de navoir que des informations sommaires avec des outils sous-exploits.

En un mot
Bien quindispensable, la mise en place dun outil de supervision ne simprovise pas. Si ladministrateur se borne vouloir considrer ce projet dun point de vue purement technique, il est vou lchec. De nombreux obstacles se dressent devant lui, le premier tant que les autres administrateurs peuvent mal vivre larrive de la solution. Des mthodes existent pour diminuer ces problmes. Une fois adopt et intgr aux processus du service, loutil permet damliorer sensiblement la disponibilit du systme dinformation et dallger la charge pesant sur les administrateurs.

3
Choix dune solution de supervision : atouts et fonctionnement de Nagios
Sur quels critres juger une solution de supervision ? Quel est le fonctionnement de Nagios, rfrence open source en matire de supervision ? La mise en place de la solution de supervision devant tre traite comme un projet part entire, commenons par ltude des besoins.

Choix dune licence open source

En ces priodes o les budgets des services informatiques fondent comme neige au soleil, la gestion des licences est de plus en plus contraignante. Les demandes des utilisateurs augmentent et conduisent une accumulation de licences. Les outils de supervision ne font pas exception cette rgle. On peut, dans certains cas, arriver ces situations o seuls les environnements critiques sont superviss, faute de moyens pour acqurir les licences ncessaires aux autres environnements. Cette situation est dommageable la qualit du service fourni aux utilisateurs loutil risque par

30

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

exemple de ne pas tre utilis pour signaler un problme sur un environnement de test avant mise en production. Lutilisation dun outil open source est tout indique dans ce genre de situation.

Le besoin dadaptabilit et de modularit

Le choix dune licence open source permet de rpondre un second besoin : ladaptabilit. Comme nous lavons vu, tous les environnements informatiques sont diffrents. La supervision doit sadapter chaque situation. Elle ne doit pas se comporter de la mme manire sur un petit site que sur un systme rparti sur plusieurs sites distants. Les applications grer sont galement extrmement varies. La modularit de loutil est primordiale pour ne pas laisser de ct tout un pan du systme. Avec un outil de supervision propritaire, dans bien des situations, mme si les administrateurs savent comment superviser un lment non pris en compte, ils ne peuvent pas, contractuellement ou techniquement, lajouter dans loutil. Dans le cas dun outil open source, il ny a pas de limitation. Les administrateurs peuvent ladapter librement.

Transparence du mcanisme de remonte dalerte

Un autre besoin des administrateurs est de savoir comment est recueillie linformation. Les alertes quils ne comprennent pas ne peuvent gure leur inspirer confiance. Sils savent prcisment comment est rcupre linformation, ils la prendront immdiatement en considration. Ils pourront mme essayer de lamliorer. Cest tout lintrt des solutions open source !

De trs bonnes performances

Les systmes dinformation varient en architecture mais aussi en taille. La solution de supervision choisie doit tre performante afin dtre en mesure de grer un nombre important dlments. Il serait dommage de se restreindre cause des pitres performances de loutil. Bien videmment, toute solution a ses limites, ne serait-ce quen raison des limitations des serveurs. Loutil doit dans lidal proposer des mthodes de rpartition de charge sur plusieurs serveurs.

Mise en commun des expriences

Le phnomne de communaut est galement important. Si chaque systme dinformation se distingue des autres, les diffrences ne sont gnralement cantonnes qu

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

31

une partie restreinte. Les systmes ont, en gnral, de nombreux points communs et doivent tre superviss de la mme manire. Au sein dune communaut dutilisateurs, il est possible de partager et de rassembler les meilleures pratiques de supervision. Ce phnomne de communaut est extrmement marqu lorsquil sagit doutils open source car tout le monde peut participer la conception de lapplication, et chacun peut apporter son exprience dans la supervision dun lment particulier et en faire profiter lensemble de la communaut.

Critres de slection dun projet open source

Le monde du logiciel libre est vaste. Comment sy retrouver parmi les nombreuses solutions qui existent et trouver celle qui rpond au mieux ses besoins ?

Un monde particulier, avec ses propres rgles

Lorsquon arrive dans le monde de lopen source, on perd un peu ses points de repres. Il nest en gnral plus question dditeur, mais de communaut dutilisateurs et de dveloppeurs. Ce changement peut tre dur apprhender. Il est difficile de savoir comment tout ceci peut fonctionner correctement face aux solutions propritaires soutenues par de grands diteurs. Il est courant davoir initialement certaines craintes quant lassistance dont on va pouvoir bnficier. Chaque projet open source part en gnral dun petit groupe de personnes (parfois une seule) qui souhaite rpondre un besoin particulier. Dans notre cas, le but de loutil est de superviser les systmes dinformation. Une fois loutil dans sa premire version, un groupe dutilisateurs ladopte. Cette premire priode est critique. Si la solution napporte pas de rponse innovante aux problmes rencontrs, elle ne va pas rassembler un grand groupe dutilisateurs. Or ce groupe est vital dans lcosystme de loutil : cest la communaut. Une petite partie de ces utilisateurs deviennent galement dveloppeurs et ils aident les auteurs amliorer loutil. Les autres utilisateurs, quant eux, peuvent crire de la documentation ou remonter des bugs directement aux dveloppeurs.

Importance de la communaut
La solution ne peut progresser que si elle possde une grande communaut. On peut parler de masse critique dutilisateurs pour quune solution devienne une rfrence dans le monde de lopen source. Les solutions non innovantes nont pas beaucoup dutilisateurs et priclitent.

32

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Une fois quune solution est trs prsente au sein de la communaut, vient la phase o les entreprises commencent sy intresser : se pose alors la question de lassistance.

Assistance aux entreprises

Lassistance est fournie par des socits spcialises regroupant des personnes trs sensibles la philosophie de lopen source. Celles-ci ont une forte exprience de loutil et peuvent ladapter si besoin. Ces modifications peuvent alors, si le client est daccord, tre remontes aux dveloppeurs de lapplication, en vue dune inclusion dans la version officielle. Lentreprise cliente a tout intrt accepter. Si les modifications sont reportes dans la version officielle, de nombreux utilisateurs peuvent alors les utiliser et, le cas chant, dtecter des bugs et proposer des solutions de contournement.
PRATIQUE Ne pas hsiter demander de laide
Les salaris des socits de conseil en logiciel libre sont souvent des passionns. Il ne faut pas hsiter faire appel eux. Ils peuvent faire gagner un temps prcieux aux administrateurs.

Les solutions de supervision open source ne font pas exception la rgle. Elles sont soumises, comme toutes les autres, aux rgles de lopen source et de la communaut. Le rle de la communaut est mme plus important pour une solution de supervision (qui est confronte des situations extrmement varies) que pour la plupart des autres outils open source.

Le choix de Nagios
Si lon retient tous ces critres dans le choix dune solution open source stable, performante et ayant une forte communaut, Nagios sort largement vainqueur. Cette solution est en effet la rfrence en matire de supervision dans le monde de lopen source.

Histoire de Nagios
Lhistoire dun outil peut nous en apprendre beaucoup sur lui. Nagios est dvelopp par Ethan Galstad et dbute son histoire en 1999 sous le nom de NetSaint. Quelque temps plus tard, cause dun problme de proprit intellectuelle sur le nom, il devient Nagios. Actuellement en version 3.1, il a plus de neuf ans dexistence. Comme nous le verrons par la suite, il se bonifie avec lge, limage dun grand vin.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

33

Il a volu depuis ses tous dbuts afin de sadapter des parcs de plus en plus importants, tout en amliorant ses performances et ses capacits de gestion de configuration.

Nagios ne fait rien sans ses plug-ins

Il est le digne hritier du principe KISS (Keep It Simple, Stupid) dUnix : il ne fait quune chose, mais la fait bien. Son rle est dordonnancer les vrifications sur les lments superviser et de lancer une alerte si besoin. Il ne fait rien dautre, pas mme aller vrifier lui-mme ltat des lments surveiller. Ceci peut paratre tonnant, mais Nagios ne sait rien faire tout seul. Il ne peut mme pas vrifier le bon tat du serveur sur lequel il est hberg. Son auteur a en effet considr quil ne pouvait prvoir toutes les vrifications quun tel outil doit intgrer. Il a donc dcid de nen mettre aucune au sein de Nagios et de laisser la responsabilit des vrifications des plug-ins que lutilisateur devra fournir loutil.
COMMUNAUT Utiliser au maximum lexistant
Que le lecteur se rassure, il existe dj un nombre trs important de plug-ins. Fruits du travail de toute la communaut Nagios, ils vitent ladministrateur de devoir se transformer en dveloppeur pour avoir une solution efficace. Ce sujet sera trait en profondeur par la suite.

Position de Nagios par rapport la mtrologie

Si on applique le principe de modularit la mtrologie, celle-ci ne doit pas tre gre directement par le mme outil que celui charg de la supervision. Cest pourquoi Nagios ne gre pas les donnes de mtrologie, mais les rcupre et les transmet un outil ddi. Nagios rcupre les donnes car, dans beaucoup de situations, les alertes sont dfinies par une comparaison entre les donnes mesures et des seuils dfinis par lutilisateur. Vu que Nagios doit rcuprer cette valeur via un plug-in, il serait dommage quun outil de mtrologie doive aller la chercher une seconde fois. Nagios va simplement exporter les donnes dans un fichier plat qui sera ensuite lu par loutil de mtrologie. De cette manire, lutilisateur peut choisir loutil de mtrologie quil souhaite.

34

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Atouts de Nagios par rapport aux autres outils open source

Nagios nest pas le seul outil de supervision open source. Par rapport ses concurrents, sa plus grande force rside dans sa modularit complte. Il na pas de domaine de prdilection et peut observer tout ce que ses plug-ins sont capables de rapporter. Dautres outils open source de supervision existent, mais ils ne sont pas aussi modulaires ou performants que Nagios. On trouve aussi sur le march des outils de mme envergure, mais non compltement libres.

Zabbix : la supervision simplement

Ce premier outil est trs orient systme et soccupe en interne de la mtrologie. Il nest pas aussi modulaire que Nagios. Il est beaucoup plus orient tout-en-un, avec des agents ddis quil faut dployer sur les lments distants. Si ce choix permet de gagner du temps lors de la premire mise en place, il se rvle gnant lorsquil sagit de superviser des lments non prvus par la solution. Quant aux possibilits de configuration elles sont moins toffes que celles de Nagios, ce qui peut tre contraignant lorsque le nombre dlments commence devenir important. Il manque Zabbix des solutions simples pour grer les pertes massives de connexion et tout ce qui concerne la gestion des dpendances entre lments. Ce dernier point est, encore une fois, problmatique lorsque la supervision couvre un nombre lev dlments.

Cacti : la mtrologie avec SNMP

Cacti, quant lui, est bien plus orient rseaux et mtrologie. Il repose principalement sur lutilisation du protocole SNMP trs rpandu dans le monde des rseaux. La supervision nest pas le rle premier de Cacti. Elle est base principalement sur des indicateurs qui doivent rester en de de seuils fixs. Nagios prfre laisser le choix au plug-in de se baser ou non sur des valeurs. Cacti est cependant trs efficace dans la gestion des donnes de performances. Cest pour cela quil est parfois utilis pour grer les donnes issues de Nagios.
Nous utiliserons pour la mtrologie plutt une mthode base sur Centreon, qui sintgrera plus naturellement dans la solution globale que nous mettrons en place par la suite.

OpenNMS : la supervision trs SNMP

Cet outil de supervision est globalement moins avanc que Nagios. Sa configuration est trs lourde grer, mme lorsque le nombre dlments superviss est rduit. Il ne

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

35

possde pas de fonctionnalit de gestion des dpendances, ce qui reprsente un handicap lourd dans les environnements complexes. Hors des tests SNMP classiques, OpenNMS est trs vite limit. Il est possible dinclure des tests supplmentaires, mais cest une solution relativement lourde grer.

Ganglia : la mtrologie des clusters

Ganglia est ddi la mtrologie des performances pour les environnements de type cluster. Il est conu pour minimiser son impact sur les machines supervises. Il nest pas aussi modulaire que Nagios et ne gre que trs mal les parcs htrognes. Il nest pas ax supervision mais bien mtrologie et ses possibilits dalertes sen ressentent fortement.

Zenoss : trs bonne supervision, mais pas compltement libre

Concurrent trs srieux de Nagios, il a comme particularit de ne pas tre compltement libre. L o Nagios est entirement en GPL, Zenoss est disponible sous trois versions diffrentes, dont deux non libres et soumises licences. La version libre est assez limite dans ses possibilits. Les fonctionnalits de haute disponibilit ou de supervision des environnements virtualiss ne sont tout simplement pas accessibles dans cette version. Si les versions sous licences possdent des avantages face Nagios, comme la possibilit native davoir une dcouverte du rseau, elles sont moins avances sur certains points tels que lenvoi dalertes, limit aux e-mails et aux SMS, ou, linstar de Zabbix, sur les possibilits de configuration qui restent limites. Zenoss ressemble fortement Zabbix au sens o il gre aussi lui-mme la mtrologie et propose une interface web complte, l o Nagios dlgue ces aspects des outils tiers.

Orientation vers une totale modularit : tout est plug-in

Rappelons que la force principale de Nagios rside dans sa modularit.

La modularit de Nagios : le rle des plug-ins

Nagios laisse la supervision des plug-ins, ou sondes, que va lui fournir lutilisateur. Il se contente de les lancer et de grer les informations recueillies par ce biais. La communaut fournit la plupart de ces plug-ins. Ils couvrent, en rgle gnrale, plus de 95% des besoins des utilisateurs. En outre ils voluent au fil du temps afin de grer de plus en plus de systmes. Leur conception est trs simple, comme nous le verrons par la suite. Cette simplicit permet aux non-dveloppeurs dapporter leur pierre ldifice. Cette facilit dadaptation a un autre avantage majeur : elle permet de capitaliser sur les scripts de vrifi-

36

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

cation dj mis au point et utiliss par les administrateurs avant la mise en place de Nagios. La plupart du temps, changer une seule ligne suffit les rendre compatibles avec Nagios. En effet, les rgles de Nagios sont standards dans le monde des administrateurs et bien des scripts dadministrateurs sont dj compatibles avec Nagios. Cest cette capacit dadaptation qui a fait de Nagios la solution la plus prise dans le monde de lopen source. La communaut qui sest forme autour est la plus importante en matire de supervision open source. Les administrateurs nayant pas besoin dtre dveloppeurs, le nombre de scripts de vrification proposs par la communaut est vritablement impressionnant. La communaut sest organise afin de fournir le plus simplement possible aux utilisateurs les plug-ins dont ils ont besoin. Ces plugins sont galement open source.

Des plug-ins pour avertir ou ragir

Nagios permet galement de dfinir des plug-ins qui vont alerter les utilisateurs en cas de problme, ce qui permet dtre inventif en matire davertissement. On peut penser de suite aux e-mails, mais nous verrons par la suite que beaucoup dautres possibilits soffrent nous. Lorsque quelque chose se passe mal, dautres plug-ins peuvent tenter de corriger le problme. Il nest pas possible de prvoir tous les cas de rparations possibles, sinon ladministrateur naurait plus de raison dtre. Il est donc prfrable de lui laisser le soin de dfinir lui-mme les commandes pour rsoudre le problme sur son environnement.

Capacit grer un parc important de machines

Nous avons vu quun outil de supervision doit pouvoir grer des parcs importants. Sur ce point, trois critres principaux entrent en jeu : 1 les performances ; 2 la gestion de la configuration ; 3 les pertes massives.

Performances de Nagios
En matire de performances, Nagios na rien envier aux outils de supervision propritaires. Il permet, avec un serveur modeste, de surveiller prs de 10 000 lments. Si cette performance est dj tout fait honorable, Nagios propose des options pouvant sensiblement augmenter cette valeur.
Nous les verrons au chapitre 9, ddi aux performances.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

37

Larchitecture mme de Nagios permet de surveiller autant de nuds que souhaite lutilisateur. La supervision peut tre distribue entre plusieurs serveurs, tout en centralisant ladministration sur une unique console.
Cela sera tudi plus en dtail au chapitre 10.

Gestion de la configuration
Un point dlicat concernant la plupart des outils dadministration, mais touchant tout particulirement les solutions de supervision, est la gestion de la configuration. Plus on a de points surveiller, plus la configuration devient lourde, avec les risques, si elle devient trop dure grer, dtre laisse de ct. Nagios propose diverses solutions pour faciliter la gestion dun nombre lev de points surveills, et cest mme une de ses grandes forces !
Nous verrons au chapitre 8 toutes les techniques de configuration permettant de grer simplement et sans efforts un nombre impressionnant dlments.

REMARQUE Des possibilits rarement mises en avant

Les options de configuration sont rarement prsentes sur les captures dcran vantant les produits. Cest pourtant un point capital que doivent prendre en compte les administrateurs. Aprs tout, la configuration des outils repose sur eux...

Pertes massives : la solution des dpendances

Les systmes informatiques modernes sont vastes. La plupart des lments sont relis entre eux et, si lun deux rencontre des problmes, ceux-ci se rpercutent sur dautres lments. Dans le cas des grandes architectures, de petits problmes peuvent vite devenir un vritable cauchemar. Partant dune simple erreur, on atteint au final un nombre impressionnant dalertes. Si loutil de supervision ne gre pas ce genre de cas, les utilisateurs auront toute les peines du monde trouver, parmi toutes ces alertes, la cause initiale du problme. Nagios gre ces cas grce aux relations de dpendances. Ces relations peuvent tre physiques (par exemple pour les liens rseau) ou bien virtuelles (comme cest le cas entre une application et sa base de donnes). Il permet de filtrer les alertes pour avoir uniquement celles qui apportent des informations sur la rsolution du problme.
Cela sera vu plus en profondeur au chapitre 6 sur la gestion des alertes et leur pertinence.

38

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Architecture gnrale
Un outil de supervision peut paratre un monstre de complexit lorsquon commence ltudier : il nen est rien. Le fonctionnement de Nagios est trs simple... condition den tudier les parties une par une. Ladministrateur dfinit la configuration de Nagios dans des fichiers plats. Nous tudierons par la suite leur structure. Nagios est un simple programme crit en langage C. Si on exclut la partie interface web de visualisation, il ne fait pas plus de 60 000 lignes de code, ce qui est assez faible pour un outil dune telle renomme. Nagios se lance en tant que processus darrire-plan sur un serveur Unix, GNU/ Linux de prfrence. Il lit la configuration fournie par lutilisateur et commence ordonnancer ses vrifications. Lorsquil saperoit dune erreur sur un lment supervis, il notifie les utilisateurs concerns.

Mthodes dobtention dinformations

Nagios doit obtenir des informations. Regardons les diffrentes mthodes quil emploie.

Mthode active les alertes linitiative de Nagios

La mthode de supervision qui, pour la plupart des utilisateurs, parat la plus naturelle est la mthode active. Celle-ci consiste faire lancer par Nagios une commande qui va vrifier ltat dun lment distant. Pour cela, lutilisateur doit fournir Nagios, dans la configuration, les commandes lancer pour effectuer ces vrifications. Ces commandes correspondent des scripts ou des excutables dposs sur le serveur de supervision : ce sont nos sondes. Nagios va simplement les lancer intervalles rguliers et recevoir en rsultat ltat de llment surveill. Pour lancer cette vrification, Nagios se ddouble et lun des deux Nagios rsultant lance la commande demande. Il peut fournir la commande des arguments particuliers, afin que celle-ci interroge le bon hte distant. Une fois que le plug-in a linformation, il la traite et dcide si elle est correcte ou non. Il renvoie enfin le rsultat au premier Nagios.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

39

Obtention sans rebond

La technique sans rebond consiste aller chercher linformation de manire directe, sans passer par des intermdiaires. On peut, par exemple, dcider de vrifier directement si un port rseau est ouvert sur un serveur.

Obtention avec rebond

La mthode avec rebond consiste demander un autre lment de faire la vrification notre place. Ceci se justifie, par exemple, pour des raisons de scurit ou bien de performances. Effectuer soi-mme la vrification peut tre consommateur de ressources. On peut demander un autre membre du rseau de prendre en charge une partie du travail. Lorsque laccs certaines zones du rseau nest autoris que pour certains membres, ce sont eux qui vont pouvoir faire les interrogations en lieu et place du serveur central.
PRATIQUE viter les rebonds autant que possible
Fonctionner avec des rebonds demande plus de configuration que fonctionner sans. Il est conseill dviter, dans la mesure du possible, ce genre de fonctionnement.

Mthode passive : les alertes linitiative des lments distants

Une autre mthode, moins connue, consiste faire envoyer au serveur central les informations de supervision. Celui-ci na plus qu attendre larrive des informations et les traiter de la mme manire quavec une interrogation active. Cette mthode peut tre justifie pour des raisons de performances ou bien tre particulire certains lments surveills. Certaines erreurs sont complexes vrifier de manire active. On peut prendre comme exemple la supervision des sauvegardes. Elles ne se terminent pas toujours la mme heure et il est donc trs compliqu de dcider dune heure de vrification. Un envoi passif effectu par le script de sauvegarde avertit Nagios de la russite ou non de lopration. Cette mthode est, dans ce genre de situation, beaucoup plus simple mettre en place que la mthode active. En outre, en plus dtre complexe ordonnancer, ce genre de mthode doit vrifier dans les journaux de la sauvegarde si elle sest bien passe ou non la charge de lancer les commandes de vrification pouvant se rvler trs lourde pour le serveur central. La mthode passive est donc plus lgre pour le serveur principal. Il faut tout de mme faire attention car ceci a un cot au niveau de la gestion de configuration. Il faut quun lment dcide de lenvoi dinformations. Si ce nest pas Nagios qui le fait,

40

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

ce doit tre llment distant. Lenvoi des informations doit tre planifi et implique une configuration particulire des lments concerns. Ainsi dcentralise, une telle configuration peut tre trs ardue maintenir.

Donnes dfinir dans Nagios

Nous avons parl des lments distants superviser, regardons maintenant les informations dont a besoin Nagios afin daccomplir sa tche. Ces lments devront tre dfinis dans les fichiers de configuration de Nagios. Ces fichiers sont gnralement situs dans le rpertoire etc de larborescence de Nagios, par dfaut /usr/local/nagios. Ils sont construits sur le modle suivant :
Dfinition dun objet type
define type{ parametre1=valeur1 ;commentaire parametre2=valeur2 }

Ici nous voyons la dclaration dun objet type qui a comme valeur valeur1 pour parametre1. Certains paramtres sont indispensables, dautres sont optionnels. Les commentaires commencent par le signe ;.
CONFIGURATION Une exception notable ce modle : define
La seule configuration faisant exception au define concerne celle du dmon Nagios lui-mme. Ses paramtres ne sont pas contenus dans un bloc define mais directement placs les uns la suite des autres. Ils seront tudis tout au long du livre et une annexe en fait le rsum complet.

Nous ne verrons ici que les paramtres obligatoires et les plus importants des paramtres optionnels.

Commandes de vrification
Nagios a besoin quon lui fournisse les commandes responsables des vrifications des lments distants. Ce sont ces commandes qui dterminent ltat des lments distants et donnent linformation Nagios. Elles rcuprent galement les donnes de performances. Pour les dfinir, on doit instancier lobjet fichier commands.cfg.
command.

Ces instances figurent dans le

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

41

Ces objets sont simples et ne comportent que deux proprits : command_name : cest le nom de la commande tel quon va pouvoir lutiliser dans le reste de la configuration Nagios ; command_line : cest la commande que doit lancer Nagios. On remarque dans lexemple ci-dessous une valeur un peu particulire, $HOSTADDRESS$. Cest en fait une macro qui est positionne lors du lancement de la commande par Nagios. Elle peut changer de valeur suivant le contexte. Ici, elle est gale ladresse rseau de llment que lon veut surveiller. Les macros seront tudies un peu plus loin dans ce chapitre.
Exemple de commande
define command{ command_namecheck_tcp command_line /usr/local/nagios/libexec/check_tcp -H $HOSTADDRESS$ -p $ARG1$ }

Arguments des commandes

Les commandes peuvent prendre des arguments, comme cest le cas dans notre exemple check_tcp ci-dessus. Les arguments sont de la forme $ARGn$, n pouvant aller de 1 32. Ils peuvent tre donns lors de lappel de la commande, par un hte ou par un service. Ceci permet, entre autres, davoir une seule dfinition de commande pour vrifier un port TCP et de spcifier, par exemple dans le service, le numro de port que lon souhaite surveiller.

Priodes de temps
Nagios a besoin de savoir quand superviser les lments et quand avertir les utilisateurs. Ces priodes de temps peuvent varier suivant les environnements. Il faut que lutilisateur puisse les dfinir librement.

Dfinition des priodes de temps

Lobjet qui se charge de cela est timeperiod. Ses instances figurent dans le fichier timeperiods.cfg. Cet objet a comme proprits : timeperiod_name : cest le nom qui sera utilis dans le reste de la configuration ; alias : cest un nom daffichage dans les interfaces ; sunday, monday, etc. : pour chaque jour, on peut prciser un intervalle de temps qui sera pris en considration.

42

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Version simple
Les priodes de temps peuvent tre exprimes simplement. Ici, par exemple, les horaires douverture du service :
Priode de travail
define timeperiod{ timeperiod_name workhours alias Work Hours monday 09:00,17:00 ;Lundi tuesday 09:00,17:00 ;Mardi wednesday 09:00,17:00 ;Mercredi thursday 09:00,17:00 ;Jeudi friday 09:00,17:00 ;Vendredi }

Version plus complte

Cette dfinition peut convenir beaucoup dutilisations. Il ne faut pas oublier que, parfois, les utilisateurs ont des contraintes de temps assez complexes. Par exemple, ne pas superviser un lment particulier en milieu de mois, ou alors seulement en fin de mois. Dans ce genre de cas, il faut utiliser les formes avances des priodes de temps. Voici quelques exemples de dfinitions valables au sein de la priode de temps :
Dfinition plus complte
2007-02-01 - 2008-04-01 / 3 00:00-24:00 ;Tous les 3 jours, du 2 fevrier 2007 au 1er avril 2008 2008-06-01 / 700:00-24:00 ;Tous les 7 jours depuis le 1 er juin 2008 day 1 - 15 / 500:00-24:00 ;Tous les 5 jours du 1er au 15 de chaque mois

Comme nous pouvons le voir, les possibilits sont immenses et les utilisateurs vont pouvoir crer des priodes de temps correspondant leurs besoins.
CONSEIL Rester simple
Si les possibilits de configuration des priodes de temps sont grandes, mieux vaut rester simple dans ses premiers essais et les prciser petit petit.

Commandes de notification
Les commandes de notification sont faites pour avertir les administrateurs.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

43

De simples commandes
Les commandes de notification sont des commandes comme les autres. Elles utilisent des macros relatives aux lments superviss, leur tat et aux contacts prvenir. Les macros sont tudies un peu plus loin dans ce chapitre. Les commandes de notification figurent dans le fichier commands.cfg aux cts des commandes de vrifications. Par exemple, pour envoyer un e-mail relatif un vnement sur un hte, nous avons la dfinition suivante :
Commande denvoi de-mail
define command{ command_namehost-notify-by-email command_line/bin/echo "Host $HOSTNAME$ is $HOSTSTATE$" | /bin/mail $CONTACTEMAIL$ }

Bien sr, ceci nest quun exemple simplifi car le-mail na pas de titre et ne comporte que trs peu dinformations. Il manque, par exemple, le texte de retour de la commande de vrification qui a relev le problme ou bien encore lheure laquelle la vrification a t effectue. Nous verrons dans un prochain chapitre comment grer les notifications.
PRATIQUE Un composant indispensable pour lenvoi des e-mails : le MTA
La commande /bin/mail fait appel un MTA (comme PostFix ou Sendmail) prsent sur le serveur de supervision. Ce dernier est responsable du bon envoi des messages. Cette mise en place sera tudie dans un prochain chapitre.

Une grande libert

Les utilisateurs sont libres de dfinir ce quils souhaitent dans leurs commandes de notification. Ceci leur laisse beaucoup de marge de manuvre sur la manire dont ils sont avertis. Si une ligne de commande permet dalerter lutilisateur, il est facile dintgrer Nagios cette ligne de commande en tant que mthode de notification.
PSYCHOLOGIE Rappeler lintrt des avertissements
Les administrateurs se concentrent principalement sur les alertes critiques. Pourtant, les avertissements sont pratiques pour anticiper les problmes. Recevoir ces alertes de basse priorit est le prix payer pour la proactivit.

44

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Htes
galement nomms hosts, nuds ou ressources, ce sont les lments que Nagios supervise. Dans le cadre de la supervision systme, cest le serveur surveiller ; pour la supervision rseau, il peut sagir dun switch. En cas de problme, il alerte un ou plusieurs contacts. Ces derniers seront tudis un peu plus loin dans ce chapitre. Cet lment est la base de la supervision dans Nagios.

tats dun nud

Un hte peut avoir trois tats : UP : il est en tat de rpondre ; DOWN : il est indisponible ; UNREACHABLE : ltat nest pas connu car il est situ, en termes de rseau, derrire un lment qui est tomb. Ce mcanisme sera tudi plus tard.

Dfinition dun hte

Un nud possde des proprits particulires comme son adresse rseau ou bien les personnes contacter en cas de problme. Cest un objet host au sens de Nagios. Ces objets figurent dans le fichier hosts.cfg. Lensemble des proprits indispensables sont les suivantes : host_name : nom de lhte tel quil sera utilis dans le reste de la configuration ; alias : nom qui est affich aux utilisateurs ; address : adresse rseau de lhte ; max_check_attempts : nombre de vrifications que Nagios doit tenter avant de le dclarer rellement DOWN ; check_period : priode de temps pendant laquelle le nud est supervis ; contacts : contacts prvenir en cas de souci ; contact_groups : groupes de contacts prvenir en cas de souci ; notification_interval : intervalle de temps, en minutes, entre les notifications derreur ; si cette valeur est zro, il ne sera envoy quune seule notification ; notification_period : priode de temps applique aux notifications des contacts. Deux autres proprits sont facultatives mais fortement conseilles : check_command : commande qui vrifie ltat de lhte. Elle est optionnelle car, dans certains cas particuliers comme la supervision passive, elle nest pas ncessaire. Ce mcanisme sera tudi au chapitre 7.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

45

notification_options : ce sont les tats des htes qui doivent faire lobjet dune

notification. Si loption nest pas spcifie, Nagios considre que tous les tats doivent tre remonts. Les tats possibles sont : d : lorsquun hte passe en tat DOWN ; u : lorsquun hte passe en tat UNREACHABLE ; r : lorsquun hte revient en tat UP ; f : lorsquun hte commence faire le yoyo (flapping) ; ceci sera tudi plus en dtail dans un autre chapitre ; s : lorsquun hte arrive dans une priode de maintenance dfinie par un administrateur ; n : est utilis si un contact ne veut recevoir aucune notification.

Exemple de dfinition
Dfinissons un hte reprsentant un serveur nomm srv-web1. Il est vrifi avec la commande check-host-alive qui envoie simplement un ping vers ladresse du serveur. Ce test est effectu toute les 5 minutes. En cas de problme, ce test est ritr deux autres fois : la proprit max_check_attempts = 3 = 2 + (1 test dj effectu), sera approfondie dans la suite du chapitre. Si le problme persiste, une notification est envoye au groupe web-admins. Si le problme nest pas rsolu 30 minutes aprs, une autre notification est envoye, et ainsi de suite. Lorsque le problme est rsolu, le compteur repasse zro.
Dfinition dun hte
define host{ host_name alias address check_command check_interval retry_interval max_check_attempts check_period contact_groups notification_interval notification_period notification_options } srv-web1 Serveur Web 1 192.168.0.1 check-host-alive 5 1 3 24x7 web-admins 30 24x7 d,u,r

Le paramtre retry_interval sera tudi un peu plus loin dans ce chapitre. Les htes sont les lments de base de la configuration de Nagios. Ils sont simples dfinir et rpertorier, car ils correspondent aux serveurs et aux lments rseau qui composent le parc.

46

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Services
Les services sont les points superviss sur les htes. Dans le cas dun serveur, il sagira, par exemple, de sassurer du bon fonctionnement dune application particulire, ou bien de vrifier si la charge du serveur est acceptable. Les htes et les contacts alerter sont indispensables dans la dfinition des services.
PRATIQUE Plus que les services
Le terme de service, au sens de Nagios, est plus complet que ce quentendent les administrateurs au premier abord. Un service web est un service, mais il faut bien comprendre quune vrification CPU lest galement. Un service est un point de supervision.

tats des services

Un service peut avoir plusieurs tats : OK : tout va bien pour llment surveill. WARNING : quelque chose commence aller mal comme, par exemple, un disque qui est presque rempli. CRITICAL : la situation est trs grave et demande une intervention immdiate. Cest le cas, par exemple, dun disque plein. UNKNOWN : la commande de vrification na pas pu obtenir les informations souhaites. Par exemple, les arguments fournis la commande ne sont pas bons.

Dfinition dun service

Tout comme les autres objets, les services possdent des proprits indispensables : service_description : nom du service ; host_name : nom de lhte sur lequel se trouve le point surveiller ; check_command : commande de vrification pour obtenir linformation souhaite ; on peut lui fournir des arguments en les sparant par le caractre ! ; max_check_attempts : nombre de tentatives au bout desquelles la situation est considre comme sre ; check_interval : priode entre deux tests en temps normal ; retry_interval : priode entre deux tests lorsquil y a un souci ; check_period : priode de temps durant laquelle le service est supervis ; notification_interval : intervalle de temps entre deux notifications. Tout comme pour les nuds, si cette valeur est zro, une seule notification est envoye ;

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

47

notification_period : priode de temps durant laquelle les notifications sont

envoyes ; contacts : contacts prvenir ; contact_groups : groupes de contacts prvenir. Une autre proprit est importante mais facultative : notification_options : ce sont les tats qui, pour un service, doivent faire lobjet dune notification. Comme pour les htes, si ce paramtre nest pas positionn, tous les tats sont pris en compte. Ces tats sont : w : lorsquun service passe en tat WARNING ; u : lorsquun service passe en tat UNKNOWN ; c : lorsquun service passe en tat CRITICAL ; r,f,s,n : mmes options que pour les htes, mais appliques aux services.

Exemple de dfinition
Dfinissons un service Http vrifiant que le port 80 (HTTP) est bien ouvert sur le serveur srv-web1. Le numro de port est ici pass en argument numro 1 la commande check_tcp dfinie prcdemment. Si la commande avait eu besoin dun second argument, on laurait ajout la suite, en mettant un autre ! entre les arguments. Par exemple check_tcp!80!5, 80 tant $ARG1$ dans la commande et 5, $ARG2$. Il est noter que ceci vaut pour tous les appels de htes galement.
check_command

et donc pour les

Les paramtres contacts et contact_groups nont pas besoin dtre prsents tous les deux. Si un seul est positionn, la dfinition est valide. Cette vrification est faite toutes les 5 minutes. En cas de problme, un test supplmentaire est effectu (max_check_attempts = 3 = 2 + 1 test dj effectu) au bout de 3 minutes. Si le problme est toujours prsent, une notification est envoye aux admins-web. Au bout de 30 minutes, si le problme nest toujours pas rsolu, une autre notification est envoye et ainsi de suite.
Dfinition dun service
define service{ host_name service_description check_command max_check_attempts check_interval retry_interval check_period

srv-web1 Http check_tcp!80 2 5 3 24x7

48

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
notification_interval notification_period notification_options contact_groups } 30 24x7 w,c,r admins-web

Importance des services

Les services sont les vritables objectifs de la supervision de Nagios. Il faut bien retenir que les nuds ne sont prsents que comme support aux services. Les services sont en nombre bien plus important que les htes. Les utilisateurs dfinissent plusieurs services sur les nuds. Un seul service par nud, regroupant toutes les informations, naurait que peu dintrt : en cas de problme, lalerte serait toujours leve avec le mme nom, mme si les soucis nont rien en commun, par exemple une charge trop leve ou un disque plein. Il faut dcoupler les services de sorte qu un service corresponde un problme potentiel.

Contacts : qui et comment ?

Les contacts sont les personnes qui reoivent les notifications dalertes de Nagios. Les htes et les services se voient accrocher des contacts. Nous avons vu quil ne faut prvenir les utilisateurs que pour des incidents qui les concernent. Nagios doit savoir qui prvenir lorsquun problme surgit. Nous allons avoir un contact par utilisateur de Nagios. Les contacts doivent avoir des priodes de notification. Certains souhaitent recevoir les alertes uniquement sur certaines plages horaires. Ceci est tout particulirement vrai lorsquon voque les envois de SMS. Il est inutile que ces messages partent en pleine journe. Certains autres ne veulent recevoir que les alertes critiques et pas les simples avertissements. Tout ceci est possible avec Nagios.

Dfinition dun contact

Les objets contenant les contacts sont tout simplement contact. Ils sont dfinis dans le fichier contacts.cfg et possdent les proprits suivantes : contact_name : cest le nom du contact tel quil sera utilis dans le reste de la configuration. host_notifications_enabled : accepte ou non les notifications concernant les htes.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

49

service_notifications_enabled : accepte ou non les notifications concernant

les services.
host_notification_period : priode de temps o les notifications derreurs sur

les htes sont acceptes.

service_notification_period : priode de temps o les notifications derreurs

sur les services sont acceptes. host_notification_options : tats qui, sur les htes, doivent faire lobjet dune notification. Les valeurs possibles sont les mmes que pour le paramtre notification_options des htes. Ces tats sont : d : lorsquun hte passe en tat DOWN ; u : lorsquun hte passe en tat UNREACHABLE ; r : lorsquun hte revient en tat UP ; f : lorsquun hte commence faire le yoyo (flapping) ; s : lorsquun hte arrive dans une priode de maintenance dfinies par un administrateur ; n : est utilis si un contact ne veut recevoir aucune notification. service_notification_options : tats qui, sur les services, doivent faire lobjet dune notification. Les valeurs possibles sont les mmes que pour le paramtre notification_options des services. Ces tats sont : w : lorsquun service passe en tat WARNING ; u : lorsquun service passe en tat UNKNOWN ; c : lorsquun service passe en tat CRITICAL ; r,f,s,n : mmes options que pour les htes, mais appliques aux services. host_notification_commands : commande de notification qui est utilise pour avertir dun vnement sur un hte. service_notification_commands : commande de notification qui est utilise pour avertir dun vnement sur un service.

Les tats des lments seront tudis un peu plus loin dans ce chapitre. Un autre paramtre important, quoique facultatif, est : email : ladresse e-mail du contact.

Exemple de dfinition de contact

Voici une dfinition de contact. Il se nomme David tout le temps et ce, par e-mail.
Brossart.

Il souhaite tre averti

50

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Dfinition du contact dbrossart

define contact{ contact_namedbrossart aliasDavid Brossart host_notifications_enabled 1 service_notifications_enabled 1 service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by-email host_notification_commands host-notify-by-email email dbrossart@masociete.com }

Plus dune manire de notifier un mme contact

Nous remarquons que service_notification_commands et host_notification_commands sont au pluriel, ceci nest pas anodin. Un contact peut tre averti de plusieurs manires la fois. On peut lalerter par e-mail et par SMS en mme temps.
PRATIQUE Ne pas abuser des alertes
Nous verrons au chapitre 6 comment grer au mieux les notifications. Lune des cls est de ne pas abuser des envois multiples.

La dfinition, dans ce cas, est trs simple : il suffit de dfinir les commandes spares par des virgules :
Dfinition de plusieurs commandes de notification
service_notification_commands notify-by-email,notify-by-sms host_notification_commands host-notify-by-email,host-notify-by-sms

Avec une telle dfinition, chaque envoi de courriel va correspondre un envoi de SMS. Dans ce cadre, il nest pas possible denvoyer les SMS certaines heures de la nuit seulement, sauf si la commande qui envoie les SMS gre les horaires elle-mme. Le plus simple, dans ce genre de cas, consiste dupliquer la dfinition du contact : lune des copies dfinit lenvoi de-mail sur une priode 24x7 et lautre gre lenvoi de SMS sur une priode en heures non ouvres.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

51

CONFIGURATION La commande notify-by-sms

La commande denvoi de message par SMS ncessite des quipements et une mise en place qui seront tudis dans un prochain chapitre.

Groupes de contacts
Il est rare quun administrateur soit seul devoir recevoir une alerte. On peut crer un groupe de contacts dans lequel sont placs plusieurs contacts devant recevoir les mmes alertes. Il est possible de dfinir ce groupe notifier. Linformation sera alors redirige automatiquement vers les membres du groupe. La dfinition est trs simple. Lobjet associ est contactgroup et se trouve dans le fichier contacts.cfg aux cts des contacts. Il ne possde que quatre proprits : contactgroup_name : nom du groupe tel quil sera utilis dans le reste de la configuration ; alias : nom daffichage pour ce groupe ; members : liste des contacts du groupe, spars par des virgules ; contactgroup_members : liste des groupes de contacts faisant parti du groupe.
dmartin

Voici un exemple de dfinition dun groupe de contacts regroupant les administrateurs et dbrossart et incluant galement les membres du groupe admins-linux.

Dfinition dun groupe de contacts

define contactgroup{ contactgroup_name admins-web alias Administrateurs web members dmartin,dbrossart contactgroup_members admins-linux }

Il ne faut pas hsiter dfinir des groupes de contacts. Ils facilitent grandement la configuration des services et de nuds, car il nest pas ncessaire de recopier chaque fois tous les membres des groupes, au risque den oublier de temps en temps.

Plug-ins dobtention dinformations : les sondes

Nous avons dj voqu le fait que Nagios se contente de dlguer la vrification aux plug-ins dfinis dans les commandes de vrification. Voyons maintenant comment sont faits ces plug-ins, galement nomms sondes, et comment ils peuvent renvoyer leurs informations Nagios.

52

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Intrt des codes retour

Un concept important de la programmation shell est utilis par Nagios. tudions dj son fonctionnement, puis comment Nagios lutilise.

Une vrification simple du bon fonctionnement dun programme

Il est trs important pour un programme, lorsquil se termine, de positionner un code retour. Il sagit dune valeur renvoye celui qui a lanc le programme, et qui indique si celui-ci a fonctionn correctement ou sil a rencontr un problme. Ce code est primordial dans les scripts en programmation shell.

Exemple de code retour

Prenons un simple exemple de commande dressant la liste du contenu dun rpertoire : il est possible de savoir, en lisant le code retour de la commande, si elle sest droule correctement ou non. Sous un shell Unix, pour obtenir le code retour dune commande, il suffit de lire la variable $? juste aprs lavoir lance :
Code retour dune commande
user@station:~$ ls /root/ ls: ne peut ouvrir le rpertoire /root/: Permission non accorde user@station:~$ echo $? 2

Nous avons ici une erreur de droits pour la commande ls. La commande est libre de dfinir ce quelle souhaite comme code retour. Nous pouvons dailleurs lire dans le manuel de cette commande :
Exit status is 0 if OK, 1 if minor problems, 2 if serious trouble.

Il est simple de savoir si la commande sest bien droule ou non. Ici nous avons eu un problme srieux, elle a donc renvoy la valeur 2.

Codes retour recommands

Il est courant davoir les codes retour suivants dans le monde Unix : 0 : la commande sest excute avec succs ; 1 : la commande a rencontr un problme mineur ; 2 : la commande a rencontr un problme majeur qui la fait chouer. Ce mcanisme est simple mettre en place. Il suffit de donner la valeur lors de lappel exit qui ferme le programme.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

53

Positionner nos propres codes retour

Voici titre dexemple un programme en bash qui teste lexistence dun fichier :
Vrification de lexistence dun fichier : test.sh
#!/bin/bash if [ -f /tmp/fichier.txt ]; then echo "le fichier existe" exit 0 else echo "le fichier n'existe pas" exit 2 fi

Nous pouvons tester le script et vrifier le code retour obtenu, suivant que le fichier / tmp/fichier.txt existe ou non :
Changement de code retour
user@station:~$ ./test.sh le fichier n'existe pas user@station:~$ echo $? 2 user@station:~$ touch /tmp/fichier.txt user@station:~$ ./test.sh le fichier existe user@station:~$ echo $? 0

Il faut bien noter que cest le programme qui dfinit ses codes retour ; les valeurs 0, 1 et 2 ne sont quune convention quil est conseill de respecter dans la mesure du possible. Ce nest pas obligatoire. Nous aurions trs bien pu dfinir 2 comme code retour normal et 0 pour un code retour anormal.

Aspect supervision de Nagios

Nous avons vu que Nagios se duplique avant de lancer une commande de vrification. Lun des deux Nagios rsultants lance la commande et le premier, quant lui, poursuit ses tches et rcupre le code retour un peu plus tard. Nagios utilise le code retour pour obtenir le rsultat de la vrification. La commande doit positionner correctement son code retour suivant la rponse de llment distant.

54

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Interprtation des codes retour par Nagios

Nous ne serons pas tonns de dcouvrir que Nagios reprend la norme Unix concernant les codes retour. Les tats diffrent suivant que la commande sert vrifier un hte ou un service. Pour les htes, la commande doit renvoyer les codes suivants : 0 : UP ; 1 : UP si la vrification force est active sur lhte, DOWN sinon (ce point sera dtaill par la suite) ; 2 : DOWN ; 3 : DOWN. Dans le cas des alertes DOWN, si le nud se trouve derrire un lment rseau non disponible, il sera en tat UNREACHABLE. Ceci sera dtaill plus en profondeur dans un prochain chapitre. Concernant les codes pour les services, les quivalences sont : 0 : OK ; 1 : WARNING ; 2 : CRITICAL ; 3 : UNKNOWN. Nagios rcupre simplement le code retour de la commande et, grce sa valeur, positionne ltat de lhte ou du service.

Affichage des informations de retour

Il est trs important de donner un petit texte expliquant le problme lorsque celui-ci est remont aux administrateurs. Sans explication, ils savent quil y a un problme sur un lment particulier, mais ils nen connaissent pas la nature. Nagios utilise la sortie standard des plug-ins et la fournit aux scripts de notification. Il peut prendre plus dune ligne la fois. La premire ligne est mise disposition de la commande de notification travers la macro $SERVICEOUTPUT$ et les autres lignes sont accessibles avec la macro $LONGSERVICEOUTPUT$. Ce dcoupage sexplique par le fait que Nagios na longtemps gr quune seule ligne de retour et que, dans un souci de compatibilit ascendante, une autre macro permet daccder aux donnes prcdemment non disponibles. La limite de taille pour les lignes de retour au sein de Nagios est de 8k caractres. Il est possible de changer cette valeur en recompilant Nagios et en changeant la valeur MAX_PLUGIN_OUTPUT_LENGTH dans le fichier include/nagios.h.in du code source. Elle est cependant suffisante pour la plupart des utilisations.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

55

PRATIQUE La raison de la limite

Nagios a pour but davertir les administrateurs dun problme en leur fournissant un rsum concis. La limite du nombre de caractres est cohrente avec cet objectif. Elle empche une sonde de renvoyer trop dinformations et de rendre les consoles de supervision illisibles.

Conception dun script de vrification

Si nous reprenons notre script qui teste lexistence du fichier /tmp/fichier.txt, il est dj adapt la vrification dun service. Si cette commande de vrification est utilise, le service est en tat OK si le fichier existe, CRITICAL sinon. Lidentification de ltat repose uniquement sur le code retour. Mieux encore, le script est dj correct pour laffichage des informations de retour car il renvoie du texte explicatif sur sa sortie standard. On peut lutiliser librement pour un service sur un nud afin de vrifier que le fichier /tmp/fichier.txt existe. Il est alors pratique de placer ce chemin dans un argument afin de pouvoir utiliser ce script pour tout fichier. Ceci sera tudi trs prochainement. Nous remarquons pour finir que lcriture dun script de supervision est trs simple : une ligne envoye sur la sortie standard et un code retour suffisent faire dun simple script une commande de supervision. Il ny a pas besoin dutiliser de librairie de dveloppement lourde pour faire des commandes de vrification pour Nagios. Vu que les standards de dveloppement Unix sont respects, de nombreux scripts de vrification dvelopps par les administrateurs avant la mise en place de Nagios pourront y tre intgrs sans mme avoir besoin de les modifier. Si nous reprenons notre script vrifiant la prsence dun fichier, nous pouvons le dcouper suivant ses trois composantes : 1 vrification proprement parler ; 2 affichage des lignes dinformations ; 3 positionnement du code retour. La premire tape est commune tous les logiciels de supervision, les deux dernires sont spcifiques Nagios.
tapes dun script de vrification
#!/bin/bash #1 : vrification if [ -f /tmp/fichier.txt ]; then #2 : affichage echo "le fichier existe"

56

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
#3 : exit else #2 : echo #3 : exit fi code retour 0 affichage "le fichier n'existe pas" code retour 2

Codes retour non prvus

Dans certains cas, les commandes de vrification renvoient des codes retour non prvus par Nagios. Celui-ci prvient alors les utilisateurs que la commande ne sest pas droule correctement, et il leur donne le code retour quil narrive pas interprter. La plupart du temps, on se retrouve avec les codes derreur suivants : 9 : la commande a essay de faire une division par zro ; 127 : la commande nexiste pas ou lutilisateur na pas les droits pour la lancer ; 139 : la commande est sortie en erreur mmoire (segfault). Ces codes aident le dveloppeur de la commande la corriger.

lments complexes des plug-ins de vrification

Comme nous venons de le voir, la communication entre les plug-ins et Nagios est trs simple. Cependant, il ne faut pas croire que tous les plug-ins sont simples, loin de l. Si la partie Nagios est toujours simple, il en va tout autrement pour la partie responsable de la vrification. Suivant ce quon souhaite savoir, ceci peut tre trs trivial (par exemple vrifier la prsence dun fichier) ou plus compliqu (comme simuler un client web pour vrifier lintgralit dun site). Sur ce point, tous les outils de supervision sont logs la mme enseigne. Pour obtenir une information, il faut effectuer la vrification correspondante. Avec Nagios, au moins, le dialogue ne ncessite pas de complexifier loutil de vrification : cest dj a. Il ne faut pas oublier lexistence de la communaut, de surcrot trs tendue. Il y a de fortes chances pour que ce que lon cherche soit dj disponible, et ce librement.
COMMUNAUT Le site dchange de sondes

Le site NagiosExchange http://www.nagiosexchange.org est la rfrence en matire de sondes pour Nagios. Tous les membres de la communaut y dposent leurs scripts. Lorsquun administrateur cherche raliser une supervision non prvue dans les plug-ins classiques de Nagios, il a tout intrt vrifier sur ce site si la sonde en question y figure.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

57

Communication entre les Nagios

Nous avons voqu le fait que le Nagios principal se duplique et produit un fils qui lance la commande de vrification. Regardons un peu comment le fils communique le rsultat son pre. Le fils gnre, pour chaque vrification, un fichier dans le rpertoire dfini par la variable check_result_path de nagios.cfg. Par dfaut, cette variable prend la valeur /usr/local/nagios/var/spool/checkresults. Le nom de chaque fichier est de la forme checkAZERTY. AZERTY tant une chane de caractres alatoires. Le contenu dun tel fichier ressemble :
Exemple de fichier de rsultat
### Active Check Result File ### file_time=1231700656 ### Nagios Service Check Result ### # Time: Sun Jan 11 20:04:16 2009 host_name=srv-web1 service_description=Http check_type=0 check_options=0 scheduled_check=1 reschedule_check=1 latency=0.635000 start_time=1231700656.635833 finish_time=1231700656.667482 early_timeout=0 exited_ok=1 return_code=0 output=Http OK | time=0.001s\n

Ces fichiers sont vrifis toutes les max_check_result_reaper_time secondes. Par dfaut, cette vrification se fait toutes les 5 secondes par le processus matre. Celui-ci en extrait des fichiers les informations dtat puis les supprime. Ce mcanisme est simple et permet une communication entre les diffrents processus. Si un redmarrage de Nagios est ncessaire, les fichiers seront toujours prsents aprs le redmarrage et ils seront traits par le nouveau processus. Si linformation est
max_check_result_file_age

plus ancienne que la valeur dfinie par (qui vaut par dfaut une heure), linformation ne sera

pas prise en compte.

58

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Partie mtrologie
Nous avons trait le cas de la supervision, mais quen est-il des donnes de mtrologie ? Nous avons signal que les commandes de vrification rcuprent les informations de mtrologie. Voyons comment elles remontent ces informations Nagios.

Spcifier des donnes de performances dans les plug-ins

Comme dhabitude avec Nagios, le principe est trs simple. Les donnes de mtrologie sont remontes dans la ligne de la sortie standard. On a vu que cette ligne sert au plugin remonter des informations de supervision. Pour intgrer les donnes de mtrologie, cette ligne est simplement coupe en deux par un signe | (barre verticale ou pipe). Tout ce qui se situe avant cette barre est le retour de supervision, qui est plac comme on la vu dans la macro $SERVICEOUTPUT$. Ce qui se trouve aprs la barre est trait comme donnes de mtrologie et est export par Nagios dans un fichier plat. Ce fichier est lu par un outil tiers servant grer les donnes de performances. Pour ces donnes, deux formats sont possibles :
'label'=valeur[unit] 'label'=valeur[unit];[warn];[crit];[min];[max]

Les donnes entre crochets sont optionnelles. On peut placer la suite, spares par un espace, autant de donnes de mtrologie que lon souhaite (dans la limite des 8k caractres, sans oublier de prendre en compte la partie du texte de supervision).

Exemple de donnes de performances

Nous pouvons ainsi avoir un retour de plug-in valant :
Exemple de sortie simple dune commande
DISK OK | /=56%

ou bien alors :
Exemple de sortie plus complte
DISK OK | /=2643MB;5948;5958;0;5968

Nous aurons alors dans le premier cas un suivi du pourcentage dutilisation de lespace /. Dans le second, nous aurons le trac de lespace consomm exprim en Mo ; loutil de mtrologie ayant galement les informations de niveaux warning, critique, minimum et maximum, il pourra faire figurer ces donnes sur le graphique.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

59

Si lon souhaite avoir plusieurs informations de mtrologie dans la mme sortie, cest tout fait possible :
Plusieurs informations de mtrologie
DISK OK | /=56% /boot=50% /home=15%

Nous pouvons suivre nimporte quel type dinformation. Si lenvie prend lutilisateur de compter le nombre de manchots vivant sur la banquise, il peut le faire avec Nagios. Il ne lui reste qu trouver une solution pour les compter en ligne de commande...

Arguments, macros et variables denvironnement

Comme tout programme, les commandes ont des arguments et des environnements particuliers.

Arguments des commandes

Nous avons vu que nous pouvons passer des arguments aux commandes. Ces arguments peuvent tre utiliss avec les macros $ARGn$ dfinies dans les commandes, quil sagisse de commandes de vrification ou de notification. Si lon souhaite utiliser des arguments, on doit appeler la commande de la manire suivante :
Arguments dune commande
check_command check_tcp!80!5

avec 80 pour $ARG1$, 5 pour $ARG2$, etc. Il nest cependant pas souhaitable de tout faire passer par des arguments. Si lon souhaite donner la commande, par lintermdiaire dune variable, ladresse rseau de llment surveill, il faut rcrire ladresse de lhte tester dans lappel de la commande par le service. Cest dommage car linformation est dj dfinie dans llment host auquel on rattache le service. Nagios permet la commande de prendre directement linformation quelle souhaite la source.

Macros
Nous avons vu plusieurs macros au cours de ce chapitre. Au lancement dune commande, Nagios en positionne un grand nombre qui changent de valeurs en fonction du contexte. La macro correspondant ladresse de lhte sur lequel est lance la vrification est tout simplement $HOSTADDRESS$. Ceci permet de dfinir simplement notre test TCP :

60

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Exemple dutilisation dune macro

command_line$USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$

Nous remarquons que la macro $USER1$ est utilise. Elle est dfinie dans le fichier ressources.cfg. Lutilisateur peut dfinir 32 macros $USERn$. La plus commune est $USER1$, qui reprsente en fait le rpertoire dans lequel sont placs les scripts de supervision, gnralement /usr/local/nagios/libexec/. Ceci vite de saisir le rpertoire chaque dfinition de commande. lappel de la commande avec le paramtre !80, sur un hte ayant comme adresse 192.168.0.1, Nagios lance en fait la commande :
Commande rellement lance
/usr/local/nagios/libexec/check_tcp -H 192.168.0.1 -p 80

Il est possible et fortement conseill de tester les commandes de vrification directement depuis un shell sur le serveur de supervision.

Variables denvironnement
Il y a une diffrence entre une commande lance directement depuis un shell et la mme commande lance depuis Nagios : lenvironnement. Sur le serveur de supervision, Nagios est excut par un utilisateur non privilgi, gnralement nomm nagios. Lorsquil lance une commande, Nagios retire les variables denvironnement de lutilisateur et positionne les siennes : les macros. Il nest pas ncessaire de passer une macro en argument si le programme lanc est capable de la rcuprer dans ses variables denvironnement. Il nest pas conseill de fonctionner de cette manire, ne serait-ce que par souci de lisibilit des commandes lances. De plus, ces commandes sont plus compliques tester directement depuis un shell, car il faut positionner correctement les variables denvironnement avant de les lancer. La variable PATH du shell nest pas positionne. Les sondes doivent utiliser des chemins absolus si elles souhaitent lancer des programmes. Ceci est une cause frquente de problmes lors des tests. Un programme de vrification peut trs bien fonctionner en ligne de commande et beaucoup moins bien dans Nagios, tout simplement car il souhaite utiliser la variable PATH qui nest pas positionne.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

61

PIGE Toujours employer lutilisateur nagios pour tester les plug-ins

Un pige classique, lorsquon teste un nouveau plug-in, consiste le lancer en tant que root. Ceci est proscrire absolument. Le dmon Nagios fonctionne avec un utilisateur non privilgi, gnralement nagios. Il refuse catgoriquement de se lancer en tant que root (et insulte au passage ladministrateur qui tente une telle hrsie). Si le programme de vrification a besoin des droits root, il faut penser positionner correctement son bit SUID ou utiliser sudo. Plus grave encore, si le programme utilise des fichiers temporaires, le tester en tant que root peut empcher le plug-in de fonctionner correctement en tant que nagios, cause des droits sur ces fichiers.

Ordonnancement des vrifications et des notifications

Nagios est un ordonnanceur de vrifications. Regardons comment il en dtermine lordre. tudions galement son systme de notifications.

Ordonnancement initial des vrifications

Commenons notre tude par les vrifications.

taler la charge sur les machines

Lorsque Nagios dmarre, il ordonnance les vrifications quil doit effectuer. Sil prvoit de les lancer toutes la fois, la charge sur le serveur de supervision risque dtre trs importante, srement trop pour que les sondes aillent au bout de leurs tches. Une fois lances, si elles sont planifies pour se lancer toutes les cinq minutes, Nagios naura rien faire pendant cet intervalle de temps. Il est important dtaler au maximum les vrifications pour lisser la charge. Un autre problme fait surface, mais il concerne les htes surveills. Sur la plupart des nuds, plusieurs services sont configurs. Si Nagios fait un ordonnancement bte , il lance les services les uns aprs les autres. Les services dun mme hte se retrouvent lancs presque en mme temps. La charge correspondante sur les htes nest pas ngligeable. Le lissage de la charge doit donc intervenir aussi pour les lments surveills, sous peine de les soumettre des pics de charge inutiles.

taler les vrifications sur le serveur Nagios

Le lissage des vrifications depuis le serveur Nagios se fait grce linter-check delay. Il correspond lintervalle de temps entre les lancements de vrifications. Cette dure tant, en rgle gnrale, infrieure la dure dexcution des commandes, plusieurs dentre elles vont tre lances en parallle.

62

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Ce mcanisme prend en paramtre service_inter_check_delay_method. Si ladministrateur positionne une valeur comme 0.01, cest cette dure, en secondes, qui est prise comme dlai entre les lancements de vrifications. Il est conseill de laisser Nagios calculer cet intervalle par lui-mme, ce que lon obtient par la valeur s (smart). Le dlai devient alors :

Le calcul est simple : Nagios prend le dlai moyen entre deux vrifications dun mme lment et il le divise par le nombre total dlments. Si lon considre la dure moyenne entre les vrifications comme une priode de vrification, il cherche rpartir au maximum les vrifications sur cet intervalle de temps. Prenons un exemple avec 2000 services surveills toutes les 5 minutes. La priode moyenne de vrification est simple calculer ici : 5 minutes. Pour 2000 machines, cela reprsente un inter_check_delay de , soit 0,15 seconde. Le mme mcanisme existe pour les vrifications dhtes. La seule diffrence est le nom du paramtre, qui devient host_inter_check_delay_method.

taler les vrifications sur les machines distantes

Pour le lissage des vrifications sur les machines distantes, il faut tout dabord comprendre comment Nagios cre en mmoire sa liste de services superviser. la lecture de la configuration, il parcourt les htes et ajoute, pour chacun, ses services les uns aprs les autres. La liste de services ainsi cre nest pas souhaitable comme ordre de vrification : les services dun mme nud ne sont pas espacs. Pour viter cela et crer sa file de vrification, Nagios utilise le paramtre service_interleave_factor. Ce dernier peut tre un entier ou bien s (smart). Si cest un entier, lors de la cration de la file, Nagios prend un service sur service_interleave_factor. Les services dun mme hte sont donc espacs dans la vrification. Si ce paramtre est gal un, alors ils sont la suite les uns des autres : cette valeur est donc fortement dconseille. La valeur par dfaut est s et implique que Nagios calcule lui-mme lespacement appliquer entre les services dun mme hte. Pour cela, il utilise la formule suivante :

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

63

Le principe est, ici encore, trs simple. Il compte le nombre moyen de services par nud. Avec cette valeur, il obtient un espacement qui permet, en moyenne, dordonnancer des services se trouvant sur des htes diffrents. Dans certains cas, sur des htes hbergeant beaucoup de services par rapport la moyenne, il peut arriver que deux services soient demands de manire rapproche. Toutefois, mme dans ce cas problmatique, la charge est bien moindre que si elle ntait pas lisse. Ce mcanisme est reprsent sur le diagramme suivant :

Figure 31 Lissage des vrifications par interleave_factor

Types dtat SOFT et HARD

Nous venons de voir ce quil faut dfinir dans Nagios pour lui indiquer les lments superviser, ainsi que les commandes utilises pour surveiller tout ce petit monde. Nous allons maintenant regarder plus en dtail la logique de supervision de Nagios. Nous avons trs brivement survol ce sujet lors des explications sur les paramtres de retry des htes et des services notamment. Nous avons indiqu que les notifications sont envoyes uniquement si les tats des htes et services ont t valids. Ces tats (UP, DOWN, UNREACHABLE pour les htes, OK, WARNING, CRITICAL et UNKNOWN pour les services) peuvent tre de deux types bien diffrents : SOFT : le problme vient juste dtre dtect et demande vrification ; HARD : le problme est confirm. Les tats de bon fonctionnement (UP et OK) ne peuvent tre que de type HARD : le type SOFT na pas une grande signification pour eux, une exception prs que nous verrons par la suite. Les nuds et les services possdent un paramtre important dans ce contexte : Il correspond au nombre de fois o une commande retourne un tat diffrent de UP ou OK avant de passer en type HARD. Il est important de noter quici, le premier test retournant lerreur est pris en compte dans
max_check_attempts.

64

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
max_check_attempts. Si lon souhaite ds la premire erreur passer en tat suffit donc de placer cette proprit 1. HARD,

il

Les intervalles de vrification ne sont pas les mmes entre les tats SOFT et HARD. Les lments (services et nuds) ont les proprits suivantes : check_interval : correspond lintervalle de vrification en tat HARD ; retry_interval : correspond lintervalle de vrification en tat SOFT. Nous allons avoir deux intervalles de supervision : un quand linformation est sre, un autre, gnralement infrieur, qui est utilis uniquement pour clarifier une situation.

Exemple de changement de type dtat

Nous pouvons dfinir un service comme suit :
Exemple de paramtrage dun service
max_check_attempts 4 check_interval 5 retry_interval 3

La vrification se fait en temps normal toutes les 5 minutes. Si un problme survient (WARNING, CRITICAL ou UNKNOWN), alors on effectue 3 essais supplmentaires. On nen fait que 3, le passage en tat HARD intervient au bout de 4 tests. On vient dj den raliser un, celui qui a rvl lanomalie. Nous nous retrouvons alors ce moment en tat de type SOFT.

Figure 32 Changement de type dtat dun service lors de la supervision

Les 3 autres vrifications sont ralises avec un intervalle de temps de 3 minutes (paramtre retry_interval). Si, au bout de ces tests, la situation nest pas redevenue

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

65

ou UP, alors le dernier tat passe en tat de type HARD. Les tests sont alors conduits toutes les 5 minutes. Lorsque la situation revient en tat UP ou OK, ltat reste en HARD et on continue de vrifier toutes les 5 minutes jusqu larrive dune nouvelle erreur. Nous pouvons observer cela sur le diagramme de la figure 3-2.
OK

Un tat SOFT un peu particulier : SOFT-RECOVERY

Il arrive que, lors des vrifications supplmentaires du type SOFT, le problme soit rsolu et que la commande renvoie un rsultat UP ou OK. Dans ce cas, le type dtat ne va pas tre SOFT car il est rserv aux problmes, ni HARD car ltat nest pas vrifi, mais SOFT-RECOVERY. Ce type dtat se comporte comme un type SOFT classique, cest--dire que les vrifications rapproches continuent. Le rsultat du dernier test est retenu comme ltat HARD. Voici un exemple dune telle problmatique. Ici, ltat OK est obtenu le temps dune seule vrification, qui nest pas la dernire. Cest ltat CRITICAL qui est retenu comme tat HARD.

Figure 33 Passage par un tat SOFT-RECOVERY avant datteindre ltat HARD

Notifications de problmes
Continuons notre tude avec les notifications.

Notifications : le but des types dtat SOFT et HARD

Nous pouvons lgitimement nous demander quoi servent les types SOFT et HARD. Ils sont simplement utiliss dans le cadre de la notification des problmes aux contacts.Peu de situations justifient denvoyer une alerte sur un lment si, quelques

66

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

secondes aprs, elle nest plus valable. Cest le cas, par exemple, lors dun problme rseau momentan. Pour certains services ou htes, il peut tre intressant dtre averti du moindre souci ; toutefois, dans une grande majorit des cas, il est prfrable de vrifier linformation avant de lenvoyer aux utilisateurs. Cest cela que servent les types SOFT et HARD : ils permettent de vrifier la pertinence dune alerte. Lors de la phase SOFT, Nagios tente de vrifier si lerreur est effectivement toujours prsente. La vrification est rpte autant de fois que le souhaitent les utilisateurs, grce aux paramtres max_check_attempts et retry_interval.

Renvoi de notifications
Une fois que ltat est valid, en phase HARD, Nagios notifie les contacts sils le souhaitent. Cette notification intervient ds le passage en tat HARD. Lutilisateur peut, avec le paramtre notification_interval, spcifier Nagios lintervalle de temps entre deux notifications. La notification est relance tant que ltat nest pas redevenu UP ou OK.
PRATIQUE tre lger sur les notifications
Comme nous le verrons au chapitre 6, envoyer trop de notifications est dangereux. Il faut choisir le paramtre notification_interval avec soin.

Lorsque ltat revient la normale et si lutilisateur la dcid dans le paramtre Nagios envoie une alerte de recovery pour les services, dUP pour les htes. Ce paramtre doit tre suprieur la valeur check_interval. Si cette valeur tait infrieure, Nagios enverrait une notification alors quil na pas re-vrifi ltat de llment, ce qui nest pas logique. La seule exception est la valeur 0 : elle signifie de nenvoyer quune seule notification pour le problme.
notification_options,

Exemple dordonnancement des notifications

Si nous positionnons les paramtres comme ceci, nous obtenons le comportement du diagramme 3-4.
notification_interval notification_options 8 w,c,r

Nous remarquons qu t = 19 min une notification dalerte critique est envoye. Elle correspond au passage en tat HARD. 8 minutes aprs, t = 27 min, vu que le service est toujours en tat CRITICAL, une autre notification est leve. Pour finir, une dernire notification est envoye t = 29 min. Cest une notification recovery de service. Nous remarquons dans le paramtre notification_options le champ r : ladministrateur souhaite donc quune telle notification soit envoye.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

67

Figure 34 Types SOFT, HARD et notifications

Il est noter que, pour quune notification soit leve, elle doit survenir durant la priode notification_period dfinie sur les services et les htes. Si cette condition nest pas vrifie, la notification nest pas envoye.

Notifications : la configuration des contacts prime

Nous nous souvenons que les contacts possdent les deux proprits service_notification_period et service_notification_options (il en va de mme pour les htes). Elles permettent de spcifier les notifications que le contact souhaite accepter. Ces options agissent comme un filtre. Elles peuvent, par exemple, tre dfinies sur lhte ou le service, mais pas sur un contact. Dans ce cas, ce dernier nest pas notifi du problme. Si nous avons un service dfini comme :
notification_options w,c,r

mais que le contact a seulement dfini :

notification_options w,c

lors de la leve de la notification de recovery (option r), le contact ne reoit pas linformation. De mme, si cest linverse qui est configur :
notification_options w,c

68

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

sur le service et :
notification_options w,c,r recovery

sur le contact, la notification de ne la reoit pas.

ntant pas leve par le service, le contact

En cas de problme persistant : lescalade des notifications

Il arrive que les personnes qui reoivent les notifications narrivent pas rgler le problme. Regardons comment Nagios peut grer cette situation.

Lorsque les problmes perdurent : on appelle un ami

Lorsquune erreur persiste malgr lenvoi dune notification un ou plusieurs contacts, cest que ceux-ci ne sont pas en mesure de rgler le problme. Ce genre de situation arrive souvent lorsquon a diffrents niveaux dassistance au sein du service. Les alertes peuvent tre diriges tout dabord vers lassistance de niveau 1 qui tente de rsoudre le problme en recherchant une solution dans la base de connaissances de lentreprise. Si la base ne contient pas de solution adapte, lalerte doit tre remonte au niveau suprieur, et ainsi de suite jusqu arriver au dernier niveau : ce stade, il faut trouver une solution, cote que cote. Ce mcanisme est prsent au sein de Nagios et se nomme escalade de notifications. Nous allons pouvoir y dfinir un nombre maximum denvois de notifications avant de passer au niveau de contacts suivant.

Bien penser laspect psychologique dune telle mise en place

Il faut bien faire attention ne pas abuser de ce mcanisme. Nous avons mis en garde ladministrateur Nagios, dans les premiers chapitres, sur les aspects psychologiques qua la mise en place dune solution de supervision. Les escalades en font pleinement partie. Les contacts ne doivent pas prendre Nagios pour un dlateur auprs de leur hirarchie. Ils pourraient alors faire en sorte que loutil ne dtecte plus rien, ce qui serait contre-productif.
CONFIGURATION Une charge supplmentaire
En plus de laspect psychologique, la mise en place des escalades implique davantage de configuration. Ladministrateur doit peser le pour et le contre dune telle mise en place.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

69

Si la mise en place dun tel procd se justifie, comme dans le cas des diffrents niveaux dassistance ou de personnes en astreinte, il ne faut pas hsiter. Dans les autres cas, il faut bien peser le pour et le contre.

Dfinition dans Nagios

Les escalades de notifications sont contenues dans les objets serviceescalation. Ceux-ci possdent 6 proprits : host_name : nom de lhte concern ; service_description : nom du service auquel sapplique lescalade ; first_notification : numro de la notification partir de laquelle le groupe de contacts est alert ; last_notification : numro de la notification partir de laquelle le groupe de contacts nest plus alert : si cette valeur est 0, lescalade ne finit pas ; notification_interval : priode denvoi des notifications pour ce groupe de contacts ; contact_groups : groupe de contacts qui reoit les notifications. Nous remarquons que les escalades sappliquent sur un intervalle de notifications : son dbut ainsi que sa fin sont des numros de notification. Nous pouvons avoir plusieurs escalades, chacune ayant son intervalle de notifications. Si ces intervalles se chevauchent, tous les groupes sont avertis. Les escalades peuvent redfinir lintervalle entre deux notifications. Dans le cas dun chevauchement descalades, cest la valeur la plus faible qui lemporte.

Exemple descalade
level1,

Nous nous plaons dans la situation o lassistance de niveau 1, nomme supportest destinataire des notifications sur le service Http, lui mme accroch au serveur srv-web1. Nous souhaitons que les 2 premires notifications soient envoyes ce groupe. Si, aprs ces deux remontes dalertes, le problme nest toujours pas rsolu, cest le groupe support-level2 qui est averti pendant 2 notifications. Si, de mme, le problme nest pas rsolu, il est remont au support-level3, et ce, indfiniment.
Dfinition dune escalade
define serviceescalation{ host_name service_description first_notification last_notification notification_interval

srv-web1 Http 3 4 30

70

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
contact_groups } define serviceescalation{ host_name service_description first_notification last_notification notification_interval contact_groups } support-level2

srv-web1 Http 5 0 60 support-level3

Cas des notifications de type recovery

Nous pouvons nous retrouver dans un cas un peu particulier avec les notifications de type recovery et les escalades. Une telle notification est considre comme un envoi supplmentaire. Mais que se passe-t-il si cet envoi fait remonter le problme ? Des contacts nayant jamais eu connaissance du problme sont informs quil est rsolu ; cette information ne leur est toutefois daucune utilit. Nagios traite ce cas en ne faisant tout simplement pas descalade dans le cas dune notification de type recovery. Daprs sa dfinition, elle ne sera plus suivie de notification, donc ceci ne pose aucun problme.

Destination de toutes les informations rcoltes

Avec ce que nous avons vu, nous pouvons fournir Nagios des lments superviser, des commandes pour le faire et mme des techniques de notification. Que doit-il faire de toutes les informations quil recueille ?

Informations dtat, dalerte et de notification

Nagios crit les informations immdiates sur les tats des lments superviss dans le fichier var/status.dat toutes les status_update_interval secondes (par dfaut 15 secondes). Ce fichier est lu par les interfaces pour obtenir ltat des lments. Concernant les donnes de performances, il les dpose simplement dans un fichier plat, en attendant quun programme tiers vienne les rcuprer. Le reste des informations, comme les alertes ou les envois de notifications sont sauvegards dans le fichier journal principal de Nagios : var/nagios.log.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

71

En cas de redmarrage : le fichier status.sav

Afin de pouvoir conserver les informations dtat lors dun redmarrage, Nagios sauvegarde rgulirement les tats des htes et des services dans un fichier. Il sagit, en gnral, de var/status.sav. Ce fichier est relu au dmarrage de Nagios afin den tirer ltat actuel des lments.

Un module dexport de donnes : NDOUtils

Nagios dispose galement dun module un peu particulier : NDOUtils. Ce module se loge au sein de Nagios et rcupre toutes sortes dinformations comme les tats des htes et des services, ou bien les commandes lances et leurs retours. Il permet de dposer toutes ces informations dans une base de donnes. Actuellement, seules les bases MySQL et PostGreSQL sont prises en charge. Ceci permet de rechercher des informations trs rapidement. De plus, dans le cas o lon a plusieurs serveurs Nagios, chacun peut y dposer ses informations. Ceci sera expliqu en dtail au chapitre 10.

Comment donner un ordre Nagios

Nagios lit sa configuration lors de son dmarrage puis se lance dans ses oprations de supervision. Il reste cependant lcoute de lextrieur et notamment des administrateurs.

Fonctionnement de la communication
Nagios cre un fichier spcial lors de son initialisation, qui lui permet de recevoir des ordres. Ce fichier est un tube nomm , var/rw/nagios.cmd. Ce type de fichier est comme une voie de communication sens unique. Un processus peut y crire, un autre lit ces informations. Les donnes ne font que transiter par le fichier sans y rester ; si personne nest en train dcrire dedans, il est vide. Nagios lit ce fichier. Lorsquun processus extrieur y crit, Nagios y cherche des ordres ou des informations de supervision. Les utilisateurs peuvent exploiter ce fichier pour forcer Nagios changer son ordonnancement, voire pour lui donner des indications sur ltat dun lment supervis. Pour cela, un simple echo dun texte dans le fichier suffit donner un ordre Nagios. On parle pour ce mcanisme de commandes externes . Les outils tiers peuvent utiliser ce mcanisme pour fournir leurs informations Nagios. Nous verrons cependant dans un autre chapitre que certains dmons aident cette communication.

72

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Ce quon peut lui demander

Nagios fournit un nombre assez impressionnant de commandes externes. Nous nallons pas toutes les tudier, ceci prendrait bien trop de place. Voici quelques exemples.
REMARQUE Liste des commandes externes
La liste complte est disponible dans la documentation officielle de Nagios. B http://nagios.sourceforge.net/docs/3_0/extcommands.html.

Prise en compte dun tat

Un utilisateur peut avertir ses collgues quun problme a t pris en compte. Ceuxci peuvent ainsi se concentrer sur dautres problmes. La commande ddie est
ACKNOWLEDGE_SVC_PROBLEM.

Lutilisateur envoie le texte suivant Nagios :

ACKNOWLEDGE_SVC_PROBLEM;<host_name>;<service_description>;<sticky>; <notify>;<persistent>;<author>;<comment>

Les paramtres sont : host_name : nom de lhte hbergeant le service concern ; service_description : nom du service ; sticky : si positionn 1, ne sera supprim que si le service passe nimporte quel changement dtat sera pris en compte ; notify : prvenir ou non les autres contacts du service ; persistent : linformation rsiste ou non un redmarrage ; author : nom de lauteur ; comment : texte explicatif. Voici un exemple denvoi de cette prise en compte Nagios :
Prise en compte dun service

OK,

sinon

now=`date +%s` commandfile='/usr/local/nagios/var/rw/nagios.cmd' /bin/printf "[%lu] ACKNOWLEDGE_SVC_PROBLEM;srv-web1;Http;1;1;1;Un administrateur;Probleme sous controle\n" $now > $commandfile

Forcer un rsultat de vrification dun service

Un utilisateur peut forcer un rsultat dune vrification dun service particulier. La commande ddie est PROCESS_SERVICE_CHECK_RESULT.

Choix dune solution de supervision : atouts et fonctionnement de Nagios CHAPITRE 3

PROCESS_SERVICE_CHECK_RESULT;<host_name>;<service_description>; <return_code>;<plugin_output>

73

Les paramtres sont : host_name : nom de lhte hbergeant le service concern ; service_description : nom du service ; return_code : code retour du service, correspondant aux codes de CRITICAL et UNKNOWN ; plugin_output : texte du retour du service. Voici un exemple dun tel envoi de communication :
Envoi dun rsultat Nagios

OK, WARNING,

now=`date +%s` commandfile='/usr/local/nagios/var/rw/nagios.cmd' /bin/printf "[%lu] PROCESS_SERVICE_CHECK_RESULT;srv-web1;Http;0;OKTout va bien maintenant\n" $now > $commandfile

En un mot
Lorsque lon recherche un outil de supervision, le choix dune solution open source est trs avantageuse. Dans ce monde, Nagios est la rfrence. Sa conception est simple et sa plus grande force est sa modularit. Ses possibilits sont trs tendues. La seule limite rside dans lobtention des informations de supervision. Si ladministrateur est capable de les obtenir en ligne de commande, alors lintgration dans Nagios est possible.

4
Premier niveau de test : rponse dun nud sur le rseau
Dans ce chapitre nous allons tudier le fonctionnement des plug-ins qui devront rechercher activement les informations sur les htes. Ils peuvent les obtenir soit directement sur le rseau, soit par lintermdiaire dun agent situ sur le nud.

Tests directs sur le rseau

Nous avons tudi la configuration des lments dans Nagios, le fonctionnement de la communication avec les plug-ins et enfin son ordonnancement des vrifications. Nous avons voqu le fait que ce sont les sondes qui font les vrifications et qui dcident de ltat des lments superviss. Regardons maintenant dun peu plus prs les mthodes dobtention dinformations sur les nuds distants. Seules les mthodes actives sont tudies ici. Les mthodes passives le seront dans un autre chapitre.

76

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

REMARQUE Effectuer les tests en parallle

Ce chapitre contient de nombreuses commandes illustrant les vrifications. Il peut tre utile au lecteur davoir sous la main un shell pour excuter ces commandes. Pour cela, il peut ds prsent lancer les commandes dcrites dans la partie Installation des paquetages du chapitre suivant. Il trouvera les sondes dans /usr/lib/nagios/plugins.

Tests applicatifs simples

Lun des cas les plus simples traiter consiste vrifier linformation lorsquelle est directement disponible sur le rseau. Dans le cadre de la supervision dun service distant, on se place simplement dans le rle dun client. On effectue une requte et on vrifie que lon obtient bien une rponse conforme ce que lon souhaite. Imiter le comportement dun client standard a un avantage certain : cest un moyen simple et direct de savoir si la ressource est disponible pour les autres clients. Cest pour cela quil faut se rapprocher le plus possible de la position dun utilisateur normal.

Test des ports rseau

La plupart des applications sont sur le rseau. On peut parfois se contenter de tester la connectivit pour dterminer leur tat.

Un test simple et lger

Un service rseau est gnralement disponible sur un port TCP ou UDP dune adresse IP. Si le service nest pas lanc, il ne peut pas avoir son port ouvert. Trouver ce port ferm signifie que le service nest pas disponible aux clients.
B-A-BA Rappel sur le rseau
Il est toujours bon de rappeler les diffrentes couches du rseau que lon utilise tous les jours : 1. physique (cble ou onde) ; 2. Ethernet ; 3. IP ; 4. TCP ou UDP ; 5. applicatif. La plupart des sondes Nagios travaillent un niveau suprieur 3.

Une mthode de supervision des services consiste se limiter la supervision des ports des applications. Vrifier quils sont bien ouverts est lune des oprations les

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

77

plus lgres en matire de supervision, que ce soit en termes de charge systme ou rseau. Cette opration est de toute manire ncessaire lors des communications entre les clients et les serveurs. Si la lgret de la solution est attirante, elle a un dfaut gnant : si un port ferm signifie quune application est non disponible, linverse nest pas assur. Il peut arriver, dans certains cas, quune application coute toujours ses ports, mais quelle ne sache plus traiter les demandes quelle reoit. Une telle situation peut se produire, par exemple, dans une application faisant appel une base de donnes. Si cette dernire nest pas disponible, lapplication na pas accs ses donnes et renvoie un message derreur ses clients. Le problme avec le simple test dun port se situe justement au niveau de ce message derreur : puisque lon na pas fait de vraie requte en sarrtant la simple ouverture du port, on ne reoit pas ce message. Le test est positif, mais il sagit dun faux positif. Il faut cependant relativiser la situation. Dans de nombreux cas, un tel test est largement suffisant. De plus, faire de vraies interrogations peut parfois savrer complexe, voire tout simplement impossible. Une telle situation arrive si, par exemple, le protocole de communication nest pas document.

Test dun port TCP

Appel du plug-in check_tcp Voyons prsent lexemple dun test de port TCP. tudions plus en dtail ce qui transite rellement sur le rseau. Considrons le test dun port 80 (HTTP) sur un serveur distant. On utilise pour cela le plug-in check_tcp. La commande dfinie est la suivante :
Dfinition de la commande check_tcp
$USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$

On appelle par exemple cette commande dans un service comme suit :

Appel de la commande check_tcp
check_commandcheck_tcp!80

La commande check_tcp possde de nombreux paramtres, pouvant rpondre un nombre lev de besoins. Elle peut faire bien plus quouvrir un port. Elle peut galement envoyer un texte de requte au service et en attendre une rponse.

78

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Voici ce que donne un test douverture de port sur un serveur web :

Test douverture dun port web
/usr/local/nagios/libexec/check_tcp -H www.google.fr -p 80 TCP OK - 0,093 second response time on port 80|time=0,093117s;;;0,000000;10,000000 echo $? 0

Le code de retour OK du service serait remplac par un code UP si nous vrifions un hte. Le texte de retour est explicite. Le plug-in renvoie galement des donnes de performances indiquant le temps de rponse du service. Ici, le port sest ouvert en 93 ms. La valeur limite du temps de rponse tait de 10 secondes, et peut tre change avec le paramtre -t. Ce que le plug-in effectue rellement Dans le cas dun test de port TCP, la commande effectue simplement une connexion TCP nomme 3-Way Handshake ( tablissement dune connexion en trois tapes ). Dans le cas dun port ouvert, louverture de la connexion se passe en effet en 3 tapes : 1 le client envoie un paquet SYN ; 2 le serveur lui rpond SYN+ACK ; 3 le client rpond alors ACK. Seuls trois paquets rseau de petite taille sont ncessaires pour ouvrir une connexion. Dans le cas dun port ferm, la communication est encore plus rapide : 1 le client envoie un paquet SYN ; 2 le serveur lui rpond RST+ACK. Dans ce cas, ceci signifie que la machine est encore disponible car sa pile rseau a pu rpondre, mais que lapplication coutant sur le port est ferm. L encore, le test est lger et rapide.

Un test suffisant pour la disponibilit dun hte

Un des cas o la disponibilit dun port est reprsentative de la disponibilit dune ressource est le test des serveurs et des lments rseau. Pour les htes, ladministrateur doit dfinir une mthode permettant de savoir, avec un seul plug-in, si le nud est vivant ou non.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

79

Lorsquon met en place pour la premire fois un outil de supervision, on choisit souvent de tester la disponibilit des nuds avec une rponse un ping ICMP. Ce test est trs simple, mais il peut se rvler vite limit. En effet, pour des raisons de scurit, ce protocole est dans de nombreuses entreprises limit au rseau local. Certains serveurs munis dun pare-feu ne rpondent pas ce test, pas plus que les lments en zone DMZ. Il faut alors dfinir une autre mthode pour ces serveurs particuliers mthode de prfrence commune lensemble des serveurs. On pourra par exemple tirer parti de la disponibilit des ports dadministration. Tous ces lments sont administrables distance, par le biais dune application coutant les requtes des administrateurs, aussi bien sur le port SSH des serveurs Unix et des quipements rseau, que sur le port MSTSC sur les serveurs Windows. Ces applicatifs ont la qualit dtre particulirement robustes et peu dpendants dautres ressources. Nous pouvons considrer que, si le port rpond, lapplication est disponible. Dans ce cas, lhte est dclar comme tant en tat UP. Dans le cas contraire, puisque que ces applications de prise de contrle sont indispensables au travail des administrateurs, larrt de cette application implique que le nud nest pas disponible et quil ne rpond plus aux requtes rseau ; on le considre alors comme DOWN. Lun des avantages dun tel test, outre le fait quil est trs lger, se situe au niveau des rgles de pare-feu : les ports dadministration sont disponibles simplement et ne demandent pas de nouvelle rgle sur les quipements de filtrage. Inutile de crer une rgle ICMP sur le rseau chose qui ferait frmir bon nombres dadministrateurs.
SCURIT Filtrage de ICMP
Les paquets ICMP peuvent contenir des informations utiles, mais sont aussi un trs bon support pour les canaux cachs. Cela dit, bien dautres dangers plus immdiats menacent les systmes (tunnel TCP sur HTTP, vol dinformations par cl USB...).

Test des services web

De nombreux services mis en place actuellement sont des services web. Nous avons besoin dun test permettant de dterminer sils sont en bon tat ou non. Lun des avantages des ces applications est leur protocole de communication : HTTP. Celui-ci est simple et connu. Le plug-in standard ddi cette supervision est check_http.

Principe des tests HTTP

Les tests HTTP sont simples. On imite le comportement dun client, et on demande lapplication web une page par dfaut la page daccueil. On vrifie que celle-ci est bien forme et quelle ne contient pas de message derreur particulier. Sur ce point,

80

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

chaque application est diffrente. Elles ne renvoient pas toutes le mme texte. On doit donc changer lgrement le test de vrification pour chaque service web. Lapplication web, en plus de renvoyer la page, transmet des informations importantes grce un code retour inclus dans le protocole HTTP. Il doit tre interprt en priorit. On peut noter certains codes qui reviennent souvent : 200 : la requte sest droule sans erreur ; 301 : la page demande a t dplace dfinitivement ; 401 : la page requiert une authentification ; 403 : la page est interdite daccs ; 404 : la page nest pas disponible ; 500 : le service a subi une erreur interne qui la empch de traiter la requte. Ces codes de retour HTTP reprsentent diffrents tats pour la commande de vrification. Les codes 200 et 301 correspondent un tat correct. Le rsultat correspondant est OK. Les tats 401, 403 et 404 sont des tats inquitants. La page na pu tre atteinte, mme si le dmon web semble en bon tat. Il sagit dun WARNING. Quant lerreur 500, celle-ci dmontre que le service web a rencontr un grave problme en traitant la requte, lerreur est considre comme CRITICAL.

Le plug-in check_http
Le plug-in standard permettant de vrifier les rponses web est check_http. Il prend comme argument ladresse du service tester par le paramtre -H. On peut lui fournir galement une page spcifique interroger, grce au paramtre -u. Si le paramtre nest pas spcifi, le plug-in teste la page de garde. Il peut galement chercher une chane de texte dans la page reue et avertir sil ne la trouve pas. On la lui prcise avec le paramtre -s. Tester la page daccueil dun site Plaons-nous tout dabord dans un cas o la requte est correcte. Nous testons ici la page principale du site. Nous supposons que le plug-in check_http se trouve dans le rpertoire par dfaut des plug-ins de Nagios. Ce rpertoire est /usr/local/nagios/libexec dans une configuration standard. Nagios le rfrence dans sa configuration avec la macro $USER1$.
Exemple dutilisation de check_http
$USER1$/check_http -H www.google.fr HTTP OK HTTP/1.0 200 OK - 6482 bytes en 0,231 secondes |time=0,231233s;;;0,000000 size=6482B;;;0

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

81

Ce test est effectu sur le mme service web que le test douverture de connexion, mais il a mis deux fois plus de temps sexcuter. Dans cet exemple, une requte HTTP a t effectue sur le service et celui-ci a rpondu. Cela prend plus de temps quune simple ouverture de connexion sans requte.
REMARQUE Simplification des commandes dans cet ouvrage
Dans la suite du chapitre, la macro $USER1$ ne sera pas prsente pour ne pas surcharger inutilement les commandes. Dans une configuration relle de Nagios, elle doit tre indique.

Rechercher une chane de caractres dans la page Sur cette mme page, nous cherchons une chane de caractres. En loccurrence, celle-ci ne sy trouve pas, ce qui dclenche une erreur.
Recherche dune chane de caractre inexistante sur une page web
check_http -H www.google.fr -s "pere noel" HTTP CRITIQUE - chane non trouve|time=0,254568s;;;0,000000 size=6488B;;;0

Nous sortons en tat CRITICAL car le test na pas t concluant. Tester lexistence dune page Pour notre dernier test, nous consultons une page qui nexiste pas. Nous nous attendons donc sortir avec un tat WARNING.
Recherche dune page inexistante sur une page web
check_http -H www.google.fr -u "/nexistepas" HTTP WARNING: HTTP/1.0 404 Not Found

Cest en effet le cas.

Cas des services web accs scuriss : authentification, HTTPS...

Demandes dauthentification Certains sites web contiennent des zones qui sont, juste titre, scurises par une demande dauthentification. Si lon souhaite superviser une page situe dans une telle zone, il faut que le plug-in ait connaissance dun compte avec lequel se connecter.

82

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

PIGE Diffrents types dauthentification sur les sites web

Il faut faire attention aux diffrentes mthodes dauthentification sur les sites web. Celles-ci peuvent tre effectues par le serveur web et donc passer par le protocole HTTP. Certaines applications grent ellesmmes lauthentification avec un formulaire remplir. Dans ce cas, la mthode prsente ici ne fonctionne pas. Il faut alors utiliser un autre plug-in, nomm Webinject, qui permet de jouer un parcours du site web. Ce plug-in est tudi un peu plus loin.

On utilise, pour grer cette authentification, le paramtre -a de simplement fournir une paire compte:motdepasse en argument.

check_http.

Il faut

Par exemple, pour atteindre la zone /admin dun site sur un intranet, on utilise le compte admin et le mot de passe supermotdepasse. On obtient alors la requte suivante :
Vrification dune page web avec authentification
check_http -H intranet.mydomain -u /admin -a admin:supermotdepasse HTTP OK HTTP/1.0 200 OK - 6482 bytes en 0,230 secondes |time=0,229866s;;;0,000000 size=6482B;;;0

Cas des serveurs HTTPS De plus en plus de services web font appel la couche SSL pour permettre aux clients didentifier formellement le serveur et de chiffrer leurs communications sensibles , comme leur authentification. La seule diffrence avec le cas dun service web classique se trouve dans la communication entre les deux parties. Celle-ci est contenue dans un flux SSL. Pour surveiller un tel service et se faire passer pour un client standard il faut envoyer les requtes via un canal SSL. check_http le gre grce au paramtre -S. Il se comporte alors comme prcdemment, mais utilise le port 443 (HTTPS) et une connexion SSL pour dialoguer avec le serveur. Nous pouvons changer le port de connexion, si besoin, grce au paramtre -p. Nous obtenons pour un serveur classique une demande de la forme suivante :
Vrification dune page web travers HTTPS
$USER1$/check_http -H www.google.com -S HTTP OK - HTTP/1.0 302 Found - 0,325 secondes de temps de rponse |time=0,325044s;;;0,000000 size=407B;;;0

On peut noter quici on a eu un retour 302. Cest en fait une variante dune page migre (code 301). Ce nest pas un code derreur.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

83

Vrifier lexpiration des certificats Lorsque lon met en place un service web scuris par SSL, il faut disposer dun certificat sign par une autorit de certification. Ces certificats ont une certaine dure de validit. Il est trs courant doublier de les renouveler temps. On se trouve alors dans une situation inconfortable : les clients ont une erreur sur leur navigateur car le certificat est prim, mais le site fonctionne bien si on oublie ce dtail. De nombreux utilisateurs ny font pas attention, mais dautres vont tout simplement voir ailleurs. Dans le cas dun site de vente en ligne, cela peut avoir un impact financier trs rapide. Il faut donc penser surveiller la validit des certificats. Le plug-in check_http propose cette fonctionnalit qui ne doit pas tre oublie. On utilise pour cela le paramtre -C. Celui-ci demande une valeur reprsentant le nombre de jours de validit restants partir duquel il commence avertir (WARNING) lutilisateur. Si, malgr ces avertissements, le certificat nest pas chang temps, le retour passe CRITICAL. Voici un exemple dun tel test :
Vrification de la validit dun certificat
$USER1$/check_http -H www.google.com -C 20 OK - Certificate will expire on 05/02/2009 17:02.

Dans cet exemple, on demande tre averti si le certificat expire dans moins de vingt jours. Au vu du site surveill, un rsultat autre que OK aurait t tonnant.
PIGE Les certificats se cachent partout
Il ne faut pas croire que seuls les services web utilisent des certificats. Toutes les applications faisant appel SSL peuvent en exploiter. Certaines architectures avec plusieurs nuds, comme les serveurs dannuaires Active Directory, y font appel. Si les certificats sur ces serveurs ne sont plus valides, les clients ne les utilisent plus. Parmi ces clients on peut citer, par exemple, les serveurs de messagerie lectronique de lentreprise. Si ces deux services ne dialoguent plus, cela peut avoir un impact important. Il faut dresser une liste et surveiller tous les certificats, mmes signs par une autorit interne. Le plug-in check_tcp propose, en plus de check_http, un tel test avec son paramtre -D.

Jouer un scnario plus complexe avec Webinject

Parfois, tester la connexion une page ne suffit pas. Les applications web deviennent de plus en plus complexes. Si lapplication utilise une base de donnes, laccs une unique page nest pas reprsentative de ltat global de lapplication. Dans ce genre de situation, tester un vritable scnario de connexions et de transaction dans une application peut tre utile. Si lopration arrive son terme, cest que tout fonctionne correctement.

84

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Par exemple, sur un site de vente en ligne, il peut tre intressant de dfinir un compte de test. Ce compte neffectue pas rellement de vritable transaction. Si une mthode de vrification permet de simuler un client qui, en utilisant ce compte, effectue une commande, alors ce test est reprsentatif de ltat du site de vente en ligne.
check_http

ne permet pas de raliser ce type de test. Cette sonde est conue pour faire une unique requte. Pour les tests plus complexes, une nouvelle sonde est ncessaire. Il existe une application lgre, nomme WebInject, servant crer et jouer des scnarios de connexions des sites.
OUTIL Webinject pour jouer des scnarios web
Application crite en Perl et pesant moins de 100 Ko, Webinject permet de dfinir une srie daccs des pages tout en conservant, pendant toute la session, des informations comme les cookies. Cette fonctionnalit permet de simuler un vritable client HTTP. Lapplication a le bon got de ne pas ncessiter dinstallation ; il suffit de dcompresser larchive. B http://nagios-fr.org/wiki/integration/webinject

La syntaxe de dfinition du scnario est fournie dans deux fichiers XML : config.xml et testcases.xml. Le premier permet de dfinir lenvironnement de connexion, par exemple la prsence dun proxy. Il est galement possible (et recommand) de demander WebInject de se comporter comme nimporte quelle sonde Nagios. Il suffit dajouter la valeur <reporttype>nagios</reporttype> dans ce premier fichier. Il fait ensuite rfrence au second fichier qui dcrit les tapes de la vrification. Le second fichier XML dfinit des entits case qui sont des successions de tests. Les demandes peuvent tre de type get ou post. Pour chaque rsultat, on peut rcuprer une valeur dans le retour pour le transfrer aux tests suivants. Cest particulirement pratique pour les variables comme SESSION. Exemple de scnario Voici un exemple de vrification dune application web. Supposons que la premire page fournit un identifiant de session :
config.xml
<testcasefile>testcases.xml</testcasefile> <useragent>WebInject Application Tester</useragent> <timeout>10</timeout> <globaltimeout>20</globaltimeout> <proxy>http://proxy:3128</proxy> <reporttype>nagios</reporttype>

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

85

testcases.xml
<testcases repeat="1"> <case id="1" description1="Connexion sur Application" method="get" url="http://www.myapplication.com/login.php" parseresponse='SESSION="|"' verifypositive="Login" errormessage="Impossible de se connecter sur la page de login" /> <case id="2" description1="Authentification sur Application" method="post" url="http://www.myapplication.com/Authentication.php" postbody="user=test&password=superpass&session={PARSEDRESULT}" verifynegative="User unknown" errormessage="Impossible de se connecter avec test" /> <case id="3" description1="Navigation sur Application" method="get" url="http://www.myapplication.com/Application.php" verifypositive="Bienvenue sur le site de vente" errormessage="Impossible de naviguer sur le site, mme authentifi" /> <case id="4" description1="Test de commande" method="post" url="http://www.myapplication.com/DemandeAchat.php" postbody="objet=voiture&couleur=rougevif" verifypositive="Votre commande est effectue" errormessage="Impossible de passer une commande de voiture" /> </testcases>

Pour lancer la commande, il suffit dappeler webinject.pl avec comme argument -c, suivi du fichier de configuration dfinissant le test :

86

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Lancement de WebInject
webinject.pl -c config-nagios.xml WebInject OK - All tests passed successfully in 0.19 seconds |time=0.19;20;;0

En cas derreur lors dun des tests, elle retourne :

Erreur dtecte par WebInject
WebInject CRITICAL - Impossible de se connecter avec test |time=0.138;20;;0

PRATIQUE Obtenir des informations sur la connexion au site avec HttpFox

Dans le cas prcdent, il tait primordial dutiliser la variable SESSION propose par la premire page. Pour lidentifier, il faut observer les en-ttes retourns lors dune connexion fructueuse. Firefox fournit une extension pratique, nomme HttpFox, pour analyser des applications web. Elle permet de sauvegarder les changes HTTP lorsque lon navigue sur un site. Elle est trs pratique pour mettre au point ces tests de vrification.

Cette application simple et lgre permet de dfinir simplement des tests avancs. Elle est dune grande utilit pour vrifier les applications web qui sont de plus en plus nombreuses. Nous remarquons de plus quelle retourne le temps qui a t ncessaire pour effectuer lensemble des tests. Cet indicateur peut tre important dans la dtection de performances dgrades sur lapplication web.
PRATIQUE Les applications SOAP
De nombreuses applications utilisent le protocole SOAP pour la communication entre leurs diffrents composants. SOAP est bas sur HTTP. WebInject est capable de procder des tests des diffrentes parties des applications en effectuant des tests de bas niveau.

Test des services DNS

DANS LA VRAI VIE Un service ne pas oublier
Sil est un service indispensable que lon oublie souvent de superviser, cest bien le DNS. On le pense, tort, infaillible. Cependant, en cas de problme, cest tout le systme dinformation qui tombe.

Certains soucis peuvent survenir sur les DNS des entreprises. Parfois, certains enregistrements peuvent tre supprims, que ce soit cause dune fausse manipulation ou

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

87

dun bug logiciel. Si lenregistrement est celui dun serveur critique, les problmes peuvent saccumuler trs rapidement. cause du cache DNS prsent sur les machines, si un administrateur cherche voir si lenregistrement fonctionne toujours, sa requte risque dtre traite par le cache de son ordinateur. Il ne voit donc pas que le serveur ne peut plus rpondre pour cet enregistrement pour les nouveaux clients.

Mthode de supervision des DNS

La supervision de ce service est trs simple. Nous allons, pour tous les enregistrements importants, faire des requtes rgulires vers les serveurs DNS et vrifier quils peuvent encore rpondre correctement. Le plug-in qui effectue ces requtes est check_dns. Il prend en paramtre -H, lenregistrement rcuprer, et -s, le serveur DNS interrog.
PIGE Enregistrements DNS automatiques sous Windows Active Directory
Si le serveur DNS est gr par Active Directory, les serveurs Windows peuvent y enregistrer leur propre entre DNS. Cependant, sur les serveurs ayant plusieurs interfaces rseau, ce mcanisme peut tre plus dangereux quautre chose. Lentre DNS dune interface prive peut par exemple tre mise jour avec les donnes dune interface prive, ce qui peut causer des pertes de connexions pour les utilisateurs. La supervision des entres DNS est importante pour dtecter ce genre de situation difficile reprer.

Exemple de test DNS

Un exemple dinterrogation dun clbre serveur web sur le serveur DNS dun non moins clbre fournisseur daccs donne :
Exemple de vrification dune entre DNS
$USER1$/check_dns -H www.google.fr -s 212.27.40.240 DNS OK: 0,046 secondes de temps de rponse. www.google.fr renvoie 74.125.43.147,74.125.43.103,74.125.43.99,74.125.43.104|time=0,045761s;; ;0,000000

Ici le test vrifie que le serveur 212.27.40.240 est capable de renvoyer un enregistrement pour www.google.fr.

Test des annuaires LDAP

Dans les infrastructures actuelles, les annuaires LDAP ont pris une place prpondrante. Ils centralisent les informations concernant les utilisateurs ; grce eux, finie lpoque o il fallait dupliquer les informations.

88

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Mthode de supervision
Sils sont devenus une pierre angulaire des infrastructures actuelles, il ne faut pas oublier quils sont, comme tous les services, faillibles. Bien souvent, ces annuaires ne sont consultables que si lutilisateur possde un compte. Il faudra donc pour les superviser se connecter avec un compte et rechercher des informations. Il y a de fortes chances quil puisse lire ses propres informations. Si elles sont valides, on peut considrer que lannuaire fonctionne correctement.
PIGE Plusieurs ports de communication
Les annuaires LDAP sont souvent disponibles sur deux ports TCP : 389 et 636. Sur le premier port, il peut accepter, exclusivement ou non, les connexions passant par SSL. Sur le second, seules les connexions SSL sont acceptes. Il ne faut pas oublier de superviser tous les ports de communication des applications. Le port non scuris peut en effet tre ouvert alors que le port SSL nest pas disponible, par exemple cause dun mauvais paramtrage, ou parce que son certificat est expir.

Exemple dinterrogation LDAP

Le plug-in ralisant ce test est check_ldap. Il prend comme argument le serveur interroger avec -H et la requte effectuer avec -b. Il utilise un compte fourni par lutilisateur avec les arguments -D et -P. Il peut se connecter en SSL en utilisant largument -S. Nous supposons ici que le serveur LDAP est srv-ldap1. On utilise le compte nagios de lannuaire pour se connecter et on demande ses informations.
Exemple de vrification dun serveur LDAP
check_ldap -H srv-ldap1 -b "cn=nagios,ou=users,dc=society,dc=com" -D nagios@society.com.com -P "password"

Le rsultat est similaire ce qui suit :

Rsultat de la vrification
LDAP OK - 0.015 seconds response time|time=0.014801s;;;0.000000

Le temps de rponse retourn en donne de mtrologie est utile pour suivre ltat de charge des annuaires.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

89

Supervision du DHCP
Les systmes dinformation regroupent un nombre important de composants. Parmi ceux-ci, les postes clients sont les plus nombreux. Leur configuration rseau est fortement facilite par lutilisation du protocole DHCP.

Un lment indispensable pour les clients

Ce protocole permet de fournir une configuration rseau complte aux clients qui en font la requte. Un serveur DHCP est mis en place sur le rseau. Sil nest plus disponible, les nouveaux clients, ou les anciens qui doivent renouveler leur adresse, sont isols. Son rle est important, car laccs au rseau est une condition indispensable pour que les clients puissent utiliser les ressources du systme dinformation. Sa supervision est tout aussi importante.

Sonde check_dhcp
est utilise dans ce but. Elle effectue une demande DHCPDISCOVER sur le rseau. Si elle reoit en rponse un DHCPOFFER, cela signifie que le serveur DHCP fait toujours son office. tant donn que la sonde ne rpond pas la demande avec un DHCPACK ou un DHCPNACK (acceptation ou refus de ladresse), ceci na pas dimpact sur le service DHCP.
check_dhcp

La sonde

Si plusieurs serveurs DHCP sont disponibles sur le rseau, des problmes peuvent survenir, surtout si la configuration des serveurs nest pas identique. Il est conseill dattribuer une adresse rserve au serveur qui interroge le service. De cette manire, il est possible de vrifier que le serveur dont on attend une rponse rpond bien et quil nous offre ladresse que lon souhaite. Le paramtre -s permet de spcifier la commande ladresse du serveur dont on veut une rponse. Le paramtre -r permet, quant lui, de lever une alerte si ladresse obtenue nest pas celle demande. Enfin, le paramtre -i permet de choisir linterface rseau qui fait la demande.
PRATIQUE Contrles frquents du serveur DHCP
Le DHCP est lune des pierres angulaires des rseaux actuels. moins de migrer en IPv6, les administrateurs ont tout intrt le vrifier trs frquemment afin dtre alert rapidement.

Problmes de droits
Cette sonde a une particularit. Si elle est lance avec lutilisateur retourne une erreur :
nagios,

elle

90

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Erreur de droits avec check_dhcp

check_dhcp -i eth0 Warning: This plug-in must be either run as root or setuid root. To run as root, you can use a tool like sudo. To set the setuid permissions, use the command: chmod u+s yourpluginfile Error: Could not bind socket to interface eth0. Check your privileges...

Une requte DHCP ncessite des privilges root. Le processus de Nagios ne pouvant fonctionner en tant que root, il est ncessaire de donner le droit nagios de lancer cette commande comme sil tait root. Deux solutions sont envisageables dans cette situation : lutilisation de sudo ; le positionnement du bit suid sur check_dhcp.

La commande sudo
Le programme sudo permet de lancer une commande sous le compte root si lutilisateur en a lautorisation. Il na pas besoin de laccs un shell root pour cela. Le fichier de configuration de sudo est /etc/sudoers. Dans ce fichier, la ligne suivante permet dautoriser lexcution en tant que root de la sonde check_dhcp avec nimporte quel argument, sans avoir donner un mot de passe.
Configuration dans sudoers
nagios ALL = NOPASSWD: /usr/local/nagios/libexec/check_dhcp *

Une fois sudo configur, lutilisateur dant de sudo :

Lancement de check_dhcp avec sudo

nagios

peut lancer la commande en la prc-

sudo /usr/local/nagios/libexec/check_dhcp -i eth0 -s 192.168.0.254 -r 102.168.0.1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec.

Dans la configuration de Nagios, la commande doit tre configure avec les chemins complets :
Configuration au sein de Nagios
/usr/bin/sudo $USER1$/check_dhcp -i $ARG1$ -s $ARG2$ -r $ARG3$

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

91

Le bit SUID
Si la commande sudo nest pas disponible, il existe une autre mthode pour que lutilisateur nagios puisse lancer la commande en tant que root. Le bit suid est une fonctionnalit du systme de fichiers. Une fois positionn, ce bit permet un autre utilisateur que le possesseur de lexcutable de le lancer sous lidentit du possesseur. Si ce dernier est root, il a tous les droits. Nimporte quel utilisateur a ces droits, contrairement sudo o la gestion des droits est trs fine. Pour positionner ce bit, il faut utiliser la commande suivante en tant que root :
Placement du bit SUID sur check_dhcp
chown root.nagios check_dhcp chmod ug+s check_dhcp ls -l check_dhcp -rwsr-x--- 1 root nagios check_dhcp

On peut alors lancer simplement la sonde sous le compte nagios :

Lancement de check_dhcp
/usr/local/nagios/libexec/check_dhcp -i eth0 -s 192.168.0.254 -r 102.168.0.1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec.

Cette mthode a pour avantage de ne pas faire appel au chemin /usr/local/nagios/ libexec dans la configuration de sudo.

Supervision de la messagerie
Les systmes dinformation servent grer des informations. Lun des vecteurs dchanges le plus important est, lheure actuelle, lchange par e-mails. Le courriel est devenu indispensable pour beaucoup dutilisateurs. La moindre indisponibilit est directement ressentie par lensemble des utilisateurs et la surveillance de cette application est primordiale. Superviser une messagerie est plutt simple car il existe sur Internet des adresses de destinataires un peu particulires, dites de rebond : lorsquun e-mail est reu une de ces adresses, une rponse est automatiquement envoye. La supervision de toute la chane de messagerie peut se faire facilement. La commande de vrification na qu envoyer un message une ou deux de ces adresses, et attendre ensuite quelques secondes pour obtenir le retour. Les messages de retour sont supprims automatiquement.

92

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

La sonde check_email_delivery est ddie cette tche. Dans lexemple suivant, on suppose que les services SMTP et IMAP sont sur le mme serveur. Dans le cas contraire, des arguments permettent de les spcifier.
Vrification de bout en bout de la messagerie
check_email_delivery -H monserveur --mailto ping@oleane.net,echo@cnam.fr --mailfrom user@local --username user -password secret EMAIL DELIVERY OK - 5 seconds

COMMUNAUT Les adresses de rebond

Les administrateurs peuvent remercier chaleureusement les personnes ayant mis en place ces adresses de rebond. Elles permettent de vrifier simplement lenvoi et la rception de-mails.

Supervision dune base MySQL ou PostgreSQL

Les bases MySQL et PostgreSQL sont des rfrences dans le monde de lopen source. La premire est mme utilise dans la solution que nous mettons en place. Par dfaut, elle est accessible sur le port 3306. Pour la superviser, la sonde check_mysql est tout adapte. Elle ncessite davoir un compte sur la base de donnes. Ce compte a uniquement besoin de droits SELECT sur une base. Elle effectue une connexion la base, que ce soit par le rseau ou par socket Unix suivant la configuration de la base. Dans notre exemple, nous utilisons la connexion rseau. Le compte nagios dont le mot de passe est superpass tente daccder la base nomme nagiosBD.
Vrification dune base MySQL
check_mysql -H monserveur -u nagios -p superpass -d nagiosBD Uptime: 1316 Threads: 1 Questions: 1257 Slow queries: 0 Opens: 25 Flush tables: 1 Open tables: 19 Queries per second avg: 0.955

Pour les bases PostgreSQL, la sonde check_pgsql permet de faire la mme vrification que pour MySQL. L encore, le lancement de la commande est simple :
Vrification dune base PostgreSQL
check_pgsql -d nagiosBD -l nagios -p superpass OK - database nagiosBD (0 sec.)|time=0.000000s;2.000000;8.000000;0.000000

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

93

Lorsque de simples vrifications rseau ne suffisent pas : les agents

Nous venons de voir quelques exemples de tests simples directement accessibles par le rseau. Malheureusement, toutes les informations ne sont pas disponibles de cette manire.

Rle des agents

Par exemple, pour obtenir les informations de charge des serveurs, il faut se placer directement sur ces serveurs. Nagios ne peut pas lancer seul une commande de vrification sur les serveurs distants. Il ne peut que lancer des commandes locales. Nous allons utiliser des agents de supervision sur les lments distants. Ce sont des dmons qui coutent les demandes dinformations de Nagios et lui rpondent. Nous allons voir ici les principaux agents utiliss.
PSYCHOLOGIE Rsistance face aux agents
Les administrateurs systme voient en gnral dun trs mauvais il la mise en place dun agent. Dans le cas dagents open source, ils peuvent vrifier ce qui est lanc, et seront moins enclins sopposer leur installation.

Principaux agents disponibles

Diffrents types dagents existent. Certains ne font que lancer des plug-ins fournis par lutilisateur sur lhte superviser. Dautres proposent en standard une liste de donnes fournir lutilisateur. Dautres encore font les deux. Si les donnes pr-exportes sont pratiques dans un premier temps, elles deviennent vite limites lorsquun administrateur veut mettre en place une supervision avance. Il est alors prfrable de passer par des sondes dposes sur les htes. Elles seront lances par les agents sur demande de Nagios.

NRPE : lancer des plug-ins distance

Commenons notre tude des agents par le plus rpandu dentre eux : NRPE.

94

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Fonctionnement de NRPE
NRPE

est lagent dploy classiquement sur les serveurs de type Unix. Il signifie Nagios Remote Process Executor (excuteur distant de processus Nagios). Il permet Nagios dexcuter distance des plug-ins dposs par ladministrateur. Comme Nagios, NRPE ne sait lui-mme rien faire. Les plug-ins dposs sont identiques ceux prsents sur le serveur de supervision. NRPE sert dintermdiaire entre Nagios et ces sondes.

Nagios lance comme plug-in, sur son serveur, lexcutable check_nrpe. Celui-ci envoie une requte de supervision lagent NRPE. Elle correspond une entre dans la configuration de lagent. Cette entre contient un script lancer, avec ses arguments. Le dmon lance le plug-in et retourne le rsultat check_nrpe. Ce rsultat est compos du code retour du plug-in et des lignes de sortie, comme nimporte quelle sonde Nagios. Lexcutable check_nrpe transmet tout simplement ces informations Nagios. Nous pouvons galement noter que la communication entre check_nrpe et le dmon NRPE se fait travers un flux SSL. Il ny a donc pas de risque quun pirate rcupre des donnes sensibles. Le diagramme suivant rsume ce fonctionnement.

Figure 41 Une requte NRPE

Configuration du dmon
Le fonctionnement tant connu, concentrons-nous sur la configuration de NRPE.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

95

Fichier de configuration principal

Paramtres du dmon Lagent NRPE ne possde au dpart quun seul fichier de configuration. Il se trouve, sur une installation par dfaut, dans /usr/local/nagios/etc. On peut utiliser les paramtres suivants : server_port : port TCP sur lequel le serveur coute les requtes de Nagios. Par dfaut, sa valeur est 5666 ; server_address : IP sur laquelle le dmon coute. Si non spcifie, il coute sur toutes les adresses disponibles ; nrpe_user : utilisateur sous lequel le dmon est excut. Tout comme pour Nagios, il nest ni possible, ni recommand dutiliser root ; allowed_hosts : liste des IP des serveurs pouvant effectuer des demandes au dmon. On y place logiquement ladresse du serveur Nagios ; dont_blame_nrpe : autorise ou non lutilisation darguments envoys par le client au dmon NRPE ; command_timeout : temps en secondes laiss aux commandes lances pour sexcuter. Si le temps imparti est coul, la commande est tue. Dfinition des commandes On doit galement configurer les commandes lancer lors dune interrogation. Cela se fait grce aux entres du type suivant :
Dfinition dune commande dans nrpe.cfg
command[nom]=chemin_du_plugin paramtres

Il faut attribuer chaque commande lancer un nom avec lequel check_nrpe va lappeler. On doit indiquer le chemin complet vers la sonde lancer. En ce qui concerne les arguments, on peut laisser lutilisateur les spcifier lors de la demande. Cela nest autoris que si le paramtre dont_blame_nrpe a la valeur 1. Tout comme dans la configuration de Nagios, les arguments sont dfinis par $ARG1$, $ARG2$, etc.
SCURIT Utilisation des variables
Le paramtre dont_blame_nrpe permet dautoriser ou non le passage de paramtres pour les clients NRPE. Il porte bien son nom. Laisser la possibilit aux clients dutiliser leurs propres arguments peut tre un problme de scurit. Certains utilisateurs pourraient chercher en abuser. Le dmon NRPE limite les caractres utilisables, enlevant les plus dangereux. De plus, il filtre les IP. Le choix de laisser ou non les variables est laiss ladministrateur.

96

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Voici deux exemples de dfinition pour observer la charge des serveurs grce la commande check_load. Celle-ci sera tudie plus en dtail au chapitre 14.
Dfinition standard
command[load]=/usr/local/nagios/libexec/check_load -w 1,1,1 -c 2,2,2

Voici la mme commande, mais en utilisant des arguments variables :

Dfinition avec arguments
command[load]=/usr/local/nagios/libexec/check_load -w $ARG1$ -c $ARG2$

Grer les exceptions de configuration

Dans le cas o lon doit dployer un grand nombre dagents sur ses serveurs, on utilise le mme fichier de configuration. Cependant, certains dentre eux prsentent des exceptions. Par exemple, sur certains vieux systmes, une information peut ne pas tre disponible. Un plug-in fonctionnant correctement sur le reste du parc ny fonctionne alors pas. Si on laisse la mme commande dappel, on risque de se retrouver avec une excution systmatiquement en erreur. Les exceptions dans la configuration des agents NRPE doivent tre possibles. Si lon nutilise pas de moyen de gestion de configuration volu sur ses serveurs, on doit utiliser le paramtre include du fichier de configuration nrpe.cfg. Ce paramtre permet dappeler un autre fichier de configuration comme sil tait plac la suite. Pour grer les exceptions, nous crons un fichier de configuration nomm specifique.cfg situ ct de nrpe.cfg. Nous y plaons nos exceptions en redfinissant les commandes que nous souhaitons modifier. Dans le fichier nrpe.cfg, le fichier est inclus en dernire ligne :
Inclusion du fichier spcifique au serveur
include=/usr/local/nagios/etc/specifique.cfg

Si une commande est prsente deux fois dans le fichier de configuration, cest sa dernire occurrence qui est prise en compte. Dans notre cas, puisque lon a appel specifique.cfg la fin de nrpe.cfg, ce sont les valeurs spcifiques qui priment. On a tout loisir de redfinir, si besoin, des commandes ou den dfinir de nouvelles. Une mthode de gestion de configuration consiste avoir le mme fichier nrpe.cfg pour tous les htes. Seuls les fichiers specifique.cfg sont particuliers chaque

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

97

nud. Lors de la mise jour du nrpe.cfg commun sur tous les serveurs, on ne craint plus de perdre de la configuration spcifique un nud.
CONFIGURATION Notion de pack de plug-ins
Des systmes similaires ont les mmes plug-ins de supervision. Nous y dposons donc les mmes scripts. Lensemble des scripts communs un systme dexploitation sappelle un pack de plug-in et il est contenu dans nrpe.cfg. Tous les autres plug-ins doivent tre rfrencs dans specifique.cfg. Lors de la mise jour du pack, il suffit de copier le nouveau nrpe.cfg sur tous les serveurs.

Lancement de lagent
Lagent nest en fait compos que dun binaire nrpe, de son fichier de configuration et des plug-ins quil lance. Il peut tre lanc travers xinetd, mais cette possibilit nest pas tudie ici. Dans le cas dun lancement en mode standalone, il faut le lancer comme ceci :
Lancement de NRPE
/usr/local/nagios/bin/nrpe -d -c /usr/local/nagios/etc/nrpe.cfg

NRPE sexcute sous lidentit de lutilisateur spcifi dans son fichier de configuration, condition que celui-ci ne soit pas root. En effet, dans ce cas, il ne se lance pas. On utilise gnralement un compte non privilgi nomm nagios.

Exemple dinterrogation
Depuis le serveur Nagios, on lance la commande check_nrpe avec comme paramtres lhte sur lequel est lanc NRPE, ainsi que la commande dsire (en loccurrence, la commande rfrence par check_load). Plaons-nous tout dabord dans la situation o lutilisateur ne peut pas fournir darguments la commande :
Interrogation de lagent NRPE
check_nrpe -H srv-web1 -c load OK - Charge moyenne: 0.51, 0.28, 0.28|load1=0.510;1.000;2.000;0; load5=0.280;1.000;2.000;0; load15=0.280;1.000;2.000;0; echo $? 0

Dans le cas o lon peut fournir des arguments, nous avons :

98

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Interrogation avec arguments

check_nrpe -H srv-web1 -c load -a 1,1,1 2,2,2 OK - Charge moyenne: 0.29, 0.36, 0.31|load1=0.290;1.000;2.000;0; load5=0.360;1.000;2.000;0; load15=0.310;1.000;2.000;0; echo $? 0

Dans les deux cas, du point de vue de Nagios, le rsultat est le mme que celui dune commande locale. Il en retire les mmes informations, savoir le code retour et les lignes de donnes.

SSH peut galement faire laffaire

Comme dit prcdemment, les administrateurs systme ne sont pas enclins installer des agents. Il existe des mthodes pour sen passer.

Lancement de commandes travers SSH

NRPE permet de lancer des commandes distance, ce qui peut galement tre ralis grce SSH. Ce protocole permet de lancer une commande sur un serveur distant. De plus, le code retour et les messages de sortie sont conservs travers lutilisation de SSH. Si nous reprenons notre exemple prcdent en utilisant SSH, nous obtenons :
Lancement dune commande par SSH
ssh srv-web1 '/usr/local/nagios/libexec/check_load -w 1,1,1 -c 2,2,2'

Nous avons besoin dun compte sur srv-web1. Nous utilisons le compte nagios que nous aurions utilis pour NRPE. La commande renvoie ce qui suit :
Rsultat
OK - Charge moyenne: 0.25, 0.35, 0.35|load1=0.250;1.000;2.000;0; load5=0.350;1.000;2.000;0; load15=0.350;1.000;2.000;0; echo $? 0

Nous obtenons le mme rsultat que si nous lavions lanc travers NRPE.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

99

Problme de lauthentification
Cette mthode prsente un problme : le serveur distant demande une identification. Lorsquon fait des des tests, on peut saisir un mot de passe ; ce nest pas le cas si la commande est lance par Nagios. L encore, le protocole SSH propose une solution. Il est possible dutiliser une mthode dauthentification par chiffrement asymtrique. Sans entrer dans le dtail, lutilisateur cre deux cls lies : une publique, quil peut fournir volont ; une prive, quil doit garder jalousement. La cl prive peut dchiffrer des messages cods avec la cl publique de lutilisateur. Si un serveur envoie un message alatoire chiffr avec la cl publique dun utilisateur, seul ce dernier peut retrouver le message original grce sa cl prive. Cela permet dauthentifier formellement un utilisateur.
Pour une introduction au chiffrement cl publique, lire : R Lucas, PGP et GPG, Eyrolles 2006

Pour gnrer les cls, on utilise la commande ssh-keygen :

Gnration de cls pour SSH
ssh-keygen -t rsa

Lorsque le programme demande une passphrase, il faut la laisser vide. Il sagit dun mot de passe chiffrant la cl prive. Nous ne pouvons pas lutiliser ici car il faudrait la saisir chaque fois que lon utilise la cl, ce qui nest pas possible au sein de Nagios.
SCURIT Cl SSH sans phrase secrte
Les cls SSH sans phrase de passe sont peu populaires chez certains administrateurs qui craignent une compromission de laccs au serveur. Pour pallier ce problme, on peut souvent utiliser ssh-agent. Cependant, ssh-agent et ssh communiquent par le biais dune variable denvironnement, variable que Nagios supprime avec toutes les autres avant de lancer les sondes. La mise en place de ssh-agent est donc dlicate. Le compte nagios est de toute faon un compte sans privilges, ce qui rduit les risques encourus du point de vue de la scurit.

Cette commande gnre les deux cls. La cl prive est ~/.ssh/id_rsa.pub.

~/.ssh/id_rsa,

la publique

100

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Il faut dployer la cl publique sur le serveur distant. Nous utilisons pour cela le programme ssh-copy-id qui facilite grandement la tche :
Dploiement de cls sur un compte distant
ssh-copy-id -i ~/.ssh/id_rsa.pub nagios@srv-web1

Une fois la cl en place, lutilisateur sur le serveur matre peut se connecter sans mot de passe sur le serveur srv-web1. Il peut galement y lancer des commandes.

Utilisation de SSH la place de NRPE

Lutilisation de SSH en lieu et place de NRPE est possible, mais il faut en mesurer limpact. Avec SSH, nous ne pouvons pas utiliser les exceptions de configuration comme nous lavons fait avec le fichier specifique.cfg. De plus, la charge de calcul dune requte SSH est plus importante que celle dune demande NRPE. Pour utiliser SSH, il faut que lutilisateur nagios du serveur Nagios ait un accs au shell sur les serveurs distants. Si des mthodes permettent de limiter lutilisation de ce shell, elles sont cependant lourdes grer. SSH a pourtant un atout non ngligeable : il est dj prsent sur la quasi-totalit des serveurs Unix. Il vite davoir dployer un nouvel agent. Il faut cependant que les plug-ins de supervision soient prsents. Les administrateurs peuvent choisir entre ces deux solutions celle quils prfrent suivant leurs facilits de dploiement dun agent ou au vu des problmatiques de charge sur le serveur central.

SNMP : une liste de donnes exportes

Il est presque impossible de trouver un lment rseau sur lequel on peut installer les applications que lon souhaite. Ce sont de vritables botes noires. La mise en place de NRPE tant impossible, voyons comment les superviser.

Le protocole SNMP et les OID

Pour obtenir des informations sur ltat dun quipement rseau, il faut passer par un dmon qui est lui prsent sur la quasi-totalit des quipements rseau : SNMP (Simple Network Management Protocol, protocole simple de gestion rseau).

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

101

Ce protocole peut tre dcoup en deux fonctionnalits principales : un client obtient des informations en lanant une requte au serveur. On nomme cela le poll SNMP ; llment rseau envoie une information sous la forme dune alerte un dmon distant. Ce sont les traps ou alertes SNMP. Ce mcanisme sera tudi dans un autre chapitre car il fait partie des mthodes passives. Les informations exportes par SNMP sont nombreuses et peuvent varier suivant le constructeur. Elles sont indexes sur un arbre dont chaque entre est un OID (Object unique IDentifier). Elles sont regroupes dans des fichiers nomms MIB. Ils reprsentent la cartographie des donnes de larbre. Chaque constructeur possde une branche. Il peut y faire figurer les informations quil souhaite. Certaines branches sont standardises. On peut citer pour exemple la MIB HOSTRESOURCES. Cest dans cette dernire que nous allons prendre la plupart de nos informations. Dans les versions les plus rpandues de SNMP, les versions 1 et 2c, la scurit est base sur un mot de passe nomm communaut. La valeur par dfaut de ce mot de passe est public. Il est diffus en clair sur le rseau. La version 3, la plus rcente, possde de vritables mcanismes de scurit. Elle nest malheureusement pas encore largement dploye.

Exemple dinterrogation SNMP

Nous cherchons obtenir lutilisation CPU sur un routeur administrable ladresse 192.168.0.254. La communaut utilise est public. Le plug-in rcupre lOID .1.3.6.1.2.1.25.3.3.1.2 qui correspond la charge CPU et compare la valeur aux deux seuils que nous lui avons spcifis.
Rcupration de la charge CPU par SNMP
check_snmp_switch_cpu.pl -H 192.168.0.254 -C public -w 50 -c 60 SNMP_ENVIRONMENT OK : CpuUtil=10%|CpuUtil=10%

SNMP sur les serveurs

Les serveurs possdent galement des services SNMP. Ils exportent les valeurs de la MIB HOST-RESOURCES. Celle-ci contient les valeurs classiques comme lutilisation des processeurs, de lespace disque, de la mmoire ou du trafic rseau.

102

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Si, dans les quipements rseau, lutilisation du SNMP est impose, ce nest pas le cas dans le cadre des systmes dexploitation. Les informations disponibles par ce biais sont limites. On y trouve des valeurs classiques qui suffisent dans une partie des cas. Dans de nombreuses situations, elles ne sont pas suffisantes. Sur certains systmes, la seule information disponible propos de la mmoire est lutilisation de la mmoire virtuelle. Celle-ci regroupe la mmoire physique et lespace dchange. Lorsque celui-ci est utilis, il est bien souvent trop tard. Un tel indicateur nest pas suffisant. Des plug-ins ddis lancs par des agents sont plus appropris.
MTHODE SNMP, un bon dbut
Les agents SNMP tant fournis par les systmes dexploitation, les administrateurs ne sopposent pas leur activation. Cela peut tre pratique dans un premier temps pour leur montrer les avantages de la supervision. Une fois conquis, les administrateurs demanderont des amliorations qui ncessiteront un vritable agent. Ils ne sopposeront plus son installation.

NSClient++ : des plug-ins et des donnes

Un client un peu particulier est disponible sur les environnements Windows. Il regroupe en son sein un agent NRPE et des informations dj exportes, comme le fait SNMP. Il est bas sur des modules sous forme de DLL. Lun dentre eux porte le nom NRPE. Il est utilis comme agent du mme nom au sein de NSClient++. Tout comme pour son pendant Unix, il ne dispose pas, par dfaut, de sonde. Ladministrateur doit lui en fournir. Dautres modules exportent nativement des donnes. On peut dresser la liste des principales, qui permettent de faire un rapide tour de ltat du systme. espace disque ; utilisation des processeurs ; utilisation de la mmoire ; tat des services. Deux clients sont utiliss : check_nrpe pour les excutables lancs par lagent ; check_nt pour les interrogations des autres modules.

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

103

Mise en place
Lagent possde un excutable dinstallation. Il sinstalle par dfaut dans le rpertoire C:\Program Files\NSClient++. Pour ceux qui souhaitent automatiser linstallation, il suffit de dposer les fichiers de lagent dans un rpertoire et de lancer la commande suivante :
Installation de NSClient++
NSClient++ /install

Pour le dmarrer, il suffit de lancer le service du mme nom. Le module NRPE coute sur le port classique 5666/TCP. Les autres modules sont sur le port 12489/TCP. La configuration est galement dcoupe en deux parties, une pour chaque lment de lapplication. Elle se trouve dans le fichier NSC.ini. La configuration et lutilisation de lagent NRPE sont identiques celles de la version UNIX, nous ny reviendrons pas. La configuration du reste de lagent commence par la dclaration des modules utiliss. On les place dans la partie [modules] du fichier de configuration. Voici un exemple de configuration contenant les modules les plus classiques:
Configuration des modules
[modules] FileLogger.dll CheckSystem.dll CheckDisk.dll NSClientListener.dll NRPEListener.dll CheckEventLog.dll CheckWMI.dll

Vient ensuite la partie [Settings] o se trouvent les clients autoriss dialoguer avec lagent et la dfinition dun mot de passe si besoin. Voici un exemple pour un serveur Nagios dont ladresse est 192.168.0.2 :
Paramtres de scurit
[Settings] password=superpassword allowed_hosts=192.168.0.2 use_file=1

104

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Le paramtre use_file permet de signaler NSClient++ de prendre ses paramtres dans le fichier de configuration plutt que dans la base de registre. Cette dernire utilisation est viter, la fois du point de vue de la facilit dadministration et pour unifier ladministration des diffrents agents sous Windows et sous Unix.

Un peu plus que des valeurs immdiates

Pour certains indicateurs, comme la charge dun processeur, dfinir une valeur comme incorrecte est complexe. Cette valeur est trs volatile. Un pic dutilisation nest pas critique, alors quune valeur plus faible mais constante est signe de contention. Le module des tests CPU rcupre rgulirement la charge des processeurs sur la machine. Il propose ensuite les moyennes et valeurs maximales lutilisateur sil le demande. Ce dernier a alors plus de facilit surveiller cet indicateur plus complexe quil ny parat.

Importance de WMI
Une grande source dinformations Windows implmente la norme WBEM (Web-Based Enterprise Management) sous le nom WMI. Elle prsente sous la forme de tables les informations du systme et de certaines applications compatibles. Lutilisateur peut effectuer des recherches dans ces tbles grce une syntaxe proche du SQL. Un systme de filtres WHERE est galement disponible pour faciliter les recherches complexes. Lors des premiers contacts avec les tables exportes nativement par le systme Windows, les administrateurs sont impressionns par leur nombre. Le systme expose presque toutes ses informations par ce biais. Le site de documentation MSDN de Microsoft savre dune aide prcieuse. Un outil nomm ScriptomaticV2 est disponible sur ce site. Il permet dnumrer et dinterroger simplement toutes les tables disponibles sur le systme.
SCURIT Le besoin de droits levs
Malheureusement, les requtes WMI de supervision systmes demandent des droits maximum sur le serveur. Les agents neffectuant que des Select et filtrant les demandes, le risque est acceptable.

Exemple dinterrogation WMI Par exemple, pour obtenir lespace libre disponible sur les disques, il faut lancer la requte suivante :

Premier niveau de test : rponse dun nud sur le rseau CHAPITRE 4

105

Requte WMI pour lespace disque

Select FreeSpace From Win32_LogicalDisk

Si nous nous limitons la valeur pour le disque C:, la requte devient :

Requte avec filtre
Select FreeSpace From Win32_LogicalDisk Where DeviceID = 'C:'

Nous obtenons :
FreeSpace=2120848896

Le rsultat est en octets, soit ici environ 2 Go despace libre sur le lecteur C:.
Les valeurs les plus importantes des tables WMI seront exposes dans un prochain chapitre.

Pour lancer la requte avec NSClient++, il suffit de lancer, depuis le serveur de supervision, la commande suivante :
Requte WMI depuis un client
check_nrpe -H $HOSTADDRESS$ -c CheckWMIValue -a 'Query=SELECT FreeSpace FROM Win32_LogicalDisk WHERE DeviceID="C:"' MinCrit=1000000000

En un mot
Ltape la plus simple de la supervision consiste superviser les lments distants directement par le rseau. Diverses mthodes existent. De la plus lgre qui consiste vrifier louverture dun port la simulation complte dun client, ladministrateur a le choix. Lorsque les informations ne sont pas disponibles directement, lutilisation dun agent simpose. Suivant les systmes considrs, les possibilits sont varies.

5
Installation et configuration : premier test de quelques serveurs web
Aprs avoir vu les grands principes de Nagios, tentons une premire mise en place de loutil. Pour cela, nous allons prendre une situation simple : la supervision de serveurs web.

Objectifs de cette mise en place

Les grands principes de Nagios ont t vus dans les prcdents chapitres : la configuration des lments superviss ; les contacts prvenir en cas de problme et le mode opratoire associ ; les commandes de vrification des htes et services distants ; les diffrentes phases dordonnancement. Tout ceci va nous permettre dinstaller notre premier environnement de supervision. Pour cela, nous allons installer Nagios et sa console de supervision standard. Les lments superviss seront simples. Ce sont des serveurs web installs sur des serveurs GNU/Linux. Nous allons mettre en place une supervision des sites publis, mais galement des serveurs qui les sous-tendent.

108

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Premire installation : simplicit

Nagios est un outil trs complet. Commenons par une premire mise en place trs simple afin de nous familiariser avec ses grands principes.

Choix du systme
Nagios peut tre install sur de nombreux environnements Unix. Afin de limiter les surprises et dtre le plus standard possible, il est recommand de linstaller sur Linux. Ce systme dexploitation trs rpandu est disponible dans de nombreuses distributions. Nous ne pouvons pas dtailler linstallation sur toutes les distributions possibles. En dresser la liste remplirait dj ce livre. Nous allons utiliser un systme CentOS. Il sagit dune version totalement libre du systme RedHat. Ce dernier est le plus rpandu dans les entreprises.
Ces deux distributions sont totalement compatibles au niveau des binaires. CentOS est une compilation des sources de RedHat dont on a retir les logos et nom de RedHat.

La version utilise est CentOS 5.2. Les utilisateurs de distributions diffrentes comme Debian ou Suse devront adapter leur systme les paquetages prsents. Les grandes lignes de linstallation sont les mmes.

Installation par le gestionnaire de paquetages

Linstallation du systme est ici minimale. Ceci permet de prsenter les paquetages ncessaires linstallation et lutilisation de Nagios. Les fonctionnalits du systme telles que le pare-feu ou bien SeLinux seront dsactivs. Dans cette premire installation, la mise en place de Nagios et des outils connexes se fera par le gestionnaire de paquetages de la distribution. Ce choix est motiv par la simplicit requise pour une premire mise en place.

Avantages de linstallation par paquetage

Les avantages de ce mode dinstallation sont nombreux. Lors des mises jour de Nagios, une simple demande au gestionnaire de paquetages met jour toute linstallation de ladministrateur. Tous les prrequis de fonctionnement de loutil sont grs simplement. Les versions installes par ce biais ont dj t testes par dautres administrateurs.

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

109

En passant par le gestionnaire de paquetages, les chemins dinstallation des diffrents fichiers de lapplication respectent les chemins dfinis par la distribution. Si lon choisit de compiler soi-mme le code source, il arrive souvent que lapplication choisisse elle-mme ses chemins, en contradiction avec les recommandations des administrateurs. Heureusement, on peut dfinir ces chemins lors de la phase prliminaire la compilation. Les chemins tant communs aux diffrentes installations de tous les administrateurs de la plante, trouver de laide est simple. Ce point est prendre en considration lors du choix de linstallation par paquetage ou par compilation. Dans la majorit des situations, linstallation par paquetage suffit aux administrateurs.

Quelques dsavantages
Certains inconvnients font toutefois surface. Ladministrateur utilisant les versions empaquetes (ou, en franglais, packages) des outils est soumis aux choix de celui qui a prpar le paquetage. Si, par exemple, une fonctionnalit rcente na pas t intgre au paquetage, ladministrateur na aucun moyen de la rajouter aprs installation. Il devra soit renoncer lutiliser, soit procder une compilation manuelle. Dans ce cas, il perdra les avantages de la gestion de paquetages. Le cas inverse est galement envisageable. Si le crateur du paquetage a configur une fonctionnalit non souhaite par dadministrateur, deux situations sont possibles : la fonctionnalit ralentit lutilisation mais ne cause pas de souci de fonctionnement ladministrateur ; la fonctionnalit cause de graves problmes lutilisation. Cette seconde situation est trs rare, mais peut arriver. L encore, ladministrateur doit choisir de revenir ou non la compilation manuelle. Si ladministrateur souhaite apporter des modifications ou amliorations loutil, il ne pourra pas utiliser la version dj compile. La modification des sources implique de compiler nouveau loutil. Cette situation nest pas courante dans le cas de Nagios mais elle existe. Ladministrateur doit dj avoir des notions de dveloppement en langage C. ll doit galement avoir des besoins particuliers que Nagios ne couvre pas en standard. Dans cette situation, une installation par paquetage nest pas possible.

Installation des paquetages

Les paquetages de Nagios ne sont pas disponibles en standard sur CentOS. Ils sont prsents dans les rpertoires de RPMFORGE, qui est un dpt de paquetages pour les distributions RedHat et assimiles.

110

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

La dclaration de RPMFORGE dans yum se fait en installant un paquetage. On rcupre ce paquetage sur un site web :
Rcupration du paquetage rpmforge
wget http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release0.3.6-1.el5.rf.i386.rpm

PRATIQUE Utilisation dun proxy avec wget

wget peut utiliser un proxy HTTP. Pour cela, il faut paramtrer la variable denvironnement http_proxy. Par exemple, pour utiliser le proxy proxy.localdomain.com sur le port 3128 avec lutilisateur User et le mot de passe Pass, on utilisera la commande : export http_proxy="http://user:Pass@proxy.localdomain.com:3128"

Le repository (dpt) ajout yum expose une cl pour authentifier ses paquetages. Il est ncessaire de limporter :
Installation de la cl de rpmforge
rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Une fois la cl en place, le paquetage de RPMFORGE peut tre install :

Installation du paquetage
rpm -Uvh rpmforge-release-0.3.6-1.el5.rf.i386.rpm

On peut alors installer Nagios et ses plug-ins :

Installation de Nagios par les paquetages
yum install nagios nagios-plugins nagios-plugins-nrpe

Ces outils possdent des dpendances. Voici la liste des paquetages ncessaires au bon fonctionnement de Nagios :
Liste des paquets ncessaire Nagios
fping, gd, libtool-ltdl, perl-Crypt-DES, perl-Digest-HMAC ,perl-NetSNMP, perl-Socket6

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

111

Principaux fichiers de configuration de Nagios

Linstallation de Nagios par les paquetages ne dpose pas les fichiers dans le rpertoire classique /usr/local/nagios/. Les fichiers de configuration sont placs dans /etc/nagios. Le fichier de configuration principal est dautres fichiers de configuration :
/etc/nagios/nagios.cfg.

Il fait appel

Inclusion des autres fichiers de configuration dans nagios.cfg

cfg_file=/etc/nagios/objects/commands.cfg cfg_file=/etc/nagios/objects/contacts.cfg cfg_file=/etc/nagios/objects/timeperiods.cfg cfg_file=/etc/nagios/objects/templates.cfg cfg_file=/etc/nagios/objects/localhost.cfg

La configuration de Nagios est standard. Voici les principaux arguments :

Principaux arguments de nagios.cfg
log_file=/var/log/nagios/nagios.log status_file=/var/nagios/status.dat status_update_interval=10 nagios_user=nagios check_external_commands=1 command_file=/var/nagios/rw/nagios.cmd service_inter_check_delay_method=s max_concurrent_checks=0 enable_notifications=1 process_performance_data=0

tudions un peu cette configuration. Le rpertoire /usr/local/nagios/var est chang en /var/nagios pour les fichiers temporaires et /var/log/nagios pour les fichiers journaux (ou journaux). Lutilisateur faisant fonctionner Nagios est nagios. Il a t cr lors de linstallation du paquetage. Les commandes externes sont prises en compte. Le fichier de commandes est /var/nagios/rw/nagios.cmd. Il ny a pas de limite dans le nombre de vrifications lances en parallles. Les notifications sont envoyes aux administrateurs et enfin les donnes de performances ne sont pas prises en comptes. Pour cette premire mise en place, ces paramtres ne seront pas modifis. Seuls les lments superviser le seront.

112

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Mise en place de la vrification

Le fichier de configuration principal ayant t rempli, regardons le reste de la configuration.

Description de lenvironnement supervis

Nous prenons comme cibles de supervision des serveurs web dnomms srv-web1, srv-web2, srv-web3 et srv-web4. Ce sont des serveurs Apache sur une base Linux, qui hbergent les mmes sites web. Ils ont respectivement les adresses 192.168.0.1, 192.168.0.2, 192.168.0.3 et 192.168.0.4. Le serveur de supervision est install sur la machine srv-nagios dadresse 192.168.0.5. Les systmes des serveurs sont sous la responsabilit de d.brossard et e.belleville. Ces administrateurs grent galement les services web hbergs sur ces serveurs. Ils souhaitent tre avertis de tous les problmes qui surviennent sur ces machines. La supervision doit porter sur les systmes et laccs aux pages HTML par les utilisateurs.

Configuration des contacts

La configuration commence par celle des contacts devant tre avertis et, en tout premier lieu, par le moyen dalerte souhait.

Commandes denvoi de-mails

Les deux contacts que nous allons dfinir sont nos deux administrateurs. Ils veulent tre avertis par le biais dun e-mail pour chaque problme. Les alertes doivent porter sur les htes et les services quils hbergent. Regardons, dans la configuration standard de Nagios, la dfinition des commandes envoyant un e-mail aux administrateurs. Elles figurent dans le fichier /etc/nagios/objects/commands.cfg :
Commandes denvoi par e-mail
# 'notify-host-by-email' define command{ command_name notify-host-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$ }

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

# 'notify-service-by-email' define command{ command_name notify-service-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ }

113

Le fonctionnement de ces commandes est simple malgr leur longueur. Elles ralisent lenvoi de le-mail en deux tapes. Tout dabord, elles gnrent le texte du message. Lors de lappel la commande pour lenvoi dune notification, les macros sont modifies par les valeurs du contexte de lerreur. Par exemple, dans le cas dune erreur sur le nud srv-web1, la macro $HOSTNAME$ est modifie en srv-web1. Voici un exemple de texte gnr pour une alerte relative un hte qui nest plus disponible :
Exemple de texte envoy par e-mail
***** Nagios ***** Notification Type: PROBLEM Host: srv-web1 State: DOWN Address: 192.168.0.3 Info: CRITICAL - Socket timeout after 10 seconds Date/Time: Mon Feb 2 22:06:03 CET 2009

Une fois ce texte gnr, il est envoy sur lentre standard de la commande /bin/ mail. Cette dernire sert tout simplement envoyer un e-mail. Le paramtre -s sert paramtrer le titre, qui est galement appel avec des macros. Le dernier argument correspond ladresse du destinataire du message. Un service denvoi de-mail est ncessaire sur le serveur de supervision. ce propos, sur la distribution installe ici, cest le programme Sendmail qui est install par dfaut. Il est fortement recommand de passer un programme plus rcent et de meilleure rputation : Postfix. Cette opration est fort simple :
Pour une introduction Postfix : R Bck et al., Monter son serveur de mails sous Linux, Eyrolle 2006

114

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Installation de Postfix
yum install postfix /etc/init.d/sendmail stop chkconfig sendmail off chkconfig --add postfix /etc/init.d/postfix start

Une fois ce remplacement fait, il est conseill de tester lenvoi dun e-mail directement en ligne de commande comme le ferait lutilisateur nagios. Une fois connect avec ce compte, il suffit dappeler la commande /bin/mail.
Test denvoi de-mail
su nagios /usr/bin/printf "%b" "message de test" | /bin/mail -s "mon titre" monemail@mondomaine.com

Si le message arrive bien dans la boite aux lettres de lutilisateur concern, le test est valid. Dans le cas contraire, il faut vrifier dans le fichier journal de Postfix pourquoi lenvoi a chou. Le fichier journal en question est /var/log/maillog.

Configuration des priodes

Les priodes de temps sont ncessaires pour la configuration des autres lments. Les priodes sont dfinies au sein du fichier suivant :
/etc/nagios/objects/timeperiods.cfg.

La priode qui nous intresse ici est de 24 heures sur 24, 7 jours sur 7.
Priode la plus large possible
define timeperiod{ timeperiod_name 24x7 alias 24H a Day, 7 Days a Week monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 sunday 00:00-24:00 }

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

115

CONFIGURATION Exemples de priodes de temps

Le fichier timeperiods.cfg propose en standard de nombreux exemples de syntaxe pour les priodes de temps. Lexemple des priodes de temps excluant les vacances est pratique pour servir de base la dfinition des priodes de travail des administrateurs.

Configuration des contacts dans contacts.cfg

Les commandes de notification sont accroches un ou plusieurs contacts. Nous avons ici deux contacts : d.brossard et e.belleville. Leur configuration se fait au sein du fichier /etc/nagios/objects/contacts.cfg. Les deux administrateurs veulent tre avertis 24 heures sur 24. Ils souhaitent avoir tous les tats derreur des htes et des services. Les commandes de notification sont celles que nous venons de voir. Voici la configuration de nos deux contacts :
Configuration de d.brossard et e.belleville
define contact{ contact_name d.brossard alias David Brossard email d.brossard@mydomain.com service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,c,r host_notification_options d,u service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email } define contact{ contact_name e.bellevlle alias Eric Belleville email e.bellevlle@mydomain.com service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,c,r host_notification_options d,u service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email }

Si les contacts souhaitent tre avertis, paralllement aux e-mails, par dautres mthodes, il suffit de rajouter la nouvelle commande de notification aprs notifyservice-by-email et notify-host-by-email, en sparant simplement les commandes par une virgule.

116

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Configuration des htes

La configuration se poursuit avec celle des nuds devant tre surveills.

Commande de vrification des htes

Une fois la configuration des contacts faite, nous pouvons passer celle des htes. Pour cela, il faut dfinir une mthode de supervision de ltat des nuds. Ceux-ci sont des serveurs Linux. Au chapitre prcdent, nous avons vu que la supervision du port SSH suffit dcider si un nud est UP ou DOWN. La commande utilise pour cela est commands.cfg.
Configuration de check_tcp
# 'check_tcp' command definition define command{ command_name check_tcp command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$ } check_tcp.

Sa dfinition figure dans le fichier

La variable $USER1$ est dfinie dans le fichier /etc/nagios/resource.cfg :

Dfinition de $USER1$
$USER1$=/usr/lib/nagios/plugins

Il peut tre utile de tester la commande directement en ligne de commande avant de linscrire dans les fichiers de configuration. Ici, le test porte sur ltat du serveur srv-web1 :
Test de check_tcp
/usr/lib/nagios/plugins/check_tcp -H 192.168.0.1 -p 22 TCP OK - 0.016 second response time on port 22|time=0.015545s;;;0.000000;10.000000

Le test est concluant. Cette commande fonctionne correctement lorsquelle est lance par lutilisateur nagios. Cette vrification est rapide et devrait prcder toute configuration dune nouvelle commande au sein de Nagios.
PRATIQUE Des options nombreuses
La sonde check_tcp regorge doptions plus ou moins utiles. Lancer simplement check_tcp -h prsente toutes ses possibilits aux administrateurs.

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

117

Configuration des htes

Crons le fichier de configuration dans lequel nous allons dfinir nos serveurs. Ce fichier va se situer aux cts du fichier de configuration du serveur de supervision. Nommons-le hosts.cfg. La supervision des nuds se fait sur la priode 24 heures sur 24, 7 jours sur 7. La commande de vrification est lance toutes les 2 minutes. En cas de problme, 4 tests supplmentaires sont lancs, espacs dune minute. Si, au bout de cette priode de temps, le problme persiste, une notification est envoye aux administrateurs. Cet envoi est rpt toutes les deux heures jusqu ce que le serveur redevienne disponible. La configuration de nos quatre nuds est la suivante :
Configuration des htes
define host{ name srv-web1 host_name srv-web1 alias srv-web1 address 192.168.0.1 check_period 24x7 check_interval 2 retry_interval 1 max_check_attempts 5 check_command check_tcp!22 notification_period 24x7 notification_interval 120 notification_options d,u,r contacts d.brossard,e.belleville notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 0 retain_status_information 1 retain_nonstatus_information 1 } define host{ name srv-web2 host_name srv-web2 alias srv-web2 address 192.168.0.2 check_period 24x7 check_interval 2 retry_interval 1 max_check_attempts 5 check_command checktcp!22

118

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE
notification_period 24x7 notification_interval 120 notification_options d,u,r contacts d.brossard,e.belleville notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 0 retain_status_information 1 retain_nonstatus_information 1 } define host{ name srv-web3 host_name srv-web3 alias srv-web3 address 192.168.0.3 check_period 24x7 check_interval 2 retry_interval 1 max_check_attempts 5 check_command checktcp!22 notification_period 24x7 notification_interval 120 notification_options d,u,r contacts d.brossard,e.belleville notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 0 retain_status_information 1 retain_nonstatus_information 1 } define host{ name srv-web4 host_name srv-web4 alias srv-web4 address 192.168.0.4 check_period 24x7 check_interval 2 retry_interval 1 max_check_attempts 5 check_command checktcp!22 notification_period 24x7 notification_interval 120 notification_options d,u,r contacts d.brossard,e.belleville

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 failure_prediction_enabled 1 process_perf_data 0 retain_status_information 1 retain_nonstatus_information 1 }

119

Autant le dire de suite, cette configuration est assez imposante.

PIGE Avoir au minimum un groupe dhtes
Un pige classique dans les premires mises en place de Nagios consiste ne pas dfinir de groupe dhtes. Cette fonctionnalit sera tudie dans un prochain chapitre. Ici, le nud localhost dfinissant le serveur de supervision est en standard inclus dans un groupe dhtes.

Configuration des services

La dernire tape de la configuration concerne les services.

Commande de vrification des services web

Les htes sont configurs, il est temps de mettre en place la supervision des services. Ceux-ci vont consister dans un premier temps la supervision des services web. Pour cela, nous allons utiliser la sonde check_http prsente dans le chapitre prcdent. Comme dhabitude, il est conseill de tester en ligne de commande la sonde de vrification avant de la dfinir au sein de Nagios :
Test de vrification web
/usr/lib/nagios/plugins/check_http -I 192.168.0.1 -u / HTTP OK HTTP/1.1 200 OK - 40162 bytes in 1.221 seconds |time=1.221249s;;;0.000000 size=40162B;;;0

Cette commande est dfinie dans le fichier commands.cfg.

Configuration de la commande
define command{ command_name command_line }

check_http $USER1$/check_http -I $HOSTADDRESS$ -u $ARG1$

120

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Configuration des services web

Nous allons configurer les quatre services que nous allons nommer Http. La commande de vrification est lance toutes les 5 minutes. En cas de problme, la priode entre les tests est dune minute. Les tests supplmentaires sont au nombre de 4. ce moment, les notifications sont envoyes si besoin. Les contacts prvenus sont nos deux administrateurs. Les priodes de vrification et de notification sont toutes deux de 24 heures sur 24, 7 jours sur 7. Seuls les deux premiers services sont proposs ici. Nous faisons grce aux lecteurs des deux autres.
Dfinition des services
define service{ host_name srv-web1 service_description Http check_command check_http!/ active_checks_enabled 1 notifications_enabled 1 flap_detection_enabled 1 check_period 24x7 max_check_attempts 5 normal_check_interval 5 retry_check_interval 1 contacts e.belleville,d.brossard notification_options w,c,r notification_interval 180 notification_period 24x7 } define service{ host_name srv-web2 service_description Http check_command check_http!/ active_checks_enabled 1 notifications_enabled 1 flap_detection_enabled 1 check_period 24x7 max_check_attempts 5 normal_check_interval 5 retry_check_interval 1 contacts e.belleville,d.brossard notification_options w,c,r notification_interval 180 notification_period 24x7 }

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

121

Dfinition des fichiers de configuration dans nagios.cfg

Les fichiers services.cfg et hosts.cfg nexistaient pas. Il est ncessaire de les rajouter dans le fichier nagios.cfg. Pour cela, nous allons utiliser la fonction cfg_file. Celle-ci prends un chemin complet vers les fichiers de configuration que nous avons dfinis. Lajout peut se faire nimporte o dans le fichier. Il est toutefois conseill de ne pas dissminer ces inclusions. Dans notre cas, nous allons rajouter les deux appels aprs celui du fichier localhost.cfg.
Inclusion des nouveaux fichiers de configuration
cfg_file=/etc/nagios/objects/localhost.cfg cfg_file=/etc/nagios/objects/hosts.cfg cfg_file=/etc/nagios/objects/services.cfg

Lordre de dfinition nest pas important. Les services peuvent tre dfinis avant les nuds ; tant que, la fin de la vrification de la configuration, tous les lments sont bien prsents, Nagios arrivera faire le lien.

Lancement de Nagios
Nous avons dfini les contacts, une priode de temps, nos htes et enfin les services. Il est important, avant tout lancement de Nagios, de tester la configuration. Mme dans le cas de modifications mineures, ce test est important. Il est rapide et vite de se retrouver sans supervision le temps de corriger en urgence la configuration errone active par mgarde. Largument -v de nagios permet de raliser cette vrification. Une manire plus simple consiste passer par le script situ sous /etc/init.d et lui demander de sen charger.
Vrification de la configuration
/etc/init.d/nagios checkconfig

Dans le cas dune configuration comportant une ou plusieurs erreurs, lappel renvoie le message :
Message derreur
Running configuration check... CONFIG ERROR! Check your Nagios configuration.

122

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Il est alors ncessaire de corriger la configuration. Pour obtenir des messages derreurs plus prcis, on doit faire appel directement Nagios :
Vrification manuelle
/usr/bin/nagios -v /etc/nagios/nagios.cfg

Nous obtenons :
Rsultat de la vrification
Nagios 3.0.6 Copyright (c) 1999-2008 Ethan Galstad (http://www.nagios.org) Last Modified: 12-01-2008 License: GPL Reading configuration data... Running pre-flight check on configuration data... Checking services... Checked 12 services. Checking hosts... Error: Contact 'd.brossarr' specified in host 'srv-web1' is not defined anywhere! [] Total Warnings: 0 Total Errors: 1 ***> One or more problems was encountered while running the pre-flight check...

Ici, lerreur est simplement due un nom mal orthographi. Si la configuration est valide, le message est :
Configuration valide
/etc/init.d/nagios checkconfig Running configuration check... OK.

Une fois la configuration valide, Nagios peut tre dmarr. Pour cela, ladministrateur doit le lancer en tant que root :
Lancement de Nagios
/etc/init.d/nagios start

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

123

ce qui retourne le message :

Starting nagios: done.

On peut vrifier simplement que le processus liste des processus de lutilisateur nagios :
ps -fu nagios

nagios

est bien lanc en dressant la

En cas de succs, le processus /usr/bin/nagios doit tre visible :

UID PID PPID CMD nagios 1913 1 /usr/bin/nagios -d /etc/nagios/nagios.cfg

Il peut tre utile de suivre le fichier de log de Nagios dans un premier temps. Dans cette installation, ce fichier figure dans /var/log/nagios. Pour le suivre en temps rel, il suffit de lancer la commande tail :
Lecture du fichier de log de Nagios
tail -n 100 -f /var/log/nagios/nagios.log

Un lancement correct ressemble :

Entres de log lors du lancement de Nagios
[1233605889] [1233605889] [1233605889] [1233605889] Nagios 3.0.6 starting... (PID=2496) Local time is Mon Feb 02 21:18:09 CET 2009 LOG VERSION: 2.0 Finished daemonizing... (New PID=2497)

Nous remarquons que chaque ligne commence par un horodatage exprim en temps Unix, cest--dire le nombre de secondes coules depuis le 1er janvier 1970. Si ce format est pratique pour le traitement des fichiers logs, il nest pas trs lisible pour un tre humain. Pour changer cela, nous utilisons une fonctionnalit de Perl. Cet interprteur na pas besoin dun script utiliser. Les commandes lancer peuvent tre passes aprs largument -pe. La fonction localtime permet de transformer un temps Unix en chane plus lisible pour un tre humain. Associe aux expressions rgulires, une simple commande donne au fichier de log de Nagios une forme plus agrable :

124

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Lecture plus adapte du fichier de log

tail -f nagios.log | perl -pe 's/(\d+)/localtime($1)/e' -

Nous obtenons :
[Mon [Mon [Mon [Mon Feb Feb Feb Feb 2 2 2 2 21:18:09 21:18:09 21:18:09 21:18:09 2009] 2009] 2009] 2009] Nagios 3.0.6 starting... (PID=2496) Local time is Mon Feb 02 21:18:09 CET 2009 LOG VERSION: 2.0 Finished daemonizing... (New PID=2497) status.dat

Nous vrifions que Nagios a bien gnr un fichier

ls -thor /var/nagios/status.dat

dans /var/nagios :

-rw-rw-r-- 1 nagios 24K Feb 2 21:31 /var/nagios/status.dat

Test de dtection dun problme

Nagios lanc, il est utile de vrifier quil effectue bien les envois de notifications lorsquun problme survient. Nous allons tester les alertes portant sur les services et celles portant sur les nuds. Nous allons simplement arrter un service web puis le serveur qui lhberge. Notre cobaye sera srv-web1. Larrt du service web est simple :
Dclenchement volontaire dune erreur
/etc/init.d/httpd stop

Suivons un peu le fichier journal de Nagios :

Enregistrement de lerreur dans Nagios
[Mon Feb 2 21:51:03 2009] SERVICE ALERT: srv-web1;Http;CRITICAL;SOFT;1; Connection refused

Lerreur a t dtecte. Au bout de 4 erreurs supplmentaires, les notifications sont leves :

Envoi des notifications
[Mon Feb 2 21:51:03 2009] SERVICE ALERT: srv-web1;Http;CRITICAL;SOFT;1; Connection refused

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

[Mon Feb 2 Connection [Mon Feb 2 Connection [Mon Feb 2 Connection 21:52:03 2009] SERVICE ALERT: srv-web1;Http;CRITICAL;SOFT;2; refused 21:53:03 2009] SERVICE ALERT: srv-web1;Http;CRITICAL;SOFT;3; refused 21:54:03 2009] SERVICE ALERT: srv-web1;Http;CRITICAL;SOFT;4; refused

125

[Mon Feb 2 21:55:03 2009] SERVICE NOTIFICATION: e.belleville;srv-web1; Http;CRITICAL;notify-service-by-email;Connection refused [Mon Feb 2 21:55:03 2009] SERVICE NOTIFICATION: d.brossard;srv-web1; Http;CRITICAL;notify-service-by-email;Connection refused

Il est utile de vrifier que les e-mails sont bien partis du serveur vers les botes aux lettres des administrateurs.
Trace de la notification dans Postfix
Feb 2 22:09:30 localhost postfix/smtp[4455]: 0ED6314CBCB: to=<e.belleville@mydomain.com>, relay=mail.mydomain.com[192.168.0.253]:25, delay=2.5, delays=0.06/0.01/ 0.53/1.9, dsn=2.0.0, status=sent (250 2.0.0 OK 1233608970 23si2535605mum.52)

Les commandes de vrification envoient bien les e-mails. Un contrle rapide, directement dans les botes des administrateurs, permet de sassurer que les messages sont bien forms.

Complexifions un peu larchitecture

Notre premire mise en place de Nagios effectue, commenons rajouter des lments superviser dans le but davoir des informations plus prcises.

Supervision des systmes

La premire extension de la supervision doit naturellement porter sur les systmes.

Importance de la supervision systme

Avec la supervision que nous avons mise en place, les administrateurs sont avertis lorsquun problme intervient sur les services web. Sans mettre en place la supervision des systmes, les administrateurs ont bien du mal identifier la source du problme. Ils sont obligs de se connecter la machine et dy procder une supervision manuelle.

126

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Avec une supervision des systmes, les problmes peuvent tre dtects avant quils ne causent de vrais soucis. Un disque qui se remplit est rapidement dtect et les administrateurs peuvent faire du mnage quand lespace disque occup atteint 95 %.
Les indicateurs prendre sur les systmes en compte sont nombreux. Les plus importants sont traits au chapitre 14. Nous allons en voir ici quelques-uns. Pour plus de dtails quant leur fonctionnement, le lecteur peut se rfrer au chapitre ddi.

Supervision du serveur de supervision

Un nud important Lorsquun administrateur met en place un systme de supervision, il pense de suite surveiller les applications ; viennent ensuite les systmes ; la supervision rseau arrive rapidement aprs. Il nest pas rare, dans ces conditions, doublier un lment important : le serveur de supervision lui mme ! Ce serveur est pourtant critique pour la solution de supervision. tant situ sur ce serveur, Nagios na pas de mal obtenir les informations sur ltat du systme. La configuration standard fournie avec Nagios propose des sondes et une configuration pour la machine locale. Regardons un peu ce qui est supervis et comment la configuration est organise. Configuration de lhte Dans la configuration par dfaut, la dfinition de lhte et de ses services rsident dans le mme fichier. Si cette mthode est possible pour grer un unique hte, il devient trs complexe de sy retrouver lorsquon augmente le nombre de nuds. Le fichier correspondant la machine locale est /etc/nagios/objects/localhost.cfg. Le serveur de supervision est rfrenc sous le nom localhost. Sa dfinition est :
Dfinition de localhost
define host{ host_name localhost alias localhost address 127.0.0.1 notifications_enabled 1 notification_period 24x7 check_period 24x7 max_check_attempts 10 check_command check-host-alive notification_period workhours

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

notification_interval 120 notification_options d,u,r contact_groups admins }

127

CONFIGURATION Configuration simplifie pour localhost

La configuration figurant dans le fichier localhost.cfg nest pas exactement celle prsente ici. Elle est plus condense car elle utilise des fonctonnialits de configuration que nous aborderons ultrieurement.

La commande de vrification est check-host-alive. Elle effectue un simple test de rponse un ping. Il y a peu de chances quelle retourne un jour une erreur. Si cest le cas, cela signifie que le serveur de supervision est tomb : Nagios aurait alors bien du mal lancer ses vrifications. Cette vrification est tout de mme lance. Nagios voit en fait le serveur localhost comme nimporte quel hte et il na aucune connaissance de son placement sur ce dernier. Lhte est reli au groupe de contacts admins. Ce groupe comporte un seul membre : nagiosadmin. Celui-ci a pour adresse e-mail nagios@localhost, cest--dire ladresse associe au compte faisant fonctionner Nagios. Ladministrateur doit remplacer ce compte par celui dun ou plusieurs administrateurs rels afin que les alertes ne soient pas perdues. La configuration des notifications est un peu diffrente de ce que nous avons mis en place. Dans la configuration propose pour localhost, la priode de notification est workhours au lieu de 24x7. Cette priode est dfinie par les horaires de travail de 9 h 17 h, du lundi au vendredi. Si le test dun serveur comme celui-ci dcle un incident en dehors de cette priode de temps, les administrateurs doivent en tre informs. Il est conseill de modifier workhours en 24x7. Services standard accrochs au serveur de supervision Les services dfinis par dfaut sur le serveur de supervision sont les suivants : PING : test de rponse de la machine un ping ; Root Partition : vrification de lespace disponible sur la partition / ; Current Users : nombre dutilisateurs connects au systme ; Total Processes : nombre total de processus lancs sur le serveur ; Current Load : vrification de la charge de la machine. Les services dfinis ne sont pas exempts de dfaut comme nous allons le voir. Sils permettent de se familiariser avec la supervision systme, ils se rvlent vite limits. Le service PING na pas de vraie raison dtre. Il est une duplication du test effectu au niveau de lhte et il est conseill de le supprimer.

128

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Le service Root Partition ne surveille que la partition /. Si cet espace est trs important pour le systme, ce nest pas forcment celui qui se remplit le plus souvent. Un espace /var rempli aura galement des effets dramatiques sur les applications et le risque quil se remplisse est beaucoup plus lev que pour /. Il nest pas conseill de crer un service par partition. Nous verrons par la suite une mthode plus simple pour superviser les disques. Les services Current Users et Total Processes ne sont pas particulirement utiles. Les cas dutilisateurs connects directement sur un serveur Unix sont de plus en plus rares. De mme, les administrateurs prfrent surveiller le nombre de processus dune application particulire plutt que le nombre total de processus dun systme. Le service Current Load est, quant lui, beaucoup plus utile. Il permet de savoir quand un serveur est trop charg. La configuration de la commande est malheureusement inapproprie dans beaucoup de situations. Avec les valeurs par dfaut, un serveur standard pourrait tre surcharg sans que les administrateurs ne soient au courant. Le chapitre 14 explique comment fonctionne cet indicateur et comment choisir les valeurs dalerte.

Prise en compte de localhost par Nagios

Une fois le fichier /etc/nagios/objects/localhost.cfg dclar au sein de nagios.cfg, la configuration peut tre teste. Lors de la vrification de configuration de Nagios, on peut contrler que le nouvel hte est bien pris en compte en observant la ligne Checked X hosts :
Vrification de lajout du nud
/usr/bin/nagios -v /etc/nagios/nagios.cfg Checking hosts... Checked 5 hosts.

Nos quatre serveurs web ajouts au serveur de supervision : le compte est bon. Une fois la configuration valide, le dmon peut tre redmarr. Pour cela, deux solutions existent : procder un arrt / redmarrage de Nagios ; lui faire recharger sa configuration. La premire mthode est un simple appel au service nagios , dabord avec une commande stop puis avec une commande start. La seconde mthode consiste envoyer un signal HUP Nagios. Ce signal contraint Nagios relire sa configuration. Pour obtenir le numro de processus de Nagios, il suffit de lire le fichier dfini par la variable lock_file. Sur notre environnement, sa valeur est /var/run/nagios.pid.

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

129

Pour recharger Nagios, il suffit dutiliser la commande :

Rechargement de Nagios
kill -HUP `cat /var/run/nagios.pid`

On peut alors vrifier dans le fichier journal de Nagios quil a bien reu la demande.
Vrification du rechargement
[...] lancement de Nagios [Tue Feb 3 21:30:37 2009] Finished daemonizing... (New PID=1914) [...] lancement de la commande kill [Tue Feb 3 21:36:04 2009] Caught SIGHUP, restarting... [Tue Feb 3 21:36:04 2009] Nagios 3.0.6 starting... (PID=1914) [Tue Feb 3 21:36:04 2009] Local time is Tue Feb 03 21:36:04 2009 [Tue Feb 3 21:36:04 2009] LOG VERSION: 2.0

Nous remarquons que le processus garde le mme PID.

Supervision des systmes distants

La supervision de la machine Nagios tant en place, nous pouvons maintenant nous pencher sur celle des serveurs web. Installation de lagent et des sondes La supervision des systmes distants est primordiale. Pour une premire mise en place, nous allons utiliser lagent NRPE, qui est install par paquetages. Pour cela, sur les quatre serveurs, il est ncessaire de lancer :
Installation de NRPE
yum install nagios-nrpe nagios-plugins-nrpe

Sa configuration seffectue dans le fichier /etc/nagios/nrpe.cfg, dont le format a t tudi au chapitre prcdent. On doit y modifier le paramtre allowed_hosts pour lui affecter ladresse du serveur Nagios. Si le paramtre nest pas chang, un appel au client check_nrpe naboutit pas :
Erreur dauthentification
/usr/lib/nagios/plugins/check_nrpe -H srv-web1 -n CHECK_NRPE: Error receiving data from daemon.

130

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Ce message sexplique par le fait que le client a pu ouvrir le port avec lagent, mais que celui-ci a immdiatement ferm la connexion. Le client nayant reu aucune donne, il lve une alerte. Une fois le paramtre dfini, lagent peut tre dmarr :
Dmarrage de lagent
/etc/init.d/nrpe start

Depuis le serveur Nagios, on peut vrifier que la communication est possible :

La communication est valide
/usr/lib/nagios/plugins/check_nrpe -H srv-web1 NRPE v2.5.1

Un appel check_nrpe sans demande de commande renvoie la version de lagent distant. Choix dune connexion SSL ou non Il est important de noter que lagent possde deux modes de fonctionnement : avec SSL ; sans SSL. Ce mode de fonctionnement ne peut tre fix dans le fichier de configuration. Il est choisi lors de la compilation de lagent. Au lancement de lagent, on peut voir dans quel mode celui-ci fonctionne grce la commande :
Vrification de la configuration de NRPE
/usr/sbin/nrpe -c /etc/nagios/nrpe.cfg

Cette commande ne lance pas rellement lagent. Si elle renvoie la ligne

SSL/TLS

Available: Anonymous DH Mode, OpenSSL 0.9.6 or higher required,

lagent fonctionne en mode SSL. Une autre mthode consiste vrifier les bibliothques lies au binaire nrpe. Si la bibliothque SSL est prsente, lagent lutilise :

Prsence de la librairie SSL

ldd /usr/sbin/nrpe | grep ssl libssl.so.6 => /lib/libssl.so.6 (0x00552000)

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

131

PRATIQUE Vrification des bibliothques

La commande ldd est trs pratique pour vrifier les liens entre les excutables et les bibliothques. Lorsquune application ne se lance pas, il peut tre pratique de la vrifier laide de ldd. Il est courant doublier des bibliothques ncessaires certaines sondes. La commande ldd peut identifier les bibliothques manquantes.

La commande check_nrpe doit choisir dutiliser ou non une connexion SSL avec lagent. Le paramtre -n permet de demander une connexion en clair. Dans le cas dune tentative de connexion chiffre sur un agent qui ne gre pas SSL, le client renvoie le message :
Connexion impossible sans SSL
CHECK_NRPE: Socket timeout after 10 seconds.

Avec le paramtre -n, la connexion stablit correctement :

Connexion avec SSL
check_nrpe -H srv-web1 -n NRPE v2.5.1

Il est fortement conseill dutiliser les connexions SSL entre les clients et les agents pour les protger des regards indiscrets. La configuration des clients nen est que plus simple : le paramtre -n nest pas utilis. Commandes exportes Lagent exporte les mmes commandes que pour le serveur de supervision. Une partie de la configuration ncessite une adaptation :
Commandes standard de NRPE
command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1 command[check_disk2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hdb1

Il est conseill davoir un unique test pour lensemble des disques. Pour cela, il faut supprimer les deux lignes et rajouter :
Nouvelle dfinition
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10

132

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

puis redmarrer lagent. Dans cette configuration, une partition sous la barre des 20 % despace disponible lvera un avertissement, moins de 10 % une alerte critique. Configuration des services Lagent tant configur et lanc, il est temps de configurer les commandes de vrification et les services. Tout dabord, avant dditer les fichiers de configuration, il est ncessaire de passer par une tape de test de commande directement avec un shell. Depuis le serveur Nagios, nous allons utiliser la commande check_nrpe pour dialoguer avec les agents. Le compte utilis sur les serveurs est nagios. Nous vrifions que le dialogue stablit correctement avec les agents et quils effectuent bien les vrifications.
Interrogation distante de NRPE
/usr/lib/nagios/plugins/check_nrpe -H srv-web1 -c check_disk DISK OK - free space: / 4139 MB (75% inode=96%); /var 8282 MB (97% inode=99%); /boot 75 MB (81% inode=99%); /dev/shm 251 MB (100% inode=99%);| /=1357MB;5776;5786;0;5796 /var=212MB;8938;8948;0;8958 / boot=17MB;78;88;0;98 /dev/shm=0MB;231;241;0;251

Cette tape tant valide, nous pouvons passer la configuration. La commande check_nrpe est ncessaire et nous la rajoutons donc au fichier commands.cfg :
Dfinition de check_nrpe
define command{ command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }

La configuration des services y fait appel. Largument fourni en $ARG1$ est la commande lancer par lagent. Par exemple, la configuration du service Load sur le serveur srv-web1 est :
Dfinition du service de vrification de charge par NRPE
define service{ host_name srv-web1 service_description Load check_command check_nrpe!check_load active_checks_enabled 1 notifications_enabled 1 flap_detection_enabled 1 check_period 24x7 max_check_attempts 5

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

normal_check_interval 5 retry_check_interval 1 contacts e.belleville,d.brossard notification_options w,c,r notification_interval 180 notification_period 24x7 }

133

Il suffit de recopier cette configuration pour les autres commandes et htes.

Mise en place de la console de supervision

Une brique utile dans la solution de supervision
Avec la solution que nous avons actuellement mise en place, les administrateurs sont informs des alertes par e-mail. Ils ne peuvent pas suivre en temps rel ltat des serveurs. Ceci ncessite de mettre en place une console de supervision.

Une interface qui volue

Nagios vient en standard avec une interface web. Avant la version 3.1 de Nagios, cette interface tait code en C. Elle tire ses informations du fichier status.dat. Depuis, une interface en PHP est fournie. Le systme que nous avons choisi ne propose pas la nouvelle interface, dont la mise en place est un peu plus complexe que lancienne : il est conseill de commencer par lancienne.
REMARQUE Une nouvelle interface
Lorsque ce livre sera publi, il y a de fortes chances pour que la nouvelle interface soit devenue la norme. Si elle amliore ses dfauts de conception comme la lecture du fichier status.dat, elle ne soccupe toujours que de la visualisation des informations. Elle na que peu dintrt face aux interfaces que nous verrons au chapitre 11.

Mise en place de linterface web

Linterface disponible nativement avec le paquetage nagios de CentOS 5.2 est lancienne version, crite en scripts CGI C. Cette version suffit pour une premire mise en place. Les fichiers de linterface ncessitent le programme Apache pour fonctionner et prsenter les rsultats aux administrateurs. Nagios tant utilisable sans son interface, linstallation du serveur web nest pas un prrequis. Linstallation dApache se fait par :

134

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Installation dApache
yum install httpd

Quant aux fichiers de linterface de Nagios, ils sont situs dans : /etc/nagios : fichiers de configuration de linterface ; /usr/share/nagios : fichiers de linterface, par exemple les images ; /var/log : fichiers de log ; /usr/lib/nagios/cgi : fichiers CGI de linterface. Linterface ne doit pas tre disponible pour tout le monde. Elle repose sur lauthentification dApache. Le fichier contenant les comptes et mots de passe des utilisateurs est /etc/nagios/htpasswd.users. Pour modifier les entres dun utilisateur existant ou en crer un nouveau, il faut utiliser loutil htpasswd :
Modification du mot de passe de nagiosadmin
htpasswd -c /etc/nagios/htpasswd.users nagiosadmin

Le fichier de configuration de linterface de Nagios est /etc/nagios/cgi.cfg. La configuration suivante permet lutilisateur nagiosadmin dagir depuis linterface.
Configuration du CGI de Nagios
# Utiliser l'authentification use_authentication=1 # Acceder aux informations systeme authorized_for_system_information=nagiosadmin # Acceder a la configuration authorized_for_configuration_information=nagiosadmin # Lancer des commandes authorized_for_system_commands=nagiosadmin # Observer les hotes et services authorized_for_all_services=nagiosadmin authorized_for_all_hosts=nagiosadmin

Pour se connecter linterface, ladministrateur peut utiliser son navigateur Internet prfr et ouvrir lURL http://192.168.0.5/nagios. Une fois connect avec le compte nagiosadmin, ladministrateur peut observer librement ltat des htes et des services. Avec les autorisations fournies dans le fichier cgi.cfg, ladministrateur a le droit de forcer des vrifications ou de voir la configuration en place.

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

135

Implications dune augmentation du nombre dlments

Lajout dlments superviss nest pas anodin. tudions-en les effets.

Une augmentation invitable du nombre de nuds

Avec linstallation que nous venons de mettre en place, les deux administrateurs sont heureux dobtenir leurs premires alertes. Si un serveur web est tomb, ils en sont avertis. Si cest uniquement le service web qui nest plus disponible, ils lapprennent galement. Ce premier succs en appelle dautres. Tout dabord, les administrateurs vont vouloir largir le primtre des machines surveilles sans changer celui des types dlments surveills. Lagent va tre dploy sur tous les serveurs web de lentreprise. Chacun deux requiert la mme configuration. Une fois ceci en place, les administrateurs vont demander surveiller de plus en plus dlments sur ces machines, ce qui conduit une forte augmentation du nombre de sondes. Vient ensuite la phase dlargissement de la supervision un nombre encore plus important de machines. Dautres systmes vont tre surveills : avec eux, arrivent de nouvelles mthodes de supervision et de nouveaux agents. Ce cheminement est classique et ses diffrentes phases sont immuables. Ladministrateur en charge de Nagios aura bien du mal contenir lenthousiasme et les demandes de ses collgues. Cest un bon signe quant ladoption de loutil. Il doit cependant faire attention divers piges conscutifs laugmentation du nombre de nuds. Sans un minimum dorganisation, la multiplication des nuds peut rimer avec un curement des administrateurs face la lourdeur de configuration et au nombre dalertes reues. Dressons rapidement la liste des problmes principaux rencontrs par les administrateurs Nagios lors de la mise en place de la solution.

Une augmentation dangereuse du nombre de notifications

Le nombre dlments superviss augmente et, avec lui, le nombre dalertes. Si les administrateurs sont contents de recevoir quelques alertes le matin dans leur boite aux lettres, le seuil entre assez et trop dalertes est vite franchi. Une premire approche de la supervision consiste remonter toutes les alertes : les administrateurs pensent ainsi ne rien rater. Il est vrai que lalerte figure dans la boite e-mail de ladministrateur mais, si elle est perdue au milieu de 300 autres, elle risque tout bonnement de passer inaperue.

136

Introduction la supervision et Nagios avec une mise en place simple PREMIRE PARTIE

Reprenons un peu notre exemple. Nous avons dfini quatre htes distants et, sur chacun deux, six services. Ceci reprsente 24 services qui peuvent remonter une erreur, si on considre que le serveur de supervision na jamais de problme. En cas de coupure rseau, les informations ne sont pas remontes. Si chaque service lve une alerte, les administrateurs reoivent chacun 24 messages. ceci, il faut ajouter quatre alertes dhte si les serveurs sont injoignables. Les notifications sont envoyes toutes les 120 minutes, soit toutes les deux heures. Si le problme survient 18 h, les administrateurs se retrouvent le lendemain matin 8 h avec (8 h - 18 h ) / 2 28 = 196 e-mails dalertes. Et ce, pour quatre malheureuses machines. Si le problme arrive aprs lajout dune vingtaine de serveurs, le nombre de notifications peut atteindre 1 000 e-mails dans la nuit. Aucun administrateur, mme avec la meilleure volont du monde, ne va lire toutes les erreurs. Heureusement, Nagios propose des mcanismes simples permettant de limiter trs fortement ce phnomne. Ils seront tudis au prochain chapitre.

Une lourdeur croissante de la configuration

Arrtons-nous un instant sur la configuration que nous avons mise en place pour nos quatre serveurs. Notre fichier de configuration hosts.cfg est loin dtre petit : il comporte 91 lignes. Le fichier de configuration des services fait quant lui 426 lignes. Que se passe-t-il lorsque le nombre dhtes augmente ? La configuration suit la mme voie. Si nous utilisons les mmes mthodes de configuration pour les nouveaux nuds, le fichier risque de devenir trs imposant, trop pour pouvoir sy retrouver. Une mthode simple permet de limiter la configuration. Pour chaque service, on peut spcifier plusieurs htes sur lesquels sapplique la dfinition. Par exemple, au lieu davoir 70 lignes pour le service Load des srv-web, on peut le rduire en :
Ajout de plusieurs htes par service
define service{ host_name srv-web1,srv-web2,srv-web3,srv-web4 service_description Load check_command check_nrpe!check_load active_checks_enabled 1 notifications_enabled 1 flap_detection_enabled 1 check_period 24x7 max_check_attempts 5 normal_check_interval 5 retry_check_interval 1 contacts e.belleville,d.brossard

Installation et configuration : premier test de quelques serveurs web CHAPITRE 5

notification_options w,c,r notification_interval 180 notification_period 24x7 }

137

Si les gains sont importants, ils ne sont pas suffisants pour atteindre un seuil acceptable en termes de charge de configuration lorsque le nombre dhtes et de services est lev. Ladministrateur risque fortement de perdre pied. Sans matrise complte de la configuration, des lments peuvent faire lobjet dune surveillance superflue. Les administrateurs reoivent des alertes qui ne les intressent pas. Plus grave, des lments peuvent ne pas tre surveills alors que les administrateurs croient le contraire. Si ladministrateur passe son temps changer la configuration, il ne peut pas profiter des bienfaits de la supervision. Bien utilise, la supervision peut lui faire gagner du temps ; passer son temps ladministrer ne rentre pas dans la catgorie utilisation optimale . L encore, Nagios propose de nombreux mcanismes pour aider ladministrateur grer simplement sa configuration. Ils seront tudis au chapitre 8.

En un mot
Cette premire mise en place nous permet de sentir le fonctionnement de Nagios. Pour un faible nombre de nuds, elle est simple. Les administrateurs prennent got trs rapidement la supervision. Laugmentation du primtre de lapplication intervient rapidement et suivant deux axes : le nombre de nuds ; le nombre de services surveills par hte. Les problmes surviennent lors de la phase dexpansion et aprs. Mal contrle, la solution submerge les administrateurs dalertes inutiles. La configuration devenant de plus en plus consquente, ladministrateur Nagios doit passer un temps croissant administrer loutil au lieu de lutiliser. Dautres problmes surviennent, par exemple la gestion des services particuliers. Les alertes passives ne sont pas gres par linstallation actuelle. Ladministrateur na, pour linstant, aucune mthode pour connatre les capacits de traitement de Nagios. Poussons notre tude de cet outil dans les prochains chapitres afin de rpondre toutes ces questions et dobtenir une solution pleinement utilisable.

DEUXIME PARTIE

Options avances de Nagios

Cette seconde partie constitue le cur de louvrage. Aprs une premire exprience, le lecteur a pu constater les limites dune mise en place simple de la supervision. Chaque problme soulev trouve sa solution dans les chapitres de cette partie. Le chapitre 6 permet de diminuer sensiblement le nombre dalertes que reoivent les administrateurs, tout en amliorant leur pertinence. Le chapitre 7 prsente des mthodes de supervision particulires, notamment les alertes passives. Le chapitre 8 sattaque au problme de la gestion de configuration. Sans les mthodes prsentes, la configuration de Nagios devient ingrable si le nombre dlments superviss dpasse la centaine. Le chapitre 9 propose une tude des performances de Nagios et des techniques qui permettent de les amliorer. Si les mthodes du chapitre 9 ne sont pas suffisantes, il faut passer une supervision distribue. Cest le sujet du chapitre 10. Il prsente galement les mthodes pour assurer une haute disponibilit de la supervision avec Nagios. Une fois ces chapitres finis, le lecteur est mme de raliser une mise en place complte de Nagios. Certains points, comme la mtrologie, sont encore complexes grer avec seulement Nagios : il est conseill dutiliser des outils complmentaires, qui seront vus dans la dernire partie.

6
Trier les alertes et amliorer leur pertinence
Les alertes remontes aux administrateurs sont au cur mme des outils de supervision. Nous allons voir comment assurer leur prcision et leur pertinence.

De lintrt de filtrer correctement les alertes

Nous avons dj voqu la ncessit dimpliquer au maximum dans le projet les administrateurs. Ils sont les seuls pouvoir dfinir les rgles de supervision de leurs environnements. Lun des objectifs du chef de projet est de leur faire accepter loutil. Pour cela, la solution doit faciliter leur travail. Les informations doivent leur arriver dj filtres. Dans le cas contraire, ils perdent du temps. Le seuil de tolrance est variable suivant les administrateurs. On peut considrer quune vingtaine dalertes par jour est acceptable pour une grande majorit. Audessus, certains vont commencer se plaindre. Cette limite est notre marge haute. Si lon arrive faire mieux, il ne faut pas sen priver.

142

Options avances de Nagios DEUXIME PARTIE

Concision des alertes

La solution de supervision doit faire gagner du temps aux administrateurs. La concision des alertes est un premier pas dans cette direction.

Concision et prcision
Les administrateurs naiment pas perdre de temps lorsquil sagit dalertes sur leurs serveurs ou lments rseau. Ils veulent que linformation soit nonce rapidement et clairement. Le responsable de la solution de supervision doit donc particulirement veiller la concision des alertes, sans pour autant tomber dans le travers inverse : lalerte doit tre suffisamment explicite pour permettre ladministrateur de savoir do vient le problme. Trop court, un descriptif nindique pas do vient la panne. Les informations gnralement ncessaires sont les suivantes : le nom de la machine sur laquelle le problme est survenu ; llment qui est en faute sur la machine ; la criticit de lalerte ; lheure o le problme a t dtect ; un petit texte explicatif du problme (une ligne ou deux maximum) ; un lien vers la rsolution du problme si elle est disponible. Il nest pas ncessaire dajouter des formules de politesse dans le texte, les administrateurs ne sen vexeront pas. Ils ne trouveront les informations recherches que plus rapidement. Il ne faut pas oublier que les messages dalerte sont souvent envoys par plusieurs biais. Les textes ne devront pas tre les mmes entre un envoi par e-mail et un envoi par SMS. Ce dernier est de taille limite : il faut tre trs concis. Les seules informations y placer sont le nom de la machine, llment qui est en faute, la criticit et lheure du problme.

Exemple de-mail dalerte

Voici un exemple de-mail dalerte pour un incident survenu sur le serveur srv-web2 concernant une utilisation trop importante de la mmoire.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

143

Message par e-mail bien format

***** Nagios Notification ***** State: WARNING Host: srv-web2 Service: Memory Date/Time: 16-12-2008 15:35 Additional Info: WARNING: 92% Used Memory - Total: 8116 MB, used: 7503 MB, free: 613 MB Documentation: clic here.

Exemple de SMS
Dans le cas dun SMS envoy pour le mme problme, on peut envoyer ce qui suit :
Message dans le cas dun SMS
WARNING: srv-web2/Memory at 16-12-2008 15:35

Bien choisir le niveau derreur

Toujours dans le but de faire gagner du temps, la pertinence des alertes est importante. Le niveau derreur permet damliorer cette pertinence.

Criticit
Linformation de criticit des alertes est lune des plus importantes. Un administrateur doit savoir en priorit si lalerte est importante ou non. Il peut tre en train deffectuer une opration sur un serveur et doit pouvoir dterminer rapidement sil a besoin de sinterrompre. Diffrents niveaux dalerte sont dfinis. Ces niveaux changent suivant diffrents critres comme la criticit de la machine et limpact du problme. Ces niveaux se traduisent sur la console par diffrentes couleurs. Celles-ci sont visibles et simples comprendre, et ce sans mme avoir lu la moindre documentation : critique : rouge ; avertissement : orange ; tout va bien : vert.

144

Options avances de Nagios DEUXIME PARTIE

REMARQUE Un arbitrage dlicat pour les administrateurs

Dfinir les niveaux nest pas forcment vident pour ladministrateur de la solution. Un problme peut lui paratre dimpact limit alors que ladministrateur du serveur o le problme a eu lieu sait que ce problme est en fait critique.

Difficult de dfinir les niveaux de criticit

Les administrateurs qui utilisent la solution sont les plus mme de fixer les diffrents niveaux dalerte. Lorsquils dfinissent les lments superviser, ils doivent faire une liste des problmes quils cherchent dtecter. Pour chaque problme, linformation de criticit est importante. Les administrateurs ont tendance tout transformer en erreur critique. Cest une situation viter. Les erreurs critiques seraient trs courantes. La console de supervision serait constamment rouge vif. Une alerte rellement critique passerait alors inaperue. Le rouge doit tre signe quun service aux utilisateurs est en danger et quune intervention immdiate est ncessaire. Linverse est galement dommageable. Si le problme a un impact sur les utilisateurs et les empche de travailler, cest lobjectif mme du service informatique qui est touch. Si ce dernier est soumis contrats avec les autres services, les implications dun tel problme peuvent tre importantes. Dans ce genre de situation, le niveau critique est ncessaire. Les administrateurs ne doivent pas chercher cacher des problmes qui peuvent tre perus par les utilisateurs. Linformation ne reste pas longtemps protge. Des retours au service se font entendre. Si les responsables apprennent quun problme na pas t remont, ils demandent lajouter dans loutil de supervision. Si le niveau de criticit nest pas correct, ils demanderont le faire changer. Sils apprennent que quelquun a essay de faire disparatre lerreur en douce, les consquences peuvent tre fcheuses

Des niveaux voluent amens voluer

Les niveaux de criticit font pleinement partie des lments qui voluent au fil du temps sur la solution de supervision. Certains problmes qui peuvent paratre non bloquants a priori le sont. Dautres qui paraissent avoir un impact important le perdent au fil du temps. Par exemple, lorsquon modifie un service pour le faire fonctionner en cluster, la disponibilit dun nud du cluster est bien moins critique que dans le cas dun serveur isol. Laspect processus du projet est ici profitable. Avec leur exprience, les administrateurs peuvent redfinir les niveaux de criticit avec le risque dalourdir la configura-

Trier les alertes et amliorer leur pertinence CHAPITRE 6

145

tion en raison de lhtrognit de lenvironnement. Nous verrons que Nagios offre lutilisateur des solutions simples pour la grer.

Une seule alerte par erreur

Les administrateurs nont pas le temps de trier eux mme les alertes. Ce travail doit tre fait en amont par loutil de supervision.

Diminuer encore le nombre dalertes

Les systmes rcents sont fortement imbriqus les uns dans les autres. Une erreur peut en dclencher de nombreuses autres. Cest le fameux effet domino. Les administrateurs reoivent alors un nombre incalculable dalertes. Ils ne peuvent pas se fier lordre de rception des alertes. Car la cause peut dclencher une alerte plus tardive que celle de ses consquences. Pourtant, dans loptique de rsoudre le problme, il est primordial didentifier la source. Si les administrateurs rsolvent les effets, ils se battent contre des moulins vent. Les mmes causes reproduiront les mmes effets. Les administrateurs savent quelles sont les relations entre les lments. Ils ont bti larchitecture et matrisent leurs solutions. Ils sont capables de retrouver la cause parmi toutes les erreurs reues... sils en ont le temps ! Cest malheureusement une denre rare en pleine intervention. Les administrateurs sont stresss et la recherche de la cause est encore plus complexe quen temps normal. La solution de supervision doit pouvoir filtrer les alertes afin de les limiter aux seules sources de problmes. Elle ne peut pas deviner toutes les relations qui relient les lments. Elle doit cependant faire le maximum pour aider les administrateurs.

Ce qui se passe lorsquune machine tombe

Les diffrentes supervisions
Supposons, pour prendre un cas classique denvoi dalertes inutiles, quune machine nest plus disponible. Celle-ci est supervise par deux moyens : la supervision dhte ; la supervision des services qui y sont attachs. Lorsquune machine nest plus disponible, elle passe en tat supervision dhte. Cela lve une alerte de nud.
DOWN

au niveau de la

146

Options avances de Nagios DEUXIME PARTIE

Puisque que la machine est tombe, les services qui y sont surveills passent galement tous en tat non OK. Si la solution de supervision lance une alerte par service, ladministrateur qui les reoit est, pour chaque machine qui tombe, submerg dalertes. Il est inutile de recevoir ces alertes. Ladministrateur a dj linformation de non-disponibilit de la machine. Celle du service napporte aucune nouvelle information. Inutile, elle ne doit pas remonter ladministrateur.

Raction de Nagios
Nagios traite cette situation trs simplement. Si un hte est en tat DOWN, les services sont toujours surveills, mais les alertes ne sont pas envoyes. Sil sarrtait l, lutilisateur pourrait tout de mme recevoir certaines informations inutiles. Les nuds sont surveills rgulirement. Cette supervision permet de dterminer ltat des machines. Ces tests se font en parallle de ceux des services. Si la machine est teste avant les services et si elle tombe entre ces deux tests, on peut arriver une situation o lhte est indiqu comme OK alors que les services ne le sont pas. Nagios pourrait alors dcider denvoyer ce rsultat lutilisateur. Ce nest heureusement pas le cas. En cas de retour non OK sur une machine en tat UP, il planifie un test du nud avant denvoyer le rsultat du service. Si lhte est disponible, cest que le service a rellement un problme. La notification du service est envoye. Il y a un dcalage entre la dtection de lerreur et lenvoi cause du test supplmentaire. Puisque que la machine est disponible, le test est rapide. Ce dlai est, en rgle gnrale, plutt ngligeable. Si lhte est indisponible, la notification du service est oublie. Ceci permet dviter ladministrateur de recevoir une information inutile (voir figure 6-1).
Figure 61

Dpendance entre hte et services

Ce mcanisme est simple et efficace pour limiter le nombre dalertes. La supervision dhte est presque ddie cette utilisation. Linformation envoye aux administrateurs est filtre. Ils nont pas besoin de lire plusieurs messages afin de savoir que cest tout simplement une machine qui est tombe.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

147

De plus, suivant les tests des services et le plug-in utilis, linformation de nonrponse de la machine nest pas forcment facilement intelligible. Un message issu dune alerte de test de nud est reue sans erreur dinterprtation, mme par un administrateur ayant peu de cafine dans le sang.
REMARQUE Une premire notion de dpendance
Nous pouvons considrer que ce comportement quivaut une dpendance entre les services et les nuds. Ces derniers ont le mot final concernant les envois dalertes.

Dpendances rseau
Les pertes rseau constituent un autre cas classique o les administrateurs peuvent tre submergs dalertes.

Problmatique des pertes rseau

Si une perte rseau ne touche quun lment terminal, comme un serveur, lutilisateur ne reoit quune seule alerte. Les services nenvoient pas de notification puisque que lhte est dclar DOWN. Mais la coupure peut survenir au niveau dun lment rseau. Le nombre de nuds qui ne sont plus disponibles est alors potentiellement gigantesque. Le nombre dalertes lest tout autant. Parmi toutes ces erreurs, ladministrateur a du mal trouver la cause. Celle-ci est pourtant simple pour un administrateur qui a connaissance de la topologie du rseau et qui a le temps de lire toutes ces alertes. Par exemple, imaginons que lon perd un routeur sur un site de filiale. Lensemble des serveurs et lments rseau situs dans cette filiale remontent en erreur dans Nagios (voir figure 6-2).

Figure 62 Pertes massives de rseau

148

Options avances de Nagios DEUXIME PARTIE

Solution : les dpendances rseau

Nagios propose une solution simple ce problme : les dpendances rseau. Elles permettent de lui fournir la topologie du rseau. Chaque lment peut avoir un ou plusieurs pres auquel il est connect. Si llment est de type rseau, il peut avoir des fils. Ces relations sont dfinir du point de vue du serveur de supervision. Il peut y avoir autant de niveaux que lutilisateur le souhaite. Il obtient un arbre topologique. La racine de larbre est le serveur de supervision. Un arbre simple Nous pouvons voir en figure 6-3 un exemple de relation parent unique. Nous supposons que le serveur de supervision est plac dans le cur de rseau dune entreprise ayant plusieurs filiales.

Figure 63 Relations de dpendance rseau

Un arbre plus complexe La figure 6-4 prsente un exemple de liens o un nud a plusieurs parents. Dans cette situation, le serveur srv-distant1 a deux pres, ici routeur-1 et routeur-2.

Figure 64 Relations de dpendances rseau multiples

Trier les alertes et amliorer leur pertinence CHAPITRE 6

149

Recherche du lien dfaillant Lorsquil rencontre un problme sur un nud, Nagios remonte son arbre de parent en lanant des tests de disponibilit de nuds. Le dernier lment ne rpondant pas est la cause du problme. Cet lment passe en tat DOWN, ses fils sont quant eux en tat UNREACHABLE (inaccessible). Dans le cas des relations parents multiples, il faut que tous les parents soient non disponibles pour que lenfant soit dclar non atteignable sur le rseau (tat UNREACHABLE). La remonte de vrification est illustre par la figure 6-5.

Figure 65 Remonte des tests de disponibilit

Gnralisation de la dpendance services/hte Ce mcanisme est en fait une gnralisation sur le rseau de la relation de dpendance qui lie les services un hte. Pour cette relation, larbre de relation est trs rduit. Il est mme complmentaire du mcanisme global. Si un service sur un hte est non disponible, Nagios lance un test de nud. Si ce dernier ne rpond pas, il remonte larbre des relations pour trouver la source du problme. Ladministrateur ne reoit quune seule notification, la bonne. Il peut cependant, sil le souhaite, recevoir des alertes pour tous les nuds perdus car non atteignables. Il faut simplement que, dans la configuration des nuds, il ait donn la valeur u (UNREACHABLE) au paramtre notification_options ainsi quau paramtre host_notification_options dans le contact associ au nud. Il est cependant dconseill de procder ainsi, ces informations napportant rien pour la rsolution du problme. De plus, si lutilisateur souhaite avoir la liste des machines indisponibles, il peut regarder directement sur la console.

Dfinition dune relation de supervision

Cette relation de parent est dfinie dans lhte fils grce au paramtre parents. Il sagit dune liste de nom dhtes, spars par des virgules. Si le paramtre nest pas dfini, Nagios considre que le nud est disponible sur le rseau local, sans aucun intermdiaire entre eux.

150

Options avances de Nagios DEUXIME PARTIE

Exemple de dfinition Voici un exemple de dfinition de relation pour lun des cas vus prcdemment :
Exemple de relation de parent
define host{ host_name srv-dist1 parents routeur-filiale,routeur-filiale-bkp } define host{ host_name routeur-filiale parents routeur-princ } define host{ host_name routeur-filiale-bkp parents routeur-princ }

Larbre, un graphe sans cycle Il faut faire particulirement attention ne pas faire de boucle dans la dfinition des relations de parent. Dans une telle situation, la remonte des tests de disponibilit serait sans fin et Nagios tournerait indfiniment. Pour viter cela, il vrifie dans la configuration si les relations forment un arbre, cest--dire un graphe sans cycle.
PERFORMANCES Une vrification trs longue
Dans le pass, la vrification des relations de dpendance par Nagios tait trs lente, voire trop lente. Lalgorithme utilis nest pas optimal. Votre serviteur a propos un nouvel algorithme bien plus efficace qui est, au jour de rdaction, tout juste intgr Nagios. Il sera actif avec la version 3.2.

En cas de problme dtect, la configuration est rejete avec une erreur et Nagios refuse de se lancer. Une telle configuration est interdite :
Relation de parent incorrecte
define host{ host_name routeur-1 parents routeur-2 }

Trier les alertes et amliorer leur pertinence CHAPITRE 6

define host{ host_name routeur-2 parents routeur-3 } define host{ host_name routeur-3 parents routeur-1 }

151

Cette configuration est illustre en figure 6-6.

Figure 66

Relation de parent cyclique interdite

Dpendances applicatives
Les applications sont, de nos jours, aussi lies que les lments rseaux. Tout comme pour ces derniers, une gestion des dpendances amliore la pertinence des alertes.

Dpendances entre services

Lorsque les relations sont plus complexes que de simples liens rseau, on peut dfinir des relations de dpendance entre services ou entre nuds. Ce dernier cas ntant pas trs utile en plus de lhritage rseau, il nest pas tudi ici. Dans le cas o un service est dpendant dun autre qui nest pas disponible, il est intressant de ne pas tre averti. Il est mme inutile daller vrifier que le service fonctionne bien puisque que lon sait que le rsultat est ngatif. Nagios propose travers la fonctionnalit des dpendances applicatives une solution ce problme. Ces relations se dfinissent entre deux services. Nous supposons ici que le service A est dpendant de ltat du service B. A est un service web, B est le service de sa base de donnes. Ltat de ce dernier dcide de la supervision ou non de A. Il dcide galement, si le service est surveill, de lenvoi ou non de la notification. Dfinition Les dpendances entre services sont dfinies dans lobjet servicedependency.

152

Options avances de Nagios DEUXIME PARTIE

Il permet de dfinir les proprits suivantes : dependent_host_name : nom de lhte sur lequel se trouve le service dont on dpend. Dans notre exemple, cest lhte du service B ; dependent_hostgroup_name : nom du groupe de machines o se situent les services dont on dpend ; dependent_service_description : nom du service dont on dpend, dans notre exemple B ; host_name : nom de lhte hbergeant le service surveill initialement, soit le service A ; hostgroup_name : nom du groupe de machines de lhte du service A ; service_description : nom du service surveill initialement, dans notre exemple A ; inherits_parent : on applique ou non les relations de dpendance du service dont on hrite. Ce mcanisme sera tudi un peu plus tard ; execution_failure_criteria : tats du service dont on dpend qui annulent la vrification du service A. Les tats possibles sont : o : tat OK ; w : tat WARNING ; u : tat UNKNOWN ; c : tat CRITICAL ; p : tat PENDING (ltat na pas encore t vrifi) ; n : aucun tat ; notification_failure_criteria : tats du service dont on dpend qui annulent la notification du service A. Les tats sont les mmes que prcdemment ; dependency_period : priode de temps durant laquelle le relation est active. Types dtat Dans la configuration de base, ltat pris en compte est le dernier tat de type HARD. Mme si ltat a chang en SOFT, il nest pas pris en compte. Si ladministrateur souhaite changer ce comportement, il peut ajouter le paramtre soft_state_dependencies dans le fichier de configuration nagios.cfg. Exemple de dfinition Dans le cas de nos services A et B, nous supposons que si service A ne doit pas tre surveill. La dfinition est :
B

est en tat

CRITICAL,

le

Trier les alertes et amliorer leur pertinence CHAPITRE 6

153

Exemple de relation de dpendance

define servicedependency{ dependent_host_name srv-B dependent_service_description B host_name srv-A service_description A execution_failure_criteria c notification_failure_criteria n }

Cela est illustr en figure 6-7.

Figure 67

Relation de dpendance entre services

Plusieurs dpendances pour un mme service

Si un service est dpendant de plusieurs autres, Nagios annule la supervision ou lenvoi de notification si un seul des services dont il dpend est dans un tat inacceptable. Lordre de dfinition des relations de dpendance na pas dimportance dans ce mcanisme. Dans lexemple prsent en figure 6-8, si C est dans un tat WARNING ou si B est dans un tat CRITICAL, alors A nest pas surveill.
Figure 68

Multiples relations de dpendance

154

Options avances de Nagios DEUXIME PARTIE

Hritage des dpendances

La valeur par dfaut du paramtre inherits_parent est 0. Ceci signifie que lon napplique pas les relations de dpendance un service dont il dpend. Dans notre exemple, si B dpend dun service D, si lhritage nest pas activ, la relation entre B et D nest pas prise en compte pour A. Dans le cas contraire, A est dpendant de B et de D. On applique la dpendance de B et D pour A. Si lun des deux services valide les critres de la dpendance, alors celle-ci est active, et on ne supervise pas A. Considrons la configuration suivante :
Exemple dhritage de relation de dpendance
define servicedependency{ dependent_host_name srv-B dependent_service_description B host_name srv-A service_description A execution_failure_criteria c notification_failure_criteria n inherits_parent1 } define servicedependency{ dependent_host_name srv-D dependent_service_description D host_name srv-B service_description B execution_failure_criteria w notification_failure_criteria n }

La configuration est reprsente en figure 6-9.

Figure 69 Hritage de dpendances

Trier les alertes et amliorer leur pertinence CHAPITRE 6

155

Si le service B est en tat CRITICAL ou D en tat WARNING, alors A nest pas surveill. Ce comportement est en fait le plus logique. Considrons A comme un service web, B un service de base de donnes et D le service daccs au disque de la base. Pour que le service web (A) fonctionne, il a besoin de sa base de donne (B). Cette dernire, quant elle, a besoin daccder ses fichiers (D). Nous avons naturellement besoin de D pour A.
CONFIGURATION Un hritage conseill
Comme nous venons de le voir, lhritage des dpendances est un comportement logique. Il est conseill de lactiver systmatiquement.

Se concentrer sur les vraies alertes : la production

Les administrateurs ne doivent pas oublier le vrai rle dun systme dinformation : la production.

Les notifications : rserves la production

Les notifications sont ce que voient en premier les administrateurs. Ce vecteur dinformation ne doit pas tre pollu par des alertes non importantes.

Les diffrents environnements

Plusieurs environnements coexistent pour une mme application. Ils comptent au moins un environnement de production dont la disponibilit doit tre assure au maximum. Dans la plupart des cas, sont galement prsents des environnements de qualification, voire de dveloppement. La supervision doit tre disponible sur tous ces environnements. Une erreur sur un environnement de qualification peut trs bien prdire un futur problme en production. Et cest bien cette dernire qui nous intresse par-dessus tout. Si tous ces environnements sont autoriss lever des notifications, les administrateurs risquent den recevoir beaucoup trop. Une mthode efficace pour cela est de ne permettre quaux quipements de production de lever des alertes. Les erreurs sur les autres environnements restent disponibles sur la console de supervision. Lorsquun administrateur est notifi, il sait que linformation est importante et quil faut la traiter immdiatement. Si les autres environnements peuvent lever des envois de-mails, par exemple, les administrateurs sont obligs de les lire afin de savoir sils sont importants ou non.

156

Options avances de Nagios DEUXIME PARTIE

Certaines exceptions existent cette rgle, en particulier la disponibilit des machines et les problmes de scurit. Ces alertes doivent tre remontes mme sur des environnements non critiques, car elles annoncent des problmes pouvant se propager trs rapidement. Les administrateurs doivent ragir trs vite, il faut leur transmettre linformation le plus rapidement possible et ne pas attendre quils aillent regarder les consoles de supervision.

Astreintes
Toutes les productions ne seront pas forcment la mme enseigne. Certaines sont plus critiques que dautres. Cest particulirement vrai lors des priodes dastreinte. Pendant ces priodes, certains services peuvent par exemple envoyer des alertes par SMS. Il ne faut pas que nimporte quel service puisse lever une telle notification. Un environnement important la journe peut ne pas ltre la nuit.
PSYCHOLOGIE Des priodes complexes grer
Les priodes dastreinte sont dlicates. tre rveill par une alerte non pertinente nest pas des plus agrable. Inversement, ne pas ltre alors que la production est dans un tat critique peut avoir des consquences fcheuses.

Certains serveurs et quipements rseau ont un statut particulier dans la production car ils peuvent lever les alertes les plus importantes. Ces alertes doivent tre dfinies avec deux types de contacts : les administrateurs normaux, et les personnes dastreinte. Ces dernires ont une priode de notification bien prcise pour viter les alertes doubles en journe.

Du rouge dans la console de supervision : rserver la production

Jusquici, nous navons fait de diffrence entre les environnements quau niveau des envois de notifications. Au niveau de la console de supervision, il ny a pour linstant aucune diffrence entre eux. Pourtant, en plus des alertes envoyes, les administrateurs reoivent les informations de disponibilit sur un cran de supervision. Si aucune diffrence nest faite ce niveau, des environnements non critiques peuvent lever des alertes critiques. Les administrateurs doivent alors lire toutes les lignes rouges qui apparaissent avant de savoir si linformation est importante ou non. Nous arrivons dans la mme situation que prcdemment. Nous ne pouvons pas faire disparatre totalement de la supervision les environnements de qualification et de dveloppement. Ils sont importants pour prvoir les problmes qui peuvent survenir sur la production. Ils ont leur place dans la console de supervision.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

157

La solution est simple : ne faire apparatre en rouge que les environnements de production. La couleur est simplement dfinie dans Nagios comme le retour dun plugin. Cest ltat dun service ou dun nud. Pour la disponibilit des machines, nous avons vu que cette information est importante quelle que soit la machine. Pour les services, ce nest pas le cas. Les alertes critiques sur un environnement de qualification ne sont, au final, quun avertissement. Il suffit dappliquer ce principe. Seule la production doit pouvoir monter au niveau critique. Le niveau maximum des autres environnements est le niveau WARNING. Ces avertissements restent clairement identifiables sur la console de supervision, mais les administrateurs ne shabituent pas voir du rouge sur la console. Cette couleur garde tout son sens : une alerte importante sur la production. Nous verrons un peu plus loin dans le chapitre comment appliquer ce principe sur les plug-ins sans avoir tous les modifier grce aux sur-couches.
PSYCHOLOGIE Le choix des couleurs
Les couleurs correspondant aux alertes sont immuables. Si ladministrateur peut jouer sur la teinte, il est fortement dconseill de changer radicalement une couleur. Par exemple, personne ne comprendrait un indicateur bleu : bien ou mal ?

Tirer avantages des priodes

Des allies prcieuses
Les priodes sont des allies trs puissantes contre les alertes inutiles. Les administrateurs ont tendance les oublier. Pourtant, elles permettent de filtrer trs efficacement les vrifications inutiles ainsi que les notifications non sollicites. Les environnements ne sont pas tous disponibles 24 heures sur 24, 7 jours sur 7. Pendant les priodes de sauvegarde par exemple, il arrive que les applications soient arrtes. Les administrateurs sont au courant de larrt du service. Ce dernier est planifi par leurs soins. Recevoir une alerte indiquant que lapplication nest pas disponible ne leur est pas utile. Elle pollue leur bote aux lettres et les empche de voir les vraies alertes. Pour rduire le nombre dalertes inutiles, deux priodes sont ajustables. check_period permet de spcifier la priode o seffectue la supervision. notification_period permet de dterminer quand une notification peut tre leve.

158

Options avances de Nagios DEUXIME PARTIE

Priodes de supervision
Suivant ce que souhaite obtenir ladministrateur, il doit dfinir lune de deux ces deux variables. La priode de vrification restreint la supervision. Si la priode exclut, par exemple, les heures de sauvegarde, Nagios ne tente pas de vrifier ltat de lapplication pendant ce temps. Sil ne voit rien, il nenvoie pas dalerte. Cette mthode a lavantage de ne rien prsenter aux administrateurs. Que ce soit sur les notifications ou la console, rien ne fait rfrence ltat indisponible de llment. Elle rduit cependant les informations disponibles pour Nagios. Si un problme inhabituel fait surface, labsence de supervision implique quil nest pas dtect. Les administrateurs nont aucun moyen dobtenir les informations par ce biais ultrieurement.

Priodes de notification
La priode de notification permet, quant elle, de poursuivre la vrification des lments, mais de ne pas envoyer de notification sur une certaine priode. Si ladministrateur la dfinit sur la priode de non-disponibilit, Nagios nenvoie pas dalerte inutile aux administrateurs. Cette mthode a pour inconvnient de laisser apparatre dans la console de supervision des erreurs normales . Si, sur cette priode, personne ne la regarde, cela ne pose pas de problme. Les administrateurs nen prennent pas connaissance le matin en lisant leurs messages. Elle permet de continuer superviser les lments. Si un problme anormal se produit, Nagios conserve les informations. Les administrateurs peuvent aller chercher dans les fichiers de journalisation leurs informations. Cette mthode est privilgier si les erreurs dans la console ne sont pas un point bloquant pour les administrateurs.

Que faire dans le cas de simples pertes de connexion ?

Toujours dans le cadre de lamlioration de la pertinence des alertes, la problmatique des pertes de connexions se doit dtre pose.

Des pertes invitables

Les rseaux et les systmes ne sont pas parfaits. Les pertes de connexion sont monnaie courante. Comment interprter cette information ? Le cas des vrifications dhtes a dj t trait dans un chapitre prcdent. La perte de connexion implique une machine DOWN ou UNREACHABLE.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

159

Le cas des services est moins vident. Ce type de tests regroupe en fait deux catgories : les tests de disponibilit dun service ; les recherches dinformations comme la charge CPU.

Dans la peau dun utilisateur

Lorsque les alertes sont remontes aux administrateurs, ils la qualifient rapidement grce leur titre et leur criticit. Dans bien des cas, le titre est mme la seule information quils regardent, faute de temps pour tout lire. Disponibilit des services distants Dans le cas des alertes de disponibilit, la perte dune connexion quivaut un service non accessible aux clients. Le contact recevant une alerte CRITICAL avec le nom de lapplication comprend tout de suite quelle nest pas disponible, mme sans avoir lu le message du plug-in. On peut prendre pour exemple une perte de connexion vers un service Web. La perte de connexion doit dclencher un tat critique, car le service nest pas disponible. Informations de charge Pour les recherches dinformations, de charge par exemple, cest beaucoup plus dlicat. Comment ragit un administrateur lorsquil reoit une alerte nomme : CPU is CRITICAL ? Il pense naturellement que la charge CPU est trop leve sur le serveur. Sans mme aller lire lalerte en entier, il se connecte au serveur. Si lalerte tait relle, il voit une charge anormale et peut rgler le problme. Mais il se peut quil ny ait rien voir. Cela se produit lorsquune micro-coupure rseau a empch le plug-in de rcuprer la valeur. Si ladministrateur regarde un peu plus prcisment lalerte, il peut y lire un message quivalent connexion timeout . La micro-coupure ayant t rapide, le test de nud induit par le retour anormal du plug-in a renvoy un tat correct. Or, ladministrateur na pas reu un message indiquant que la machine ntait plus disponible, mais une alerte de service. Cette alerte nest donc pas correctement remonte. Lalerte indique une valeur incorrecte, alors que lon na pas pu obtenir cette information. Pourquoi lever une alerte sur une information inconnue ? Si un service de test de disponibilit de services est en place, il se charge de remonter linformation. Il en est de mme pour le test des nuds dans le cas dune coupure longue.

160

Options avances de Nagios DEUXIME PARTIE

Ltat UNKNOWN est ddi ce genre de cas : linformation nest pas disponible, donc on annonce Nagios un statut inconnu. La plupart des contacts choisissent avec raison de ne pas se faire envoyer de notification sur des alertes UNKNOWN. Sur la console de supervision, les alertes sont signales en gris. Si la perte rseau est longue, le nud passe en DOWN et les personnes sont clairement averties du problme. Exemple Prenons pour exemple la recherche de la charge sur un serveur distant grce NRPE. Une telle information nest pas une information de disponibilit. Nous renvoyons le statut UNKNOWN si NRPE narrive pas rcuprer linformation. Nous utilisons pour cela le paramtre -u de check_nrpe qui permet de changer le comportement normal du plug-in qui est de sortir en tat CRITICAL. Le texte de check_nrpe nest pas modifi, linformation reste claire.
Comportement dune sonde lors dune perte de connexion
check_nrpe -H srv-web1 -c load -u connexion timeout echo $? 3

Des sur-couches pour viter la prolifration de plug-ins

Avec la multiplication des types denvironnements, les sondes se multiplient. Voyons comment grer ce problme.

Moins de plug-ins, plus de choix

Nous avons vu que, suivant le contexte, les plug-ins ne doivent pas ragir de la mme manire. Par exemple, les retours des plug-ins sexcutant pour les environnements de qualification ne doivent pas dpasser le seuil WARNING. Pour chaque type dinformation aller chercher, il faut un plug-in. On en obtient en gnral un nombre assez consquent. Si chaque plug-in doit exister en plusieurs versions pour grer tous les contextes, leur nombre risque daugmenter trs rapidement. Chaque modification dun plug-in doit tre reporte sur plusieurs sous-versions . Cest difficilement grable.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

161

Prenons un peu de recul sur ce problme. Un plug-in est une simple commande lance qui renvoie : un texte explicatif ; des donnes de performance, spares du texte par un caractre | ; un code de retour. Les variations de contexte ne peuvent porter que sur ces trois lments. Pour en modifier ou en supprimer un, le plug-in peut tre lanc par un script qui reoit lensemble des sorties du plug-in. Il effectue ensuite les modifications, puis retourne le rsultat Nagios. Ce script est une sur-couche. Comme les plug-ins retournent tous les mmes trois lments, la sur-couche peut tre utilise pour lensemble des plug-ins de ladministrateur. Il na plus besoin de maintenir une arme de sondes.

Diminuer de niveau dalerte

La qualification ne doit pas renvoyer dtat CRITICAL. Un tel tat doit tre traduit en WARNING. Pour cela, lutilisation dun script de sur-couche est tout indiqu. Linformation de criticit est contenue dans le code retour du plug-in appel. Le script ne modifie pas les lignes de retour du plug-in. Ladministrateur a besoin du texte dalerte, mme sur les environnements de qualification. La mtrologie est galement ncessaire, ne serait-ce que pour tailler au plus juste des environnements qui nont pas besoin dautant de ressources que la production. Concernant les codes retour, le seul qui a besoin dtre modifi est le CRITICAL, soit le code 2. Il faut le transformer en WARNING, soit 1. Un tel script, nomm nocritical.sh peut scrire en quelques lignes :
nocritical.sh
#!/bin/sh LINES=`$*` RET=$? If [$RET= '2'] then RET=1 fi echo $LINES exit $RET

Dans la configuration de Nagios, nous dupliquons simplement la dfinition des commandes : une commande normale pour la production ; une commande qui ne peut pas renvoyer dtat CRITICAL, cest--dire la mme ligne, mais prcde de nocritical.sh.

162

Options avances de Nagios DEUXIME PARTIE

Voici, par exemple, la dfinition de production de NRPE :

Dfinition de check_nrpe pour la production
$USER1$/check_nrpe -H $HOSTADDRESS$ -u -c $ARG1$

La qualification est dfinie de la manire suivante :

Dfinition de check_nrpe pour la qualification
$USER1$/nocritical.sh "$USER1$/check_nrpe -H $HOSTADDRESS$ -u -c $ARG1$"

Selon leur environnement (production ou non), les services appellent la commande qui leur est ddie.

Pour se limiter la mtrologie

Certains plug-ins retournent des informations de mtrologie trs intressantes, mais leur partie supervision est inutile, voire gnante. Elle ajoute des alertes sur un systme qui nen a pas besoin. Ladministrateur pourrait modifier le plug-in. Cette solution nest malheureusement pas toujours simple. De plus, elle est consommatrice de temps. Nous allons lui prfrer une solution avec un script de sur-couche. Il permet de modifier le comportement du plug-in comme nous le souhaitons. Il retourne toujours un OK puisque que linformation de supervision ne nous intresse pas. Le texte de supervision doit tre remplac pour ne pas induire un administrateur en erreur. Le texte de mtrologie ne doit pas tre modifi, cest la seule partie qui nous intresse. Voici un script permettant de raliser cela. Nous le nommons metrolonly.sh :
metrolonly.sh
#!/bin/sh METROL=`$* | cut -d'|' -f2` echo "OK | $METROL" exit 0

La commande est dfinie comme suit :

$USER1$/metrolonly.sh "$USER1$/check_load -w 1,1,1 -c 2,2,2"

Trier les alertes et amliorer leur pertinence CHAPITRE 6

163

Supprimer la mtrologie
Certains plug-ins renvoient des informations de mtrologie qui ne sont pas utiles aux administrateurs. Si elles sont recueillies, elles sont envoyes loutil de mtrologie. Elles consomment des ressources pour rien. Il est possible de spcifier au niveau du service de ne pas rcuprer ces donnes de performance. Cette configuration doit tre effectue sur tous les services appelant le plug-in. Il serait prfrable que la commande ne retourne tout simplement pas ces donnes. Lutilisation dun script de sur-couche est recommand dans cette situation. Il supprime simplement la partie mtrologie sans toucher au reste. Nous pouvons nommer un tel script nometrol.sh. Il sera de la forme suivante :
nometrol.sh
#!/bin/sh LINE=`$* | cut -d'|' -f1` RET=$? echo "$LINE" exit $RET

La commande est dfinie comme suit :

$USER1$/nometrol.sh "$USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$"

Comment obtenir le rsultat inverse dune commande

Parfois, nous aimerions quun service ne soit pas lanc, quun port ne rponde pas, quun fichier ne soit pas prsent. Bref, on veut le contraire de ce que tout le monde attend. Dans ce genre de situation, les plug-ins classiques ne sont pas adapts. Ils font le contraire de ce que lon souhaiterait. Nous pourrions les modifier, mais cest parfois complexe et lourd maintenir. Nous prfrons, une fois de plus, utiliser une sur-couche. Elle porte uniquement sur les codes retour et effectue les modifications suivantes : OK est chang en CRITICAL ; CRITICAL est chang en OK ; WARNING et UNKNOWN restent inchangs. Pour lillustrer, reprenons lexemple de notre script test.sh que nous avons dfini au chapitre 3. Il permet dtre alert si un fichier nexiste pas. Sans avoir le modifier, il peut alerter de lexistence dun fichier. Nous pouvons prendre pour exemple le cas dun fichier dalerte dune application.

164

Options avances de Nagios DEUXIME PARTIE

Le fichier dalerte est /tmp/alerte.txt. Si le fichier est absent, le script, utilis normalement, a le comportement suivant :
Comportement normal de test.sh
test.sh /tmp/alertes.txt CRITICAL the file /tmp/alertes.txt does not exist. echo $? 2

Avec lutilisation de negate, nous obtenons linverse :

Inversion du rsultat de test.sh
negate "test.sh /tmp/alertes.txt" CRITICAL the file /tmp/alertes.txt does not exist. echo $? 0

Le texte nest pas modifi, mais les administrateurs ne sont pas avertis. trs pratique pour rgler les situations un peu atypiques.

negate

est

gayer (un peu) les alertes

Les administrateurs sont certes un public un peu particulier, mais qui ne verra pas dinconvnient ce quon facilite et rende plus agrable la lecture des alertes.

Le fond et la forme
Les alertes ne sont pas, par dfinition, trs joyeuses. Elles apportent de mauvaises nouvelles aux administrateurs. Parfois, elles sont annonciatrices de nuits blanches ou dinterventions en priode dastreinte. Cest pour cette raison que Nagios na pas trs bonne rputation. Cest un oiseau de mauvais augure. Une solution pour amliorer un peu cette situation est dgayer les alertes. Les administrateurs ne sont pas, en rgle gnrale, trs sensibles la forme des messages. Ils se concentrent le plus souvent sur le fond. Le fait que bon nombre dentre eux prfrent la ligne de commande en est la meilleur preuve. La forme peut cependant mettre en avant certaines informations importantes. La svrit et le nom de llment concern doivent tre mis en avant dans les alertes. La

Trier les alertes et amliorer leur pertinence CHAPITRE 6

165

forme de celles-ci est importante pour faire ressortir ces informations. Le temps gagn dans la qualification des alertes est trs important lorsquon considre le nombre que lon en reoit dans lanne. Il peut tre mis contribution sur des actions plus intressantes, comme les amliorations darchitectures. Si la forme des alertes est importante, le mdia dinformation lest galement. Suivant les alertes et les administrateurs, on peut choisir de les avertir dune manire particulire. Par exemple, pour les priodes dastreinte, lutilisation de SMS est conseille, voire obligatoire. Nous allons voir que dautres moyens sont la disposition de ladministrateur pour alerter ses camarades de la manire la plus efficace qui soit.
PSYCHOLOGIE Un outil plus attirant
Ces moyens rendent loutil un peu plus attrayant, ce qui peut donner un petit sourire aux administrateurs lorsquils reoivent lalerte. Cest dj un objectif assez intressant lorsquon considre ce public :-)

Un peu de couleur dans un monde de brutes

Lorsque les administrateurs regardent leur messages dalertes, ils lisent le titre en priorit. Celui-ci rsume les informations importantes que sont la criticit et llment concern. Sils ne lisent pas le titre, ils doivent chercher ces informations. Nous avons dj vu quelles doivent tre prsentes au dbut de le-mail. Nous pouvons les mettre en relief avec quelques astuces typographiques. Si le-mail nest pas un simple texte brut, mais un mail au format HTML, nous disposons dune panoplie trs large de solutions pour faire ressortir les informations importantes. Il ne faut pas en abuser. Le-mail annonce une alerte des administrateurs. Un e-mail arc-en-ciel ne sera pas forcment bien reu. Trop de couleurs peuvent aveugler plutt qualerter. Il est donc prfrable de se limiter deux couleurs dans les e-mails. Puisque que la plupart des personnes interprtent la couleur rouge comme une erreur grave, lorange comme une alerte et le vert comme un signal que tout va bien, nous allons utiliser ces couleurs dans les e-mails. Ltat de llment est simplement mis en exergue. Ladministrateur peut ainsi voir, avant mme de lire, si linformation est importante ou non. Voici un exemple de message que peut recevoir ladministrateur :
Mise en avant des informations importantes
***** Nagios Notification ***** State: WARNING Host: srv-web2 Service: Memory

166

Options avances de Nagios DEUXIME PARTIE

Date/Time: 16-12-2008 15:35 Additional Info: WARNING: 92% Used Memory - Total: 8116 MB, used: 7503 MB, free: 613 MB Documentation: clic here.

Le WARNING sera ici en orange. Ladministrateur sait que linformation est intressante, mais non critique.

Alertes en flux RSS

Le canal phare des informations du Web peut tre employ bon escient avec Nagios.

Un vecteur dinformation trs employ et pratique

Les administrateurs ne sont pas ncessairement avertis lors de larrive dun nouvel e-mail. Ils doivent pourtant suivre en temps rel les alertes quils reoivent. Par ailleurs, les flux RSS sont de plus en plus utiliss par les administrateurs pour suivre des flux dactualits. Ce sont de simples fichiers XML accessibles par le Web qui exportent des rsums et des liens vers les informations plus compltes sur des sites web. Voil donc un vecteur dinformation simple pour alerter les administrateurs raison dun flux par contact. Chaque contact doit avoir accs ses alertes et aux siennes seulement. Le plug-in permettant de former ces fichiers XML se nomme rss-multiuser. Il est appel par Nagios comme simple commande de notification. Les administrateurs nont qu sinscrire ce nouveau flux personnalis. Ils sont avertis rapidement de toute nouvelle entre. Les outils grant les flux RSS sont nombreux et peuvent avertir lutilisateur par une petite fentre sur leur cran ou en gnrant une alerte sonore.

Mise en place de rss-multiuser

Deux scripts sont utiliss : rss-multiuser : gnration de fichiers RSS pour chaque utilisateur ; rss.cgi : script appel par le serveur web pour fournir les flux aux utilisateurs. Le premier est situ dans le rpertoire /usr/local/nagios/bin, le second dans /usr/ local/nagios/sbin. Ils utilisent un fichier de configuration commun, /usr/local/ nagios/etc/rss.cfg. On peut y dfinir les proprits suivantes : title : titre du flux RSS ; description : description du flux ; server : URL du serveur web ; extinfo : URL vers extinfo.cgi qui permet dobtenir plus dinformations ;

Trier les alertes et amliorer leur pertinence CHAPITRE 6

167

rssdir : chemin vers les fichiers rss des contacts ; max : nombre dentres des flux.

La commande de notification associe aux contacts est :

Dfinition de notify-by-rss
define command{ command_name notify-by-rss command_line /usr/local/nagios/bin/rss-multiuser }

Les administrateurs doivent, quant eux, dfinir le chemin suivant dans leur gestionnaire de flux :
Adresse de lecture du flux
http://srv-nagios/nagios/cgi-bin/rss.cgi

Chaque utilisateur doit tre identifi au niveau dApache pour le rpertoire cgi-bin afin dobtenir son flux personnalis. Cette configuration a dj t tudie dans le chapitre prcdent (configuration du fichier htpasswd.users).

Exemple de flux
Voici un exemple de flux gnr, ici limit 2 entres :
Exemple de flux RSS de rss-multiuser
<?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule"> <channel> <title>Nagios alerts</title> <link>http://srv-nagios</link> <description>Nagios alerts for RSS readers</description> <language>en</language> <item> <title>UP: srv-web1</title> <link>http://srv-nagios/nagios/cgi-bin/ extinfo.cgi?type=1&#x26;host=srv-web1</link> <description>Output: TCP OK - 0.041 second response time on port 139 </description> <guid isPermaLink="false">/nagios/srv-web1/1229516001</guid> <pubDate>17 Dec 2008</pubDate> </item>

168

Options avances de Nagios DEUXIME PARTIE

<item> <title>CRITICAL: srv-web2 Fans</title> <link>http://srv-nagios/nagios/cgi-bin/ extinfo.cgi?type=2&#x26;host=srv-web2&#x26;service=Fans</link> <description>Output: Critical : Fan 1 is Faulted</description> <guid isPermaLink="false">/nagios/srv-web2/Fans/1229514475</guid> <pubDate>17 Dec 20080</pubDate> </item> </channel> </rss>

Les liens des entres pointent vers linterface web de Nagios qui permet dobtenir plus dinformations sur les alertes correspondantes. Ces liens peuvent galement effectuer des actions complmentaires comme relancer une vrification ou la prendre en considration pour les autres contacts.

Alertes par SMS

Les alertes par SMS sont souvent synonymes de rveils trs matinaux et dastreintes, mais elles sont fort pratiques. Le rseau GSM a un intrt tout particulier : il est indpendant du rseau de lentreprise. Si le serveur de messagerie nest tout simplement pas joignable, il y a peu de chance que les administrateurs reoivent leur e-mails dalerte. Dans ce cas, pour les administrateurs qui ne sont pas sur site, le SMS est lun des seuls moyens de les joindre. Ces messages sont en rgle gnrale trs courts, moins de 180 caractres. Pour les envoyer, un modem GSM est ncessaire. Le plus simple appareil du genre est un simple tlphone portable. Des botiers ddis existent. Ils se connectent au serveur de supervision par port srie ou USB. Notre exemple utilise un simple tlphone portable branch par USB. Le programme gnokii permet de contrler ce modem et de demander un envoi de SMS. Il sinstalle simplement :
Installation de gnokii
yum install gnokii

La liste des tlphones compatibles est disponible sur le site du programme. Lorsquun tlphone est connect, il est disponible travers le fichier /dev/ttyACM0. Laccs au fichier demande lutilisateur nagios dtre dans le groupe dialout. Le programme gnokii est configur dans le fichier /etc/gnokiirc.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

169

/etc/gnokiirc
port = /dev/ttyACM0 model = AT connection = serial

Une simple commande permet de tester lenvoi dun message vers un tlphone portable :
Test dun envoi de SMS
echo 'Test avec Gnokii' | gnokii -config /etc/gnokiirc -sendsms +33670809010

Le numro de tlphone doit tre au format international, avec lindicatif +33 pour la France. Dans Nagios, on dfinit les commandes denvoi de SMS comme suit :
Commande denvoi de SMS pour les services
define command{ command_name notify-by-sms command_line echo "$NOTIFICATIONTYPE$ : $HOSTALIAS$ $SERVICEDESC$ is $SERVICESTATE$ - $OUTPUT$" | gnokii config /etc/gnokiirc sendsms $CONTACTPAGER$ }

Commande denvoi de SMS pour les htes

define command{ command_name host-notify-by-sms command_line echo "$NOTIFICATIONTYPE$ : $HOSTALIAS$ is $HOSTSTATE$ $OUTPUT$" | gnokii config /etc/gnokiirc sendsms $CONTACTPAGER$ }

Ces commandes ne doivent tre associes quaux contacts grant des services et des htes de la plus grande importance. Les priodes de notification doivent tre cales sur celles dastreinte. Les administrateurs ne comprendraient pas de recevoir un SMS en pleine journe alors quils sont devant leur bureau.
PIGE Bien surveiller le tlphone
La mise en place denvoi par SMS avec un tlphone implique de surveiller que ce dernier est toujours allum. Il serait dommage de ne pas recevoir une alerte cause dune batterie vide. Cette surveillance peut se baser sur la prsence du fichier /dev/ttyACM0.

170

Options avances de Nagios DEUXIME PARTIE

Canaux dalerte non conventionels

Les moyens classiques dalerte ayant t tudis, regardons les autres.

Des moyens dalerte originaux

Nagios offre la possibilit ladministrateur de lancer la commande quil souhaite pour avertir les contacts. Cela permet dutiliser nimporte quel support dalerte, y compris les plus originaux. En fait, la seule limite se situe au niveau de limagination de ladministrateur : sil est possible de lancer une action en ligne de commande, alors elle peut devenir un vecteur dalerte. Il ne faut pas en abuser. Mais ils permettent dalerter les administrateurs les moins rveills.

Lecture dun son

Une alerte sonore est un bon moyen davertir les administrateurs. Pour cela, un PC connect des hauts-parleurs est suffisant. Il suffit de lancer sur ce PC une commande pour jouer un son. Dans le cas dun PC sous GNU/Linux, nous pouvons utiliser un petit fichier mp3 lu avec mpg123. La lecture est lance depuis le serveur Nagios grce SSH. Pour cela, un mcanisme dauthentification par cls est indispensable. Cette procdure a dj t tudie dans le chapitre 4.
PRATIQUE La production uniquement
Une alerte sonore ne doit tre associe qu des incidents critiques. Il ne faudrait pas que le bureau se transforme en discothque.

Voici un exemple dun tel script :

Lecture dun son sur un serveur distant
#!/bin/sh ssh pc "mpg123 ~/mysound.mp3"

Alerte sur lcran LCD du clavier

Certains claviers disposent dun petit cran LCD. Nous pouvons y faire apparatre des messages derreur. Prenons lexemple du clavier G15. Un dmon est disponible pour contrler lcran. Il suffit de le lancer :

Trier les alertes et amliorer leur pertinence CHAPITRE 6

171

Lancement du dmon de contrle du clavier

/etc/init.d/g15daemon start nohup g15composer /tmp/g15pipe &

Le script doit simplement crire dans le fichier /tmp/g15pipe pour que le message apparaisse sur lcran. Nagios crit simplement dans le fichier via SSH (voir figure 6-10).
Envoi dun message sur le clavier
#!/bin/sh ssh pc "echo 'TL \"$NOTIFICATIONTYPE$ :\" \"$HOSTALIAS$/$SERVICEDESC$ is \" \"$SERVICESTATE$ \"' > /tmp/g15pipe "

Figure 610

Exemple daffichage sur un clavier

Le lapin qui chante et qui danse

Parfois, il faut employer les grands moyens pour attirer lattention des administrateurs. Un petit lapin qui danse et qui chante les alertes dans une profusion de lumire est la dernire solution applicable. Le Nabaztag est un petit gadget amusant se prsentant sous la forme dun petit lapin lectronique pouvant mettre de la lumire, bouger les oreilles en rythme et lire un texte envoy par lutilisateur. Ce lapin est connect en Wi-Fi, il rcupre rgulirement des messages sur Internet et les prononce.

172

Options avances de Nagios DEUXIME PARTIE

Nous pouvons adapter ce gadget notre supervision. Il vrifie rgulirement si Nagios lui a fourni un texte lire. Ce dernier est tout simplement le message dalerte. Pour les mmes raisons que prcdemment, il ne faut faire passer par ce biais que les alertes rellement critiques. Le bureau pourrait rapidement se transformer en jardin enchant. On envoie le message sur le site du fabricant avec le programme wget. Cest le rle du script suivant, nomm send_nabaztag. Il prend en argument un numro de srie de lappareil et un token. Ces informations sont disponibles pour chaque lapin sur le site du fabricant. Le dernier argument est tout simplement la ligne annoncer.
Script denvoi dun message au lapin : send_nabaztag
#!/usr/bin/perl use URI::URL; $str=URI::URL->new($ARGV[2]); $url='http://api.nabaztag.com/vl/FR/ api.jsp?sn='.$ARGV[0].'&token='.$ARGV[1]."&tts=$str&ttlive=300"; system("/usr/bin/wget -q -O /dev/null '$url'");

Nous dfinissons la commande comme suit :

Dfinition de la commande
define command { command_name notify-by-nabaztag command_line /usr/local/nagios/libexec/send_nabaztag SERIAL TOKEN "$HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$" }

Il ne faut pas oublier de changer SERIAL et TOKEN par ceux de lappareil. Il ne reste plus qu lassocier un contact qui accepte de voir ses alertes chantes par un petit gadget.
SCURIT Confidentialit
Il va de soi que les alertes seraient ainsi connues dudit fabricant...

Le lance-roquettes USB
Le lance-roquettes USB est un gadget dont on peine voir lutilit, mais on peut dclencher une salve avec une simple commande. Un administrateur taquin a probablement dj une ide derrire la tte de ce quil peut faire en le couplant avec Nagios. Cela est laiss en exercice. Pour aider un peu, le paquetage de contrle sous GNU/Linux est USBMissileLauncher, et on dclenche le lancement comme suit :

Trier les alertes et amliorer leur pertinence CHAPITRE 6

173

Commande pour lancer un missile

USBMissileLauncherUtils -F

SCURIT Une roquette en mousse peut faire mal

Il est bon de rappeler que prendre un tir de roquette en mousse peut mettre de mauvaise humeur un administrateur. Un tel outil peut cependant servir aux reprsailles contre un gadget lumineux qui danse en bougeant ses oreilles au milieu du bureau.

Les ractions sur alertes, ou comment rgler automatiquement les problmes

Rsoudre automatiquement les problmes est le plus vieux rve des administrateurs...

Une solution sduisante double tranchant

La solution de supervision tant en premire ligne pour reprer les problmes, elle lest galement pour cette rsolution automatique. Il faut faire trs attention lorsquon met en place de telles mthodes. Les rsolutions de problmes incluent par exemple le redmarrage dun service ou la suppression de fichiers de journalisation pour gagner de lespace disque. De telles mesures peuvent rsoudre le problme, condition quil existe rellement. Dans le cas contraire, cette tentative est nfaste. Il faut bien mesurer limpact de telles actions.

Gestionnaires dvnements
Nagios propose un systme de raction sur problme. Ce sont les event handlers (gestionnaires dvnements). Ce sont de simples scripts fournis par les administrateurs que Nagios peut lancer dans les situations suivantes : le problme vient dtre dtect (tat SOFT) ; le problme est confirm et passe en tat HARD ; le systme revient en tat OK ou UP. Ils sont dfinis dans le fichier commands.cfg, comme toutes les commandes. Il existe, pour les htes comme pour les services, deux types devent handlers : les scripts globaux ; les scripts spcifiques.

174

Options avances de Nagios DEUXIME PARTIE

Les premiers sont appels dans le fichier nagios.cfg. Les variables correspondantes sont nommes global_host_event_handler et global_service_event_handler. Ils sont appels pour tous les htes et services. Les dfinitions spcifiques sont associes aux htes et services par le paramtre event_handler. Ils crasent la dfinition globale si elle existe. Le paramtre enable_event_handlers permet de dsactiver cette fonctionnalit.
PRATIQUE Dsactivation des event handlers
Si le paramtre enable_event_handlers prsent dans nagios.cfg a la valeur 0, alors cette fonctionnalit est dsactive, mme si le paramtre a la valeur 1 sur un hte ou sur un service.

Dfinition
Les scripts utilisent en priorit les macros suivantes (ici celles associes aux services) : $SERVICESTATE$ : tat du service ; $SERVICESTATETYPE$ : type dtat (SOFT ou HARD) ; $SERVICEATTEMPT$ : nombre de fois o le test a t lanc depuis le dernier tat OK/ HARD. Prenons lexemple du redmarrage du service web local, dfini comme suit :
Appel dune commande daction
define service{ host_name srv-web2 service_description Http max_check_attempts 3 event_handler restart-local-httpd [...] }

La commande restart-local-httpd correspond la commande suivante :

Dfinition de la commande restart-local-httpd
define command{ command_name restart-local-httpd command_line sudo $USER1$/eventhandlers/restart-httpd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ }

Trier les alertes et amliorer leur pertinence CHAPITRE 6

175

Nous souhaiterions que le script ne relance le service que dans le cas dun tat HARD ou un tat SOFT au 2e test, le 3e dbouchant sur ltat HARD. Dans cette situation, le script est appel trois fois :
Appel au premier tat CRITICAL/SOFT (pas daction du script)
restart-httpd CRITICAL SOFT 1

Appel au deuxime tat CRITICAL/SOFT

restart-httpd CRITICAL SOFT 2

Appel au passage ltat HARD

restart-httpd CRITICAL HARD 3

Le script restart-httpd peut par exemple tre dfini comme suit :

Script restart-httpd
#!/bin/sh # Vrification de l'tat du serveur HTTP case "$1" in OK) # Le service n'a pas de problme, rien faire ;; WARNING) # Un avertissement n'est pas trs important ;; UNKNOWN) # On ne sait pas s'il y a une erreur ou pas, on ne fait rien. ;; CRITICAL) # Le service HTTP a un problme, on le redmarre peut-tre # Est-on en tat "SOFT" ou "HARD" ? case "$2" in SOFT) # Vrification du nombre de tentatives case "$3" in 2) # Le problme est rel, on redmarre echo -n "Redmarrage du service HTTP (2e tat CRITICAL SOFT)..." /etc/init.d/httpd restart ;; esac ;;

176

Options avances de Nagios DEUXIME PARTIE

HARD) # On peut essayer de redmarrer, mais l'tat HARD # informe les contacts de toute faon echo -n "Redmarrage du service HTTP..." /etc/init.d/httpd restart ;; esac ;; esac exit 0

Gestion de leffet yoyo

Il est important dtre averti lorsquune machine ou un service tombe puis revient. Mais sil oscille entre ces deux tats plusieurs fois pendant la nuit, les administrateurs reoivent beaucoup dalertes. Ce comportement peut envoyer inutilement des alertes aux administrateurs.

Une tempte de messages

Si, une machine dmarre en deux minutes et tombe au bout dune minute, par exemple dans le cas dun service en cluster ne trouvant pas ses disques de donnes, nous obtenons en une nuit 12h (20up + 20down) = 480 messages. Tous les efforts effectus pour diminuer les alertes et augmenter leur pertinence sont vains. Ces envois multiples ne sont pas grs par le paramtre notification_interval des htes et services. Il ne permet que despacer les messages alertant dun mme tat. Ici, llment fait le yoyo entre deux. Dans cette situation, lidal est davertir les contacts que llment fait le yoyo (flapping en anglais) et denvoyer ce message avec lintervalle de temps notification_interval.

Mthode de dtection
Nagios conserve pour chaque lment ses 21 derniers tats. Cela permet davoir potentiellement 20 changements dtats. Pour chaque passage en tat HARD, il calcule le taux de variation des tats. Les valeurs les plus anciennes ont un poids moins important que les rcentes. Ce poids varie entre 0.8 pour les plus vieilles 1.2 pour les plus rcentes. Il ne prend en considration que les tats indiqus par le paramtre flap_detection_options pour les htes : o : UP ;

Trier les alertes et amliorer leur pertinence CHAPITRE 6

177

d : DOWN ; u : UNREACHABLE ;

Et pour les services : o : OK ; w : WARNING ; c : CRITICAL ; u : UNKNOWN. Le calcul du taux devient :

Il le compare ensuite deux paramtres : high_service_flap_threshold ;

low_service_flap_threshold.

Si le taux est suprieur high_sevice_flap_threshold, Nagios considre que llment se met osciller. Il envoie alors une notification dans ce sens si les valeurs notification_options de llment et des contacts ont la valeur f (flapping). Par la suite, pour savoir si llment est toujours en tat FLAPPING, il compare le taux low_sevice_flap_threshold. Si le taux calcul est plus faible, Nagios considre que ltat de flapping sarrte. Ces deux paramtres sont disponibles au niveau global de Nagios et on peut les dfinir pour chaque hte et chaque service. Il est possible de dsactiver la dtection des oscillations avec le paramtre flap_detection_enabled. Les paramtres dtectant le flapping des htes sont nomms high_host_flap_threshold et low_host_flap_threshold. La valeur par dfaut du taux high est de 50 %, celle du taux low de 25 %.

Exemple de dtection
Prenons pour exemple un service. Sur le diagramme de la figure 6-11, nous notons ses changements dtat. Les tests sont numrots dans lordre chronologique. Le service a chang dtat aux tests 5, 7, 10, 13, 15, 17, 18 et 20. Nous obtenons sans pondration un taux de 8/20=40 %. Nous appliquons ensuite les pondrations indiques en figure 6-12.

178

Options avances de Nagios DEUXIME PARTIE

Figure 611 Changement dtat dun service

Figure 612 Pondration des changements dtats

Nous obtenons, au final, un taux proche de 41 %. Sil est suprieur high_sevice_flap_threshold, le service est dclar en flapping. Sil ltait dj et que le taux est infrieur low_sevice_flap_threshold alors ltat de flapping est supprim.

Gestion des priodes de maintenance

Les serveurs et les services ne fonctionnent pas 24 heures sur 24, 365 jours par an. Des interventions sont rgulirement programmes pour effectuer les oprations de maintenance et de mise jour. Les environnements ntant pas disponibles, des alertes sont leves. Les administrateurs tant dj au courant de la situation, ces alertes sont polluantes et risquent de masquer les vrais problmes.

Trier les alertes et amliorer leur pertinence CHAPITRE 6

179

Les administrateurs peuvent spcifier une priode de maintenance sur les lments grce une commande externe. Cette dernire est, pour un hte, SCHEDULE_HOST_DOWNTIME. Elle prend les arguments suivants : host_name : nom de lhte ; start_time : date de dbut de la maintenance, exprime en temps Unix ; end_time : date de fin ; fixed : si sa valeur est 1, la date de fin a la valeur end_time, sinon cette valeur est start_time+duration ; trigger_id : identifiant dune autre priode de maintenance qui peut activer cette priode ; duration : dure de la priode de maintenance en secondes ; author : auteur ; comment : commentaire. Dautres commandes externes existent pour placer un service ou tout un groupe de machines en maintenance. Pour plus de dtails, se rfrer la documentation de Nagios.

En un mot
Un outil de supervision peut tre trs envahissant. Nagios ne fait pas exception. Des mthodes existent afin de diminuer sensiblement le nombre dalertes reues par les administrateurs. Ils peuvent se concentrer pleinement sur celles qui en valent la peine. Lorsquils regardent la console de supervision, ils peuvent en un coup dil savoir si un problme grave est en cours grce un code couleur trs simple. Nagios propose de nombreux moyens pour prvenir les administrateurs. Ceux-ci ne sont pas obligs dtre rivs leurs e-mails.

7
Services particuliers : journaux, alertes SNMP...
Certains services ne peuvent tre surveills comme les autres. La vrification des fichiers de logs (journaux) et les alertes passives en font partie. Nous allons voir comment les traiter au sein de Nagios.

Comment vrifier les fichiers journaux

Les fichiers journaux sont parmi les sources dinformations les plus prcieuses des administrateurs.

Mthode de vrification des journaux

Dans bien des cas, ces fichiers sont le seul moyen de communication entre une application et lextrieur. Lapplication y enregistre toutes les informations qui la concernent, en particulier les messages dalerte qui sont minemment intressants pour les administrateurs.

182

Options avances de Nagios DEUXIME PARTIE

Une supervision primordiale

Cette surveillance est lune des plus importantes de la solution de supervision. Elle repose sur lutilisation de plug-ins distants qui recherchent des textes particuliers dans ces fichiers. Ces textes sont spcifiques aux applications. Les administrateurs sont les mieux placs pour les reconnatre.
MTHODE Ne pas sous-estimer les journaux
Si la supervision des fichiers journaux nest pas des plus simples, elle est pourtant lune des plus puissantes. Lorsquune application commence dvier de ses objectifs, les administrateurs analysent les fichiers journaux. Une supervision leur fait gagner un temps prcieux. De plus, ceci les oblige se pencher sur ces fichiers essentiels bien avant que le premier problme ne survienne.

Ces messages nont pas tous le mme niveau de criticit. Certains annoncent des problmes futurs. Dautres rvlent des problmes graves qui sont en train de se produire dans lapplication. Sur ce point encore, les administrateurs sont les seuls pouvoir jauger la criticit.

Une analyse par morceaux

Les fichiers journaux sont parfois trs volumineux et les parcourir en entier chaque test peut avoir un impact consquent. Avec cette mthode, on analyse tout lhistorique de lapplication depuis la cration du fichier. En cas de problme, si on rpte lanalyse complte, des problmes qui ne sont plus dactualit vont nanmoins remonter en erreur. Le parcours complet systmatique nest donc pas adapt la supervision. La mthode prconise consiste, chaque test, parcourir uniquement les nouvelles lignes enregistres depuis le dernier test. La premire vrification se fait sur le fichier en entier. Cette mthode permet de dtecter les problmes une fois et une seule. Elle annule le risque de relever des erreurs qui nont plus cours. Ces tests ncessitent de conserver la position laquelle on sest arrt dans le fichier, afin de reprendre le parcours cet endroit au test suivant. On utilise pour cela un petit fichier temporaire qui sert de mmoire entre les tests. Ce fichier est dpos dans un rpertoire qui nest pas supprim au redmarrage de la machine. De cette manire, si la machine doit tre redmarre, il nest pas ncessaire de parcourir de nouveau les fichiers dans leur intgralit.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

183

Exemple de plug-in de vrification des journaux

Le plug-in ddi cette vrification est check_log2.pl. Il prend en paramtre -l le fichier de log analyser. On renseigne le chemin du fichier de positionnement laide de largument -s. Lexpression rgulire rechercher est spcifie avec -p. Le paramtre -r permet dexclure un texte particulier de la recherche. Enfin, si le retour associ une occurrence du texte recherch doit tre critique, il faut utiliser -c. Voici un exemple de recherche qui ne renvoie aucun problme.
Commande de vrification dun fichier journal
check_log2.pl -l /var/log/messages -s ~/seekfile -p Error OK - No matches found.

En cas de retour positif, le niveau dalerte souhait est lev, le nombre doccurrences du message est indiqu (ci-dessous 13) et la dernire entre est renvoye :
Commande de vrification dun fichier journal Oracle
check_log2.pl -l /oracle/bdump/alert_PROD.log -s ~/alert_PROD.seek -p 'ORA-' -c

Nous obtenons :
Rsultat positif dans la recherche
CRITICAL: (13): ORA-00600: internal error code, arguments: [memory leak], [],[],[],[],[],[],[]

Problme des tests conscutifs

Si nous nous arrtions l, la vrification des fichiers journaux serait fort simple. Malheureusement, ce nest pas le cas.

Tests suivants
Les tests qui suivent la dtection dun problme posent un problme dans la logique de supervision. Lorsquun problme est dtect, une erreur est leve. Lorsquon ritre le test, de nouvelles entres sont analyses. Le problme qui nous intresse nest relev quune seule fois. Le nombre maximal de tests avant notification des utilisateurs doit tre de 1. Les alertes sont envoyes et les actions de correction, si elles sont dfinies, sont lances. La phase SOFT de lalerte est vince. On passe directement en HARD.

184

Options avances de Nagios DEUXIME PARTIE

Si cette procdure permet dalerter immdiatement les administrateurs, elle pose la question des tests suivants et de leur traitement : il ny a aucune alerte dans le nouveau texte, le test renvoie OK ; il y a une erreur moins critique que prcdemment, par exemple un WARNING ; il y a une nouvelle erreur critique.

Test en tat OK
Dans le premier cas, le service repasse en type OK / HARD. Lalerte figure sur la console de supervision seulement pendant la dure coule entre deux tests. Si les administrateurs sont absents pendant ce temps, ils ne peuvent se fier quaux notifications. Il est noter que, si le service est configur avec une option notification_options de type r (recovery), une nouvelle notification est mise. Celle-ci annonce que le problme est rgl, alors que ce nest nullement le cas. Cest une nouvelle partie du journal qui a t analyse, mais rien nindique que le problme est bien rsolu. Il ne faut pas configurer de notification recovery sur une analyse de fichiers journaux.

Erreur de moindre importance

Dans le second cas, nous avons un changement dtat HARD. Les actions de rsolution et de notification sont effectues avec ce nouveau niveau de criticit. Les administrateurs doivent faire attention lorsquils lisent leurs alertes : ils ne doivent pas considrer uniquement le dernier tat reu, mais bien tout lhistorique reu prcdemment. Dans le cas contraire, ils peuvent manquer une erreur critique et ne prendre en considration que lavertissement.

Erreur de mme criticit

Dans ce dernier cas, nous nous trouvons face une situation problmatique : nous restons dans le mme tat que prcdemment, qui tait de type HARD. Les tentatives de correction et de notification ne sont pas lances. Pourtant, cest une nouvelle partie du fichier de log qui est analyse. Le problme est nouveau. Mme sil a de fortes chances dtre li aux prcdents messages dalertes, les administrateurs devraient en tre alerts. De nouvelles actions correctrices devraient tre lances. Nous ne pouvons pas consulter le fichier de log de Nagios. Celui-ci ne journalise que les retours de plug-ins impliquant un changement de type dtat. Cette situation est inextricable avec les mthodes de configuration de Nagios que nous avons vues jusqu maintenant.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

185

Configuration au sein de Nagios : la volatilit

Un nouveau concept peut nous tirer de ce gupier : la volatilit. Il sagit dun paramtre des services qui permet de changer le comportement des notifications et tentatives de correction. Lorsque le paramtre is_volatile vaut 1 sur un service, pour chaque retour non-OK quand le service est en tat HARD, Nagios adopte le comportement suivant : enregistrement dans le journal de Nagios ; envoi dune notification ; lancement des actions correctrices. Le paramtre is_volatile ne modifie que le comportement des services en tat HARD. Il est ncessaire de positionner correctement les paramtres vitant davoir des tats SOFT. Lexemple ci-dessous montre un paramtrage typique dun service de vrification de log :
Dfinition pour un service volatile
max_check_attempts 1 is_volatile1 notification_optionsw,c

Le service passe en tat HARD au moindre problme. Les administrateurs reoivent toutes les erreurs dcouvertes dans le fichier journal. Ils peuvent remonter sans difficult lhistorique des erreurs. Leur rsolution devrait en tre simplifie. Les actions correctrices sont lances correctement pour chaque problme. Les administrateurs ne reoivent pas non plus de notification de type recovery.

Quand chaque changement est important

Parfois, les actions lances par les services volatiles sont inutiles. Les actions correctrices et les envois de notifications sont plus embtants quautre chose en cas dalertes non-OK rptes. En revanche, la partie sauvegarde des retours des sondes est trs utile dans certains cas.

Lorsque la volatilit est de trop

Prenons lexemple des pertes de disque sur un contrleur RAID. Si le contrleur reconstruit automatiquement le disque perdu sur un disque de secours, il est impor-

186

Options avances de Nagios DEUXIME PARTIE

tant de savoir quun disque est perdu. Une alerte de type recovery prviendra les utilisateurs que tout est revenu la normale. Les administrateurs ont besoin a posteriori de remonter prcisment toutes les tapes de la reconstruction. Ils nont pas besoin dtre alerts de chaque tape. De mme, le lancement des actions correctrices na pas de sens dans cette situation. Lutilisation du paramtre is_volatile nest pas adapt.

Suivi prcis des tats

Le paramtre stalking_options est le plus mme de rpondre cette situation. Seuls les lments enregistrs dans journal de Nagios sont modifis par ce paramtre. Le comportement des notifications et des actions correctrices nest pas modifi. Ce paramtre prend en argument les tats qui doivent tre pris en compte pour la conservation des retours des plug-ins. La ligne de retour nest conserve que si ltat est vis par stalking_options, et quelle est diffrente du dernier retour. Il est inutile de rcrire les mmes lignes dans le fichier journal.

Exemple de paramtrage
Reprenons le cas de notre contrleur RAID. Voici une srie de retours du plug-in qui vrifie ltat du contrleur : 1 OK : RAID OK ; 2 WARNING : RAID degraded (1 drive down, 1 spare rebuilding) ;
3 WARNING : RAID degraded (2 drives down,1 spare online, 1 spare
rebuilding)

4 CRITICAL : RAID failed (3 drives down) ; 5 CRITICAL : RAID failed (3 drives down).

Dans le cadre dun service normal, les seuls retours enregistrs sont les tats 2 et 4. Si le service est configur avec le paramtrage suivant, les tats sauvegards sont les tats 2, 3 et 4. Ltat 5 ne lest pas car son texte est identique au prcdent.
Dfinition de loption de stalking
stalking_options w,c

Dans les deux cas, seuls 2 et 4 dclenchent les notifications et les actions correctrices.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

187

Services passifs : exemple de gestion des alertes SNMP (traps)

Nous navons voqu jusqu maintenant que les services actifs. Sils sont trs pratiques, ils ne sont pas adapts toutes les situations.

Intrt des services passifs

Prenons lexemple dune vrification de la bonne excution dune sauvegarde : il peut tre trs complexe de dterminer, a posteriori, si elle sest bien passe ou non.

Les vrifications actives ne peuvent pas tout

Si loutil de sauvegarde envoie ses informations dans un fichier journal, la supervision devient techniquement simple : il suffit de rechercher les erreurs dans ce fichier. Le problme porte plutt sur le moment o faire cette vrification. Les sauvegardes nont pas la mme dure tous les jours. Si la vrification consiste rechercher un texte signalant que la sauvegarde sest bien droule, deux cas problmatiques sont possibles : si la vrification se lance avant la fin de la sauvegarde, elle renvoie une erreur sans fondement ; si la vrification est trop tardive, elle peut retarder la rsolution du problme et de ses implications. Le moment le plus appropri est la toute fin de la sauvegarde. Le seul outil qui peut connatre ce moment est celui qui gre la sauvegarde. Il faut quil puisse avertir Nagios du rsultat de lopration.

Donner linformation dtat Nagios

Cest le rle des services passifs. Ils prviennent Nagios de ltat dun service ou dun nud sans que celui-ci ait besoin de lancer une commande pour faire la vrification. Les services peuvent tre actifs et passifs la fois. Cest mme leur configuration par dfaut. Les administrateurs peuvent contrler ce comportement laide des paramtres suivants : active_checks_enabled : autoriser les tests actifs ; passive_checks_enabled : autoriser les tests passifs. Ils sont positionns 1 par dfaut. Lenvoi de linformation se fait par commande externe. On utilise, pour les services par exemple, la commande PROCESS_SERVICE_CHECK_RESULT. Elle prend en paramtres : host_name : nom de lhte hbergeant le service ;

188

Options avances de Nagios DEUXIME PARTIE

svc_description : nom du service ; return_code : code retour ; plugin_output : sortie du plug-in.

Pour les htes, il faut utiliser PROCESS_HOST_CHECK_RESULT. Les commandes doivent tre excutes sur le serveur Nagios. Nous verrons par la suite comment lavertir depuis des serveurs distants. Les informations ne sont prises en compte que si lhte ou le service correspondant existe bien. Dans le cas contraire, on observe lentre suivante dans le fichier nagios.log :
Lhte / service nexiste pas
[1229979805] Warning: Passive check result was received for service 'Traitement' on host 'NEXISTEPAS', but the service could not be found!

Linformation est simplement oublie car incorrecte. Lors des premires mises en place des vrifications passives, il est conseill de sassurer, dans le fichier journal de Nagios, que tout se passe comme prvu. Les tats reus passivement arrivent dans la file dattente des traitements. Cette file est analyse toutes les check_result_reaper_frequency secondes. Ce paramtre figure dans le fichier de configuration principal de Nagios et vaut par dfaut 5 secondes. Les informations actives et passives sont gres de la mme manire par Nagios. Une fois dans la file dattente, il ny a plus de diffrence entre elles. La mme logique de supervision est applique toutes les informations, que ce soit sur les tats SOFT et HARD ou bien la volatilit. Nous pouvons suivre dans le fichier nagios.log les rceptions passives dtats. Voici un exemple pour le service Backup sur la machine srv-web2, qui est dclar comme tant CRITICAL.
Rception de linformation
[1229979143] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;srvweb2;Backup;2;Backup failed.

Linformation est mise dans la file dattente.

Mise en attente de linformation
[1229979143] PASSIVE SERVICE CHECK: srv-web2;Backup;2;Backup failed.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

189

Puis vient son traitement : ici, une alerte critique sur le service Backup est leve.
Traitement de linformation
[1229979144] SERVICE ALERT: srv-web2;Backup;CRITICAL;HARD;1;Backup failed.

Nous remarquons sur ce dernier exemple que les informations sur le type dtat sont prsentes. Il est en HARD et cest le premier test qui est effectu. Nous souhaitions tre averti ds la premire alerte : le script de supervision nenverra pas dautre alerte.

Notion de fracheur dun tat

Les alertes passives narrivant pas forcment un rythme rgulier, une nouvelle donne de supervision fait surface : la fracheur.

Limites des alertes passives simples

Il peut tre intressant de superviser les traitements sur des machines. Quil sagisse de scripts de sauvegarde, comme nous venons de le voir, ou bien de traitements plus applicatifs, lutilisation des alertes passives est tout indique. Les traitements peuvent envoyer leur succs (tat OK) ou leur chec (tat WARNING ou CRITICAL suivant lalerte). Les administrateurs sont avertis simplement de la bonne excution ou non des traitements. Un problme se pose cependant dans cette supervision purement passive : lalerte est leve par le traitement lui-mme. Mais que se passe-t-il sil nest pas lanc ? Il ne risque pas de prvenir quil a rencontr un problme, car il ne peut pas prvenir Nagios. Les administrateurs ne sont pas au courant du problme.

Comme pour le poisson, la fracheur est importante

Nagios rsout ce dilemme grce la fracheur des tats. Les administrateurs peuvent dfinir un dlai limite pour lobtention de nouvelles informations sur un tat. Ce dlai coul, si Nagios na pas eu de nouvelles, il tente dobtenir linformation de manire active. Cette limite de fracheur est dfinie par le paramtre freshness_threshold. On peut choisir de vrifier ou non ltat de fracheur dun service ou dun hte avec le paramtre check_freshness. Dans les situations o lon utilise la mthode passive, la voie active est sans issue. Les administrateurs nont pas choisi la voie passive pour rien. Elle va servir tout autre chose : mettre le service en erreur afin de lancer les notifications.

190

Options avances de Nagios DEUXIME PARTIE

Un plug-in toujours en erreur pour prvenir les administrateurs

Pour cela, nous utilisons une sonde qui ne fait pas grand chose : check_dummy. Elle nest capable que de renvoyer ltat que nous lui demandons avec un texte lappui. Voici un exemple simple o nous lui demandons de renvoyer un tat texte explicite.
Utilisation de check_dummy
check_dummy 1 "texte explicite." WARNING: texte explicite. echo $? 1 WARNING

et un

Nous configurons simplement le service pour quil ait comme commande de test actif check_dummy avec un texte stipulant que le traitement nest pas pass temps. Cette vrification ne doit pas tre ordonnance. Le service peut tre vu comme purement passif. Nous positionnons active_checks_enabled 0. La vrification lance cause du manque dinformations est tout de mme effectue, mme avec cette valeur.

Exemple de configuration
Voici un exemple de configuration avec prise en compte de la fracheur dun tat.
Configuration dun service passif avec vrification de la fracheur
define service{ host_name srv-web1 service_description Traitement active_checks_enabled 0 passive_checks_enabled 1 check_freshness 1 freshness_threshold 3720 check_command check_dummy!2!Traitement non lance temps. [...] }

Supposons que le traitement sexcute toutes les heures. Si le traitement ne renvoie pas dtat (que ce soit OK, WARNING ou CRITICAL) au moins toutes les 3720 secondes, la commande check_dummy est lance et place le service en tat CRITICAL (2). Les administrateurs sont alors avertis que le traitement ne sest pas lanc comme il aurait d. Cette vrification est effectue toute les service_freshness_check_interval secondes pour les services et host_freshness_check_interval secondes pour les htes. Par dfaut, elle a lieu toutes les minutes.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

191

Dans le fichier journal de Nagios, nous avons la trace suivante, indiquant que ltat du service est arriv premption.
Entre dune information prime
[1229984990] Warning: The results of service 'Traitement' on host 'srvweb1' are stale by 0d 0h 0m 57s (threshold=0d 1h 2m 0s). I'm forcing an immediate check of the service.

Lentre de journal annonce que ltat est prim depuis 57 secondes.

Positionnement correct du seuil de fracheur

Dans lexemple prcdent, le seuil de fracheur a t tabli 3720 secondes, soit une heure et deux minutes. Le traitement est cens se lancer toutes les heures. Il doit donc envoyer le rsultat toutes les 3600 secondes. Le seuil de fracheur doit tre au moins gal cette valeur. Sil est trop faible, il avertit les utilisateurs pour rien. Mettre une valeur trop grande nest pas conseill non plus. Les administrateurs sont alors prvenus tardivement du problme, potentiellement trop tard pour pouvoir le rsoudre sans que les utilisateurs le remarquent. Il ne faut pas non plus tailler trop juste. Si, dans lexemple prcdent, la valeur freshness_threshold tait de 3600 secondes, alors, au moindre retard, les administrateurs sont avertis. Les retards peuvent tre ds au traitement lui-mme sil ne sest pas lanc temps, mais galement Nagios. Comme vu prcdemment, Nagios vrifie rgulirement les informations passives. Cette vrification nest toutefois pas immdiate, ce qui peut entraner un dlai. Si Nagios ajoute deux secondes et que le traitement sest lanc comme convenu, on arrive avec un dlai de deux secondes. Lalerte est lance pour rien. Il faut ajouter une petite marge de scurit la valeur. Si le traitement est rgl comme du papier musique, un ajout de deux minutes est bien suffisant. Les administrateurs sont les mieux placs pour savoir au bout de combien de temps ils souhaitent tre prvenus du retard.

Comment grer les traps SNMP

Comme nous lavons vu au chapitre 4, le protocole SNMP est trs rpandu dans le monde des quipements rseau. Les applications qui y font appel sont peu nombreuses mais elles existent. Ce protocole prsente deux volets : la vrification active avec les polls ; les alertes passives avec les traps.

192

Options avances de Nagios DEUXIME PARTIE

Nous allons tudier laspect passif de SNMP. Chaque alerte est rfrence sur larbre SNMP en tant quOID (Object Identifier ou identifiant dobjet), comme pour les informations actives. Chaque alerte peut reprsenter un large ventail dinformations, comme le redmarrage dun lment rseau ou une erreur de connexion sur une application. Une alerte (trap) est envoye depuis llment rseau ou lapplication vers un serveur charg de la recevoir. Elle est envoye sous la forme de paquets UDP sur le port 162. Dans le cas de Nagios, cest le serveur de supervision qui accueille ce service de rception. Il se nomme, sous Linux, SNMPTRAPD. Le service SNMPTRAPD est exclusivement ddi la rception de ces alertes envoyes via SNMP. Il les transmet ensuite un autre outil qui les traduit sous une forme un peu plus lisible des fins de traitement. Cet outil de transformation est SNMPTT et utilise pour cela les MIB (Management Information Base ou base dinformations de gestion). Une fois la transformation effectue, linformation est fournie Nagios. cet effet, le script submit_check_result prvient Nagios de ltat dun service. Dans cette mise en place, toutes les alertes SNMP lances depuis un nud arrivent sur le mme service accroch dessus, sans aucune diffrenciation au niveau du service.
PRATIQUE Prfrer Centreon pour une mise en place simple et performante
Nous verrons au chapitre 11 une mthode beaucoup plus souple pour grer ces alertes, qui utilise la couche apporte par Centreon, un outil de configuration. La mthode prsente ici ne doit tre utilise que dans le cas dun Nagios mis en place seul, sans Centreon.

Configuration de SNMPTRAPD
SNMPTRAPD sert uniquement rceptionner les paquets dalertes envoyes via SNMP et les fournir SNMPTT. Nous le paramtrons avec son fichier de configuration, /etc/snmp/snmptrapd.conf. Sa configuration est la suivante :

/etc/snmp/snmptrapd.conf
traphandle default /usr/sbin/snmptt disableAuthorization yes donotlogtraps yes

Elle permet notamment les choses suivantes : dappeler SNMPTT pour toutes les alertes (traps) reues ; de ne pas avoir tenir compte de la communaut SNMP (mot de passe) sous laquelle nous avons reu les traps ;

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

193

de ne pas avoir tracer les traps reus ; cest SNMPTT qui sen chargera.

Par dfaut, SNMPTRAPD modifie les OID des alertes SNMP quil reoit. Il faut lui indiquer de les laisser au format brut. Pour cela, nous ajoutons le paramtre -On dans sa ligne de dmarrage. Sur un systme RedHat, ceci implique de modifier /etc/rc.d/ init.d/snmptrapd comme ci-dessous :
Pas de modification des OID par SNMPTRAPD
OPTIONS="-On -Lsd -p /var/run/snmptrapd.pid"

Configuration de SNMPTT
Fichier snmptt.ini
SNMPTT

est appel par SNMPTRAPD pour grer les traps reus. Sa configuration est divise en deux parties : une pour son comportement gnral ; une pour la gestion des OID.

[General],

La configuration globale se fait dans le fichier /etc/snmp/snmptt.ini. Dans la partie il faut modifier le paramtre strip_domain_list comme ci-dessous :

Entre du domaine des machines

strip_domain_list = <<END votre.domaine END

Ce paramtre permet de supprimer le nom de domaine des adresses rseau reues afin de les faire concider avec la configuration des nuds dans Nagios. Il faut galement rajouter la ligne suivante :
Utilisation de Net-SNMP
net_snmp_perl_enable = 1

Elle permet de faire appel au module OID. Conversion des fichiers MIB
SNMPTT

net_snmp

de Perl afin de traduire au mieux les

appeler

a besoin de savoir quoi faire des alertes quil reoit. Nous allons lui faire submit_check_result, qui permet denvoyer une commande externe

194

Options avances de Nagios DEUXIME PARTIE

Nagios. Nous lui passons comme paramtres le nom du nud metteur, le service TRAP dfini sur les nuds et enfin le niveau WARNING. La commande ci-dessous gnre un fichier snmptt.conf.equipement. Nous utiliserons pour chaque MIB de fabricant un nom plus explicite.
Conversion dune MIB
snmpttconvertmib in=EQUIPEMENT.MIB --out=/etc/snmp/ snmptt.conf.equipement --exec='/usr/local/nagios/libexec/eventhandlers/ submit_check_result $r TRAP 1'

Rajout des fichiers snmptt.conf.equipement dans snmptt.ini Une fois les fichiers snmptt.conf.equipement gnrs, il suffit de les rajouter dans la partie [TrapFiles] de snmptt.ini. Nous obtenons :
Dclaration des nouveaux OID
[TrapFiles] snmptt_conf_files = <<END /etc/snmp/snmptt.conf.equipement1 /etc/snmp/snmptt.conf.equipement2 END

La configuration est automatiquement prise en compte pour les prochaines alertes reues.

Configuration du service TRAP pour la rception des alertes

Pour chaque nud pouvant envoyer des alertes SNMP, nous dfinissons le service TRAP qui reoit les alertes :
Dfinition du service TRAP
define service{ service_description TRAP is_volatile 1 check_command check_dummy!0 max_check_attempts 1 active_check_enabled0 passive_checks_enabled 1 notification_interval 0 check_freshness 1 freshness_threshold 3600 [...] }

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

195

Le service est dfini comme volatile. Plusieurs traps peuvent arriver sur ce service et, pour chacun deux, les administrateurs doivent tre mis au courant. Lutilisation de check_freshness permet simplement de faire disparatre lerreur de la console de supervision au bout dune heure, grce lutilisation de check_dummy avec comme argument OK.

Exemple de rception dune alerte SNMP

Effectuons un test de redmarrage dun quipement rseau. Lors quil redmarre, il envoie une alerte de type coldStart. Celui-ci figure dans la MIB SNMPv2, MIB standard du rseau. Voici un exemple de ce que nous obtenons dans le journal de SNMPTT :
Exemple dalerte SNMP
Tue Jun 17 17:01:34 2008 .1.3.6.1.6.3.1.1.5.1 1 "Status Event" switch-1 - SNMP is restarting

Rception et traitement des alertes passives distantes

Comme nous venons de le voir, les alertes SNMP peuvent avertir dvnements sur les nuds distants. Elles sont cependant peu pratiques manier et ne sont pas adaptes la supervision double tat : OK ou WARNING/CRITICAL.

Un moyen efficace de rcolter les tats distants : NSCA

Si les traps sont le seul moyen dalerte sur les quipements SNMP, les systmes utilisent un mcanisme bas sur les commandes externes pour avertir Nagios dun tat. Cette solution est beaucoup plus souple manier. Le lancement de la commande doit tre fait sur le serveur de Nagios. Les htes distants auront du mal lancer la commande. Pour leur faciliter la tche, les administrateurs peuvent utiliser un dmon sur le serveur Nagios qui reoit les ordres donner Nagios. Ce dmon se nomme NSCA (Nagios Service Check Acceptor).

Son fonctionnement
Le dmon coute le port TCP/5667 sur le serveur Nagios. Il se compose dun simple excutable qui prend moins de 2 Mo en mmoire. Lorsquil reoit un tat, il crit simplement dans le fichier nagios.cmd les renseignements ncessaires pour informer Nagios. Les nuds utilisent un client particulier pour dialoguer avec ce dmon. La communication peut tre chiffre et base sur un mot de passe partag. Il est conseill de

196

Options avances de Nagios DEUXIME PARTIE

definir le mot de passe afin dempcher nimporte qui denvoyer des informations fausses Nagios. Le client se nomme send_nsca et il possde lui aussi un fichier de configuration. Il est disponible pour une large palette de systmes (voir figure 7-1).
SCURIT Utilisateur non privilgi
NSCA na pas besoin davoir des droits levs. Le compte le plus adapt pour le lancer est tout simplement nagios.

Figure 71 Fonctionnement de NSCA

Configuration du dmon
Le dmon utilise un fichier de configuration nomm nsca.cfg situ dans /usr/ local/nagios/etc. Il possde les proprits intressantes suivantes : server_port : port TCP que le dmon coute, par dfaut 5667 ; server_address : si spcifie, le dmon coute sur cette IP, sinon il coute sur toutes ; nsca_user : utilisateur faisant fonctionner le dmon, typiquement lutilisateur
nagios ;

nsca_group : groupe de lutilisateur prcdent, typiquement le groupe nagios ; debug : envoi ou non, par le dmon, des informations reues syslog ; command_file : chemin du fichier de commande externe de Nagios ; max_packet_age : ge maximum accept pour les commandes reues, ceci afin

dviter les tentatives de r-mission ; password : mot de passe partag entre le dmon et les clients ;

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

197

decryption_method : mthode de chiffrement utilise, devant tre la mme entre

le dmon et les clients.

CONFIGURATION Un juste milieu
La liste exhaustive des mthodes de chiffrement disponibles figure dans le fichier de configuration. Le choix doit tenir compte de la charge induite par une mthode de chiffrement trop forte comme, par exemple, RIJNDAEL-256. Un juste milieu est ncessaire suivant la capacit du serveur de supervision et le besoin de confidentialit.

Configuration du client
La configuration du client est trs simple. Elle seffectue dans le fichier send_nsca.cfg, qui ne possde que deux proprits : password : mot de passe partag entre le dmon et le client ; encryption_method : mthode de chiffrement utilise, devant tre la mme que NSCA. Une fois la configuration du dmon en place, celle du client est presque un simple copier-coller.

Lancement du dmon et du client

Le lancement du dmon est fort simple :
Lancement de NSCA
/usr/local/nagios/bin/nsca -c /usr/local/nagios/etc/nsca.cfg --daemon

Il est possible de le lancer travers xinetd. Le client send_nsca prend en argument -H le nom du serveur de supervision et en -c le chemin vers son fichier de configuration. Les informations de supervision lui sont envoyes sur son entre standard. Pour les services, il prend les options dans lordre suivant : host_name : nom du nud auquel est accroch le service ; svc_description : nom du service qui nous intresse ; return_code : code retour de ltat que lon souhaite positionner ; plugin_output : ligne de retour souhaite. Pour les htes, il suffit de ne pas mettre le champ svc_description. Les options doivent tre spars par un dlimiteur que lon fixe grce largument -d. Par dfaut, cest la tabulation qui est utilise.

198

Options avances de Nagios DEUXIME PARTIE

Il est important de noter que lon peut envoyer une information sur le service que lon souhaite. Mme sil nest pas accroch au nud sur lequel on se situe, NSCA ne refusera pas linformation. On peut, depuis lhte srv-web1, envoyer une information pour un service accroch au nud srv-web2.
PIGE La casse est importante
Il est important de respecter la casse utilise lors de la dfinition des htes et des services. Sans cela, Nagios ne peut pas faire la correspondance entre ltat reu et les objets concerns, et il ne prend pas en compte linformation. Une entre figure tout de mme dans son fichier journal pour avertir ladministrateur du problme.

web2.

Voici un exemple denvoi dtat pour un service Traitement accroch au nud srvCette commande est, par exemple, lance depuis srv-web1 :

Envoi dune information distance

printf "%s\t%s\t%d\t%s\n" srv-web2 Traitement 0 "Le traitement est bon." | /usr/local/nagios/libexec/send_nsca -H srv-nagios -c /usr/local/ nagios/etc/send_nsca.cfg

Le serveur de supervision est ici srv-nagios. Sur ce dernier, si nous avons activ debug=1 dans le fichier nsca.cfg, nous avons dans le fichier de syslog :
Rception de linformation par NSCA
Dec 24 06:04:53 srv-nagios nsca[5641]: Handling the connection... Dec 24 06:04:53 srv-nagios nsca[5641]: SERVICE CHECK -> Host Name: 'srvweb2', Service Description: 'Traitement', Return Code: '0', Output: 'Le traitement et bon.' Dec 24 06:04:53 srv-nagios nsca[5641]: End of connection...

Dans le fichier journal de Nagios, nous avons :

Rception de linformation par Nagios
[1229979143] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;srvweb2;Traitement;0;Le traitement est bon.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

199

Exemple dapplication : traitement des journaux par un service distant

Limites de la simple supervision dun fichier journal Le lancement de la commande check_log2.pl nest pas toujours pratique. Parfois, lutilisateur nagios qui la lance na pas les autorisations pour lire le fichier journal. La lecture du fichier de log se fait en une seule passe. Entre deux tests, aucune information nest conserve. Dans certains cas, ce manque de possibilits dans les corrlations entre les tests peut tre bloquant. Des outils sont spcialiss dans la gestion des journaux. Parmi les nombreux programmes Open Source qui existent, deux se distinguent particulirement : SEC et Octopussy. Tous deux sont dvelopps en Perl. Ce langage excelle dans le traitement des expressions rgulires. Le premier est un script Perl, tandis que le second est un ensemble de programmes Perl bass autour de syslog-ng. SEC est un programme crit par Risto Vaarandi. Il signifie Simple Event Correlator. Sa plus grande force est de permettre ladministrateur de faire des corrlations entre les entres des fichiers journaux. Par exemple, un utilisateur qui narrive pas sauthentifier na rien de bien inquitant. Mais si cette erreur se reproduit une dizaine de fois dans la minute, cest le signe dune attaque en cours ou dun utilisateur particulirement motiv pour se connecter.
SEC

Avec un programme comme check_log2.pl, qui ne traite les lignes quune par une, il est impossible de dtecter ce genre de comportement. Si une erreur est remonte ds quun utilisateur se trompe de mot de passe, les botes aux lettres des administrateurs sont submerges en moins dune journe. La configuration de SEC intervient dans des fichiers plats. Leur syntaxe est trs complte. La configuration suivante dtecte des tentatives infructueuses rptes :
sshd-logins.conf
type=PairWithWindow ptype=RegExp pattern=sshd\[\d+\]: \[ID \d+ auth\.error\]\ error: PAM: Authentication failed for (\S+) from \S+ desc=PAM authentication failed for $1 action=event PAM_AUTHENTICATION_FAILED_FOR_$1 ptype2=RegExp pattern2=sshd\[\d+\]: \[ID \d+ auth\.info\]\ Accepted keyboard-interactive/pam for ($1) from \S+ port \d+ ssh2 desc2=PAM authentication successful for $1 action2=none window=30

200

Options avances de Nagios DEUXIME PARTIE

type=SingleWithThreshold ptype=RegExp pattern=PAM_AUTHENTICATION_FAILED_FOR_(\S+) context=!USER_$1_ALREADY_COUNTED && !COUNTING_OFF continue=TakeNext desc=Ten authentication failures for distinct users have been observed action=pipe '%s' mail -s 'PAM alert' root; create COUNTING_OFF 3600 window=600 thresh=10

Nous nexpliquerons pas toutes les possibilits de SEC. Il mriterait un ouvrage lui tout seul. La configuration prcdente comporte trois volets. Le premier dtecte un message de type PAM: Authentication failed for USER from MACHINE. Une fois dtect, le message place en mmoire dans SEC une valeur PAM_AUTHENTICATION_FAILED_FOR_USER, valeur qui est conserve 30 secondes. Au bout de 10 valeurs consignes, un e-mail est envoy ladministrateur et la valeur COUNTING_OFF est enregistre. Cette dernire a une dure de vie dune heure. Pendant ce temps, ladministrateur ne reoit pas de nouveaux e-mails. Pour lancer SEC sur le fichier, une simple commande suffit :
Lancement de SEC
sec.pl conf=sshd-logins.conf input=/var/log/messages

Il est certes pratique de prvenir ladministrateur par e-mail, mais envoyer linformation Nagios lest encore plus. Pour cela, il suffit de remplacer lappel par :
shellcmd /usr/local/nagios/libexec/eventhandlers/submit_check_result SERVEUR LoginAttack 2 "Too many failed connection"

Laction conjointe de SEC et Nagios permet de grer les journaux de manire trs performante. Malheureusement, la configuration de SEC est complexe maintenir car elle est situe sur les machines distantes. Octopussy est un ensemble de programmes Perl que lon peut administrer par une interface web. Celle-ci permet de visualiser les alertes, mais galement de dfinir simplement de nouvelles rgles. Lorsquune entre est dtecte, elle peut faire appel en natif NSCA. Octopussy se base sur les fichiers journaux reus par syslog-ng. Ce dernier, successeur de syslogd, permet dexporter finement les log dun systme vers un serveur distant, ici le serveur Octopussy. Les fichiers lus par syslog-ng sont non
Octopussy

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

201

seulement ceux grs par syslog, mais galement nimporte quel fichier du systme. Lorsquune modification y a lieu, elle est transfre automatiquement. ne permet pas encore de corrler des vnements. En ce sens, il est moins performant que SEC. Il a pour lui sa facilit dadministration grce son interface web. Son intgration NSCA est native. Il volue rapidement et pourrait devenir sous peu la nouvelle rfrence en matire de gestion des journaux dans le monde de lOpen Source.
Octopussy

Un type de vrification particulier : surveiller un cluster

Les environnements clusteriss sont de plus en plus rpandus. Comme ils visent rpondre au besoin de haute disponibilit des applications, leur supervision nest pas des plus aise. Pour mettre en place une supervision efficace, tudions leur fonctionnement.

Des clusters varis

Les applications clusterises sont en fait plusieurs applications situes sur plusieurs nuds. Plusieurs modes de fonctionnement existent (voir figure 7-2) : actif / actif : les services sont lancs en mme temps ; actif / passif : le plus souvent deux membres, un seul est lanc la fois et le second sert de secours.

Figure 72 Actifs multiples ou non

ces diffrents modes de fonctionnement sajoutent diffrentes vues utilisateur. Les utilisateurs peuvent avoir connaissance de larchitecture du cluster, ou bien ne voir

202

Options avances de Nagios DEUXIME PARTIE

quun unique point dentre. Ne prsenter quune interface simplifie a bien des avantages. Les clients nont pas besoin de savoir comment la solution est mise en uvre. Les modifications de larchitecture, par exemple lajout dun membre, ne ncessitent pas de modifier la configuration de tous les clients (voir figure 7-3).
Figure 73

Diffrentes vues utilisateurs

Cette prsentation unique dinterface nest malheureusement pas toujours ralisable. Les mthodes de supervision doivent tre adaptes toutes ces situations.

Supervision des services rels

La supervision des clusters commence par celle des services rels. Regardons comment grer chaque type darchitecture.

En actif / actif
La supervision des services rels en mode actif / actif est trs simple. Elle se rsume superviser chaque service rel comme un simple client, ce qui implique de pouvoir sadresser directement eux. Ce nest pas leur fonctionnement en cluster qui est intressant ici, mais la capacit voir si une des ressources du cluster est en faute.

En actif / passif
Dans ce mode de fonctionnement, on a une situation normale si le service matre actif est en bon tat de fonctionnement. Le service de secours doit tre inactif. Pour cette vrification, nous utilisons la mme commande que pour la ressource active mais avec negate. Cet excutable, vu au chapitre prcdent, inverse un code retour. Par exemple, si nous vrifions un service web en commande suivante sur le nud actif :
actif / passif,

nous utilisons la

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

203

Commande sur le nud actif

check_http -H srv-actif

Et sur le nud passif :

Commande sur le nud passif
negate "check_http -H srv-passif"

MTHODE Garder la main sur la configuration

Il est important de positionner la nouvelle commande avec negate immdiatement la suite de son homologue normale. En effet, si la premire commande vient tre modifie, il faut penser corriger la seconde.

En cas de bascule du nud actif vers le nud passif, les administrateurs sont avertis que le nud matre est tomb et que le nud passif a pris le relais. Ce dernier message sera une alerte. Il est possible de ne pas utiliser negate et denvoyer uniquement les notifications de type recovery. Cette solution a malheureusement linconvnient dafficher en continu une erreur sur la console de supervision, ce qui nest pas conseill.

Avoir une vue agrge du cluster

La supervision sest limite pour linstant la surveillance indpendante de chaque service rel du cluster. Si la perte de lun dentre eux est ennuyeuse, elle nest pas critique pour le bon fonctionnement du service fourni aux utilisateurs. Ces architectures sont justement conues avec cet objectif en tte.

Plug-in check_cluster
Les administrateurs ont besoin dtre avertis de la perte dlments du cluster, mais aussi de la criticit de ces pertes. Si la perte dun lment est inquitante, la perte dautres peut tre plus critique. Le nombre de services encore actifs est une information primordiale. Tester nouveau chaque service est embtant car cette vrification a dj t faite. Cela conduirait dupliquer la configuration ncessaire ainsi que la charge associe. Nagios possde dj ces informations dtat en mmoire. Il suffit de les utiliser pour obtenir un tat global. Le plug-in check_cluster va tre mis profit ici.

204

Options avances de Nagios DEUXIME PARTIE

Ce plug-in permet davoir un indicateur agrg : il faut pour cela lui spcifier les tats des services et ce que les administrateurs considrent comme inquitant ou critique. Il prend en argument -l un intitul du cluster, utilis pour laffichage. Il attend un argument -service ou -host afin de savoir sil a affaire un type de cluster particulier. Les arguments -w et -c reprsentent le nombre dlments en tat autre que OK/UP qui doivent lever respectivement un avertissement ou une situation critique. Enfin, largument -d est une liste de codes dtat, spars par des virgules. Si les premiers arguments sont simples fournir, le dernier lest beaucoup moins.

Macros la demandes
Nous utilisons dans ce cadre la fonctionnalit de macros la demande. Ce type de macro permet dobtenir les informations relatives nimporte quel objet de Nagios, et plus seulement de celui qui est surveill. Leur format est simple. Dans le cas dun service :
Macro la demande pour un service
$NOMMACRO:nomhost:nomservice$

Pour un hte :
Macro la demande pour un nud
$NOMMACRO:nomhost$

Par exemple, pour obtenir ltat du service Http situ sur le nud positionnons la macro $SERVICESTATEID:srv-web1:Http$.

srv-web1,

nous

Elle peut tre appele par une commande sexcutant sur nimporte quel service, quil soit sur srv-web1 ou non. Considrons un cluster de services Http situs sur les serveurs srv-web1, 2, 3 et 4. La perte de 2 services est alarmante. En perdre 3 est critique. Ce cluster est illustr figure 7-4. Le service reprsentant le cluster se nomme ClusterHttp. Nous laccrochons un nud imaginaire, SuperCluster. Ce dernier est simplement un nud vrifi avec la commande check_dummy!0.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

205

Figure 74

Un cluster actif / actif de services web

Le service est associ la commande check_cluster, dont la dfinition est :

Dfinition de check_cluster
define command{ command_name check_service_cluster check_cluster --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$ }

Elle est appele par le service comme :

Appel la commande check_cluster
define service{ [...] check_command check_service_cluster!"Http Cluster"!2!3!$SERVICESTATEID:srv-web1:Http$,$SERVICESTATEID:srvweb2:Http$,$SERVICESTATEID:srv-web3:Http$, $SERVICESTATEID:srv-web4:Http$ }

PRATIQUE Alertes des services rels

Si les administrateurs sont alerts par le service cluster, il peut tre inutile de leur envoyer les alertes des services rels. Ce double envoi est prjudiciable. Il est conseill de dsactiver les notifications pour les services rels.

206

Options avances de Nagios DEUXIME PARTIE

Exemple de tests du cluster

Prenons deux exemples. Si les services Http sont tous OK, lappel est :
Appel avec tous les service en OK
check_service_cluster!"Http Cluster"!2!3!0,0,0,0

Nous obtenons :
Http Cluster ok: 4 ok, 0 warning, 0 unknown, 0 critical

Si les services Http sont en tat critique sur les serveurs srv-web1 et 2 :
Appel avec deux services en CRITICAL
check_service_cluster!"Http Cluster"!2!3!2,2,0,0

Nous obtenons :
Http Cluster problem: 2 ok, 0 warning, 0 unknown, 2 critical echo $? 1

Ne pas oublier la vue utilisateur

Seule la couche des services rels a t traite jusquici. Le service ClusterHttp nest quune construction mentale reprsentant le cluster pour les administrateurs. Malheureusement, un cluster ayant suffisamment de nuds nest quune condition ncessaire au bon fonctionnement dun service vis--vis des clients, pas une condition suffisante. La couche du service adopte pour la vue utilisateur est galement importante. Si elle est inexistante et que les utilisateurs accdent directement aux services rels, ce problme ne se pose pas. Dans le cas dune interface unique prsente lutilisateur, une vrification simpose. Cette interface est le plus souvent une IP virtuelle qui redirige les requtes clientes vers les serveurs rels. Dans cette situation, le moyen le plus simple est de se glisser dans la peau dun utilisateur. La vrification du bon fonctionnement du service vis--vis des utilisateurs, dans le cas de nos serveurs web, est un simple test Http vers Virtual IP. Il faut dfinir un hte pour cette IP virtuelle et y accrocher un test Http, comme pour nimporte quel serveur web.

Services particuliers : journaux, alertes SNMP... CHAPITRE 7

207

PSYCHOLOGIE Alertes dans le cas actif / passif

Comme vu prcdemment, dans le cas des clusters actif / passif, lors de la bascule deux alertes avertissent les contacts. Si le service de secours ne prend pas la main, les contacts ne reoivent quune seule erreur. Peu dadministrateurs vont prter attention ce manque dalerte. Il ne faut donc pas oublier de positionner un test global de la vue utilisateur, qui se substitue la mise en place de check_cluster dans ce type de cluster.

En un mot
Les services ne sont pas tous aussi simples vrifier que louverture dun port. Les services passifs ne sont pas ce quoi les administrateurs pensent immdiatement lorsquon parle de disponibilit des systmes et des applications. Ils forment pourtant une part non ngligeable des sources dinformations. Leur gestion est assure dans Nagios grce de nombreuses options avances.

8
Lhritage de configuration pour les grands environnements
La mise en place et la configuration initiale dune solution de supervision doivent tre le plus simples possible. La gestion de la solution doit galement tre aise et grer au mieux larrive de nouveaux lments superviser, afin que les utilisateurs, dj occups intgrer un nouveau matriel, naient pas subir la lourdeur dun outil cens leur faire gagner du temps.

Techniques de gestion de configuration

Toutes les mthodes de configuration dans Nagios reposent sur quelques principes simples que nous allons tudier ici.

Factoriser pour traiter les nuds similaires

Si le matriel ajout est un nime serveur applicatif ou un routeur identique tous ceux qui trnent dj firement en salle machine, il nen aura pas moins une adresse rseau et un nom diffrents. Il faut cependant utiliser au maximum les points communs des lments afin dallger au maximum la charge de ladministrateur Nagios.

210

Options avances de Nagios DEUXIME PARTIE

Prenons un premier exemple de deux nuds similaires dfinis par, nous lavons vu au chapitre 3, au minimum 9 arguments et nayant que 3 arguments diffrents (le nom, lalias et ladresse). Leurs tats sont surveills de la mme manire (avec une adresse rseau diffrente bien sr), les mmes personnes sont prvenues aux mmes horaires, etc. Pour ces deux htes, nous configurerions un total de 18 arguments, dont 12 sont communs. En transposant, nous aurions, pour N nuds, une configuration trs imposante (N x 9) avec une majorit de valeurs identiques (N x 6). Si N est grand (20 nuds par exemple), la complexit de la configuration devient beaucoup trop importante et induit une norme perte de temps. Pour peu quun administrateur ait peaufin sa configuration, il risque de passer beaucoup de temps au moindre changement commun tous ses serveurs : il doit modifier chaque configuration de nud, sans compter quil risque den oublier dans lopration. Certes, il pourrait se crer des outils pour automatiser et fiabiliser cette reconfiguration, mais ce nest pas son cur de mtier que de pallier les manques des outils.
PSYCHOLOGIE Les attentes des utilisateurs varient
Il faut faire attention au fait que le ressenti dune solution est trs diffrent suivant que nous nous plaons du point de vue des utilisateurs ou de celui des administrateurs : les utilisateurs veulent principalement des alertes pertinentes et, si possible, peu nombreuses ; pour les administrateurs, la facilit dadministration va primer. Si un outil est difficilement administrable, il est laiss de ct, mme sil est performant.

ANALOGIE Factorisation en programmation

Remarquons que nous retrouvons ici les mmes problmatiques que celles auxquelles doivent faire face les dveloppeurs dapplications : beaucoup de similitudes dans les objets, le tout exprimer avec le moins de lignes possible pour en faciliter la maintenance.

En matire de programmation, le concept de factorisation est primordial. Il consiste rassembler ce qui peut ltre afin de rduire le nombre de lignes pour que, en cas de changement, on nait besoin de modifier quun seul lment, la modification tant rpercute partout o cet lment est utilis (voir figure 8-1).
Figure 81

Factorisation

Lhritage de configuration pour les grands environnements CHAPITRE 8

211

Ce principe de bon sens quest la factorisation peut sappliquer dans Nagios : nous dfinissons un modle qui possde des valeurs de configuration, mais ne correspond aucun vrai lment supervis. Il peut cependant tre appel par un tel lment qui utilise alors les valeurs que nous avons places dans le modle. Celui-ci ne correspondant rien de rel, il nest pas surveill par Nagios. Il ne sert que de repre de configuration pour ladministrateur. Il nest pas non plus ncessaire dy renseigner toutes les valeurs obligatoires. Nous pouvons utiliser tout ou partie dun modle. Cette facilit de configuration fait partie de lensemble des techniques dhritage que nous expliquerons par la suite.

Grer les exceptions

Si regrouper les informations est important, il ne faut pas oublier que les nuds prsentent parfois de lgres variations. Si nous nous arrtions aux similitudes, la vie des administrateurs serait fort simple. Malheureusement, elle ne lest pas. Par exemple, sur les N nuds que nous avons voqus, ltat de certains peut ne pas tre important durant quelques heures de la nuit. Dautres peuvent aussi tre administrs par des personnes diffrentes. Nous devons jongler entre les grandes similitudes et les spcificits de certains nuds. Bien sr, en oubliant ces similitudes, nous pouvons gnrer la configuration de tous les nuds comme expliqu au dbut de ce chapitre. Cela va demander ladministrateur un effort surhumain pour grer sa configuration par la suite. Nous devons diminuer sa charge en optimisant la configuration. Dfinir un modle permet de diminuer la configuration en regroupant certaines valeurs. Cependant, cela ne permet pas de grer tous les cas, notamment les exceptions. En effet, comment faire cohabiter une factorisation et une diffrenciation de linformation ? Pour les concilier, nous devons utiliser une fois de plus les mthodes des programmeurs : les techniques dhritage. Si certaines sont simples, dautres sont un peu plus complexes apprhender. Mais toutes rpondent des scnarios visant simplifier la configuration tout en permettant ladministrateur Nagios de conserver ses cas particuliers.

Grer simplement une configuration complexe

Jusquici, nous navons pas encore trait des services. Ils constituent cependant la majorit de la configuration de Nagios. Cest tout lintrt dune solution comme Nagios que den proposer un panel important lutilisateur. En simplifiant, si nous avons N machines ayant chacune Y services dessus, nous obtenons une configuration de NY services. Supposons de plus que chaque service a

212

Options avances de Nagios DEUXIME PARTIE

besoin de 11 paramtres au minimum et nous arrivons une configuration de NY11 lignes. Pour les grands environnements, cest tout simplement ingrable en ltat. En effet, il est trs rapide darriver plus de 200 machines ayant chacune une quinzaine de services. Dans un tel cas, nous arrivons plus de 33 000 lignes si nous nutilisons aucune mthode de simplification de configuration. Nous allons voir que Nagios propose des mthodes permettant de rduire de manire drastique cette configuration et de laisser ladministrateur travailler sur des activits valeur ajoute. Ces mthodes sont les techniques dhritage. Nous pouvons voir en figure 8-2 un ordre de grandeur de lvolution de la complexit de la configuration en fonction du nombre dlments configurs lorsquon utilise ou non les techniques de configuration. Ladministrateur a tout intrt les utiliser, et ce mme pour un nombre dlments assez restreint.

Figure 82 volution de la complexit par rapport au nombre de nuds

COMMUNAUT Axes de dveloppement de Nagios

Nous pouvons faire une remarque ici sur les grands axes de dveloppement de Nagios. Nous pouvons en distinguer deux tout particulirement : la supervision de nouveaux lments ; la gestion de parcs de machines de plus en plus grands. Ce dernier point regroupe lamlioration des performances et la mise en place des mthodes de configuration qui permettent de grer un nombre important de machines avec le moins de configuration possible.

Lhritage de configuration pour les grands environnements CHAPITRE 8

213

Hritage de mme type : dfinition de modles

tudions une premire application du principe de factorisation dans Nagios : les modles.

Factorisation simple
Commenons notre analyse par le rle des modles.

Factorisation par modle

Pour prsenter la premire technique dhritage, nous allons repartir de lexemple de N machines similaires. Pour ces N machines, nous avions N9 paramtres dont seulement trois taient spcifiques chaque machine. Nous allons utiliser ici la factorisation de configuration, nomme aussi technique dhritage simple. Elle consiste dfinir un modle dhte comprenant les paramtres communs. Les nuds y font simplement appel et remplissent leurs propres paramtres particuliers comme leur nom ou leur adresse. Ils nont pas besoin de redfinir ceux du modle, ce qui vite les duplications. Si toutes nos machines lutilisent, nous obtenons 9+3N paramtres au lieu de 9N, ce qui donne par exemple pour 100 machines 309 paramtres au lieu de 900. Ce gain est dj fort apprciable. Ainsi, en cas de changement dun paramtre commun toutes les machines utilisant ce modle, il suffit de modifier ce dernier pour quelles soient toutes modifies. Ladministrateur ne risque pas den oublier dans lopration. Nous pouvons observer ce principe sur la figure 8-3.
Figure 83

Factorisation par modle

Mise en place dans Nagios

Nous allons dfinir un modle commun nos serveurs Linux hbergeant un serveur web. Nous le nommons linux-web-server. Nous y plaons la configuration commune nos serveurs. Nous ne prsentons ici que le paramtre des groupes de contacts, mais ladministrateur peut remplir ceux quil souhaite. Son nom doit tre rfrenc par le paramtre name et non host_name. Chaque modle doit avoir un nom diffrent.

214

Options avances de Nagios DEUXIME PARTIE

Les serveurs sont srv-web1, srv-web2, etc. Ils font appel au modle grce au mot-cl use. Le modle, ntant quune facilit de configuration, ne doit pas tre rellement cr. Il utilise le mot-cl register la valeur 0 pour que Nagios le considre comme un modle. Pour notre exemple nous obtenons :
Mise en place dun modle
define host{ name linux-web-server contacts_group admin-linux,admin-apache [...] register 0 ; dfinit un modle } define host{ use linux-web-server host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com } define host{ use linux-web-server host_name srv-web2 [...] }

Cette dfinition est quivalente la suivante :

Dfinition quivalente pour srv-web1
define host{ host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com contacts_groupadmin-linux,admin-apache }

Nous pouvons voir que la dclaration des srv-web* est trs courte, bien plus que si lon avait d mettre toutes les valeurs que demandent les nuds. Nous gagnons en maintenabilit : si nous voulons ajouter, par exemple, un groupe de contacts, il suffit de lajouter dans le modle pour quil soit appliqu automatiquement.

Lhritage de configuration pour les grands environnements CHAPITRE 8

215

Gestion des exceptions

Comme nous lavons vu, tout cela fonctionne parfaitement quand toutes nos machines sont identiques. Il y a cependant toujours une ou plusieurs machines qui font bande part. Nous pouvons dfinir toute leur configuration, sans utiliser le modle, mais cest alourdir inutilement ladministration. Cest plus dommage encore si cette diffrence ne porte que sur un seul paramtre. Cela peut tre gr simplement par lhritage simple : si une machine dfinit un paramtre dj prsent dans le modle, cest sa valeur qui prend le dessus sur celle du modle. La dfinition de lexception est donc trs simple au final, il suffit dajouter dans la configuration de la machine ce paramtre pour quil soit pris en compte. Nous conservons toujours les autres paramtres du modle. Ladministrateur peut ainsi garder la main sur sa configuration de manire simple et lgante. Nous pouvons illustrer cela avec laide de nos serveurs web. Si lun dentre eux, srvweb4, pose problme aux utilisateurs, une nouvelle quipe dadministrateurs, que lon nomme admin-experts, lobserve en plus de ses administrateurs habituels afin de trouver ce qui ne va pas. Pour cela, nous dfinissons ce serveur de la manire suivante :
Dfinition dune exception au modle sur srv-web4
define host{ use linux-web-server host_name srv-web4 contacts_group admin-linux,admin-apache,admin-experts [...] }

La valeur dfinie dans le nud prend le pas sur celle de linux-web-server.

Hritage sur les services et les contacts

Cette mthode nest heureusement pas rserve aux seuls nuds. Elle est galement utile dans le cas des dfinitions des contacts et des services. Si nous navons que peu de chances davoir beaucoup de contacts, le nombre de services que lon dfinit est, quant lui, trs important. Nous lutilisons de la mme faon que pour les nuds, savoir travers le mot-cl use. Nous pouvons en voir un exemple ci-dessous. Le modle se nomme genericservice et est appel par le service Http appliqu sur la machine srv-web3. La proprit hrite est ici contacts_groups.

216

Options avances de Nagios DEUXIME PARTIE

Utilisation dun modle de service

define service{ name generic-service contacts_groups admin-linux, admin-apache register0 } define service{ use generic-service service_description Http host srv-web3 check_command check_tcp!80 }

Nous obtenons alors une dfinition quivalente :

Dfinition quivalente pour le service Http sur srv-web3
define service{ contacts_groups linux-admin, apache-admin service_description Http host srv-web3 check_command check_tcp!80 }

Cascade dhritages
Nagios permet aux administrateurs dutiliser lhritage simple sur plusieurs niveaux.

Arbre dhritage
Nagios permet un modle den utiliser lui-mme. Cela forme un arbre dhritage. Les feuilles sont les lments rels que lon supervise, les niveaux suprieurs les modles. Lhritage est gr de proche en proche, un modle redfinissant un argument gagne par rapport ses pres, tout comme une dfinition dlment gagne par rapport son modle. Ainsi, dans cette cascade de modles, chacun apporte une spcification dans les proprits. Les lments les plus gnriques se retrouvent en haut et les lments les plus spcialiss, cest--dire les lments rels, en bas (voir figure 8-4). Ladministrateur de Nagios peut dfinir un arbre permettant de ne pas dupliquer dinformation. Pour raliser cela, on regroupe dans des modles les valeurs les plus courantes et on construit un arbre. On peut, par exemple, dfinir sur les serveurs de production une priode de vrification de 24h/24 7j/7 et un groupe de contact admin-prod.

Lhritage de configuration pour les grands environnements CHAPITRE 8

217

Figure 84

Arbre dhritage de modles

Il faut faire tout particulirement attention ce que la complexit de la configuration ne soit pas transforme en complexit dhritage. Il faut rester raisonnable dans le nombre de modles que lon dfinit.
PRATIQUE Impact de lutilisation de modles
Nous pouvons considrer cette mthode comme lune des plus efficaces pour rduire la taille de la configuration et amliorer sa maintenabilit. On peut esprer diviser par un facteur 5 le nombre de lignes de configuration de nuds ou de services, car en plus des paramtres obligatoires, il ne faut pas oublier lexistence des paramtres optionnels. Cest sans hsiter la premire mthode mettre en place sur sa configuration.

Exemple darbre dhritage

Pour illustrer ce mcanisme, nous allons repartir une fois de plus de nos serveurs web. Supposons que certains soient sous Linux, dautres sous Windows. Tous ont en commun le rle de serveur web et les mmes administrateurs : le groupe admin-apache. La diffrence entre les serveurs Windows et Linux porte sur la vrification des htes : on observe ltat du port 22 sur les Linux (le port SSH) et le port 339 sur les Windows (le port MSTSC). Avec un seul niveau dhritage, chaque type de serveur a son modle et on duplique contacts_group dans chacun. Si lon utilise un arbre dhritage, nous pouvons crer un modle qui dfinit cette valeur. Les modles linux-web et windows-web nont alors qu lutiliser. Ils dfinissent simplement leur propre appel la commande de vrification pour se diffrencier.

218

Options avances de Nagios DEUXIME PARTIE

Exemple dhritage de modles

define host{ name generic-server contacts_group admin-apache [...] register 0 ; dfini un modle } define host{ use generic-server name linux-web-server check_command check_tcp!22 register 0 } define host{ use generic-server name windows-web-server check_command check_tcp!339 register 0 } define host{ use linux-web-server host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com } define host{ use windows-web-server host_name srv-web2 [...] }

Ainsi, en cas de changement de groupe, il suffit de modifier generic-server.

Hritages multiples
Nous avons vu les hritages simples. tudions-en les limites et ce que les hritages multiples peuvent y apporter.

Lhritage de configuration pour les grands environnements CHAPITRE 8

219

Avoir plus dun modle

Dans la mthode dhritage que lon vient de voir, nous hritons dun seul modle la fois. Suivant le nombre de modles que lon dfinit, larbre dhritage peut devenir trs profond. Il est commun de diminuer le nombre de valeurs dfinies par modle et daugmenter leur nombre. Cependant, cette augmentation peut complexifier la gestion. De plus, une grande profondeur darbre implique un fort niveau de spcialisation. Cela implique galement des duplications dinformations entre les branches. Nous pouvons supprimer cette duplication grce une nouvelle technique : lhritage multiple. Le principe est simple : on hrite de plus dun modle la fois. Il ne sagit pas de deux modles qui se suivent dans larbre, mais bien de deux modles totalement distincts, de mme niveau. Ceci permet de simplifier larbre dhritage en factorisant certains modles (voir figure 8-5).
Figure 85

Technique dhritage multiple

Le modle web-server a t factoris par rapport la situation prcdente. Il peut tre rutilis en cas de mise en place dun nouveau systme dexploitation. De mme, les modles linux-server et windows-server sont dsormais indpendants de lapplication web. Nous avons dcorrl les rles de machines. Il est ainsi plus simple didentifier et de sparer les proprits en modles.

Dfinition au sein de Nagios

La dfinition de modles multiples est simple : nous dfinissons dautres modles en plus de celui que nous avons dfini prcdemment. Nous les appelons en les sparant simplement par une virgule.

220

Options avances de Nagios DEUXIME PARTIE

Exemple de dfinition
Si nous reprenons lexemple de nos serveurs web, nous obtenons :
Exemple dhritage multiple
define host{ use generic-server name linux-server check_command check_tcp!22 register 0 } define host{ use generic-server name windows-server check_command check_tcp!339 register 0 } define host{ name web-server contacts_group admin-apache register0 } define host{ use linux-server,web-server host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com } define host{ use windows-server,web-server host_name srv-web2 [...] }

Ordre dhritage entre modles

Si nous avons vit dans notre exemple davoir des modles dfinissant les mmes arguments, ce nest pas toujours le cas. Voyons comment Nagios gre cette situation.

Lhritage de configuration pour les grands environnements CHAPITRE 8

221

Priorit la premire valeur assigne

Nagios permet diffrents modles davoir des proprits communes. Il gre lordre dhritage de ces proprits afin que lutilisateur puisse prvoir ce quil va obtenir. Nous avons vu deux mthodes dhritage par modles : lhritage simple qui consiste hriter verticalement dune cascade de modles ; lhritage multiple qui consiste hriter horizontalement de plusieurs modles la suite. Nous avons vu que, dans le cas de lhritage vertical, cest la valeur de llment le plus bas (le premier lment rencontr) qui est pris en compte. Lobjectif de cela est de permettre au final la dfinition de llment rel de prendre le pas sur les modles. Appliquons ce mme principe pour lhritage multiple. Ceci implique que, dans cet hritage, la premire valeur rencontre est applique, en parcourant les modles de gauche droite. Entre ces deux hritages, la rgle est simple : Nagios parcourt lhritage vertical du dernier modle dfini, puis procde de mme pour le suivant et ainsi de suite (voir figure 8-6).
Figure 86

Ordre des hritages de modles

Exemple dordre dhritage

Reprenons lexemple prcdent et observons une application dordre dhritage. Puis, changeons lordre dhritage du nud srv-web1 et tudions en limpact.

222

Options avances de Nagios DEUXIME PARTIE

Exemple dhritage
define host{ name generic-server contacts_group admin-default register 0 } define host{ use generic-server name linux-server check_command check_tcp!22 register 0 } define host{ name web-server contacts_group admin-apache register 0 } define host{ use linux-server,web-server host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com }

Dans cette configuration, la valeur contacts_group de linux-server est admincar il hrite de generic-server, alors que celle de web-server est adminapache. Le nud srv-web1 utilise linux-server en premier et ne dfinit pas de valeur pour ses groupes de contacts, il utilise donc ceux de linux-server. Sa dfinition est donc quivalente :
default

Dfinition quivalente pour srv-web1

define host{ contacts_group admin-default host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com }

apache,

Si nous souhaitons que le nud srv-web1 ait comme groupe de contact il faut le dclarer comme ceci :

admin-

Lhritage de configuration pour les grands environnements CHAPITRE 8

223

Changement dans lordre dhritage

define host{ use web-server,linux-server host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com }

Il est alors quivalent :

Nouvelle quivalence
define host{ contacts_group admin-apache host_name srv-web1 alias srv-web1 address srv-web1.mydomain.com }

Lordre de dfinition des modles est trs important. Il faut les dfinir convenablement afin dobtenir ce que nous souhaitons. Dans la mesure du possible, il faut viter de croiser des dfinitions en hritage multiple afin de simplifier la configuration.

Rduction de la configuration : application des services sur les groupes de nuds

Nous nous sommes pour linstant intresss la taille des lments. Il faut prsent tenir compte de leur nombre, car, mme sils sont de taille raisonnable, nous risquons den obtenir un nombre trop imposant pour les grer convenablement.

Groupes de machines
Dans la plupart des cas, nous allons dfinir plus de services que de nuds. Les htes sont la base de la configuration de Nagios, les services y tant associs. Il faut dclarer chaque nud. Cependant, les services sont associs des nuds similaires. Nous avons dj utilis cette proprit pour diminuer la taille de la dclaration des nuds. Nous allons encore lutiliser pour diminuer cette fois le nombre de services configurer. Si on applique de plus les mthodes dhritage par modles sur ces dclarations, elles ne seront plus un souci.

224

Options avances de Nagios DEUXIME PARTIE

Une premire solution la configuration des services consiste appliquer la mthode vue au chapitre 5 : on dfinit chaque service pour chaque nud. Une telle configuration est lourde. Par exemple, pour 100 serveurs avec chacun 10 services, cela fait 1 000 dfinitions. Mme avec des modles 3 lignes par service, cela fait tout de mme 3 000 lignes de configuration Il est probable qu des nuds similaires correspondent des services identiques. Nous pouvons regrouper les nuds ayant des services en commun dans des groupes dhtes. Cette mise en commun permet de diminuer sensiblement le nombre de dclarations de services faire. La dfinition des groupes de nuds est contenue dans un objet hostgroup. Il contient un nom indiqu dans la proprit hostgroup_name (ayant un alias tout comme les htes) et une liste de membres groups dans la proprit members. En voici un exemple :
Dfinition dun groupe de machines
define hostgroup{ hostgroup_name Web-Servers alias Web-Servers members srv-web1,srv-web2,srv-web3 }

PIGE Diffrence entre modle et groupe de nuds

Les groupes de machines sont diffrents des modles de machines. Il faut bien faire la diffrence entre les groupes et les modles de nuds. La diffrence se situe principalement sur les similitudes des machines. En effet, lorsquon dfinit un modle, on sintresse la manire de surveiller quune machine est tombe et aux personnes prvenir en cas de problme : cest de la supervision dhtes. Lorsquon dfinit un groupe, on indique ce quil faut vrifier sur les nuds : cest de la supervision de services.

Ajout de services un groupe

tudions une technique permettant de rduire dramatiquement le nombre de services dfinis.

Dfinir un service sur un groupe de nuds

Une fois un groupe de machines dfini, on peut y associer un service. Nagios lassocie automatiquement lensemble des nuds qui le composent. Cest comme si on avait configur indpendamment ce service pour tous les nuds du groupe (voir figure 8-7).

Lhritage de configuration pour les grands environnements CHAPITRE 8

225

Figure 87 Application de services sur les groupes de nuds

Nous obtenons un effet de factorisation. Lorsquon ajoute un nouveau service, il suffit de lappliquer sur le groupe, sans avoir le redfinir autant de fois quil y a de nuds. De plus, si un nouveau serveur arrive, il suffit de lajouter dans le groupe de machines pour quil hrite automatiquement de tous les services attachs au groupe. Attention cependant : la mme dfinition de service sapplique sur lensemble des machines du groupe. Les arguments de la commande de vrification sont les mmes. Bien sr, lors du lancement des commandes, les macros sont toujours dfinies et uniques chaque membre du groupe afin de pouvoir surveiller le bon lment.

Dfinition et exemple
Cette dfinition a lieu simplement dans le service : il suffit dutiliser la proprit host_groups pour lappliquer sur le ou les groupes que nous souhaitons. En reprenant lexemple de notre service Http sur les serveurs web, nous obtenons :
Application dun service sur un groupe dhtes
define service{ use generic-service host_groups Web-Servers contacts_groups linux-admin, apache-admin service_description Http check_command check_tcp!80 }

Le service Http est ici cr sur lensemble des machines dfinies dans le groupe Webservers. Cela est quivalent :

226

Options avances de Nagios DEUXIME PARTIE

PRATIQUE Nommage des modles et des groupes de nuds

Il faut choisir une normalisation pour nommer les modles et les nuds. Il faut se souvenir quun modle nest quun lment unique qui est utilis par dautres. Un groupe est un ensemble dlments. On peut donc choisir la norme ci-dessous : un modle a un nom sans majuscule et au singulier ; un groupe a un nom en majuscule et au pluriel.

Dfinition quivalente
define service{ use generic-service host srv-web1 contacts_groups linux-admin, apache-admin service_description Http check_command check_tcp!80 } define service{ use generic-service host srv-web2 contacts_groups linux-admin, apache-admin service_description Http check_command check_tcp!80 } []

PRATIQUE Impact de lassociation des services aux groupes de nuds

Cette mthode de configuration est galement trs performante pour diminuer sensiblement la configuration des services. On peut facilement la diviser par un facteur 20. Elle est incontournable dans la gestion de la configuration de Nagios.

Gestion des exceptions

La dfinition du service sapplique sur lensemble des membres du groupe. Les exceptions lors de ces dfinitions sont possibles. Des exceptions toujours prsentes Les groupes sont gnralement utiliss pour un nombre important de services. Il se peut que, pour un hte du groupe, un service particulier fasse exception. Nous pouvons prendre pour exemple un changement dans un paramtre de la commande de supervision. Supposons quune sonde vrifie tous les disques systme et que, sur les 50 serveurs de ladministrateur, un unique serveur accde ce disque par un chemin diffrent. Il est dommage de sortir lhte du groupe pour lui crer son

Lhritage de configuration pour les grands environnements CHAPITRE 8

227

propre service, dautant plus si ce groupe se voit galement associer dautres services comme la vrification des disques de donnes ou bien la mmoire disponible. En cas dexclusion de lhte du groupe, il faudrait galement copier ces services.
PIGE Nagios 3.1 : un correctif est ncessaire
La fonctionnalit prsente ci-dessous nest possible quavec un correctif propos par lauteur. Le correctif est tout juste inclus et devrait tre disponible dans Nagios 3.2. Les versions de Nagios jusqu la 3.1, incluse ne disposent pas de cette fonctionnalit, sauf si le correctif est appliqu.

Dfinition dune exception par Nagios Heureusement, Nagios permet de redfinir sur un hte particulier un service dfini sur un groupe dhtes avec le mme nom. La dfinition sur lhte simple prend systmatiquement le pas sur celle des groupes dhtes.
PIGE Sans correctif le comportement est tout autre
Sans lapplication du correctif, les dfinitions des groupes sont systmatiquement prioritaires par rapport celles des htes simples.

Exemple dexception Par exemple, reprenons notre service Http. Imaginons que le service sur srv-web1 ait besoin dalerter, en plus des groupes linux-admin et apache-admin, le groupe adminexperts. La dfinition suivante est valide :
Application dun service sur un groupe dhtes

define service{ use generic-service host_groups Web-Servers contacts_groups linux-admin, apache-admin service_description Http check_command check_tcp!80 } define service{ use generic-service host srv-web1 contacts_groups linux-admin, apache-admin, admin-experts service_description Http check_command check_tcp!80 }

228

Options avances de Nagios DEUXIME PARTIE

Le service

apache-admin

sur srv-web1 notifie dans ce cas tous les groupes linux-admin, et expert-admin. La dfinition du service sur srv-web2 et sur le reste des serveurs dans Web-Servers nest pas modifie.
Http

Nous verrons par la suite, que dautres mthodes existent pour ajouter une exception sur un service. Celle-ci a le mrite dtre simple et de ne pas ncessiter de modifier la dfinition du service sur les groupes de nuds. Nous remarquons cependant quelle implique une duplication dinformations, cest ce que permettent dviter les mthodes que nous allons voir par la suite.

Hritage implicite : hriter dun autre type

Nous avons trait pour linstant des techniques dhritage dlments similaires entre eux, comme les htes avec les htes. Examinons maintenant les mthodes qui permettent de mlanger les genres et ce quelles apportent aux administrateurs.

Problmes soulevs par lassociation des services aux groupes

Nous avons vu quun service appliqu sur un groupe dhtes tait le mme pour chaque nud, quil sagisse des personnes prvenir ou des horaires de vrification. Certains services sont dfinis sur beaucoup de groupes. Par exemple, sur tous les groupes de serveurs Windows, on peut vrifier si un service dmarr automatiquement est arrt. Cependant, tous les serveurs de ces groupes nappartiennent pas aux mmes administrateurs et ne doivent pas ncessairement tre surveills au mme moment. En ce qui concerne les contacts, il ne faut leur envoyer que leurs alertes. Quallonsnous mettre alors dans la proprit contacts_group du service ? Il ne faut pas oublier que, si nous dfinissons une valeur, elle est la mme pour tous les nuds. Nous ne pouvons pas mettre lensemble des contacts, ni nous limiter un seul. Dans le cas des priodes de temps, certains serveurs peuvent tre en tat incohrent (un service automatique arrt par exemple) sans que cela ne soit problmatique (la nuit pendant la sauvegarde). Quallons-nous mettre comme priode de notification ? Si nous dfinissons une priode trop large, de fausses erreurs seront remontes sur ces serveurs. Si elle est trop troite, nous risquons de perdre de prcieuses alertes sur les autres serveurs qui doivent fonctionner 24h/24. Une solution simple consiste diviser le groupe en plusieurs sous-groupes et associer chacun un service avec les valeurs adquates. Nous pouvons, par exemple, crer des groupes de nuds ayant les mmes administrateurs et diviser encore ces groupes

Lhritage de configuration pour les grands environnements CHAPITRE 8

229

pour chaque priode de temps utilise. Cela implique un nombre important de groupes dfinir et maintenir. La tche se complique encore lors de la cration de services particuliers. Si nous changeons la commande lance ou ses paramtres, il faut modifier lensemble des services. Nous perdons encore en maintenabilit car nous dupliquons les informations. Nous pouvons diminuer cet impact en dfinissant des modles de services, mais ce nest quun faible palliatif.

chaque problme sa solution

Le choix est cornlien : comment choisir entre une configuration prcise et une bonne maintenabilit ?

Rechercher les informations dupliques

Le choix est simplifi par Nagios : il ny a pas de compromis faire. Ne remplissons pas les champs posant problme. Se pose alors la question suivante : ces champs (groupe de contacts et priode de temps) sont indispensables la dfinition dun service. Nagios peut-il autoriser cela ? Heureusement, il ne sarrte pas cet tat de fait. Sil lui manque une valeur, il tente de la trouver par lui mme. Ici, il faut se souvenir que nous appliquons un service sur un nud (une application sur un groupe de N nuds quivaut N dfinitions identiques du service). Les nuds possdent dj les informations sur les personnes prvenir en cas de problme et sur les heures auxquelles alerter. Nous pouvons alors lgitimement nous poser la question suivante : ces valeurs sont-elles tre diffrentes entre le nud et le service qui y est attach ? Pour la plupart des services, nous prvenons les propritaires et nous dfinissons les mmes priodes de notification que pour la machine. Nous avons une duplication dinformation entre le nud et le service. Nous allons appliquer une technique de factorisation.

Raction de Nagios
Partant de ce constat, si Nagios na pas linformation pour le service dans sa configuration, il rcupre les valeurs du nud. Nous hritons de ces valeurs pour les services. Cest un hritage entre diffrents types que lon nomme hritage implicite. La mthode consiste identifier les arguments que lon souhaite hriter du nud et ne pas les remplir sur le service associ un groupe. Le simple changement de la configuration du nud le rpercutera automatiquement sur le service (voir figure 8-8).

230

Options avances de Nagios DEUXIME PARTIE

Figure 88 Hritage implicite entre un service et un nud

Exemple dhritage implicite

Reprenons notre service Http. Nous lappliquons sur un groupe de serveurs, WebServers. Celui-ci contient les nuds srv-web3 et srv-web4. Ils ont des valeurs diffrentes pour contacts_group, srv-web4 ayant en plus admin-experts. Nous obtenons la dfinition :
Dfinition des htes
define hostgroup{ hostgroup_name Web-Servers alias Web-Servers members srv-web3,srv-web4 } define host{ use linux-web-server host_name srv-web3 contacts_group admin-apache } define host{ use linux-web-server host_name srv-web4 contacts_group admin-apache,admin-experts }

Nous dfinissons le service Http sur le groupe Web-Servers en utilisant lhritage implicite : nous ne dfinissons pas de valeur pour contacts_group :
Dfinition du service avec hritage implicite
define service{ use generic-service

Lhritage de configuration pour les grands environnements CHAPITRE 8

service_description Http host_groups Web-servers check_command check_tcp!80 }

231

Nous supposons ici que generic-service na pas de valeur contacts_group dfinie, sinon le service Http en hrite. Ici, nous obtenons une dfinition quivalente :
Dfinition quivalente des services
define service{ use generic-service service_description Http host srv-web3 contacts_group admin-apache check_command check_tcp!80 } define service{ use generic-service service_description Http host srv-web4 contacts_group admin-apache,admin-experts check_command check_tcp!80 }

Si nous modifions les contacts des htes, linformation est reporte automatiquement sur les services.
PRATIQUE Quand faut-il utiliser cette mthode ?
Dans le cas de services appliquer sur un groupe de nuds, si linformation qui pose problme est prsente dans la configuration de ces derniers, cest cette mthode quil faut utiliser. Nous pouvons esprer diminuer le nombre de groupes et de services de moiti avec cette mthode.

Une solution ne pas utiliser systmatiquement

Il faut garder lesprit que, si cette technique est pratique, il ne faut pas en abuser en cherchant lappliquer lorsque ce nest pas souhaitable. Nous pouvons prendre pour exemples les services qui doivent renvoyer une alerte quelquun dautre que les administrateurs de la machine ou un service qui doit alerter une priode de temps prcise, quelle que soit la priode de notification de la machine sous-jacente. Ces services sont la plupart du temps ceux qui ont un rle de supervision de la scurit. La scurit est bien souvent remonte une quipe ddie et na pas de priode de non-visibilit.

232

Options avances de Nagios DEUXIME PARTIE

Hritages des macros variables : gnralisation de lhritage implicite

Nous venons de voir lhritage implicite qui porte sur certains champs prdfinis. Voyons comment gnraliser ce fonctionnement dautres proprits.

Lintrt des macros variables

Bien souvent, les seules diffrences que nous avons entre deux services similaires sont les paramtres dappel de la commande de vrification. Si ces diffrences sont prsentes au niveau des nuds, nous utilisons une fonctionnalit de Nagios permettant de ne pas dcouper le service. Nous spcifions la donne directement sur le nud. Nous pouvons mettre ce mcanisme en parallle de lhritage implicite que lon vient juste de voir. Celui-ci tait un cas particulier dhritage entre le service et les nuds, concernant uniquement les valeurs des contacts et les priodes de notification. Lutilisateur peut dfinir des proprits non prdfinies par Nagios : ce sont les macros variables. Lutilisateur peut les nommer comme il le dsire avec la seule limitation que leur nom doit commencer par un _ . Lutilisateur peut y placer les valeurs quil souhaite. Elles peuvent tre utilises dans les commandes de vrification ou de notification grces aux macros : $_HOSTvaname$ ; $_SERVICEvaname$ ; $_CONTACTvaname$.
vaname

est le nom de la proprit que nous avons dfinie, sans le

_ .

Ces macros sont utilises dans une commande appele par un service commun aux diffrents nuds. Lors du lancement de la commande, Nagios substitue la valeur par celle qui a t dfinie par lutilisateur sur le nud. Nous navons plus besoin de dupliquer le service.

Exemple dutilisation
Prenons pour exemple un service qui fait une interrogation SNMP. Ici, pour simplifier, nous ne faisons pas figurer les informations communes aux vrifications. Nous nous concentrons sur une valeur qui diffre suivant les nuds : la communaut SNMP.
Dfinition des macros variables
define host{ host_name srv-web3 _SNMPCOMMUNITY public }

Lhritage de configuration pour les grands environnements CHAPITRE 8

define host{ host_name srv-web4 _SNMPCOMMUNITY secret } define service{ use generic-service service_description Snmp host srv-web3,srv-web4 check_command check_snmp } define command{ command_name check_snmp command_line $USER1$/check_snmp -H $HOSTADDRESS$ -c $_HOSTSNMPCOMMUNITY$ }

233

La commande check_snmp est diffrente lorsquelle est utilise pour le service Snmp sur le nud srv-web3 et sur srv-web4. En effet, la variable $_HOSTSNMPCOMMUNITY$ change de valeur. Nous obtenons : pour srv-web3 : /usr/local/nagios/libexec/check_snmp -H srv-web3 -c public ; pour srv-web4 : /usr/local/nagios/libexec/check_snmp -H srv-web4 -c secret.
PRATIQUE Quand faut-il utiliser cette mthode ?
Cette mthode est utilise dans les mmes cas que lhritage implicite : si linformation diffrente entre les services est spcifique aux nuds, cette mthode est applicable.

Hritage additif : ajouter une valeur au lieu de lcraser

Jusquici, pour ajouter simplement une valeur une proprit hrite, il fallait penser recopier les valeurs hrites. Le modle devenait totalement inutile cause de cette duplication. Si on modifiait le modle, il fallait penser vrifier que ses hritiers navaient pas recopi ses valeurs en les modifiant. tudions un nouveau type dhritage qui permet dviter ce genre de souci.

234

Options avances de Nagios DEUXIME PARTIE

Limites des modles simples et solution de Nagios

Pour illustrer cela, nous pouvons reprendre le cas o nous souhaitons ajouter un groupe de contacts une machine. Le serveur srv-web4 est notre cobaye attitr pour cela. Ce serveur hrite du modle linux-web-server, dfini comme :
Rappel de la dfinition du modle
define host{ name linux-web-server contacts_group admin-linux,admin-apache [...] register 0 }

Nous souhaitons ajouter le groupe admin-experts sur cette machine. Nous avons prcdemment fait cela en dfinissant srv-web4 de cette manire :
Ajout dun groupe dadministrateurs par recopie complte
define host{ use linux-web-server host_name srv-web4 contacts_group admin-linux,admin-apache,admin-experts }

Nous avons dupliqu les valeurs admin-linux et admin-apache. Si nous modifions contacts_group dans le modle linux-web-server, il faut modifier le serveur srv-web4. Nagios permet de rsoudre ce problme grce lhritage additif : on ajoute la valeur quon souhaite une valeur quon hrite. Pour cela, on prfixe tout simplement les valeurs quon ajoute dun signe +. Ce nest valable que pour les paramtres de type chane de caractres.
experts

Utilisons lhritage additif sur lexemple prcdent. Nous ajoutons le groupe adminau lieu dcraser la valeur hrite. Nous dfinissons srv-web4 de cette faon :
Ajout dun groupe dadministrateurs par hritage additif
define host{ use linux-web-server host_name srv-web4 contacts_group +admin-experts }

Lhritage de configuration pour les grands environnements CHAPITRE 8

235

Nous obtenons la mme dfinition que prcdemment, sans duplication et en amliorant la maintenabilit. Ce mcanisme permet de dfinir simplement de nouvelles valeurs par rapport celles hrites. Il peut tre trs appropri pour ajouter, par exemple, un ou plusieurs contacts particuliers sur une machine. Ladministrateur Nagios a ainsi le choix, lors de lutilisation des modles, entre utiliser les valeurs hrites en ne redfinissant pas de valeur, lui ajouter des lments grce au signe + ou bien craser compltement les valeurs sans ce caractre.

Hritage additif sur hritage implicite

Nous pouvons nous poser la question sur la raction de Nagios face lutilisation de lhritage additif sur un champ hrit implicitement. Son fonctionnement est en fait trs simple : il applique dabord lhritage implicite, puis ajoute les valeurs de lhritage additif. Si le groupe admin-experts ne souhaite recevoir que les alertes dun service particulier sur le serveur srv-web4, nous navons pas besoin de modifier la configuration du nud. Nous reprenons notre service Http. Il est dfini comme utilisant lhritage implicite, cest--dire quil avertit les contacts de la machine laquelle il est associ. Si nous souhaitons juste ajouter le groupe sons lhritage additif. Nous obtenons :
Application de lhritage additif sur un hritage implicite
define host{ host_name srv-web4 contacts_groups admin-linux,admin-web [...] } define service{ name Http host srv-web4 contacts_groups +admin-experts use template-without-contact } admin-experts

sur le service, nous utili-

236

Options avances de Nagios DEUXIME PARTIE

Nous avons alors une dfinition de Http quivalente :

Dfinition quivalente
define service{ name Http host srv-web4 contacts_groups admin-linux,admin-web,admin-experts use template-without-contact }

Nous pouvons ainsi utiliser sans crainte lhritage additif, mme sur un champ ayant t hrit de manire implicite.

Hritages : ordre de succession

Rsumons lordre dans lequel Nagios utilise ces techniques dhritage. Considrons la dclaration dun service ayant plusieurs modles et associs un groupe de machines. Pour les autres cas dhritage, il suffit de ne pas prendre en compte la phase de dclaration sur les groupes de nuds et lhritage implicite qui est particulier aux services. Quand nous dfinissons un service sur un groupe de nuds, Nagios clate simplement cette dfinition sur les membres du groupe. Pour chaque dfinition, il applique ensuite lhritage de son premier modle. Si celui-ci a un modle, lhritage est appliqu et ainsi de suite. Nagios applique ensuite le second modle. Si une valeur est dj dfinie, il ne lcrase pas. Il utilise alors sur les valeurs vides ligibles lhritage implicite : il rcupre les valeurs sur le nud. Il applique pour finir lhritage additif si lutilisateur a dfini des valeurs prcdes du signe +. Nous obtenons alors la dclaration dfinitive du service (voir figure 8-9).

Figure 89 Ordre dapplication des techniques dhritages

Lhritage de configuration pour les grands environnements CHAPITRE 8

237

PRATIQUE Se souvenir de lordre dapplication des hritages

Pour se souvenir de cet ordre, il faut penser la manire dont on pourrait rsoudre logiquement un tel problme. On applique les dfinitions machine par machine, modle par modle, en ne gardant que les premires valeurs rencontres et en ajoutant la fin ce que souhaite ladministrateur.

Impact de cette puissance de configuration

Sil est un point tout particulirement critique dans un outil de supervision, cest bien la configuration. Si le projet de supervision est rapidement une russite, il est vite dploy vers le reste du systme dinformation. Dans cette situation, la configuration se complexifie. Nous pourrions presque considrer ce problme comme tant exponentiel. Garder la main sur cette configuration est le vritable dfi de ladministrateur Nagios. Il doit factoriser le plus possible sa configuration pour que, en cas de changement, il nait pas modifier un nombre important dobjets. Cette factorisation conserve la possibilit de dfinir des exceptions. Les techniques dhritage peuvent aider ladministrateur. Vritable point fort de Nagios, elles ne sont pas toutes aussi simples utiliser. Si lhritage simple et lassociation de services des groupes de nuds sont les deux pierres angulaires de la configuration dans Nagios, ils ne peuvent pas grer toutes les exceptions simplement. De plus, le nombre de groupes et de services risque dtre important. Dans ce cas, les hritages additifs et implicites se rvlent de prcieux allis pour ladministrateur. Quant aux hritages multiples, ils permettent de rduire la profondeur de larbre dhritage et doffrir ainsi une vue plus simple de la configuration. Ces techniques sont valables lorsque nous utilisons Nagios seul. Certains outils de gestion de configuration que nous verrons par la suite proposent, en plus de celles que nous venons de voir, dautres solutions pour simplifier la configuration. Arm de ces outils, ladministrateur Nagios doit reprer les cas dutilisation de ces diffrentes mthodes. Tout au long de ce travail, il peut utiliser les pistes que nous venons dexplorer. Cette tche dpend cependant fortement de son exprience et de ses exprimentations. Ce sont ses meilleurs atouts.
PRATIQUE Mthodologie gnrale de simplification de configuration
Il faut garder lesprit que si des informations sont dupliques, il faut appliquer une technique dhritage. Il faut ensuite grer les exceptions. On choisit la mthode dhritage en fonction du contexte (nud, service, etc).

238

Options avances de Nagios DEUXIME PARTIE

En un mot
La gestion de la configuration peut devenir un vritable calvaire lorsque le nombre dlments augmente. Si ladministrateur ne fait rien, il ne peut pas grer correctement la situation au-del dune cinquantaine de machines. Nagios propose heureusement une panoplie trs toffe de mthodes pour diminuer sensiblement cette configuration. Elles sont regroupes sous le terme de techniques dhritage. Ladministrateur peut diminuer le nombre de lignes de configuration sans pour autant perdre de vue les exceptions qui ne manqueront dapparatre.

9
Pousser Nagios dans ses derniers retranchements
Sil est bien une question qui revient systmatiquement lors de ltude de Nagios, cest celle des performances. Quel serveur faut-il pour surveiller son parc ?

Les performances : une problmatique complexe

Les performances dune solution de supervision sont critiques. Les vrifications doivent tre ordonnances rgulirement. Si les tests ne sont pas effectus temps, on peut passer ct de problmes. De plus, il est fort probable que personne ne sen aperoive avant quun incident srieux ne survienne.

Des besoins divers

Le serveur Nagios a besoin dtre correctement dimensionn. Il doit supporter la charge de la supervision et de la mtrologie. Ces deux activits nont pas forcment les mmes besoins. La supervision consiste lancer un nombre lev de vrifications sur les htes distants. La mtrologie doit, quant elle, conserver un nombre plus restreint dlments, mais sur une dure trs longue.

240

Options avances de Nagios DEUXIME PARTIE

La supervision rencontre principalement des problmes de temps de calcul pour ordonnancer les tests. Si le serveur nest pas capable de suivre, les tests sont lancs en retard. Sil ne peut pas rattraper ce retard, lcart se creuse. Les tests sont de plus en plus dcals et ne se font pas aussi rapidement que le souhaitait ladministrateur. Un serveur qui dispose de ressources suffisantes lance les tests en temps et en heure. Les principaux problmes de la mtrologie concernent, quant eux, les disques. Les informations devant tre conserves sur une longue dure, lespace est une ressource critique. Si le volume ncessaire est plutt simple estimer, limpact des disques sur le traitement des donnes est plus complexe suivre et prvoir. Une mtrologie mal taille peut rapidement ralentir la supervision, avec toutes les consquences que nous venons dvoquer.

Un ordonnancement coupable
La supervision est en charge de lancer des tests rguliers. Les lments surveills sont varis. La supervision de la charge CPU est diffrente de celle des espaces disques. Lobtention des informations ne seffectue pas de la mme manire et suivant un ordonnancement diffrent. La charge varie trs rapidement. Un serveur qui ne fait pas grand chose 8h50 peut tre sous leau 9 h. La probabilit est bien moins leve de voir un disque ayant encore 100 Go despace libre se remplir en moins de 5 minutes. Le risque de problme nest pas le mme dans le temps. Les vrifications de charge doivent tre trs proches. Celles portant sur lespace disque peuvent tre bien plus espaces. Si ordonnancer les tests de manire trop rapproche nest pas problmatique pour les informations reues, a lest pour la charge de supervision. Lancer le test a un cot. La charge dun test pris unitairement est trs faible ; celle de plusieurs milliers, beaucoup moins. Prenons un exemple. Pour 1000 htes, nous vrifions la charge CPU et lespace disque. Les tests sont lancs toutes les minutes. Supposons quun test prend 50 ms. Si les tests ne sont pas lancs en mme temps, ceci demande 2000 0,050 secondes = 100 secondes, soit plus dune minute. Lordonnancement ne peut suivre ce rythme. Si nous effectuons le test sur les disques une fois par heure, nous avons en moyenne 1000 / 60 = 17 tests la minute. 50 ms par test, cela reprsente moins dune seconde de tests conscutifs. Ajouts aux 50 secondes ncessaires aux tests de la charge, nous arrivons une situation o nous avons le temps deffectuer les tests dans une minute.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

241

Cette situation est volontairement exagre. Les tests de charge la minute ne sont pas une bonne ide et, heureusement, les tests peuvent se faire de manire paralllise. Elle illustre cependant que bien ordonnancer les tests est un exercice complexe. Pour raliser cela, sadapter aux variations des indicateurs est primordial. Que les indicateurs varient rapidement ou lentement, les tests doivent suivre le rythme. Ceci permet de diminuer la charge de supervision en supprimant les informations inutiles qui peuvent ralentir la surveillance dautres lments.

Une rtention trop leve

Tout comme lordonnancement, les dures de rtention sont importantes. Les informations nont pas la mme valeur suivant quelles sont rcentes ou non. La valeur de la charge dun serveur une heure auparavant est utile pour comprendre les dficiences dune application ce moment-l. La mme information relative au mois prcdent a beaucoup moins dimportance. Les donnes de performances anciennes sont utiles pour suivre lvolution de la consommation des ressources. Si, par exemple, les administrateurs saperoivent que les processeurs sont deux fois plus chargs que trois mois auparavant, ils peuvent en rechercher la raison. Ils peuvent galement prvoir quand les ressources ne seront plus suffisantes. Le cas de lespace disque est galement intressant. Lvolution de loccupation disque est lente mais rgulire. Suivre cette information sur les derniers mois permet de savoir quand augmenter lespace disque. Ces donnes nont pas besoin davoir une granularit trs fine. Ce qui intresse les administrateurs sur une grande priode, ce sont les valeurs moyennes qui permettent de suivre au mieux lvolution. Conserver lensemble des donnes issues de Nagios est inutile. Par exemple, avec un test de charge toutes les 5 minutes, nous avons 105 000 donnes lanne. Avec 100 octets par donnes (incluant le titre, par exemple) et pour 1000 serveurs, ceci reprsente 10 Go par an simplement pour une donne. Or celle-ci nest pas la seule tre conserve. Calculer les volutions sur une dure dun an est trs long cause du volume traiter. Une agrgation des donnes est ncessaire. Il est utile de garder une granularit fine pour les donnes rcentes. Les donnes plus anciennes sont agrges sur certaines priodes prdfinies. Un des formats ddi ce travail est RRD. Il permet davoir, dans un fichier de taille rduite, lensemble des informations de performances. la cration du fichier, on renseigne les priodes de granularit et dagrgation. Ainsi, pour une donne de performance observe sur lanne, la taille du fichier est de 2 Mo. Ceci est beaucoup moins consommateur despace disque que de conserver toutes les donnes, et cela rduit dautant le risque de voir loccupation disque exploser et les accs aux disques ralentir la supervision.

242

Options avances de Nagios DEUXIME PARTIE

Observer les performances de Nagios

Avant de savoir si nous devons rviser notre ordonnancement, il est utile de savoir si les ressources de Nagios sont suffisantes. Aprs tout, est-ce utile damliorer une situation qui fonctionne bien ? Il peut tre intressant dobserver le comportement de Nagios face diverses charges de supervision. Lors de la mise en place de Nagios, les administrateurs savent ainsi jusquo ils peuvent aller en termes dajout de nuds et de services. Nagios ordonnance des tests de vrifications. Que ce soit pour surveiller des htes ou des services, il lance des sondes. Sa limite sexprime en nombre de tests lancs par minute. Sil est trop lent, il ne peut pas suivre le rythme demand par ladministrateur. Il prend du retard dans ses vrifications. Cette situation est viter tout prix.

Latence : Nagios nous montre sil tourne au ralenti

Si nous pouvons dterminer combien de tests par minute peut lancer un serveur, comment savoir si ceci suffit Nagios ?

Latence des ordonnanceurs

Nagios doit lancer un certain nombre de tests par minute. Sil y arrive, de meilleures performances ne lui servent rien. Sil ny arrive pas, il va prendre du retard. Ce phnomne est observable en figure 9-1.
Figure 91

Le phnomne de latence

Mesure de la latence : nagiostats

Ce retard est mesurable. Il est lindicateur principal du bon fonctionnement de Nagios. Il est mesur en interne pour chaque vrification dhte ou de service. Le nombre de lancements de sondes est galement conserv par Nagios. Ces donnes sont disponibles au sein du fichier dtat, status.dat. Calculer soi-mme ces donnes est lourd. Cest pour cela que Nagios propose loutil nagiostats. Celui-ci figure au mme niveau que le binaire nagios, dans /usr/ local/nagios/bin. Il prend en argument le fichier de configuration de Nagios, o il trouve les informations dont il a besoin, comme lemplacement du fichier status.dat.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

243

Il exporte un nombre important de donnes. Les plus importantes sont les suivantes : Services Checked : nombre total de services configurs ; Services Scheduled : nombre de services devant tre surveills de manire active ; Services Actively Checked : nombre de services ayant t surveills depuis le lancement de Nagios ; Services Passively Checked : nombre de services surveills de manire passive ; Total Service State Change : taux de variations minimal, maximal et moyen des tats de services, en pourcentages ; Active Service Latency : valeurs minimale, maximale et moyenne de la latence de lancement des vrifications ; Active Service Execution Time : valeurs minimale, maximale et moyenne du temps dexcution des sondes ; Active Service Checks Last 1/5/15 min scheduled : nombre de vrifications de services lances sur les priodes indiques ; Active Service Checks Last 1/5/15 min cached : nombre de tests de vrification vits car pris dans le cache (ce mcanisme sera tudi un peu plus loin) ; External Commands Last 1/5/15 min : nombre de commandes externes reues sur les dures indiques ; Used/High/Total Command Buffers : nombre de slots utiliss actuellement, au maximum et au total, pour les commandes externes. Les donnes pour les services sont galement disponibles pour les htes. Linformation tudie dans cette partie est la latence des vrifications des services actifs.

Exemple de sortie de nagiostats

Voici, par exemple, une sortie de nagiostats sur un Nagios lanc depuis 11 minutes, devant vrifier 8500 services sur un seul hte.
Exemple de sortie de nagiostats
CURRENT STATUS DATA Status File: /usr/local/nagios/var/status.dat Status File Age: 0d 0h 0m 5s Program Running Time: 0d 0h 11m 25s Used/High/Total Command Buffers: 0/0/4096 Services Checked: 8500 Services Scheduled: 8500 Services Actively Checked: 8500 Services Passively Checked: 0

244

Options avances de Nagios DEUXIME PARTIE

Total Service State Change: 0/0/0% Active Service Latency: 0.003/1.479/0.619 sec Active Service Execution Time: 0.011/0.088/0.014 sec Active Service State Change: 0.000/0.000/0.000% Active Services Last 1/5/15/60 min: 1701/8498/8500/8500 Passive Services Last 1/5/15/60 min: 0/0/0/0 Active Service Checks Last 1/5/15 min: 1701/8498/19263 Scheduled: 1701/8498/19263 Cached: 0/0/0 Passive Service Checks Last 1/5/15 min: 0/0/0 External Commands Last 1/5/15 min: 0/0/0

La latence moyenne des vrifications actives est de 0.619 seconde. Cela signifie que les tests de vrification sont lancs moins dune seconde aprs lhoraire prvu.

Supervision de la latence
Une valeur de latence infrieure la seconde est tout fait acceptable. Elle peut crotre trs fortement si nous augmentons le nombre de vrifications actives, comme nous allons le voir par la suite. Si les administrateurs ont le rflexe de vrifier, lors de la premire mise en place de Nagios, quelle latence ils ont affaire, peu pensent suivre cette valeur sur le long terme. Il est pourtant important de superviser cette valeur et il existe un moyen simple pour cela. Il suffit de crer un script qui vrifie la latence et avertit lorsquelle est trop importante. Si ce script renvoie des donnes de performances, ladministrateur peut suivre cette volution au fil des mois et voir simplement si le serveur de supervision est encore capable de suivre la cadence. Voici un script simple charg de cette vrification :
check_latency.pl
#!/usr/bin/perl $latency=`/usr/local/nagios/bin/nagiostats | grep "Active Service Latency"|cut -f3 -d'/' | awk '{print $1}' | tr -d '\n'`; if($latency > 5){ print "Latency is too high $latency | latency=$latency"; exit(1); }else{ print "Latency is ok $latency | latency=$latency"; exit(0); }

Le service auquel cette commande est accroche ne doit pas sonner lalarme la premire alerte. La latence peut augmenter temporairement, par exemple lors des sauve-

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

245

gardes du serveur de supervision. Une deux heures de latence leve reprsentent en revanche un dlai correct pour alerter les administrateurs.

Mthodologie de test de performances

La mthode de test que nous prsentons ici nous permet dobserver le comportement de Nagios lorsquil commence manquer de ressources.

Une myriade de services sur un nud

Cette mthode peut tre utile aux administrateurs pour tester les capacits de leur serveur de supervision et savoir combien de tests ils peuvent planifier avant de manquer de ressources. Le principal indicateur est la latence dexcution des sondes. Nous allons lobserver quand le nombre de tests effectus augmente. Si la latence crot trop, cest que le serveur ne peut pas suivre. Nous tudierons alors diverses mthodes visant amliorer la situation. Afin de navoir quun seul indicateur suivre, on privilgie les excutions de services. Un seul hte est dfini et on lui accroche un certain nombre de services. La machine utilise ici est un serveur quip de 2 processeurs Xeon 5160 3 GHz. Les services lancent la mme sonde avec la mme configuration. Elle consiste mettre un ping vers linterface de loopback. Ce qui nous intresse pour linstant est le nombre de tests que lon peut lancer.
REMARQUE Une charge infime
La charge induite par le ping sur linterface loopback est ngligeable face au lancement dun nouveau processus.

Configuration ncessaire
La commande lance est simple :
Dfinition de la commande check_ping
define command{ command_name check_ping command_line $USER1$/check_ping -H 127.0.0.1 -w 3000.0,80% -c 5000.0,100% -p 1 }

La commande prend 3 millisecondes pour sexcuter, ce qui est acceptable.

246

Options avances de Nagios DEUXIME PARTIE

PERFORMANCES Choix de la sonde

Pour effectuer un test de ping, le plug-in check_ping nest pas le plus efficace. La sonde check_icmp ne fait appel aucune commande intermdiaire pour envoyer la requte, contrairement check_ping qui respose pour cela sur le programme /bin/ping. Avec check_icmp, les rsultats du nombre de commandes lances sont plus impressionnants, mais l nest pas le but de lexercice.

Lhte configur se nomme srv-1 et il est attach la machine locale. Son unique rle est de servir de point dancrage aux services. Le fait quil ny ait quun seul hte na pas dimpact sur les performances tant quil est en tat UP.
Dfinition de lunique hte
define host{ use linux-server host_name srv-1 alias srv-1 address localhost }

Les services ont comme nom service-n et lancent la commande check_ping. Ils sont ordonnancs toutes les 5 minutes. Leur retour est toujours OK. Leur nombre est notre variable lors des tests. Par exemple, la dfinition du service-3 est gale :
Exemple de dfinition dun service
define service{ use generic-service host_name srv-1 service_description service-3 normal_check_interval 5 check_command check_ping }

La valeur suivie est la latence dexcution des services. Pour la rcuprer, nous utilisons le script prsent prcdemment.

Une situation idale

Cette situation est idale, voire un peu trop. Les services renvoient toujours OK, il ny a pas de test demand par les administrateurs. En conditions relles, le nombre de services que lon peut configurer est moins important, surtout avec des scripts consommant davantage de ressources. Elle permet tout de mme davoir un ordre de grandeur des performances que les administrateurs peuvent attendre de leurs futures solutions.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

247

Les intervalles de vrification des lments en tat non OK ou UP sont plus courts que les intervalles normaux. Des notifications sont envoyes de temps en temps. Des vrifications supplmentaires sont effectues pour la gestion des dpendances. Tout ceci augmente la charge de Nagios. Une marge de 20% entre nos tests et une situation relle est raisonnable.

volution de la latence en fonction du nombre de services

Commenons par gnrer 100 services. La configuration de Nagios autorise un nombre illimit de tests lancs en parallle. Voici un trac, en fonction du temps, de lvolution de la latence (voir figure 9-2).

Figure 92 volution de la latence pour 100 services

La latence reste faible. Cette machine est pleinement capable de grer le lancement de 100 commandes en 5 minutes. Lanons prsent la mesure avec 1000 services (voir figure 9-3) : Nous remarquons que la valeur de latence est similaire au cas prcdent, comportant 100 services. Les situations de bon fonctionnement de Nagios sont caractrises par une latence qui reste faible aux cours du temps.

248

Options avances de Nagios DEUXIME PARTIE

Figure 93 volution de la latence pour 1000 services

Regardons ce qui se passe avec 10 fois plus de services (voir figure 9-4).

Figure 94 volution de la latence pour 10000 services

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

249

Dans ce cas, la situation est tout autre. La latence augmente de manire importante pendant les 20 premires minutes, puis se stabilise sur un plancher. Traons cette dernire valeur suivant le nombre de services.

Figure 95 volution de la valeur plancher suivant le nombre de services

Une valeur acceptable pour la latence est de quelques secondes. On observe un phnomne de seuil. Lorsque Nagios a suffisamment de ressources pour effectuer ses tests, la latence est faible. Lorsquil commence en manquer, la situation se dgrade trs rapidement. Nous pouvons considrer quavec cette configuration, la machine peut supporter environ 9500 services toutes les 5 minutes. Nous verrons par la suite que nous pouvons fortement amliorer cette valeur. Les administrateurs peuvent reproduire ce test afin dvaluer la charge acceptable pour leur serveur. En sachant combien de tests peuvent tre lancs toutes les 5 minutes, ils peuvent configurer leur ordonnancement de faon adapte.

Tampon de traitement des informations passives

Nous venons de traiter le cas des tests actifs, mais les informations peuvent galement tre passives. Elles sont mises en attente de traitement dans le tampon des commandes externes. Cest le remplissage de ce tampon qui nous intresse. Cet indicateur est disponible par lintermdiaire de la commande nagiostats, qui fournit la

250

Options avances de Nagios DEUXIME PARTIE

taille maximale du tampon dfinie par la valeur external_command_buffer_slots de nagios.cfg. Nagios consomme les lments toutes les command_check_interval secondes. Il est fortement conseill de laisser la valeur -1 : elle signifie quil consomme les lments disponibles ds que possible. La valeur du remplissage actuel, ainsi que la valeur maximale atteinte, sont galement disponibles. Voici un exemple de valeurs :
Used/High/Total Command Buffers: 5 / 100 / 4096

Dans cette situation, lutilisation maximale du tampon de commandes passives est de commandes en attentes. Cette valeur tant loin de la limite des 4096 que compte le tampon, ladministrateur na pas de souci se faire. Dans le cas dune valeur trop proche de la limite, voire gale, il est important daugmenter la taille du tampon sous peine de perdre des informations.
100

Tout comme pour la latence, si ladministrateur a une forte utilisation des commandes externes, notamment par supervision passive, il est important de garder un il sur cette valeur.
REMARQUE Un cas rarissime
Les cas dutilisation de Nagios qui occasionnent un remplissage des 4096 commandes externes sont trs rares. Dans la plupart des installations, cette valeur est bien suffisante.

Le script ci-dessous permet dtre alert en cas de problme :

check_buffer.pl
#!/usr/bin/perl $max_tampon=`/usr/local/nagios/bin/nagiostats | grep "Used/High/Total Command Buffers"|cut -f5 -d'/' | awk '{print $1}' | tr -d '\n'`; $max_used=`/usr/local/nagios/bin/nagiostats | grep "Used/High/Total Command Buffers"|cut -f4 -d'/' | awk '{print $1}' | tr -d '\n'`; if($max_used > 0.9*max_tampon){ print "Command buffer is too low $max_used | max_used=$max_used"; exit(1); }else{ print "Command buffer is OK $max_used | max_used=$max_used"; exit(0); }

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

251

Une charge machine atypique

Nagios consomme principalement de la ressource CPU pour ce qui concerne la supervision. Nous remarquons que cette ressource peut galement servir faire fonctionner les programmes lancs par lutilisateur ou bien effectuer des oprations dans le noyau. Sur un systme Linux, la consommation de lutilisateur est mesure par le %user de temps CPU, celle du noyau par le %system. Ces mesures sont disponibles par le biais de la commande top. Les administrateurs ont lhabitude de voir un %user lev et un %system faible. Dans beaucoup de situations, les applications utilisateur sont bien plus consommatrices que le noyau. Dans le cas de Nagios, la situation est diffrente. La raison nest pas que Nagios est mal cod et gaspille des ressources, bien au contraire en fait. Nagios ne fait pas grand chose part ordonnancer beaucoup de lancements de vrifications. Ces vrifications sont des sondes lancer. Ceci signifie que le noyau doit lancer beaucoup de processus. Cette action, prise unitairement, est drisoire mais, multiplie par 10 000, elle lest beaucoup moins. Sur le serveur Nagios, il nest pas tonnant de voir un %system plus lev que la moyenne. Les sondes ne consomment en gnral gure de temps CPU. Lindicateur %user est trs utile pour savoir si cest rellement le cas. Une valeur trop leve trahit une sonde trop gourmande, qui doit tre amliore.
Le chapitre 14 donne des informations plus dtailles sur linterprtation des indicateurs de charge des systmes. Elles peuvent tre appliques au serveur Nagios afin de dterminer quelle est la ressource limitante dans une situation de contention.

Revoir lordonnancement de ses vrifications

Si un administrateur se retrouve face un systme satur, il peut commencer par changer lordonnancement des vrifications.

Diminuer le nombre de vrifications lances

Si les informations de la production ne doivent pas tre modifies, celles des environnements de qualification et de dveloppement sont mallables. Une solution pour allger la charge de Nagios consiste augmenter les dlais de vrification de ces environnements. Bien souvent, ces environnements reprsentent une moiti des serveurs. Un doublement de leurs dlais de supervision nest pas grave, ces alertes ne sont pas prioritaires. Un peu de retard est moins grave que des vrifications retardes sur un environnement de production.

252

Options avances de Nagios DEUXIME PARTIE

Si, par exemple, nous doublons le dlai de vrification sur la moiti des serveurs, la charge de Nagios est diminue de 25%. On peut alors revenir sous la limite du nombre de vrifications lances et retrouver une latence acceptable. Dans ce genre de situation, il est bon de vrifier que les recommandations fournies au dbut du chapitre ont bien t appliques. Chaque information doit tre surveille son rythme. Les gains peuvent tre rapides et demandent peu de temps. Si cest dj le cas, il est alors ncessaire damliorer le fonctionnement de Nagios. Pour cela, nous allons tudier diffrentes pistes.

Suivre les conseils de Nagios

Nagios possde une option pour indiquer ladministrateur si sa configuration peut tre amliore simplement. Il vrifie quil ny a pas de faute importante dans lordonnancement. Pour cela, il suffit de le lancer avec largument -s. Si, par exemple, ladministrateur na pas dfini la valeur 0 pour max_concurrent_checks, il impose un nombre limit de tests en parallle. Dans ce cas, si la valeur est juge trop faible par Nagios pour fonctionner correctement, il prvient ladministrateur. Nous voyons un tel exemple ci-dessous :
Lancement de nagios avec -s
SERVICE SCHEDULING INFORMATION ------------------------------Total services: 10000 Total scheduled services: 10000 Service inter-check delay method: SMART Average service check interval: 300.00 sec Inter-check delay: 0.03 sec Interleave factor method: SMART Average services per host: 10000.00 Service interleave factor: 10000 Max service check spread: 5 min First scheduled check: Sun Jan 4 16:34:11 2009 Last scheduled check: Sun Jan 4 16:39:11 2009 CHECK PROCESSING INFORMATION ---------------------------Check result reaper interval: 10 sec Max concurrent service checks: 10 PERFORMANCE SUGGESTIONS ----------------------Value for 'max_concurrent_checks' option should be >= 667

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

253

Ladministrateur a tout intrt suivre ces conseils. Une bonne solution est de laisser Nagios grer seul le nombre de tests quil va effectuer en parallle. Pour cela, le paramtre max_concurrent_checks doit valoir 0.

Amliorer les plug-ins

Les sondes sont le vecteur dobtention des informations pour Nagios. Lances sur le serveur de supervision, elles ont un cot en terme de performances.

Impact du type de sondes sur les performances

Nous ne nous sommes pas encore penchs sur les performances des sondes, mais il est temps de nous en proccuper.

Un impact fort
Que ce soit pour obtenir une information directement, ou bien pour interroger des agents, il faut un certain temps dexcution. Suivant les sondes et leur programmation, elles vont consommer des ressources qui peuvent tre du temps CPU, des entres / sorties disques ou rseau. Pris unitairement, le lancement de ces sondes passe bien souvent inaperu. La plupart sexcutent en quelques millisecondes. Ladministrateur demande Nagios dordonnancer un grand nombre de ces tests. Si le serveur ne peut pas suivre le rythme, la latence augmente et les administrateurs ne sont plus avertis assez rapidement. Les limites du serveur sexpriment en nombre de tests lancs par minute. Suivant les sondes utilises, cette limite peut fortement varier. Nous allons tudier les divers types de sondes, leur impact sur les performances et lincidence qua une meilleure intgration Nagios.

Scripts contre excutables

Les scripts sont, en rgle gnrale, plus lents lexcution que leur quivalents binaires. Ces derniers nayant pas besoin de passer par une phase dinterprtation, leur excution est directe. Parmi les langages de scripts, il existe de fortes disparits en termes de performances. Les scripts shell sont particulirement lents car ils reposent sur des lancements dexcutables. Ces appels tant lents, lexcution globale du script est ralentie. Si nous reprenons notre exemple du chapitre 3, qui permet de vrifier la prsence dun fichier, nous obtenons les deux programmes suivants.

254

Options avances de Nagios DEUXIME PARTIE

En shell tout dabord :

check_test.sh
#!/bin/bash if [ -f ./test.txt ]; then echo "le fichier existe" exit 0 else echo "le fichier n'existe pas" exit 2 fi

Et en C ensuite :
check_test.c
#include <stdio.h> main(){ FILE *fp = fopen("./test.txt","r"); if( fp ) { printf("Le fichier existe\n"); fclose(fp); return(0); } else { printf("Le fichier n'existe pas\n"); return(2); } }

Si nous lanons 10 000 fois ces deux tests nous obtenons un temps total dexcution de 30 s pour le test en shell et 8 s pour celui en C. Ils effectuent pourtant la mme vrification. Sur un grand nombre de vrifications, limpact du type de sonde est lev. Dautres langages de scripts offrent un large ventail de fonctions pour viter de faire appel des excutables extrieurs tels que cat ou grep. Des langages comme Perl ou Python, qui offrent de telles bibliothques de fonctions, sont privilgier face au shell lorsque les performances viennent manquer. Ils peuvent galement tre utiles dans le cas o les tests sont complexes raliser avec les commandes standard Unix.
DOCUMENTATION Un ouvrage de rfrence sur Python
Ceux souhaitant apprendre le langage Python peuvent se tourner vers le livre sur Python de Tarek Ziad aux ditions Eyrolles. Les administrateurs pourront mme grce lui prendre got la programmation. R Tarek Ziad, Programmation Python, syntaxe, conception et optimisation, Eyrolles, 2e dition 2009

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

255

Les scripts sont en rgle gnrale plus simple crire que du code en C. Leur maintenance en est facilite. Davantage de dveloppeurs sont capables de crer des scripts que des binaires. Ceci peut avoir un impact important car, dans le monde des administrateurs, peu sont galement dveloppeurs. Changer un script sera plus simple que modifier et recompiler un fichier .c.

Utilisation de linterprteur Perl intgr

Un grand nombre de sondes de supervision sont disponibles sous la forme de scripts Perl. Le moindre gain sur ce langage peut avoir des rpercussions importantes sur les performances de Nagios.

Un interprteur intgr
Ce langage a le soutien des administrateurs. Il existe un grand nombre de bibliothques pour effectuer les tches dadministrations courantes. tant un langage de scripts, il est interprt par le binaire perl. Cette interprtation a un cot non ngligeable en termes de temps CPU. Laction demande, avant mme son excution, mobilise une partie des ressources CPU. Si laction est rpte un nombre important de fois, la consommation est importante. Si Nagios fait appel au script directement, celui-ci sera compil par Perl chaque demande. Ceci a un impact important sur les performances. Nagios propose un interprteur Perl interne dot dun cache, nomm ePN (pour embedded Perl Nagios). Au premier ordonnancement du script Perl, Nagios le compile en bytecode. Ce dernier est plac dans un cache. Nagios peut ensuite lexcuter sans avoir passer par le binaire perl. Lorsque le script est demand nouveau, la phase de compilation nest plus ncessaire car le code est dj en cache. La phase dexcution peut directement se lancer. Lexcution tant lance par le processus Nagios, cest une excution de processus que lon spargne. Ce gain est important et apprciable lorsque le serveur est charg. Le fait de mettre en cache le code excuter prsente un inconvnient : si le script est modifi aprs avoir t compil par Nagios, les modifications ne sont pas prises en compte. Il est alors ncessaire de relancer Nagios pour quil compile nouveau le script.
ePN nest par limit aux lancements de vrifications. Il est galement utilis pour toutes les autres commandes que lance Nagios. Les notifications et les commandes de rsolution peuvent en tirer partie.

256

Options avances de Nagios DEUXIME PARTIE

Exemple dutilisation dePN

Prenons par exemple le script check_bonding.pl. Il vrifie, dans les informations du noyau, ltat des liens rseau agrgs en lisant les fichiers du rpertoire /proc/net/ bonding/. Ces derniers dresse une liste dinformations sur les diffrents agrgats. Si linterprteur nest pas utilis, on observe sur le systme les processus suivants :
Lancement dun plug-in Perl sans interprteur interne
/usr/bin/perl /usr/local/nagios/libexec/check_bonding.pl

Ils ont comme pre un processus nagios, lui mme issu du processus matre. Lorsque linterprteur intgr est utilis, ces processus /usr/bin/perl disparaissent. Ce sont les processus nagios qui effectuent la commande, sans avoir appeler le binaire / usr/bin/perl. Regardons la limite des tests lancs avec et sans utilisation de linterprteur intgr. Il est noter que les options de performances avances, analyses plus loin dans ce chapitre, sont galement appliques.

Figure 96 Impact de linterprteur Perl intgr

Lintrt de linterprteur intgr est trs lev pour les administrateurs faisant appel beaucoup de scripts Perl. On observe un gain de 30%.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

257

Pour activer cette fonctionnalit, loption enable_embedded_perl du fichier nagios.cfg doit tre positionne 1. Nagios doit galement tre compil avec cet interprteur, mais cest gnralement le cas.
PERFORMANCES Le cache Perl est important
la compilation de Nagios, on peut lui demander de ne pas utiliser de cache pour les plug-ins Perl. Cette configuration est dconseiller trs fortement. Nagios devant recompiler le script chaque lancement, les performances seront moins bonnes que si le plug-in est appel travers le binaire perl.

Tous les scripts Perl ne peuvent tre utiliss de cette manire. Par exemple, les morceaux de codes <DATA> ou BEGIN ne peuvent tre utiliss par linterprteur interne. Dans ce cas, cest le binaire perl qui prend le relais, mais ladministrateur perd alors le bnfice des performances.

Tester un script avec linterprteur intgr

Il est possible de tester un script Perl avec linterprteur intgr avant de linclure dans Nagios. Pour cela, un binaire compiler, nomm new_mini_epn, est disponible dans le rpertoire contrib des sources de Nagios. Un simple :
cd contrib make new_mini_epn

suffit pour le compiler. Une fois lanc, il demande la ligne de commande lancer. Il se comporte alors comme le module ePN de Nagios. Avec le script check_mem.pl, nous obtenons :
Test dune sonde avec new_mini_epn
new_mini_epn plugin command line: /usr/local/nagios/libexec/check_mem.pl -w 90 -c 95 embedded perl compiled plugin /usr/local/nagios/libexec/check_mem.pl with error: Can't locate utils.pm in @INC (@INC contains: /home/nagios/ nagios-3.0.5/contrib

Une erreur de compilation sest produite. Le script check_mem.pl fait appel au fichier module Perl utils.pm. Ce dernier nest pas disponible dans le rpertoire courant de new_mini_epn, il ne peut donc pas lutiliser. Si nous copions ce fichier (disponible dans /usr/local/nagios/libexec) dans contrib et que nous relanons notre test, nous obtenons :

258

Options avances de Nagios DEUXIME PARTIE

Lancement russi
plugin command line: /usr/local/nagios/libexec/check_mem.pl -w 90 -c 95 embedded perl plugin return code and output was: 0 & OK: 29% Used Memory | MemUsed=29%;90;95

PIGE Le fichier utils.pm

Lorsquun script Perl est appel travers le binaire perl, il fait appel au fichier utils.pm dans le rpertoire du plug-in, soit /usr/local/nagios/libexec. Dans le cas dune excution travers ePN, ce fichier est pris dans le rpertoire /usr/local/nagios/bin. Oublier de copier utils.pm dans ce rpertoire est une cause classique derreur avec ePN. Un lien vers le fichier prsent dans libexec suffit ePN.

Ladministrateur a tout intrt tester ses scripts avec cet excutable afin de vrifier leur fonctionnement dans ePN. Si un script nest pas correct et sil nest pas possible de le corriger, il est important de spcifier Nagios de ne pas utiliser linterprteur interne. Cest ce que nous allons voir de suite.

Spcifier Nagios dutiliser ou non ePN

Pour viter de recompiler inutilement un script qui nest pas compatible avec linterprteur, on peut spcifier la ligne suivante demandant Nagios de ne pas le compiler :
Dsactivation de lePN pour ce script
# nagios: -epn

Nagios propose par ailleurs loption use_embedded_perl_implicitly dans son fichier nagios.cfg, grce laquelle les administrateurs peuvent prciser sil doivent ou non activer automatiquement linterprteur pour tous les scripts Perl. Dans le cas o linterprteur est dsactiv automatiquement, ladministrateur peut utiliser la ligne suivante pour demander Nagios de compiler le script en interne :
Activation de lePN pour ce script
# nagios: +epn

Ces lignes doivent figurer parmi les 10 premires lignes du script.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

259

Mise en place progressive dePN

Si les administrateurs nont pas de problme de performances, le plus simple pour eux est de dsactiver lePN. Dans le cas contraire, il est recommand de le mettre en place progressivement. Les performances peuvent se dgrader si Nagios essaie continuellement de compiler un script qui nest pas dvelopp dans ce but. Le paramtre use_embedded_perl_implicitly doit tre positionn 0 et les scripts tests petit petit, avec new_mini_epn. Lajout de la ligne +epn permet de les intgrer dans loutil.

NRPE ou SSH
Au chapitre 4, il est fait mention du protocole SSH comme remplaant possibles de NRPE. Si les deux offrent un chiffrement fort pour effectuer des commandes distance, leur impact en termes de performances nest pas identique. SSH consomme en effet presque trois fois plus de ressources CPU que NRPE. Ceci est d principalement une phase dauthentification par cls qui nest pas prsente dans NRPE. Cette phase permet dauthentifier formellement un serveur distant avec SSH. NRPE se base quant lui sur les adresses IP. Sur le serveur test, on obtient pour les tests NRPE une limite de presque 30000 pour 5 minutes (avec les options de performances dcrites plus loin), contre seulement 15000 pour SSH. En cas de problmes de performances, il est prfrable deffectuer les vrifications par NRPE plutt qu travers SSH.
PERFORMANCES Les conditions du test
Dans le cas de SSH, nous avons utilis le protocole aes128-cbr. Cest le plus rpandu et il offre de trs bonnes performances.

Des vrifications actives aux passives

Les vrifications actives demandent Nagios de lancer un processus afin dobtenir une information. Dans le cas dune vrification passive, linformation est envoye dans le fichier nagios.cmd, qui est lu rgulirement par Nagios. La lecture du fichier a un impact bien moindre sur les performances que le lancement dun nouveau processus. Le passage de vrifications actives passives peut faire gagner en performances. Ce gain a un cot trs important, pour ladministrateur, en termes de gestion de la configuration. Il doit ordonnancer lenvoi des tats sur lensemble des machines du parc ce qui est dj, en soi, trs long. De plus, toute modification de cet ordonnancement demande aussi un temps consquent. La configuration des priodes de fracheur est galement requise dans ce cadre. Si son impact est ngligeable sur les performances, il en va tout autrement du ct de la configuration.

260

Options avances de Nagios DEUXIME PARTIE

Sauf si des problmes de performances se profilent lhorizon, les vrifications passives doivent tre cantonnes la supervision de traitements particuliers. Il est conseill, avant de passer aux vrifications passives en cas de problmes de performances, de tester toutes les possibilits de Nagios. Les solutions tant nombreuses, rares sont les situations o des administrateurs doivent sacrifier leurs tests actifs.

La virtualisation malheureusement encore dconseille

La virtualisation des systmes est trs pratique. Elle nest malheureusement pas miraculeuse. Son utilisation est adapte des situations o la performance nest pas critique. Les temps de calcul, dans lespace noyau des systmes virtualiss, sont plus consquents que sur une machine physique. Ceci peut fortement ralentir Nagios. Une part non ngligeable du temps de calcul du serveur consiste lancer de nouveaux processus. Les temps systme tant augments, les machines virtualises vont tre moins performantes quune machine physique quivalente. Prenons comme exemple un clbre systme de virtualisation pour serveur, install sur un serveur dot dun processeur Xeon 5160, o deux curs virtuels sont ddis une machine virtuelle. Un mme environnement est install sur un serveur physique ayant galement un processeur Xeon 5160 (soit deux curs).

Figure 97 Diffrence entre machine virtuelle et physique

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

261

Comme nous pouvons le voir, la perte de performances est brutale, de lordre de 40 %. Si ladministrateur na pas besoin dune telle puissance, la virtualisation est privilgier. Dans le cas contraire, il doit prfrer une machine physique.
PERFORMANCES Conditions du test
Les administrateurs de virtualisation peuvent se poser des questions sur les conditions du test. Le serveur de supervision tait totalement jour, les tools taient installs correctement sur la machine virtuelle. Les autres machines fonctionnant sur le serveur taient au repos et le %ready (temps dattente de la machine) tait infrieur 3 %. La machine virtuelle navait pas de limite en mmoire ou en processeur. Le serveur hbergeant les machines ntait pas surcharg. De nombreux tests disponibles sur Internet arrivent au mme rsultat.

Options de configuration augmentant les performances

Les sondes ayant t optimises, il ne reste plus qu demander Nagios damliorer ses propres performances.

Mcanismes de cache de Nagios

Les vrifications lances par Nagios ne sont pas uniquement celles que demandent les administrateurs. Nous avons vu limpact des vrifications. tudions celui de ces tests supplmentaires et comment le diminuer.

Vrifications supplmentaires
Dans certains cas, Nagios prend linitiative de lancer de nouvelles vrifications pour claircir une situation. Cest le cas, par exemple, pour les relations de parent rseau. Si un nud ne rpond pas, Nagios vrifie ses parents (sil en a) afin de dterminer lorigine exacte de la perte. Le mme systme existe pour les dpendances de services. Ces vrifications entrent dans le groupe des vrifications on demand ( la demande), lances pour vrifier les dpendances. Leur nombre peut varier fortement suivant les relations entre les lments, par exemple sil existe une grande hirarchie au sein du rseau. Lutilitaire nagiostats offre une vue sur le nombre de ces tests supplmentaires qui sont lancs au fil du temps. Les lignes suivantes leur sont ddies :

262

Options avances de Nagios DEUXIME PARTIE

Exemple de vrifications on demand

Active Host Checks Last 1/5/15 min: On-demand: 7 / 36 / 100 Active Service Checks Last 1/5/15 min: On-demand: 0 / 0 / 0

Sur cet exemple, il y a eu des tests supplmentaires pour les htes et ce, principalement pour la gestion des liens de parent. Les htes et les services sont surveills rgulirement. Un test de vrification hors ordonnancement normal peut trs bien survenir quelques secondes aprs un prcdent test normal . Dans une grande majorit de cas, ltat sera le mme. Il est intressant de rcuprer en mmoire ltat de llment et de ne pas relancer le test.

Rutilisation des tats en mmoire

Nagios propose un tel mcanisme avec le cache de tests. Il peut, dans les situations demandant de nouveaux tests, utiliser les valeurs dj acquises. Bien entendu, plus le temps passe, plus ces informations sont potentiellement primes. Il propose ladministrateur une limite de temps paramtrable pour lge des tats. Si ceux-ci sont trop vieux, il relance un test. Dans le cas contraire, il les utilise. Les deux paramtres suivants permettent ladministrateur de spcifier ces ges pour les htes et les services :
Paramtres du cache dtats de Nagios
cached_host_check_horizon=15 cached_service_check_horizon=15

Ces valeurs sont exprimes en secondes. Dans cette configuration, si ltat en mmoire est g de moins de 15 secondes, il sera pris en considration sans avoir besoin de relancer de nouveaux tests.

Performances contre prcision

Comme dans beaucoup de situations, ce que lon gagne en performances est perdu en prcision. Si nous augmentons le temps de validit des tats en mmoire, les informations peuvent se rvler inexactes. Une machine fonctionnant bien un instant t peut avoir de gros problmes t + 30 s. Dans le cas des htes, une erreur pourrait tre leve sur un nud, alors que cest son parent qui est tomb. Ceci se produit si le test du parent, encore positif quelques secondes auparavant, a t pris dans le cache.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

263

Cest pour cette raison que certains administrateurs dcident de purement et simplement dsactiver le cache. Pour cela, il paramtrer le temps de validit 0 seconde. Dautres vont accepter ces informations imprcises de temps en temps. Si, par exemple, leur installation est sa limite de performance, le gain que reprsente une latence acceptable est bien suprieur quelques imprcisions.

Trouver un bon cache hit ratio

Le cache hit ratio peut tre dfini comme le rapport du nombre de tests pris en mmoire sur le nombre total de demandes de revrifications. Ces valeurs sont fournies par nagiostats. Par exemple :
Exemple de rsultat de nagiostats
Active Host Checks Last 1/5/15 min: On-demand: 7 / 42 / 109 Cached: 4 / 33 / 93 190 / 699 / 2141

Nous remarquons quici, sur les 699 tests de machines lancs ces 5 dernires minutes, 42 taient des demandes de revrifications. Ceci reprsente presque 6 % de tests supplmentaires. 33 de ces tests ont t vits. Ceci reprsente 80 % de tests supplmentaires vits. Cest notre cache hit ratio. Dans cet exemple, le temps de validit est de 30 secondes. Si nous diminuons cette valeur, le taux chute fortement. Les administrateurs peuvent suivre cet indicateur et positionner comme ils souhaitent les dures de validit des caches. Il est conseill de maintenir une valeur faible si les administrateurs nont pas de problme de performances. Les informations quils reoivent sont alors totalement pertinentes.

Options spcifiques aux environnements trs tendus

Lorsque les administrateurs ont vrifi leur ordonnancement, que toutes leurs sondes sont optimises et que, malgr tout, la latence est trop leve, il reste encore un espoir, trois en fait. Ce sont les options de configuration pour les grands environnements. Ces options peuvent augmenter trs fortement les performances de Nagios. Elles ne sont pas sans risque. Nous allons les tudier toutes les trois et observer leur impact sur le nombre de vrifications quil est possible dordonnancer. Il sagit des Large Installation Tweaks.

264

Options avances de Nagios DEUXIME PARTIE

Suppression des variables denvironnement

Les macros sont fournies aux commandes de vrification par deux biais : les arguments des sondes ; les variables denvironnement. Cette dernire utilisation nest pas trs rpandue. Il est bien plus simple de passer les valeurs par les arguments, dont la configuration est plus visible . Le positionnement des variables est trs coteux en termes de calcul. On peut demander Nagios de ne pas le faire. Pour cela, largument fichier nagios.cfg.
enable_environment_macros

doit tre positionn 0 dans le

Dsactivation des macros denvironnement

enable_environment_macros=0

Il est important de vrifier que les sondes mises en place par ladministrateur nutilisent pas cette fonctionnalit. Si cest le cas, il est ncessaire de les modifier pour quelles utilisent ces valeurs travers les arguments. Si limpact de cette modification en termes de performance nest pas miraculeux, il est tout de mme apprciable. Voici par exemple la courbe des seuils de latence sur le serveur pris en exemple, avec et sans lutilisation de ce paramtre.

Figure 98 Impact du paramtre enable_environment_macros

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

265

Lamlioration est de lordre de 15%. Son impact nest pas trs important car lutilisation des variables denvironnement est anecdotique parmi les sondes standards.

Nettoyage de lespace mmoire des plug-ins

Lorsquun sous-processus ayant lanc une commande se termine, Nagios nettoie sa mmoire alloue. Ceci fait partie des mesures conseilles mais non obligatoires sur un systme. Le systme nettoie de toute manire la mmoire libre avant de la fournir un nouveau processus. Cette prcaution est inutile dans le cadre dun systme surcharg. Nagios peut ne pas nettoyer lespace allou si ladministrateur lui en fait la demande. Ceci passe par le paramtre free_child_process_memory de nagios.cfg. La valeur 0 permet de ne pas lancer le nettoyage lors de la fermeture du processus.
Suppression du nettoyage de lespace mmoire des fils
free_child_process_memory=0

La courbe suivante prsente limpact de ce paramtre sur les seuils de latence :

Figure 99 Impact du paramtre free_child_process_memory

Lamlioration issue de ce paramtre est de 90 %. Ce paramtre est trs intressant pour augmenter la performance dun serveur Nagios. Son impact est relativement

266

Options avances de Nagios DEUXIME PARTIE

limit le temps que le systme prend bien en charge les processus qui oublient de librer leur mmoire.
REMARQUE Un systme adquat
Le nettoyage de lespace mmoire des fils tant laiss au systme, celui-ci doit pouvoir grer la situation correctement. Sur la plupart des systmes actuels, cela ne pose aucun problme et le risque est vraiment limit.

Suppression de la double duplication

Lorsque Nagios lance une sonde de vrification, il effectue une double duplication de processus. Ceci permet de rendre indpendants, du point de vue du systme, le processus nagios et celui quil a lanc. Si ce dernier adopte un comportement anormal, Nagios nen sera pas impact. Dans le cas de sondes en lesquelles les administrateurs ont pleinement confiance, cette prcaution est inutile. La double duplication est trs lourde grer par le systme. Elle reprsente presque un doublement de la charge systme. Nous avons dj signal que celle-ci reprsente une part trs importante de la charge globale. Son amlioration profitera lensemble de la solution. Par exemple, si nous regardons les appels systme mis par le processus nagios, nous remarquons quil passe une grande majorit de son temps lancer de nouveaux processus. Ceci est reprsent par lappel clone.
Suivi des appels systme de Nagios
strace -c -p NAGIOSPID %time seconds usecs/call calls syscall 82.82 2.541715 2311 1100 clone

Le lancement de processus consomme plus de 80 % du temps systme de Nagios. Rduire ces appels a un fort impact sur les performances, et ce dans le bon sens. Le paramtre ddi cela est child_processes_fork_twice. De base, il vaut 1. Pour supprimer la double duplication, il faut le positionner 0.
Duplication unique pour les fils
child_processes_fork_twice=0

La figure suivante prsente les courbes des seuils de supervision avec et sans suppression de la double duplication.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

267

Figure 910 Impact du paramtre child_processes_fork_twice

Cette amlioration est la plus efficace des trois. Elle est de 190 %. Si les administrateurs ont confiance dans la robustesse de leurs sondes, cette technique peut tre utilise facilement et avec des effets rapides.
REMARQUE Un systme adquat
La encore, le systme doit grer la situation par lui-mme. Dans ce cas, il doit reprer les processus zombies de Nagios et les supprimer. Les systmes actuels nont, pour la plupart, aucun problme le faire.

Utilisation conjointe des trois techniques

Si nous utilisons conjointement les trois techniques prcdentes, notre gain est important. Mme sil nest pas gal la somme des trois gains individuels, il reste tout de mme intressant. Il est ncessaire de rappeler que, si nous gagnons en performances, nous devons nanmoins grer tous les problmes inhrents ces astuces. Il est conseill de les tester une par une et de ne les utiliser conjointement que si aucun problme nest apparu dans les tests. Le paramtre use_large_installation_tweaks permet dactiver les trois paramtres prcdents.

268

Options avances de Nagios DEUXIME PARTIE

Utilisation des trois tweaks la fois

use_large_installation_tweaks=1

La figure suivante prsente les courbes de seuils de latence avec et sans ce paramtre.

Figure 911 volution de la latence avec use_large_installation_tweaks

Lamlioration est de lordre de 225%. Si ce gain est impressionnant, le risque quil reprsente est loin dtre nul. Ce paramtre est utiliser avec la plus grande prcaution.

Positionnement des fichiers intermdiaires

Nagios fonctionne avec beaucoup de petits fichiers temporaires. Regardons si cela pnalise les performances et, si oui, comment les amliorer.

Systmes de fichiers en mmoire

Les critures sur les disques durs sont lentes, bien plus que les accs mmoire. Les disques ont toutefois lintrt de conserver les informations mme en cas de coupure dalimentation. Ils sont gnralement dune trs grande taille face la mmoire. Si les informations temporaires sont de taille importante, les administrateurs ont lhabitude dutiliser lespace /tmp mont sur un disque dur pour les y entreposer. Au redmarrage de la machine, cet espace est bien souvent vid.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

269

Un autre type despace temporaire existe. Son nom est tmpfs et cest un systme de fichiers accessible comme nimporte quel autre. Sa spcificit est de loger les informations en mmoire. Sans accs physique sur les disques, la vitesse de lecture / criture est trs rapide. Les fichiers consomment simplement leur taille en espace mmoire. Un tel espace existe en standard sur les systmes Linux. Il est mont dans / dev/shm. Seul lespace rellement consomm est pris en mmoire, lexcdent est disponible pour le reste du systme. Voici un exemple dun tel espace :
Exemple despace en mmoire
df -h /dev/shm/ Filesystem tmpfs

Size Used Avail Use% Mounted on 1013M 0 1013M 0% /dev/shm

Les fichiers crits dans cet espace sont perdus si la machine est redmarre. Ne doivent y tre placs que des fichiers temporaires de taille rduite et ayant une dure de vie trs faible. Il est prfrable de privilgier les fichiers ayant besoin de fortes performances en lecture / criture.

Fichier status.dat
Une source de ralentissement du serveur Nagios est la gnration rgulire du fichier status.dat. Utilis par linterface CGI de Nagios, il est gnr rgulirement par Nagios. Sa localisation est gre par le paramtre temp_file. Le fichier est ensuite copi sous status_file. Cette opration en deux tapes vite que les utilisateurs de status_file aient lire un fichier non fini. Cette gnration intervient toutes les status_update_interval secondes. Par dfaut, le fichier est enregistr sous /usr/ local/nagios/var/status.dat toutes les 10 secondes. Si ladministrateur a configur un nombre lev dhtes et de services, le fichier peut tre trs imposant. Par exemple, pour une configuration importante de 30000 services, le fichier peut atteindre 120 Mo. Ceci reprsente 12 Mo par seconde dcriture sur le disque, ce qui est important. Une solution consiste diminuer lintervalle de gnration du fichier. Ceci implique cependant un dlai plus long entre larrive de linformation dans Nagios et son apparition sur la console. Une autre solution existe. Le constat est simple : ce fichier a une dure de vie trs limite et nest pas important en cas de redmarrage du serveur. Pour amliorer la situation, sans avoir diminuer sa priode de gnration, nous pouvons gnrer le fichier dans un espace en mmoire.

270

Options avances de Nagios DEUXIME PARTIE

Si nous configurons temp_filecomme /dev/shm/nagios.tmp et comme /dev/shm/status.dat, nous obtenons :

tat de lespace mmoire aprs lopration
df -h Filesystem none

status_file

Size Used Avail Use% Mounted on 1014M 123M 890M 13% /dev/shm

Et le fichier :
tat du fichier status.dat
l-rw-r--r-- 1 nagios 123M Jan 2 15:28 /dev/shm/status.dat

Rpertoire checkresults
Le rpertoire var/spool/checkresults est galement ligible cet espace. Il recueille les rsultats des tests de vrification. Il est rgulirement vid par le processus nagios matre pour obtenir les informations. Ces fichiers font en moyenne 400 octets. Il y en a autant que de tests lancs par priode de check_result_reaper_frequency, soit en gnral 5 secondes. Ceci peut reprsenter rapidement 1 Mo de fichiers mis jour trs rapidement. Ces fichiers ne sont pas importants en cas de redmarrage de serveur. Ce chemin peut donc faire appel lespace en mmoire. Il est paramtr avec check_result_path. Lui affecter la valeur /dev/shm permet de crer ces fichiers en espace mmoire plutt que sur un disque physique.

Impact des fichiers temporaires en mmoire

Lutilisation de /dev/shm pour les fichiers des tats et des rsultats de vrifications a un impact, certes lger, sur les performances de Nagios. Sur le serveur considr avec les options de performances, dcrites ci-dessus, la limite de vrifications 5 minutes tait de 31000 tests. Avec lutilisation de /dev/shm, une consommation supplmentaire de 124 Mo de RAM est noter. La limite des tests atteint 32000 vrifications. Le gain est de 3 % pour un risque nul.
PERFORMANCE Des disques rapides
Si limpact sur la supervision nest pas extraordinaire, celui de la mtrologie lest beaucoup plus. Si le volume des fichiers de rsultats nest pas important, leur nombre implique beaucoup daccs disque. Comme nous le verrons au chapitre 14, les accs disque ont un impact lev sur la charge globale dune machine. La mtrologie aura plus de disponibilit sur les ressources disques et en fonctionnera dautant mieux.

Pousser Nagios dans ses derniers retranchements CHAPITRE 9

271

Consommation de RAM de Nagios

Faisons un rapide point sur lutilisation mmoire de Nagios. Les facteurs de consommation mmoire dans Nagios sont les lments superviser et ce qui les entoure. Les services et les nuds sont les deux grands consommateurs. Lutilisation de la RAM est proportionnelle au nombre dlments superviss. Voici une courbe prsentant la consommation de RAM en fonction du nombre de services (avec un ratio de 10 services par hte) :

Figure 912 volution de la consommation mmoire en fonction du nombre de services

La plupart des installations nayant pas plus de 10 000 services, lutilisation mmoire sera infrieure 20 Mo. Ici, seule la consommation du processus matre est trace. Les processus fils font la mme taille avant de lancer les commandes qui, elles, ne consomment presque rien en matire de mmoire. Considrons le cas o nous lanons 10 000 services en 5 minutes et quun test prend en moyenne 1 seconde sexcuter ( cause des temps rseau sur un systme fortement rparti, par exemple). Nous avons en moyenne 33 processus en parallle. Fort heureusement, pour les administrateurs, ceci ne reprsente pas 33 fois la taille mmoire du processus nagios, mme si cest ce que nous indique la commande top lorsque nous dressons la liste les processus. Les noyaux Unix permettent de faire du copy-on-write de la mmoire lors de la duplication des processus. Ainsi, seules les pages mmoire qui diffrent du processus matre

272

Options avances de Nagios DEUXIME PARTIE

sont rellement alloues. Les processus fils ne modifiant presque pas leur mmoire avant de lancer les commandes, leur consommation relle est quasi nulle. La consommation du processus matre est la seule susceptible dintresser ladministrateur. La consommation des sondes ne profite pas de ce systme. Les sondes font appel des bibliothques, qui sont partages entre les processus. On peut considrer quune sonde classique consomme entre 500 Ko et 1 Mo en mmoire. Suivant le nombre de sonde lances en parallle, la consommation mmoire est plus importante que celle de Nagios lui-mme. Dans le cas des 33 processus simultans, la consommation globale ne dpasse pas les 35 Mo dans la majorit des environnements. La ressource mmoire nest pas le plus grand problme dun systme bas sur Nagios. Ceci est dautant plus intressant que, dans larchitecture que nous allons monter par la suite, nous utiliserons une base de donnes pour grer les donnes de Nagios. Ce genre de programme est trs gourmand en mmoire. La mmoire non consomme par Nagios lui sera alloue.

Architectures distribues
Si, malgr toutes ces options, la latence est trop leve, il faut augmenter les capacits du serveur Nagios au plan physique. Lajout de processeurs peut avoir un effet bnfique. Une seconde solution consiste augmenter le nombre de serveurs et les faire travailler de concert pour superviser lensemble des htes et services. Cette solution est tudie au chapitre suivant.

En un mot
Une question revient souvent lors des tudes sur Nagios : quel serveur faut-il pour superviser X lments. Dans ce chapitre, nous avons prsent un ordre de grandeur. Si ce dernier nest pas suffisant, des mthodes permettent damliorer sensiblement les performances de Nagios. Elles ne sont pas toutes utilisables dans nimporte quelle situation. Que ce soit par des paramtres ou des astuces systme, les administrateurs ont le choix.

10
Haute-disponibilit et rpartition de charge
Comme tout programme, Nagios a des limites, que ce soit en termes de disponibilit ou de performance. Ce chapitre traite des solutions architecturales visant rgler ces problmes.

Haute-disponibilit
Un outil de supervision doit surveiller tous les autres. Il se doit dtre le plus rsistant possible. Si la simplicit de Nagios lui permet dtre particulirement robuste, il nest pas totalement infaillible. De plus, dpendant dun serveur et dun systme dexploitation, il subit leurs alas. Sil est possible de mettre en place deux Nagios identiques sur deux serveurs, il ne faut pas que les administrateurs soient doublement alerts des problmes. Nous allons tudier deux mthodes permettant de configurer Nagios en mode haute-disponibilit et grant le problme des notifications trop nombreuses.

Un Nagios dans lombre dun autre : la voie active/active

Commenons par la forme la plus simple darchitecture haute-disponibilit de Nagios, la forme active/active.

274

Options avances de Nagios DEUXIME PARTIE

Deux Nagios actifs la fois

Ce que les administrateurs attendent de Nagios est quil les avertisse en cas de problme. Si un Nagios principal nest plus en mesure de les avertir, peu leur importe de recevoir les alertes dun second, tant quils les reoivent bien. Ce second Nagios fonctionne en parallle du premier. Il surveille les mmes lments mais ne lve les notifications que si le premier Nagios nest plus disponible. Le second Nagios dsactive ses notifications dans sa configuration standard. Sil saperoit que le Nagios principal est tomb, il les ractive (voir figure 10-1).
Figure 101

Un Nagios dans lombre

Le Nagios principal na pas connaissance du second. Ce dernier surveille lhte du primaire ainsi que le processus nagios qui fonctionne dessus. Si lun des deux nest plus disponible, il excute une commande de rsolution qui active ses propres notifications. Pour cela, le script quil appelle lance la commande externe ENABLE_NOTIFICATIONS. Le script qui lance cette commande est habituellement /usr/local/nagios/libexec/ eventhandlers/enable_notifications (voir figure 10-2).
Figure 102

Activation des notifications

Haute-disponibilit et rpartition de charge CHAPITRE 10

275

Si le Nagios principal revient, il dsactive les notifications du Nagios secondaire. Pour cela, la commande DISABLE_NOTIFICATIONS est utilise. Le script lanant cette commande est le suivant :
/usr/local/nagios/libexec/eventhandlers/disable_notifications.

Superviser un Nagios
La supervision du processus nagios distant se fait grce la sonde check_nagios. Cette dernire vrifie que le fichier dtat de Nagios nest pas plus vieux quune limite autorise. Pour rappel, ce fichier est gnr toutes les status_update_interval secondes. Par dfaut, cet intervalle est de 15 secondes. Elle vrifie galement que le processus Nagios est toujours lanc. Si lune des deux conditions nest pas remplie, elle retourne une erreur. La sonde prend comme arguments : -F : le chemin vers le fichier status.dat ; -e : le nombre de minutes pour lge maximum du fichier de rtention ; -C : le chemin vers le binaire Nagios. On lance par exemple la commande suivante :
Commande de vrification dun Nagios
check_nagios -e 1 -F /usr/local/nagios/var/status.dat -C /usr/local/ nagios/bin/nagios

Nous obtenons, sur un Nagios en bon tat :

Rsultat OK pour la vrification
NAGIOS OK: 5 processes, status log updated 7 seconds ago

Raction face la perte du Nagios matre

Voici un script nomm handle-master-nagios-event utilis dans le cas dun changement dtat qui arrive sur le Nagios matre :
handle-master-nagios-event
#!/bin/sh case "$2" in HARD) case "$1" in

276

Options avances de Nagios DEUXIME PARTIE

CRITICAL) /usr/local/nagios/libexec/eventhandlers/enable_notifications ;; WARNING) UNKNOWN) ;; OK) /usr/local/nagios/libexec/eventhandlers/disable_notifications ;; esac ;; esac exit 0

Sa dfinition est situe dans le fichier commands.cfg :

Dfinition de handle-master-nagios-event
define command{ command_name handle-master-nagios-event command_line /usr/local/nagios/libexec/eventhandlers/handle-masternagios-event $SERVICESTATE$ $SERVICESTATETYPE$ (proc -> nagios) }

Le script est appel si besoin par le service du nud secondaire qui supervise le Nagios matre. Voici un exemple de dfinition du service :
Appel de handle-master-nagios-event
define service{ host_name srv-principal service_description NagiosPrincipal max_check_attempts 1 event_handler handle-master-nagios-event check_command check_nagios_principal [...] }

Le Nagios secondaire a la configuration suivante :

Configuration du Nagios secondaire
enable_notifications=0 check_external_commands=1

Haute-disponibilit et rpartition de charge CHAPITRE 10

277

Limiter la priode de brouillard

Cette mthode peut poser un problme. Le Nagios secondaire peut ne sapercevoir de la chute du premier quau bout de quelques minutes. Pendant ce laps de temps, les administrateurs ne sont pas avertis des problmes sur les autres environnements. Pour diminuer cette priode, il faut planifier frquemment la vrification de lhte et du service de Nagios. La gestion de la configuration nest pas trs complexe. Chaque nagios.cfg est spcifique, mais chacun inclut des fichiers communs aux deux Nagios. Ces derniers contiennent la configuration des nuds, des services et des contacts qui doivent tre partags. Le second Nagios inclut, en plus, un fichier contenant la configuration prsente ci-dessus, pour surveiller le premier.
PIGE Garder un il sur le second Nagios
Il est important de surveiller que le second Nagios est toujours en tat de fonctionnement. Il serait dangereux de penser avoir une solution de secours en cas de souci avec le Nagios matre et quelle soit en fait indisponible depuis plus dun mois. Le premier Nagios devrait avoir un service pour surveiller le second. Les administrateurs seraient alors avertis du manque de systme de secours. Il nest pas utile dautomatiser la relance du Nagios secondaire dans cette situation.

Synchroniser les deux Nagios

Les mmes plug-ins Avoir deux Nagios peut tre complexe pour conserver la synchronisation entre les deux. Leurs sondes doivent tre les mmes. Toute modification dun ct doit tre reporte de lautre. Un bon moyen de sassurer de cela est de mettre en place un script qui envoie tous les plug-ins du Nagios primaire vers le secondaire. Nous pouvons utiliser pour cela le protocole SSH. La cration dun couple de cls publique et prive permet de ne pas avoir sauthentifier chaque connexion. Par exemple :
Script de synchronisation des sondes
#!/bin/sh LIBEXEC=/usr/local/nagios/libexec scp $LIBEXEC/* nagios@serveur-secondaire:$LIBEXEC

Ce script peut, par exemple, tre ordonnanc par cron tout les quarts dheure afin de garder les sondes au mme niveau.

278

Options avances de Nagios DEUXIME PARTIE

La mme configuration La configuration des services et des nuds doit galement tre gre. Il nest pas possible de transfrer automatiquement tous les fichiers du rpertoire /usr/local/ nagios/etc. Une partie de la configuration des deux nuds est diffrente. Par exemple, tout ce qui est en rapport avec handle-master-nagios-event sur le nud secondaire nest pas prsent sur le nud matre. La configuration du nud matre sur le Nagios secondaire doit tre place dans un fichier part. Le reste de la configuration des htes, services, commandes et contacts doit tre plac dans les mmes fichiers (hosts.cfg, services.cfg, commands.cfg et contacts.cfg). Le script suivant peut tre utilis conjointement au prcdent :
Script de synchronisation de la configuration
#!/bin/sh ETC=/usr/local/nagios/etc PID=/usr/local/nagios/var/nagios.pid cd $ETC #on copie la configuration scp hosts.cfg services.cfg commands.cfg contacts.cfg nagios@secondaire:$ETC #on redmarre nagios ssh nagios@secondaire "kill -HUP `cat $PID`"

Un Nagios dormant de secours : la mthode active/passive

tudions une autre architecture haute-disponibilit plus efficace que la prcdente.

Un seul Nagios actif la fois

La mthode prcdente permet de continuer la supervision, mme en ayant un Nagios terre. Elle a cependant un inconvnient majeur : elle multiplie par deux la charge de supervision. Le Nagios de secours supervise tous les lments. Il ne fait rien de ces informations. Une autre mthode est de mettre en place une architecture active/passive. Le second Nagios attend que le premier ne soit plus disponible pour lancer sa supervision. Cette architecture illustre en figure 10-3. Il est possible de mettre en place un tel systme grce au programme HeartBeat. Celuici permet de lancer un service, ici Nagios, en cas de problme sur le nud matre. Cette solution a un problme : le Nagios de secours dmarre sans disposer des tats prcdents. Cela peut lempcher deffectuer une supervision efficace rapidement.

Haute-disponibilit et rpartition de charge CHAPITRE 10

279

Figure 103

Un Nagios dormant

Problme des tats prcdents

Le fichier de rtention des tats, retention.dat, peut tre utile. Pour que le Nagios de sauvegarde ait accs ce fichier, nous pouvons le placer sur un systme de fichiers partag. On peut pour cela utiliser GFS, ou plus simplement un montage NFS.
PIGE Le NFS devient un SPOF
En cas de mise en place du fichier retention.dat sur NFS, il faut bien faire attention ce que ce dernier ne devienne pas un SPOF (Single Point Of Failure). Des mthodes existent pour configurer NFS lui-mme en haute-disponibilit. Lidal est de demander une baie NAS ddie de le grer.

Si une telle mise en place est trop complexe, il est possible dutiliser un systme bas sur un Nagios semi-dormant. Il ne lance pas les vrifications, mais attend que le Nagios primaire lui envoie passivement les tats. Lorsquil dcide de lancer ses vrifications, il dispose de toutes les informations dont il a besoin pour tre efficace rapidement. Le Nagios primaire les lui fournit par le biais de NSCA. On ne peut pas utiliser cette fin les commandes de rsolution de problmes. Le second Nagios a en effet besoin de tous les tats. Or, ces commandes ne sont lances quen cas de changement dtat. Nagios propose les commandes OCSP et OCHP qui, si elles sont dfinies dans le fichier de configuration nagios.cfg, sont appeles aprs chaque vrification. Elles servent lancer des commandes qui relaient les informations des services et des nuds dautres Nagios. Elles sont dfinies comme suit sur le matre :
Configuration des commandes OCSP/OCHP
obsess_over_services=1 ocsp_command=submit_service_check_result obsess_over_hosts=1 ochp_command=submit_host_check_result

280

Options avances de Nagios DEUXIME PARTIE

La commande submit_service_check_result est dfinie dans le fichier commands.cfg de la manire suivante :

Dfinition de submit_service_check_result
define command{ command_name submit_service_check_result command_line /usr/local/nagios/libexec/eventhandlers/ submit_service_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$' }

Le script submit_service_check_result est, quant lui, de la forme suivante :

submit_service_check_result
#!/bin/sh return_code=-1 case "$3" in OK) return_code=0 ;; WARNING) return_code=1 ;; CRITICAL) return_code=2 ;; UNKNOWN) return_code=-1 ;; esac /bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | /usr/ local/nagios/bin/send_nsca -H server-secondaire -c /usr/local/nagios/ etc/send_nsca.cfg

Il galement mettre en place ce type de script pour les htes et la commande submit_host_check_result. Lances aprs chaque vrification de service ou dhte, ces commandes permettent denvoyer passivement les tats un autre Nagios. Ce dernier obtient sans effort les informations du matre (figure 10-4).
PERFORMANCE Un impact non ngligeable
Le fait denvoyer tous les tats un Nagios secondaire a un impact fort sur les performances. Chaque lancement dune sonde implique le lancement de la commande OCSP ou OCHP correspondante.

Haute-disponibilit et rpartition de charge CHAPITRE 10

281

Figure 104

Envoi des tats

Relais par le Nagios secondaire

Le Nagios secondaire est configur pour ne pas vrifier activement les services et des htes. Il doit accepter les commandes passives, le matre lui envoyant ses tats passivement. Il ne renvoie pas de notification. Les paramtres suivants sont dfinis dans le fichier nagios.cfg du Nagios passif :
Configuration du Nagios passif
execute_service_checks=0 execute_host_checks=0 enable_notifications=0 check_external_commands=1

Ne pouvant pas lancer de vrifications actives, il ne peut pas superviser lui-mme le premier Nagios. Pour cela, nous utilisons un ordonnanceur externe de type cron. Dans le cas dun Nagios primaire qui ne rpond pas, il doit donner la main au secondaire pour la supervision. Pour cela, il lance les commandes START_EXECUTING_SVC_CHECKS, START_EXECUTING_HOST_CHECKS et ENABLE_NOTIFICATIONS. Elles permettent de ractiver les tests actifs et les notifications. Lorsque le premier Nagios est de nouveau disponible, le Nagios secondaire doit laisser la main. Pour cela, le script lanc par cron doit lancer les commandes DISABLE_NOTIFICATIONS, STOP_EXECUTING_SVC_CHECKS et STOP_EXECUTING_HOST_CHECKS. Sans vrification et sans notification, il redevient le Nagios de secours semi passif. Un tel script, nomm check_nagios_primaire.sh, est de la forme suivante :
check_nagios_primaire.sh
#!/bin/sh LIBEXEC=/usr/local/nagios/libexec

282

Options avances de Nagios DEUXIME PARTIE

EVENT=$LIBEXEC/eventhandlers/ $LIBEXEC/check_nrpe -H srv-primaire -c check_nagios $RET=$? if [ "$RET" = "0" ] then $EVENT/disable_active_service_checks $EVENT/disable_active_host_checks $EVENT/disable_notifications else $EVENT/enable_active_service_checks $EVENT/enable_active_host_checks $EVENT/enable_notifications fi

Il est lanc toutes les minutes par un utilisateur ayant les autorisations sur le fichier nagios.cmd, typiquement nagios (voir figure 10-5).
Figure 105

Le Nagios passif se rveille

Il se peut quil y ait une priode de recouvrement entre le redmarrage du matre et sa dtection par le passif. Si le script de vrification est lanc toutes les minutes, cette priode est au maximum dune minute galement. Cest tout fait acceptable quant aux notifications qui peuvent tre envoyes pendant ce court laps de temps.

parpillement des donnes de mtrologie

Il ne faut pas oublier les donnes de mtrologie dans cette architecture. Elles sont gnres sur le nud qui est actif. Suivant la solution choisie pour grer ces donnes, ladministrateur doit penser les renvoyer sur le nud matre une fois la situation redevenue normale et intgrer les donnes au jeu de donnes principal.

Haute-disponibilit et rpartition de charge CHAPITRE 10

283

Rpliquer NSCA
Les alertes passives doivent galement tre gres par le systme de secours. NSCA est dj lanc, mais les clients ne sadressent pas lui. Un moyen pour pallier cela consiste mettre en place une adresse virtuelle sur les deux nuds grs par HeartBeat. Une telle mise en place sera dcrite plus loin dans ce chapitre.

Rpartition de charge : chaque Nagios sa tche

Voyons prsent les architectures de rpartitions de charge.

Centraliser les informations, pas la charge

La puissance des systmes nest pas infinie. Chaque installation de Nagios a une limite de taille. Si une configuration soigneuse permet de la repousser, elle existe toujours. Nous pouvons considrer que, lheure actuelle, un serveur de milieu de gamme peut grer, avec une configuration de Nagios adapte, entre 15 000 et 20 000 services. Cela ne prend en compte que la charge de Nagios. Si nous comptons en plus les services web et la mtrologie, nous arrivons environ 10 000 services. Avec une moyenne dune dizaine de services par hte, cela reprsente 1 000 nuds. Si les besoins des administrateurs sont moindres, le problme ne se pose pas. Dans le cas contraire, il faut mettre en place plusieurs serveurs Nagios qui vont surveiller chacun une sous partie du systme dinformation, tout en gardant sur la mme console lensemble des informations.

Une architecture distribue avec les commandes externes

Nous allons reprendre les techniques vues dans la partie haute-disponibilit pour mettre en place une architecture distribue. Plusieurs Nagios fonctionnent de concert. Lun dentre eux est le Nagios principal, les autres des relais de supervision. Ils surveillent une partie des htes, puis envoient le rsultat au principal. Ce dernier ne sert qu lancer les notifications et grer la console. Nayant pas lancer les vrifications, sa charge est fortement rduite. Cette architecture est illustre en figure 10-6. En cas de problme de charge sur un des relais, il suffit de scinder ce quil supervise et den ajouter un nouveau. Les relais ne disposent que de la configuration des nuds et des services dont ils soccupent. Les notifications devant tre leves par le primaire, leur envoi dalertes est dsactiv. Ils nont pas besoin non plus de la console de supervision et de son serveur web.

284

Options avances de Nagios DEUXIME PARTIE

Figure 106 Supervision distribue par commandes externes

Pour chaque information recueillie par les relais, ils avertissent le primaire par le biais des commandes OCSP et OCHP. La configuration des Nagios distants est la suivante :
Configuration des Nagios distants
obsess_over_services=1 ocsp_command=submit_service_check_result obsess_over_hosts=1 ochp_command=submit_host_check_result enable_notifications=0

Les commandes submit_service_check_result et submit_host_check_result sont celles qui ont t dfinies prcdemment. Elles doivent simplement envoyer les informations vers le Nagios central. La configuration des htes et des services est, quant elle, classique. Les serveurs Nagios distants ne devant pas envoyer dalerte, la partie notification nest pas ncessaire. Le serveur central reoit les tats des nuds et des services de manire exclusivement passive. Il doit accepter les commandes externes et il est charg de lever les notifications. Nous obtenons la configuration suivante :
Configuration du serveur central
execute_service_checks=0 execute_host_checks=0 enable_notifications=1 check_external_commands=1

Haute-disponibilit et rpartition de charge CHAPITRE 10

285

Il doit avoir dans sa configuration lensemble des htes et des services dfinis sur les serveurs distants. Il naccepte passivement les tats que des lments dont il connat lexistence. Il faut, dans ce genre de situation, se prmunir des pertes des Nagios distants. Il faut, pour cela, vrifier la fracheur des informations reues. Sur le Nagios primaire, nous vrifions que nous avons bien des tats mis jour rgulirement. Du point de vue du Nagios central, nous sommes dans la situation de services purement passifs. Comme nous lavons dj fait au chapitre 7, la dfinition de la commande de la vrification active renvoie une alerte. Voici une telle dfinition :
Vrification de la fracheur des donnes
define service{ passive_checks_enabled 1 check_freshness 1 freshness_threshold 600 check_command check_dummy!2!Information prime. [...] }

Ici, la limite est place 10 minutes. Suivant la planification du service sur le serveur distant, il peut tre bon de laugmenter ou de la diminuer. Un changement dordonnancement sur un relais doit tre rpercut sur la valeur de fracheur, sous peine de voir lever des alertes inutiles. Le problme de la perte dun Nagios distant plane toujours. Dans le cas dune simple perte rseau entre les Nagios, des informations sont irrmdiablement perdues. La gestion de la configuration est particulirement complexe. Chaque service est configur au moins deux fois : 1 sur le serveur distant, pour la supervision active ; 2 sur le serveur central, pour la vrification de la fracheur et les notifications. Cette solution est trop lourde grer.

Simplification de la rpartition avec NDO

Nouveaut de Nagios passe sous silence jusquici, NDO simplifie la rpartition de charge.

NDOMOD : un nouveau type de module

Le systme de relais Event Broker est un systme de plug-ins internes pour Nagios. Cela signifie quil est inclus dans le processus Nagios, et non appel par lui. Sa principale utilisation consiste exporter des informations internes de Nagios vers lextrieur.

286

Options avances de Nagios DEUXIME PARTIE

REMARQUE Fonctionnement des modules Nagios

Les capacits des modules sont en fait un peu plus tendues que la simple extraction dinformation. Ils peuvent prendre le pas sur certaines fonctions internes de Nagios comme celle qui effectue les vrifications. Un exemple sera prsent un peu plus loin dans ce chapitre avec la prsentation du module DNX.
NDOMOD est un module tirant parti de ce systme. Il envoie les informations travers un fichier ou un socket, qui peut tre tre local ou rseau.

Les administrateurs peuvent faire ce quils souhaitent des informations recueillies. Ils peuvent par exemple les mettre dans une base de donnes. Lexcutable soccupant de cela se nomme ndo2db. La figure 10-7 illustre cette communication.

Figure 107 Communication ndomod/ndo2db

Le module Ndomod : exporter les donnes

Ndomod se compose dun fichier ndomod.o (binaire ELF) situ dans /usr/local/ nagios/bin et dun fichier de configuration nomm ndomod.cfg. Ce dernier est situ dans /usr/local/nagios/etc. Le fichier ndomod.o est charg comme module par le programme Nagios. Le fichier de configuration possde les proprits importantes suivantes : instance_name : nom donn au Nagios dans lequel est charg ndomod. Par dfaut, le nom est default ; output_type : type de sortie. Valeur disponible dans la liste suivante : file : dans un fichier plat, tcpsocket : sur le rseau, unixsocket : dans un fichier de type socket Unix, local au serveur ; output : destination de la sortie. Varie suivant la valeur de output_type : file : chemin vers le fichier plat gnr, tcpsocket : IP vers laquelle sont envoyes les informations, unixsocket : chemin du fichier de socket Unix ; tcp_port : port TCP utilis dans le cas dune sortie sur le rseau, par dfaut 5668 ;

Haute-disponibilit et rpartition de charge CHAPITRE 10

287

buffer_file : fichier tampon utilis lorsque ndomod ne peut pas transmettre ses

informations, par dfaut le fichier est /usr/local/nagios/var/ndomod.tmp ; output_buffer_items : nombre de places dans le fichier tampon, par dfaut 5000 lments ; reconnect_interval : temps entre deux tentatives de reconnexion lorsque la connexion sur le rseau est perdue ; data_processing_options : champ servant spcifier les informations exportes. Il sera tudi plus en dtail dans un second temps. La mthode conseille pour la connexion entre ndomod et ndo2db est la connexion rseau. Mme sils sont situs sur le mme serveur, ce type de connexion est le plus fiable. Le module ndomod doit tre charg par Nagios. Pour cela, il faut ajouter ce qui suit dans le fichier nagios.cfg :
Appel au module ndomod dans nagios.cfg
broker_module=/usr/local/nagios/bin/ndomod.o config_file=/usr/local/ nagios/etc/ndomod.cfg event_broker_options=-1

Choix des donns exportes Le paramtre data_processing_options sert spcifier les donns exporter. Si la valeur est -1, Nagios envoie toutes les donnes. Dans le cas contraire, il va utilise les bits de la numrotation binaire pour slectionner les informations. Celles-ci sont en effet indexes sur des puissances de 2. Les informations disponibles ne sont pas pleinement documentes. Il faut, lheure actuelle, aller regarder le code de ndomod afin de voir ces valeurs. Le fichier considrer est include/ndomod.h. Comme que ce nest pas trs pratique, les puissances de deux des lments sont retranscrits dans le tableau 10-1.
Tableau 101 Donnes exportes par NdoMod

Nom de la donne PROCESS TIMED_EVENT LOG SYSTEM_COMMAND EVENT_HANDLER NOTIFICATION SERVICE_CHECK

Index de puissance de 2 0 1 2 3 4 5 6

Nom de la donne HOST_CHECK COMMENT DOWNTIME FLAPPING PROGRAM_STATUS HOST_STATUS SERVICE_STATUS

Index de puissance de 2 7 8 9 10 11 12 13

288

Options avances de Nagios DEUXIME PARTIE

Tableau 101 Donnes exportes par NdoMod (suite)

Nom de la donne ADAPTIVE_PROGRAM ADAPTIVE_HOST ADAPTIVE_SERVICE EXTERNAL_COMMAND OBJECT_CONFIG MAIN_CONFIG

Index de puissance de 2 14 15 16 17 18 19

Nom de la donne AGGREGATED_STATUS RETENTION ACKNOWLEDGEMENT STATECHANGE CONTACT_STATUS ADAPTIVE_CONTACT

Index de puissance de 2 20 21 22 23 24 25

Certaines informations font doublon avec les fichiers plats. Par exemple, les donnes de journalisation et les informations de rtention sont disponibles galement en base. Il est probable que, lavenir, Nagios propose plusieurs mthodes pour obtenir ces informations : les fichiers plats ou la base de donnes. Il est dconseill de supprimer une donne inconnue. Il peut tre intressant, cependant, de supprimer les donnes inintressantes, consommatrices de bande passante et despace disque. Les donnes les plus volumineuses sont SERVICE_CHECK, HOST_CHECK et SYSTEM_COMMAND. Elles concernent les commandes lances par Nagios et leur rsultat. Ces informations ntant pas, lheure actuelle, utilises, nous pouvons les enlever sans souci. En ajoutant les valeurs de toutes les donnes, on obtient :

Si nous souhaitons enlever des donnes, nous calculons alors :

Pour enlever les donnes obtenons :

SERVICE_CHECK, HOST_CHECK

et

SYSTEM_COMMAND,

nous

Nous utilisons cette valeur pour le paramtre nes inutiles ne sont pas envoyes ndo2db.
PIGE Garder les valeurs utiles

data_processing_options.

Les don-

Ici, nous avons enlev les valeurs service_check, host_check et system_command car nous savons quelles ne sont pas utilises par les outils que nous allons mettre en place par la suite. Il faut faire trs attention aux donnes que lon supprime. Si lon nest pas certain quune donne est inutile, mieux vaut la garder.

Haute-disponibilit et rpartition de charge CHAPITRE 10

289

Charge gnre par lexport des donnes La charge de calcul du module ndomod est minime. Le trafic gnr est variable suivant le nombre dlments superviss. Lordre de grandeur est de 5ko/s pour 1 000 services superviss toutes les 5 minutes. Cette consommation de bande passante est raisonnable.

Ndo2db : recevoir les donnes et les placer dans une base

Ndo2db est, quant lui, un dmon qui se prsente sous la forme dun excutable situ dans /usr/local/nagios/bin et dun fichier de configuration ndo2db.cfg situ dans /usr/local/nagios/etc. Configuration Les options intressantes de ce fichier sont les suivantes : ndo2db_user : compte utilis pour faire tourner ndo2db ; ndo2db_group : groupe de lutilisateur prcdent ; socket_type : type de socket que ndo2db coute. Les valeurs possibles sont : unix : coute un fichier socket unix, tcp : coute un port TCP ; socket_name : uniquement utilis pour un socket de type unix, cest le chemin du fichier ; tcp_port : port cout si le socket est de type TCP, par dfaut 5668 ; db_servertype : type de base de donnes dans laquelle on place les donnes. Les valeurs possibles sont : mysql : MySQL, pgsql : PostgreSQL ; db_host : IP du serveur de base de donnes ; db_port : port de connexion la base ; db_name : nom de la base de donnes ; db_prefix : prfixe utilis devant les tables de la base ; db_user : compte utilisateur de la base de donnes ; db_pass : mot de passe de lutilisateur de la base de donnes. Dautres tapes dinstallation de ndo2db sont ncessaires, principalement en ce qui concerne la cration de la base de donnes.

290

Options avances de Nagios DEUXIME PARTIE

Dmarrage Le programme se lance de la manire suivante :

Lancement de Ndo2db
/usr/local/nagios/bin/ndo2db -c /usr/local/nagios/etc/ndo2db.cfg

Le module ndomod se lance, quant lui, avec Nagios. Lorsque nous le dmarrons, nous obtenons dans le fichier nagios.log les entres suivantes :
Entres dans nagios.log pour le chargement de ndomod
[1230409791] ndomod: NDOMOD 1.4b7 (10-31-2007) Copyright (c) 2005-2007 Ethan Galstad (nagios@nagios.org) [1230409791] ndomod: Successfully connected to data sink. 0 queued items to flush. [1230409791] Event broker module '/usr/local/nagios/bin/ndomod.o' initialized successfully.

Lors de son chargement, le module demande un nettoyage des anciennes entres dans la base. Cette tape peut prendre quelques secondes.
PRATIQUE Rduire le temps de lancement
Pour rduire le temps de dmarrage, on peut demander ndo2db de conserver les informations moins longtemps. De cette manire, le nettoyage est plus rapide. Les paramtres max_timeevents_age, max_systemcommands_age, max_hostchecks_age et max_eventhandlers_age, exprims en minutes, sont utiliss dans ce but.

Il envoie ensuite les lments sauvegards dans buffer_file pour les envoyer en base. Dans lexemple ci-dessus, il ny en avait pas en attente. Le module en stocke au maximum output_buffer_items. Il enregistre dans le tampon les lments de supervision lorsquil narrive pas se connecter ndo2db. Il tente de se reconnecter toutes les reconnect_interval secondes.Sil arrive se reconnecter, il vide son fichier tampon. Par exemple, lors de la perte de connexion, nous observons ce qui suit dans nagios.log :
Perte de connexion entre ndomod et ndo2db
[1230412336] ndomod: Error writing to data sink! Some output may get lost... [1230412352] ndomod: Still unable to reconnect to data sink. 0 items lost, 669 queued items to flush.

Haute-disponibilit et rpartition de charge CHAPITRE 10

291

Puis, une fois que la connexion est rtablie :

[1230412384] ndomod: Successfully reconnected to data sink! 0 items lost, 1863 queued items to flush. [1230412386] ndomod: Successfully flushed 1863 queued items to data sink.

Une fois en base, les informations ne demandent qu tre lues pour obtenir les tats de supervision. Pour linstant, la console standard de Nagios ne sait pas lire ces informations, mais nous verrons comment Centreon permet de les utiliser pleinement.
PERFORMANCE Faire attention aux performances de la base de donnes
Le module ndo2db ne consomme pas beaucoup de ressources. Il ne fait que transmettre les informations une base de donnes. Celle-ci peut cependant tre fortement sollicite suivant le nombre de services et de nuds dfinis. Pour lallger, il faut slectionner au mieux les donnes exportes.

Architecture de supervision distribue avec NDOUtils

Centralisation des donnes par NDO Le module NDOMOD est utile dans la mise en place dune solution de supervision distribue. Contrairement la solution prcdente, les serveurs Nagios sont tous au mme niveau. Il ny a pas de Nagios matre. La base de donnes est utilise uniquement pour la console de supervision. Les Nagios ont la responsabilit complte de leur primtre de supervision et de lenvoi des notifications. Leur configuration est complte. Ils remontent les informations par le biais de modules ndomod situs sur chaque Nagios. Ils permettent de se passer des commandes de type submit_service_check_result. Les lments sont ajouts automatiquement dans la base de donnes. Chaque module NDO doit avoir une valeur instance_name diffrente afin de diffrencier ses rsultats. Les informations sont envoyes vers un dmon ndo2db qui enregistre les informations dans une base. Dans la plupart des situations, ce service se situe sur le serveur de supervision qui a le plus de ressources. Ce nest en rien une obligation. Il peut tre install sur un serveur totalement indpendant.
DFAUT Des connexions non chiffres
lheure de rdaction de ce livre, le lien entre ndomod et ndo2db nest pas encore chiffr. Votre serviteur a propos un correctif sur NDOUtils permettant de mettre en place un chiffrement SSL. Ce correctif najoute pas de surcot notable au fonctionnement de loutil. Il est encore en validation chez le dveloppeur de Nagios.

292

Options avances de Nagios DEUXIME PARTIE

Cette architecture peut tre observe en figure 10-8.

Figure 108 Supervision distribue avec NDOUtils

Configuration La configuration des services et des nuds est rpartie sur les Nagios et ce, sans duplication. La charge de ladministrateur Nagios est allge par rapport la solution prcdente, mais reste contraignante. La gestion des configurations sur des serveurs qui peuvent se trouver trs loigns peut savrer dlicate. Les donnes de performances sont situes sur chaque serveur. Il faut que ladministrateur gre le rapatriement des donnes pour les intgrer dans loutil de mtrologie.
PRATIQUE Une gestion simplifie grce Centreon
Nous verrons dans un prochain chapitre Centreon qui permet de faciliter cette gestion. Ladministrateur pourra grer toute sa configuration depuis une seule console. Centreon permet galement dautomatiser la gestion des donnes de mtrologie.

Impact limit des pertes de lien Les pertes de connexion nont plus le mme impact. Les Nagios ayant la pleine responsabilit de leur supervision, les pertes de connexions sont gres comme pour tout Nagios. La console nest pas en reste. Les informations tant transmises par ndomod, en cas de perte de connexion avec ndo2db, un tampon est disponible pour renvoyer automatiquement les informations par la suite. Il ny a pas de perte de donnes.

Haute-disponibilit et rpartition de charge CHAPITRE 10

293

Il est tout de mme important dtre averti de ces pertes de connexion. On peut, pour cela, exploiter check_nagios, mais nous pouvons mettre en place une autre solution utilisant la base NDO. Les Nagios y enregistrent rgulirement des donnes. La table programstatus contenant les informations issues de PROGRAM_STATUS est ici utile. Nous pouvons y voir la dernire mise jour dtat pour chaque instance de Nagios. Si nous recherchons linformation pour le premier Nagios, nous effectuons la requte suivante :
Requte dans la base NDO sur ltat dune instance
SELECT status_update_time FROM nagios_programstatus WHERE instance_id=1;

Nous obtenons le rsultat suivant :

status_update_time=2008-12-28 15:52:03

Il suffit de faire la diffrence avec lheure actuelle pour voir si les informations sont trop vieilles au got des administrateurs. Pour obtenir le numro attribu chaque instance, il suffit de lancer la requte suivante :
Identification des instances
SELECT instance_id,instance_name FROM nagios_instances;

Nous obtenons, ici pour une base remplie par deux instances :
instance_id=1, instance_name=default instance_id=2, instance_name=distant

En seulement deux requtes, il est simple de savoir si les serveurs distants sont encore fonctionnels. La sonde check_ndo est justement faite pour cela. Son rle est de surveiller ces enregistrements en base et dalerter si les informations sont trop ges. Elle prend en paramtres : H : ladresse du serveur de base de donnes ; -d : le nom de la base de donnes NDO ; -u : un utilisateur de la base ; -p : le mot de passe de lutilisateur ; -t : le temps en secondes de non-mise jour accept ; -i : le nom de linstance Nagios qui est vrifie.

294

Options avances de Nagios DEUXIME PARTIE

Voici un exemple de ce que donne son lancement sur une base jour :
Vrification de ltat dune instance en base
check_ndo.pl -H srv-base -d ndo -u ndouser -p pass -t 60 -i default

Nous obtenons :
Instance en tat OK
Instance "default" is running and database was updated during the last 60 seconds. OK

Sur une base qui na pas t mise jour depuis plus dune minute par linstance default, nous obtenons :
Instance qui ne met plus jour la base
default was not updated during the last 60 seconds. echo $? 2

PRATIQUE Un ordonnancement frquent

La charge de cette sonde est trs limite. Son intrt tant lui trs grand, il est conseill de la planifier trs frquemment.

Rpartition de charge par Worker (DNX)

Devant la complexit de la mise en uvre de plusieurs Nagios distribus, un groupe de dveloppeurs a dcid de proposer une mthode plus souple pour rpartir la charge.

Une nouvelle utilisation de levent broker

Des vrifications dtournes Pour cela, ils utilisent levent broker. Ce dernier, en plus dexporter des informations, permet des modules de prendre la main sur des fonctions exportes. Ce module, nomm
NEBCALLBACK_SERVICE_CHECK_DATA.

(Distributed Nagios eXecutor), utilise la fonction exporte Cette dernire permet un module de prendre en charge les vrifications actives. Lorsquune vrification doit tre lance, le module demande Nagios de faire la vrification et lui retourne linformation de bon drouDNX

Haute-disponibilit et rpartition de charge CHAPITRE 10

295

lement du lancement. Ce dernier est, en fait, effectu par un client distant. Ce fonctionnement est illustr en figure 10-9.

Figure 109 Dtournement des vrifications par DNX

Le module DNX charg dans Nagios, galement appel DnxServer, ouvre deux ports de communication : le port Dispatcher, UDP/12480, sert aux clients pour rcuprer les commandes lancer ; le port Collector, UDP/12481, sert aux clients pour retourner les rsultats des commandes.
SCURIT Des ports ouvrir
En cas dutilisation conjointe de DNX et dun pare-feu, il ne faut pas oublier douvrir ces ports en entre sur le serveur Nagios.

Des clients externes ralisant les vrifications Les clients, nomms DnxClients, sont des programmes fonctionnant sous Linux. Ils utilisent un compte non privilgi, idalement nomm nagios. Ils sont chargs de se connecter sur le port Dispatcher du serveur, et de rcuprer les commandes lancer. Les sondes doivent tre places sur les serveurs des clients. Ils utilisent intelligemment un pool de threads pour leurs vrifications. Ce systme est plus lger que la duplication de processus de Nagios. Une fois la sonde lance, le rsultat est retourn au port Collector. Ce rsultat, une fois rcupr par le module serveur, est export dans le rpertoire des rsultats de Nagios, comme pour nimporte quelle vrification. Nagios le parcourant rgulirement, il rcupre et traite les donnes normalement. Ce fonctionnement est illustr en figure 10-10.

296

Options avances de Nagios DEUXIME PARTIE

Figure 1010 Communication au sein de DNX

Avantages Cette mthode est trs souple. Le serveur ne fait que proposer des commandes lancer. Il ne prend pas linitiative de contacter les clients. Lajout dun client est transparent pour le serveur. La perte dun client nest pas critique. Les vrifications dont il avait la charge sont perdues. Nagios ne rcuprant pas de rsultat, il rordonnance le test. Le client tant perdu, il ne rcupre pas de nouveaux tests. Ceux-ci sont la charge des autres clients.
DNX

est spar en deux parties : le module serveur ; les clients.

Module serveur
Configuration Une fois install, la prise en compte du module serveur par Nagios est simple. Il suffit, comme pour NDO, dutiliser le paramtre broker_module dans le fichier nagios.cfg :
Appel au module dnxServer dans nagios.cfg
broker_module=/usr/local/nagios/lib/dnxServer.so

REMARQUE Plusieurs modules dans Nagios

Levent broker de Nagios autorise le chargement de plusieurs modules. Il suffit de mettre plusieurs dclarations broker_module. Le module DNX nentre pas en conflit avec NDO.

Haute-disponibilit et rpartition de charge CHAPITRE 10

297

dnxServer.cfg.

La configuration du module est situe dans le fichier /usr/local/nagios/etc/ Les paramtres principaux sont : channelDispatcher : adresses et ports ouvrir pour la communication Dispatcher ; channelCollector : adresses et ports ouvrir pour la communication Collector ; authWorkerNodes : listes des adresses autorises se connecter au serveur ; localCheckPattern : expression rgulire permettant de reprer les services ne devant pas tre exports sur les clients, mais traits localement sur le serveur Nagios ; syncScript : commande permettant de synchroniser les sondes entre les clients ; logFile : fichier de journalisation du module serveur, par dfaut /usr/local/ nagios/var/log/dnxsrv.log.

Dmarrage Une fois configur, il suffit de lancer Nagios pour charger le module :
Entre dans nagios.log du chargement du module dnxServer
[1233820400] Event broker module '/usr/local/nagios/lib/dnxServer.so' initialized successfully.

La lecture du fichier de journalisation de bien t lanc :

DnxServer

permet de vrifier que tout a

Lancement de dnxServer dans /usr/local/nagios/var/log/dnxsrv.log

[Thu Feb 5 15:13:25 ------[Thu Feb 5 15:13:31 DNX job list. [Thu Feb 5 15:13:31 [Thu Feb 5 15:13:31 [Thu Feb 5 15:13:31 requests... [Thu Feb 5 15:13:31 2009] -------- DNX Server Module Startup Complete 2009] Allocating 25000 service request slots in the 2009] Registered for SERVICE_CHECK_DATA event. 2009] Server initialization completed. 2009] DNX Registrar: Awaiting worker node 2009] Dispatcher awaiting jobs...

Clients DNX
Configuration Une fois le serveur lanc, il est temps de soccuper des clients. Lorsquils sont installs, leur configuration est situe dans le fichier /usr/local/nagios/etc/ dnxClient.cfg. Les paramtres importants sont les suivants :

298

Options avances de Nagios DEUXIME PARTIE

channelAgent : adresse sur laquelle le client coute les demandes de ladministra

teur sur ses performances ; channelDispatcher : adresse du serveur auprs duquel le client doit aller rcuprer les tests de vrification ; channelCollector : adresse du serveur auquel le client doit renvoyer les rsultats ; poolInitial : nombre de threads allous au lancement pour traiter les demandes ; poolMin : nombre de threads minimum que le client doit conserver ; poolMax : nombre de threads maximum qui peuvent tre lancs ; poolGrow : unit dallocation des threads ; threadMaxRetries : temps dinactivit dun thread avant quil ne se ferme ; pluginPath : chemin vers les sondes ; logFile : fichier de journalisation du client ; User : utilisateur sous lequel fonctionne le client.

Dmarrage Une fois configur, on lance le client en appelant la commande suivante :

Lancement du client DNX
/usr/local/nagios/sbin/dnxClient -c /usr/local/nagios/etc/dnxClient.cfg

Le fichier de journalisation permet de valider le lancement :

Entre du lancement du client DNX dans /usr/local/nagios/var/log/dnxcld.log
[Thu Feb 5 15:57:12 2009] Startup -------[Thu Feb 5 15:57:12 2009] All rights reserved. [Thu Feb 5 15:57:12 2009] dnxClient.cfg. [Thu Feb 5 15:57:12 2009] [Thu Feb 5 15:57:12 2009] [Thu Feb 5 15:57:12 2009] [Thu Feb 5 15:57:12 2009] [Thu Feb 5 15:57:12 2009] [Thu Feb 5 15:57:12 2009] -------- DNX Client Daemon Version 0.18 Copyright (c) 2006-2008 Intellectual Reserve. Configuration file: /usr/local/nagios/etc/ Agent: udp://0:12480. Dispatcher: udp://172.16.49.83:12480. Collector: udp://172.16.49.83:12481. WLM: Increased thread pool by 20. WLM: Started worker thread pool. DNX Client Agent awaiting commands...

Haute-disponibilit et rpartition de charge CHAPITRE 10

299

On peut vrifier que les commandes sont bien lances en observant les processus de lutilisateur nagios :
Vrification du lancement des commandes
ps -fu nagios nagios /usr/local/nagios/sbin/dnxClient -c /usr/local/nagios/etc/ dnxClient.cfg nagios |----->/usr/bin/perl /usr/local/nagios/libexec/check_bonding.pl

Avantages et inconvnients
Les avantages de DNX sont nombreux. Cette solution permet daugmenter facilement la rpartition de la charge sur plusieurs nuds. Lajout ou la suppression dun client naffecte pas, ou peu, le serveur. Cependant, ladministrateur na aucun contrle sur le client qui effectue la vrification. Si des commandes doivent tre lances dun nud particulier, elles doivent ltre depuis le serveur de supervision. Cette limite peut tre rdhibitoire dans certains cas. La gestion de la rpartition de la charge entre les clients nest pas vidente, mme avec les paramtres de nombres de threads maximum. Il est conseill davoir des machines identiques pour traiter les demandes. Les performances de chaque client sont trangement infrieures celle dun Nagios configur pour des performances maximum. Les options de configuration vues dans le chapitre prcdent ne sont plus applicables. Ladministrateur risque davoir besoin de plus de machines en utilisant DNX que dans le cas de serveurs Nagios utilisant NDO et dont les paramtres sont affins.
PERFORMANCE Des problmes contre-balancs avec NRPE
Dans le cas o les vrifications se basent majoritairement sur check_nrpe, DNX ayant une librairie intgre, il peut tre plus performant que Nagios.

La disponibilit du processus Nagios est galement un problme. Les agents ne sont pas critiques, mais le dmon qui ordonnance les vrifications lest. Il est malheureusement seul dans larchitecture actuelle.

Utilisation de DNX et NDO

Les architectures bases sur besoins.
DNX

et

NDO

ne rpondent pas exactement aux mmes

300

Options avances de Nagios DEUXIME PARTIE

DNX

est utilis dans le cas o une instance de Nagios ne peut pas supporter la charge qui lui est demande. Laugmentation du nombre de clients DNX permet de rpartir cette charge sur plusieurs serveurs.

NDO, quant lui, rajoute de nouvelles instances de Nagios. Elles peuvent travailler ensemble dans un objectif commun en se partageant un pan du systme dadministration. Elle sont utilises pour dcouper la supervision en units logiques indpendantes.

Les notifications sont envoyes depuis chaque Nagios distribu. Le dcoupage de NDO peut reflter celui de lorganisation de lentreprise : sil existe plusieurs datacenters, chacun a sa propre quipe dadministration. Il est utile davoir une vision densemble des problmes. NDO peut rpondre ce besoin particulier. Les administrateurs de chaque instance sont indpendants les uns des autres. Ils peuvent configurer leur Nagios comme bon leur semble sans risquer dinterfrer avec les autres administrateurs. Si une instance est coupe du reste de la socit, elle continue de surveiller son pan du systme. Les administrateurs ne sont pas sans supervision pendant ce temps.
DNX, quant lui, ne propose quune rpartition des tests. Cette rpartition nest pas contrlable par les administrateurs. Les notifications sont envoyes depuis un unique Nagios. Si un site est coup du reste du monde, le client DNX na plus aucun intrt puisquil ne peut pas interroger le serveur Nagios central. Il ne peut pas envoyer de notification. Les administrateurs se retrouvent dmunis.

Ces deux systmes ne sont pas exclusifs. NDO permet de dcouper de grands pans indpendants du systmes dinformation tout en ayant une vue globale des problmes et DNX permet chaque instance de rpartir sa charge sur autant de clients quelle le dsire. La figure 10-11 illustre cette architecture.

Figure 1011 Architecture utilisant NDO et DNX de concert

Haute-disponibilit et rpartition de charge CHAPITRE 10

301

Rpartition de charge haute-disponibilit

Nous avons vu les environnements haute-disponibilit et ceux rpartition de charge. Essayons dsormais davoir le meilleur des deux mondes.

Le besoin accru de disponibilit

Pour grer la redondance des Nagios, la mthode active/passive est conseille. Elle permet de diminuer la charge globale de la supervision. Elle pose tout de mme le problme de la duplication de la configuration. La rpartition de charge par NDO est fiable et pratique. Elle permet de grer simplement les pertes de liaison entre les superviseurs et le serveur de base de donnes. La configuration est distribue et il ny a pas de notion de nud matre. Avoir un environnement distribu augmente les chances de perdre un service Nagios. Il est important de mettre en place une solution pour grer la perte dun nud. Nous allons utiliser pour cela un Nagios passif pour chaque Nagios distribu. La figure 1012 illustre cette architecture.
Figure 1012

Une supervision distribue haute-disponibilit

chaque Nagios son ombre

Nous reprenons la configuration active/passive pour chaque serveur Nagios distribu. Elle se compose dun matre et dun autre serveur passif. Ce dernier ne lance ses vrifications que si un script lui en donne lordre. Leur configuration est identique en ce qui concerne les nuds, les services et les contacts quils doivent grer. Pour disposer dun tat cohrent quand il prend la main, le nud secondaire doit recevoir ses tats du primaire. Pour cela, nous utilisons les commandes OCSP et OCHP. Cette solution fonctionne sans soucis dans le cadre dun Nagios seul. Dans une architecture distribue, il contient en plus le module ndomod. Ce dernier envoie les informations de supervision vers ndo2db. Deux envois ont lieu, un par Nagios.

302

Options avances de Nagios DEUXIME PARTIE

Si les deux serveurs ont un nom dinstance NDO diffrent, chaque tat est dupliqu dans la base de donnes. Cette situation tant viter, le nom est identique. Lorsque le second Nagios envoie ses donnes, elles sont simplement mises jour et non dupliques. Seul un doublement de la charge sur ndo2db et la base de donnes est perceptible. Il ny a malheureusement, lheure actuelle, pas de moyen de communiquer via commandes externes avec ndomod. Il faut utiliser un moyen dtourn pour limiter les connexions non souhaites provenant du systme de secours. Pour rappel, le script check_nagios_primaire.sh vrifie rgulirement que lactif est toujours vivant. Il dmarre les vrifications actives sur le systme de secours si besoin. Nous pouvons lui ajouter une commande supprimant les liaisons entre ndomod et ndo2db quand le service est passif. Lorsquil passe en mode actif, le script est charg dautoriser la communication.
check_nagios_primaire.sh
#!/bin/sh LIBEXEC=/usr/local/nagios/libexec EVENT=$LIBEXEC/eventhandlers/ $LIBEXEC/check_nrpe -H srv-primaire -c check_nagios $RET=$? if [ "$RET" = "0" ] then $EVENT/disable_active_service_checks $EVENT/disable_active_host_checks $EVENT/disable_notifications $EVENT/drop_ndo_connexions else $EVENT/enable_active_service_checks $EVENT/enable_active_host_checks $EVENT/enable_notifications $EVENT/enable_ndo_connexions fi

Les scripts drop_ndo_connexions et enable_ndo_connexions crent simplement une rgle de pare-feu pour autoriser ou non les communications vers le port de ndo2db. Le script suivant vrifie que la rgle NetFilter est active. Si elle ne lest pas, il la cre.
CONFIGURATION Droits sudo
Pour ce script, lutilisateur nagios a besoin de lancer une commande en tant que root. Pour cela, il utilise la commande sudo. La rgle rajouter au fichier /etc/sudoers est nagios
ALL=NOPASSWD:/sbin/iptables *

Haute-disponibilit et rpartition de charge CHAPITRE 10

303

drop_ndo_connexions
#!/bin/sh sudo /sbin/iptables -L | grep "ndo-server tcp dpt:5668" RET=$? if [ "$RET" = "0" ] then sudo /sbin/iptables -I OUTPUT -d ndo-server -p tcp --dport 5668 -j DROP fi

Le script suivant fait exactement linverse : si la rgle est active, il la supprime.

enable_ndo_connexions
#!/bin/sh sudo /sbin/iptables -L | grep "ndo-server tcp dpt:5668" RET=$? if [ "$RET" = "1" ] then sudo /sbin/iptables -D OUTPUT -d ndo-server -p tcp --dport 5668 -j DROP fi

La figure 10-13 illustre le fonctionnement de ce script.

Figure 1013

Suppression des connexions parasites

Haute-disponibilit pour NDO2DB

Une partie de la prcdente architecture possde un point unique pouvant faire seffondrer ldifice. Voyons comment pallier cette vulnrabilit.

Un service important doubler

Chaque Nagios tant second par un autre, ils sont considrs comme haute-disponibilit. Si lun deux tombe, un autre prend le relais et envoie sa place les informations NDO2DB. Dans les diagrammes que nous avons vus jusqu maintenant, ce dernier tait seul. Il est pourtant important pour les consoles de supervision.

304

Options avances de Nagios DEUXIME PARTIE

Les notifications sont toujours envoyes, mais les administrateurs ne peuvent pas obtenir plus dinformations par la console de supervision. Cette dernire se doit dtre galement configure en haute-disponibilit.. Lutilisation du logiciel HeartBeat de Linux est ici justifie. Pour faciliter la gestion des modules ndomod, ndo2db est mis en place sur une IP virtuelle. ndo2db et lIP virtuelle basculent au besoin sur le systme de secours. Ce mcanisme est observable sur le diagramme suivant :
Figure 1014

Haute-disponibilit de NDO2DB

Le programme HeartBeat de chaque nud surveille ltat de lautre nud. Un membre et un seul la fois est nomm matre des ressources : ladresse virtuelle et le processus ndo2db. Sil nest plus disponible, le systme de secours acquiert toutes les ressources. Si le nud matre revient, il reprend la main.

Mise en place de HeartBeat

Pour mettre en place cette architecture, nous avons besoin, par exemple sur systme Red Hat, des paquets heartbeat, heartbeat-stonith et heartbeat-pils. Nous supposons ici que le nud matre se nomme srv-clust1 et le nud de secours srvclust2. Ils ont comme adresses, respectivement, 192.168.0.1 et 192.168.0.2. Ladresse virtuelle est 192.168.0.3 et se nomme ndo-server. Linstallation se fait en lanant sur les deux nuds :
Installation de HeartBeat
rpm -Uvh heartbeat-2.0.7-1.c4.i386.rpm heartbeat-stonith-2.0.71.c4.i386.rpm heartbeat-pils-2.0.7-1.c4.i386.rpm

Haute-disponibilit et rpartition de charge CHAPITRE 10

305 de

Nous ditons ensuite le fichier de configuration du cluster, srv-clust1 :

/etc/ha.d/ha.cf sur srv-clust1
ucast debugfile logfile logfacility keepalive deadtime warntime initdead udpport node node eth0 192.168.0.2 /var/log/ha-debug /var/log/ha-log local0 2 10 6 60 694 srv-clust1.domain.com srv-clust2.domain.com

/etc/ha.d/ha.cf,

auto_failback on

CONFIGURATION Nom des nuds

Les noms placer dans les paramtres node sont ceux que lon obtient en lanant la commande uname
-n sur les serveurs.

Le fichier /etc/ha.d/ha.cf ne diffre sur srv-clust2 que de la premire ligne :

/etc/ha.d/ha.cf sur srv-clust2
ucast eth0 192.168.0.1

La configuration demande au programme HeartBeat de vrifier lautre membre toutes les 2 secondes. Au bout de 10 secondes sans rponse, il est dclar mort. Le fichier /etc/ha.d/haresources sert dcrire les ressources du cluster. Il est identique sur les deux membres et se compose dune seule ligne indiquant le nom du matre et les ressources proprement parler :
/etc/ha.d/haresources
srv-clust1.domain.com Ipaddr::192.168.0.3 ndo2db

306

Options avances de Nagios DEUXIME PARTIE

Ipaddr

resource.d.

et ndo2db sont des scripts dinitialisation placs dans le rpertoire /etc/ha.d/ Ils permettent respectivement de monter une adresse virtuelle et de lancer ndo2db. Le premier est fourni par le paquet HeartBeat. Le second, /etc/ ha.d/resource.d/ndo2db, est reproduit ici :

/etc/ha.d/resource.d/ndo2db
#!/bin/sh # Start/stop the ndo2db daemon. Ndo2dbBin=/usr/local/nagios/bin/ndo2db Ndo2dbCfg=/usr/local/nagios/etc/ndo2db.cfg case "$1" in start) echo -n "Starting ndo2db" $Ndo2dbBin -c $Ndo2dbCfg ;; stop) echo -n "Stopping ndo2db" killall $Ndo2dbBin ;; esac exit 0

Le fichier /etc/ha.d/authkeys sert dfinir le message qui permet de vrifier le bon tat de lautre membre. Il est identique pour les deux membres et a les droits root/600 :
/etc/ha.d/authkeys
auth 2 1 md5 "Vive ndo2db" 2 crc

Une fois les services HeartBeat lancs, les membres se mettent daccord sur celui qui possde les ressources. Ici srv-clust1 prend la main, car il est nomm matre des ressources dans haresources.
CONFIGURATION Le lien de HeartBeat
Ici, pour des raisons de facilit, le lien LAN primaire est utilis pour la communication entre les serveurs
HeartBeat. Une situation plus robuste consiste utiliser entre les serveurs un lien ddi qui ne subit

pas les alas du rseau principal.

Haute-disponibilit et rpartition de charge CHAPITRE 10

307

Adresse virtuelle pour NSCA

Dans le cadre de la mise en place des Nagios actif/passif, les nuds passifs doivent pouvoir prendre en charge la supervision passive. Pour cela, un Heartbeat mis en place avec une adresse virtuelle suffit. Cest cette dernire qui est configure pour les clients send_nsca. Lorsque le membre matre nest plus actif, ladresse virtuelle passe sur le nud de secours et les alertes sont toujours traites.

Supervision de HeartBeat
HeartBeat

est trs pratique pour mettre en place un cluster facilement. Il est important de le superviser afin de pouvoir remonter lhistorique des problmes rencontrs. Un moyen simple de vrifier si le nud sur lequel nous nous situons est le nud actif consiste lancer un ifconfig. Si nous voyons ladresse virtuelle, cest bien le cas.

Affichage de linterface virtuelle

eth0:0 inet addr:192.168.0.3

La commande cl_status permet dobtenir les informations souhaites sur ltat du cluster. Elle est appele par la sonde ddie la supervision de HeartBeat. Elle se nomme check_heartbeat_link et vrifie que le programme est bien lanc sur le nud actuel et que lautre membre rpond bien galement. Par exemple, lanc sur srv-clust1 :
srv-clust1 voit bien srv-clust2
Heartbeat Link OK: srv-clust2.domain.com:eth0:up

Si srv-clust2 nest plus disponible

Heartbeat Link CRITICAL: srv-clust2.domain.com:eth0:dead

En un mot
Nagios nest pas infaillible. Ses performances sont leves, mais pas illimites. Nagios propose des solutions architecturales permettant davoir une solution haute-disponibilit, distribue, ou les deux la fois. Chaque architecture a ses avantages et ses inconvnients. Suivant la rpartition du systme dinformation, les solutions bases sur DNX ou NDO peuvent permettre de grer autant dhtes que le souhaitent les administrateurs. Les mthodes de haute disponibilit peuvent profiter des facilits offertes par le programme HeartBeat sous Unix.

TROISIME PARTIE

cosystme de Nagios et mise en place de la solution

Cette dernire partie prsente les programmes associs Nagios dans la construction de la solution globale, ainsi que leur installation et leur configuration. Tous les outils tudis prcdemment sont mis contribution pour que le lecteur ait entre les mains une solution complte et fonctionnelle base sur Nagios. Le chapitre 11 prsente les outils de configuration et tout particulirement le plus complet dentre eux : Centreon. Nous verrons quil fait bien plus que gnrer la configuration de Nagios. Le chapitre 12 prsente les problmatiques que pose lutilisation des information issues de Nagios. Nous abordons la visualisation agrge des alertes sur des crans de supervision ainsi que le reporting des alertes. Le chapitre 13 se concentre sur linstallation et la configuration technique des programmes. Diffrentes techniques de mise en place sont voques. Nous y traitons la mise en place par les sources afin que ladministrateur ait une connaissance approfondie de ses outils. Aprs ce chapitre, le lecteur peut tre tent de partir tte baisse dans la configuration des vrifications. Avant cela, il est ncessaire de faire un point sur les indicateurs importants de la supervision des systmes et des quipements rseau. Cest lobjet du chapitre 14. Ces indicateurs sont indpendants du fonctionnement de Nagios mais nous tudions galement les commandes classiques de Nagios et les bonnes pratiques qui les entourent.

310

Nagios 3

Le chapitre 15 prsente un systme dinformation type et explicite la configuration des lments superviss, non sans avoir rappel les points importants qui dterminent la russite du projet de supervision.

11
Outils daide la configuration : lexemple de Centreon
La configuration de Nagios peut tre longue et fastidieuse. Heureusement, il est possible de puiser dans un cosystme applicatif trs vaste pour trouver dexcellents outils daide la configuration, parmi lesquels figure en premire place Centreon.

Intrt de tels outils

tudions les avantages que les administrateurs peuvent retirer doutils daide la configuration.

Une configuration longue et fastidieuse

Le nombre de fichiers de configuration est assez important et il est courant de sy perdre un peu. Les ajouts se faisant la main, il est courant de commettre des erreurs de recopie. Automatiser la configuration est donc utile et et peut faire gagner un temps considrable, quon passera plutt tester de nouvelles mthodes de dtection de problmes ou bien en perfectionner danciennes.

312

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

BONNE PRATIQUE Efficacit

Auprs de certains publics, annoncer que lon est capable de configurer Nagios de A Z en ligne de commande peut faire son effet. Toutefois, en rgle gnrale, cest surtout signe quon aime perdre son temps. La configuration de Nagios est longue. Lancer vi pour ajouter un nouveau serveur na rien de sympathique...

De nombreux programmes gravitent dans lcosystme doutils libres de Nagios. Les sondes en sont la partie la plus visible, mais dautres programmes sont galement disponibles. Parmi ceux-ci, les outils de gestion de configuration ont une place toute particulire. Ces outils sont le plus souvent bass sur une interface web. Les administrateurs y font appel pour administrer leur solution depuis nimporte quel endroit avec un simple navigateur. Leur convivialit permet de faire adopter la solution bien plus facilement que si les administrateurs doivent diter directement les fichiers de configuration. Ils pallient bon nombres de points faibles de Nagios. Ils sont indispensables la mise en place efficace dune solution de supervision base sur Nagios.

La gestion simultane des aspects de mtrologie

Ces outils ne se limitent pas la supervision. Laspect mtrologie est galement pris en compte. Ceci permet davoir sur la mme page les alertes et les variations des indicateurs. La partie web ne gre que laffichage des courbes. La partie intgration des donnes depuis Nagios est gre par un programme sexcutant en tche de fond sur le serveur de supervision. Celui-ci rcupre le fichier de performances de Nagios et en exporte les donnes. La destination peut tre une base de donnes relationnelle ou des fichiers RRD. Nagios possde nativement une interface web. Celle-ci est crite en CGI C. Ce langage nest pas le plus appropri pour la conception de sites web. Lvolutivit de cette interface est limite et la gestion des autorisations y est laborieuse. linverse, les nouveaux outils permettent de grer cet aspect trs facilement.

La solution Centreon
Parmi toutes les solutions existantes, celle de Centreon se dmarque particulirement. Il a volu au fil du temps pour assurer bien plus que la simple configuration de Nagios, comme nous allons le voir par la suite. Simposant comme loutil de rfrence pour btir une solution de supervision autour de Nagios, il est devenu indispensable pour la mise en place de Nagios dans de grands environnements. Centreon repose sur une base trs active dutilisateurs de tous horizons. Certains sont des membres de la premire heure de la communaut Nagios, dautres sont de tout rcents utilisateurs. Lentraide sur les forums est trs bonne. La documentation,

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

313

longtemps perue comme le point faible de loutil, volue rapidement grce la participation de tous les membres. Un wiki est disponible afin que tout le monde puisse apporter sa brique ldifice.
COMMUNAUT DOreon Centreon, une volution rapide
Le dveloppement de Centreon commence en 2003 sous le nom dOreon, sous licence GLP v2. Les dveloppeurs principaux de lapplication sont franais. La communaut dutilisateurs se dveloppe rapidement. Lorsquelle change de nom pour devenir Centreon, cette solution a atteint la maturit et reprsente un choix sr pour mettre en place un Nagios administrable, dautant plus quelle corrige au fur et mesure ses erreurs de jeunesse, et gagne en rapidit et agilit dans la manire de proposer les informations. B http://fr.doc.centreon.com/Docs:Centreon2/fr

Mise en garde : limites des outils de gestion de configuration

Si les outils de gestion de configuration sont importants, ils ne font pas tout. Faisons le point sur leurs limites.

Les outils ne font pas tout

La conception de la solution reste encore du ressort des administrateurs. Ils sont les seuls connatre la criticit de leurs environnements. Les seuls, encore, savoir de quelle manire ils prfrent tre avertis. Les outils font gagner du temps lors de la mise en place, mais la phase de conception nen est pas diminue. Elle reste prpondrante dans la russite du projet et ne doit sous aucun prtexte tre bcle. Le fait davoir un outil acclrant la mise en place de la solution ne corrige pas les erreurs darchitecture.
MTHODE Un apprentissage ncessaire
Le lecteur peut tre rassur, il na pas lu tous les chapitres prcdents pour rien. Avec ou sans outil de configuration, leur comprhension est toujours la cl dune mise en place russie.

Cet tat de fait est bien souvent oubli par les administrateurs. Cest pourtant la premire cause dchec de la mise en place dune solution de supervision. Si la modification dune sonde ou dun paramtrage est rapide, reprendre les processus de dcision concernant la supervision est bien plus contraignant. Si bien que, dans la majorit des cas, ils ne seront pas modifis ou amliors par la suite.

314

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Il ne faut pas oublier que, comme il sagit dune couche supplmentaire la solution, ces outils peuvent contenir des bugs. Leur conception tant relativement simple, peu de problmes sont survenus au fil du temps. Les soucis peuvent tre fcheux, mais ils sont vite corrigs.

Nagios avance vite

Les outils permettent de grer les options de configuration de Nagios, et celles-ci voluent rgulirement, tout comme Nagios. Les possibilits de gestion de configuration voluent trs vite. Une configuration juge invalide dans une version peut ne plus ltre par la suite.
Prenons, par exemple, lhritage implicite. Ce dernier permet dhriter dun nud certains champs pour les services. Cette possibilit est arrive avec la version 3 de Nagios. Les outils de gestion de configuration qui ne fonctionnaient quavec Nagios 2 considraient quune configuration reposant sur ce principe tait invalide. Ce qui tait vrai dans Nagios 2 ne ltait plus avec Nagios 3. Les administrateurs utilisant les outils de gestion de configuration ont d choisir entre conserver leur outil et exploiter cette nouvelle possibilit de Nagios.

Les diffrents lments tant lis, leur volution suit le mme rythme. Il nest pas toujours possible de profiter des toutes dernires nouveauts de Nagios sans attendre une mise jour de loutil de configuration. Parfois le fonctionnement des outils de gestion de configuration nest que partiel avec une nouvelle version majeure de Nagios. Dans ce cas, si les fonctionnalits perdues ne sont pas utilises par les administrateurs, rien nempche dexploiter loutil en ltat. Dans le cas contraire, les administrateurs peuvent soit attendre une nouvelle version, soit modifier directement les outils. Ces derniers tant Open Source, rien nempche les administrateurs de les adapter aux nouvelles fonctionnalits. Ils peuvent en faire profiter la communaut par la suite.

Des fonctionnalits utiliser avec parcimonie

Certaines possibilits offertes par les outils de gestion de configuration paraissent allchantes mais sont utiliser avec parcimonie. Dans la majorit des situations, elles permettent de combler un manque de Nagios ou damliorer son fonctionnement. Il ne faut pas oublier que ce sont des surcouches de Nagios. Suivant la manire dont se font ces amliorations, elles peuvent tre plus ou moins lies loutil. Dans le cas dun lien faible, changer doutil ne pose pas de problme. Avec un lien fort, une partie de la solution peut ne plus tre utilisable.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

315

La partie grant la configuration est tout particulirement concerne. Les outils gnrent les fichiers de configuration de Nagios, fichiers qui sont valides de son point de vue. Le problme qui peut se poser concerne leur maintenance sans loutil. Nous verrons que cest le cas avec Centreon. Le problme pourrait paratre bloquant, mais il ne faut pas oublier que ces outils sont libres. Rien nempche les administrateurs de rcuprer les donnes quils souhaitent ou bien dadapter les outils de nouvelles fonctionnalits. Dans le cas dun outil propritaire, le problme serait beaucoup plus inquitant.

Centreon, le meilleur ami de votre Nagios

Centreon est une rfrence parmi les outils de configuration de Nagios. Il est mme devenu bien plus que a. Nous verrons en dtail son installation et sa configuration aux chapitre 13 et 15.

Un outil incontournable
Dressons une liste des avances de Centreon qui lui ont permis de grer de plus en plus daspects de la solution de supervision.

Une volution constante

Centreon a gr les aspects de configuration et de visualisation ds ses premires versions. Laffichage des alertes par Centreon ressemblait alors beaucoup celui de linterface CGI de Nagios. Si Centreon a volu fortement depuis lors afin damliorer sans cesse son interface et de la rendre plus agrable, plus efficace pour les administrateurs, ce nest pas le cas de celle de Nagios.

Une nouvelle gestion de la mtrologie

Centreon a volu au fil du temps pour intgrer la gestion de la mtrologie. lpoque de sa premire version, seul le programme PerfParse tait disponible pour grer les donnes de mtrologie de Nagios. Cet outil tait trs performant car crit en C, mais il avait une interface crite dans le mme langage. Il posait un autre problme : il stockait tout dans une base de donnes relationnelle, sans agrger les informations au fil du temps. Les volumes traiter grandissaient trs rapidement, si bien quau bout dun moment, les interrogations pour gnrer des courbes pouvaient prendre plus dune vingtaine de minutes.

316

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Le projet a cess dvoluer en 2005. Centreon a alors propos une solution nomme ODS (qui sera renomme CentStorage par la suite) afin de grer au mieux la mtrologie sans retomber dans les travers de PerfParse.

Une gestion simple des alertes SNMP (traps)

Une autre volution de Centreon a consist prendre en charge dune manire simple les alertes SNMP. une poque, les administrateurs disposaient uniquement de la mthode prsente au chapitre 7 pour grer ces alertes. Cette mthode est lourde mettre en place. De plus, elle nest pas souple dans le sens o toutes les alertes arrivent sur un mme service. Ceci nest pas forcment souhaitable. Centreon apporte une solution simple et lgante la gestion de ces alertes puisquelle permet de charger simplement de nouvelles alertes. Elle offre galement la possibilit de slectionner les alertes reues et de navertir que les administrateurs concerns.

Des architectures distribues enfin simples

La dernire version majeure de Centreon prend en compte la mise en place darchitectures distribues. Comme nous lavons vu au chapitre prcdent, une telle mise en place peut se rvler complexe. Son administration au fil du temps est galement problmatique. De nouveaux problmes se posent, par exemple celui des donnes de mtrologie situes sur des serveurs distants. Centreon propose ici encore une solution simple. Les administrateurs peuvent grer un parc de superviseurs aussi facilement quun serveur unique. Sa prise en main est simple et il permet de mettre en place trs rapidement une solution Nagios. Cet aspect permet de convaincre des administrateurs rebuts par Nagios et sa myriade de fichiers de configuration. Les performances de Centreon ont galement bien volu depuis ses premires versions.
PERFORMANCE Explication des gains de performances
Ces gains ont t possibles grce aux amliorations de Nagios et tout particulirement larrive du module NDO.

Aspect configuration : le cur de Centreon

Le but premier de Centreon est daider la configuration de Nagios. Pour cela, il propose une application web crite en PHP, fournissant aux administrateurs des formulaires correspondant aux diffrentes parties de la configuration de Nagios. Le fichier principal et les lments de configuration sont grs.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

317

Une fois les paramtres fournis, les valeurs sont sauvegardes dans une base de donnes MySQL, fournie par Centreon. Cette partie est nomme CentWeb. Les pages de configuration sont claires et lon sy retrouve facilement. Des onglets permettent de regrouper les donnes par thmes. Par exemple, dans la configuration dun service, ladministrateur a le choix entre les onglets suivants : Service configuration : paramtres dfinissant quelle commande lancer et qui avertir en cas de souci ; Relations : paramtres dfinissant les nuds auxquels accrocher le service ; Data processing : paramtres concernant des options facultatives comme la vrification de la fracheur des services passifs ; Service Extended Info : donnes facultatives comme un lien vers la documentation ; Macros : onglet permettant de dfinir des macros pour ce service. Dans la majorit des cas, les administrateurs nutilisent que les deux premiers onglets. Ils peuvent dupliquer un lment pour en dfinir un autre. Cette fonctionnalit est toutefois utiliser petite dose. Une duplication dinformations est dangereuse sur le long terme. Il est prfrable dutiliser le plus possible les modles, afin de diminuer le nombre de pages modifier le jour o un paramtre commun doit tre chang. Les principes de configuration tudis au chapitre 8 sappliquent galement Centreon. Une fois la configuration complte, ladministrateur demande Centreon de gnrer les fichiers de configuration de Nagios. Avant dcrire la configuration finale, on peut gnrer et faire tester par Nagios une version dans un rpertoire temporaire. Si celleci est valide, la configuration de Nagios est crase et il lui est demand de la relire.

Figure 111 Gnration de la configuration de Nagios par Centreon

Ladministrateur na pas besoin de modifier directement les fichiers de configuration de Nagios. Ceux-ci sont regnrs chaque demande. Il na pas besoin de savoir parfaitement le nom des proprits des objets. Il est tout de mme fortement conseill de connatre la mthodologie de configuration de Nagios. Sans cela, la configuration na pas forcement le sens souhait par ladministrateur.

318

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Nous pouvons voir ci dessous une capture dcran de linterface de configuration dun hte dans Centreon.

Figure 112 Capture dcran de linterface de configuration dun hte dans Centreon

Les configurations passes ne sont pas oublies

Centreon possde un module permettant de charger une configuration Nagios existante en base de donnes. Il accepte les fichiers plats ou une archive. Cette fonctionnalit peut rajouter des valeurs ou craser des paramtres existants. Elle est particulirement pratique lorsquun administrateur ayant dj un Nagios en production souhaite mettre en place Centreon sans perdre toute sa configuration. Le chargement des fichiers de configuration doit cependant se faire dans un certain ordre. Centreon refusera de charger un objet qui fait rfrence un lment inconnu. Lordre de chargement est simple. Les relations de dpendance des objets doivent tre respectes. Pour rappel, les voici reprsentes la figure 11-3.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

319

Figure 113

Relations de dpendance entre les objets de Nagios

Le chargement doit tre effectu dans lordre suivant : 1 commandes de notification ; 2 commandes de vrification ; 3 priodes de temps ; 4 contacts et groupes de contacts ; 5 htes et groupes dhtes ; 6 services et groupes de services ; 7 escalades. Pour chaque tape, Centreon indique le nombre dlments quil a chargs. Ladministrateur vrifie ainsi que lensemble de sa configuration est bien charge. Une fois complte, il peut demander Centreon de regnrer la configuration et relancer Nagios.
CONFIGURATION Des commandes diffrentes
Centreon fait la diffrence entre les commandes de vrification et celles de notifications. Cette diffrence ntant pas prsente au niveau des fichiers de Nagios, limport doit se faire en deux tapes distinctes.

Des possibilits de configuration bien connues

Les lments configurables dans Centreon sont varis : les classiques htes, services, contacts, les groupes de ces diffrents lments, les priodes de temps et enfin les diffrentes commandes. Centreon prsente galement des possibilits de gestion de configuration de Nagios. Les modles dlments y sont aussi disponibles. Centreon propose une dition en masse des lments. Les modles sont toutefois prfrables ldition en masse.

320

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Ladministrateur peut choisir plusieurs modles, ils seront retranscrits dans lordre dans les fichiers de configuration. Les hritages multiples sont ainsi utilisables.

Dautres un peu plus particulires

Centreon propose galement une possibilit de configuration que Nagios noffre pas en standard. Il est possible daccrocher un modle de service un modle dhte. Ceci peut paratre inutile : aprs tout, ces modles ne sont pas crs rellement dans Nagios. Ce sont juste des facilits de configuration. Ce lien entre modles ne sera pas gnr dans les fichiers de configuration. Nagios ne reconnat pas ce type de liaison. Mais Centreon possde une option pour gnrer dans sa base de donnes les services accrochs un modle lorsque celui-ci est appliqu sur un nud. Tous les services accrochs au modle seront gnrs. Si un modle de service est modifi, tous les services qui ont t gnrs partir de lui sont mis jour. Ceci permet de gnrer sans crainte un grand nombre de services. Cette manire de procder est une approche totalement oppose celle dun Nagios traditionnel. Dans une configuration normale de Nagios, les services sont appliqus aux groupes dhtes. Les techniques dhritage permettent de grer la plupart des particularits des nuds. Un cas est cependant difficile grer : lorsque nous souhaitons modifier un service particulier appliqu un grand nombre de nuds. Si cette modification ne concerne que peu de nuds, une mthode base dhritage macros variables est envisageable. Elle ncessite une prise en charge, par la commande, dun argument variable suivant lhte. Le positionnement de cette variable sur les nuds est galement ncessaire. Ceci peut demander beaucoup de temps et deffort. Les services gnrs automatiquement par Centreon sont librement modifiables par les administrateurs. Les cas particuliers peuvent tre modifis directement. Dans ce cas, lutilisation des services appliqus des groupes est remplacer par des modles de services appliqus des modles de nuds.
REMARQUE Valable pour les versions de Nagios antrieures la 3.1
Comme nous lavons vu au chapitre 8, dans les versions infrieures ou gales Nagios 3.1, les exceptions sur un service appliqu un groupe de nuds ntaient pas simples. Avec les modifications intgres aux versions suivantes, ce problme ne devrait plus se poser.

Lors de la conception de la configuration, les groupes de nuds sont remplacer intgralement par les modles de nuds. Ceux-ci ont deux utilisations : placer les paramtres de supervision dhte ; servir de point daccroche de services.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

321

Cette mthode a cependant quelques inconvnients. Les administrateurs ont un peu de mal sy retrouver parmi la montagne de services configurs. Ce problme se rgle rapidement avec une bonne utilisation des filtres. Un problme un peu plus ennuyeux se pose lorsquun modle est retir dun nud. Les services sont gnrs automatiquement, mais leur suppression ne lest pas. Ce problme peut devenir difficile grer lorsque le nombre de nuds devient important. Il se pose un autre problme avec cette utilisation lorsque ladministrateur veut changer doutil de gestion de configuration. La configuration gnre par Centreon est valide du point de vue de Nagios. On peut lintgrer sans mal dans un nouvel outil. En revanche, les liens de templates lui sont spcifiques et ils sont donc perdus ; et avec eux, la gestion des mises jour simples des services. Les administrateurs se retrouvent face un nombre important de services non factoriss. Leur travail de refactorisation est important. Les risques derreur sont levs lors de cette phase. Heureusement, au vu des qualits de Centreon, ce genre de situation na que peu de chances de se produire.

Moins dutilisation du shell

la configuration dune commande, ladministrateur peut demander Centreon de celle-ci tester depuis linterface graphique. Ceci permet de simuler un lancement comme dans le cadre de Nagios. Ladministrateur na pas besoin de se connecter avec un shell pour effectuer cette vrification.
REMARQUE Pas toujours possible
Nous verrons plus loin que ce nest pas toujours possible cause de problmes de droits.

Cette possibilit permet un plus grand nombre dadministrateurs de dfinir des commandes ou des variations de commandes existantes. Ils nont pas connatre lemplacement physique des commandes pour les tester. Une option de Centreon permet de lancer les commandes avec largument -h, qui sert demander la documentation de la sonde. Ladministrateur a alors toutes les informations ncessaires pour tester et configurer efficacement sa nouvelle vrification.

Aspect supervision des alertes

Centreon permet de configurer les lments superviser, mais il est galement capable de prsenter le rsultat des vrifications.

322

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Une console trs pratique

Lcran principal dresse la liste des erreurs des services. Ladministrateur peut filtrer seulement sur certains nuds ou services qui lintressent. Des vues organises par groupes dhtes ou de services sont galement disponibles. Elles permettent aux administrateurs de garder un il sur les informations essentielles pour eux. Les vues les plus pratiques sont celles prsentant les problmes en cours. Les administrateurs nont pas grande considration pour les cas o tout est en ordre. Ce qui les intresse, ce sont les situations o un problme se pose. Ils nont pas envie de passer leurs journes parcourir des pages de messages OK pour enfin arriver une information CRITICAL. Les pages affichant lensemble des informations ne sont pas souvent utilises par les administrateurs. Certaines vues proposent galement dafficher uniquement les problmes qui nont pas encore t pris en compte par un administrateur. Linformation est fournie par Nagios. Un administrateur peut avertir Nagios quil prend en compte un problme et quil est inutile de lavertir nouveau. Ce fonctionnement a t tudi la fin du chapitre 3, sur la base de la commande externe ACKNOWLEDGE_SVC_PROBLEM. Nous verrons pas la suite que Centreon propose un moyen simple pour que ladministrateur prvienne Nagios. Lorsquun administrateur slectionne un hte ou un service, il obtient les informations prcises de la supervision. Outre le retour du plug-in de vrification et sa date de lancement, on dispose des informations suivantes : type dtat (Hard ou Soft) ; nombre de tentatives de vrification ; date de la prochaine vrification ; latence ; temps dexcution de la vrification ; date du dernier changement dtat ; pourcentage de changement pour le flapping. Ces informations permettent ladministrateur de vrifier que linformation disponible est rcente. Il peut ainsi vrifier o en est un service pour lequel il a t alert rcemment par e-mail. Ltat prsent est le dernier que possde Nagios. Certaines commandes externes de llment sont proposes. Ladministrateur peut, par exemple, demander une vrification immdiate. Voici une liste des principales commandes disponibles : planifier une vrification immdiate ; dsactiver ou ractiver les futures vrifications de llment ;

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

323

fournir un rsultat passif ; dsactiver ou ractiver les notifications de llment ; prendre en compte lalerte ; planifier une priode de maintenance.

On peut fournir des commandes Nagios sans pour autant devoir accder un shell sur le serveur de supervision. La syntaxe des commandes ntant pas vidente, le passage par une page web est le bienvenu. Nous pouvons voir ci-aprs une capture dcran de linterface de visualisation de lensemble des alertes, ainsi quune alerte particulire.
Figure 114

Capture dcran de linterface de visualisation de lensemble des alertes

Figure 115

Capture dcran de linterface de visualisation dune alerte particulire

324

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Obtention de toutes ces informations

Pour fournir ces informations aux administrateurs, Centreon doit les obtenir de Nagios. Si le fichier status.dat est prvu cet effet, il possde de gros inconvnients. Cest un fichier plat, quil faut parcourir en entier pour obtenir la moindre information. Ce fichier peut atteindre une taille assez consquente. Il nest pas rare de rencontrer des fichiers status.dat de plus de 10Mo. Le parcours dun fichier dune telle taille a un cot non ngligeable, dautant plus si nous lanalysons chaque interrogation. Afficher les informations utiles aux administrateurs pourrait prendre plus de 5 secondes, multiplies par le nombre dutilisateurs et par des dlais de rafrachissement des pages : les ressources dun serveur peuvent tre monopolises par ses consoles de supervision. Un mthode plus lgre est ncessaire. Ce genre de parcours est plus efficace en base de donnes et les requtes sont plus simples crire. Cest pour cela que Centreon utilise NDO. Le module NDOMOD, que nous avons dj voqu au prcdent chapitre, est utilis ici. Nagios envoie ses donnes dans la base NDO grce lutilisation conjointe de ndomod et ndo2db. Centreon se contente de lire les donnes en base. La configuration de ces deux programmes est gre dans Centreon, ce qui en simplifie la mise en place.
status.dat.

Pour information, linterface web de Nagios utilise encore ce jour le fichier Il nest pas conseill de lutiliser comme console de supervision constamment affiche sur un cran. Sa charge, en termes de temps de calcul CPU, est assez importante. Cest lune des raisons pour lesquelles elle nest pas traite dans cet ouvrage.

Un historique des alertes

Si observer les alertes en temps rel est pratique, pouvoir remonter le temps peut ltre galement. Centreon offre un accs lhistorique de toutes les alertes passes. Celui-ci permet de vrifier ce qui sest pass aux alentours dune date correspondant un incident. Le filtrage sur les noms de machines et de services permet de gagner un temps prcieux lorsque nous recherchons les causes dun problme particulier. Centreon propose de slectionner simplement les nuds ou les services, quil rassemble en groupes de nuds ou de services. Si le groupe entier est slectionn, lensemble des informations des membres seront remontes. On peut par ailleurs appliquer dautres filtres celles-ci. Parmi ces filtres, les plus utiles sont ceux sur la priode tudier, le type de message recherch (une alerte ou une notification par exemple) et enfin les tats des lments recherch (comme UP/DOWN pour les htes ou OK/CRITICAL pour les services). Ces slections sont trs rapides. Elles permettent de retrouver facilement et rapidement une information prcise sur un vnement pass. Les informations remontes peuvent

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

325

tre exportes : les formats grs sont le CSV et le XML. Ces donnes peuvent tre utilises par dautres outils ou tre remontes, par exemple, comme preuve la direction. Heureusement, cette recherche ne seffectue pas directement dans les fichiers journaux de Nagios, qui rallongeraient dautant la recherche quils peuvent tre volumineux. la place, toutes les 5 minutes, le programme /usr/local/centreon/bin/ logAnalyser analyse le fichier journal de Nagios. Il en extrait les informations quil dpose en base de donnes. Ce script permet galement darchiver dans /usr/local/ nagios/var/archives les anciens fichiers journaux de Nagios. Les recherches tant effectues en base de donnes, elles sont trs rapides. Elles profitent des possibilits de filtrage des requtes SQL.

Restrictions daccs
Les informations de supervision ne sont pas publiques. Elles peuvent contenir des donnes confidentielles. Certaines politiques de scurit sont ncessaires.

Des informations prives

Les administrateurs rseau nont pas besoin de connatre ltat des serveurs. Les administrateurs systme nont pas besoin de voir les dtails des liens rseau. Une vue synthtique leur suffit largement. Une alerte bnigne sur un lment rseau peut tre mal interprte par un administrateur systme. Si, par exemple, un lien secondaire est tomb, il ny aura aucune incidence sur les liens vus par les serveurs. Si, ce moment-l, un problme survient entre deux applications, le rseau est accus de suite. Seuls les administrateurs responsables de leur partie peuvent interprter correctement les informations quils reoivent. Eux seuls peuvent qualifier lalerte. La sparation des vues sur les erreurs est importante. Une interprtation errone est trs vite arrive. Les rgles de visualisation doivent tre positionnes afin de limiter ces problmes. Les administrateurs ne doivent pas avoir accs tous les nuds et services.

Diminuer le nombre dlments affichs

En plus de conduire des erreurs dinterprtation, prsenter des lments non pertinents pour les administrateurs est galement problmatique pour la lisibilit. Si un administrateur a accs plus de nuds quil ne devrait, il voit galement les alertes y tant accroches. Ces informations, sil nen a pas besoin, vont le polluer. Il ne verra pas clairement, au premier regard sur la console, ce qui est de son ressort ou non. En cas derreur critique sur un lment, il faut vrifier duquel il sagit. Lalerte peut porter sur un problme qui ne concerne pas ladministrateur. Il peut galement

326

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

perdre du temps inutilement dterminer si llment impact est de sa responsabilit ou non. Les notifications sont envoyes uniquement aux personnes responsables des lments : la vue dans la console doit faire de mme.

Des accs en modification surveiller

Les accs en modification doivent galement tre limits. Certains administrateurs ne sont pas forms lutilisation de Nagios. Ils peuvent modifier un lment, mais sans savoir ce quils font prcisment. Ils peuvent crer de gros problmes de configuration. Si la configuration est incorrecte, Nagios refusera de se relancer.
PRATIQUE Au moins deux administrateurs Nagios
Il est fortement dconseill de fonctionner avec un seul administrateur Nagios. Cest dautant plus vrai lorsque les commandes de rsolution de problmes sont configures. Si elles causent des soucis alors quaucun administrateur nest disponible, la solution de supervision dans son ensemble peut en ptir.

Un administrateur form rgle ce problme trs rapidement. Il ne se serait pas trouv dans une telle situation. Si aucune personne capable de rgler le problme nest prsente, la supervision devient indisponible et peut conduire une situation critique. Des lments rencontrent des problmes sans que personne ne puisse les dtecter avant les utilisateurs. Les accs en modification doivent tre rservs aux personnes qui y sont formes. Une formation, mme sommaire, peut suffire. Tous les champs ne sont pas intressants pour les administrateurs. Ceux-ci souhaitent le plus souvent changer les paramtres des commandes lances. Sils savent quils ne doivent toucher qu ce champ, les risques sont amoindris. Ils ne doivent avoir accs qu des lments dont ils sont responsables. Un administrateur systme na pas changer un paramtre sur une sonde vrifiant un lment rseau. Mme avec les meilleures intentions du monde, cela ne peut conduire qu des problmes.

Gestion des accs selon Centreon

ACL Centreon propose une gestion des accs trs fine. Nommes ACL (Access Control Lists ou listes de contrle daccs), ces rgles permettent de limiter la vision et les actions des utilisateurs. On peut paramtrer les pages accessibles, ainsi que les lments modifiables.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

327

Suivant les groupes dun utilisateur, il pourra avoir accs certaines parties de linterface et pas dautres. Sa vision sera limite aux nuds et services qui le concernent. Une application simple de ce principe consiste dfinir des utilisateurs ayant seulement le rle de pupitreur. Ils ne peuvent pas accder la partie configuration des lments. Ils peuvent observer les alertes des nuds qui les intressent, mais ne voient pas le reste des lments dfinis dans Nagios. Accs aux pages de linterface Les possibilits de filtrage sont regroupes dans des grandes familles que lon peut inclure ou exclure facilement : home : vue globale des tats des lments ; monitoring : vue prcise des erreurs ; views : accs la partie mtrologie ; reporting : partie rserve au reporting de Centreon ; configuration : partie concernant la configuration de Nagios et des lments qui sy trouvent ; administration : partie concernant ladministration de Centreon. Visibilit sur les lments Les lments visibles et modifiables sont galement disponibles. La slection peut se faire sur des groupes de machines, des htes ou bien des services, que lon peut inclure ou exclure. Cette fonctionnalit permet de filtrer trs finement laccs. Il est important de noter que ces accs sont dcorrls des notifications de Nagios. Les administrateurs peuvent recevoir une alerte de ce dernier sans pour autant avoir les autorisations daccs llment dans la console. Ce type de configuration est fortement dconseill : les administrateurs risquent de se sentir lss par la solution. La partie administration doit tre rserve aux administrateurs de Centreon. Les autres utilisateurs nont pas y avoir accs. Ils pourraient y faire des modifications empchant le bon fonctionnement de Centreon. La partie configuration peut tre laisse aux administrateurs ayant t forms Nagios. Ils peuvent changer directement la configuration pour la supervision des lments qui les concernent sans avoir demander systmatiquement lintervention de ladministrateur Nagios. Il est conseill de leur faire tester la configuration par Nagios avant de le relancer, car les modifications de configuration sont rarement bonnes du premier coup.

328

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Centreon, gestionnaire de la mtrologie

En plus de la configuration et de la visualisation des alertes, Centreon gre les donnes mtrologiques recueillies par Nagios.

CentStorage : le gestionnaire des donnes de performances

Centreon propose un module permettant de grer facilement la mtrologie. Celui-ci se nomme CentStorage. Il rcupre les donnes de mtrologie issues de Nagios dans le fichier /usr/local/nagios/var/service-perfdata. Ce dernier est rempli par Nagios de toutes les donnes de mtrologie issues des services. Pour cela, Centreon positionne dans la configuration de Nagios les paramtres suivants :
Activer la gestion des performances dans nagios.cfg
process_performance_data=1 service_perfdata_command=process-service-perfdata

La commande process-service-perfdata est dfinie comme :

Appel la commande process-service-perfdata
$USER1$/process-service-perfdata "$LASTSERVICECHECK$" "$HOSTNAME$" "$SERVICEDESC$" "$SERVICEOUTPUT$" "$SERVICESTATE$" "$SERVICEPERFDATA$"

Le script appel est /usr/loca/nagios/libexec/process-service-perfdata. Il crit simplement dans le fichier service-perfdata les donnes passes en arguments :
/usr/loca/nagios/libexec/process-service-perfdata
TIMET=$1 HOSTNAME=$2 SERVICEDESC=$3 OUTPUT=$4 SERVICESTATE=$5 PERFDATA=$6 PERFFILE="/usr/local/nagios/var/service-perfdata" /usr/bin/printf "%b" "$TIMET\t$HOSTNAME\t$SERVICEDESC\t$OUTPUT\t$SERVICESTATE\t$PERFDATA\n" >> $PERFFILE

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

329

Voici un exemple de ligne disponible dans ce fichier :

Extrait de /usr/local/nagios/var/service-perfdata
1232884634 srv-web1 uptime=8028213s Reboot OK: uptime=8028213s OK

O :
1232884634 : est la date de la donne, exprime en temps Unix. Ici le dimanche

25 janvier 2009 12h57. srv-web1 :est le nom de lhte. Reboot : est le nom du service. OK: uptime=8028213s : est le texte de retour de la sonde. OK : est le code retour de la sonde? uptime=8028213s : est la donne de performances utiliser pour le graphique.

Le module CentStorage est un programme crit en Perl tournant en tche de fond. Il utilise le compte nagios pour fonctionner et il a pleinement accs au fichier service-perfdata. Par dfaut, le programme CentStorage est situ dans /usr/ local/centreon/bin/.

Destination des informations

Le fichier de donnes est lu rgulirement : par dfaut, toutes les 10 secondes. Une fois le fichier analys, il est vid. Les donnes ont alors deux destinations : dans une base de donnes MySQL de Centreon ; dans des fichiers RRD. Chaque service dfini dans Centreon et renvoyant des donnes de performances possde une base RRD, qui est celle intressant les administrateurs. Cest elle qui sert gnrer les graphiques prsents aux utilisateurs de Centreon. La base de donnes de Centreon est utilise pour re-gnrer les bases RRD lorsque ces dernires ont des problmes, ou bien lors des phases de migration du serveur de supervision. Les donnes sont conserves un certain nombre de jours dans ces deux formats (par dfaut, 180 jours). Il est fortement recommand daugmenter cette dure de rtention, ne serait-ce que pour les bases RRD. Il peut tre utile de conserver les donnes au moins une anne.

Accs aux courbes

Centreon permet daccder rapidement aux donnes de mtrologie depuis un service affich sur linterface. Diffrentes priodes de temps sont proposes pour laffichage

330

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

des donnes. Ladministrateur peut observer les donnes sur les dernires heures, les derniers jours ou la dernire anne. Il peut galement observer les donnes sur une priode particulire. Les donnes sont de plus en plus agrges au fil du temps. Cette fonctionnalit ne peut tre utilise avec des informations prcises que sur des donnes rcentes, comme sur les tous derniers jours par exemple. Voici un exemple despace disque consomm sur un serveur au cours des derniers mois :
Figure 116

Exemple de courbe issue de CentStorage

Sur cette courbe, nous observons une forte augmentation de lespace occup sur le disque F: (courbe gris clair). Si lvolution continue ce rythme, dans deux mois, le disque sera plein. Les administrateurs doivent prendre des mesures rapidement sous peine de devoir trouver de lespace disque en urgence.

Des informations sur les performances de Nagios

Centreon propose aussi des graphiques qui ne sont pas rattachs des services dfinis par les administrateurs. Ils reprsentent diffrents indicateurs des performances de Nagios. Les principaux indicateurs sont : le nombre de vrifications de nuds ; le nombre de vrifications de services ; les temps de latence. Avec ces informations, ladministrateur Nagios peut savoir dun simple coup dil si Nagios a assez de ressources ou non se rfrer au chapitre 9 pour linterprtation des temps de latence.
PRATIQUE Supervision de la latence
Si lobservation de la latence dans Centreon est pratique, il est tout de mme conseill de mettre en place sa propre supervision comme expliqu au chapitre 9.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

331

Centreon facilite la gestion des alertes SNMP

Comme nous avons pu le voir dans un chapitre prcdent, la gestion des traps SNMP au sein de Nagios nest pas vidente. SNMPTT facilite la vie de ladministrateur mais reste encore lourd grer. Pour rappel, lenvoi des alertes SNMP vers Nagios ncessite de compiler la MIB dun constructeur. Cette tape garantit que SNMPTT, rception dune alerte contenue dans la MIB, envoie une alerte passive Nagios sur le service TRAP. La commande effectuant ceci est :
Commande de conversion de MIB pour en extraire les traps SNMP
snmpttconvertmib in=EQUIPEMENT.MIB --out=/etc/snmp/ snmptt.conf.equipement --exec='/usr/local/nagios/libexec/eventhandlers/ submit_check_result $r TRAP 1'

Cette mthode ntait pas trs pratique. Il fallait lancer cette commande pour chaque fichier MIB, ce qui na rien de simple. Toutes les alertes du fichier arrivaient un mme service dans Nagios, et ce mme si les informations taient destines des contacts diffrents. Il ntait pas possible de dfinir plusieurs services pour plusieurs contacts. Tous devaient tre relis au mme service TRAP et tous recevraient les alertes. Ce manque de souplesse explique en grande partie pourquoi les traps SNMP ne sont que peu dploys dans le cadre dun Nagios simple. Les administrateurs nont pas particulirement envie de passer leur temps compiler des MIB en ligne de commande pour obtenir des informations trop globales leur got.

Un chargement et une compilation automatique

Centreon en propose une gestion simplifie et plus souple, et les administrateurs ont tout intrt lutiliser sils souhaitent faire usage des traps SNMP dans leur environnement. Dans linterface de Centreon, on peut dfinir des constructeurs, qui servent simplement contenir un ensemble de MIB provenant du mme fabricant. Une fois un constructeur dfini, on peut lui charger des fichiers MIB directement par linterface. Il ny a pas besoin denvoyer le fichier sur le serveur de supervision, il sera simplement charg au travers de linterface web. Centreon propose deffectuer automatiquement et sans effort le travail de compilation des MIB pour SNMPTT. Chaque alerte lue est insre dans la base de donnes de Centreon. Une fois lensemble des informations ncessaires enregistres en base, ladministrateur peut demander la gnration automatique de la configuration de SNMPTT. Pour chaque constructeur, un fichier /etc/snmp/centreon_traps/snmpttCONTRUCTEUR.conf va tre cr, dans lequel nous retrouvons la structure classique de

332

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

la configuration de SNMPTT : chaque OID aura sa propre entre. Les messages des alertes et un appel au script /usr/local/nagios/libexec/traps/trapHandler y figurent. Ce script, fourni par Centreon, est charg denvoyer ces alertes Nagios.

Remonte dalertes de SNMPTT vers Nagios

Voici, par exemple, la ligne dappel trapHandler, situe dans lentre dun levant en cas dauthentification errone sur un lment rseau :
Appel trapHandler
/usr/local/nagios/libexec/traps/trapHandler $aA $A $o "An authenticationFailure trap signifies that the SNMP $*" OID

se

Les arguments de trapHandler sont des macros de SNMPTT. Tout comme dans le cas de Nagios, elles sont modifies lorsque la commande est envoye. Elles signifient respectivement : $aA : adresse IP de lmetteur, $A : nom de lmetteur, $o : OID de lalerte SNMP envoye. Avec ces informations, trapHandler peut rechercher le service mettre en alerte. Une fois que ladministrateur a dfini les OID dans Centreon, il peut les associer un service. Cette association se fait dans la base de donnes de Centreon. Nagios nen a aucune connaissance. Cette fonctionnalit permet de dfinir plusieurs services pour des alertes diffrentes. Les fichiers MIB ne sont plus vus comme un bloc, mais bien comme une collection dalertes dans laquelle les administrateurs pourront piocher souhait. Pour savoir qui alerter, trapHandler parcourt ces relations dfinies en base de donnes. Sil trouve, pour la machine qui a envoy lalerte, un service accroch lOID mis, il gnre alors une alerte passive pour ce service. Pour cela, il crit simplement dans le fichier nagios.cmd avec lappel :
Envoi dun rsultat Nagios
/bin/echo "[$datetime] PROCESS_SERVICE_CHECK_RESULT;$this_host;$this_service;$status;$argument s_line" >> $conf[0]

La valeur $conf[0] est le fichier nagios.cmd. Nagios recevant une alerte passive, il lve les notifications requises au besoin, comme pour nimporte quelle alerte passive. Le fonctionnement global est illustr sur le diagramme suivant :

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

333

Figure 117 La gestion des alertes SNMP (traps) au sein de Centreon

Centreon permet dassocier simplement, et en passant uniquement par son interface graphique, des OID et des services. Les administrateurs nont plus besoin de compiler la main les MIB ni dcrire la configuration des fichiers SNMPTT pour chaque service : le gain de temps est donc trs important.

Centreon pour grer Nagios en distribu

La dernire facult de Centreon est utile dans le cas de grands environnements : il permet de grer simplement plusieurs serveurs Nagios.

Une configuration complexe

De mme quil nous facilite la gestion des alertes SNMP, Centreon peut grandement nous aider mettre en place une architecture distribue. Comme nous lavons vu au chapitre prcdent, Nagios peut tre install sur plusieurs serveurs afin de rpartir la charge de supervision. Cette installation peut tre fastidieuse. De plus, la gestion de la configuration sur plusieurs serveurs peut devenir complexe. Centreon gre cette possibilit. Avec une seule console de supervision, les administrateurs peuvent visualiser la totalit des alertes. Ils peuvent galement lutiliser pour configurer tous les Nagios rpartis.

Les Nagios distants : des pollers

Pour cela, Centreon propose la notion de poller ou satellite. Il en ncessite au moins un. Chaque poller est un Nagios distribu. Il y a un Nagios local au serveur Centreon comme auparavant, mais aussi dautres, situs sur des serveurs distants. Cette mise en place est simple et sera tudie en dtail dans un prochain chapitre. Le module permettant de grer les interactions entre Centreon et les diffrents Nagios est CentCore. Cest un programme crit en Perl qui se trouve dans /usr/ local/centreon/bin. Il utilise le compte nagios du serveur Centreon. Chaque Nagios a un nom, qui sert pour la valeur instance_name de la base NDO des Nagios. Ce module est utilis pour centraliser les alertes provenant des Nagios distribus.

334

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Dans Centreon, chaque Nagios possde ses propres fichiers de configuration nagios.cfg et ndomod.cfg. Le serveur Centreon, quant lui, dispose en plus dun fichier ndo2db.cfg utilis par ndo2db. Ce dernier rceptionne les messages des Nagios distants et envoie les informations dans une base de donnes. Cette base est ensuite lue par Centreon pour afficher les informations aux utilisateurs. Cest le mme fonctionnement qui est utilis dans le cadre dun Nagios simple mais, ici, chaque Nagios distant a son identifiant en base.

Associations poller / htes

Les nuds superviser sont accrochs un satellite et un seul. On cre cette relation trs facilement dans la configuration au sein de Centreon.
CONFIGURATION Un poller proche
Lorsque lon dploie des pollers pour des problmes de performances, il est fortement recommand de slectionner le satellite le plus proche en termes de rseau pour effectuer la vrification.

Une fois ces relations dfinies, Centreon gnre la configuration de chaque poller. Celle-ci se compose des fichiers nagios.cfg et ndomod.cfg, mais galement des fichiers de tous les lments superviser et ce qui y est raccroch. Seuls les lments devant tre superviss par le poller sont gnrs. La configuration globale est rpartie sur lensemble des pollers. Lensemble des contacts et des commandes figurent dans les configurations distribues. Les serveurs distants devant lancer les vrifications et avertir les administrateurs, ils ont besoin de ces informations.

Envoi des configurations

Cet clatement de la configuration est effectu par CentCore. Une fois toutes les configurations gnres, elles sont envoyes sur les serveurs distants grce SCP, commande de copie utilisant le protocole SSH. Une fois lenvoi termin, un test est effectu avec la commande md5sum afin de vrifier que les fichiers nont pas t modifis pendant lenvoi. Ladministrateur peut demander chaque Nagios distant de vrifier la configuration qui lui est soumise. Si elles sont toutes valides, il peut leur demander de recharger leur configuration.

Outils daide la configuration : lexemple de Centreon CHAPITRE 11

335

Des Nagios presque indpendants

Chaque processus Nagios distant fonctionne de manire indpendante des autres. Ils nont mme aucune connaissance les uns des autres. Leur seul lien avec Centreon est leur module NDOMOD qui envoie les donnes vers la base NDO. Ils doivent superviser les htes que leur ont confis les administrateurs. Ils doivent lancer les commandes de vrification et grer les problmes comme le ferait nimporte quel Nagios. Leur comportement est identique un Nagios unique ayant sa propre configuration. Ils lancent les notifications si besoin. Les pertes de connexion avec NDO2DB sont gres avec le tampon denvoi de ndomod, ce que nous avons tudi au chapitre prcdent. Il est conseill de dimensionner ce tampon de manire assez large si les liaisons entre les diffrents lments sont de mauvaise qualit.
PRATIQUE Ne pas oublier de surveiller les Nagios
Comme tudi au chapitre 10, la supervision des Nagios est importante. Pour cela, la sonde
check_ndo est toute adapte.

Mtrologie issue des satellites

Les valeurs de mtrologie recueillies sur les pollers ne sont pas oublies. Chaque Nagios gnre son propre fichier service-perfdata. CentCore rcupre ces fichiers rgulirement. Ce transfert se fait, comme pour les fichiers de configuration, par SCP. Une fois rcuprs, les fichiers sont dposs dans le rpertoire /var/lib/centreon/ perfdata/ID. La valeur ID est lidentifiant du satellite dans la base Centreon. Une fois un fichier dpos dans ce rpertoire, CentStorage lintgre dans sa base MySQL et dans les bases RRD. La suite est identique au cas dun seul satellite. Ce fonctionnement est illustr par le diagramme suivant :

Figure 118 La gestion des donnes de performances dans le cas dune architecture distribue

336

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Les administrateurs nont pas se proccuper de lintgration des donnes de performances lorsquils disposent dune architecture distribue. Leur travail en est grandement facilit.

Des notifications repenser

Dans cette configuration, les notifications sont envoyes directement par les Nagios satellites. Si, dans la majorit des cas, cela ne pose pas de problme, certains cas particuliers font surface. Les serveurs SMTP des entreprises ne sont pas ouverts toutes les machines. Il existe une liste de serveurs autoriss sy connecter. Dans le cas dune architecture distribue, chaque serveur distant a besoin dun tel accs. Il ne faut pas oublier de les rajouter et procder un test denvoi de-mail lors de la mise en place. Lutilisation de rss-multiuser peut galement poser des problmes. Les serveurs distants ont juste besoin dun Nagios. Un serveur Apache nest pas utile. Si les processus nagios gnrent chacun un fichier RSS, les administrateurs doivent rajouter un serveur web sur chaque satellite. Pour empcher cela, il peut tre utile de faire pointer les sorties des scripts rss-multiuser sur un partage NFS mont par le serveur Centreon qui hberge le service Apache. De cette manire, chacun rajoute ses informations dans un fichier commun.

En un mot
Les outils daide la supervision peuvent recler des piges que les administrateurs doivent connatre : il est courant de voir des personnes mettre en place une solution complte et penser quavec une interface graphique, ils nont pas concevoir les mthodes de supervision. Ces outils sont nanmoins trs utiles, ils induisent un gain de temps ne pas ngliger. Parmi eux, Centreon est une rfrence. Il soccupe de nombreux aspects de la solution comme la supervision, la configuration, la gestion des alertes SNMP (traps) ou encore la mtrologie. Il facilite grandement la mise en place denvironnements distribus.

12
Au-del de la supervision : cartographie et reporting
Une fois les informations de supervision recueillies, il peut tre important de les prsenter sous diffrentes formes, que les donnes soient utilises immdiatement ou agrges pour tre intgres dans des indicateurs.

Agrgation de vues avec NagVis

Nous avons tudi les notifications et les consoles de supervision. Jusquici, la prsentation des alertes est trs technique. Voyons comment il est possible de reprsenter ces informations pour coller au mieux au systme dinformation tel que ce que les administrateurs et les utilisateurs se le reprsentent.

Mise en relief des informations importantes

Le rle de cette reprsentation nest pas de remplacer les consoles de supervision. Elle doit se limiter un nombre raisonnable dindicateurs reprsentatifs.

338

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

RAPPEL Des moyens dalerte varis

Les administrateurs reoivent les notifications de Nagios sous diverses formes. Les e-mails, flux RSS et SMS sont les moyens les plus connus. Le chapitre 6 en a prsent une large panoplie. Certains peuvent faire sourire, mais ils reprsentent des moyens efficaces pour que les administrateurs prsents leur bureau soient avertis. Les consoles de supervision sont galement une source prcieuse dinformations sur les alertes en cours. Certaines nont pas encore t envoyes aux administrateurs car elles demandent vrification. Leur niveau de criticit peut cependant tre important. Des alertes de niveau CRITICAL sont captes du regard bien plus facilement que de simples avertissements. Cette gestion des niveaux de criticit a galement t tudie au chapitre 6.

Des consoles qui ne se vident pas

Un nombre consquent dalertes sont prsentes en continu sur ces consoles de supervision. Elles prsentent au minimum les notifications quont reues les administrateurs et gnralement un peu plus. Suivant la taille du systme dinformation, le nombre moyen dalertes varie entre 1 % et 2 % du nombre dlments superviss. Les consoles ne sont jamais totalement vertes. Les administrateurs ayant comme objectif de navoir aucune erreur dchantent gnralement assez vite. Les erreurs ne restent jamais bien longtemps sur la console. Pour celles qui ne sont que passagres, un test supplmentaire suffit les supprimer. Les administrateurs ne reoivent pas de notification pour de telles alertes. Elles ne sont prsentes que temporairement sur les consoles de supervision. Dans dautres cas, il peut sagir de vraies erreurs ; dans ce cas, les administrateurs sont avertis et les rsolvent rapidement. Une console de supervision affiche donc toujours des erreurs, quelles soient temporaires ou non. Les systmes et les applications en subissent constamment. Les administrateurs se battent pour que ce nombre reste raisonnable. Ils tendent, au fil du temps, amliorer la situation grce des interventions plus rapides ou des rsolutions automatiques. Le nombre derreurs moyen est cens diminuer, mais cest sans compter sur le fait quils dfinissent aussi de nouveaux indicateurs. Ils supervisent de plus en plus dlments car ils ne sont limits, en la matire, que par leur imagination. Un quilibre existe entre ces deux tendances. Il se stabilise entre 1 et 2 % de taux moyen dalertes. Celles-ci tendent devenir de moins en moins critiques. Cest sur cet aspect que les administrateurs peuvent le plus amliorer la disponibilit du systme dinformation.
EN PRATIQUE Un taux de 1 % viser... aprs paramtrage !
Ce taux nest valide que pour une solution stabilise. Lors de sa mise en place, les erreurs de paramtrage lui font rgulirement dpasser 10%.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

339

Des alertes plus ou moins critiques

Les alertes remontent dans la console pour lensemble des environnements. Les simples avertissements sont nombreux. Les administrateurs ne veulent voir en direct que les indicateurs qui les intressent vraiment. Pour le reste, les notifications font trs bien laffaire. Ils traiteront ces problmes en temps voulu, une fois la production assure. Une vue plus agrge des alertes peut tre pratique. Cette vue peut tre affiche sur des crans allums dans le service informatique. Mme si les administrateurs ne sont pas leur poste, ils peuvent voir si un lment est en panne. Ces crans, contrairement aux e-mails ou aux notifications, sont visibles par lensemble des personnes prsentes dans les locaux. Il est extrmement important de ny faire figurer que des informations utiles. Si un directeur passe et observe sur lcran une image de priphrique avec des indicateurs rouges ou verts, il peut ne pas lapprcier, dautant plus que les ressources consommes sont celles de son service.
EN PRATIQUE Une vitrine ne surtout pas ngliger
Ces crans sont la partie la plus visible de la solution de supervision. Ils servent aussi de point daccs aux informations pour les non-administrateurs. Ils sont aussi importants que la partie non visible.

crans publics et crans privs

Les crans peuvent tre selon les cas : visibles de tout le monde ; visibles des seuls administrateurs. La figure 12-1 prsente un exemple de placement des diffrents crans.
Figure 121

Exemple de placement des crans

340

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Dans ces deux situations, les informations quil est possible de fournir ne sont pas identiques, comme nous allons le voir par la suite. Que ce soit sur le fond ou la forme, les deux types dcrans ne prsentent pas les mmes niveaux dinformation. Il est important que les crans des administrateurs ne soient pas visibles de tout le monde. Les responsables eux-mmes ne devraient pas les avoir sous les yeux en continu. Dans la majorit des cas, ils ne peuvent pas prendre le recul suffisant pour interprter les informations reues de Nagios. Ce ne sont pas eux qui ont dfini les services et les seuils de criticit. Ils ne devraient venir voir ces crans que lorsquun indicateur est pass en orange ou en rouge sur les crans publics. Une fois avertis dune application posant problme, ils peuvent demander un administrateur ce qui se passe. Bien souvent, ce dernier peut alors montrer lcran o linformation est clairement affiche.

Choisir les informations afficher

Le choix des indicateurs importants varie selon le public vis. Les changements portent sur le fond aussi bien que sur la forme des crans.

Slection des alertes sur les crans publics

Les administrateurs naiment pas que les crans publics affichent en permanence du rouge, puisquils sont... responsables lorsque quelque chose va mal. Le rouge est directement interprt comme une erreur critique par la majorit des personnes. Des crans continuellement rouges sont synonymes de problmes critiques constants. Or si tel tait rellement le cas, ces administrateurs ne seraient plus en poste depuis longtemps... Cest donc que le systme dinformation fonctionne plutt bien en priode normale. Ces priodes normales devraient tre caractrises par des crans publics principalement verts, qui ne sont pas ncessairement ceux des consoles dadministration, puisque ces dernires relvent y compris des avertissements sur lensemble du systme.
RAPPEL Slection des indicateurs
Les administrateurs doivent faire particulirement attention aux indicateurs slectionns pour laffichage. Ce qui est critique pour eux ne lest pas forcment pour leur direction. Un service de sauvegarde peut tre arrt et remont en erreur critique pour les administrateurs. Pour eux, le problme est grave. Sans intervention, les prochaines sauvegardes nauront pas lieu. Le service est tout de mme fourni aux utilisateurs. Cest cet aspect, et uniquement celui-l, qui doit tre remont sur les crans publics.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

341

Les vues utilisateur doivent tre exposes au regard de tous ; elles dmontrent ainsi une volont de transparence de la part du service informatique plus forte raison quand celui-ci a mauvaise rputation. Les administrateurs sont gnralement vus comme des personnes peu sympathiques, sexprimant en des termes sotriques pour la majorit des personnes. Ils sont responsables de tous les maux survenant sur le systme dinformation. Bien souvent, ils sont mme accuss de faire de la rtention dinformation quant la disponibilit des applications. Avec un tel systme dcrans, tout le monde peut savoir dans quel tat se trouvent les applications. Il nest pas utile dafficher des indicateurs trop hermtiques aux utilisateurs, comme les charges des machines ou les espaces disque. Cest laccessibilit des applications qui doit tre linformation principale et visible comme telle. Quant aux niveaux de fonctionnement dgrads, ils peuvent certes tre reprsents sur ces crans mais sans tre considrs comme critiques. Un utilisateur ou un directeur passant par l et voyant une croix rouge ct du nom dune application pense immdiatement quelle nest pas disponible du tout. Si lindicateur est orange, il comprend, sans que personne ne lui donne la notice dexplication, que des problmes existent mais quils ne mettent pas en pril lutilisation de lapplication.

Slection des alertes sur les crans privs des administrateurs

Les administrateurs aiment tre avertis en cas de problmes. Ils ne veulent ltre que lorsque cela les intresse vraiment. Ce dilemme sest dj pos lors de la mise en place des notifications. Il se pose nouveau lorsque nous parlons des crans de surveillance quils ont sous les yeux en permanence. Les administrateurs sont encore plus sensibles ces derniers quaux notifications. Ils doivent donc choisir un nombre restreint dindicateurs au sein de Nagios afficher en continu. Le critre de choix est similaire celui des notifications critiques. Seules les alertes demandant une intervention immdiate doivent tre prsentes sur ces crans. Il est possible de voir ces crans de surveillance comme un prolongement des notifications, qui avertissent dun problme que, suivant le niveau de criticit, ladministrateur prend en compte ou non. Les crans de supervision peuvent ainsi concentrer les indicateurs les plus importants pour les administrateurs. Ceux-ci reoivent toujours les notifications, mais leur regard est attir automatiquement lorsquun changement se produit. Au lieu dafficher une liste derreurs, les crans peuvent reprsenter un tat global des systmes. En cas derreurs nombreuses, cela permet de sy retrouver beaucoup plus facilement et les administrateurs traitent en priorit ce qui se trouve sur les crans. Les tats des applications sont de bons indicateurs pour les administrateurs. Ils refltent le service dlivr aux utilisateurs. On peut galement ajouter dautres indicateurs plus techniques, par exemple les liens rseau. La visualisation des diffrents lments

342

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

dun cluster est galement importante. Les utilisateurs ont toujours accs aux applications, mais les administrateurs doivent rgler les problmes le plus rapidement possible avant quils ne se propagent. Ces crans permettent aux administrateurs de faire leur contrle matinal bien plus rapidement. Ils peuvent bien sr aller vrifier les notifications quils ont reues pendant la nuit, mais un cran leur montre ltat actuel. Un cran rempli de vert est bon signe : il ny a pas derreur importante. Ils peuvent se concentrer sur des actions moins importantes que remettre en marche la production.
REMARQUE Des diffrences entre les crans pour administrateurs et pour utilisateurs
Il est intressant de remarquer que les administrateurs souhaitent des crans bien diffrents de ceux des utilisateurs. Ils tendent vers une vision conceptuelle de leur architecture. A contrario, les utilisateurs veulent des informations basiques limites aux applications. Ces diffrences illustrent bien les diffrents points de vue entres ces deux mondes.

Les flux entre les applications sont galement des informations quil est possible dafficher. Les administrateurs peuvent, en arrivant le matin, tout comme pour ltat des applications, savoir si les traitements importants de la nuit se sont bien passs. Cette vrification a le mrite dtre immdiate.

Lutter contre la tentation de multiplier les indicateurs

Les administrateurs ont tendance vouloir toujours plus dindicateurs sur les crans de supervision. Ce nest pas une bonne ide. Ladministrateur en charge de Nagios pourrait y passer ses journes.
RAPPEL crans versus consoles de supervision
Rappelons que les crans ne remplacent pas les consoles de supervision comme celle de Centreon. Ils sont une agrgation des indicateurs les plus importants.

Les administrateurs doivent identifier parmi les leurs un nombre raisonnable dlments afficher. Sils ne sont pas capables de le faire, cest quils nont pas t capables de bien ordonnancer leur criticit pour les notifications. Il faut alors leur expliquer comment procder.

Des vues hirarchises dindicateurs

Comme nous allons le voir par la suite, on peut prsenter sur les crans des indicateurs en contenant dautres.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

343

Cela permet de crer une hirarchie de cartes. Une conception du gnral au particulier est recommande. Le systme dinformation doit tre reprsent dans son ensemble. Nous le dcoupons en applications principales. Celles-ci peuvent tre redcoupes gographiquement si besoin. La figure 12-2 montre un exemple de hirarchie de cartes.
Figure 122

Exemple de hirarchie de cartes de supervision

Plus on descend dans larbre des cartes, plus on entre dans le dtail. Les responsables nont pas besoin davoir les cartes prcises sous les yeux. Une vue plus haute leur suffit gnralement. Deux hirarchies parallles sont utilises : une pour les crans publics ; une autre pour les crans des administrateurs. La vue des administrateurs est plus prcise que celle des utilisateurs. Elle comporte bien plus derreurs. Si cette vue se situait en-dessous, hirarchiquement, de celle des utilisateurs, ces derniers observeraient des erreurs quils ne devraient pas voir. Un autre arbre parallle au premier est ncessaire. Les donnes ne sont pas lies un arbre, mais peuvent tre affiches dans plusieurs arbres simultanment. Il ny a donc pas de problme de duplication de donnes.
PRATIQUE Un nombre variable de hirarchies
Nous conseillons deux hirarchies afin de bien sparer les vues utilisateur et administrateur. Ce nombre ne constitue pas une limite haute. Si des vues reprsentent une vision plus prcise dun pan du systme dinformation et quelles ne sont destines qu certains utilisateurs, alors elles peuvent former leur propre hirarchie.

Vues de diffrents types : logique, physique, gographique

Si la visualisation au sein de Nagios ou de Centreon est trs axe sur les erreurs des machines, les cartes de supervision laissent libre champ limagination des administrateurs.

344

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Diffrents types de vues sont possibles. Ils vont dpendre de ce que Nagios est capable de superviser. Ses possibilits sont grandes ; par exemple il est possible de faire figurer des indicateurs qui ne sont pas du tout techniques (par exemple, indicateur issu dune sonde alertant un financier sur la chute dun cours de bourse, etc.). De manire gnrale, on peut distinguer trois types de cartes : physique : reprsentation des serveurs ou des lments rseaux ; logique : reprsentation des applications ; gographique : liens rseau entre les pays, par exemple. Les administrateurs peuvent reprsenter facilement des indicateurs pour des personnes peut enclines recevoir des alertes par e-mail. Elles peuvent avoir un tat des lieux des informations importantes en levant la tte.

Reprsenter graphiquement la prise en compte des erreurs

Les outils de mise en page de cartes permettent de prsenter les erreurs ayant t prises en compte. Cela permet aux administrateurs de montrer que le problme est en cours de rsolution et quil nest pas ncessaire de les prvenir quun incident est en cours. Les administrateurs sont plus enclins utiliser cette fonction de Nagios si elle est directement visible. Elle peut mme devenir une vritable interface entre les administrateurs et les utilisateurs. Ces derniers peuvent vrifier simplement quun problme est survenu, mais galement quil a t dtect et pris en compte par les personnes responsables. Si la prise en charge des incidents est rapide, limage du service informatique peut tre fortement amliore.

Localiser et illustrer les erreurs

Les vues doivent tre prsentes de faon claire et concise. De longues listes linaires derreurs permettent ladministrateur de sapercevoir quune erreur est en cours, mais lobligent sapprocher de lcran pour connatre prcisment lenvironnement en cause. Si en revanche lerreur est localise sur un schma de lenvironnement par une croix rouge, situe devant un lment, le message est bien plus clair. Il nest pas ncessaire de sapprocher de lcran pour savoir ce qui est en panne. Quant aux images reprsentant les lments, elles doivent tre choisies avec soin. Si llment reprsent est une imprimante, mettre une image de serveur na que peu de sens. Mettre limage dune imprimante quelconque est dj une dmarche plus intressante. Ces vues sont aussi nombreuses quil y a de systmes informatiques. Les administrateurs doivent pouvoir dfinir eux-mmes les images de fond des crans. Ils peuvent ainsi y placer, leur convenance, les informations releves par Nagios. Ce dernier mettant jour ses informations rgulirement, les administrateurs observent des donnes jour.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

345

Ces images de fond doivent tre sobres. Si elles fourmillent de dtails, on a du mal y retrouver les informations importantes. Des diagrammes avec des couleurs ples sont trs adapts ce genre de cas. Ils peuvent reprsenter facilement les diffrentes couches des applications.
GRAND COMPTE Sur une carte du monde...
Les situations gographiques peuvent galement tre prises en compte. Une simple carte du monde avec peu de couleurs et quelques indicateurs reprsentant la connectivit des filiales suffit. Cette carte est interprte par tout le monde comme ltat des liens entre les pays. Le titre de la page nest mme pas ncessaire.

Fonctionnement de NagVis pour cartographier les erreurs

Parmi les outils permettant dagrger les donnes de supervision de Nagios pour obtenir des crans de supervision, il en est un qui se dtache nettement en termes de fonctionnalits et de stabilit : NagVis. crit en PHP, il utilise beaucoup de Javascript afin de donner vie aux pages.
COMMUNAUT Licence GPL v2 de NagVis
La licence de NagVis est, comme souvent, la GPL v2. Le projet NagVis connat une volution sre et rgulire, et regroupe une trs large communaut. Les contributions dutilisateurs concernent principalement des images utilisables pour loutil.

La cration des cartes se fait directement depuis son interface web. Cette tape est intuitive. Les fonctionnalits Javascript font que la dfinition dun lment et son placement sont faciles.

Disposition des indicateurs sur une carte de supervision

NagVis propose aux administrateurs de crer leur propre carte de supervision. Celleci est un simple fond au format PNG sur lequel ils placent diffrents indicateurs. Il est possible de choisir ceux-ci dans la liste suivante : hte ; service ; groupe dhte ; groupe de service ; carte.

346

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Si les premiers lments sont clairement dfinis, le dernier ncessite quelques explications. Il permet dobtenir une hirarchie entre les cartes. Un tat est associ chaque carte, correspondant ltat le plus grave des lments quelle contient. Si une carte contient un hte qui est en tat DOWN, alors elle est en tat critique. Les informations peuvent ainsi tre remontes aux niveaux suprieurs. Si les niveaux les plus levs sont verts, cest que tous les indicateurs dfinis en-dessous le sont galement.

Choix des images par ladministrateur

Images des lments superviss
En plus de permettre le choix des fonds de carte, NagVis propose aux administrateurs de choisir les images reprsentant les diffrents lments superviss. Une collection est disponible en standard. Elle est compose dimages au format PNG reprsentant des croix rouges, oranges ou vertes. Une collection a un nom (NOM) et les images qui la composent doivent tre nommes en respectant la forme suivante : NOM_ack.png : un problme sur un hte ayant t pris en compte par un administrateur ; NOM_error.png : linformation nest pas disponible ; NOM_unknown.png : ltat est UNKNOWN ; NOM_critical.png : le service est en tat CRITICAL ; NOM_ok.png : le service est en tat OK ; NOM_up.png : lhte est en tat UP ; NOM_down.png : lhte est en tat DOWN ; NOM_sack.png : un problme sur un service ayant t pris en compte par un administrateur ; NOM_warning.png : le service est en tat WARNING. Ces images doivent tre situes dans le rpertoire /usr/local/nagios/share/ nagvis/nagvis/images/iconsets. Les administrateurs peuvent dfinir, sur chaque carte, une collection utiliser par dfaut. Si un ou plusieurs lments doivent utiliser une autre collection, il est possible de le spcifier. Les administrateurs peuvent ainsi crer des images de diffrentes tailles ou plus reprsentatives des lments que les simples croix fournies par dfaut.
ERGONOMIE Le format PNG pour grer la transparence
Les images doivent tre au format PNG. Cela permet de grer la transparence. Sans cela, les cartes sont beaucoup moins jolies.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

347

De nombreux modles sont mis disposition par la communaut. Ils peuvent tre adapts librement.

Bibliothque dimages libres

NagVis permet galement aux administrateurs de placer sur les cartes les images quils souhaitent sans quelles soient forcment lies un lment supervis. Elles peuvent tre utiles afin dgayer les fonds choisis par les administrateurs. Il est bien plus simple de dfinir un fond simple et basique, et dy apposer des images, que de redessiner des fonds pour chaque cas. Les administrateurs pouvant placer les images librement avec un simple navigateur web, la maintenance et la cration de nouvelles cartes en est simplifie. La figure 12-3 prsente un exemple de carte quil est possible de crer avec NagVis, en loccurrence une reprsentation des tats des services principaux dun systme de messagerie lectronique.

Figure 123 Exemple de carte avec NagVis

Rcupration des tats

NagVis peut rcuprer les donnes de Nagios de plusieurs manires. Ladministrateur doit pour cela dfinir un backend, autrement dit une mthode daccs aux informations. Deux backends sont disponibles :

348

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

ndomy ; ndo2fs.

Ndomy : lecture depuis une base MySQL (ndo2db)

La premire mthode est utilise dans le cas o les informations issues de Nagios sont stockes grce ndo2db. NagVis rcupre les donnes de Nagios en scrutant la base NDO. Dans le cadre dune solution utilisant Centreon, NDO est dj prsent. Lintgration de NagVis en est facilite. Les requtes de NagVis ne sont pas particulirement consommatrices du point de vue de la base de donnes. Lors de la configuration de NagVis, il faut fournir le nom, ladresse et un compte pour la base de donnes. Ces paramtres doivent tre placs dans la partie backend_ndomy_1 du fichier de configuration de NagVis : backendtype : nom du module utilis, ici ndomy ; dbhost : adresse du serveur MySQL ; dbport : port de la base ; dbname : nom de la base NDO utilise ; dbuser : utilisateur pour accder la base ; dbpass : mot de passe de lutilisateur ; dbprefix : prfixe utilis pour les tables de la base NDO, gnralement nagios_ ; dbinstancename : nom de linstance Nagios utilise ; maxtimewithoutupdate : temps dinactivit dinstance partir duquel NagVis affiche une erreur ; gnralement 180 secondes (3 minutes). Voici un exemple de configuration standard :
Configuration MySQL pour NagVis
[backend_ndomy_1] backendtype="ndomy" dbhost="localhost" dbport=3306 dbname="db_nagios" dbuser="nagios" dbpass="superpassword" dbprefix="nagios_" dbinstancename="default" maxtimewithoutupdate=180

Au-del de la supervision : cartographie et reporting CHAPITRE 12

349

Ndo2fs : lecture depuis des fichiers plats

Ce module concurrent de ndo2db permet dexporter les donnes de Nagios non pas dans une base de donnes mais directement en fichiers plats. Le programme ndo2fs est un programme crit en Perl qui coute sur un socket les informations provenant de ndomod. Assez jeune, il nest pas encore trs utilis.
EN COULISSES Choix du nom de ndo2fs par les auteurs de NagVis
Les auteurs de NagVis ont nomm leur module ndo2fs du mme nom que le programme ponyme qui gnre les fichiers en sortie de ndomod (qui joue un rle quivalent ndo2db).

peut tre utile dans le cas o lon ne souhaite pas mettre en place de base Si lon nutilise pas Centreon, la base de donnes nest quune gne pour obtenir les informations. Avec ndo2fs, un simple rpertoire suffit contenir les informations de Nagios et les prsenter au reste du monde.
ndo2fs MySQL.

IMPORTANT Utilisation conjointe de ndo2fs et ndo2db

Lutilisation de Ndo2fs nempche pas celle de ndo2db. Le premier est capable de transmettre toutes les informations reues sur un socket. Cela permet de chaner les programmes. Ce processus est illustr en figure 12-4.
Figure 124

Chanage des modules ndo2fs et ndo2db

Seules certaines donnes sont gres par ce module. Voici la liste des donnes conserves : les vrifications dhtes (check) ; les changements dtat (statechange) ; les tats des nuds (host_status) ; les contacts (contact_status) ; les tats des services (service_status) ; les commentaires (comment) ; les fichiers de configuration principaux (main_config) ; les prises en compte dincidents (acknowledgement) ; la sauvegarde des tats entre les redmarrages (retention) ; la configuration des objets (object_config) ;

350

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

les priodes de maintenance (downtime) ; ltat du processus Nagios actuel (program_status) ; les vrifications de services (service_check) ; lhistorique des anciens processus Nagios (process).

Ladministrateur souhaitant utiliser uniquement ndo2fs peut dfinir le paramtre data_processing_options de ndomod la valeur 32259009. Les fichiers gnrs sont rpartis dans deux rpertoires : PERSISTENT : toutes les donnes qui se conservent la fermeture de Nagios, comme les fichiers de journalisation ; VOLATILE : les informations temporaires. Le second rpertoire, VOLATILE, est le plus intressant. Cest dans celui-ci que se trouvent les donnes utilises par NagVis. Il est organis en rpertoires pour chaque instance de Nagios. Les rpertoires disponibles sont : auth : liens entre les contacts, les htes et les services ; contactgroups : liste des contacts dans les groupes ; contacts : liste des contacts ; hostauth : liens entre les contacts les htes ; hostgroups : liste des nuds dans leurs groupes ; hosts : liste des htes ; serviceauth : liens entre les contacts et les services ; servicestate : tats des services. Quatre fichiers sont la racine de linstance : mainconfig : paramtres du fichier de configuration principal ; process_status : historique des anciens processus Nagios ; program_status : tat du processus Nagios actuel ; runtimevars : statistiques de la configuration de Nagios. La consommation despace des fichiers de la partie VOLATILE est constante lors dune excution de Nagios. titre dexemple, une configuration de 6 000 services consomme environ 110 Mo. Il est conseill de placer ce rpertoire directement en mmoire. Pour cela, il suffit de le faire pointer vers le rpertoire /dev/shm sous Linux.
PERFORMANCE Une consommation raisonnable
La majorit des processus nagios grent entre 3 000 et 6 000 lments. Mme pousse lextrme avec les 40 000 services dfinis dans le chapitre 9, la consommation de lespace de ndo2fs reste acceptable aux vu des capacits mmoire des serveurs actuels.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

351

La configuration de la partie ndo2fs au sein de NagVis est plus simple que celle de ndomy : path : chemin vers les fichiers de ndo2fs ; dbinstancename : nom de linstance Nagios utilise ; maxtimewithoutupdate : temps dinactivit dinstance partir duquel NagVis affiche une erreur, gnralement 180 secondes. La charge de ndo2fs est plus faible que celle de ndo2db. Nayant pas grer toute une base de donnes, cette solution consomme moins de ressources CPU. Elle nest pas adapte pour les analyses sur le long terme des informations. Il est conseill de linstaller en mmoire afin den maximiser les performances. Les informations des lments sont directement accessibles selon leur nom grce la hirarchie de ndo2fs. NagVis nayant pas besoin deffectuer une requte pour obtenir les informations, la charge est limite. Si les informations sont en mmoire, la charge est mme minimale.

Rotation des vues dans NagVis

Les crans de supervision sont accrochs au mur. Ils nont pas dutilisateur constamment connect. Dans bien des cas, un PC est cach sous un bureau et lcran reli affiche les cartes. Il nest pas envisageable de demander une personne de faire dfiler les cartes les unes aprs les autres. Une solution possible est de laisser affiche la carte situe au sommet de la hirarchie. Outre le fait dabmer les crans, elle permet de savoir quun problme est arriv, mais nest pas trs prcise. Certes toujours utile, linformation pourrait tre bien mieux exploite. NagVis propose une solution simple ce problme : les rotations. Il sagit de listes de cartes dfinies par ladministrateur. Lorsquune rotation est affiche lcran, la page est rafrachie automatiquement par la carte la suivant dans la rotation. Lintervalle de temps entre les cartes est paramtrable par ladministrateur. Par dfaut, il est gal 15 secondes. Suivant les crans, les cartes affiches ne doivent pas tre les mmes. Pour cela, ladministrateur peut dfinir diffrentes rotations. Dans chaque rotation, il place les cartes quil a cres pour les diffrents types dcrans. Une fois la rotation lance, les crans se succdent sans fin. Le choix des crans prsents ne doit pas se faire la lgre. Pour les crans publics, trop dinformations peuvent tre nfastes. Pour les administrateurs, avoir trop dinformations ralentit la dtection des problmes.

352

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

PRATIQUE Des hirarchies trs utiles

Une bonne mthode pour choisir les cartes placer dans les rotations consiste repartir des hirarchies de cartes. Toutes les vues nont pas besoin dtre reprsentes. Suivant la taille de larbre, les deux ou trois premiers niveaux peuvent constituer la rotation. Les utilisateurs observant un problme sur un niveau suprieur nont qu attendre quelques secondes pour obtenir une information plus prcise.

Mise jour automatique des cartes lajout dun noeud

Mettre jour rgulirement les cartes peut tre fastidieux. Si les administrateurs souhaitent avoir beaucoup dindicateurs, ladministrateur Nagios passe une partie de son temps ajouter de nouveaux lments. Certaines vues reprsentent une sous-partie du systme dinformation, par exemple les serveurs prsents dans une filiale de grande importance. Lorsquun nouvel lment est ajout dans la filiale, il faut penser lajouter sur la carte. Dans un cas sur deux, ladministrateur oublie. Pour grer cela, NagVis propose une fonctionnalit permettant de gnrer des cartes automatiques. Une fois quun nud lui est fourni, il est capable de reprsenter ltat de ses enfants et petits-enfants. Il est possible de se limiter au niveau de la profondeur de larbre afficher. Ds quun nouvel hte est ajout, le rafrachissement suivant de la carte le reprsente.
DFAUT Vue par groupes
Il aurait pu tre pratique de proposer une vue par groupes dhtes ou de services. Malheureusement, NagVis ne propose pas, pour linstant, une telle fonctionnalit.

Reporting dans Nagios

Les alertes en temps rel sont importantes, mais pouvoir prendre du recul en tudiant leur rpartition et leur volution dans le temps lest tout autant.

De limportance dune analyse plus globale et dans le temps

La supervision, comme nous lavons mise en place jusqu prsent, se focalise sur les alertes en temps rel. Les notifications permettent de remonter dans le temps rcent. La mtrologie permet, quant elle, dobserver de plus prs des manques rcents de ressources. Sur une longue priode, elle permet de prvoir, en extrapolant, les consommations futures. partir de l, les administrateurs peuvent tailler au plus juste les environnements.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

353

Sur le long terme, une alerte na que peu dimportance. Si elle est trs ge, le problme est srement rsolu. Il en est de mme pour la mtrologie. Une valeur ancienne a peu dintrt. Cest pour cette raison que la mtrologie est agrge afin de fournir les variations sur le long terme. La supervision doit galement faire lobjet dagrgations. Cest le rle du reporting des alertes. Si une moyenne du nombre dalertes est disponible pour chaque environnement, il est possible de dtecter ceux qui ont le plus de difficults.
PSYCHOLOGIE Superviser les administrateurs ?
Encore plus que pour la supervision en temps rel, les administrateurs peuvent trs mal prendre les rsultats prsents ici. Il faut faire particulirement attention ce que les moyennes sur les environnements ne soient pas interprtes comme des moyennes sur les personnes. Les valeurs recueillies par les outils que nous allons voir ne doivent pas tomber entre toutes les mains.

Lorsque les administrateurs reoivent au jour le jour les alertes, ils ne peuvent pas prendre un recul suffisant pour apprcier au mieux les points faibles des environnements. Ces sujets sont en outre trs sensibles, et peu dadministrateurs sont objectifs lorsquil sagit de leurs serveurs. Un calcul effectu de manire totalement objective permet dviter ce genre de problmes. Une fois les environnements reprs, les efforts damlioration peuvent se concentrer dessus. La supervision passe un stade suprieur. Reste dfinir ces calculs prcisment et comment les mettre en place.

Dfinir les indicateurs : une mission dlicate

Le plus dlicat dans la mise en place de loutil de reporting nest pas la partie technique, mais le choix de ce que nous souhaitons calculer. Une simple moyenne de tous les indicateurs nest pas intressante. Leur nombre est trop important pour russir sy retrouver. On utilise des indicateurs agrgs. Lagrgation est ici aussi utile que dans le cadre de la mtrologie. Sa dfinition est cependant un peu plus complexe. Pour la mtrologie, une simple agrgation sur le temps suffit. Dans le cas de la supervision, ladministrateur doit dfinir des indicateurs agrgeant divers lments. Deux pistes complmentaires sont considrer : lanalyse des taux de disponibilit ; les taux de performances dgrades. Dans le premier cas, seuls les lments de supervision reprsentant un tat binaire des services sont pris en compte. Cest la forme de donne la plus simple obtenir.

354

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Dans le second cas, les occurrences de performances dgrades sont prises en compte. Ces indicateurs sont plus complexes mettre en place. Leur interprtation nest pas vidente non plus. Si le service informatique est soumis contrat avec les autres services, les taux acceptables ont dj t discuts. Suivant que les contraintes aient t fortes ou non, suivant la ralit des chiffres, les parties peuvent se remettre daccord sur des valeurs plus acceptables. La limite du taux de disponibilit des applications est plus simple dfinir que celle des performances dgrades. Les utilisateurs ne comprennent pas quun systme peut tre disponible mais plus lent que la normale. L encore, les taux peuvent tre remanis pour coller au plus prs de la politique de lentreprise. Si les informations ne sont utilises quen interne dans le service, la pression de ces chiffres est moindre. Les rsultats permettent de savoir si des investissements particuliers sont ncessaires. Par exemple, si la disponibilit de lapplication est trs bonne, mais que son taux de performances dgrades est lev, des amliorations sont prvoir. Si les pertes sont dues une faiblesse dun nud du cluster, lajout dun membre est envisageable.
RAPPEL Une couleur part : lorange
Si, en matire de supervision, les couleurs vertes et rouges sont simples comprendre, lorange est plus sujet interprtation. Tout le monde linterprte comme quelque chose va mal . Au regard de leurs expriences respectives, les utilisateurs pensent un problme de disponibilit sur un module particulier alors que les administrateurs pensent un ralentissement.

Le module de reporting de Centreon

Centreon permet ladministrateur de slectionner une priode de temps sur laquelle il souhaite obtenir des valeurs. Une fois cette priode choisie, ladministrateur slectionne llment sur lequel porte le calcul. Il peut choisir une liste de nuds, des groupes de nuds ou enfin des groupes de services. Linterface va chercher les informations en base de donnes. Une fois le calcul effectu, les donnes sont affiches lutilisateur sous plusieurs formes. Dans le cas dun hte, les diffrents tats sont reprsents. Les taux sont exprims en termes de pourcentage et de dure pendant laquelle llment tait dans un tat donn. Les informations sont galement disponibles pour chaque service qui y est attach. Un histogramme reprsentant les tats du nud sur la priode choisie est disponible. Lors dun vnement particulier, ladministrateur a accs sa date et sa dure. Il peut retracer finement les erreurs qui se sont produites.

Au-del de la supervision : cartographie et reporting CHAPITRE 12

355

En un mot
Les administrateurs ont souvent besoin dobserver ltat des indicateurs les plus importants de leurs systmes. Des crans de supervision placs dans leur bureau constituent un lment incontournable de la solution. NagVis permet de rcuprer les informations de Nagios et de les prsenter de manire agrable. Le choix des informations y placer nest pas si simple. Suivant la personne qui regarde les crans, les alertes peuvent ne pas tre interprtes de la mme manire. Les crans publics doivent tre conus avec un trs grand soin. Les solutions de reporting ne sont pas en reste. Elles font pleinement partie de laspect processus du projet. Centreon propose un module relativement complet.

13
Compilation et installation de Nagios, Centreon et NagVis
Passons enfin la mise en place des outils tudis ! Voyons comment, en partant dun systme vierge, nous pouvons arriver une solution pleinement fonctionnelle.

Les diffrentes possibilits de mise en place

Les possibilits dinstallation de logiciels sous Linux sont varies. tudions-les afin que les administrateurs puissent faire leur choix en connaissance de cause.

Installation partir de paquets

Les distributions recourent des gestionnaires de paquets pour linstallation de programmes. Cette mthode assure une cohrence et le maintien des diffrents lments niveau. Lors de linstallation, cest le systme qui gre les relations de dpendance : ladministrateur demande linstallation dun programme, et tous les paquetages dont il dpend sont proposs et installs. Cette mthode est la prfre des administrateurs systme. Une seule commande met jour lensemble de leur systme. Luniformisation de cette mthode permet de gagner

358

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

du temps. Nul besoin de connatre par cur toutes les options des programmes puisque le dveloppeur qui a compil et empaquet le programme a dj fait le choix des options, qui permettent dutiliser le programme dans le maximum de situations. Hlas, en de rares occasions, ces choix ne sont pas adapts aux besoins de ladministrateur.
EXEMPLE Inclusion de linterprteur Perl dans le paquet
Par exemple, une poque, il ntait pas possible de choisir dutiliser ou non linterprteur Perl intgr Nagios. Ce choix tait fait lors de la compilation. Si un script ne passait pas la phase de compilation interne, il tait lanc avec linterprteur Perl du systme. Chaque lancement demandait une compilation interne voue lchec, qui dgradait les performances. Suivant le choix du crateur du paquetage, linclusion ou non de linterprteur Perl pouvait correspondre ou non aux besoins de ladministrateur.

Compilation depuis les sources

La mthode par compilation est plus contraignante. Elle demande ladministrateur de connatre les options de compilation des programmes quil souhaite mettre en place. Il peut choisir ses chemins dinstallation. Suivant ce quil dcide dutiliser, il na pas la mme installation que les autres personnes. Ceci peut lui demander de changer des paramtres des programmes qui utiliseront loutil.
Ladministrateur reproduit tout le travail de celui qui fait les paquetages pour la distribution...

Cette mthode lui permet de choisir ses propres options de compilation. Si une fonctionnalit de loutil ne lintresse pas, il peut ne pas lintgrer. Ceci permettra notamment de diminuer les ressources ncessaires au programme.
PERFORMANCE Un gain minime
Le principal gain dans la suppression dune option de compilation est la mmoire. Nous avons vu que la consommation de Nagios sur ce point est trs raisonnable. Le gain esprer est donc minime.

Mise en place complte automatique avec FAN

Nagios fonctionne sur de nombreux environnements. Le nombre de distributions GNU/Linux lintgrant dans leurs paquetages standard est trs important. Peu dentre elles proposent une installation simple et automatique de la solution complte. Une seule existe pour linstant : FAN (Fully Automated Nagios). Elle est base sur la distribution CentOs et propose la solution la plus simple et efficace pour mettre en

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

359

place Nagios, Centreon, NagVis et Nareto (un outil de reporting) en une seule installation. Elle a de plus lavantage de proposer un environnement dj configur. Les administrateurs nont plus qu rajouter leurs lments superviser. Cette distribution avance rapidement et elle est promise un grand avenir dans le monde de la supervision Open Source. Elle va devenir sans lombre dun doute la rfrence pour la mise en place dune solution complte de supervision base sur de Nagios.
COMMUNAUT Histoire de FAN
Initi par Cdric Temple dbut 2008 pour rpondre des besoins quotidiens dadministration, le projet FAN, Fully Automated Nagios, est une distribution GNU/Linux ddie la supervision base sur Nagios et son formidable cosystme. Les auteurs ont cout les demandes de nombreux utilisateurs pour btir une solution complte qui comprend les principaux plug-ins de Nagios, linterface de configuration Centreon pour la configuration, NagVis pour la visualisation agrge des problmes, ou bien encore NaReTo pour le reporting arborescent. Son objectif principal est de fournir tout cela en moins de 20 minutes avec la mme simplicit dinstallation que pour nimporte quelle autre distribution.

Installation manuelle complte titre didactique

Lors de la prcdente mise en place, nous avons utilis la mthode par paquetage. Ladministrateur a pu commencer prendre en main loutil. Nous allons tudier une installation par compilation, surtout afin de bien comprendre les rpertoires et dpendances des applications qui nous intressent.
ALTERNATIVE FAN pour aller plus vite !
Dans le cas dune installation en environnement rel, si les administrateurs manquent de temps, ils peuvent se tourner vers la distribution FAN dont nous venons de parler.

Lors de cette installation, nous allons mettre en place tous les outils voqus jusqu maintenant. Lordre de mise en place est important : Centreon a besoin de NDO pour fonctionner ; ce dernier a besoin dun Nagios fonctionnel. Les grands principes dinstallation de logiciels ayant t traits, il est temps de se concentrer sur le cas de notre solution de supervision.

Compilation et installation de Nagios

Nagios tant la pierre angulaire de notre solution, nous allons commencer par lui.

360

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Rcupration du programme Nagios

La compilation commence par la rcupration des sources. Ladministrateur peut obtenir celles de Nagios sur le site officiel, http://www.nagios.org. Nous allons utiliser la dernire version stable au jour de rdaction : la 3.1.0.
PRATIQUE Une installation en tant que root
Les commandes lancer de ce chapitre doivent tre lances par lutilisateur root.

Les sources se prsentent sous la forme dun fichier tar.gz de 2.5 Mo. Il est ncessaire de transfrer le fichier sur le serveur choisi par ladministrateur. Pour cela, on peut utiliser le logiciel winscp, disponible librement. Une fois le fichier transfr, ladministrateur doit dcompresser les sources.
Dcompression des sources de Nagios
tar xvfz nagios-3.1.0.tar.gz

Pr-requis de Nagios
La compilation de Nagios demande un compilateur. Le plus adapt cette situation est le compilateur roi du monde Open Source : gcc. Le programme make est galement ncessaire.
Installation des outils de dveloppement
yum install make gcc

Phases de linstallation de Nagios

Compiler un programme pour Linux suit presque toujours les trois mmes tapes :
1 configure 2 make 3 make install

La premire phase permet ladministrateur de slectionner les composants intgrer loutil, mais aussi les chemins de fichiers. Le script configure gnre les options de compilation pour la suite des oprations. La seconde tape lance la compilation proprement parler. Cette phase peut tre relativement longue suivant le programme.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

361

La dernire phase dploie le programme compil ainsi que tous ses fichiers dans les rpertoires choisis par ladministrateur. Phase de configuration Le programme configure possde de nombreuses options. Ladministrateur peut en dresser la liste avec loption -help. Voici les options principales de ce script pour la compilation de Nagios : --prefix : chemin principal de linstallation. Par dfaut, /usr/local/nagios. --libexecdir : chemin des sondes. Par dfaut, $prefix/libexec. --sysconfdir : chemin des fichiers de configuration de Nagios. Par dfaut, $prefix/etc. --localstatedir : chemin pour les fichiers temporaires de Nagios. Par dfaut, $prefix/var. --enable-nanosleep : active la fonction nanosleep au sein de Nagios. Celle-ci permet lordonnanceur dtre plus prcis. --enable-event-broker : active les fonctions devent broker. --enable-cygwin : permet des administrateurs tmraires de mettre en place un systme Nagios sous Windows. --with-nagios-user : utilisateur de lapplication, habituellement nagios. --with-nagios-group : groupe de lutilisateur de lapplication, habituellement nagios. --with-checkresult-dir : chemin des fichiers rsultats des commandes de vrification, habituellement $prefix/var/spool/checkresults. --enable-embedded-perl : active linterprteur Perl interne. --with-perlcache : active le cache Perl vitant de compiler les scripts chaque lecture. CFLAGS : permet de spcifier des options de compilations au programme GCC. Dans linstallation que nous allons mettre en place, nous allons utiliser les chemins par dfaut de Nagios. Le programme sera install dans /usr/local/nagios. La configuration sera dans /usr/local/nagios/etc, les sondes dans /usr/local/nagios/ libexec, le binaire nagios sera dans /usr/local/nagios/bin et enfin les fichiers temporaires de Nagios seront dans /usr/local/nagios/var. La fonction nanosleep permet Nagios dtre plus prcis dans lordonnancement des vrifications. Sans elle, il est contraint dutiliser la fonction sleep qui permet seulement dattendre un nombre entier de secondes, contrairement nanosleep qui permet des attentes de lordre de la milliseconde.

362

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Dans notre installation, le module NDO aura une importance prpondrante. Il utilise les fonctionnalits obligatoires devent broker de Nagios. Le cache Perl est dune importance primordiale si ladministrateur souhaite utiliser linterprteur intgr. Sans le cache, le gain de linterprteur est nul, voire ngatif. Grce au cache, Nagios nest pas oblig de compiler les scripts Perl chacun de leurs lancements. Sils sont appels souvent, le gain est trs important. Les options par dfaut de GCC activent les options de dbogage et une optimisation modre des programmes. Si ladministrateur na aucune ide du rle du programme gdb, les options de dbogage ne sont pas ncessaires. Quant aux options de compilation, il est conseill dopter pour des valeurs maximales. Les options de GCC deviennent alors -O3 (optimisation niveau 3). Lutilisateur nagios devant faire fonctionner lapplication nexiste pas encore. Pour lajouter, il faut lancer la commande :
Ajout de lutilisateur nagios
adduser nagios passwd nagios

Au final, lappel configure est :

Lancement de configure
./configure --prefix=/usr/local/nagios --enable-nanosleep --enableevent-broker --with-nagios-user=nagios --with-nagios-group=nagios -enable-embedded-perl --with-perlcache CFLAGS=-O3

Si aucun message derreur nest affich, la configuration de la compilation est prte. Phase de compilation Pour lancer la compilation, il faut faire appel au programme make. Ce dernier utilise le fichier Makefile gnr par la commande configure et prend en argument les objets compiler. Le plus simple est dutiliser largument all permettant de compiler tous les objets. La commande make prend galement en argument -j le nombre de processus parallles de compilation. Si le serveur possde plusieurs processeurs, ladministrateur a tout intrt utiliser cette fonctionnalit. Placer une valeur lgrement suprieure au nombre de processeurs est optimal. Pour lancer la compilation de Nagios sur une machine bi-processeur, il suffit de lancer :

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

363

Compilation de Nagios sur une machine double cur

make all -j 3

Aprs lexcution dune longue srie de commandes sotriques, la commande rend la main. Elle annonce firement par un *** Compile finished *** que la compilation est russie. Phase dinstallation On doit ensuite lancer les commandes suivantes : make install : cre le rpertoire /usr/local/nagios et y installe le binaire nagios ; make install-init : installe le script nagios dans /etc/init.d pour le lancer en tant que service ; make install-commandmode : cre le rpertoire contenant le fichier de commandes externes de Nagios ; make install-config : installe des exemples de fichiers de configuration dans /usr/local/nagios/etc ; make install-webconf : ce lancement optionnel installe les fichiers de configuration pour Apache dans /etc/httpd/conf.d. Une fois toutes ces commandes excutes, Nagios est install. Tous les fichiers indispensables au fonctionnement de Nagios sont situs dans le rpertoire /usr/local/nagios. Dplacer un Nagios simple sur un nouveau serveur consiste simplement copier ce rpertoire.

Compilation de NDOUtils
NDOUtils est indispensable la communication des informations au sein de la solution : cest son tour dtre install.

Rcupration et compilation de NDOUtils

La compilation de ndoutils ressemble fortement celle de Nagios. Les sources disponibles sur le site de Nagios correspondent la version 1.4b7. Une fois le fichier des sources tlcharg et plac sur le serveur, il faut le dcompresser :
Dcompression des sources de NDOUtils
tar xvfz ndoutils-1.4b7.tar.gz

364

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Les options de configure sont les suivantes : --prefix : mme sens que pour Nagios ; --enable-mysql : utiliser les bases MySQL pour ndo2db ; --enable-pgsql : utiliser la place les bases PostgreSQL ; --with-ndo2db-user : utilisateur faisant fonctionner ndo2db ; --with-ndo2db-group : groupe de lutilisateur ci-dessus. Dans notre situation, nous allons privilgier une base sous MySQL. Cest la seule gre par Centreon que nous installerons plus tard. La compilation de NDO demande les bibliothques de dveloppement de MySQL. Pour cela, il faut installer le paquetage mysql-devel :
Installation des bibliothques de dveloppement pour MySQL
yum install mysql-devel

Il est important dinstaller ces bibliothques avant de lancer le script configure.

Lancement de configure
./configure --prefix=/usr/local/nagios --with-ndo2db-user=nagios -with-ndo2db-group=nagios enable-mysql

La phase de compilation qui suit est trs rapide.

Compilation de NDOUtils
make all

Une fois la compilation effectue, il faut crer la base de donnes dans laquelle ndo2db va envoyer ses informations. Nous allons nommer cette base nagios. Le programme ndo2db a besoin dun compte pour y accder la base : le compte cr est nagios.

Cration de la base pour NDO

Le programme mysql est ncessaire pour grer les bases de donnes. Pour linstaller et le lancer, on utilise les commandes suivantes :
Installation et lancement du serveur MySQL
yum install mysql-server /etc/init.d/mysql start

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

365

La cration de la base nagios est simple si nous utilisons le programme mysqladmin :

Cration de la base nagios
mysqladmin create nagios

REMARQUE Un nom variable pour la base

Il arrive de voir cette base porter le nom ndo dans certaines documentations. Cest tout fait valide et ceci nentrane pas de problme par la suite.

Crer le compte nagios ncessite de se connecter la base nomme mysql :

Cration de lutilisateur nagios pour la base du mme nom
mysql mysql GRANT CREATE,SELECT,INSERT,UPDATE,DELETE ON nagios.* TO 'nagios'@'localhost' IDENTIFIED BY 'superpass'; flush privileges;

Pour vrifier que le compte est fonctionnel, il suffit se connecter la base :

Vrification de laccs la base
mysql -u nagios -psuperpass nagios

La base est cre mais ne possde aucune table utilise par NDO. Les sources de NDOutils comportent toutefois un rpertoire db. Le script installdb quil contient permet de crer automatiquement les tables :
Installation de la base nagios
installdb -u nagios -p superpass -h localhost -d nagios

Le script ne trouvant pas les tables de NDO dans la base, il procde leur cration :
Rsultat de linstallation
DBD::mysql::db do failed: Table 'nagios.nagios_dbversion' doesn't exist at ./installdb line 51. ** Creating tables for version 1.4b7 Using mysql.sql for installation... ** Updating table nagios_dbversion Done!

366

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

La premire ligne est une erreur normale. Elle rsulte de labsence de la table nagios_dbversion.

Installation de NDO
Une fois la base prte, il est temps de passer aux binaires, qui sont situs dans le rpertoire src. Le module ndomod est constitu du fichier ndomod-3x.o. Ndo2db, quant lui, correspond au fichier ndo2db-3x. La dnomination -3x sert diffrencier les versions 2 et 3 de Nagios. Elle nest pas utile dans notre mise en place actuelle. Linstallation des fichiers est simple :
Mise en place de NdoMod et Ndo2db
cp ndomod-3x.o /usr/local/nagios/bin/ndomod.o cp ndo2db-3x /usr/local/nagios/bin/ndo2db

Les seuls fichiers manquants sont les fichiers de configuration des deux binaires. Ils sont situs dans le rpertoire config. Il suffit de les copier dans le rpertoire /usr/ local/nagios/etc.
Mise en place des fichiers de configuration
cp ndomod.cfg /usr/local/nagios/etc/ cp ndo2db.cfg /usr/local/nagios/etc/ chown nagios:nagios /usr/local/nagios/etc/*cfg

Installation des sondes de Nagios

Le Nagios actuel est incapable de lancer des sondes, et pour cause : il ny en a aucune. Sur le site de Nagios, les sources des plug-ins standard sont disponibles, sous la forme dune archive de 2.2 Mo dans la version actuelle (1.4.13). Une fois larchive dpose sur le serveur, ladministrateur peut procder sa dcompression et la compilation des sources.
Dcompression des sources des sondes Nagios
tar xvfz nagios-plugins-1.4.13.tar.gz cd nagios-plugins-1.4.13

Le script configure possde beaucoup doptions. Les principales sont : --prefix : chemin de linstallation de Nagios ; --with-ipv6 : utiliser les capacits IPv6 des sondes ; --with-ping-command : commande pour ping.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

367

Dans notre cas, nous allons lancer la commande de manire simple :

Lancement de configure
./configure --prefix=/usr/local/nagios

Si des WARNING figurent dans la sortie de la commande, certains pr-requis ncessaires des sondes ne sont pas prsents. Par exemple, nous pouvons avoir :
Erreur dans configure sur snmpget
checking for snmpget... no configure: WARNING: Get snmpget from http://net-snmp.sourceforge.net to make check_hpjd and check_snmp plugins

Cela signifie que la commande snmpget nest pas disponible sur le systme. Pour linstaller, ainsi que tous les utilitaires SNMP, il faut lancer :
Installation des outils SNMP
yum install net-snmp-utils perl-Net-SNMP

Il faut alors relancer le script configure. La ligne WARNING disparat et les sondes utilisant SNMP sont prises en compte. La commande make
Compilation des sondes
make all -j3 all

permet de compiler les sondes configures.

La commande

make install

procde linstallation des sondes dans

/usr/local/

nagios/libexec.

Installation des sondes

make install

Toutes les sondes disponibles ne sont pas installes. Certaines sont entreposes dans le rpertoire contrib : elles sont en phase dacceptation dans la branche principale. La plupart sont des scripts Perl. Les sources C doivent tre compiles avant dtre utilises. Pour cela, ladministrateur doit utiliser make. Par exemple, pour compiler le fichier check_cluster2.c :

368

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Compilation dun plug-in en particulier

make check_cluster2

Le binaire doit tre copi dans Nagios.

/usr/local/nagios/libexec

pour tre utilis par

Il est fortement recommand ladministrateur dtudier et de tester les sondes disponibles.

La compilation et linstallation de lagent NRPE et sa commande check_nrpe sont trs similaires celles de Nagios et ne seront pas traites ici.

Installation de Centreon
Les briques de base tant en place, ladministrateur peut se concentrer sur les outils visant parfaire la solution. Centreon est le premier tre install.

Pr-requis linstallation
Une fois installs Nagios, les modules ndomod et ndo2db, il est temps de mettre en place Centreon. Il faut bien lavouer, cette mise en place nest pas des plus courtes. Elle nest pas complexe, mais repose sur de nombreux pr-requis. Les plus importants sont : Nagios ; les sondes ; Apache ; MySQL ; PHP 5 ; GD ; sudo ; RRDTool 1.2 ; la bibliothque net-snmp. Pour cela, il faut lancer la commande :
Installation des prrequis Centreon
yum install php gd gd-devel rrdtool net-snmp sudo httpd

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

369

Les bibliothques ncessaires Centreon sont nombreuses :

yum install php-mysql php-pear php-snmp php-posix gd-devel libpng libpng-devel perl-Config-IniFiles perl-Crypt-DES perl-Digest-Hmac perlDigest-SHA1 perl-GD perl-IO-Socket-INET6 perl-Net-Snmp perl-rrdtool perl-Socket6 php-gd php-ldap

Rcupration et installation de Centreon

Les sources de Centreon sont disponibles sur le site http://www.centreon.com. Une fois larchive dcompresse sur le serveur, ladministrateur peut passer la phase dinstallation.
Dcompression des sources de Centreon
tar xvfz centreon-2.0.tar.gz cd centreon-2.0

Toute linstallation se fait travers le script install.sh. Ce dernier pose des questions ladministrateur. Sil valide loption sans saisir de valeur, la valeur par dfaut, situe entre crochets [], est utilise. Nous dressons ci-dessous la liste des questions pour lesquelles ladministrateur ne doit pas laisser les valeurs par dfaut :
Lancement de linstallation de Centreon
./install.sh -i Do you accept GPL license ? [y/n], default to [n]: y Do you want to install : Centreon Web Front [y/n], default to [n]: y Do you want to install : Centreon CentCore [y/n], default to [n]: y Do you want to install : Centreon Nagios Plugins [y/n], default to [n]: y Do you want to install : Centreon Snmp Traps process [y/n], default to [n]: y Do you want me to create this directory ? [/usr/local/centreon] [y/n], default to [n]: y

370

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Do you want me to create this directory ? [/usr/local/centreon/log] [y/n], default to [n]: y Do you want me to create this directory ? [/etc/centreon] [y/n], default to [n]: y Where is the RRD perl module installed [RRDs.pm] default to [/usr/lib/ perl5/RRDs.pm] /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/RRDs.pm

Pour trouver ce module, on utilise la commande suivante :

Localisation du fichier RRD.pm
updatedb && locate RRDs.pm

Le script dinstallation se poursuit :

Where is PEAR [PEAR.php] default to [/usr/share/php/PEAR.php] /usr/share/pear/PEAR.php

Pour ce fichier, on utilise encore la commande locate :

Localisation du fichier PEAR.php
locate PEAR.php

Suite de linstallation
Do you want me to create this directory ? [/usr/local/centreon/bin] [y/n], default to [n]: y Where is your NDO ndomod binary ? default to [/usr/sbin/ndomod.o] : /usr/local/nagios/bin/ndomod.o Do you want me to configure your sudo ? (WARNING) [y/n], default to [n]: y

Nous arrivons un message peu clair :

I think you'll have a problem with 'Default requiretty' in sudo file Press enter to continue.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

371

Il faut ouvrir une nouvelle session shell et diter le fichier /etc/sudoers pour y commenter la ligne suivante :
Ligne qui doit tre commente dans /etc/sudoers
# Defaults requiretty

Elle permet un utilisateur nayant pas de vrai shell de faire appel sudo. Centreon tant une application web, cest le service Apache qui fait appel sudo. Apache fonctionne sans shell. Une fois ceci fait, la suite de linstallation de Centreon peut reprendre.
Do you want to add Centreon Apache sub configuration file ? [y/n], default to [n]: y Do you want to reload your Apache ? [y/n], default to [n]: y

La phase suivante du script met jour les modules de PHP ncessaires Centreon. On utilise pour cela le module PEAR de PHP. Avec une connexion directe, aucun problme ne survient ; dans le cas contraire, il faut rajouter les informations de proxy. Dans un nouveau shell :
Configuration dun proxy pour PEAR
pear config-set http_proxy "http://monuser:monpass@serveur-proxy:3128"

PRATIQUE Un premier passage rat

Il se peut que la partie PEAR du script dinstallation se lance avant que ladministrateur ait eu le temps dajouter le proxy. Ce nest pas bloquant : le script fait simplement un premier passage infructueux avant den proposer un second qui sera bien meilleur. Ladministrateur a tout de mme le temps daller prendre un caf pendant la premire phase...

Phase de mise jour de PEAR et fin de linstallation :

Upgrading PEAR modules Do you want me to create this directory ? [/var/run/centreon] [y/n], default to [n]: y Do you want me to create this directory ? [/var/lib/centreon] [y/n], default to [n]: y

372

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Do you want me to install CentStorage init script ? [y/n], default to [n]: y Do you want me to install CentStorage run level ? [y/n], default to [n]: y Do you want me to install CentCore init script ? [y/n], default to [n]: y Do you want me to install CentCore run level ? [y/n], default to [n]: y Do you want me to create this directory ? [/var/lib/centreon/ centplugins] [y/n], default to [n]: y

Configuration de Centreon
La suite de linstallation passe par les pages web de Centreon, auxquelles on accde par lURL http://192.168.0.5/centreon/ Une fois la licence GPL v2 accepte, les pages de configuration commencent. Pour la page 3, les options entrer sont : Nagios user : nagios ; Nagios group : nagios ; Apache User : apache ; Apache Group : apache ; Nagios Version : 3.x ; Nagios configuration directory : /usr/local/nagios/etc/ ; Nagios plugins : /usr/local/nagios/libexec/ ; RRDTool binary : /usr/bin/rrdtool ; Les pages 4 et 5 vrifient que toutes les options de PHP sont correctement installes. Avec les paquetages que nous avons indiqus jusqu maintenant, il ne devrait y avoir aucun problme sur cette page. La page 6 sert configurer laccs la base de donnes. Deux nouvelles bases de donnes sont ncessaires pour Centreon : centreon : sert stocker les lments configurs par les administrateurs ; centstorage : sert stocker les donnes de performances avant leur intgration en base RRD.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

373

Les options configurer sont les suivantes : Root password : mot de passe root pour MySQL, vide sil na pas de mot de passe ; Centreon Database : nom de la base Centreon, indiquer centreon ; Centstorage Database : nom de la base Centstorage, mettre centstorage ; Database Password : un mot de passe pour laccs la base ; Database location : adresse du serveur MySQL, localhost pour la plupart des installations ; Centreon Web Interface location : adresse du serveur Centreon, habituellement localhost ; MySQL Client version : version de MySQL, ici >= 4.1. La page 7 vrifie la connectivit avec la base MySQL. La page 8 permet de configurer le compte administrateur de Centreon : Administrator login : nom du compte administrateur de Centreon, indiquer admin ; Centreon Administrator password : mot de passe de ladministrateur ; Firstname Administrator : prnom de ladministrateur ; Lastname Administrator : nom de ladministrateur ; Email : adresse e-mail de ladministrateur. La page 9 set configurer laccs une base Ldap pour Centreon. Nous ne lutiliserons pas ici. La page 10 permet de vrifier que Centreon a accs en criture /etc/centreon/. Il y gnre ses fichiers de configuration : pour Centreon :/etc/centreon/centreon.conf.php ; pour Centstorage :/etc/centreon/conf.pm. La page 11 sert installer les tables dans les bases centreon et centstorage. Une fois linstallation finie, on peut dmarrer les programmes
censtorage. centcore

et

Lancement de CentCore et CentStorage

/etc/init.d/centcore start /etc/init.d/centstorage start

On accde Centreon par lURL locale http://192.168.0.5/centreon/

374

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Mise en place de NagVis pour lagrgation de vues

La suite de linstallation passe par le module de visualisation avance, NagVis.

Installation de NagVis
La mise en place de NagVis est plus simple que celle de Centreon. La version que nous mettons en place est la version stable actuelle, la 1.3.2. On rcupre lapplication sur le site du projet, http://www.nagvis.org. Une fois larchive dpose sur le serveur, on la dcompresse :
Dcompression des sources de NagVis
tar xvfz nagvis-1.3.2.tar.gz mv nagvis-1.3.2 nagvis

NagVis utilise lapplication graphviz pour gnrer ses graphiques ainsi que la bibliothque mbstring de PHP.
Installation des pr-requis de NagVis
yum install graphviz graphviz-php php-mbstring

Linstallation de NagVis est simple : il suffit de dplacer son rpertoire dans la partie web de Nagios.
Installation de NagVis
mv nagvis /usr/local/nagios/share/

Configuration de NagVis
Le fichier de configuration de NagVis est nagvis.ini.php.
Mise en place de la configuration
cd /usr/local/nagios/share/nagvis cp etc/nagvis.ini.php-sample etc/nagvis.ini.php /usr/local/nagios/share/nagvis/etc/

Il faut lditer pour modifier laccs la base de donnes nagios par NagVis. La partie qui nous intresse pour linstant est le bloc backend_ndomy_1.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

375

Configuration de NagVis pour laccs la base MySQL

[backend_ndomy_1] ; type of backend - MUST be set backendtype="ndomy" ; hostname for NDO-db dbhost="localhost" ; portname for NDO-db dbport=3306 ; database-name for NDO-db dbname="nagios" ; username for NDO-db dbuser="nagios" ; password for NDO-db dbpass="superpass" ; prefix for tables in NDO-db dbprefix="nagios_" ; instace-name for tables in NDO-db dbinstancename="default" ; maximum delay of the NDO Database in Seconds maxtimewithoutupdate=180 ; path to the cgi-bin of this backend htmlcgi="/nagios/cgi-bin"

Configuration des droits sur NagVis

Une fois NagVis configur, nous positionnons les droits de lapplication afin que lutilisateur apache puisse accder aux informations et diter les cartes contenues dans /usr/local/nagios/share/nagvis/etc/maps.
Changement des droits
chown chmod chmod chmod chmod chmod chmod -R apache:apache /usr/local/nagios/share/nagvis/ 664 /usr/local/nagios/share/nagvis/etc/nagvis.ini.php 775 /usr/local/nagios/share/nagvis/nagvis/images/maps 664 /usr/local/nagios/share/nagvis/nagvis/images/maps/* 775 /usr/local/nagios/share/nagvis/etc/maps 664 /usr/local/nagios/share/nagvis/etc/maps/* 775 /usr/local/nagios/share/nagvis/var

Comme nous navons pour linstant pas dclar linterface de Nagios dans Apache, nous allons le faire. Cela demande simplement de copier le fichier sample-config/ httpd.conf dans le rpertoire conf.d dApache.

376

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Dclaration du site Nagios auprs dApache

cd ~/nagios-3.1.0/sample-config cp httpd.conf /etc/httpd/conf.d/nagios.conf /etc/init.d/httpd restart

Laccs aux pages de Nagios et utilisateur nagiosadmin :

Ajout dun utilisateur du site

NagVis

ncessite de sauthentifier. Nous ajoutons un

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

On accde linterface de configuration de NagVis par lURL locale :

http://192.168.0.5/nagios/nagvis/config.php

Mise en place de la base de connaissances

Un wiki comme gestionnaire de base de connaissance
Comme nous lavons vu, une base de connaissances contenant les descriptifs des tests effectus ainsi que les explications pour rsoudre les problmes fait partie intgrante dune solution de supervision. Si les administrateurs possdent dj une base de connaissances, ils peuvent tout naturellement lutiliser dans ce cadre. Dans le cas contraire, un wiki est tout fait adapt ce genre de situation. Nous allons mettre en place le plus clbre dentre eux, MediaWiki, qui est le moteur de Wikipedia.
DOCUMENTATION Aller plus loin sur MediaWiki
Ceux voulant pousser ltude de ce formidable outil quest MediaWiki peuvent consulter avec profit le livre MediaWiki efficace. R D. J. Barrett, MediaWiki Efficace Un wiki sur mesure la porte de tous, Eyrolles, 2009

Installation de MediaWiki
Linstallation de MediaWiki ressemble celle de toutes les applications web classiques. Le paquetage dinstallation se tlcharge sur le site du projet. Une fois larchive dpose sur le serveur, il suffit de la dcompresser dans /var/www/html.

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

377

Dcompression de MediaWiki
cp mediawiki-1.14.0.tar.gz /var/www/html cd /var/www/html tar xvfz mediawiki-1.14.0.tar.gz mv mediawiki-1.14.0 wiki chown -R apache:apache wiki

La suite de linstallation se passe par linterface web sur lURL http://192.168.0.5/ wiki. La page propose permet de gnrer la configuration du programme. Les champs intressants sont : Wiki name : nom donn au site, typiquement le nom de la socit ; Admin username : nom du compte administrateur du wiki, habituellement WikiAdmin ; Password : mot de passe du compte administrateur ; Database host : adresse du serveur de base de donnes ; Database : nom de la base de donnes ; DB username : nom de lutilisateur qui accde aux donnes ; DB password : mot de passe du compte daccs aux donnes ; Superuser name : compte administrateur de la base de donnes ; Superuser password : mot de passe de ladministrateur de la base ; Database table prefix : prfixe placer devant le nom des tables ; Storage Engine : moteur de MySQL utiliser pour la base de donnes, typiquement InnoDB. Une fois le formulaire rempli, le fichier config/ LocalSettings.php est cr : il contient toute la configuration de loutil. Il suffit de le placer la racine du site pour que lapplication soit disponible.
Finalisation de linstallation
mv config/LocalSettings.php .

Mise en place de la sauvegarde avec mysqldump

Lorsque nous voquons la mise en production dun nouvel outil, il est indispensable de se proccuper de sa sauvegarde. Chaque application a ses particularits en matire de sauvegarde : certaines peuvent tre sauvegardes chaud, dautres non.

378

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

REMARQUE Le retour de Murphy ?

Il est intressant de voir quel point ce sont les applications non sauvegardes qui on besoin de restauration. Cest peut tre un effet de notre chre loi de Murphy, ou bien reprsentatif du soin avec lequel un administrateur gre une application, au choix...

Si nous parlons dun Nagios pur, il ny a aucun problme pour le sauvegarder chaud avec un simple tar. Cest aussi le cas pour lapplication NagVis. Le point qui mrite un peu plus dattention concerne les bases Centreon et Nagios (NDO). Ces bases MySQL peuvent tre sauvegardes chaud, grce lapplication mysqldump. Elle ncessite un compte sur la base de donnes. Cette sauvegarde est cohrente si aucun utilisateur ne fait de modification dans la configuration sans lavoir valide.
PRATIQUE Sauvegardes nocturnes
Si la sauvegarde est lance 3h du matin, le risque quun administrateur soit en train deffectuer des modifications est plus faible...

Les fichiers sauvegards sont placs dans /backup/files, les fichiers journaux dans /backup/log. Ce premier script sauvegarde le rpertoire de Nagios et la base NDO.
/backup/bin/save_nagios.sh
#!/bin/sh LOG_NAGIOS=/backup/log/nagios_`date +%d%m%Y`.log SAVE_NAGIOS=/backup/files/nagios_$INSTANCE_NAME_`date+%d%m%Y`.tar.bz2 NAGIOS_DIR=/usr/local/nagios/ echo "Debut de la sauvegarde de nagios a"`date` | tee -a $LOG_NAGIOS cd $NAGIOS_DIR tar cvfj $SAVE_NAGIOS .| tee -a $LOG_NAGIOS echo "Backup de la base Nagios (ndo)" DATE=`date +'%Y%m%d'` cd /backup/files/ mysqldump -u nagios -psuperpass nagios | bzip2 -c > nagiosdb_${DATE}.dump.bz2 | tee -a $LOG_NAGIOS echo "Supprime les sauvegardes datant de plus de deux semaines" | tee a $LOG_NAGIOS

Compilation et installation de Nagios, Centreon et NagVis CHAPITRE 13

#On nettoie les ancien backups de plus de 14 jours find -mtime +14 -exec rm -f {} \; cd /backup/log/ find -mtime +14 -exec rm -f {} \; echo "Fin de la sauvegarde de Nagios a"`date` | tee -a $LOG_NAGIOS

379

Le second script sauvegarde les fichiers et des deux bases de Centreon.

/backup/bin/save_centreon.sh
#!/bin/sh LOG_CENTREON=/backup/log/centreon_`date +%d%m%Y`.log echo "Debut de la sauvegarde de Centreon a"`date` | tee -a $LOG_CENTREON echo "Dump de la base Centreon" | tee -a $LOG_CENTREON DATE=`date +'%Y%m%d'` cd /backup/files/ mysqldump -u root -psuperpass -databases centreon centstorage | bzip2 c > centreondb_${DATE}.dump.bz2 | tee -a $LOG_CENTREON echo "Dump des fichiers Centreon" | tee -a $LOG_CENTREON cd /usr/local/centreon tar cvfj /backup/files/centreon_${DATE}.bz2 . | tee -a $LOG_CENTREON echo "Fin de la sauvegarde de Centreon a"`date` | tee -a $LOG_CENTREON

La planification se fait par le biais de cron :

/etc/crontab
# Sauvegardes 00 3 * * * root /backup/bin/save_nagios.sh 00 3 * * * root /backup/bin/save_centreon.sh

On recharge cron laide de la commande :

/etc/init.d/cron reload

Ces scripts peuvent tre amliors pour contrler le rsultat des commandes tar et mysqldump. Ils pourraient prvenir Nagios, de manire passive, du bon droulement ou non de la sauvegarde.

380

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

PRATIQUE Une mise en place prcoce

Nombreux sont les cueils de configuration que rencontrent les administrateurs Nagios leurs dbuts. Il est conseill de planifier des sauvegardes trs frquentes. Un test de restauration avant de rentrer toutes les machines du parc informatique nest pas superflu non plus. Si le test choue, il y aura moins de pertes.

En un mot
Ladministrateur a mis en place ses outils. Avant de procder la configuration effective des lments superviser, il est important de se pencher sur les principaux indicateurs disponibles sur les systmes. Ladministrateur ayant dj les informations sur ce quil est possible de superviser ou non, il sera plus mme daider les autres dans leurs demandes de supervision en vue de la mise en place finale de la solution. Cest lobjet du chapitre suivant.

14
Aide linterprtation des indicateurs classiques
Les possibilits de supervision offertes par Nagios sont trs importantes. Voyons quels sont les indicateurs les plus utiles et comment les administrateurs doivent les interprter.

Obtention des indicateurs

La supervision est base sur la lecture dindicateurs. Regardons comment les sondes les obtiennent.

Sur les systmes Linux

Lobtention des informations sous un systme Linux est trs simple. Le noyau expose ses informations travers un systme de fichiers un peu particulier, procfs. Celui-ci est mont sous le rpertoire /proc. Les fichiers disponibles ne sont pas tous accessibles nimporte quel utilisateur. Les informations disponibles peuvent tre globales au systme ou concerner un processus particulier.

382

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Ces fichiers nexistent sur aucun disque physique. Ils sont uniquement situs en mmoire. Il suffit de les lire pour obtenir les informations, que le systme gnre la vole. Il est possible dcrire dans certains fichiers, mais cette possibilit nest pas utilise dans le cadre de la supervision.

Informations globales
Les informations globales concernant ltat du systme sont varies. Par exemple, le fichier /proc/meminfo est une vritable mine dinformations sur ltat de la mmoire. En voici un court extrait :
/proc/meminfo
MemTotal: MemFree: Buffers: Cached: 2073936 156012 71108 906720 kB kB kB kB

Ce fichier est accessible tous les utilisateurs du systme. Dautres sont rservs lutilisateur root. Par exemple, le fichier /proc/kcore est un accs direct la mmoire du noyau. Ce type de fichier nest, en rgle gnrale, pas utile dans la supervision.

Informations relatives aux processus

Les processus ont, quant eux, un rpertoire qui leur est ddi. Il sagit tout simplement de /proc/PID, o PID est lidentifiant du processus concern. Ce rpertoire contient des informations sur les ressources consommes par le processus. Il nest lisible que par lutilisateur qui a lanc le processus. Le fichier /proc/PID/status permet dobtenir les informations sur ltat dun processus. Nous pouvons, par exemple, savoir si un processus est en tat zombie ou non. Les fichiers /proc/PID/ stat et /proc/PID/statm permettent dobtenir des informations propos de la consommation de ressources du processus.

Analyse des informations

Ces fichiers ne sont, en gnral, pas simples lire. Ce sont des valeurs brutes sans autre indication. Ils diffrent selon les versions du noyau. De nombreux outils les parcourent pour prsenter plus lisiblement ces informations. Les administrateurs les utilisent tous les jours. Parfois ils ne savent pas trs bien do viennent leurs informations. Ces commandes sont ps, top et netstat, pour les plus connues. Ces commandes analysent les fichiers du rpertoire /proc et en tirent les informations souhaites. Il nest pas intressant de refaire ce travail. Ces outils grent les diffrentes versions des fichiers et sortent un rsultat constant. Leur utilisation peut

Aide linterprtation des indicateurs classiques CHAPITRE 14

383

faire gagner beaucoup de temps dans lobtention dinformations de supervision et de mtrologie.

DOCUMENTATION Un ouvrage sur /proc
R Ceux qui souhaitent pousser ltude de /proc peuvent se tourner vers le livre /proc et /sys dOlivier

Daudel aux ditions OReilly.

Un simple appel ps dresse la liste des processus dun utilisateur avec les informations choisies. Par exemple, imaginons que nous souhaitions obtenir les informations suivantes sur lensemble des processus du systme : PID : numro de processus ; ARGS : commande lance avec les arguments ; RSS : taille de la mmoire rsidente du processus ; %CPU : pourcentage de CPU utilis. Il suffit de lancer la commande suivante :
ps -eo pid,args,rss,%cpu

Voici un extrait du rsultat :

Visualisation des processus du systme
24398 25047 25103 25116 25125 26260 26291 28106 28107 28109 28110 /usr/local/nagios/bin/ndo2d 488 0.0 /usr/sbin/httpd 47512 5.8 /usr/sbin/httpd 49680 5.9 /usr/sbin/httpd 74720 5.7 /usr/sbin/httpd 46596 5.8 sshd: nagios@pts/1 1860 0.0 -bash 1520 0.0 /usr/local/nagios/bin/nagio 10856 0.0 /usr/bin/perl -w /usr/local 8384 1.5 /usr/local/nagios/bin/nagio 10856 0.0 /usr/bin/perl -w /usr/local 8380 10.0

Nous remarquons que les processus httpd sont consommateurs despace mmoire et de ressources CPU. Cette information peut tre utile dans la supervision. En ce qui concerne les informations rseau, la commande netstat permet davoir un suivi prcis de ltat des connexions. Elle permet dobtenir, travers lutilisation du fichier /proc/net/netstat, la consommation des ressources rseau et, par /proc/ net/tcp et /proc/net/udp, la liste des connexions actuellement en cours.

384

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Tout comme les fichiers associs aux processus, ils sont difficilement comprhensibles. La commande netstat est chaudement recommande. Il peut tre utile de suivre le nombre de connexions ouvertes ou le nombre de paquets envoys et reus sur le rseau. Nous allons prsenter les informations importantes superviser sur les systmes Linux dans ce chapitre. Si les fichiers /proc originaux seront voqus, les sondes utilisent principalement les commandes comme ps ou netstat.

Sur les systmes Windows

Dans le chapitre 4, nous avons voqu les tables WMI. Elles permettent daccder, avec une syntaxe proche du SQL, aux informations des systmes Windows et des quelques logiciels compatibles. La mthode daccs aux informations a t prsente prcdemment, et nous ny reviendrons pas. Les tables intressantes pour la supervision et la mtrologie seront numres dans la suite de ce chapitre.

Lexistence dun indicateur de charge globale

Commenons notre tude des indicateurs par le rve de tout administrateur : un indicateur de charge globale.

Une question rcurrente

Si une question trotte dans la tte des administrateurs, cest bien celle-ci : ses serveurs sont-ils (trop) chargs ? Pour y rpondre, il doit trouver un moyen dobserver la charge des machines. Le besoin de dfinir un seuil de surcharge apparat alors. Les administrateurs doivent grer un nombre trs important de machines. Ils ont besoin de tailler au plus juste les environnements. Pour cela, lobservation de la charge des anciennes machines peut se rvler plus quutile.
DANS LA VRAIE VIE Le bon administrateur doit tre paresseux
Il ne faut pas oublier que les administrateurs sont des informaticiens. Or, un bon informaticien est fainant et les administrateurs sont gnralement de bons informaticiens. Ils souhaitent obtenir linformation de charge par un seul indicateur qui permette de dterminer si une machine est surcharge ou non.

Aide linterprtation des indicateurs classiques CHAPITRE 14

385

Ce sont les ressources dune machine surcharge qui nous intressent tout particulirement ici. Dans cette machine, de nombreux lments peuvent tre sur-sollicits. Les plus importants sont les suivants : CPU ; RAM ; disques durs ; interfaces rseau. Traitons tout de suite le cas de la RAM. Lorsquune machine nen a pas assez, elle utilise les espaces dchanges. Ceux-ci sont situs sur les disques durs. Dans ce cas, la ressource bloquante est le disque. On ne donne donc pour la RAM que deux tats : il y en a assez, ou non. Elle nest pas prise en compte dans lindicateur global car elle est contenue dans les disques durs lorsquelle ne suffit pas. Lorsquune machine narrive pas traiter les informations assez rapidement, les files dattente des traitements augmentent. Les traitements sont les processus. Lindicateur qui nous intresse est la file dattente des processus. Les Unixiens pensent immdiatement au load average. Ci-aprs, un rapide rappel sur cet indicateur de charge moyenne pour ceux qui nont pas pris lunixien en premire langue.

Dfinition de la charge moyenne, ou load average

De nombreux mythes et lgendes entourent cet indicateur. Par exemple, certains affirment quil doit tre infrieur 1, dautres quil ne doit pas dpasser le nombre de CPU physiques. Cela ntant pas totalement vrai, il est conseill aux administrateurs mme les plus aguerris de lire la suite.
REMARQUE Des load average similaires sous Unix/Linux
Cette section traite du cas du load average sous Linux. Il hrite de la dfinition et du comportement communs tous les Unix. Les informations fournies ici peuvent tre gnralises sur lensemble des Unix. Les systmes Windows ne disposent malheureusement pas de cet indicateur en standard.

Compos de trois chiffres, le load average est disponible par les commandes uptime ou top, ainsi que dans le fichier /proc/loadavg. Les trois chiffres du load average reprsentent le nombre moyen (au sens dune moyenne pondre sur le temps) de processus en tat dexcution ou en attente dune ressource au cours des dernires 1, 5 et 15 minutes. Cette dfinition ntant pas particulirement triviale, tudions-la morceau par morceau.

386

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Processus pris en compte

Tout dabord, faisons un rapide rappel sur les tats dun processus. Pour simplifier, ils peuvent tre en tat dexcution, en attente dune ressource ou bien ne rien faire. Seuls les deux premiers sont considrs dans le calcul du load average. Le noyau compte rgulirement ces processus et met jour les moyennes. Ce relev est effectu toutes les cinq secondes. Lhorloge du systme est cadence une frquence HZ dfinie dans le noyau : son quantum de temps correspond donc 1/HZ secondes. Dans un environnement moderne, HZ est dfini 100 hertz. Par consquent, pour que le relev ait lieu toutes les cinq secondes, il est effectu tous les 5xHZ intervalles, soit 5xHZ/HZ = 5 secondes.
PIGE Les architectures tickless
Certains vont se demander comment un tel intervalle peut tre dfini sur les architectures tickless. Ces dernires ont comme particularit de ne pas dfinir de temps systme rguliers mais de se rveiller quand le systme a quelque chose faire. Elles nont pas de valeur dfinie pour HZ. Dans ce cas, le systme fournit le temps coul depuis la dernire mesure la fonction qui dtermine si une mise jour des moyennes est ncessaire. Quand ce temps dpasse cinq secondes, le calcul est effectu.

Le noyau obtient le nombre de processus compter travers la fonction nr_active disponible dans le fichier kernel/sched.c du noyau Linux. Voici un extrait de cette fonction :
Fonction du noyaux Linux qui compte le nombre de processus pour la charge
unsigned long nr_active(void) { unsigned long i, running = 0, uninterruptible = 0; for_each_online_cpu(i) { running += cpu_rq(i)->nr_running; uninterruptible += cpu_rq(i)->nr_uninterruptible; } [...] return running + uninterruptible; }

Les processus qui sexcutent (cpu_rq(i)->nr_running) et ceux qui attendent une ressource (cpu_rq(i)->nr_uninterruptible) sont pris en compte. Nous avons ainsi dfini la liste des processus pris en compte. Voyons maintenant le calcul des moyennes proprement parler.

Aide linterprtation des indicateurs classiques CHAPITRE 14

387

Moyennes exponentielles
REMARQUE Pertinence de ltude
Cette partie nest pas indispensable aux administrateurs pour interprter le load average. Elle permet cependant de mieux comprendre son volution au cours du temps. Les administrateurs allergiques aux mathmatiques peuvent sauter cette partie. Cest cependant dommage car elle montre quel point elles pourraient les aider dans la vie de tous les jours.

Nous avons voqu que les moyennes sont pondres sur le temps. Les valeurs prises en compte lors des derniers relevs doivent avoir un poids plus fort dans la moyenne que les anciennes valeurs. La dcroissance des poids est une exponentielle dcroissante. Ce calcul se trouve dans le fichier kernel/timer.c de Linux. La fonction en question est calc_load.
Calcul du load average
void calc_load(unsigned long ticks) { unsigned long active_tasks; static int count = LOAD_FREQ; count -= ticks; if (unlikely(count < 0)) { active_tasks = count_active_tasks(); do { CALC_LOAD(avenrun[0], EXP_1, active_tasks); CALC_LOAD(avenrun[1], EXP_5, active_tasks); CALC_LOAD(avenrun[2], EXP_15, active_tasks); count += LOAD_FREQ; } while (count < 0); } } }

La valeur count permet de savoir quand faire le calcul. Elle est infrieure ou gale zro toutes les 5 secondes. Aprs le calcul, elle est rinitialise. La mise jour des valeurs de charge a lieu dans la macro CALC_LOAD. Voici les macros impliques dans ce calcul. Elles sont dfinies dans kernel/timer.h.
Macros utilises dans le calcul
#define #define #define #define FSHIFT 11 /* nr of bits of precision */ FIXED_1 (1<<FSHIFT) /* 1.0 as fixed-point */ LOAD_FREQ (5*HZ+1) /* 5 sec intervals */ EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */

388

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

#define EXP_5 2014 /* 1/exp(5sec/5min) */ #define EXP_15 2037 /* 1/exp(5sec/15min) */ #define CALC_LOAD(load,exp,n) \ load *= exp; \ load += n*(FIXED_1-exp); \ load >>= FSHIFT;

La valeur FSHIFT permet de dfinir la prcision des calculs. LOAD_FREQ sert positionner lintervalle de 5 secondes. Les valeurs EXP_* sont, pour linstant, un peu mystrieuses. La macro CALC_LOAD calcule la charge linstant t, dans le cas de la charge sur une minute, par :

Cest en fait la dfinition mathmatique dune moyenne mobile exponentielle. Pour la comprendre, transformons-la un peu. FIXED_1 est le chiffre 1.0 reprsent en notation virgule fixe. Cette notation permet dexprimer un nombre qui possde un nombre fixe de chiffres aprs la virgule, ici 11. Le dcalage binaire vers la droite >> de 11 chiffres quivaut une division par 211, soit FIXED_1. Une fois la formule transforme, nous obtenons :

Pour rappel, la valeur n est le nombre de processus travaillant lors de la mesure. La charge est gale ce nombre de processus, auquel nous ajoutons une valeur. Si la valeur n est plus grande que lancienne charge, alors load(t-1)-n est ngatif et la charge calcule pour linstant t est gale au nombre de processus qui travaillent, moins une valeur. Si le nombre de processus qui travaillent est infrieur lancienne charge, alors load(t-1)-n est positif et la charge calcule est gale au nombre de processus auquel on ajoute une valeur. La figure 14-1 montre un exemple dvolution de la courbe pour chacun des cas :
Figure 141

Calcul de lvolution du load average

Aide linterprtation des indicateurs classiques CHAPITRE 14

389

Cette valeur que nous ajoutons ou soustrayons est un multiple de EXP_1/FIXED_1. FIXED_1 est gal 2^11=2048. EXP_1 vaut, daprs le code, 1884. Cest la reprsentation en virgule fixe de 1/exp(5/60). Cette valeur provient de la dfinition de la moyenne mobile exponentielle. Elle prend en compte la priode des mesures. Dans le cas de la minute, elle est gale 5/60. Que ce soit pour 1, 5 ou 15 minutes, la valeur est toujours infrieure reprsentation en virgule fixe de EXP_K est calcule comme suit:
FIXED_1.

La

Nous avons alors :

Si nous augmentons K, nous tendons vers

sans jamais latteindre. Le facteur EXP_1/FIXED_1 est toujours infrieur 1. Voici ce quil vaut pour 1,5 et 15 minutes : EXP_1/FIXED_1 = 0,919 ; EXP_5/FIXED_1 = 0,983 ; EXP_15/FIXED_1 = 0,994. Ce facteur reprsente le poids du pass pour le calcul de la charge. Plus nous nous basons sur de longues priodes, plus il est important. Cela signifie que la valeur la minute a une volatilit plus importante que celle 15 minutes par exemple. Si nous calculons les valeurs de charge sur plusieurs priodes, les facteurs se multiplient sur les valeurs les plus anciennes. Cela donne son allure dexponentielle la courbe. Pour trois relevs conscutifs, si nous posons

le calcul suivant est effectu pour la dernire valeur :

Les valeurs du pass ont un coefficient Q une puissance gale leur ge. Ce coefficient tant infrieur 1, cela donne une allure exponentielle la courbe. Si n est stable sur une longue priode, la valeur de load(t-1)-n diminue de plus en plus au fil des calculs. La charge tend vers n.

390

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Exemples de courbes
Prenons un cas simple pour notre exemple. La machine considre possde deux curs. Seuls les processus consommant de la ressource CPU sont considrs. Deux de ces processus sont lancs t=0s. t=900s, ils sont arrts. La courbe de la figure 14-2 reprsente lvolution des trois composantes du load average.
Figure 142

volution du load average

Nous retrouvons bien les courbes exponentielles voques ci-dessus. Les courbes tendent, chacune leur rythme, vers la valeur 2 lors de la phase de consommation de ressources. La valeur la minute est bien plus rapide arriver cette limite que celle 15 minutes. Le mme phnomne est prsent dans la phase descendante, lorsque les valeurs tendent vers 0. Si nous savons dsormais tout ce quil y a savoir sur le calcul du load average, cela ne nous claire pas encore sur la manire de linterprter.

Reprsentation visuelle du load average

Pour faciliter lanalyse de cet indicateur, il peut tre pratique de se le reprsenter. Pour cela, nous repartons des trois ressources que peuvent consommer les processus, savoir les processeurs, les disques durs et le rseau. Un mme processus ne peut en consommer plusieurs la fois. Une reprsentation possible du systme est celle dun entonnoir.

Aide linterprtation des indicateurs classiques CHAPITRE 14

391

Celui-ci est dun type un peu particulier. Il possde autant de tuyaux de sortie que de ressources. Les processus y entrant sont obligs de faire la queue devant la sortie quils souhaitent utiliser. Ils peuvent tre en tat dattente ou en cours de consommation de la ressource. Les processus sont reprsents comme un nombre moyen de processus cette position. Dans le cas dune machine avec un processeur deux curs, un disque, une interface rseau et ayant en moyenne trois processus consommant un cur, le systme peut tre reprsent comme en figure 14-3.
Figure 143

Reprsentation des files dattente des ressources

Le load average est simplement la moyenne pondre sur le temps du nombre de processus prsents dans le diagramme. tudions quelques cas reprsentatifs afin dobserver la charge des machines dans diverses situations.

Systmes typiques
Systme sous-dimensionn
Dans lexemple de la figure 14-3, le load average tend vers trois. Deux processus sont en moyenne en train de consommer les ressources CPU et un est en attente de pouvoir le faire. Nous nous retrouvons face une situation de contention au niveau des processeurs. Le systme mriterait davoir un cur dexcution en plus. Le load average est de trois, pour quatre ressources au total, ou deux si lon considre uniquement les processeurs. Une interprtation possible du load average concernant les processus consommant uniquement des processeurs est quil doit tre infrieur au nombre de ressources disponibles. Dans le cas contraire, il y a des contentions. Cest en gnral le cas. Il existe cependant une situation o cette affirmation est errone. Par exemple, imaginons que le processus qui attend possde une priorit

392

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

plus basse que les deux autres. Ladministrateur a jug que le temps de calcul de ce processus ntait pas important. Sil ne cause pas de souci aux autres, est-ce rellement grave davoir une contention ce niveau ? Cela dpend des attentes de ladministrateur concernant ce processus.

Systme bien dimensionn

Prenons dsormais une situation moins charge que la prcdente. La ressource processeur nest consomme qu moiti. En moyenne, un processus est en train dtre excut (voir figure 14-4).
Figure 144

Files dattente sur un systme bien dimensionn

Il ny a, a priori, pas de contention. Le load average est de 1. Nous pourrions considrer que cette machine est bien dimensionne et que ses ressources CPU sont utilises hauteur de 50%. Cest oublier un peu vite que le load average est une moyenne temporelle. Les processus illustrs ici sont une moyenne. Deux cas font surface : un processus unique a consomm toute une ressource CPU sur la dure tudie ; une myriade de processus ont travaill de temps en temps et consomm en moyenne le CPU compltement. Dans le premier cas, le processus gagnerait srement disposer dun processeur plus puissant. Dans le second, aucun processus na consomm toute une ressource. Le CPU est utilis 50%. Le fait de savoir si cela est suffisant sera discut un peu plus loin dans ce chapitre. Le load average est le mme dans ces deux situations mais son interprtation est compltement diffrente. Les applications fonctionnant sur le systme semblent avoir leur importance. Continuons notre analyse afin de comprendre cela.

Aide linterprtation des indicateurs classiques CHAPITRE 14

393

Systme sur-dimensionn ?
Notre prochain systme a en moyenne un quart de cur de consomm ainsi quun quart dune ressource disque. Cela est illustr sur la figure 14-5.
Figure 145

Files dattente sur un systme sur-dimensionn

Le load average est de +=0,5. Aucun processus ne peut avoir consomm la totalit dune ressource. Cette situation semble idyllique. Elle a un got de systme surdimensionn : les utilisateurs de cette machine doivent tre ravis. Le load average infrieur 1 semble synonyme de charge tout fait acceptable. Ce nest malheureusement pas forcment le cas.

Changement de point de vue

Nous nous tions placs dans la peau dun administrateur jusquici. Plaons-nous dsormais dans la peau des utilisateurs. Les machines qui soutiennent des applications leur tant ddies, il est important de ne pas oublier cet objectif dans notre analyse de la charge.

Analyse contradictoire
Reprenons deux analyses prcdentes depuis notre nouveau point de vue : load average 1 o un processus consomme un cur continuellement ; load average 0.5 o une partie des processeurs et des I/O disque sont consommes. Du point de vue de ladministrateur, la premire situation est un cas de processeur surcharg, la seconde un cas o tout va bien. Suivant les applications, les utilisateurs peuvent ne pas avoir le mme avis. Dans le premier cas, prenons lexemple dune application qui consomme toute une ressource CPU, quelle que soit la puissance dont elle dispose. Un jeu appartient ce type de programmes. Sil nest pas limit en nombre dimages par seconde gnrer,

394

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

il consomme toute une ressource CPU. Suivant la vitesse du processeur, le jeu peut tourner plus ou moins de 60 images par seconde. Au-dessus de ce seuil, les joueurs ne ressentent pas la diffrence. En-dessous, le jeu nest pas fluide. La charge machine est toujours de 1 dans les deux cas. Du point de vue des utilisateurs, les ressentis de charge ne sont pas les mmes. Une relation charge/application semble se profiler. Regardons sur le second cas si cest bien le cas dans une situation quun administrateur qualifie de non charge. Considrons quun processus est responsable de la charge de 0.5. Ceci signifie quil a travaill approximativement la moiti du temps. Cela est une moyenne. Il a trs bien pu travailler 30 secondes daffile. Un utilisateur a trs bien pu aussi demander 60 pages web, chacune demandant 0,5 seconde de travail pour safficher. Dans le premier cas, lutilisateur peut ntre pas totalement satisfait. Il a presque le temps daller prendre un expresso pendant le traitement. Dans le second, aucune page nayant mis plus dune demi-seconde arriver, il est pleinement satisfait.
REMARQUE Une fcheuse manie
Si lutilisateur nest pas friand de cafine, il peut remplacer le caf par un coup de tlphone pour se plaindre auprs des administrateurs. Ce genre de situation est viter tout prix.

La relation charge/application est relle. Une mme charge nest pas interprte de la mme manire suivant les applications fonctionnant sur la machine.

Attentes des utilisateurs

Certaines applications sont reconnues par les utilisateurs comme nayant pas besoin de temps de rponse particulirement rapides. Les applications de reporting en font partie. Dautres, au contraire, ne sont utilisables qu partir dun certain seuil de performances. Les jeux en sont le meilleur exemple. Si le nombre dimages par seconde nest pas suffisant, cest injouable. Ces attentes des utilisateurs peuvent galement varier suivant la priode. Un utilisateur du ple financier nest pas aussi patient pendant une priode de clture comptable quen-dehors. Obtenir les informations de temps de rponses acceptables de la part des utilisateurs est trs important. Lidal consiste pouvoir tester ces indicateurs sur un scnario applicatif et les comparer aux souhaits des utilisateurs.

Aide linterprtation des indicateurs classiques CHAPITRE 14

395

Une analyse variable de la charge

Le load average a-t-il perdu toute son utilit ? Non. Les scnarios applicatifs ne sont pas toujours ralisables. Les informations de temps de rponse acceptables sont une denre extrmement rare de la part des utilisateurs. Sils connaissent bien les applications fonctionnant sur leurs machines, les administrateurs peuvent exploiter des retours des utilisateurs propos de temps de rponse trop lents. Corrls avec le load average, ces retours leur permettent de dfinir le seuil de charge acceptable pour une machine donne. types dapplications et machines quivalents, il est possible dutiliser ce seuil sur dautres serveurs. Ces seuils ne sont pas fixes et il nexiste pas de mthode miracle pour les dfinir. Lindicateur de load average est galement utile pour observer lvolution de la charge sur une mme machine au cours du temps. Il est le compagnon idal de ladministrateur. Il est une trs bonne moyenne de charge, mais qui dit moyenne dit perte de donnes. Cest pourquoi il est galement indispensable de suivre la consommation des diffrentes ressources. Le load average peut alerter dun problme de charge globale. Reste ensuite trouver la ressource limitative.

Deux indicateurs valent mieux quun

Le mythe de lindicateur global tant tomb, voyons si nous pouvons tirer dautres informations de notre tude du load average.

Limites du load average considr seul

Nous venons de voir que le load average tait principalement constitu des attentes processeur et des attentes dentres/sorties, comme celles des disques. Lorsquun administrateur cherche amliorer une situation, il peut jouer sur ces deux facteurs. Les processeurs se remplacent, et les accs disques samliorent en ajoutant du cache. Le load average tant une moyenne des deux, ladministrateur ne peut pas lutiliser pour savoir quoi amliorer. Sur les systmes Linux, on peut distinguer les deux composantes du load average : processeurs ; ressources bloquantes (disques).

Analyse du load average

Obtention de linformation Sous Linux, le noyau exporte le fichier tout particulirement :
/proc/stat

o deux lignes nous intressent

396

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Lecture du fichier /proc/stat

[...] procs_running 3 procs_blocked 0

La ligne procs_running indique le nombre de processus en tat running ou en attente de processeur. La seconde indique le nombre de processus en attente dentre/sortie. Ce sont les deux composantes du load average. Il est intressant de remarquer que la premire ligne ne peut pas tre zro. Le processus qui effectue la lecture consommant du temps processeur, il faut retirer 1 cette valeur afin davoir le nombre rel de processus qui travaillent. Calcul des moyennes exponentielles Si le noyau fournit la moyenne exponentielle de la charge totale dans /proc/loadavg, il neffectue pas ce calcul pour ces deux composantes. Nous devons faire appel un dmon qui calcule cette moyenne et exporte cette valeur pour lutilisateur. Votre serviteur a crit un tel dmon sous licence GPL v2. Il se nomme advanced load average et se prsente sous la forme dun script Python. Il permet dagrger dautres donnes que celle des composantes du load average. Nous en reparlerons par la suite.
REMARQUE Un outil qui tombe pic
Comme peut se douter le lecteur, cet outil est le rsultat de lanalyse du fonctionnement du load average.

Son lancement est fort simple :

Lancement davanced load average
/usr/local/nagios/bin/advLoadAvgd.py -c /usr/local/nagios/etc/ advLoadAvgd.cfg

Il exporte par dfaut ses fichiers de rsultats dans /dev/shm. Celui qui nous intresse pour linstant est /dev/shm/advLoadAvg_component.dat.
/dev/shm/advLoadAvg_component.dat
0.28 0.58 0.74 0.54 0.47 0.44

Les trois premires valeurs sont la charge CPU 1, 5 et 15 minutes. Les trois dernires sont la charge I/O 1, 5 et 15 minutes. Le load average tait :
Load average
0.84, 1.03, 1.17

Aide linterprtation des indicateurs classiques CHAPITRE 14

397

Nous retrouvons : 0.84 ~ 0.28 + 0.54 1.03 ~ 0.58 + 0.47 1.17 ~ 0.74 + 0.44 Les sont dues aux calculs de moyennes. La sonde check_load_component permet denvoyer ces donnes Nagios et de vrifier que le dmon fonctionne toujours bien.
check_load_component.py -c /usr/local/nagios/etc/advLoadAvgd.cfg OK daemon is UP | LoadCpu1=0,28 LoadCpu5=0.58 LoadCpu15=0.74 LoadIo1=0.54 LoadIo5=0.47 LoadIo15=0.44

approximations

Exemples de mesures Si nous traons les courbes de charge 15 minutes de nos deux nouveaux indicateurs, nous obtenons un graphique similaire celui de la figure 14-6.
Figure 146

Trac des charges CPU et I/O sur une semaine

La courbe du load average pour la mme priode est reprsente en figure 14-7.
Figure 147

Trac du load average

398

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

La courbe du load average est bien la somme des deux premires courbes, LoadCpu15 et LoadIo15. Avec le premier trac, ladministrateur sait quel gain il peut retirer de lamlioration des processeurs ou des entres/sorties. Dans le cas prsent, les amliorations des accs disques sont privilgier pour avoir les meilleurs gains. La machine ayant dj 8 processeurs physiques et une charge CPU 2, en ajouter ne servirait rien Ladministrateur pourrait aussi obtenir une courbe comme celle de la figure 14-8.
Figure 148

Trac des charges CPU et I/O

Dans ce cas, lamlioration des disques ne servirait rien. Suivant le nombre de processeurs que possde la machine, il peut tre intressant den ajouter. Ici, la machine en possde 4, il ny a aucun intrt en ajouter. tant des moyennes, ces valeurs subissent les mmes inconvnients que le load average. Elles ncessitent dautres indicateurs et lexprience des administrateurs pour pouvoir en tirer toutes les informations ncessaires.

Charge des processeurs

Lorsquon parle de systme charg, on pense immdiatement aux processeurs.

Un indicateur important
Les processeurs sont, dans lesprit de tout un chacun, la premire ressource des machines. Si, dans de nombreuses situations, les disques sont bien plus limitatifs, il est important de garder un contrle sur leur utilisation. Celle-ci nest pas constante. Un processeur na que deux tats : il travaille ou il ne travaille pas. Lorsque nous parlons de pourcentage dutilisation, il est question dune moyenne des tats sur une certaine dure.

Aide linterprtation des indicateurs classiques CHAPITRE 14

399

Les courbes de consommation de CPU sont, par dfinition, trs variables. Un processeur inactif linstant t peut tre surcharg t+1. Si la charge est ponctuelle, cela ne porte pas consquence, cest une variation normale pour cet indicateur. Si la charge est constante sur une dure plus longue, nous avons probablement affaire une contention. Cet aspect de volatilit de lindicateur a un impact sur le paramtrage des services le surveillant. Le relev de lindicateur se fait un instant t. Lindicateur dutilisation du CPU nest pas une moyenne temporelle comme le load average. Il est important de dfinir plusieurs vrifications de charge avant davertir les administrateurs. Si la charge est passagre, il ny a pas de problme. Si, aprs plusieurs tests, elle est toujours leve, un envoi dalerte est ncessaire. Cela se configure par le biais des paramtres max_check_attempts et retry_interval. Une dure de charge de 15 minutes est acceptable avant de lancer une notification.
REMARQUE Seuil variable
Cette dure est variable suivant les environnements et surtout les utilisateurs concerns.

Plusieurs types de charge CPU

La consommation des processeurs peut se faire plusieurs niveaux : un processus utilisateur ; le noyau du systme. Suivant la source de la consommation, la rsolution du problme nest pas la mme. Dans le cas dune application, une consommation excessive de temps de calcul est observable, par exemple, avec les commandes top ou ps sous Linux. Une fois lapplication fautive identifie, reste la modifier pour quelle ne recommence pas. Le cas de lutilisation par le noyau est bien plus complexe grer. Ceci signifie quune partie du temps de calcul se passe en mode noyau. Cela peut tre d au code du noyau qui sexcute, mais cela narrive que trs rarement. Les noyaux sont crits avec une trs grande rigueur et cherchent passer inaperus dans la charge de la machine. Ils y arrivent gnralement trs bien. Ils doivent grer les demandes des processus comme les accs aux disques ou le lancement de nouveaux processus. Ces actions se passent en mode noyau. Le temps pass les raliser est dcompt sur le temps systme. De trop nombreux accs disques sont caractriss par un temps dutilisation du noyau important.

400

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Rcupration effective de la charge CPU

Sous les Unix
La commande vmstat permet dobtenir les diffrents pourcentages dutilisation de chaque type dutilisation du processeur. Elle cherche ses informations dans le fichier /proc/stat. La sonde check_cpu y fait appel :
check_cpu
check_cpu -w 90 -c 95 OK: CPU is 38% full | cpu=38% idle=62% user=20% sys=18%

Le dmon advanced load average exporte les moyennes de ces composantes dans le fichier /dev/advLoadAvg_cpu.dat qui est lu par la sonde check_load_cpu.py. Ces mesures permettent de lisser les courbes pour une meilleure analyse de mtrologie.

Sous Windows
Interrogation WMI directe Sous Windows, linformation de lutilisation des processeurs est disponible dans la table WMI Win32_Processor. Chaque processeur a un identifiant. Il existe un indicateur supplmentaire qui fait une moyenne de la charge des autres. Le pourcentage dutilisation est contenu dans le champ LoadPercentage. Voici un exemple dinterrogation qui rcupre le pourcentage dutilisation des processeurs :
Rcupration de la charge processeur en WMI
SELECT LoadPercentage FROM Win32_Processor

Voici un exemple de rsultat sur une machine deux curs qui en a un dutilis pleinement :
DeviceID=CPU0:LoadPercentage=0 DeviceID=CPU1:LoadPercentage=100

Utilisation de NSClient++ Si ladministrateur a la bonne ide dutiliser lagent NSClient++, celui-ci propose une valeur moyenne de lutilisation des CPU sur une certaine dure. Par exemple, si lutilisation moyenne sur cinq minutes intresse ladministrateur, il peut utiliser la commande suivante :

Aide linterprtation des indicateurs classiques CHAPITRE 14

401

Rcupration de la charge processeur par NSClient++

check_nt -H serveur -v CPULOAD -l5,70,90 CPU Load 9% (5 min average)

Il est alert si la valeur dpasse 70 ou 90% suivant le niveau de criticit choisie. Cela permet de ne pas avoir positionner de paramtres retry_interval cause de la volatilit de lutilisation CPU. Une valeur de 5 minutes est trop courte pour justifier une leve dalerte. Il est conseill dutiliser une moyenne de lordre du quart dheure la place. Les diffrents temps CPU Le cas trait pour linstant est celui de la charge globale des processeurs. Il nest pas fait mention de la rpartition du temps consomm. Le systme Windows propose des indicateurs assez prcis sur la source de la charge. Ces informations sont disponibles dans la table Win32_PerfFormattedData_PerfOS_Processor. Les champs utiliss sont : PercentDPCTime : temps pass sur lactivit rseau. Une valeur suprieure 50% montre un problme ; PercentPrivilegedTime : temps pass sur lactivit des disques. Une valeur suprieure 20% montre un problme. Il peut tre utile dalerter les administrateurs si ces seuils sont franchis. Il est important davoir une documentation claire sur ces indicateurs. Leur nom est en effet assez peu parlant et un administrateur recevant une alerte pourrait ne pas prendre la peine den rechercher la signification.

Superviser la mmoire
La mmoire est lune des ressources qui revient le moins cher sur les environnements actuels. Il est tout de mme important de la surveiller.

Un indicateur un peu particulier

Il est possible, grce la mtrologie, de reprer des machines ne consommant pas toute la mmoire dont elles disposent et de laffecter dautres qui en manquent cruellement. Il est trs courant de voir un jeu de chaises musicales dans les machines peu de temps aprs la mise en place de la supervision. La RAM a t mise de ct lors de ltude de la charge machine. Les ralentissements dus un nombre daccs mmoire important sont observables dans le temps CPU. Si

402

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

le systme commence manquer despace RAM, il dplace des pages mmoire en zone dchanges, sur disque dur. Les performances lors de laccs ces pages sont catastrophiques, les disques tant bien plus lents que des barrettes de mmoire. Si un ralentissement est perceptible, il est caractris par une utilisation de la ressource I/O disque. Il ny a pas de contention sur laccs la mmoire proprement parler. Nous pouvons considrer que deux tats sont observables : le systme a assez de mmoire ; le systme en manque, il utilise la mmoire dchanges. Cela est un peu rducteur car toutes les situations ne se rsument pas ces deux tats. tudions comment observer des manques de mmoire et cherchons les cas o la supervision est complexe.

Mthode nave de supervision de la mmoire

Une premire mthode lors de la supervision de la RAM consiste avoir deux services : un pour le pourcentage de RAM utilis ; un pour la mmoire dchanges utilise. Cette mthode fonctionne plutt bien en thorie. Si la RAM est pleine, les administrateurs sont avertis. Si la mmoire dchanges se remplit galement, ils sont encore avertis. Ils peuvent agir dans les deux situations. Si les systmes taient simples, ce fonctionnement ne poserait aucun problme. Malheureusement, les dveloppeurs de systmes et les administrateurs rservent des utilisations toutes particulires cette ressource.

Le pige des caches disque

tudions les principaux cueils de la supervision de la mmoire.

Des caches bien pratiques

Les dveloppeurs de systmes partent dun constat simple : si un espace mmoire nest pas utilis, il est inutile. Ils cherchent utiliser au maximum cette ressource. Lun des piges les plus frquents lors des premiers tests de supervision de la mmoire concerne les caches disque. Cet espace mmoire permet de stocker une partie des donnes lues ou crites par les applications. La mmoire tant bien plus rapide que les disques durs, si un programme fait de nouveau appel une information disponible dans le cache, il y a accs trs rapidement.

Aide linterprtation des indicateurs classiques CHAPITRE 14

403

Les systmes exploitent lespace mmoire non utilis par les applications comme espace de cache disque. Sur un systme Linux, on peut lobserver dans la commande free.
Commande free
free -mt total Mem: 2023 -/+ buffers/cache: Swap: 509 Total: 2533 used 1944 1192 8 1952 free 79 831 501 580 shared 0 buffers 87 cached 664

Un espace disponible
Il est intressant dobserver que la valeur de used comporte lespace de cache. Lespace mmoire free dun systme Linux est systmatiquement trs rduit. Les programmes demandant de la mmoire ne se la voient pas pour autant refuser. Cet espace est simplement dduit de celui du cache. Lorsque nous supervisons lespace mmoire disponible dun systme, il est important de prendre en compte lespace free, mais galement lespace de cache disque. Dans le cas contraire, les systmes semblent systmatiquement dpourvus de mmoire disponible alors que ce nest pas le cas.
REMARQUE Un indicateur pige pour ladmin Linux dbutant
Beaucoup dadministrateurs Linux dbutants saffolent en voyant leur mmoire disponible ridiculement faible. Ils ajoutent alors des barrettes de mmoire avant de sapercevoir que cela ne sert rien. Ils commencent alors enfin en chercher le sens.

Sous Unix
La commande ddie cette vrification sur les UNIX est check_mem.pl. Elle utilise la commande free. Elle prend en compte correctement les caches disque. Voici un exemple dexcution du script :
Vrification de lespace mmoire sous Unix
check_mem.pl -w 90 -c 95 OK: 43% Used Memory | MemUsed=43%;90;95

Lespace dchanges est observ par la commande permet de surveiller lutilisation de cet espace.

swapon.

La sonde

check_swap

404

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Vrification de lespace dchanges sous Unix

check_swap -w 80% -c 50% SWAP OK - 100% free (501 MB out of 502 MB) |swap=501MB;401;251;0;502

Les seuils de check_swap sont exprims en pourcentage despace libre. Avec cette configuration, si le swap est utilis plus de 20%, un WARNING est lev. Sil est suprieur 50%, cest un CRITICAL.

Sous les systmes Windows

Sous Windows, la table WMI Win32_OperatingSystem exporte la mmoire utilise. Elle contient galement les caches disque. Les champs prendre en compte sont FreePhysicalMemory et TotalVisibleMemorySize. Voici un exemple de rsultat de lexcution de la requte :
Rcupration de la consommation mmoire en WMI
SELECT FreePhysicalMemory, TotalVisibleMemorySize FROM Win32_OperatingSystem

Cette requte renvoie le rsultat suivant :

FreePhysicalMemory=466648 TotalVisibleMemorySize=1047460

Ce rsultat reprsente 55% de mmoire utilise, ce qui est acceptable. Lespace dchanges (swap) utilis est, quant lui, indiqu dans la table Win32_PageFileUsage par les champs AllocatedBaseSize et CurrentUsage. Voici un exemple de lancement de la requte :
Rcupration de la consommation de lespace dchanges (swap) en WMI
SELECT AllocatedBaseSize,CurrentUsage FROM Win32_PageFileUsage

Cette requte renvoie le rsultat suivant :

AllocatedBaseSize=1536 CurrentUsage=120

Pour les administrateurs utilisant NSClient++, la commande utiliser est :

Rcupration de la consommation de lespace dchange (swap) avec NSClient++
check_nt -H serveur -v MEMUSE -w 80 -c 90

Aide linterprtation des indicateurs classiques CHAPITRE 14

405

Linconvnient majeur de cette mthode est de fournir des seuils sur lutilisation de la mmoire virtuelle. Celle-ci est dfinie comme la mmoire physique plus lespace dchanges. Il est dconseill de placer un seuil sur cette valeur. Lorsque lespace dchanges est utilis, il est dj trop tard. De plus, le ratio entre espace mmoire et espace dchanges est rarement identique sur tous les serveurs. Le placement du seuil devrait se faire au cas par cas.

Cas des gestionnaires de bases de donnes

Les administrateurs de bases de donnes ont eu une ide similaire celle des dveloppeurs de systmes. Les bases de donnes faisant un nombre important daccs disque, un cache des donnes rcemment utilises est disponible. Ce cache entre en conflit avec celui du systme. Il est plus appropri dans cette utilisation particulire. Les administrateurs ont tendance remplir au maximum ce cache applicatif. Il consomme tout lespace mmoire disponible. Le systme na pas connaissance du rle de cet espace. Pour lui, lapplication lutilise. Il nest pas disponible pour dautres applications. Ces serveurs sont, en rgle gnrale, ddis ce rle. Il ny a pas dautres applications qui demandent beaucoup de mmoire. Lutilisation de la mmoire nest donc pas alarmante mais totalement normale. Pourtant, le pourcentage dutilisation de la mmoire est trs important. Les alertes standard relvent des erreurs. Dans cette situation, il est important de surveiller galement lespace dchanges. Si des applications narrivent pas obtenir de mmoire, elles sont dplaces en espace dchanges. Cela rvle une contention au niveau de lespace mmoire. Cette alerte est trs importante pour les administrateurs. Une solution pourrait consister navertir les administrateurs que si lutilisation de lespace dchanges augmente. Il nest pas toujours possible de procder de cette manire.

Espace dchanges sollicit non vide malgr la mmoire disponible

Parfois, un processus alloue de la mmoire, y effectue des oprations, puis ne lutilise plus pendant une longue dure. Cet espace est en RAM alors quil nest pas utilis activement. Il ne doit pas tre perdu, le processus na pas demand sa suppression et napprcierait gure quon efface ses valeurs. Le cache disque se voit amput dun volume mmoire gal cet espace. Le cache disque nest jamais une perte sur les systmes actuels. Ceux-ci font une utilisation intensive des informations sur les disques. Plus le cache disque est grand, mieux le serveur se porte. Lespace inactif du processus est dommageable pour les performances du systme. Ce dernier peut alors prendre la dcision de placer les pages mmoire non utilises depuis longtemps en mmoire dchanges. Elles ne sont

406

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

pas perdues, mais ne prennent plus despace mmoire inutilement. La RAM libre peut tre raffecte au cache. La plupart des systmes fonctionnent de cette manire. Sous Linux, il est possible de spcifier au systme sil doit utiliser ce mcanisme souvent ou non. Ce paramtre est la swappiness. Il est accessible dans le fichier /proc/sys/vm/swappiness.
REMARQUE Windows, un cas part
Windows Server, avant sa version 2008, ne propose pas encore de fonctionnement quivalent. Il place une borne suprieure au cache. Une partie de la mmoire est systmatiquement perdue.

Ce fonctionnement pose problme dans la supervision. La mmoire dchanges peut tre en partie occupe alors que la mmoire centrale nest pas pleine. Il ne peut tre lui seul un indicateur de contention au niveau de la mmoire.

Relation de dpendance
Puisquaucun des deux indicateurs ne peut apporter dinformation prcise sur la contention mmoire, il peut tre utile de les utiliser conjointement. Une contention se produit quand la mmoire physique est pleine et que lespace dchanges commence se remplir. Si nous dfinissons un service pour la mmoire et un pour lespace dchanges, nous pouvons dfinir une relation de dpendance (voir figure 14-9).
Figure 149

Dpendance entre la mmoire et lespace dchanges

La mise en place des dpendances tant un peu longue, il peut tre galement intressant de tout simplement crire un script qui effectue les deux vrifications. Ce dernier ne renvoie une erreur que dans la situation suivante : la mmoire est utilise plus de 95% et la mmoire dchanges plus de 10%. Ces seuils permettent de grer les cas cits ci-dessus.

Aide linterprtation des indicateurs classiques CHAPITRE 14

407

Problme des I/O disque

Point souvent mis de ct, la supervision des I/O disque est pourtant de la premire importance.

Une ressource trs limitative

De nos jours, les processeurs fonctionnent une cadence infernale. Les quantits de mmoire sont trs importantes. Lvolution de ces deux ressources sur la dernire dcennie est trs importante. Les performances des processeurs a augment de 1 500 % en 10 ans et la quantit de mmoire denviron 3 000 %. Une ressource est malheureusement en retrait de cette course : les disques durs. Leur espace a augment de 30 000 %, mais leur vitesse reste toujours le parent pauvre des systmes actuels. Elle augmente dun pnible 500 % si lon considre le nombre daccs quils peuvent dlivrer. Les problmes de performances des disques ont oblig les administrateurs augmenter les caches disque et applicatifs pour pallier ce problme. Si le grand public a lhabitude dentendre parler de vitesse dcriture des disques durs, les administrateurs nutilisent pas les mmes units. Dans la majorit des situations o un disque subit des contentions, les dbits ne sont pas importants. Ils peuvent mme surprendre un nophyte lorsquon lui apprend quun serveur a du mal dlivrer plus de 4 Mo/s sur les disques. Le problme se trouve sur la manire dont fonctionnent les disques durs actuels. Fonctionnant mcaniquement, ils ncessitent un temps de dplacement de la tte de lecture pour atteindre linformation. Si lutilisateur demande des donnes situes les unes ct des autres, la tte de lecture na pas besoin de bouger pour les obtenir. Le dbit peut tre important. Dans le cas daccs compltements alatoires sur la surface du disque, les temps de dplacement sont problmatiques. Un tel dplacement prend entre 5 et 10 millisecondes. Si lapplication fait appel de nombreuses petites donnes rparties sur tout le disque, ce dernier ne va peut dlivrer quentre 100 et 150 donnes par seconde. Si chaque donne fait 4 ko, cela ne reprsente que 400 Ko/s. Ce nombre daccs par seconde est la principale limitation des systmes actuels. Elle se nomme IO/s (I/O par seconde).
PERFORMANCE Lavnement des disques SSD
Les disques SSD (Solid State Disk) commencent se dmocratiser. Nayant plus de partie mcanique, ils peuvent fournir plus de 5000 IO/s, soit plus de 50 fois plus quun disque standard. Leur prix lev et leur capacit rduite les cantonnent pour linstant au march des serveurs haut de gamme, mais leur dmocratisation pourrait tre lune des avances majeures dans le monde serveur depuis ces 10 dernires annes.

408

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Une supervision complexe

Cette ressource ayant un impact particulirement important, il est important de la superviser. Placer un seuil de nombre dI/O par seconde est presque impossible sur un systme en production. Les demandes sont varies et le nombre daccs change suivant la taille des blocs remonts. Cette information est utile dans le cadre de la mtrologie. Elle permet de voir limpact des modifications de cache des systmes et des applications. Utilise conjointement un indicateur de load average, elle permet de dterminer la source de la charge. Si le nombre doprations par seconde augmente fortement, il est urgent dintervenir. Des indicateurs de files dattente dI/O existent. Par exemple, sous Unix, la commande iostat du paquet sysstat est larme prfre des administrateurs la recherche des ralentissements de disques. Le champ avgqu-sz permet dobtenir le nombre de demandes en attente. Si cette valeur dpasse rgulirement 2, il peut tre utile de mettre des disques plus rapides. Lindicateur %util de iostat indique le pourcentage dutilisation sur le temps dun disque. Il est galement trs utile. Comme nous lavons vu dans la partie du load average, un indicateur fourni par advanced load average permet de prvoir les gains que ladministrateur peut obtenir en amliorant les accs disques. Sous Windows, lindicateur PercentPrivilegedTime dj prsent dans la partie CPU permet de dtecter des situations de contention sur les disques.

Supervision de la charge rseau

Il est inenvisageable, notre poque, de couper un serveur du rseau. Voyons comment superviser cette ressource critique.

Des liens parfois insuffisants

Les rseaux ont profit pleinement des avances technologiques. Les dbits proposs sur les rseaux locaux sont impressionnants. La demande ayant malheureusement suivi, les contentions rseau ne sont pas rares. Que ce soit sur un serveur ou sur un lment rseau, il est important de vrifier que les liens sont dimensionns correctement pour supporter la charge. La supervision des systmes et des lments rseau nest pas effectue de la mme manire. Dans le monde rseau, le SNMP est roi. Il est utilis pour obtenir cette valeur. Sur les systmes dexploitation, on prfre les agents.

Aide linterprtation des indicateurs classiques CHAPITRE 14

409

Systmes dexploitation
Sous Unix
La commande netstat permet davoir les statistiques des interfaces rseau. La sonde check_network lutilise. Elle est uniquement utilise dans la mtrologie. Corrle une alerte CPU de %sys lev, elle peut permettre didentifier une contention.

Sous Windows
Tout comme les disques, nous pouvons observer les files dattente en sortie des cartes rseau. Si la valeur dpasse rgulirement 2, cest que la machine doit faire face une une contention au niveau des interfaces rseau. La requte WMI associe est :
Rcupration des files dattente rseau en WMI
SELECT Name,OutputQueueLength FROM Win32_PerfFormattedData_Tcpip_NetworkInterface

Attention, il faut exclure des rsultats MS TCP Loopback interface car cette interface est virtuelle.

lments rseau
Sil arrive que les serveurs soient sujets des problmes de dbit rseau, bien souvent, cela provient du cur du rseau. Ce dernier doit tre capable de grer lensemble des flux. Les commutateurs et routeurs proposent, sur leur interface dadministration, des informations relatives au dbit pass pour chaque interface. Cette valeur augmente au fil du temps. Les informations de dbit sont bien plus utiles aux administrateurs rseau. Il est ncessaire de faire une diffrence entre une valeur releve et une valeur ancienne. Pour cela, des fichiers temporaires sont utiliss. La sonde check_centreon_snmp_traffic est ddie cette tche. Lors du premier lancement, elle stocke la valeur dans le fichier /tmp/centreon_trafic_ifINTERFACE_IP. Dans ce fichier se trouvent la valeur releve et sa date. Lors du premier lancement, le plug-in retourne un tat suivante :
Premier lancement de check_centreon_snmp_traffic
First Execution : Buffer in creation ... UNKNOWN

avec la sortie

410

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Cette sonde permet galement de vrifier que les interfaces mesures sont dans un tat UP. Dans le cas contraire, une erreur est leve :
Interface non disponible
Error : interface is not ready, status down

Le paramtrage de ce plug-in est un peu complexe lors des premiers essais. Le point important est de dterminer le nom des interfaces surveiller. Il utilise des expressions rationnelles pour les spcifier. Les diffrents systmes dun mme constructeur ne nomment pas ncessairement les interfaces de la mme manire. Pour cela, le paramtre -s permet de dresser la liste des noms et des tats des interfaces. Lorsque le nom des interfaces est dtermin, la sonde peut tre utilise pour interroger ltat des liens. Voici un exemple de lancement sur un commutateur :
Rcupration du trafic dun port
check_cetreon_snmp_traffic -H 192.168.0.1 -i "Port 47" -n -r Traffic In : 228.22 kb/s (0.0 %), Out : 2.93 Mb/s (0.3 %) - Total RX Bits In : 19.79 GB, Out : 14.24 Gb|traffic_in=228224,0Bits/s traffic_out=2929806,9Bits/s

Ici, linterface est utilise 0.3% en mission. Si la valeur devient trop importante, par dfaut suprieure 80% et 95% dutilisation pour respectivement un avertissement et un tat critique, une erreur est leve. Ces seuils sont paramtrables avec les arguments -w et -c.
PRATIQUE Rester raisonnable
Il est dconseill de suivre ltat de tous les liens. Les administrateurs rseau nont besoin de suivre que quelques liens particuliers. Un lien arrivant sur un poste client dclencherait une alerte chaque fois que lutilisateur allume son PC, ce qui nest probablement pas le comportement souhait...

Le reste de la supervision systme

Nous avons trait les points principaux de la supervision systme. Ils sont importants, mais dautres indicateurs sont tout de mme surveiller.

Aide linterprtation des indicateurs classiques CHAPITRE 14

411

Espace disque
Une ressource importante
Les disques ont une fcheuse tendance se remplir. Plus il y a de place disponible, plus les utilisateurs inventent de nouveaux moyens de les remplir. Cette guerre sans fin a besoin dtre supervise. Des disques pleins peuvent non seulement ennuyer des utilisateurs, mais galement causer des problmes svres. Lexemple dun traitement de sauvegarde qui choue pour cause de disque plein a t voqu dans le premier chapitre. Ses impacts peuvent tre trs importants.

Seuils dalerte
Lorsquil est question de placer les seuils pour les sondes qui supervisent les espaces disques, deux coles sont possibles : seuils en terme de pourcentage despace libre ou utilis ; seuils en terme de volume fixe sur lespace libre. Dans le premier cas, que nous plaons un seuil davertissement 80 % despace utilis ou 20 % despace libre, nous arrivons au mme rsultat. Dans le second, parler en terme de volume utilis, comme par exemple 200 Go, na pas de sens, sauf si on connat lespace disponible et que lon souhaite modifier ce seuil pour chaque volume. Les seuils en volume sont fortement dconseills. Lutilisation des pourcentages est bien plus pertinent. Prenons un exemple simple. Un administrateur possde deux disques, un de 300 Go et un de 10 Go. Il peut sagir dun espace de donnes et dun espace pour le systme. Il peut dcider de placer un seuil qui lve une alerte moins d1 Go despace disque disponible. Cette valeur nest jamais idale. Suivant le volume considr, la situation est tre bien diffrente. Sur le disque de 300 Go, 1 Go ne reprsente pas grand chose. Si une application ou des utilisateurs ont russi remplir 299 Go, le dernier Go ne durera pas bien longtemps. Un seuil de 30 Go despace disque disponible aurait t plus pertinent. Sur le disque de 10 Go, ce mme 1 Go reprsente un espace consquent. Une application ayant rempli seulement 9 Go ne remplit pas forcment aussi rapidement 1 Go que dans le cas prcdent. Le seuil est acceptable dans cette situation. Bien sr, il est possible de positionner des seuils en volume espace par espace. Mais ladministrateur va finalement revenir la mthode du pourcentage pour les calculer. Dans ces conditions, autant placer les seuils en pourcentage directement et viter une configuration fastidieuse.

412

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Sondes de supervision
Sur les systmes Unix, la commande utilisation est trs simple :
Rcupration despace disque sous Unix
check_disk -w 80 -c 90 Disk OK free space: / 1425MB (19% inode=91%); /boot 159MB (88% inode 99%); /data 52900MB (45% inode=99%) check_disk

soccupe de cette supervision. Son

La commande vrifie galement que le nombre dinodes des espaces nest pas trop important. Ce sont des liens vers les fichiers. Leur nombre est limit par systme de fichiers. Les cas de remplissage ne sont pas courants, mais particulirement tratres. Si certains espaces ne doivent pas tre surveills, ladministrateur peut utiliser largument -x. Sur les systmes Windows, la table Win32_LogicalDisk exporte ces informations. Seuls les disques doivent tre surveills. Les espaces comme les lecteurs CD-Rom ne sont pas importants. Pour cela, nous utilisons un filtre sur le champ DriveType 3.
Rcupration de lespace disque en WMI
SELECT Name,FreeSpace,Size FROM Win32_LogicalDiskwhere drivetype=3

Nous obtenons :
Name=C: Freespace=1639153669 Size=9345678543 NSClient++

propose le test USEDDISKSPACE pour vrifier plus simplement les disques :

Rcupration de lespace disque par NSClient++

check_nt -H $HOSTADDRESS$ -v USEDDISKSPACE -l C -w 80% -c 90%

PRATIQUE Vrifier sparement les espaces

Il est fortement conseill de crer deux services de vrification des disques : un pour les disques systme ; un pour les donnes utilisateur. Ces derniers tant rgulirement pleins, ils pourraient cacher des problmes plus graves sur les disques systme.

Aide linterprtation des indicateurs classiques CHAPITRE 14

413

Montages NFS
Les partages NFS sont trs rpandus dans le monde Unix. Ils peuvent, de temps en temps, tomber suite des problmes de connexion. Les administrateurs doivent en tre avertis le plus rapidement possible. La sonde check_nfs_client est ddie cette tche. Elle procde en lisant le fichier /etc/fstab dans lequel doivent tre rfrencs les montages NFS. Elle procde alors par un simple changement de rpertoire dans les points de montage. Si la commande ne rend pas la main rapidement, le montage est dclar comme tomb.

Agrgats rseau
Sous Linux, les interfaces rseau peuvent tre montes en bonding. Ce type dinterfaces est un agrgat dinterfaces physiques. Ils permettent de pallier la perte dun lien. Cette perte nest pas critique car le second prend le relais. Cette information doit tre remonte aux administrateurs. La sonde est ddie cette tche. Elle vrifie dans les fichiers /proc/net/bonding/bond* les informations des connexions. Linformation Link Failure Count permet de dterminer le nombre dinterfaces tombes.
check_bonding.pl

Voici un exemple de lancement du script :

Vrification de ltat des agrgats de liens sous Linux
check_bonding.pl bond0 up on eth0: member: eth1 (up) eth0 (up)

PRATIQUE Bonding sur le serveur Nagios

La communication entre Nagios et les nuds est essentiellement faite sur le rseau. Les interfaces doivent avoir des proprits de haute disponibilit. Lutilisation de bonding est fortement conseille sur le serveur de supervision.

tat des imprimantes

De nombreux lments peuvent tre indisponibles dans un systme dinformation. Sil en est un qui agace tout particulirement les utilisateurs, cest bien les imprimantes. Elles ont une facult avoir des problmes qui dfie limagination. Elles peuvent tre supervises par diffrents biais. Les imprimantes tant des quipements rseau, le protocole SNMP est souvent disponible. Les constructeurs ne sont cependant pas souvent daccord sur les MIB utiliser.

414

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Un moyen de supervision plus simple consiste se placer sur le serveur dimpression. Ce dernier a toute la visibilit ncessaire pour cette vrification.

Sous Unix
Le gestionnaire dimpression sous Unix est Cups. Nous pouvons interroger ltat des imprimantes avec la commande lpstat.
Vrification des imprimantes par lpstat
lpstat -h serveur -a IMPRIMANTE accepting requests since Sat Jan 17 18:16:56 CET 2009

La sonde check_lpstat permet de vrifier quil ny a pas trop dimpressions en attente sur les imprimantes.
Sonde qui automatise la vrification des imprimantes
check_lpstat -H serveur OK: IMPRIMANTE: 1 job

Sous Windows
Sur un serveur dimpression Windows, les donnes dtat des imprimantes sont disponibles dans la table Win32_Printer. Le champ PrinterStatus est celui qui nous intresse tout particulirement. Un tat normal dimprimante quivaut une valeur de PrinterStatus 3. La requte permettant dobtenir une liste des imprimantes en dfaut est :
Rcupration de ltat des imprimantes en WMI
SELECT Name,PrinterStatus Win32_Printer Name,PrinterStatus WHERE PrinterStatus!=3

Voici un rsultat de cette requte dans le cas o une imprimante est en erreur :
Name=IMPRIMANTE PrinterStatus=1

La sonde check_printer permet dobtenir des informations plus simples comprendre pour les administrateurs sur ltat des imprimantes. Voici un exemple de sortie de cette sonde :
tat des imprimantes avec check_printer
CRITICAL: IMPRIMANTE: The printer is out of toner (0 jobs)

Aide linterprtation des indicateurs classiques CHAPITRE 14

415

Services lancs automatiquement

Sous Windows, il est possible de connatre ltat dun service. Si ce dernier doit tre lanc automatiquement au dmarrage, un tat arrt est synonyme derreur. Pour cette vrification, une simple requte WMI suffit :
Rcupration de ltat des services en WMI
SELECT Name,State,StartMode FROM Win32_Service WHERE StartMode="Auto" and State="stopped" and name!="sysmonlog"

Il est important de noter que le service sysmonlog est, dans une situation normale, arrt alors quil est indiqu comme lanc au dmarrage. Ce service mis part, si la requte retourne un rsultat, cest que le service en question est arrt alors quil ne devrait pas.
PRATIQUE Services comme sysmonlog dont larrt est normal
Les services marqus comme dmarrant automatiquement mais dont larrt est normal ne sont pas courants. Certaines applications en installent. Il est ncessaire de modifier le test lorsque de tels services sont mis en place.

Redmarrage des machines

Les serveurs peuvent redmarrer de temps en temps. Le plus souvent, cest sur demande dun administrateur. Parfois, cet arrt est imprvu. La supervision des htes permet de savoir quand une machine ne rpond plus. Mais comment diffrencier un redmarrage dune simple perte rseau ? Sil est situ derrire un lment rseau, cette perte est gre par les relations de parent. Dans le cas dun serveur sur le rseau local, cette distinction est bien plus complexe. Un moyen simple pour cela est de suivre lindicateur duptime. Ce dernier donne le nombre de secondes depuis le dmarrage. Si cette valeur est petite, cest quun dmarrage a eu lieu. Sous Unix, il suffit de lire le fichier /proc/uptime. La premire valeur est le nombre de secondes depuis le dernier dmarrage. La sonde check_uptime est utilise pour automatiser cette vrification :
Vrification du redmarrage
check_uptime .pl OK : uptime : 6409856 s

416

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Sous Windows, il suffit de lire cette information dans la table champ porte le mme nom.
PRATIQUE Nom du service

SystemUpTime.

Le

Les administrateurs risquent davoir du mal de bon matin faire la corrlation entre un uptime faible et un redmarrage. Nommer le service Uptime nest pas appropri. Un nom comme Reboot est beaucoup plus parlant.

Indicateurs physiques
Derniers indicateurs tre traits mais non des moindres : les indicateurs physiques.

Alertes prioritaires
Les indicateurs physiques regroupent, par exemple, les informations sur la temprature ou lhumidit. Elles ne sont pas en rapport direct avec les systmes dinformation. Elles reprsentent cependant une couche indispensable son fonctionnement. Les erreurs devant lever des messages hautement critiques, envoys le plus souvent par SMS, ne sont pas nombreuses. Les indicateurs physiques en font partie. Si une panne lectrique fait surface au beau milieu de la nuit, il est important de la traiter au plus tt. Dans cette partie, les mesures dpendent fortement du matriel mis en place. Il arrive que certains lments ne puissent pas tre superviss. Lorsquils seront changer, ce critre devra entrer en ligne de compte. Pour la majorit dentre eux, heureusement, le SNMP est disponible. Les lments peuvent tre configurs pour envoyer des alertes SNMP (traps) lorsque des problmes surviennent. Les polls SNMP sont, quant eux, utiliss principalement pour la mtrologie. Il est possible, au fil du temps, de suivre des indicateurs importants comme la temprature ou lnergie totale consomme par la salle machine.

Temprature et humidit
Des sondes existent pour mesurer la temprature et lhumidit. Peu chres, elles sont indispensables sur les sites distants. Leur cot tant faible, il est conseill de les mettre en place partout.

Aide linterprtation des indicateurs classiques CHAPITRE 14

417

La temprature : une valeur trs variable

Les serveurs sont bien plus sensibles la temprature que ce que lon peut penser. Si une machine de bureau na pas de problme pour fonctionner dans une salle 35C, un serveur sarrte pour ne pas tre endommag. Une temprature de bon fonctionnement dune salle serveur est denviron 20C. Une premire alarme 25C est acceptable. Lalerte critique est 30C. En cas de panne de la climatisation, la temprature peut monter trs rapidement. Les 25C peuvent tre atteints en moins dune demi-heure. Les tests de temprature tant limits quelques sondes, il est conseill de les ordonnancer trs rgulirement. Chaque minute peut compter lorsquune climatisation tombe en panne. Un test toutes les minutes nest pas du luxe.
PRATIQUE Placement judicieux des sondes de temprature
Les sondes doivent renvoyer une information sur la temprature globale de la salle. Si elles sont places derrire un serveur, elles peuvent tre fortement influences par lactivit de ce dernier. On peut les placer sur le ct des armoires.

On peut ventuellement associer cette alarme une action dextinction de serveurs non critiques. Cest une bonne ide, mais attention bien vrifier que lalarme soit correctement place sous peine de gnrer plus de dgts quautre chose.

Lhumidit : variable suivant la saison

Lhumidit diminue lgrement lesprance de vie des machines. Elle varie fortement suivant la priode de lanne. Elle est plus leve en t quen hiver. Certains endroits de la plante sont plus sujets avoir une valeur leve que dautres. LAsie a par exemple une humidit moyenne plus leve que lEurope de lOuest. Un seuil de 60 % de taux dhumidit est acceptable. Cette valeur ne doit pas donner lieu une alerte critique. Elle peut cependant reflter des problmes dans la climatisation et nest donc pas ignorer totalement.

Consommation lectrique
Peu de machines arrivent fonctionner sans lectricit. Si cet lment est indispensable, il est tonnant de voir que peu dinstallations sont supervises. La plupart des onduleurs ont pourtant une console dadministration. Diffrentes alertes peuvent intresser les administrateurs. Les onduleurs ont gnralement plusieurs sources dalimentation. Si lune dentre elles nest plus disponible,

418

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

les autres sont capables de supporter la charge. Une alerte doit tre leve afin de rtablir le systme de secours le plus rapidement possible. Une coupure du lien restant serait plus que critique. Ltat des batteries est important. Si celles-ci sont trop vieilles, elles ne se chargent plus. Les administrateurs pensent avoir un systme de secours alors que ce nest pas le cas. Un simple suivi de ltat de charge des batteries suffit viter une catastrophe. Les onduleurs ont une forte sensibilit aux variations de tension. Si les valeurs deviennent trop faibles, ils peuvent arrter de fonctionner. L encore, la plupart permettent dalerter les administrateurs en cas de problme.
PRATIQUE Destinataires des alertes
Les informations sur ltat de la salle intressent fortement les responsables de la salle. Bien souvent, ils ne font pas partie du service informatique. Leur coopration est indispensable pour obtenir les informations. Il est de bon got de leur envoyer les alertes en cas de problme. Sils sont avertis rapidement, la rsolution nen est que plus rapide.

Enfin, la consommation gnrale de la salle est intressante plus dun titre. Les administrateurs ont souvent pour objectif de faire baisser les charges. Dans celles-ci, les frais concernant la consommation lectrique des serveurs et de la climatisation psent sur les rsultats. La virtualisation et la consolidation des systmes permettent un gain fort apprciable. La mesure londuleur de la consommation globale permet de fournir des chiffres clairs la direction sur les conomies ralises.

En un mot
Les lments superviser sur les systmes sont nombreux. Les indicateurs sont nombreux galement. Le plus clbre dentre eux dans le monde Unix est le load average. Sil nest pas parfait, il est trs reprsentatif de la charge dun serveur. Les autres lments dun systme ne sont pas si simples superviser quil y parat. Quil sagisse des ressources processeur, mmoire ou disque, chacune a des cas particuliers quil faut penser grer. Dautres lments comme la temprature et lhumidit sont importants pour le systme dinformation. La mise en place de la solution doit les prendre en considration.

15
Configuration applique un systme imaginaire
Les applications tant en place, ladministrateur ayant pris connaissance des diffrents indicateurs quil peut rcuprer sur son systme, il est temps de finir la configuration de la solution. Avant cela, il faut faire la liste des indicateurs surveiller et organiser toute la supervision. Nous allons dtailler une configuration adapte un environnement classique, compos de systmes htrognes (Windows et GNU/Linux), dapplications qui le sont tout autant (serveurs web et bases de donnes), le tout fonctionnant sur un rseau administr par une quipe ddie.

Rcupration des informations sur le systme superviser

La premire tape dans la configuration du systme de supervision consiste aller voir lensemble des personnes susceptibles dtre intresses par des alertes. Elles seules sont capables de fournir une liste des lments dont elles souhaitent tre averties. Cette liste doit aussi indiquer le niveau de criticit des alertes. Sur ce point, il faut faire tout particulirement attention au ratio entre alertes critiques et simples avertissements. Les personnes ont tendance tout placer en niveau critique. Il faut leur

420

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

faire comprendre un point : on qualifie de critique ce qui porte atteinte au fonctionnement mme du systme dinformation. Si les utilisateurs nont pas conscience du problme lorsquil survient, il ne ncessite en aucun cas une alerte critique, mais un simple avertissement. La priode de supervision des lments est galement importante. Certaines applications ne sont pas disponibles la nuit. Il est inutile de les surveiller et dalerter la moiti des administrateurs pour rien. Les personnes doivent aussi choisir un ou plusieurs biais de notifications. Les e-mails sont un choix classique, mais il faut leur prsenter galement les alertes par flux RSS et toutes les autres solutions du chapitre 6. Certains aiment recevoir un message en cas de rsolution du problme alors que dautres ne souhaitent pas les recevoir : ce choix doit tre fait par le contact. Recueillir toutes ces informations peut prendre du temps. Il y a peu de chances dy parvenir en une seule journe. Cette phase est pourtant primordiale. Elle doit tre accompagne dexplications pour les contacts afin quils comprennent que la supervision peut leur faciliter la vie de tous les jours. Si des rticences font surface ce moment l, par peur de perdre le contrle, il faut expliquer aux interlocuteurs quils sont encore matres de la diffusion des alertes. Il ne devrait plus y avoir de problmes une fois ce point mis au clair.
PRATIQUE Le ncessaire soutien de la hirarchie
Certains soucis dordre organisationnel peuvent survenir lors de ce recensement. Certains pans du systme dinformation sont de vritables zones dombre. Personne ne sait qui sen occupe et personne ne veut reprendre le flambeau. Il faut pourtant dsigner quelquun pour recevoir les alertes correspondantes mises depuis Nagios. Ladministrateur Nagios ne peut dcider seul de cela : il a besoin de lappui de sa hirarchie davantage encore que pour le reste de la mise en place de la solution.

Conception de larchitecture de supervision

Une fois toutes ces informations recueillies, il est temps de les agglomrer pour former des groupes.

Regroupement par type : systme, rseau, applicatifs...

Ce nest pas un mince travail qui attend ladministrateur Nagios. Sil narrive pas factoriser correctement sa configuration, il passera une grande partie de son temps futur sen occuper. Le temps pass concevoir la configuration de Nagios nest pas du temps perdu, loin de l.

Configuration applique un systme imaginaire CHAPITRE 15

421

Il est conseill de dcouper les lments suivant plusieurs plans : systmes ; rseaux ; applicatifs ; autres. Ce dcoupage permet de sparer les lments des diffrents administrateurs. Ceci nous facilitera grandement la vie lors de la configuration. Une fois le dcoupage effectu, nous pouvons regrouper les lments par familles de systmes dexploitations ou par types dapplications. On peut, par exemple, crer un groupe avec les systmes Linux et un autre pour les systmes Windows. Chaque ensemble sera redcoup suivant la criticit des lments : production ; qualification et moins.
MTHODE Le niveau dveloppement
Il est tentant de dfinir un troisime niveau : dveloppement. Les services sur ce niveau ne renverraient jamais un tat autre que OK. Seule la mtrologie serait utilise. Mais cest une fausse bonne ide. Ces serveurs doivent avoir un minimum de supervision, mme sils nenvoient pas dalertes. Celles-ci ne seront visibles que sur les consoles de supervision au niveau de simples avertissements. Ladministrateur peut ainsi faire un tour, le matin, des alertes en cours. Tout comme pour la qualification, une alerte peut annoncer un dysfonctionnement qui aura des consquences sur la production.

Concernant les applications, cest la manire dont elles peuvent tre surveilles qui nous intresse. Les bases de donnes et les sites web sont dans des groupes distincts. Il y a peu de chances que les mmes mthodes de supervision soient utilises dans ces deux cas. Parmi les lments superviser sur les htes, il est important de reprer ce qui doit tre remont aux contacts des nuds, de ce qui doit tre envoy des contacts particuliers. Par exemple, les informations sur lespace disque intressent naturellement les administrateurs responsables du serveur. Savoir si lantivirus est bien lanc concerne surtout les administrateurs scurit. Lors de la configuration des services, cette information sera trs importante pour la dfinition des contacts.

Procder par tape

Lors de la mise en place, il nest pas conseill de tout surveiller de suite. Ladministrateur Nagios a besoin de quelque temps pour se familiariser avec la solution. La premire version de la configuration nest peut-tre pas la bonne. Il est plus simple de remodeler une configuration dune vingtaine de nuds que dune centaine.

422

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Le choix des premiers environnements surveills ne doit pas tre fait au hasard. Ils doivent reprsenter le parc. Les administrateurs impliqus dans ces premiers essais doivent tre ceux qui se sont rvls les plus enthousiastes lors des phases danalyse. Lors des premiers essais, ils risquent de recevoir de nombreuses alertes avant que le responsable de la solution arrive grer correctement les niveaux de criticit des alertes ou bien les relations de dpendances entre les lments. Des administrateurs peu enclins au changement y verraient une raison supplmentaire de mettre des btons dans les roues de ladministrateur en charge de cette mise en place. Si les personnes sont un peu plus curieuses, elles vont sintresser loutil et aider sa mise en place. Aussi vaut-il mieux attendre que tout soit bien rgl pour intgrer dautres administrateurs au projet. Lors de cette deuxime phase, il faut bien donner toutes les informations sur ce que les administrateurs risquent de recevoir. En outre il est important de leur donner accs une base de connaissance pour expliciter le sens des alertes, sils nont pas particip activement leur dfinition. Ce lien peut tre fourni directement dans le-mail dalerte afin de faciliter cette recherche.
PRATIQUE Mise en place itrative
Bien sr deux phases ne sont pas suffisantes pour une mise en place complte. Les nouvelles vrifications soulvent de nouvelles questions de la part des administrateurs. Ils peuvent, suivant le rsultat, demander des ajustements sur les tests effectus. Leur soutien dans la mise en place est primordial.

Une monte en charge progressive peut galement tre utile pour sassurer que le serveur choisi suffit pour la supervision. Dans le cas contraire, il faut appliquer les recommandations du chapitre 9 avant dajouter de nouveaux lments. Rater des problmes cause dune latence trop leve est bien plus grave que de ne pas surveiller de nouveaux lments. Les administrateurs se pensent labri, alors que ce nest pas le cas. La confiance quils ont dans loutil pourrait disparatre tout jamais.
ATTENTION Attendre pour mettre en place les crans de supervision !
La mise en place des crans de supervision ne doit se faire quaprs avoir obtenu des alertes fiables. Ces crans sont l pour rassurer et alerter en cas de problme toutes les personnes du service. Si les informations sont fausses, les effets peuvent tre dramatiques.

Groupes dadministrateurs et contacts

Nous allons avoir 5 groupes dadministrateurs : administrateurs Unix ;

Configuration applique un systme imaginaire CHAPITRE 15

423

administrateurs Windows ; administrateurs rseau ; administrateurs Active Directory ; responsables des salles.

Chaque groupe peut comporter un ou plusieurs contacts. Tous reoivent les alertes par e-mail. Certains souhaitent lire les alertes au fur et mesure dans un flux RSS. Leur priode de notification est de 24/7. Des contacts sont dfinis dans chaque groupe comme personnes dastreinte. Ces contacts ne sont pas nomms, car les personnes effectuent des rotations. La priode de notification de ces contacts est no-workhours, soit de 18h 8h du matin et toutes les journes de samedi et dimanche. Leur unique commande de notification est constitue de send-by-sms. Les SMS ne doivent tre envoys que sur les priodes dastreinte. Il nest pas possible de choisir une priode de notification pour chaque commande, cette priode est relie au contact. Un nouveau contact est donc ncessaire. tant dans le groupe dadministrateurs, il suffira de rajouter ce dernier pour que la personne dastreinte soit alerte et ce, uniquement la nuit et le week-end.

Groupes de machines superviser

Les htes qui nous intressent sont rpartis en 7 groupes de machines : UnixProd ; UnixQualif ; WindowsProd ; WindowsQualif ; Reseaux ; ActiveDirectory ; DetecteursPhysiques. Ces groupes vont accueillir nos packs de sondes. Dautres groupes pourront tre rajouts par la suite. Ceux prsents actuellement reprsentent lossature de notre configuration. Les diffrences entre les services sappliquant sur les membres des groupes Prod et Qualif sont les suivantes : les commandes de qualification ne peuvent renvoyer quun tat WARNING au maximum ; les services sappliquant sur de la qualification ne peuvent pas provoquer des notifications.

424

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Ces deux lments en place, les administrateurs ne seront pas pollus par des messages provenant denvironnements non critiques. Ils pourront regarder le matin la console de supervision pour vrifier sil y a des alertes sur les environnements de qualification. Si une de ces machines tombe, ils seront tout de mme avertis.

Packs de sondes mettre en place

Concernant les packs de sondes, les points les plus importants sont les suivants : Unix : charge moyenne ; espace disque ; mmoire ; mtrologie disques ; Windows : charge CPU ; espace disque ; mmoire ; mtrologie disques ; services automatiques lancs ; Rseaux : mtrologie des liens entre les switchs et routeurs ; supervision de quelques ports importants ; services DNS ; Active Directory : tat dActive Directory ; Dtecteurs physiques : temprature ; humidit ; alimentation lectrique. Dautres lments sont galement ajouter. Lensemble de ces points a t tudi au chapitre prcdent. Les applications ne sont pas en reste. Quelques traitements importants seront superviss par Nagios. Ils sont ordonnancs par cron sur quelques serveurs. Leur tat est important pour le bon fonctionnement du systme dinformation. Les administrateurs souhaitent galement tre avertis si ces traitements nont pas fonctionn depuis une certaine priode de temps. La supervision passive avec dtection de la fracheur des tats est utile ici.

Configuration applique un systme imaginaire CHAPITRE 15

425

Lindispensable base de connaissances

Chaque vrification doit donner lieu une entre dans la base de connaissances. Il est possible, et mme recommand, de regrouper les vrifications par famille. Par exemple, une page peut contenir tous les tests effectus sur les systmes Windows. Chaque entre doit spcifier en quoi consiste la vrification et comment la reproduire sans Nagios. Un administrateur cherchant des complments sur une alerte pourra reproduire le test. De cette manire, il acceptera mieux les informations que lui fournit la solution. Comprenant ce quil fait, il pourra mme proposer des amliorations. Si le problme a une solution, il est conseill de la faire figurer dans lentre correspondant la vrification. Quand ladministrateur reoit une alerte, il na plus qu cliquer sur le lien prsent dans le-mail et appliquer les instructions qui lui sont donnes.

Configuration de Nagios dans Centreon

Le but premier de Centreon est de configurer Nagios. Regardons comment faire.

Un ou plusieurs Nagios
Centreon permet de configurer un ou plusieurs Nagios. Notre exemple nen comporte quun seul, la configuration simple. Il nest pas conseill de tenter doptimiser le fonctionnement de Nagios ds les premires mises en place. Si le nombre dlments est raisonnable (moins de 300 machines), il ny a aucune raison de tenter damliorer la situation : install sur un serveur de milieu de gamme, Nagios a suffisamment de ressources pour remplir son office.
Pour avoir une ide du nombre de vrifications quest capable de supporter un tel serveur, se rfrer au chapitre 9.

La configuration se droule dans longlet Configuration->Nagios->nagios.cfg. Dans cet cran figure la liste des principaux fichiers de configuration des Nagios dfinis par ladministrateur. Ici, nous diterons le seul prsent, Nagios CFG 1. Il est accroch lunique poller Nagios dfini, Poller Principal.

426

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Configuration dun Nagios

Fichiers journaux et autres
La premire page prsente les diffrents fichiers lis au fonctionnement de Nagios comme les fichiers journaux ou bien le fichier p1.pl ncessaire linterprteur Perl intgr. Dans la premire page, il est conseill de modifier le paramtre Aggregated Status Updates Option pour le passer Yes. Ce paramtre est Yes par dfaut dans la configuration de Nagios et, vu que le fichier de statut nest plus utilis par les interfaces, il nest pas ncessaire de le mettre jour trop frquemment.

Options de vrification
Dependencies

La seconde page prsente les options de vrification. Loption Soft Service est un choix que doit faire ladministrateur. Si loption est positionne Yes, des dpendances pourraient prendre en compte des tats non srs. Il est gnralement conseill de laisser ce paramtre sur No. Nagios sera moins ractif sur les problmes et leurs dpendances, les administrateurs risquent de recevoir un peu plus de notifications, mais ce surplus devrait tre limit. Le paramtre de flapping est, par dfaut, plac sur No. Il est pourtant dun grand secours lorsque les environnements commencent avoir le hoquet . Il est conseill de le positionner Yes. Les autres taux proposs par dfaut sont acceptables et filtrent relativement bien. Il est bon de rappeler que les htes et les services peuvent redfinir ce paramtre. Le paramtre Obsess Over Services plac sur vouloir mettre en place un Nagios miroir.
No

ne doit pas tre modifi, sauf

Les paramtres de Cached Host Check et Cached Service Check sont, par dfaut, vides dans Centreon. Cette configuration quivaut, au sens de Nagios, une plage de temps de 15 secondes. Si ces paramtres sont apprciables en termes de gains de performances, ils impliquent une approximation dans les relations de parent. Dans notre situation, les performances ne sont pas encore un problme et nous positionnerons donc pour linstant ces paramtres 0. Ils seront un levier intressant pour amliorer les performances si le besoin se prsente dans le futur. Le reste des options de configuration de la page na pas besoin dtre modifi pour une installation standard.

Options de timeout
La page suivante prsente les options sur ce qui entre dans les fichiers journaux et les diffrents timeout de Nagios. Une option intressante mettre No est Initial

Configuration applique un systme imaginaire CHAPITRE 15

State Logging. De cette manire, les redmarrages de Nagios nimpliquent pas dajouts en nombre dans le fichier nagios.log.

427

Interaction avec NDO

La page Data permet de spcifier les options NDO et des donnes de performances de Nagios. Il est bon de vrifier que le paramtre Broker Module est gal :
Paramtre Broker Module
/usr/local/nagios/bin/ndomod.o config_file=/usr/local/nagios/etc/ ndomod.cfg

Le paramtre Broker Module Options doit, quant lui, tre gal -1 dans un premier temps. Lorsque la situation sera stabilise, ce paramtre pourra tre remplac par 67108663 dans le cas de lutilisation de Centreon et NagVis.
Ce paramtre a t prsent au chapitre 10.

Les options de mtrologie nont pas besoin dtre modifies. Elles sont paramtres correctement pour que CentStorage puisse rcuprer les donnes et les traiter.

Options de performances
La page de tuning na pas tre modifie pour linstant. Cette page sera en premire ligne dans la bataille contre une latence leve, si ladministrateur doit livrer ce combat.

Pages de dbogage
Les pages Admin et Debug regroupent quelques dtails sur le fonctionnement de Nagios. Il est intressant de regarder les paramtres disponibles pour savoir o en fixer les valeurs, si besoin. Une fois ces lments sauvegards, ladministrateur peut passer au reste de la configuration.

Configuration de NDO dans Centreon

Centreon propose une interface pour la configuration de accessible par les onglets Configuration->Centreon.
ndomod

et

ndo2db.

Elle est

428

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Accs la base de donnes (NDO2DB)

La configuration de NDO2DB se rsume globalement choisir le port TCP couter et prciser laccs la base de donnes. Un seul dmon NDO2DB est ncessaire, mme en cas de supervision distribue. Qui dit un seul dmon dit une seule configuration. La premire page permet de vrifier que le type de socket est bien TCP. Le port par dfaut est le 5668. Sauf raisons particulires, il nest pas ncessaire de le changer. La seconde page permet de configurer laccs la base de donnes. Si le systme de gestion de base de donnes MySQL nest pas hberg en local sur le serveur, il est bon de modifier son adresse. La configuration standard de Centreon considre que la base NDO est nomme ndo. Nous lavons installe sous le nom nagios et nous devons donc changer le paramtrage au sein de Centreon. Le mot de passe superpass doit tre renseign dans le champ ddi. La dernire page permet de fixer les limites de validit des donnes principales. Il nest pas utile de modifier pour linstant ces paramtres. En cas de problmes de volume et dactivit de la base de donnes, ces limites peuvent tre abaisses. Le paramtrage de laccs la base de NDO est utilis pour NDO2DB. Il est galement utilis par Centreon pour obtenir les donnes de supervision disponibles dans la page dalertes temps rel.

NDOMOD
Les fichiers de configuration de NDOMOD sont uniques pour chaque Nagios. Ici nous nen mettons quun en place. Chaque ndomod est reli un poller. Dans le cas du poller principal, lunique valeur modifier est Buffer File. Il est conseill de placer ce fichier dans le rpertoire var de Nagios. Par exemple : /usr/local/nagios/var/ buffer.dat. Dans le cas du Nagios principal, la taille du tampon importe peu. Le processus nayant pas tre redmarr souvent, il y a peu de chance que NDOMOD se retrouve face un port 5668 non disponible. Ils sont sur la mme machine.
ndo2db

REMARQUE Un tampon important pour les sites distants

Si dans le cas dun ndomod et ndo2db situs sur la mme machine, le tampon importe peu, ce nest pas le cas avec des Nagios distants. La taille doit tre inversement proportionnelle la qualit du rseau assurant les liaisons avec ndo2db. Un tampon de 15000 lments nest pas absurde sur une grosse filiale ayant une ligne particulirement mauvaise.

Configuration applique un systme imaginaire CHAPITRE 15

429

Le nom de linstance est par dfaut Central. Dans NagVis, nous avons utilis le nom standard de Nagios, default. Pour que NagVis puisse retrouver ses informations, il faut utiliser le mme nom dinstance.

Application des techniques dhritage dans Centreon

Choix de la mthode de configuration
Nagios et les lments de NDO tant configurs, il est temps de passer la configuration des htes et services. Dans ce domaine, Centreon propose les mmes possibilits que Nagios, une exception prs : il ajoute la possibilit de relier des modles de services des modles dhtes. Comme discut au chapitre 11, cette possibilit est sduisante. Elle laisse une matrise complte sur la configuration. Lensemble des services tant gnrs et indpendants, il est ais den modifier certains pour en faire des exceptions. Cette fonctionnalit est double tranchant : lors de la suppression dun modle de service sur un modle dhte, les services qui ont t gnrs ne sont pas supprims. Lorsque, au bout dun certain temps, ladministrateur souhaite revoir ses packs de sondes, il risque davoir supprimer la main un nombre important danciens services. Si cette vision ninquite pas ladministrateur, il peut exploiter cette possibilit offerte par Centreon. Dans le cas contraire, elle peut faire perdre plus de temps quautre chose, surtout dans les phases initiales.
PRATIQUE Une mthode trs utile sur une configuration stabilise
Au dbut de la mise en place, les services varient fortement mais, une fois la phase de stabilisation passe, ces changements sont beaucoup moins courants. La souplesse apporte par ce type de configuration peut devenir ncessaire et, une fois le problme de suppression cart, ladministrateur a tout intrt ladopter.

Configuration des commandes et des contacts

Des commandes dj configures
Les commandes se trouvent dans longlet Configuration->Commands de Centreon. De nombreuses entres existent dj. Par exemple, Centreon fournit des plug-ins bass sur le protocole SNMP. Ces sondes sont trs pratiques pour avoir un premier niveau de supervision sur les lments distants sans avoir dagent dployer. Elles

430

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

surveillent la charge des machines, observent les processus qui y sont lancs ou bien obtiennent les informations sur le trafic rseau. Ces commandes sont malheureusement limites lorsque la supervision se complexifie. Dans ce cas, la mise en place dun agent est indispensable. Nous lavons dj voqu prcdemment, les deux agents systme les plus rpandus sont NRPE pour les Unix et NSClient++ sur Windows. Nous allons voir par la suite comment configurer les commandes pour les interroger. Dautres sondes sont paramtres dans Centreon. Les tests rseau simples sont particulirement reprsents. La commande check_dhcp est prte lutilisation ainsi que les commandes check_dns, check_ftp et check_http. Les commandes dinterrogation du serveur de supervision sont dj prsentes. Elles comportent dans leur nom le terme local.

Facilits de configuration apportes par Centreon

Pour rajouter une nouvelle commande, il suffit de cliquer sur le lien add prsent en haut de la liste des commandes. On saisit tout dabord le nom de la nouvelle commande, puis sa ligne dappel. Dans cet exercice, Centreon propose quelques fonctionnalits faisant gagner un temps prcieux aux administrateurs. Sur la droite de la page, plusieurs listes droulantes proposent des valeurs. La premire fournit la liste des macros utilisateur de type $USER1$. La seconde donne la liste des sondes prsentes dans le rpertoire libexec de Nagios. Ladministrateur na pas besoin douvrir un shell pour consulter la liste des fichiers et retrouver le nom exact de la sonde, Centreon le fait pour lui. La dernire des listes est la plus pratique : elle fournit lensemble des macros dfinies au sein de Nagios. Il est simple de rajouter la macro $HOSTADDRESS$ sans se tromper dans son orthographe. Une fois la commande entre avec ses arguments $ARG1$, $ARG2$, etc., il est important de la tester afin de vrifier quelle remplit bien son rle. Les champs Argument Example et $HOSTADDRESS$ sont positionns cet effet. Ils permettent de simuler un vritable appel la commande avec des arguments, comme le ferait Nagios. Une fois ces cases remplies et la petite icne en forme de triangle slectionne, une nouvelle page souvre avec le rsultat de la commande. Il existe quelques restrictions ce test. Tout dabord, la sonde appele doit tre place dans le rpertoire libexec de Nagios, sans quoi Centreon refusera de la lancer pour des raisons de scurit. La seconde limitation relve du compte avec lequel ce test est effectu : le compte du serveur web, apache sur un systme RedHat. Tout comme il est fortement dconseill de lancer en tant que root des commandes faisant appel des fichiers intermdiaires, les excuter avec apache conduira aux mmes problmes de droits sur les fichiers. Lorsque ladministrateur utilise cette fonctionnalit dans

Configuration applique un systme imaginaire CHAPITRE 15

431

Centreon, il doit tre certain que son lancement avec un utilisateur autre que nagios ne causera pas de problmes. Si le test nest pas concluant, cest peut-tre parce que ladministrateur na pas su utiliser la sonde correctement. Il peut afficher laide des plug-ins depuis Centreon. ct du menu droulant donnant la liste des fichiers prsents dans le rpertoire libexec, une petite icne permet dappeler lexcutable avec largument -h. Ce dernier sert dans la quasi-totalit des cas fournir la syntaxe et les possibilits des plug-ins. Une fois la documentation relue, ladministrateur peut corriger sa configuration et refaire un test.
REMARQUE La base de connaissances la rescousse
L encore, la base de connaissances a tout son intrt. Si elle est bien renseigne, ladministrateur doit y trouver un exemple dutilisation des sondes. Son travail nen est que facilit.

Une fois le test concluant, il peut sauvegarder la commande, comme commande de vrification ou bien de notification. Cette distinction, non prsente dans Nagios, permet de filtrer un peu les commandes prsentes aux administrateurs dans le reste de la configuration de Centreon.

Configuration des sondes check_nrpe et check_nt

Les sondes dinterrogation des agents sont un peu particulires. Elles prennent en argument des paramtres pour leur fonctionnement interne mais galement relatifs lobjet demander. Elles peuvent galement fournir des arguments aux commandes distantes, si ladministrateur le souhaite. Dans la plupart des situations, une perte de connexion sur une interrogation dun agent ne doit pas aboutir la notification dun administrateur. Le retour de la commande doit tre un UNKNOWN et non pas un WARNING ou un CRITICAL. Pour avoir ce fonctionnement avec check_nrpe, il suffit dutiliser le paramtre -u. Le passage dargument est galement possible avec NRPE. Pour cela, il faut utiliser le paramtre -a. Les arguments qui suivent sont fournis lagent NRPE. Ce paramtre doit tre le dernier de la commande. Si les administrateurs souhaitent ou non utiliser des arguments sur les agents NRPE, il faut dfinir la commande avec le paramtre -a. Par dfaut, Nagios arrte une commande de vrification au bout de 10 secondes. Le niveau dalerte est alors CRITICAL. Le dlai dabandon de la recherche par check_nrpe est galement de 10 secondes. Il narrivera pas au bout pour placer un UNKNOWN si Nagios larrte juste avant. Nagios dmarre son compteur peu de temps avant de lancer check_nrpe. Il est conseill de placer la valeur de timeout de check_nrpe juste en dessous de 10 secondes pour viter ce problme et obtenir rellement un tat UNKNOWN. Le paramtre ddi est -t.

432

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Une commande standard de check_nrpe sera :

Dfinition de la commande check_nrpe
$USER1$/check_nrpe -H $HOSTADDRESS$ -t 9 -u -c $ARG1$

la configuration du service appelant cette commande, ladministrateur naura plus qu placer correctement la valeur de $ARG1$. La commande check_nt ne peut pas renvoyer un tat UNKNOWN en cas de problme de connexion. Ses arguments sont un peu plus limits que check_nrpe. Elle peut, contrairement cette dernire, vrifier les valeurs reues. Cest le but des paramtres -w et -c. Pour spcifier la valeur demander, il faut utiliser le paramtre -l. Enfin le paramtre -s permet de fournir un mot de passe de connexion lagent. Il est conseill, dans le cas de check_nt, de crer plusieurs commandes dans Centreon : une pour chaque valeur quil est possible de demander. Ladministrateur naura plus qu placer les seuils dalertes en arguments. Par exemple, pour la commande de vrification de la consommation CPU sur les deux dernires minutes :
Appel check_nt sur la charge CPU
$USER1$/check_nt -H $HOSTADDRESS$ -v CPULOAD -s "superpass" -l 2,$ARG1$,$ARG2$

Commande denvoi des e-mails

Centreon propose une commande denvoi dalertes par e-mail, une pour les htes, et une pour les services. Nous avons vu au chapitre 6 que mettre de la couleur dans les e-mails peut tre bnfique. Un lien vers la base de connaissances est aussi fortement recommand. Pour cela, nous allons utiliser les scripts sendmailservices.pl et sendmailhost.pl. Une fois ces scripts tlchargs depuis le site Nagios Exchange, placs dans le rpertoire libexec de Nagios et leurs droits dexcution donns pour lutilisateur nagios, il est possible de les configurer dans Centreon. Dans la page Configuration->Commands->Notifications, il faut ajouter une commande de notification et entrer :
Commande send-email-host-color
$USER1$/sendmailhost.pl "$NOTIFICATIONTYPE$" "$HOSTNAME$" "$HOSTSTATE$" "$HOSTADDRESS$" "$HOSTOUTPUT$" "$SHORTDATETIME$" "$CONTACTEMAIL$"

Configuration applique un systme imaginaire CHAPITRE 15

433

Et pour les services :

Commande send-email-service-color
$USER1$/sendmailservices.pl "$NOTIFICATIONTYPE$" "$SERVICEDESC$" "$HOSTALIAS$" "$HOSTADDRESS$" "$SERVICESTATE$" "$SHORTDATETIME$" "$SERVICEOUTPUT$" "$CONTACTEMAIL$" "$SERVICENOTESURL$"

Configuration des contacts

Une fois les commandes de vrification en place, on peut configurer les contacts. Ceci se passe dans longlet Configuration->Users. Chaque administrateur a besoin dun contact. Il est mme recommand den dfinir un second pour les priodes dastreinte. Les priodes de notification, que lon peut dfinir dans le mme onglet, sont accroches un contact et non pas une commande de notification. Un point ne pas oublier concerne les messages de types recovery : certains ne souhaitent pas les recevoir, il faut respecter leur choix. Au niveau de la commande denvoi des notifications par e-mail, ladministrateur doit enlever notify-by-email et mettre la place send-email-service-color pour les services et send-email-host-color pour les htes. Il suffit dappliquer les demandes des utilisateurs quant aux priodes o ils souhaitent tre avertis et les diffrentes manires dont ils sont notifis. Dans cette page, on peut donner accs, ou non, linterface de Centreon. En rgle gnrale, il est conseill de laisser cette possibilit aux utilisateurs. Si le contact est not comme Admin de Centreon, il naura aucune limite en ce qui concerne ses possibilits de navigation et de configuration. Il nest pas recommand de qualifier systmatiquement les administrateurs en Admin, mais de les placer sous ACL afin quils ne puissent faire dans Centreon que ce quils savent faire. Ce sujet sera trait un peu plus loin dans ce chapitre.

Configuration des htes

Commencer par les modles
Le nombre de nuds configurs tant gnralement important, le rle des modles est primordial dans la bonne tenue dune configuration de Nagios. Au moins deux niveaux de modles sont dfinir : les modles gnraux ; les modles de types de systmes.

434

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Les premiers sont peu nombreux. Ils servent dfinir la mthode gnrale de supervision. La mthode active est gnralement utilise dans la supervision des htes, mais une supervision totalement passive est possible : ce seront nos deux modles dordre gnral. Le premier,
generic-host, Check Interval

existe dj dans Centreon. Les notifications et mis part, les valeurs proposes sont correctes.

Normal

Le paramtre Notification Interval est positionn 0 : cela signifie quune seule notification sera leve. Il est plutt conseill denvoyer le message une fois par jour. De cette manire, un message pass inaperu a encore des chances dtre lu le lendemain. Le paramtre devient donc 1440 (60 minutes 24 heures). Le paramtre Notification placer sur Yes.
Enabled

est, par dfaut, sur

No,

il est conseill de le

Le paramtre Check Interval na pas de valeur par dfaut et il est conseill den mettre une. Dans le cas contraire, les htes ne sont pas surveills activement, ce qui nest pas le but recherch. Pour crer le second modle, il est possible de partir du premier. Pour cela, il faut le slectionner et utiliser loption duplicate dans le menu droulant. Apparat alors un generic-host_1, quil faut renommer en generic-passive-host. Les champs modifier sont : Check Command : check_dummy Normal Check Interval : 0 Max Check Attempts : 1 Active Checks Enabled : yes->no Passive Checks Enabled : no->yes Les modles de systmes hritent des deux modles prcdents. Ils dfinissent simplement une nouvelle commande de vrification. Ceci ne sapplique, bien entendu, quaux vrifications actives. La commande de prdilection dans ce cas est check_tcp avec les ports dadministration des machines. Il est conseill dutiliser un timeout faible. Cette vrification doit tre rapide : si un lment ne rpond pas en moins de 3 secondes, il peut tre considr comme inaccessible. Des temps plus levs empchent tout change efficace.

Dfinir les groupes

Une fois les modles dfinis, les sept groupes que nous avons explicits prcdemment doivent tre crs. Ils forment les groupes de base auxquels dautres viendront sajouter.

Configuration applique un systme imaginaire CHAPITRE 15

435

Ces groupes supplmentaires sont ncessaires pour certains services trs particuliers. Les htes doivent faire partie dau moins un groupe de base. Les packs de services sont appliqus ces groupes, ce qui garantit alors une supervision minimale des lments constituant le systme dinformation.

Configuration fastidieuse des nuds

Une fois les groupes dfinis, il est temps de crer les htes. Pour cela, il faut faire appel le plus possible aux modles. De manire idale, un hte ne devrait avoir comme paramtres quun modle, un nom et une adresse. Si cest possible, les contacts doivent tre placs dans les modles. De cette manire, la configuration des nuds restera minimale.
PRATIQUE Automatisation de lajout de nuds
Cette phase dajout des nuds peut tre longue. Si ladministrateur est capable de gnrer la configuration de Nagios dans des fichiers plats, il peut importer la configuration dans Centreon par la page Configuration->Nagios->Load : le gain de temps est considrable. Les commandes awk et sed seront dune grande aide pour cet exercice.

Configuration des services

Quelques principes de bon sens : nommage et parcimonie
Lorsque deux indicateurs sont similaires mais sappliquent deux groupes diffrents, il est important de conserver le mme nom de service. De cette manire, on facilite lapprentissage des alertes pour les administrateurs. Par exemple, que ce soit sur un systme Windows ou un systme Linux, une alerte de charge processeur se nommera CPU. la premire mise en place dun indicateur, le nombre dessais en cas de retour anormal doit tre un peu plus lev que ce qui est initialement prvu. Lors des premires prises de contacts avec loutil, il est important de ne pas brusquer les administrateurs. Sils reoivent trop dalertes identiques, ils peuvent se braquer inutilement contre la vrification, voire contre loutil sils le dcouvrent. La premire image quils doivent avoir nest pas celle dun outil qui les submerge par une avalanche dalertes. Sils pensent que certaines alertes doivent tre remontes plus souvent, ce choix leur appartient. Ils auront limpression damliorer loutil et sy intresseront davantage.

436

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Commencer encore par les modles

Les premiers services configurer ou modifier sont les sont ncessaires : generic-service ; generic-passive-service.
templates.

Au moins deux

Le premier sert aux services actifs, le second aux vrifications passives. Le premier est dj dfini au sein de Centreon. Sa configuration standard est dj satisfaisante, hormis un point : les notifications, comme pour les htes. Les mmes changements de paramtres Notification Interval et Notification Enabled sont ncessaires. Il est conseill de supprimer tous les contacts dfinis dans ces modles. De cette manire, les services nont pas de contacts sils nen dfinissent pas. Les notifications sont alors envoyes aux administrateurs des machines, comme spcifi dans la configuration des nuds. Cest lhritage implicite qui sapplique. Pour crer le second modle, il faut procder comme pour les htes, par une duplication du premier. Les champs modifier sont alors : Is volatile : no-> yes Check Command : check_dummy Normal Check Interval : 0 Max Check Attempts : 1 Retry Check Interval : 0 Active Checks Enabled : yes->no Passive Checks Enabled : no->yes Sur le modle, nous ne dfinissons pas de vrification de la fracheur. Tous les traitements tant diffrents sur ce point, le modle ne servira rien. Ces deux modles configurs, ils peuvent servir de base pour dautres modles plus fins comme ceux nenvoyant pas de notifications ou bien seulement sur certaines priodes de notification.

Les packs dabord

Les htes tant configurs et placs dans des groupes, il est temps de mettre en place les commandes communes aux systmes. Nous utilisons les commandes dfinies prcdemment. Il est important de dfinir le moins de services possibles, mais les particularits des htes ne doivent pas tre oublies. Pour grer ces exceptions, il est important de grer au mieux les possibilits de Nagios et des agents. Par exemple, au lieu de placer les arguments dans le service, il est possible de les placer dans la configuration de NRPE. Grce aux possibilits offertes

Configuration applique un systme imaginaire CHAPITRE 15

437

par le fichier specifique.cfg sur chaque hte, on peut dfinir des exceptions facilement si Nagios nest pas capable de le faire. Ce point a t tudi au chapitre 4. Lorsque cest possible, la configuration doit tre gre au sein de Nagios directement. Pour cela, il ne faut pas oublier dappliquer les techniques dhritage, et notamment celle base sur les macros variables. Ces techniques sont tout particulirement adaptes dans le cas des services rseau SNMP, mais tout argument propre une machine peut tre utilis par ce biais.

Les particularits de la supervision systme ensuite

Certains systmes ont des particularits. Par exemple, tous les serveurs nont pas de pare-feu. Sur ceux qui en possdent, on doit raccrocher un service afin de vrifier leur tat et leurs alertes. Deux solutions sont envisageables dans cette situation : ne mettre le service que sur les machines en question ; le dployer sur toutes les machines. Dans le premier cas, une configuration supplmentaire est ncessaire. Si seules quelques machines sont concernes, on peut placer le service directement dessus. Si le nombre de machines commence tre important, un groupe est ncessaire. La solution par ajout sur les htes peut sembler prsenter un gain de temps, mais elle est double tranchant : lorsquune nouvelle machine arrive dans linfrastructure, elle doit tre qualifie en fonction des services dont elle a besoin. Bien sr, elle est place dans un groupe principal dhtes. Elle hrite automatiquement de tous les services qui y sont raccords. Pour les services secondaires, si ladministrateur a plac des services directement sur les machines, il doit dresser la liste de tous les services pour trouver ceux qui sappliquent la machine. Sil avait cr des groupes, il naurait qu parcourir leur liste, gnralement plus succincte, et rajouter la nouvelle machine dans les groupes ncessaires. La seconde solution pour grer les particularits consiste appliquer le service, et donc une commande de vrification, lensemble des nuds. Bien que sduisante, cette mthode nest pas applicable toutes les situations. Le principe consiste renvoyer un rsultat OK lorsque llment superviser nexiste pas. Si la vrification a pour rle de tester sa prsence, la contradiction est totale. Le test ne pourra alors tre lanc que sur des machines particulires. Dans le cas contraire, si la sonde oublie le cas o lobjet nexiste pas, elle peut tre utilise partout. Des tests seront lancs pour rien sur certains htes, mais la configuration est fortement simplifie. Ladministrateur peut faire le choix de la performance ou dune configuration plus rduite. Nous pouvons prendre comme exemple le cas de la vrification des liens dun agrgat rseau sous Linux. Lintrt de cette vrification est de dtecter quune interface de

438

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

lagrgat est tombe. Si les informations sur lagrgat ne sont pas disponibles, la sonde check_bonding.pl renvoie un avertissement. Ce cas nest pas particulirement utile. Si lagrgat nest pas disponible, les services qui y sont hbergs et qui sont tout de mme surveills renvoient une erreur. Si cest le lien principal, le serveur est tout simplement dclar DOWN. Une modification intressante consiste changer ce comportement. Il suffit dadapter le code suivant (ligne 109) :
Check_bonding.pl avant
if (not $message) { $message = "No bond information found"; $err = 1; }

en :
Check_bonding.pl aprs
if (not $message) { $message = "No bond information found"; $err = 0; }

Lorsque la sonde est lance sur un serveur nayant pas dagrgat, elle ne renvoie pas derreur. Cette vrification peut tre dploye sur lensemble des serveurs au lieu dune sous-partie dentre eux. Plutt que de dfinir un nouveau groupe nomm ServeursBonding, on peut rajouter le service dans le pack commun tous les Linux.

Les applications pour finir

Une fois que les lments de linfrastructure sont superviss, il est temps de passer aux applications quils hbergent. Si la supervision systme est commune dun systme dinformation un autre, les applications ne sont pas du tout les mmes. Il est courant darriver ce stade, sans avoir dfini les commandes utilises pour superviser les applications. Si cest le cas, il faut se tourner vers les sondes. Les mthodes de supervision du chapitre 4 sont appliquer. Les mthodes de dtection de ports ouverts montrent trs rapidement leurs limites. Elles sont cependant les seules utilisables dans certaines situations. Les applications web et celles, plus gnralement, reposant sur un protocole ouvert, sont plus faciles superviser. Se faire passer pour un client est la meilleure des mthodes de supervision. Limportant est ce quattendent les vrais utilisateurs, et non davoir des processus au niveau systme qui semblent bien lancs.

Configuration applique un systme imaginaire CHAPITRE 15

439

Parfois, les applications sont disperses sur plusieurs machines. Dans ce cas, le fait daccrocher le service un serveur plutt quun autre nest pas vident. Si une adresse virtuelle est disponible, elle doit tre surveille. Pour cela, il faut dfinir un nouvel hte et le service pourra lui tre affect. Dans certains cas, lapplication est vraiment disperse. Elle ne possde pas dadresse virtuelle. Pourtant, un ensemble de services est possible. Dans cette situation, il ne faut pas hsiter dfinir un hte virtuel. Ce dernier est tout simplement une coquille vide qui a pour nom lapplication surveille. Il ne sert qu accrocher des services pour Nagios. Un bon modle pour ces nuds est lhte passif. Si personne nenvoie dinformation son sujet, il nest jamais en erreur.

Ne pas oublier la base de connaissances

Dans la page Service Extended Info des services et des htes, Centreon propose le champ URL que nous utilisons comme lien vers notre base de connaissances. Chaque service devrait avoir son entre dans cette base.

Configuration des ACL

La notion dACL est spcifique Centreon. Elle permet de grer les accs aux pages de lapplication ainsi que les lments prsents aux administrateurs. Toute la configuration est base sur les groupes de contacts. Ces derniers se voient relis des htes ou des services. Cette configuration est malheureusement dissocie de celle des notifications des lments. Une fois relis des objets, ils se voient autoriser laccs certaines pages. La slection est trs fine. Dans la plupart des situations, laccs aux pages de configurations des htes et services, aux pages de supervision et aux diagrammes de performances sont suffisants pour les contacts standard. Sils ne sont pas forms la configuration au sein de Nagios, la partie Configuration doit leur tre interdite.

Gnration de la configuration par Centreon

Une fois tous les lments configurs, Centreon peut gnrer la configuration finale. Ceci se passe dans la page Configuration->Nagios. Centreon peut gnrer la configuration pour chaque Nagios dfini. Ce choix seffectue avec le menu droulant Nagios Server, o sont lists lensemble des pollers dfinis par ladministrateur et une entre nomme All Nagios Servers. Tout comme pour la configuration de Nagios, il est fortement recommand de faire un test avant de gnrer rellement le fichier. Si, dans la situation actuelle, il ny a rien perdre, prendre cette habitude ds le dbut vitera de gros problmes par la suite.

440

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Loption Generate Configuration Files demande Centreon de crer les fichiers de Nagios partir des informations contenues dans sa base de donnes. Cette gnration se fait dans le rpertoire /usr/local/centreon/filesGeneration/nagiosCFG. Chaque Nagios possde un rpertoire, dans lequel se trouve lensemble des fichiers qui le concernent comme nagios.cfg ou ndomod.cfg. Dans le premier rpertoire, celui du serveur Nagios principal, se trouve galement le fichier ndo2db.cfg. Ce dmon ntant prsent que sur ce serveur, il est gnr seulement dans ce rpertoire. Centreon, avec loption Run Nagios Debug (-v) permet de lancer Nagios en mode vrification de configuration, avec loption -v. On peut utiliser cette vrification pour la configuration du Nagios local, ou sur nimporte quelle configuration des Nagios distants. En une seule demande, il est possible de vrifier lensemble des configurations Nagios du systme. Pour cela, deux fichiers nagios.cfg sont crs dans le rpertoire temporaire. Le second se nomme nagiosCFG.DEBUG. Son unique diffrence avec le premier porte sur le chemin dinclusion des appels cfg_file. Le fichier principal de Nagios a pour rle dappeler les fichiers hosts.cfg, services.cfg, etc. Si lappel de vrification se fait sur le fichier normal, les chemins pointent sur /usr/local/nagios/etc. Ce chemin est celui de la version actuelle de Nagios, pas de la nouvelle configuration gnre. Cest pour cela que le fichier .DEBUG possde le chemin temporaire. Une vrification lance sur ce fichier permet de vrifier la nouvelle configuration. Si cette tape de vrification sest bien droule, ladministrateur peut demander, avec loption Move Export Files, de dplacer ces fichiers de configuration temporaires vers leur destination relle /usr/local/nagios/etc. Ladministrateur a le choix entre trois mthodes de redmarrage : redmarrage du service ; rechargement du service ; rechargement par commande externe. Les deux dernires mthodes aboutissent au mme rsultat. Nagios doit tre dj dmarr. Pour notre premier lancement, nous devons faire appel la premire mthode. Par la suite, le rechargement vite de repasser par une phase potentiellement longue de rechargement du module ndo. La commande lance, le rsultat est fourni pour chaque Nagios. Une rapide lecture permet de voir si des problmes sont survenus. Nagios est lanc, ladministrateur peut consulter le rsultat sur longlet Monitoring. Malheureusement, il ny a aucune information. Aucune machine nest prsente.

Configuration applique un systme imaginaire CHAPITRE 15

441

Si nous regardons le fichier journal de Nagios, nous remarquons la ligne suivante que son dmarrage a gnr :
Erreur en provenance de Ndomod
ndomod: Could not open data sink! I'll keep trying, but some output may get lost...

narrive pas envoyer ses donnes et pour cause : ndo2db nest pas lanc. Pour corriger cela, il faut le dmarrer avec le compte nagios :
Ndomod

Lancement de Ndo2db
/usr/local/nagios/bin/ndo2db -c /usr/local/nagios/etc/ndo2db.cfg

Une fois la commande lance, nous vrifions que informations :

Dchargement du tampon de ndomod dans ndo2db

ndomod

a bien russi envoyer ses

[1234290317] ndomod: Successfully connected to data sink. 3433 queued items to flush. [1234290318] ndomod: Successfully flushed 3433 queued items to data sink.

Sur la page de supervision de Centreon, nous commenons voir arriver les entres. Notez que Centreon vrifie les entres dans la base nagios remplie par ndomod. Il faut un certain temps pour quelles soient ajoutes dans la base. Ce dlai est de Maximum Service Check Spread minutes. Au bout de ce dlai qui, par dfaut, est gal 5 minutes, toutes les entres devraient tre prsentes. Dans la partie supervision, les diffrentes vues permettent aux administrateurs de sy retrouver simplement parmi tous les indicateurs. Les filtres sur les tats Acknowledged sont pratiques. Si les administrateurs renseignent effectivement leur prise en compte des erreurs, la vue de Centreon peut sen trouver fortement allge. Seules les nouvelles erreurs dont personne ne soccupe sont prsentes. Ces informations ne seront pas perdues comme nous le verrons par la suite.

Cration des vues agrges dans NagVis

Nagios et Centreon tant configurs, il est temps de soccuper de NagVis.

442

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Sparation des diffrents types de cartes

Deux types de vues vont tre dfinis dans NagVis : des vues pour les utilisateurs ; des vues prcises des systmes pour les administrateurs. Parmi les premires vues, les utilisateurs souhaitent avoir un tat de lintranet, du serveur de fichiers principal et enfin du systme de courrier lectronique. Ces informations vont tre concentres sur un seul cran. Chaque information sera prsente dans un seul indicateur de couleur.

Mise en place dune nouvelle carte

Le plus long dans la mise en place des vues agrges dans NagVis nest pas la dfinition des indicateurs, ni mme la configuration, mais le dessin du fond. Dans bien des cas, les administrateurs ont un sens artistique tout particulier. Se faire aider sur ce point peut tre utile... Limage doit tre au format PNG pour pouvoir tre intgre dans NagVis. Sur la page principale, un clic droit donne accs un menu, dans lequel le lien manage->map permet de crer une nouvelle carte. Chacune a besoin dun nom unique et de droits en lecture et criture. Pour en autoriser laccs tous, il faut entrer dans les champs EVERYONE. Le Map Iconset permet de spcifier un thme par dfaut de la carte. Ladministrateur peut rajouter son propre thme. Pour cela, se rfrer au chapitre 12. Un nouveau clic droit puis open map permet douvrir la nouvelle carte en criture. Le menu permet dajouter des htes, des services, des groupes ou dautres cartes.

Choix des indicateurs reprsents

Sur la carte ddie aux utilisateurs, seuls trois services sont reprsents. Les indicateurs doivent tre clairs et sans ambigut. Dans la meilleure des situations, les vrifications sous-jacentes doivent tre au plus proche des actions effectues par les utilisateurs. Dans le cas des cartes pour les administrateurs, les informations sont un peu plus compltes. Les htes et services sont utiliss conjointement. Les utilisateurs nont que faire des htes. Seuls les services quils utilisent les intressent. Les administrateurs sont plus concerns par ltat des machines. Dans les cartes des administrateurs, il est conseill de reprsenter les htes et services importants, une famille dapplications par carte. Par exemple, une carte pour lensemble des serveurs responsables de lintranet, que ce soient les serveurs dapplications ou la base de donnes ; une autre carte pour les serveurs de messagerie.

Configuration applique un systme imaginaire CHAPITRE 15

443

Il est important dajouter dans les cartes un indicateur sur ltat global du service. Ces indicateurs permettront de faire la corrlation entre une erreur sur un serveur et larrt du service aux utilisateurs. Les tats des htes peuvent agrger ou non ceux des services qui sont accrochs dessus, ce que lon dfinit avec recognize_services. Il est dconseill dopter pour lagrgation. Les htes peuvent accueillir des services non critiques. Les administrateurs souhaitent avoir les informations sur un nombre restreint dindicateurs, les plus importants. Les informations des autres services des nuds peuvent les induire en erreur.

Une hirarchie de cartes respecter

La hirarchie des cartes est importante. Toutes ne sont pas ncessairement faites pour tre affiches en continu. Elles peuvent tre simplement utilises pour affichage dans une carte de plus haut niveau. Si les administrateurs observent un problme, ils peuvent consulter la carte directement. Il est important davoir une carte globale du niveau le plus lev. En un seul coup dil sur la carte, chacun sait quelle carte regarder. Les rotations sont indispensables dans NagVis lorsque le nombre de cartes devient important. Chaque ple dadministrateurs est intress par quelques cartes seulement. Ce dcoupage permet de dfinir des rotations. lheure actuelle, on utilise pour cela le fichier de configuration de Nagvis :
/usr/local/nagios/share/nagvis/etc/nagvis.ini.php

La dfinition des rotations est simple. Chaque rotation a un nom, une liste de cartes et, enfin, un intervalle de rotation. Par exemple, pour dfinir la rotation nomme system et ayant comme cartes carte1 et carte2 :
Une rotation, system
[rotation_system] ; maps to rotate in this pool maps="carte1,carte2" ; rotation interval (seconds) interval=15

Laccs aux rotations se fait sur la page principale de NagVis. Chaque groupe dadministrateurs doit avoir sa propre rotation.

444

cosystme de Nagios et mise en place de la solution TROISIME PARTIE

Des exemples de cartes pour les administrateurs

Dans le cas du rseau, une carte peut reprsenter le rseau interne. Une autre peut reprsenter le rseau entre les filiales. Pour ce type de carte, les cartes gographiques font de trs bons fonds. La carte interne reprsente les switchs et routeurs. Sur ces derniers, les liens importants sont symboliss par les services PortX/Y entre les lments. Ils sont choisis parmi les liens entre les lments du cur de rseau. Pour la carte globale, les filiales sont reprsentes par lhte du routeur ou pare-feu de la filiale. Cet lment est reprsentatif de la connectivit du site distant. Il pourra tre choisi comme parent des autres serveurs de la filiale dans la configuration de Nagios. Dans le cas des serveurs de type Windows, un bon indicateur sur ltat des applications est le service vrifiant le lancement de tous les services automatiques. En cas de souci avec une application, il y a de fortes chances pour que son service ne soit plus disponible. Si lapplication est directement vrifiable par le rseau, cette dernire mthode est tout de mme privilgier. Les indicateurs sur les systmes Unix sont un peu plus complexes choisir. La plupart du temps, on privilgie un service vrifiant quun processus est bien lanc. L encore, un test direct de lapplication sur le rseau est choisir, sil en existe. Pour chaque hte, on ne doit choisir quun ou deux services. Au del, les vues agrges perdent leur intrt. Si les administrateurs souhaitent avoir lensemble des alertes des htes, lutilisation de Centreon avec des filtres est plus adapte, son affichage est moins expressif. Les administrateurs ont besoin de se rapprocher des crans afin de lire les erreurs. Mais, en matire de rpartition dans les cartes, il est conseill davoir une vue par application, et non par type de serveurs. Lorsquils reoivent une alerte utilisateur, ceux-ci donnent trs rarement le nom de la machine en question. Ils parlent au niveau applicatif. Les cartes permettent de reprsenter cette vue pour les administrateurs et de la transformer en vue serveurs.

En un mot
Une fois quil en a termin avec les vues agrges, ladministrateur peut souffler un moment : il a entre les mains une solution complte de supervision et mtrologie. Il en a une totale matrise et, ayant russi runir tous les administrateurs dans ce projet, a su viter les plus grands cueils dun projet de supervision. Au fils du temps, les alertes vont se prciser et la disponibilit du systme dinformation va faire un vritable bond en avant.

16
Conclusion et perspectives
Nous voici arrivs la fin dune aventure, et au dbut de nombreuses autres. Regardons un peu le chemin que nous venons de parcourir, et voyons ce que Nagios et son cosystme nous rservent pour la suite.

Une solution pleinement fonctionnelle

Arriv ce point, ladministrateur qui a mis en pratique les principes et mthodes dcrites jusquici a dans les mains une solution complte de supervision et de mtrologie. Il connat le rle de chaque lment et, plus important encore, sait comment grer un projet de mise en place dune solution de supervision. Les diffrents processus de ce projet sont importants. Les vrifications vont devenir de plus en plus nombreuses. Les anciennes vrifications vont se perfectionner et devenir plus prcises. Si lorganisation de la configuration est bien pense, et si ladministrateur utilise toutes les ressources de Nagios pour la grer correctement, il naura aucun problme grer un parc important de machines. Les exceptions devraient tre gres souplement grce la gestion de configuration pousse que propose Nagios. mesure que les administrateurs dcrivent de nouveaux problmes, lcriture de sondes pour les dtecter devient ncessaire. Cette tche est simple, mme pour un dveloppeur dbutant.

446

Nagios 3

Une fois la vrification rode, il ne faut pas hsiter la partager avec le reste de la communaut, notamment sur le site Nagios Exchange. Personne ne va se jeter sur un dveloppeur en criant au scandale car une sonde nest pas assez documente. Si cest vraiment le cas, libre chacun de sen occuper et pallier le manque en documentant lui-mme. Les autres membres de la communaut pourront amliorer la vrification. Ladministrateur aura pleinement particip amliorer les solutions bases sur Nagios et la communaut len remerciera.

Nagios, une solution en constante volution

Un chemin important a t parcouru depuis la naissance de Nagios, en 1999, mais il est loin dtre termin. De nombreux contributeurs participent au projet et le nombre dinstallations de Nagios progresse de jour en jour. Arrives maturit, ces solutions nont pas rougir face aux solutions propritaires des grands diteurs. Lcosystme de la supervision open source volue trs rgulirement. Il est important de se tenir inform de lvolution de Nagios. Loutil mrit rapidement et a pour objectif de grer des parcs de plus en plus importants avec le moins de configuration possible. Les architectures bases sur lEvent Broker, notamment NDO, progressent rapidement. Des modules arrivent trs rgulirement. Lun des derniers lheure de la rdaction de ce livre est bronx, un module remplaant astucieusement NSCA. tant encore un peu jeune, il na pas t tudi plus en dtail. Nagios est un carrefour de son volution. Les environnements informatiques grandissent constamment, et les systmes distribus vont prendre de plus en plus dimportance. Rfrence dans le monde de la supervision open source, Nagios gardera sa place tant quil conservera les principes qui font sa force : sa simplicit et sa modularit. Gageons que lauteur et la communaut sauront continuer suivre cette voie pour le plus grand bonheur des administrateurs.

A
Les principales sondes
Nous avons vu au fil de louvrage un certain nombre de sondes. Faisons un rapide tour dhorizon des sondes les plus utilises dans Nagios.
MTHODE Laide sur les sondes : loption -h
Noubliez pas le prcieux argument -h qui permet dafficher la documentation dune sonde...

Supervision des ressources systme locales

check_load
Permet de vrifier lindicateur de charge moyenne (load average) sur les Unix.
Pour plus dinformation sur cette valeur, se rfrer au chapitre 14.

Vrification du load average

check_load -w 1,1,1 -c 2,2,2

448

Nagios 3

check_swap
Permet de vrifier sur les Unix ltat du remplissage du fichier dchange.
Vrification du swap
check_swap -w 50% -c 10%

check_mem
Vrifie ltat des espaces mmoire sur les Unix.
Vrification de la mmoire
check_mem.pl -w 75 -c 95

check_disk
Vrifie les espaces disques disponibles sur les Unix.
Vrification des espaces disques
check_disk -w 10% -c 5%

check_file_age
Permet de vrifier quun fichier a t mis jour rapidement et quil a une taille minimale.
Vrification de la mise jour et de la taille dun fichier
check_file_age -w 60 -c 120 -W 300 -C 500 -f monfichier.log

check_ntp_peer
Permet de vrifier le temps du systme par rapport un serveur NTP.
Vrification de lheure
check_ntp_peer -H ntp.univ-lyon1.fr -w 0.5 -c 1 -W 4 -C 6 -j -1:100 -k 1:200

Les principales sondes ANNEXE

449

La supervision de ltat physique de la machine

check_ide_smart
Cette sonde vrifie les informations SMART des disques. Lorsquun dentre eux devient dfectueux, cette sonde permet de le dtecter.
Vrification de ltat des disques
check_ide_smart -d /dev/hda -n

check_sensors
Les systmes Unix exportent des informations sur ltat de la machine. La commande sensors permet de vrifier ces informations. La sonde check_sensors permet dintgrer ce test Nagios.
Vrification de ltat de la machine
check_sensors

La supervision des applications locales

check_procs
Sur les systmes Unix, cette sonde permet de surveiller les processus et leurs proprits.
Vrification des processus
check_procs -w 1:1 -c 1:1 -C ntpd

check_mailq
Cette commande permet de vrifier de lancer la commande mails en attente denvoi par sendmail ou qmail.
mailq

qui vrifie les e-

450

Nagios 3

Vrification des envois de-mails

check_mailq -w 20 -c 50

check_log2
Permet de vrifier les nouvelles entres dans un fichier de log entre deux tests.
Pour plus dinformations sur cette sonde, se rfrer au chapitre 7.

Vrification dun fichier de log

check_log2.pl -l fichier.log -s fichier.tmp -p Alerte -c

La supervision des services distants

check_tcp pour les services ftp, dhcp, (s)pop, (s)smtp, (s)imap, nntp(s), jabber, etc.
Toutes les sondes suivantes sont en fait une seule et mme sonde : check_tcp. Elle permet de vrifier louverture dun port. Si le protocole utiliser est de type texte, un message peut tre envoy et le retour analys.
Vrification de louverture dun port TCP
check_tcp -H serveur -p 21 -s Question -e Rponse

check_udp
Identique la sonde prcdente mais pour les ports UDP.
Vrification de louverture dun port UDP
check_udp -H serveur -p 161 -s Question -e Rponse

check_dhcp
Permet de vrifier quun serveur DHCP rpond bien aux demandes dadresse IP.

Les principales sondes ANNEXE

451

Vrification du fonctionnement dun serveur DHCP

check_dhcp -i eth0 -s 192.168.0.254 -r 192.168.0.1

check_dig check_dns
Ces sondes permettent dinterroger un serveur DNS et de vrifier des enregistrements.
Vrification des enregistrements DNS
check_dig -l www.google.fr -H 212.27.40.240

check_flexlm
Cette sonde permet de vrifier le bon tat dun serveur de licence de type flexlm.
Vrification de ltat dun serveur de licence
check_flexlm -F license.dat

check_smtp
Cette sonde permet de vrifier le bon fonctionnement dun serveur SMTP.
Vrification dun service SNMTP
check_smtp -H smtp.free.fr -U user -P pass

check_http
Cette sonde permet de faire une vrification simple daccs une page web.
Vrification dune page Web
check_http -H serveur -u /path

check_oracle
Ce plugin permet de vrifier diverses informations sur ltat dune base de donnes Oracle : connexion au listener, tat des caches, remplissage des tablespaces... Cette sonde a besoin dun client Oracle pour fonctionner.

452

Nagios 3

Vrification de ltat dune base Oracle

check_oracle --tablespace MABASE user superpass MyTABLESPACE 80 90

check_mysql et check_pgsql
Ces sondes permettent de tester des connexions des bases MySQL et PostgreSQL.
Vrification dune base MySQL
check_mysql -u user -p pass -d base

Vrification dune base PostgreSQL

check_pgsql -l nagios -p superpass -d nagios

La supervision des systmes distants

check_icmp check_fping check_ping
Le test de rponse une requte ICMP est un moyen simple de vrifier quune machine est encore connecte au rseau. Les trois sondes effectuent cette requte. La plus lgre est check_icmp.
Vrification dune rponse ICMP dun serveur
check_icmp -H serveur

check_hpjd
Les imprimantes rseau de marque HP possdent pour la plupart une interface JetDirect. Cette dernire permet de superviser limprimante distance par SNMP. La sonde check_hpjd permet deffectuer cette vrification.
Vrification de ltat de limprimante
check_hpjd -H imprimante -C public

Les principales sondes ANNEXE

453

check_centreon_snmp_traffic
Les liens des lments rseau peuvent tre surchargs ou tout simplement indisponibles. La sonde check_centreon_snmp_traffic permet de suivre le trafic dun lien et de vrifier quil est en bon tat.
Vrification de ltat dun lien rseau
check_centreon_snmp_traffic -H switch -C lecread -i NomDuPort -n -r

check_snmp
Les informations publies par SNMP sont nombreuses. La sonde check_snmp est gnrique. Elle permet de faire une interrogation dune ou plusieurs OID. Une fois le rsultat obtenu, il est possible de le comparer avec des seuils dfinis par ladministrateur.
Vrification dune information SNMP
check_snmp -H serveur -o HOST-RESOURCES-MIB::hrSystemUptime.0

check_disk_smb
Les partages de fichiers Windows sont nombreux. Leur supervision peut tre faite avec la sonde check_disk_smb. En plus de vrifier ltat du partage, elle permet galement de vrifier que lespace nest pas plein.
Vrification de ltat dun partage
check_disk_smb -H 192.168.0.14 -S Jean -w 80% -c 90%

check_ups
Llectricit tant une ncessit premire pour tout systme dinformation, il est courant de recourir des onduleurs de type UPS. Leur supervision est importante. La sonde check_ups est ddie cette tche.
Vrification de ltat dun onduleur
check_ups -H IpUps -u UPS

454

Nagios 3

check_snmp_load, check_snmp_mem, check_snmp_storage

Ces sondes effectuent le mme travail que celles pour les systmes locaux, mais effectuent la vrification sur des serveurs distants via SNMP.
Vrification de la charge par SNMP
check_snmp_load.pl -H serveur -C public -w 1,1,1 -c 2,2,2 -T netsl -f

Vrification de la mmoire par SNMP

check_snmp_mem.pl -H serveur -C public -w 80,80 -c 90,90 -f

Vrification de lespace disque des lecteurs C, F, G, H et I dun Windows

check_snmp_storage.pl -H serveur -C public -w 80% -c 90% -m ^[CFGHI]:

check_snmp_win
Les services sous Windows sont pratiques pour superviser les applications qui sy trouvent. Ces informations sont disponibles par SNMP. La sonde check_snmp_win permet de superviser ltat dun ou de plusieurs services.
Vrification de ltat dun service par SNMP
check_snmp_win.pl -H serveur -C public -n Service

Les sondes utilitaires pour Nagios

check_nagios
Lors de la mise en place darchitectures distribues ou hautement disponibles de Nagios, une sonde est ncessaire pour vrifier quau moins un des processus Nagios fonctionne toujours correctement.
Pour plus dinformation, se rfrer au chapitre 10.

Vrification de ltat dun Nagios

check_nagios -F /usr/local/nagios/var/nagios.log -e 20 -C /usr/local/ nagios/bin/nagios

Les principales sondes ANNEXE

455

check_dummy
Dans le cadre de la supervision passive, Nagios est amen lancer une sonde pour vrifier ltat dun lment. Cette commande va devoir renvoyer ce que demande ladministrateur. La sonde check_dummy est faite pour cela : elle renvoie ltat et le texte pass en argument.
Pour plus dinformation sur ce fonctionnement, se rfrer au chapitre 7.

Fausse vrification
check_dummy 2 ''Traitement en retard''

check_nrpe, check_by_ssh et check_nt

Les agents situs sur les htes ont aussi besoin de leur propre commande pour tre interrogs.
Interrogation dun agent NRPE
check_nrpe -H serveur -c commande

Interrogation dune commande par SSH

check_by_ssh -H serveur -C :usr/local/nagios/libexec/check_load

Interrogation du nombre de processus dun agent NSClient++

check_nt -H serveur -v INSTANCES -l Process

check_cluster
La commande check_cluster permet de faire une agrgation dtats au sein de Nagios. Les administrateurs peuvent tre avertis lorsquun certain nombre de services dun cluster sont tombs.
Vrification de plusieurs tats en un seul test
check_cluster -s -d 0,0,0

B
Options de configuration de nagios.cfg
Nous navons vu quune partie des options de configuration prsentes dans le fichier nagios.cfg. Cette annexe dresse la liste des paramtres et prsente leur rle.

Dclaration des fichiers

log_file
Chemin vers le fichier de journalisation principal de Nagios.
log_file=/usr/local/nagios/var/nagios.log

cfg_file
Chemin vers un fichier de configuration inclure.
cfg_file=/usr/local/nagios/etc/objects/commands.cfg

458

Nagios 3

cfg_dir
Chemin vers un rpertoire. Tous les fichiers comme fichiers de configuration.
cfg_dir=/usr/local/nagios/etc/servers .cfg

qui sy trouvent sont chargs

object_cache_file
Fichier o Nagios exporte sa configuration pour que les outils tiers la parcourent. Il est gnr chaque lancement de Nagios.
object_cache_file=/usr/local/nagios/var/objects.cache

precached_object_file
Fichier o Nagios exporte sa configuration lorsquil la vrifie. Il peut tre lu lors du lancement afin de ne pas avoir revrifier la configuration. Cette dernire opration peut prendre du temps.
precached_object_file=/usr/local/nagios/var/objects.precache

resource_file
Fichier de configuration o ladministrateur dfinit les valeurs $USERN$, N allant de 1 32. Ces valeurs ntant pas accessibles aux interfaces graphiques, cest un bon emplacement pour les mots de passe.
resource_file=/usr/local/nagios/etc/resource.cfg

status_file
Fichier mis jour rgulirement o sont placs les tats des lments superviss. Les applications tierces peuvent y lire les informations dont elles ont besoin.
status_file=/usr/local/nagios/var/status.dat

Options de configuration de nagios.cfg ANNEXE

459

status_update_interval
Intervalle de temps, en secondes, auquel le fichier dtats est gnr.
status_update_interval=10

Configuration de la supervision
nagios_user
Compte systme avec lequel le dmon fonctionne. Ce compte ne peut pas tre root.
nagios_user=nagios

nagios_group
Groupe de lutilisateur prcdent.
nagios_group=nagios

check_external_commands
Boolen permettant de savoir si Nagios doit ou non lire le fichier de commandes externes.
check_external_commands=1

command_check_interval
Intervalle de temps entre deux lectures du fichier de commandes externes. Si cette valeur est entire, lintervalle est un multiple de interval_length (en gnral 60 secondes). Pour lexprimer en secondes, il suffit de le faire suivre dun s (exemple : 15s). Si la valeur est gale -1, le fichier est lu aussi souvent que possible.
command_check_interval=-1

460

Nagios 3

command_file
Fichier de commande externe. Cest un tube nomm cr au lancement du dmon. Lutilisateur excutant ce dernier doit avoir les droits adquats sur le rpertoire.
command_file=/usr/local/nagios/var/rw/nagios.cmd

external_command_buffer_slots
Nombre demplacements dans le tampon des commandes externes qui nont pas encore t traites. La commande nagiostats permet dvaluer son remplissage.
external_command_buffer_slots=4096

lock_file
Fichier o le dmon place son pid afin dviter de se lancer plusieurs fois.
lock_file=/usr/local/nagios/var/nagios.lock

temp_file
Fichier temporaire cr par Nagios, renomm comme fichier dtats une fois rempli. De cette manire, ce dernier est toujours cohrent.
temp_file=/usr/local/nagios/var/nagios.tmp

temp_path
Chemin utilis par Nagios pour y placer ses fichiers temporaires.
temp_path=/tmp

Options de configuration de nagios.cfg ANNEXE

461

Chargement des modules

broker_module
Chemin et argument pour charger un module de Nagios. Peut tre appel plusieurs fois pour diffrents modules.
broker_module=/usr/local/nagios/bin/ndomod.o arg1 arg2=3 debug=0

event_broker_options
Option permettant de choisir les options exportes par levent broker. Pour plus dinformations sur cette option, voir le chapitre 10.
event_broker_options=-1

Options de journalisation
log_rotation_method
Mthode utilise pour la rotation des journaux de Nagios. n : ne pas faire de rotation des journaux ; h : faire une rotation au dbut de chaque heure ; d : faire une rotation par jour, minuit ; w : faire une rotation par semaine, le dimanche minuit ; m : faire une rotation par mois, minuit le dernier jour du mois.
log_rotation_method=d

log_archive_path
Chemin utilis pour y placer les fichiers de journalisation de Nagios aprs leur rotation.
log_archive_path=/usr/local/nagios/var/archives

462

Nagios 3

use_syslog
Utiliser, ou non, syslog pour y placer les donnes de journalisation de Nagios.
use_syslog=1

log_notifications
Enregistrer dans le journal les envois de notifications.
log_notifications=1

log_service_retries
Enregistrer dans le journal les tentatives de revrification de services.
log_service_retries=1

log_host_retries
Enregistrer dans le journal les tentatives de revrification dhtes.
log_host_retries=1

log_event_handlers
Enregistrer dans le journal les lancements de commandes dactions correctives.
log_event_handlers=1

log_initial_states
Enregistrer dans le journal les tats des lments lors du lancement de Nagios.
log_initial_states=0

log_external_commands
Enregistrer dans le journal les commandes externes reues.
log_external_commands=1

Options de configuration de nagios.cfg ANNEXE

463

log_passive_checks
Enregistrer dans le journal les vrifications passives reues.
log_passive_checks=1

Configuration de lordonnancement
global_*_event_handler
Commande par dfaut sil faut utiliser une commande de correction, mais que celleci na pas t dfinie.
global_host_event_handler=somecommand global_service_event_handler=somecommand

*_inter_check_delay_method
Mthode pour espacer les vrifications lances par Nagios.
Pour plus dinformations ce propos, se rfrer au chapitre 3.
service_inter_check_delay_method=s

max_*_check_spread
Temps, en minutes, sur lequel Nagios espace ses premires vrifications.
max_service_check_spread=30

service_interleave_factor
Mthode dtalement des vrifications de la file. Permet de diminuer la probabilit de lancer plusieurs commandes sur un mme hte en mme temps.
Pour plus dinformations, se rfrer au chapitre 3.
service_interleave_factor=s

464

Nagios 3

max_concurrent_checks
Nombre maximum de vrifications pouvant tre lances en parallle. Une valeur nulle signifie quil ny a pas de limite.
max_concurrent_checks=0

check_result_reaper_frequency
Intervalle de temps, en secondes, entre deux intgrations des rsultats des vrifications dans var/spool/check-results.
check_result_reaper_frequency=10

max_check_result_reaper_time
Temps maximum, en secondes, durant lequel lintgration des rsultats est autorise fonctionner.
max_check_result_reaper_time=30

check_result_path
Rpertoire dans lequel Nagios place les rsultats des vrifications pour quils soient analyss par la suite.
check_result_path=/usr/local/nagios/var/spool/checkresults

max_check_result_file_age
ge maximum, en secondes, des fichiers de rsultats. Sils sont trop vieux, ils ne sont pas analyss.
max_check_result_file_age=3600

Options de configuration de nagios.cfg ANNEXE

465

cached_*_check_horizon
Temps, en secondes, pendant lequel les informations dtat des vrifications peuvent tre utilises, dans le cadre des dpendances, sans lancer de vrification supplmentaire.
cached_service_check_horizon=15 cached_host_check_horizon=15

enable_predictive_*_dependency_checks
Permet Nagios, dans le cas dune dpendance, de lancer, en mme temps quune vrification, les vrifications quil aurait d lancer peu de temps aprs en cas de retour anormal du premier test.
enable_predictive_service_dependency_checks=1 enable_predictive_host_dependency_checks=1

soft_state_dependencies
Permet de prendre en considration les tats SOFT pour les dpendances.
soft_state_dependencies=0

time_change_threshold
Diffrence de temps entre Nagios et le systme, qui provoque un changement dheure de rfrence de Nagios.
time_change_threshold=900

auto_reschedule_checks
Permet Nagios de rorganiser ses vrifications en cours dexcution afin de relisser les vrifications. Cest une fonctionnalit non finalise lheure actuelle.
auto_reschedule_checks=0

466

Nagios 3

auto_rescheduling_interval
Intervalle de temps entre deux rorganisations de la file de vrifications.
auto_rescheduling_interval=30

auto_rescheduling_window
Priode de temps, en secondes, pendant laquelle Nagios tente de rorganiser ses vrifications.
auto_rescheduling_window=180

sleep_time
Temps, en secondes, pendant lequel Nagios attend lorsquil a fini ses vrifications.
sleep_time=0.25

*_timeout
Divers dlais, en secondes, dexpiration des actions.
service_check_timeout=60 host_check_timeout=30 event_handler_timeout=30 notification_timeout=30 ocsp_timeout=5 perfdata_timeout=5

retain_state_information
Permet Nagios de sauvegarder ltat des lments entre deux redmarrages.
retain_state_information=1

state_retention_file
Fichier de rtention des tats.
state_retention_file=/usr/local/nagios/var/retention.dat

Options de configuration de nagios.cfg ANNEXE

467

retention_update_interval
Intervalle de temps entre deux gnrations du fichier de rtention.
retention_update_interval=60

use_retained_program_state
Permet Nagios de sauvegarder toutes ses informations entre deux redmarrages. Si ce paramtre a la valeur 1, les valeurs courantes des options enable_notifications, enable_flap_detection, enable_event_handlers, execute_service_checks, et accept_passive_service_checks sont conserves au redmarrage.
use_retained_program_state=1

use_retained_scheduling_info
Permet Nagios de sauvegarder lordonnancement des vrifications entre deux redmarrages.
use_retained_scheduling_info=1

retained_*_attribute_mask
Masque binaire sur les informations ne pas sauvegarder. Le tableau B-1 recense les valeurs possibles.
retained_host_attribute_mask=0 retained_service_attribute_mask=0 retained_process_host_attribute_mask=0 retained_process_service_attribute_mask=0 retained_contact_host_attribute_mask=0 retained_contact_service_attribute_mask=0 Tableau B1 Donnes du masque de sauvegarde

Donne NONE NOTIFICATIONS_ENABLED ACTIVE_CHECKS_ENABLED PASSIVE_CHECKS_ENABLED EVENT_HANDLER_ENABLED

Valeur 0 1 2 4 8

Donne FLAP_DETECTION_ENABLED FAILURE_PREDICTION_ENABLED PERFORMANCE_DATA_ENABLED OBSESSIVE_HANDLER_ENABLED EVENT_HANDLER_COMMAND

Valeur 16 32 64 128 256

468

Nagios 3

Tableau B1 Donnes du masque de sauvegarde (suite)

Donne CHECK_COMMAND NORMAL_CHECK_INTERVAL RETRY_CHECK_INTERVAL MAX_CHECK_ATTEMPTS

Valeur 512 1024 2048 4096

Donne FRESHNESS_CHECKS_ENABLED CHECK_TIMEPERIOD CUSTOM_VARIABLE NOTIFICATION_TIMEPERIOD

Valeur 8192 16384 37768 65536

interval_length
Temps, en secondes, de lintervalle par dfaut. Il est dconseill de modifier cette valeur.
interval_length=60

check_for_updates et bare_update_check
Permettre Nagios de vrifier quune nouvelle version est disponible.
check_for_updates=1 bare_update_check=0

use_aggressive_host_checking
Utiliser, ou non, la vrification agressive des htes. Il est dconseill dactiver cette option.
use_aggressive_host_checking=0

execute_*_checks
Permettre Nagios de lancer des vrifications actives.
execute_service_checks=1 execute_host_checks=1

Options de configuration de nagios.cfg ANNEXE

469

accept_passive_*_checks
Autorise les vrifications passives dans Nagios.
accept_passive_service_checks=1 accept_passive_host_checks=1

enable_notifications
Autorise Nagios envoyer des notifications.
enable_notifications=1

enable_event_handlers
Permet Nagios de lancer des commandes de rparation.
enable_event_handlers=1

process_performance_data
Permet Nagios de traiter les donnes de performances.
process_performance_data=1

*_perfdata_command
Commandes pour gnrer les donnes de performances.
host_perfdata_command=process-host-perfdata service_perfdata_command=process-service-perfdata

*_perfdata_file
Fichiers de donnes des performances.
host_perfdata_file=/usr/local/nagios/var/host-perfdata service_perfdata_file=/usr/local/nagios/var/service-perfdata

470

Nagios 3

*_perfdata_file_template
Format pour lexport des donnes de performances.
host_perfdata_file_template=[HOSTPERFDATA]\t$TIMET$\t$HOSTNAME$\t$HOSTE XECUTIONTIME$\t$HOSTOUTPUT$\t$HOSTPERFDATA$ service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t $SERVICEDESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT $\t$SERVICEPERFDATA$

*_perfdata_file_mode
Mode douverture du fichier de performances : a : ajoute les informations ; w : crase les informations ; p : le fichier est un tube nomm.
host_perfdata_file_mode=a service_perfdata_file_mode=a

*_perfdata_file_processing_command
Commandes pour grer les donnes de performances.
host_perfdata_file_processing_command=process-host-perfdata-file service_perfdata_file_processing_command=process-service-perfdata-file

*_perfdata_file_processing_interval
Intervalle de temps entre deux lancements de la commande
service_perfdata_file_processing_command. host_perfdata_file_processing_interval=0 service_perfdata_file_processing_interval=0

Options de configuration de nagios.cfg ANNEXE

471

obsess_over_*
Activer ou non les commandes lances aprs chaque vrification.
obsess_over_services=0 obsess_over_hosts=0

ocsp_command
Commande lance aprs chaque vrification de service.
ocsp_command=somecommand

ochp_command
Commande lance aprs chaque vrification dhte.
ochp_command=somecommand

translate_passive_host_checks
Dans le cadre dune supervision active/passive, le second nud peut ne pas voir les lments sous le mme angle que le premier. Les relations de parent ne sont pas obligatoirement les mmes. Cette option permet au second Nagios de changer les tats reus pour quils correspondent son point de vue.
translate_passive_host_checks=0

passive_host_checks_are_soft
Permet de considrer les vrifications passives dhtes comme SOFT.
passive_host_checks_are_soft=0

check_for_orphaned_*
Permet Nagios de rordonnancer les vrifications sil na pas le retour dune commande lance.
check_for_orphaned_services=1 check_for_orphaned_hosts=1

472

Nagios 3

check_*_freshness
Active dans Nagios la gestion de la fracheur des lments.
check_service_freshness=1 check_host_freshness=0

service_freshness_check_interval
Valeur, en secondes, entre deux vrifications de la fracheur des lments.
service_freshness_check_interval=60 host_freshness_check_interval=60

additional_freshness_latency
Nombre de secondes ajoutes par Nagios aux intervalles de fracheur quil calcule luimme. Cela permet de laisser un peu de temps aux informations pour arriver par rapport leur rythme normal.
additional_freshness_latency=15

enable_flap_detection
Active la dtection de leffet yoyo .
enable_flap_detection=1

*_flap_threshold
Valeur utilises pour la gestion de leffet yoyo .
Pour plus dinformations, se rfrer au chapitre 6.
low_service_flap_threshold=5.0 high_service_flap_threshold=20.0 low_host_flap_threshold=5.0 high_host_flap_threshold=20.0

Options de configuration de nagios.cfg ANNEXE

473

Options de localisation
date_format
Format des dates de Nagios : us : MM-DD-YYYY HH:MM:SS euro : DD-MM-YYYY HH:MM:SS iso8601 : YYYY-MM-DD HH:MM:SS strict-iso8601 : YYYY-MM-DDTHH:MM:SS
date_format=us

use_timezone
Dcalage horaire que doit utiliser Nagios.
use_timezone=Europe/Paris

enable_embedded_perl
Activer linterprteur Perl intgr.
enable_embedded_perl=1

p1_file
Chemin vers le fichier p1.pl ncessaire linterprteur Perl intgr.
p1_file=/usr/local/nagios/bin/p1.pl

use_embedded_perl_implicitly
Utiliser par dfaut linterprteur Perl intgr.
use_embedded_perl_implicitly=1

474

Nagios 3

illegal_object_name_chars
Caractres interdits dans le nom des objets.
illegal_object_name_chars=`~!$%^&*|'"<>?,()=

illegal_macro_output_chars
Caractres interdits dans les macros.
illegal_macro_output_chars=`~$&|'"<>

use_regexp_matching
Utiliser les fonctionnalits dexpressions rationnelles dans la dfinition des objets.
use_regexp_matching=0

use_true_regexp_matching
Utiliser les expressions rationnelles pour toutes les proprits des objets.
use_true_regexp_matching=0

admin_*
Informations de contact de ladministrateur de Nagios.
admin_email=nagios@localhost admin_pager=pagenagios@localhost

Options de dbogage et de performances

daemon_dumps_core
Autorise Nagios crer un fichier core en cas darrt inhabituel.
daemon_dumps_core=0

Options de configuration de nagios.cfg ANNEXE

475

use_large_installation_tweaks
Utiliser les options de performances avances.
Pour plus dinformations sur cette option et les trois suivantes, se rfrer au chapitre 9.
use_large_installation_tweaks=0

enable_environment_macros
Activer ou non les variables denvironnement lors de lappel aux commandes.
enable_environment_macros=1

free_child_process_memory
Nettoyer lespace mmoire des fils de Nagios.
free_child_process_memory=1

child_processes_fork_twice
Lancer les commandes de vrification avec un fils de Nagios au lieu dun petit-fils.
child_processes_fork_twice=1

debug_level
Niveau de dbogage de Nagios.
debug_level=0

debug_verbosity
Niveau de verbosit des textes de dbogage.
debug_verbosity=1

476

Nagios 3

debug_file
Fichier de sortie des informations de dbogage.
debug_file=/usr/local/nagios/var/nagios.debug

max_debug_file_size
Taille maximale en octets du fichier de dbogage.
max_debug_file_size=1000000

Index
Symboles
/proc/ 381 loadavg 385 meminfo 382 net/netstat 383 net/tcp 383 net/udp 383 PID/stat 382 PID/statm 382 PID/status 382 stat 395

C
cache 261 cache de vrification 261 cached_host_check_horizon 262 cached_service_check_horizon 262 carte 442 cartographie 337 centcore 333 Centreon 312, 325, 326, 425 ACL 439 CentStorage 328 communaut 313 contact 433 fonctionnement 316 gestion des accs 326 hritage 429 installation 368 NDO 427 reporting 354 traps SNMP 328 CentStorage 316, 328 centweb 317 charge 447 globale 384 machine 251 check_external_commands 276 check_file_age 448 check_freshness 189 check_interval 64 check_load 447 check_mem 448 check_nrpe 432 check_nt 432 check_swap 448 check_tcp 434 child_processes_fork_twice 266

A
ACL 326, 439 active_checks_enabled 190 advanced load average 396 alerte criticit 143 dpendances 147 niveau 143 notification 155 rdiger 142 RSS 166 SMS 168 yoyo 176 apache 134 applications 449 sondes 449 architecture 420

B
base de connaissance 376, 425 bin/ nagiostats 242 broker_module 287 bronx 446

478

Nagios 3

cluster 455 code retour 52 command 40 command_line 41 command_name 41 commande de vrification 40, 366 check_bonding 413 check_centreon_snmp_traffic 409 check_cluster 203 check_cpu 400 check_dhcp 89 check_disk 412 check_dns 87 check_dummy 190 check_email_delivery 92 check_http 80 check_ldap 88 check_lpstat 414 check_mem 403 check_nagios 275 check_ndo 293 check_nfs_client 413 check_nt 401 check_swap 403 check_tcp 77 check_uptime 415 commande externe 71 ACKNOWLEDGE_SVC_PROBLEM 72 DISABLE_NOTIFICATIONS 275 ENABLE_NOTIFICATIONS 274 PROCESS_HOST_CHECK_RESULT 188 PROCESS_SERVICE_CHECK_RESULT 72, 187 SCHEDULE_HOST_DOWNTIME 179 START_EXECUTING_HOST_CHECKS 281 START_EXECUTING_SVC_CHECKS 281 STOP_EXECUTING_HOST_CHECKS 281 STOP_EXECUTING_SVC_CHECKS 281 commandes de notifications 42 compilation 359 configuration outils daide 311 performances 261 contact 48, 433

contact_name 48 email 49 host_notification_commands 49 host_notification_options 49 host_notification_period 49 host_notifications_enabled 48 service_notification_commands 49 service_notification_options 49 service_notification_period 49 service_notifications_enabled 49 contactgroup 51 alias 51 contactgroup_members 51 contactgroup_name 51 members 51

D
data_processing_options 287 dpendances rseau 147 dhcp 450 disque 411, 449 distribu Centreon 333 polleres 333 pollers 333 dns 451 DNX 294 dnxclients 295 dnxserver 295 duplication 266

E
effet yoyo 176 e-mails 432 enable_embedded_perl 257 enable_environment_macros 264 enable_event_handlers 174 enable_notifications 276 ePN 255 escalade de notification 69 espace disque 411, 448 tat dun nud 44 DOWN 44 UNREACHABLE 44

Index

479

UP 44 tat dun service 46 CRITICAL 46 OK 46 UNKNOWN 46 WARNING 46 tat physique 449 etc/ dnxClient.cfg 297 dnxServer.cfg 297 htpasswd.users 134 ndo2db.cfg 289 ndomod.cfg 286 nrpe.cfg 129 nsca.cfg 196 send_nsca.cfg 197 event handlers 173 event_broker_options 287 external_command_buffer_slots 250

F
factorisation de configuration 210 par modle 213 fan 358 fichiers journaux 426 flap_detection_enabled 177 flap_detection_options 176 flapping 176, 426 fracheur dun tat 189 free_child_process_memory 265 freshness_threshold 189

high_service_flap_threshold 177 host 44 address 44 alias 44 check_command 44 check_period 44 contact_groups 44 contacts 44 host_name 44 max_check_attempts 44 notification_interval 44 notification_options 45 notification_period 44 host_freshness_check_interval 190 hostgroup 224 hostgroup_name 224 hte 44 hpjd 452 http 451 HttpFox 86 humidit 416

I
icmp 452 imprimante 413, 452 indicateurs charge rseau 408 I/O 407 load average 384 mmoire 401 processeur 398 inherits_parent 154 intervalle de notification 434 is_volatile 185

G
global_host_event_handler 174 global_service_event_handler 174 groupe dadministrateurs 422 groupe de machines 223, 423

L
large installation tweaks 263 latence 242 Linux indicateurs 381 load average 384, 385 logAnalyser 325 logs 426 low_host_flap_threshold 177

H
heartbeat 304 hritage additif 233 implicite 228 multiple 218 high_host_flap_threshold 177

480

Nagios 3

low_service_flap_threshold 177

M
machines sondes 449 macro 59 $HOSTADDRESS$ 41 $SERVICEOUTPUT$ 54 $USERn$ 60 macro variable 232 maintenance 178 max_check_attempts 63 max_concurrent_checks 252 MediaWiki 376 members 224 mmoire 448 MIB conversion 331 traps SNMP 192 modle 213 montages NFS 413 mysql 452 mysqldump 378

rotation des vues 351 name 213 nareto 359 NDO 285 ndo 363, 427 ndo2db 289, 348, 428 ndo2fs 349 NDOMOD 428 ndomod 286 ndomy 348 NDOUtils installation 363 negate 164, 202 Netsaint V new_mini_epn 257 NFS 413 niveaux dalerte 143 nud 44 NRPE 94 nrpe.cfg allowed_hosts 129 NSCA 195 NSClient++ 102, 400, 455

N
Nagios 359, 426 configuration 426 distribu 333 RAM 271 sondes 366 nagios.cfg 111, 457 check_external_commands 111 command_file 111 enable_notifications 111 log_file 111 max_concurrent_checks 111 nagios_user 111 process_performance_data 111 service_inter_check_delay_method 111 status_file 111 status_update_interval 111 nagiostats 242, 249 NagVis 345, 374 droits 375

O
obsess_over_hosts 279 obsess_over_services 279 OCHP 279 ochp_command 279 OCSP 279 ocsp_command 279 Octopussy 200 onduleur 417, 453 options de vrification 426 oracle 451 ordonnancement 251 Oreon 313

P
parents 149 partage 453 passive_checks_enabled 187 performances 239 configuration 261, 263

Index

481

interprteur Perl 255 NRPE vs SSH 259 test 245 virtualisation 260 pgsql 452 ping 452 poller 333, 334 port 450 Postfix 113 processus 449

R
RAM 401 redmarrage 415 register 214 rpartition de charge 285 reporting Centreon 354 ressource 44 ressources systme 447 sondes 447 retry_interval 64 Rotation 351 RSS 166

S
Samba 453 satellite 333 SEC 199 send_nsca 196 service 46 check_command 46 check_interval 46 check_period 46 contact_groups 47 contacts 47 host_name 46 max_check_attempts 46 notification_interval 46 notification_options 47 notification_period 47 retry_interval 46 service_description 46 service_freshness_check_interval 190

service_inter_check_delay_method 62 service_interleave_factor 62 servicedependency 151 serviceescalation 69 smb 453 SMS 168 smtp 451 SNMP 100 alerte 191 gestion des traps 328 MIB 191 snmp 453 trap 191 SNMPTRAPD 192 SNMPTT 332 Soft Service Dependencies 426 soft_state_dependencies 152 sondes installation 366 SSH 455 stalking_options 186 status_update_interval 70 swap 448 systme supervision des ressources 447 systme dinformation disponibilit 338

T
tcp 450 temp_file 269 temprature 416 temps systme 448 timeout 426 timeperiod 41 alias 41 monday 41 sunday 41 timeperiod_name 41 topologie 148 traps SNMP gestion dans Centreon 328 type dtat HARD 63

482

Nagios 3

SOFT 63 SOFT-RECOVERY 65

NagVis 337 rotation 351

U
udp 450 ups 453 use_embedded_perl_implicitly 258 use_large_installation_tweaks 267

W
Webinject 84 Windows indicateurs 381 WMI 104 wmi Win32_LogicalDisk 412 Win32_OperatingSystem 404 Win32_PageFileUsage 404 Win32_PerfFormattedData_PerfOS_Process or 401 Win32_Printer 414 Win32_Processor 400 Win32_Service 415

V
var/ nagios.log 70, 124 rw/nagios.cmd 71 status.dat 70, 124 status.sav 71 var/spool/ checkresults 270 volatilit 185 vues agrges 337

Y
yoyo 176

Nagios 3
pour la supervision et la mtrologie
Aprs plus de dix ans de dveloppement, le logiciel libre Nagios 3 simpose comme la rfrence en matire de supervision open source. Il permet de veiller efcacement au bon fonctionnement dun parc htrogne de plusieurs dizaines ou milliers dquipements et services rseau (serveurs matriels et logiciels, routeurs, applications web), en association avec des outils de conguration et de visualisation tels Centreon et NagVis, ou au sein de distributions spcialises telles que FAN.
Nagios pour ladministrateur serein : une rfrence mthodique pour la conguration et le dploiement
Au-del des aspects techniques, cet ouvrage donne les cls pour russir la mise en place dun projet de supervision et viter les cueils classiques : choix des mauvais indicateurs, tri insufsant des alertes, mauvaise valuation de la charge Il droule une mthodologie solide de mise en uvre, rappelle comment faire accepter loutil, les problmes soulevs par laugmentation du nombre dlments surveills, et dcrit les principes respecter concernant la pertinence des alertes et linterprtation des indicateurs classiques. Les mthodes de supervision des systmes et rseaux sont dtailles, avec agent comme sans agent, et une dmarche doptimisation des performances est propose. Sont enn dcortiques des mthodes de gestion des grandes congurations et la mise en place darchitectures de supervision haute disponibilit et rpartition de charge.

Jean Gabs
Jean Gabs contribue activement aux projets communautaires Nagios et Centreon. Il administre un parc chez Lectra, socit spcialise dans lintgration de solutions dans la rgion de Bordeaux et qui possde un systme informatique distribu sur les cinq continents.

Au sommaire
Supervision et mtrologie : Principes fondamentaux Alertes en temps rel et proactivit conomiser en taillant au plus juste le SI Le projet de supervision Revoir ses processus Mise en place progressive Susciter ladhsion Automatiser les rponses aux problmes Une seule console de supervision Choix de Nagios Licence open

source Modularit et performances De nombreux plug-ins de supervision Une large communaut trs active Fonctionnement de Nagios Les plug-ins Supervision active et passive Sondes de vrications Commandes de notications Dnition des htes, services et contacts Informations de mtrologie Ordonnancement des vrications Types dtats Escalades de notications Donner un ordre Nagios Tests de supervision Tests simples: TCP, HTTP(S), SMTP, LDAP, DNS, WMI Vrication des bases de donnes Validit des certicats SSL Agents NRPE, SNMP, NSClient++ Grer les alertes Concision et pertinence Dpendances : une seule alerte par problme La production avant tout Alertes par mail, ux RSS et SMS Moyens dalerte originaux Les services particuliers Gestion des logs Alertes SNMP (traps) et supervision passive (NSCA) Supervision des clusters Gestion de la conguration Puissance des techniques dhritage (simple, multiple, additif et implicite) Modles et groupes Performances Mthode dobservation de la latence Consommation CPU et RAM de Nagios Des amliorations simples et efcaces Haute disponibilit et rpartition de charge Plusieurs Nagios en parallle grce NDOUtils DNX : dlguer le lancement des sondes pour lisser la charge Outils daide la conguration Centreon Gestion des droits (ACL) Environnements distribus (CentCore) Gestion de la mtrologie (CentStorage) et des alertes SNMP Cartographie et reporting Intrt de lagrgation des vues NagVis Choix des indicateurs de reporting Installation et administration Nagios, Centreon, NagVis. Mise en place avec FAN Indicateurs classiques systme et rseau Charge machine (load average) CPU, mmoire, disques, rseau Unix/Linux, Windows Climatisation et lectricit Exemple de conguration complte Environnements htrognes Mthode de conguration.
Conception : Nord Compo

qui sadresse cet ouvrage ?

Aux administrateurs systme et rseau qui doivent grer des parcs de machines en rseau ou souhaitent sinitier la supervision open source, notamment avec des outils libres. Aux administrateurs Nagios souhaitant prouver et amliorer leur pratique de la supervision (gestion dun projet de mise en place, ajout dindicateurs pertinents sur la charge des machines, nouveaux canaux dalertes).