Comparatif outils de monitoring (métrologie et supervision) (2/2) : Zabbix, Centreon, Nagios, Cacti et Munin

Voici la suite de l’article présentant les hypothèses de notre comparatif ainsi qu’un bref descriptif de chacun des outils comparés. Je vais maintenant établir une matrice contenant les éléments principaux de décision, selon mon expérience, afin de comparer les outils proposés et d’évaluer la réponse qu’ils apportent sur chacun de ces critères. Pour rappel, les candidats sont des outils opensource gratuits : Zabbix, Centreon, Nagios, Cacti et Munin.

Fromage ou Dessert ?
Métrologie ou Supervision ? C’est la grande question. Il faut bien évidemment que les 2 composants du monitoring soient présents pour assurer le bien-être de votre infrastructure. Cependant, il n’est pas toujours évident de savoir dans quel domaine l’outil assure le service ou bien si il assure les 2. Le schéma ci-dessous indique à quel(s) groupe(s) appartiennent les outils étudiés.

Supervision ou/et Métrologie ?

La Matrice… Enfin ! :o)
La réponse n’est pas 42, rassurez-vous. Vous trouverez-ci dessous les éléments de décision qui permettront de choisir tel ou tel outil pour votre infrastructure.

Matrice – Outils Monitoring

Les + / –
Si je devais retenir un point positif et un axe d’amélioration pour chaque outil qui me feraient pencher pour son utilisation ou non en production, ce seraient ceux là :

Munin
+ : Sa configuration très simple sous forme de fichiers de configuration et de liens symboliques, en font un candidat idéal pour un gestionnaire de configuration centralisé comme Puppet et pour de l’automatisation.
– : L’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante rend son utilisation très difficile pour de la production.

Nagios
+ : Sa configuration sous forme de fichiers, qui peut être assez vite repoussante, en fait cependant un candidat idéal à la « pupettisation » et à l’automatisation. Au delà de cela, c’est, on peut le dire, un outil complet qui a fait ses preuves.
– : L’IHM… Il ne faut pas négliger cet aspect, car une information mise en forme « avec goût » aide aussi à sa compréhension et son interprétation. La forme est importante au delà de la pertinence de l’information.

Cacti
+ : Un outil de métrologie complet avec pas mal de fonctionnalités (Thold, Weathermap, …) apportées au travers de sa Plugin Architecture. La variété et les possibilités de ses tempates complexes sont aussi un atout non négligeable.
– : La création de ses templates peut s’avérer un peu complexe au premier abord avec les différentes couches (Data Queries, Data Input Method, Data Templates, Graph Templates, Host Templates, …). Un autre point quelque peu embêtant est le manque d’homogénéité dans la configuration de ses templates (casse-tête pour l’automatisation).

Centreon
+ : Une IHM agréable et intuitive. Les notions proposées permettent une prise en main intuitive et les templates (hosts, services, commandes, …) sont pratiques et simples à mettre en place.
– : Les graphiques se contentent de tracer les données de performance remontées par Nagios sans offrir la possibilité de les mettre en relation et de les travailler afin d’obtenir des graphes orientés « logiciel/métier » comme des graphes résumant l’utilisation d’un Apache ou d’un MySQL (par exemple).

Zabbix
+ : Un outil complet autant au niveau de la métrologie que de la supervision qui se suffit à lui-même pour monitorer de manière exhaustive une infrastructure. Les fonctionnalités très avancées permettent de gérer pratiquement tous les cas.
– : Un manque de lisibilité de certains écrans (comme celui des déclencheurs par exemple) et de leurs enchaînements et des notions qui manquent parfois de prise en main intuitive. L’interface Web fait également un peu « vieillote ».

Conclusion
Il n’y a pas de mauvaise solution, certaines seront simplement plus adaptées à ce que vous voulez en faire. Voici quelques possibilités afin d’obtenir un monitoring complet de votre infrastructure :

