Ganglia : configuration avancée

1. Sécurisation

Même si Ganglia est un logiciel ayant eu peu de failles de sécurité découvertes, par défaut, les services gmond et gmetad laissent n'importe quel utilisateur les interroger et donnent donc un inventaire des serveurs, ainsi que des métriques associées. Il existe heureusement des paramètres de configuration qui permettent d'améliorer la situation à peu de frais.

1.1 Utilisation de l'unicast

Un problème connu du multicast est l'aspect sécurité. Il est très difficile de contrôler qui accède au flux. Il n'y a pas de mécanisme prévu pour empêcher une connexion à une adresse multicast. Dans certains environnements où j'ai travaillé, le multicast était banni par l'administrateur réseau sans même que j'aille jusqu'à lui parler de Ganglia.

Il est donc conseillé d'utiliser l'unicast dans les sections udp_send_channel et udp_recv_channel de gmond.

1.2 Rendre sourd gmond

En passant l'option deaf à yes dans la section globals du fichier gmond.conf, on désactive les sections udp_recv_channel et tcp_accept_channel du fichier de configuration. Concrètement, cela signifie que le service gmond ne répondra à aucune demande d'information par TCP et n'écoutera pas le statut des autres nœuds du cluster.

Cette option ne doit pas être activée sur les nœuds gmond interrogés par le service gmetad.

1.3 Mise en place des ACL

Pour sécuriser les connexions des nœuds sur lesquels gmond ne peut pas être sourd, il est possible de spécifier des ACL dans les sections udp_recv_channel et tcp_accept_channel.

Pour udp_recv_channel, si vous disposez d'un réseau dédié, on peut se contenter d'autoriser uniquement ce réseau en ajoutant cette entrée dans la section :

Ici, on autorise gmond à écouter toutes les machines du réseau 10.111.111.0/24 en UDP.

Pour tcp_accept_channel, le seul serveur ayant besoin de l'interroger est celui hébergeant gmetad. La règle est donc encore plus simple :

Ici, le serveur feddy10 a l'adresse IP 10.111.111.110.

1.4 Interface web

Je passerais sur toutes les possibilités de sécurisation possibles d'un serveur web, mais elles peuvent évidemment s'appliquer ici.

L'interface web dispose aussi d'un moyen de rendre l'accès à certains clusters dépendant d'un mot de passe. Dans le fichier /usr/share/ganglia/private_clusters, il faut mettre une ligne de ce type par cluster :

Pour générer un mot de passe au format md5 sous Linux :

Si l’on prend l'exemple du cluster mes_serveurs et le mot de passe test, il faut ajouter la ligne suivante :

Ganglia demandera un compte et mot de passe pour accéder aux pages concernant ce cluster. Le nom de compte est le nom du cluster. Un joli message « This is a private cluster. » apparaîtra sur la page du grid si le grid est composé de plusieurs clusters.

2. Ajout de métriques

2.1 La commande gmetric

La commande gmetric permet de spécifier en ligne de commande des métriques supplémentaires. L'avantage est que la commande est très simple et s'intègre facilement dans un script shell.

Le paramètre --type permet de spécifier le type de valeur que l'on va passer. gmetric permet de spécifier des entiers et des flottants de différentes tailles et signés ou non. La liste des types disponibles est dans le man de la commande.

Le paramètre --value donne la valeur de la métrique et --name spécifie le nom de la métrique. À chaque nouveau nom, gmetad crée la base RRD correspondante.

Par exemple, voici un script pour ajouter une métrique indiquant le nombre de sessions ssh ouvertes :

Un côté pratique de gmetric est qu'il n'est pas nécessaire de spécifier l'intervalle de temps entre chaque mesure. gmetad calcule lui-même tout ça.

Il suffit donc d'ordonnancer le job en Crontab, ici toutes les 5 minutes :

La commande peut être exécutée par un utilisateur lambda. Il a uniquement besoin de pouvoir lire le fichier gmond.conf. Pensez à adapter les droits du fichier si la sécurisation de Ganglia est une préoccupation pour vous.

Le graphique est automatiquement ajouté à la page concernant le serveur.

2.2 Par modules Python

gmetric est très pratique, mais lorsqu'on l'utilise de manière assez intensive, on se retrouve vite avec des dizaines de métriques supplémentaires et cela devient vite une corvée de maintenir tous les scripts et tous les ordonnancements sur chaque serveur. De plus, on aimerait bien avoir certaines métriques avec une précision de l'ordre de la dizaine de secondes.

C'est pour cela qu'à partir de la version 3.1 de Ganglia a intégré officiellement le support des modules Python et C (il était possible de les incorporer avant, mais de manière moins évidente).

On va décrire la mise en place d'un module Python qui indique le nombre de pages mémoire allant dans le paging space. Ganglia, vu son orientation HPC, manque de métrique par défaut pour mesurer l'activité disque des systèmes.