• Si vous voulez privilégier l’automatisation et la gestion centralisée des configurations de votre infrastructure (Cf. Puppet), pensez Munin-Nagios (vous aurez alors accès dans ce cas à 2 IHMs Web pour monitorer votre infrastructure), the « Double tap », the « Buddy system » du monitoring ! :o) Pas besoin d’accéder à des APIs plus ou moins avancées (comme pour leur camarades) pour ajouter/supprimer un host et associer les services à monitorer, tout est sous forme de fichiers de configuration et de symlinks. A noter que Munin n’exploitera pas les données de performances de Nagios mais celles de ses propres sondes et que la grosse lacune de Munin est l’absence actuelle sur ses graphiques d’une fonctionnalité de zoom et de time frame glissante qui rend son utilisation très difficile pour de la production.
• Si vous privilégiez une métrologie avancée donnant accès à des possibilités de supervision, pensez Cacti avec sa Plugin Architecture (assortie avec Thold par exemple). Prenez un peu de temps pour comprendre les notions utilisées pour créer les templates de graphes et créez vos propres graphes complexes ! Vous pourrez ensuite utilisez leurs métriques et la connaissance que vous aurez acquis dessus pour lever des alertes via Thold.
• Si vous privilégiez une supervision complète avec des possibilités de métrologie simple, Centreon est fait pour vous ! Surcouche de Nagios proposant un générateur de configuration, l’exploitation des données de performances de Nagios via RRDTool, du reporting agréable sur le statut de votre infrastructure, la possibilité de gérer une architecture distribuée de Nagios via son daemon CentCore qui se connecte sur les Nagios remote en SSH, … Centreon propose un pilotage de Nagios via une interface Web agréable et intuitive et une gestion de templates de hosts, services, commandes, … très pratique.
• Si vous êtes sans concessions, Zabbix vous offre une interface unifiée vous proposant aussi bien de superviser votre infrastructure avec des notions très avancées (mesures, déclencheurs, actions conditionnelles complexes, escalade, scénarii HTTP, …) que de travailler la partie métrologie avec la possibilité de créer des graphes complexes avec les mesures récupérées. A noter qu’au delà de l’aspect séduisant du « No Compromis », la prise en main est moins intuitive qu’un Centreon, par exemple, avec une IHM moins agréable et proposant parfois des enchaînements d’écrans un peu confus à mon sens.

Comme précisé dans la première partie de cet article, il est important de noter que je n’ai pas bien sûr pu tester les dernières versions de chaque outil, puisqu’il s’agit de retours d’expérience (sur plus de 2 ans) sur des environnements de production et qu’on n’en met pas un en place toutes les semaines ! ;ob Je suis donc ouvert à vos remarques sur les évolutions que vous aurez constatées sur vos outils favoris ou bien sur les éléments de décision que vous mettriez en plus dans la balance pour effectuer votre choix.

Frédéric FAURE @Twitter @Ysance

Comparatif outils de monitoring (métrologie et supervision) (1/2) : Zabbix, Centreon, Nagios, Cacti et Munin

Cet article a pour objectif de comparer quelques solutions de monitoring (métrologie et supervision) que j’ai eues l’occasion d’intégrer dans des infrastructures de production. Les candidats sont des outils opensource gratuits et de grands classiques : Zabbix, Centreon, Nagios, Cacti et Munin. Le but n’est pas de mettre en avant un produit en particulier, car il n’y a pas de mauvais choix dans la liste précitée, mais plutôt de vous fournir les éléments pour choisir celui qui vous conviendra le mieux dans votre cas d’utilisation. Le sujet sera en fait constitué de 2 articles : un premier va poser les hypothèses de cette comparaison et expliquer le fonctionnement de ces outils ou simplement les présenter afin de vous permettre de mieux aborder le comparatif. Le second article va synthétiser les éléments principaux de décision, selon mon expérience, dans un tableau afin de comparer les outils proposés et d’évaluer la réponse qu’ils apportent sur chacun de ces critères.

Monitoring = Métrologie + Supervision
Tout d’abord, un éclaircissement sur la sémantique utilisée est nécessaire afin que nous parlions bien tous de la même chose. Le monitoring est le terme global que l’on emploie afin de désigner le ou les outils qui vont nous permettre de suivre (monitorer) la vie de notre infrastructure. Le monitoring se décompose ensuite en 2 disciplines toutes aussi importantes l’une que l’autre et qu’il faut identifier :

• La supervision vérifie l’état d’un hôte ou d’un service et remonte une alerte sur la détection d’un comportement anormal (temps de réponse trop long, statut NOK, …) et implique une action immédiate de la part des interlocuteurs concernés. Une alerte doit signifier que l’hôte ou le service est inutilisable (critical) ou risque de l’être (warning) et ne pas renvoyer de « simples informations » qui pollueraient la visibilité des réels incidents.
• La métrologie permet d’historiser les données, éventuellement d’appliquer un traitement ou filtre dessus, avant de les présenter sous forme de graphiques ou de reporting. Ces données permettent d’apporter un correctif à postériori au niveau développement ou paramétrage des services afin d’apporter une optimisation desdits services et également de définir les ressources à attribuer aux services au plus juste. Cet aspect du monitoring est tout aussi important car il va permettre d’améliorer le service et donc le rendu des utilisateurs (internes ou clients finaux) et également de lisser les coûts. Les résultats issus de la métrologie doivent mettre aisément en valeur les améliorations à apporter en corrélant les valeurs récupérées.

Maintenant que cette hypothèse sémantique est posée nous allons pouvoir utiliser ces termes dans la suite de l’article.

De l’évolution des outils
Il est important de préciser que je n’ai pas bien sûr pu tester les dernières versions de chaque outil, puisqu’il s’agit de retours d’expérience sur des environnements de production et qu’on n’en met pas un en place toutes les semaines ! ;ob Je n’ai pas non plus testé tous les plugins additionnels (par exemple ceux de Cacti) qui permettent d’ajouter des fonctionnalités à l’outil. C’est un retour d’expérience sur plus de 2 ans et, pour donner un ordre d’idée, les outils sur lesquels j’ai travaillé le moins récemment sont Cacti et Nagios, il y a environ 1 an.

Il y aura donc peut-être eu des mises à jours par rapports aux éléments que je cite, donc n’hésitez pas à me faire un retour sur le sujet via les commentaires si j’ai omis un nouvelle fonctionnalité importante qui est apparue récemment.

Centreon, une interface à Nagios
Avant d’entamer le coeur du sujet, à savoir le comparatif des outils, il est nécessaire de donner une explication sur le fonctionnement de Centreon et de son rapport à Nagios car, ne soyez pas choqués, le coeur de Centreon est basé sur Nagios. Oh le fourbe ! :o)

Nagios est un ordonnanceur qui va organiser (ordonnancer) les tests de supervision, appelés contrôles, sur les différents hosts et services cibles et agréger les résultats pour les mettre à disposition via une interface web en lecture seule. Nagios permet aussi de remonter des données de performance (via ses plugins) qu’il stocke dans un énorme fichier plat et qui est, par conséquent, inexploitable en l’état. Pour préciser la remontée de ces informations, chaque résultat de contrôle renvoyé par un plugin peut être suffixé d’un | (pipe) derrière lequel les données de performances dans un format « clé=valeur » sont ajoutées. Les données « post pipe » sont simplement extraites et stockées dans ledit fichier. Voici un exemple de données de performance issues d’un plugin (en rouge) :

PING ok – Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80

De plus, toute la configuration de Nagios s’effectue directement dans les fichiers de configuration « à la main », ce qui peut devenir un peu complexe sur des infrastructures de taille respectable.

C’est sur ce constat que vient se greffer Centreon en proposant une interface web différente de celle de Nagios et ajoute ainsi les fonctionnalités suivantes :

• Génération via IHM de la configuration potentiellement complexe de Nagios en mettant notamment à disposition des notions de templates d’hosts, de services, de commandes, … avec des possibilités d’héritages multiples.
• Stockage et exploitation (graphique) des données de performance (métrologie) de Nagios via l’outil open source RRDtool.
• Reporting plus lisible sur l’état des hosts et des services de l’infrastructure sur différentes périodes : pratique pour avoir une visibilité globale de la qualité de son infrastructure dans le temps et pratique pour fournir des rapports visuels dans le cadre de SLAs.
• Une interface ergonomique de visualisation de l’état des hosts et des services (je la trouve plus agréable que celle de Nagios qui fournit de base cette fonctionnalité sur sa propre IHM web).
• La possibilité de piloter plusieurs Nagios distribués et d’agréger leurs données : cela peut être utile sur de grosses infrastructures segmentées. Il est donc à noter qu’il est possible d’installer des Nagios autonomes sur des machines différentes de celle du Centreon qui collectera les données (via CentCore).

Voici quelques captures d’écran de Centreon :

Centreon – Configuration – Nagios – nagios.cfg

Centreon – Monitoring – Services – AllServices

Centreon – Reporting – Dashboard

Centreon – Views – Graphs

Et comme un schéma vaut mieux qu’un long discours, en voici un expliquant la relation entre les deux outils :

Architecture Centreon-Nagios

Je considère Centreon comme un outil à part entière, même si il utilise Nagios comme ordonnanceur, le coeur de la fonctionnalité de supervision.

Pour résumer, Centreon est un outil complet qui vous permettra d’ajouter une composante métrologique à un solide outil de supervision. Pratique donc pour unifier dans un même outil, une même interface, tout ce qui est nécessaire aux équipes d’exploitation pour surveiller l’infrastructure. A noter cependant que l’exploitation des données de performances ne vous permet pas de mettre en place des graphes aussi complexes que ceux que l’on peut produire avec des outils de métrologie plus avancés. Par exemple, on ne pourra pas remonter des informations plus orientées services comme celle d’un serveur Web ou d’une base de donnée et les mettre en corrélation, comme on peut le voir dans des graphes Cacti, Munin ou Zabbix.