Sous Fedora, il est nécessaire d'installer le package ganglia-gmond-python.

On va commencer par créer le fichier pgspin.py dans le répertoire /usr/lib/ganglia/python_modules. Voici le contenu du script (pour des questions de lisibilité, le code de gestion d'erreur/exception a été supprimé) :

Un script Python doit contenir trois fonctions spécifiques pour pouvoir être utilisé comme un module par Ganglia.

La fonction metric_init qui décrit les métriques produites par le module à travers la variable descriptor. Ici, une seule métrique est fournie par le module, mais il est possible d'en fournir plusieurs. C'est aussi dans cette fonction que l'on récupère les valeurs passées à travers le fichier de configuration.

Les paramètres pour chaque métrique sont similaires à ceux de la commande gmetric. On ne s'étendra donc pas dessus. Le paramètre call_back par contre spécifie le nom de la deuxième fonction nécessaire au module. Ici, elle se nomme pswpin_handler, mais le nom est à la discrétion du créateur. L'important est qu'une fonction portant le nom défini dans le paramètre call_back existe et dispose d'une valeur en retour. C'est elle qui doit retourner la valeur de la métrique à gmond.

La dernière fonction est metric_cleanup et contient les opérations de nettoyage nécessaires lors de l'arrêt.

En dehors de ces 3 fonctions, on peut définir autant de fonctions que l'on veut. Ici, la fonction read_vmstat a été définie pour aller lire le fichier /proc/vmstat sous Linux et renvoyer la valeur pour le champ que l'on passe en paramètre.

On peut aussi charger les bibliothèques Python disponibles sur le système dont on a besoin. Ici, os pour tester l'existence du fichier /proc/vmstat et time pour pouvoir utiliser la fonction sleep.

Il est aussi nécessaire de créer un fichier de configuration dans le répertoire /etc/ganglia/conf.d avec une extension .pyconf.

Le fichier se décompose en deux sections :

- La section modules qui permet de spécifier le nom du module Python. Ici, name=pgsp indique que le nom du fichier est pgsp.py. L'extension n'est pas prise dans le nom.

language indique que le module a été écrit en Python. Il est possible de faire passer des paramètres au module sous la forme :

- La section collection_group qui détermine la fréquence d'interrogation des métriques en secondes grâce au paramètre collect_every et spécifie dans chaque sous-section le nom de la métrique que l'on souhaite collecter ainsi qu'une description de la métrique.

L'exemple ci-dessus pourrait être largement amélioré en utilisant des threads et en rendant persistant la collecte des données, mais cela déborderait du cadre de l'article. Un bon exemple pour aller plus loin est le module tcpconn.py fourni en standard.

3. Génération automatisée de rapports

Il est très intéressant de pouvoir accéder rapidement aux diagrammes de performance de ces serveurs. Un outil de ce type devient donc assez vite populaire. Et, avec la popularité, viennent rapidement les notions de capacity planning et les fameuses demandes de rapport de performance. Bien que l'interface web soit plutôt pratique d'utilisation, il devient vite fastidieux de générer plusieurs graphiques par serveur surtout si l'on a un parc de plusieurs dizaines voire centaines de serveurs. Nous allons voir comment réaliser cela d'une manière automatisée.

3.1 Mode debug interface web

L'automatisation est possible grâce au mode debug.

Les scripts de l'interface web de Ganglia sont prévus pour fournir un mode debug qui donne la commande rrdtool utilisée pour générer le graphique.

Dans le fichier graph.php, il suffit de modifier la ligne :

par :

Cela fait en sorte que les graphiques soit remplacés par un lien pointant sur la page contenant la commande rrdtool qui génère le graphique.

Voici un exemple de commande pour le graphique de l'activité réseau :

On obtient la syntaxe exacte de la commande.

Les personnes connaissant rrdtool peuvent penser qu'il n'est pas nécessaire de passer par le mode debug pour générer ce type de graphique. Si cela n'est pas tout à fait faux pour certains graphiques standards, l'intérêt du mode debug prend tout son sens quand on voit que l'addon custom_graph dispose aussi de cette fonction.

Il suffit d'effectuer la même modification que précédemment dans le fichier addons/custom_graph_processing.php.

On obtient ainsi littéralement une interface de développement pour des graphiques exploitant au mieux les fonctionnalités de rrdtool.

Voici un exemple de commande rrdtool reprenant les débits réseau en entrée/sortie sur une période de 1 mois :

La syntaxe de rrdtool devient tout de suite plus complexe. Il suffit de regarder la capture d'écran du menu custom_graph pour imaginer le gain de temps obtenu.

Il faut savoir que l'on peut choisir toutes les métriques disponibles d'un serveur, effectuer des calculs dessus et choisir l'aspect du graphique.

On obtient ainsi un outil permettant d'exploiter de manière « simple » les bases RRD.

3.2 Automatisation

Une fois la commande rrdtool au point, il devient facile d'automatiser la génération des graphiques.

Si l’on reprend le cluster de l'article précédent, les bases rrds se trouvent dans /ganglia/rrds. Sous ce répertoire, se trouvent l'ensemble des clusters définis dans gmetad. On trouvera donc un répertoire mes_serveurs qui lui-même contient un répertoire portant le nom de chaque serveur faisant partie du cluster. Ces répertoires contiennent les bases rrds de chaque métrique. Il y a aussi un répertoire __SummaryInfo__ qui contient les bases rrds des données consolidées du grid et des clusters.

Voici l'arborescence des répertoires pour notre cluster :

Si l’on prend comme exemple la commande rrdtool précédente, on repère assez rapidement les constantes suivantes :

- –start 'Dec 18 2008 00:00' : date de début ;

- –end 'Dec 18 2009 23:59' : date de fin ;

- –title ” debit reseau (Dec 18 2008 00:00 till Jan 18 2009 23:59) ” : titre du graphique.

On voit les modifications à faire pour automatiser cela.

Il y a aussi deux lignes définissant les bases RRD sources :

Ces lignes contiennent le nom du serveur dans le chemin. Il reste à créer un script générant exactement le même graphique pour l'ensemble des serveurs d'un cluster.

Voici un script simple qui génère les graphiques dans /ganglia/report :

Voici un exemple d'utilisation pour le cluster mes_serveurs :

3.3 Extension de l'interface web

Le script shell permet d'automatiser la génération de graphiques dans le but de faire des rapports, mais il est aussi possible de générer ses propres pages PHP pour étendre l'interface web.

Le code PHP d'une page doit être du type :

Et, comme on peut s'en douter, $command correspond exactement à la sortie que l'on obtient avec le mode debug précédemment évoqué. On peut ainsi mettre en place des pages PHP qui génèrent directement les graphiques que l'on a mis au point dans l'interface custom_graph.

On peut aussi passer des paramètres au script PHP. Voici un exemple qui montre comment contourner une limitation de Ganglia qui empêche de consolider les données de serveurs de différents clusters. En se basant sur les éléments précédents, nous allons créer une nouvelle page PHP corrigeant ce problème.

En considérant que le serveur Debian fait partie du cluster debians et que le serveur feddy10 fait partie du cluster mes_serveurs, on obtient le code PHP suivant :

Ce code PHP ne prend en paramètre que le mois de génération du rapport, mais l'idée est là. Il suffit de définir les métriques sur lesquelles on se base pour générer cela.

À noter l'utilisation de label si on le souhaite, ici pour changer les noms des métriques dans la légende.

La syntaxe est du type :

Le code PHP de l'interface web est suffisamment clair pour être facilement extensible. Il y a des exemples des modifications nécessaires dans l'interface web customisé. Il suffit de comparer le fichier graph.php et graph.php.POWER5 qui inclut des graphiques spécifiques à l'architecture POWER5.

3.4 Scribus

Un petit mot pour conseiller Scribus à ceux qui sont intéressés par la génération de rapports de performance. Scribus est un logiciel de PAO libre de qualité professionnelle. L'avantage de l'utilisation d'un outil de ce type pour générer des rapports est qu'il est possible de positionner un cadre pour les images. Cela permet de positionner exactement les images sur une page.

Mais, son véritable point fort en ce qui nous concerne est le fait que Scribus ne stocke pas directement les images dans son format de fichier, mais juste le chemin d'accès au fichier. Donc, dans le cadre de génération de rapports mensuels, il suffit de changer les images du mois précédent par les nouvelles pour que le document soit mis à jour automatiquement.

Je ne connais pas de méthode plus rapide à ce jour. Il suffit juste de remplacer les commentaires. Et on peut utiliser OpenOffice pour écrire ces textes.

4. Conclusion

Ce deuxième article a essayé de couvrir quelques-unes des possibilités de Ganglia qui font que ce logiciel est ma solution de choix pour la surveillance système. J'apprécie beaucoup ses capacités d'adaptation et son coté « tout terrain » qui ne le limite pas à un OS. Bien que j'ai essayé d'être relativement complet, il reste encore beaucoup de choses à dire sur les possibilités de Ganglia et de rrdtool. Je vous invite à suivre les liens mis en annexe pour approfondir le sujet.

Références

- http://ganglia.sourceforge.net/gmetric/ : contient des scripts utilisant gmetric

- http://www.ibm.com/developerworks/wikis/display/WikiPtype/ganglia : article DeveloperWorks sur Ganglia.

- http://oss.oetiker.ch/rrdtool/ : le site de RRDtool