Le Corbeau et le Cactus
Cela aurait pu être une fable mettant en scène un corbeau malhabile laissant des plumes sur le végétal facétieux. Mais il n’en n’est rien, il s’agit de 2 outils de métrologie.

Munin est un outil très simple basé sur RRDtool qui propose une interface simpliste sans beaucoup de fonctionnalités. Les visualisations sur plusieurs échelles de temps (jour, semaine, mois et année) ne proposent pas de zoom ou de scroll, ce qui est limitant pour une production, c’est d’ailleurs à mon sens LE gros manque. Car outre cette limitation, il remplit les fonctionnalités essentielles d’un outil de métrologie pure et chaque graphique correspond à un unique script qui gère aussi bien la récupération des informations que leur mise en forme via RRDtool selon un template très bien pensé. Munin utilisant un agent sur la cible, il suffit de déployer l’agent avec la liste des graphiques de notre infrastructure et de n’activer que ceux que nous souhaitons voir pour la cible via lien symbolique (comme les sites-enabled et les sites-available sous Apache par exemple). L’architecture est très pratique et la combo est très performante en utilisant Puppet (gestionnaire de configuration centralisé) pour les déploiements automatisés de machine et conserver homogènes les configurations de vos pools de machines. Cette combo m’a vraiment séduit. Surtout qu’elle fonctionne très bien en corrélation avec un Nagios pur qui fonctionne également sur une configuration purement sous forme de fichiers. The « Double tap » ! C’est un peu le « Buddy system » du monitoring ! :o)

Si vous voulez en savoir plus sur les possibilités offertes par Puppet dans ce cadre, vous pouvez lire cet article si vous voulez en savoir plus sur un cas d’utilisation de Puppet ou bien celui-ci pour regarder une vidéo expliquant plus le fonctionnement interne de l’outil et sa configuration. Pour finir, cette citation :

En ce qui concerne la gestion et le suivi de la ferme web de FarmVille, nous exploitons quelques outils de gestion et de monitoring Open Source. Nous utilisons Nagios pour les alertes (supervision), Munin pour le monitoring et Puppet pour la configuration.

(précision sémantique Munin => métrologie) tirée d’une interview de Luke Rajlich (FarmVille). Pour l’interview complète, lisez Comment FarmVille scale pour récolter 75 millions de joueurs par mois si vous voulez vous convaincre de l’intérêt de cette solution. :o)

Voici quelques images de l’interface Munin pour vous faire une idée :

Munin – Overview

Munin – Overview Machine

Munin – CPU by day

Munin – Mysql Queries by day

Cacti est lui aussi un outil de métrologie, plus complet que le précédent, et qui a la particularité d’avoir une « Plugin Architecture » qui va permettre de lui ajouter pas mal de fonctionnalités en important des plugins et en les configurant via l’interface web. On note parmi les plugins disponibles Thold, qui permet de mettre en place un système de remontée d’alertes mail sur des évènements liés aux graphes mis en place, comme sur le dépassement d’une valeur absolue, sur un pourcentage d’augmentation/diminution, … Cela permet de capitaliser sur l’expérience tirée de l’analyse des graphes de son infrastructure et de prévenir en cas de fonctionnement anormal. Cependant, l’aspect supervision proposé ici ne sera pas aussi développé que ceux que l’on peut trouver sur des outils plus spécialisés et gérant des escalades, un panel de mesures/déclencheurs/actions extrêmement fins et modulables, des plages horaires et des groupes d’utilisateurs, … Tout ce qui fait un outil de supervision complet. Donc Cacti est avant tout un outil de métrologie avec pas mal de plugins intéressants et avec la possibilité de mettre à disposition une supervision simple qui peut convenir dans certains cas… simples. ;ob

Le point fort de Cacti réside dans les possibilités de customisation des graphes que l’on crée ou bien que l’on importe depuis les templates variés mis à disposition par la communauté. Il est parfois un peu compliqué, je trouve, de créer ses graphes : il faut bien comprendre le mécanisme ! Rien d’insurmontable en tout cas.

Voici quelques captures d’écran, afin de vous donner une idée de l’outil :

Cacti – Settings (from http://www.cacti.net)

Cacti – Tree View (from http://www.cacti.net)

Cacti – Apache Statistics – Thread scoreboard

Il est à noter que Cacti, contrairement aux autres outils présentés ici, ne fonctionne pas avec un système d’agents mais attaque directement un serveur SNMP sur la cible pour récupérer les informations système et, de la même manière, impose que les services monitorés (Apache, MySQL, …) laisse Cacti les interroger via le réseau. C’est une autre façon de concevoir les choses. Au choix.

Zabbix
Zabbix est un outil de supervision qui propose un palette de fonctionnalités complète de métrologie. Cela en fait un outil qui peut à lui seul monitorer une infrastructure sans faire de concession. C’est un point très important quand on veut unifier les différents aspects du monitoring (métrologie et supervision) de son infrastructure dans un même outil, une même interface, à disposition de ses équipes d’exploitation.

C’est un outils complet qui permet de gérer toutes les notions relatives à la supervision (escalade, alerting, plages horaires, mesures/déclencheurs/actions sur conditions, …) et également un outil de métrologie complet permettant de tracer des graphes mettant en corrélation toutes les mesures que l’on remonte. Il est à noter que contrairement aux autres outils mettant à disposition des fonctionnalités de métrologie, il est le seul à ne pas utiliser RRDtool, mais une base de données. Aucune contre-indication, c’est à titre informatif.

Il utilise un agent comme la plupart de ses camarades afin de monitorer les machines cibles (agent qui peut fonctionner en mode passif ou bien actif, genre j’attends que le serveur me demande ou bien je suis autonome et je lui envoie directement). Il est également possible pour les métriques non système d’utiliser des connexions directes : l’intérêt est d’utiliser la fonction zabbix_sender qui va remonter un ensemble de métriques en une seule fois. Explications : par défaut, Zabbix va établir autant de connexions que de couples « clé-valeur » à remonter… Pourquoi pas, mais quand je veux monitorer des services un peu complexes ou quand je veux récupérer beaucoup de métriques, ça devient un peu consommateur. Il est alors possible de positionner des scripts (comme les plugins Nagios, Cacti, Munin, …), dans la crontab du serveur Zabbix, qui vont récupérer une liste de couples « clé-valeur » (en se connectant directement via le réseau sur les services distants et sans passer par l’agent Zabbix), les stocker dans un fichier (temporaire) sur le serveur Zabbix lui-même et les envoyer en une seule fois à Zabbix via la commande… zabbix_sender !

A noter également la possibilité de construire des écrans, à partir de multiples éléments, qu’il en ensuite possible de faire défiler… sur un grand écran plat pour votre équipe d’exploitation préférée (ceci n’est pas un message personnel ;ob). Il y a également la possibilité de définir des cartes (dans le style de celles que l’on trouve dans Nagios ou bien dans le plugin Weathermap de Cacti) afin de visualiser l’état macro de votre système.

Voici quelques quelques captures d’écran de Zabbix :

Zabbix – Dashboard (from http://www.zabbix.com)

Zabbix – Apache – Thread Scoreboard (from http://www.zabbix.com)

Zabbix – Ecrans (from http://www.zabbix.com)

Zabbix – Graphes – Zoom In (from http://www.zabbix.com)

La suite…
Voilà pour la présentation des différents outils et la pose des hypothèses à partir desquelles je vais établir un comparatif entre ces différents outils. Le second article va synthétiser les éléments principaux de décision dans une matrice afin de comparer les outils proposés et d’évaluer leur correspondance sur chacun de ces critères.

Frédéric FAURE @Twitter @Ysance

Cacti : un monitoring au fil de l’eau

Ce webcast a pour objectif de vous présenter un outil de monitoring d’infrastructure fort sympathique : Cacti. Cacti est un outil dont la valeur ajoutée est de permettre un suivi d’une infrastructure au sens large au fil de l’eau. Il permet ainsi de détecter les impacts d’une modification de l’architecture, du paramétrage d’un service ou bien de la livraison d’une nouvelle version d’une application.

L’approche open source du produit lui a permis d’obtenir une diversité de templates via la communauté.
Il est possible de créer ses propres templates pour n’importe quel outil à partir du moment où celui-ci est capable de fournir des statistiques. Il est ainsi même possible de mettre en place des graphiques pour suivre le fonctionnel d’une application par exemple (nombre de visites ou de joueurs connectés, nombre de transactions effectuées, …).

Les templates de graphes que vous créez ou mis à disposition par la communauté peuvent être importés ou exportés via de simples fichiers XML associés à un script (perl, python, …) de récupération d’informations pour le service monitoré à coller dans le répertoire « /scripts » de votre Cacti.

Cacti permet de suivre l’évolution d’une infrastructure et des services proposés au fil du temps et conserve un historique des valeurs capturées permettant de tracer des graphes sur la journée autant que sur le mois ou bien sur l’année. Cacti est basé sur l’outil de log d’informations et de graphe RRDtool.

On peut retrouver Cacti sur son site : http://www.cacti.net/ .
Je vous invite également à consulter son forum http://forums.cacti.net/ sur lequel de nombreuses informations sont mises à disposition par les créateurs et la communauté. Vous y trouverez par exemple des informations sur les plugins ou bien les templates à disposition de l’outil afin de grapher vos services (http://forums.cacti.net/about32151.html, http://forums.cacti.net/about15067.html, …).

https://s3-eu-west-1.amazonaws.com/media-wp-backup/videos/Ysance+-+Decrypt+-+Infrastructure+-+Monitoring+-+Cacti.swf

 

 

Graphes sur différentes périodes
Voici le rendu d’un graphe sur différentes périodes :

Thread Scoreboard Apache – Hourly – 1 Minute Average

Thread Scoreboard Apache – Hourly – 1 Minute Average

Thread Scoreboard Apache – Daily – 5 Minutes Average

Thread Scoreboard Apache – Daily – 5 Minutes Average

Thread Scoreboard Apache – Weekly – 30 Minutes Average

Thread Scoreboard Apache – Weekly – 30 Minutes Average

Thread Scoreboard Apache – Monthly – 2 Hours Average

Thread Scoreboard Apache – Monthly – 2 Hours Average

Thread Scoreboard Apache – Yearly – 1 Day Average

Thread Scoreboard Apache – Yearly – 1 Day Average

Frédéric FAURE @Twitter @Ysance

Mise en place d’une infrastructure sur AWS : best practices !

Ce post va présenter une description détaillée de la mise en place de l’infrastructure sur AWS (Amazon Web Services). Je me base sur ce que j’ai mis en place, en l’occurrence, à destination d’une application sociale à forte sollicitation. Cependant, quelque soit la typologie de l’infrastructure sous AWS, les éléments à mettre en place seront toujours les mêmes.

Différence avec une infrastructure standard
Tout d’abord il est normal de se poser la question. La réponse devrait être : « aucune ! ». Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes qui devraient être standards afin :

• de tirer profit des possibilités, du dynamisme, de la solution,

• de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité.

Le monitoring
Le monitoring est le premier élément à mettre en place. Dans une architecture scalable, il est indispensable d’avoir à disposition des métriques afin de savoir justement quand scaler. C’est le rôle de cet élément. Il permet de plus d’identifier les points d’engorgement de l’infrastructure, analyser l’évolution du trafic sur votre site et en déduire les comportement des utilisateurs et dans le cadre d’un monitoring actif, permet également de déclencher des alertes qui servent de base aux astreintes.

Il n’y a pas d’outil miracle pour le monitoring et un certain nombre existent sur le marché avec leurs avantages et inconvénients. Nous pouvons citer Nagios, Cacti, Zabbix, Munin, … Nous avons choisi Cacti pour notre infrastructure du fait de la qualité des courbes qu’il propose. Il est vrai que le packaging de cet outil manque, à mon avis, de rigueur et que les métriques manquent, sur certains templates, de précision, cependant la qualité des courbes, basées sur RRDtool, et leur diversité permet d’effectuer un suivi complet de notre infrastructure et de comprendre les impacts de l’évolution des composants de ladite infrastructure ou bien des applications supportées au fur et à mesure des livraisons des différentes releases.

Nous avons installé également la « plugin architecture » de Cacti qui nous permet d’installer, comme son nom l’indique, des plugin sur l’outil et notamment « Thold », nous permettant de déclencher des trigger sur l’atteinte d‘une valeur sur une courbe ou bien sur une variation afin d’effectuer du monitoring actif. Bien entendu, cela est le prélude à une gestion des astreintes et à chaque alerte remontée doit correspondre un mode opératoire de reprise sur l’incident mis en lumière via Cacti.

Le monitoring est positionné sur une machine EC2 pour des raisons évidentes de coût (le coût des échanges sur l’IP interne est nul) et de sécurité (inutile d’ouvrir plein de ports et donc autant de failles à l’extérieur).

Cacti – Apache Statistics – Thread scoreboard

La gestion de configuration centralisée
La notion de scalabilité rendue accessible par l’infrastructure des services Amazon, nous oblige à utiliser un outil de gestion centralisé de la configuration. L’utilité est multiple :

• instancier rapidement une machine correspondant à un type prédéfini : serveur SQL, serveur de cache, serveur Web, …

• assurer l’homogénéité de la configuration des instances d’un même type,

• capitaliser un savoir faire.

Nous utilisons Puppet dans notre infrastructure. Nous avons installé le Puppet Master sur le serveur de monitoring. Le Puppet Master contient les descripteurs des installations et configurations à apporter à une nouvelle machine afin de la préparer suivant le type de machine (nœud) auquel on l’a associé. Régulièrement, le client pull le master afin de vérifier que sa configuration est à jour. Il est également possible de faire du push sur les clients à partir du master pour déclencher une mise à jour urgente.

Il est ainsi très simple de monter une nouvelle instance d’un type donné et d’être sûr que, d’une machine à une autre, la configuration est complètement iso, configuration qui est centralisée sur notre machine de monitoring et dispatchée sur les instances de notre infrastructure. Il est à noter que le descripteur du Puppet Master fonctionne sur un système de nodes et donc un type de machine peut faire référence à plusieurs nodes et on obtient une configuration très modulaire. Tous nos types de machine, par exemple, utilisent le module Puppet de configuration, que nous avons décrit, du protocole SNMP, indispensable pour que Cacti monitore une machine, et le module de l’outil s3cmd nous permettant de faire fonctionner notre système de backup sur chaque machine. Ensuite, chaque type de machine a ses installations/configurations spécifiques.

Exemple du descripteur de nœuds « nodes.pp » du Puppet Master :

class web-node {
include snmp-module
include s3cmd-module
include web-module
}

Exemple du descripteur « init.pp » du module « snmp » du Puppet Master :

class snmp {
package {
« snmpd »:
ensure => installed;
}

      file { « /etc/default/snmpd »:
ensure => present,
owner => root,
group => root,
mode => 0644,
source => « puppet:///snmp/snmpd »,
require => Package[« snmpd »],
notify => Service[« snmpd »];
}

      file { « /etc/snmp/snmpd.conf »:
ensure => present,
owner => root,
group => root,
mode => 0644,
source => « puppet:///snmp/snmpd.conf »,
require => Package[« snmpd »],
notify => Service[« snmpd »];
}

      service { « snmpd »:
ensure => true,
hasrestart => true,
restart => « /etc/init.d/snmpd restart »,
hasstatus => true;
}
}

Très simple de mise en place, il nous permet de démarrer une machine en un clic sur un pic de charge. « Mais… », me direz-vous, « il faut bien installer le client sur la nouvelle machine ? ». Et oui, d’autant plus qu’il y a un système de requête/acceptation de certificat entre le client et le master afin que n’importe qui ne puisse accéder aux configurations. « Très simple ! », vous répondrais-je, au lieu d’utiliser une IHM, comme Elastic Fox, afin de se connecter aux APIs des services Amazon, il suffit de s’y connecter en lignes de commande via un script qui instancie un EC2, éventuellement crée un volume EBS et l’associe, se connecte en SSH sur la nouvelle machine et installe le client, se connecte sur le master et accepte la requête de certificat, redémarre le client sur la nouvelle machine et « hop ! ». La machine s’installe et se configure toute seule ! « Magique ! » me direz-vous, « Ca devrait être pourtant classique » vous répondrais-je… Les possibilités de réactivité et de dynamisme inhérents à EC2 et les AWS de manière générale nous impose cela, sinon ce serait sous exploiter l’outil, voire més-exploiter.

L’auto-scalabilité, que nous n’avons pas (pour l’instant ;ob) mise en place dans notre cas, consisterait, par exemple, à déclencher ce script sur le dépassement d’une valeur d’un graphe Cacti, instanciant donc une nouvelle machine pour supporter la période de pic, instance qui serait « terminée » suite au repassage en dessous de ce seuil sur le graphe. Les possibilités sont énormes.

Le déploiement automatisé
Du fait de la variation du nombre d’instances en fonction de la charge et surtout du nombre potentiellement important desdites instances, il n’est pas envisageable d’effectuer les opérations de maintenance et de déploiement unitairement sur chaque machine (et encore pire à la main !), ce qui non seulement serait chronophage, mais de surcroît source d’erreurs. Il est alors indispensable d’utiliser des outils spécialisés dans l’automatisation et l’exécution parallèle de tâches, tel que Capistrano, dont les bénéfices sont multiples :

• scripter un certain nombre de tâches (livraisons, backups, publication/maintenance du site, …) et de les exécuter en parallèle sur X machines,

• assurer la reproductibilité d’une tâche,

• exécuter rapidement des tâches complexes sur X serveurs en une seule commande,

• capitaliser un savoir faire.

Cet outil est très simple d’utilisation et très pratique et exécute des tâches en parallèle, sur un groupe de serveurs que l’on définit, en se connectant en ssh :

ssh_options[:keys] = « ~/.ssh/la_cle_privee »
ssh_options[:user] = « le_user »

Il suffit de définir une liste de serveurs correspondant à un groupe, « sql » par exemple :

role :sql, « alias_sql1  » , « alias_sql2  » , … , « alias_sqlx »

Et ensuite il reste à définir les tâches, que l’on peut décrire intégralement dans le descripteur…

task :dump_sql, :roles => :sql do
run « rm -f /mnt/backup/`hostname`.`date +%w`-* »
run « mysqldump –pmon_pwd -u mon_user ma_base | gzip -cq6 > /mnt/backup/`hostname`.`date +%w-%y%m%d_%H%M`.sql.gz »
end

… ou bien dans un fichier « .sh » que l’on uploade et que l’on exécute sur la machine distante

task :store_sql, :roles => :sql do
upload « /root/cap-scripts/cap-backup_sql.sh », « /usr/local/sbin », :via => :scp
run « /usr/local/sbin/cap-backup_sql.sh »
end

Il suffit ensuite d’exécuter la simple commande « cap dump_sql » ou « cap store_sql ».

Backups
Et oui, mettre ses données de base SQL sur EBS (dans le cas où l’on n’utilise pas SimpleDB du fait du besoin d’un minimum de modèle relationnel) ne suffit pas, parce que :

• EBS assure une durabilité très respectable par réplication réseau, mais reste l’équivalent d’un disque dur, même si plus fiable,

• il n’y a pas que les données de base SQL (ou autres) qui sont importantes, il y a également vos logs principaux et les configurations de vos outils (Cacti, Puppet, Capistrano, …).

Nous utilisons l’outil en ligne de commande « s3cmd » afin de stocker nos backups. Cet outil est utilisé dans nos tâches Capistrano appelées par cron. Très simple d’utilisation, il nous permet d’utiliser les API’s S3 et offre la possibilité de transférer les données en HTTPS et également de les stocker sous un format crypté.

Tips and tricks
DNS
Il arrive de rencontrer quelques soucis DNS au niveau du réseau Amazon pour les instances EC2. Un conseil donc, positionner des hostname plus parlant (au lieu des « domu -xxxx») et utilisez le fichier des « hosts » que vous déployez ensuite via Puppet !

CDN
Nous utilisons S3 dans notre architecture afin de mettre à disposition les images et autres statiques de notre application à disposition de notre Content Delivery Network, à savoir Panther. Inutile, en effet, de maintenir un serveur Web à cette seule fin, S3 est là pour ça pour un coût minime.

Gestion des Logs
Il serait, à mon avis intéressant, de gérer également les logs de manière centralisée. Nous ne l’avons pas mis en place et, par conséquent, je ne ferai pas de recommandations sur un sujet que je n’ai pas testé moi-même. Cependant, pour indication, il est possible de mettre en place un système de logs réseaux, sous Linux par exemple, afin de centraliser et de mutualiser les logs, logs qu’il est ensuite possible d’analyser. Ca vaut le coup pour une infrastructure ou une application distribuée de connaître le comportement ou les différences de comportement des éléments qui la constitue.

Webistrano
Webistrano est une IHM permettant d’accéder aux fonctionnalités de Capistrano et introduisant une notion de gestion de projet par la possibilité de gérer les accès aux tâches en fonction de son profil, de tracer qui a déployé quoi sur quel serveur et d’envoyer des alertes mails sur certaines actions. Nous ne l’avons pas testé en production, mais cela peut s’avérer intéressant à prendre en considération.

Conclusion
Le but de ce post n’est pas de faire la publicité de tel ou tel outil, mais de vous inciter à considérer l’automatisation de votre infrastructure qui, si elle devrait déjà être en place dans vos infrastructures actuelles internes, devient indispensable sous AWS pour peu que l’on souhaite faire de la scalabilité, être réactif ou simplement tirer parti de l’outil mis à disposition.

Je dirais que les principes fondamentaux d’une bonne infrastructure sont au nombre de 3 : KISS, DRY et YAGNI.

• KISS pour « Keep It Simple, Stupid », à savoir inutile de chercher à complexifier l’infrastructure, la plus efficace sera la plus simple.

• DRY pour « Don’t Repeat Yourself » , à savoir ce qu’il est possible de scripter et d’automatiser faites-le ! Ca vous prendra un peu plus de temps la première fois, mais vous aurez une tâche réfléchie, reproductible, et vous n’aurez surtout pas besoin de le faire une seconde fois (quoi de plus ennuyeux que de se répéter).

• YAGNI pour « You Ain’t Gonna Need It », à savoir n’installez sur vos machine que ce dont vous avez besoin. Plus vous installerez d’outils inutiles ou one-shot, plus votre infrastructure aura potentiellement des trous de sécurité et pourra introduire des effets de bords. Sans aller forcément jusque là, disons qu’elle sera moins facilement maintenable.

Ces principes vous paraissent drôles pour certains ou peut-être un peu ringard pour d’autres, mais si avant de faire une tâche sur une infrastructure on se demandait si ce que l’on va entreprendre ne rentre pas dans un de ces cas, je pense que les infrastructures, de manière générale, seraient plus fiables, homogènes et performantes.

Frédéric FAURE @Twitter @Ysance