Cédric

Temple

Chef de Projet Supervision Open Source

Ce n’est pas parce qu’on vit dans la région où les transports en commun sont les plus développés qu’on se doit de les emprunter. On peut même être contre et leur tourner le dos.

parisien_tournant_le_dos_aux_transports_en_commun

L’écologie est a la mode. Le Green IT est a la mode. Et il est nécessaire pour les entreprises de communiquer sur ce sujet. Rien de mieux qu’une publicité dans le RER parisien pour afficher sa Green attitude.

Une question cependant : quelle entreprise a pu acheter cette green publicité?

green_communication

J’ai déjà parlé du plugin Ezwebplayer-lite pour wordpress. Ce plugin permet d’afficher dans WordPress des vidéos en Flash (vidéos au format FLV), sans passer par une plate-forme d’hébergement de vidéos. Dans la version que j’avais installée, un bug était présent. Il m’empêchait de poster une vidéo depuis la page d’écriture d’un article. Lorsque je cliquais sur l’icône de ce plugin, une page blanche s’affichait. Je n’avais pas cherché bien longtemps car je préfère passer par la ligne d’appel : c’est simple, rapide et efface:

[ EZWebPlayerLite VIDEOURL="http://urlcomplete/wordpress/wp-content/uploads/ANNEE/MOIS/video.flv" / ]

ATTENTION : j’ai volontairement ajouté un espace supplémentaire juste après le crochet ouvrant et juste avant le crochet fermant afin d’indiquer la ligne de code. Penser à les supprimer!

Pour forcer la taille de la vidéo, c’est aussi très simple:

[ EZWebPlayerLite VIDEOURL="http://urlcomplete/wordpress/wp-content/uploads/ANNEE/MOIS/video.flv" WIDTH="640" HEIGHT="360" / ]

Mais il est toujours mieux de corriger une erreur. J’ai donc cherché et rapidement trouvé. Il suffit de modifier le fichier ezwebplayer-wordpress-lite-video-plugin/ezwplite_form.php à la ligne 3 et de remplacer:

require_once(../../../wp-includes/classes.php);

par

require_once(../../../wp-includes/class-wp.php);

Et voici le résultat:

Formulaire d'ajout d'une vidéo avec EZWebplayer Lite pour wordpress

J’ai décidé de changer de thème pour ce blog. L’ancien, appelé Freshy2, était bien et je m’y étais attaché. De plus, c’était le même que j’utilisais sur mon ancien blog Dotclear. Il m’a servi longtemps et je remercie l’auteur du thème Freshy2 pour son travail. Mais trois éléments m’ont fait changer de thème:

1. l’ancien thème ne semble plus maintenu : que va-t’il se passer quand il sera trop ancien pour être utilisé avec WordPress? J’ai préféré anticiper et m’éviter tout stress inutile!
2. Freshy2 disposaient de toutes les fonctionnalités… de l’époque où il a été développé. Aujourd’hui, les blogs utilisent des nouvelles fonctionnalités, non incluses dans Freshy2. Je me trouvais un peu limité. Dommage! Aujourd’hui, elles ne sont pas encore en place mais vous les verrez apparaître au fur et à mesure sur ce blog.
3. Les titres de niveaux 1 et 2 étaient identiques (couleur et taille de police). Moi même, sur la première page de mon blog, j’avais beaucoup de mal à identifier un article du titre de niveau deux d’un article. La lisibilité de ce blog n’était donc pas suffisante.

Voilà, rien de révolutionnaire pour l’instant, ce n’est qu’un thème qui a changé.

Pour information, j’utilise le thème Mangos, réalisé par SimpleWPThemes.com. Je l’ai trouvé par l’intermédiaire de wp-themes-pro. Attention : comme l’indique l’auteur de ce site, le thème “Mangos” contenait des liens “cachés”. Il a donc nettoyé ce thème pour les supprimer. Je vous invite à télécharger ce thème sur son site plutôt que sur le site officiel du thème.

Suite à mes articles sur Centreon-Syslog (1, 2 et 3), le développeur de ce module et Community Leader de Centreon (AkHeNaToN) m’a fait quelques retours.

Tout d’abord, il me précise que la syntaxe que j’ai donnée envoie les messages syslog au travers du protocole TCP (grâce au double ‘@’):

*.* @@192.168.0.11:514

Il m’indique qu’une autre syntaxe permet d’envoyer les messages au travers du protocole UDP (avec un seul ‘@’):

*.* @192.168.0.11:514

Il m’indique aussi que le protocole syslog défini que le protocole par défaut est le protocole UDP, le protocole TCP ne devant être utilisé que pour des évènements prioritaires ou demandant un accusé de réception. Par exemple, les évènement “>=kernel.warning” pourront être envoyés par TCP et le reste en UDP.

La configuration des règles de filtrage que j’ai présentées est un peu… datée selon lui. Il existe des règles plus avancées ( à base de if, elsif, and, or, msg::contain::, …) permettant d’ajouter des conditions sur tout type de champ de l’évènement. Certes, mais une configuration simple est tout aussi efficace lorsque le besoin… est simple!

Merci Laurent pour ces retours.

J’ai décidé de faire une série d’articles sur les fonctions mal connues de Centreon. Le premier de cette série est les méta services de Centreon.

Définition d’un méta service Centreon

Un méta service Centreon agrège les données de performance de plusieurs services Centreon pour effectuer sur celles-ci des calculs mathématiques et fournir un nouvel objet (appelé méta service Centreon), équivalent à un service.

Cette définition n’étant pas simple à comprendre, nous allons l’illustrer par des cas d’utilisation. Les cas d’utilisation permettent de mieux exprimer la fonctionnalité apportée par les méta services.

Cas d’utilisation du méta service Centreon

1. Vous disposez d’une application 3-Tiers avec 2 serveurs frontaux Apache, 2 serveurs MySQL en maître-esclave et 5  serveurs d’application JBoss. Sur chaque serveur JBoss, vous supervisez le taux d’occupation du CPU. Avec Centreon, vous pouvez créer un méta service qui sera la moyenne des taux d’occupation du CPU des serveurs JBoss. Vous pouvez alors désactiver les notifications sur chaque service “CPU” des serveurs JBoss et ne l’activer que sur le méta-service.
2. Autre exemple, toujours sur le même contexte (Apache/JBoss/MySQL). Vous avez configuré un service sur chaque serveur JBoss qui mesure le nombre de connexions. Vous pouvez créer un méta service correspondant au nombre total de connexions : c’est la somme de toutes les connexions.
3. Vous disposez d’imprimantes sur lesquelles vous mesurez le nombre de pages imprimées. Grâce au méta service, vous pouvez connaître le nombre total de pages imprimées. Vous pourrez alors vérifier l’impact des recommandations faites aux utilisateurs de ces imprimantes et même communiquer avec eux sur ce graphique.

D’autres exemples, plus concis :

1. connaître la bande passante totale consommée lorsque vous disposez de plusieurs connexions internet
2. disposer du nombre total de connexions sur les 2 pare-feux en cluster
3. obtenir la consommation électrique totale de tous les serveurs
4. temps moyen de connexion sur plusieurs frontaux web

Fonctionnalités du méta-service

Le méta service se base sur des services existants. Il ne permet pas d’inventer des chiffres : des données doivent exister avant la création du méta service. Dans tous les cas ci-dessus, le méta service ne fait qu’effectuer des calculs sur des données pré-existantes. Les services doivent donc exister mais leurs données de performance doivent aussi être identiques. Par exemple, il n’est pas logique d’effectuer la moyenne d’un taux d’occupation du cpu et du taux d’occupation de la mémoire. Le type de donnée de performance doit être exactement le même quelques soient les services sur lesquels seront effectués le calcul.

En créant un méta service, vous choisissez les services sur lesquels seront effectués les calculs, la donnée de performance et la fonction (somme, moyenne, minimum et maximum) à appliquer sur les données de performance. De ce fait, vous choisissez l’expression de votre méta service. A vous de définir quelle expression vous souhaitez obtenir. Les exemples ci-dessus peuvent vous aider.

Un méta service se comporte comme un service. Il a donc:

1. un état : ok/warning/unknown/critical
2. une période de supervision, un intervalle de test et de retry, un nombre maximum de tentatives, …
3. des valeurs seuils : si le résultat du calcul dépasse la valeur seuil critical alors le méta service sera en état critical
4. des notifications : le(s) contact(s) ou le(s) groupe(s) de contact(s) à notifier, un intervalle de notification, une période de notification, …
5. un graphique permettant de tracer au cours du temps le résultat de la fonction de calcul sur les données de performance
6. un modèle de graphique

Configuration d’un méta service

La configuration d’un méta service impose les réflexions préalables suivantes :

1. quels sont les services sur lesquels effectués mon calcul?
2. quelle est la donnée de performance sur laquelle le calcul sera effectué? C’est ce que l’on appelle aussi “metric”
3. quelle est la formule de calcul?

Les réponses aux questions 2 et 3 sont très évidentes dès que l’on a identifié l’expression que l’on souhaite représentée à l’aide d’un méta service. La réponse à la question 1 est soit:

1. “tous les services identiques”. Dans ce cadre, la configuration du méta service se fera par un “matching SQL”. Il s’agit d’identifier tous les services portant le même nom. Exemple : tous les services portant le nom “pages_imprimees” pour traduire “la somme des pages imprimées de toutes les imprimantes”
2. “une liste identifiée de services”. C’est le cas du groupe de machines ayant un même rôle dans une grappe (exemple : les serveurs JBoss). Ce sera traduit par la sélection précise des services dans une liste lors de la configuration du méta service.

Configuration d’un méta service par matching SQL

Pour configurer un méta service, il faut se rendre dans le menu “Configuration –> Services –> Meta Services –> Add”. Le formulaire suivant apparaît:

Centreon méta service : configuration par SQL Matching

Les paramètres sont les suivants:

• Meta Service Name : le nom que vous choisissez pour le méta service
• Output format string (printf-style) : l’affichage du statut lorsque vous parcourez l’interface de supervision. C’est “l’output” d’un service. En général, la donnée est décrite et affichée à l’aide d’un appel équivalent à la commande “printf”. Par exemple: “Load15 is : %f”. Le “%f” représente la valeur calculée par l’opération mathématique et affichée sous forme d’un nombre flottant.
• Warning Level : la valeur seuil warning
• Critical Level : la valeur seuil critique
• Calculation Type : la fonction de calcul
• Selection Mode : le type de sélection des services. Dans notre cas, SQL Matching.
• SQL LIKE-clause expression : l’expression SQL permettant de filtrer les services. Dans notre cas, nous mettons le nom du service tel que nous l’avons défini dans notre configuration. Il est possible d’utiliser les filtres SQL (% par exemple)
• Metric : le nom de la donnée de performance (metric) sur laquelle le calcul sera effectué.

Les autres paramètres non présentés ici sont identiques à ceux présents pour un service. Je vous laisse les remplir puis sauvegarder.

Attention : le méta service ne sera créé que lorsque la configuration Nagios sera générée et Nagios redémarré.

Représentation dans l’interface de Supervision

Le résultat de la configuration apparaît dans le menu “Monitoring –> Services –> Meta-Services”:

Centreon méta service : résultat obtenu dans l'interface de supervision

Configuration d’un méta service par sélection unitaire dans une liste

La création d’un méta service par sélection unitaire des services dans une liste se fait en deux étapes:

1. création du méta service en sélectionnant le type “Service list” et sauvegarde
2. sélection unitaire des services

Pour simplifier la compréhension, une vidéo est meilleure qu’une série de screenshots:

Enfin, penser à générer la configuration Nagios et à redémarrer Nagios!

On continue notre série d’articles sur Centreon-Syslog. Après avoir découvert Centreon-Syslog et comment supprimer les messages d’erreur générés au démarrage de RSyslog, nous allons voir comment faire parvenir les messages syslog d’un serveur Linux au serveur Centreon-Syslog. Cependant, pour éviter de saturer le réseau ou le serveur Centreon-Syslog, nous filtrerons les messages envoyés. Seuls ceux considérés comme intéressants seront envoyés. Les autres seront uniquement stockés en local. Dans cet article, je ne parle que de RSyslog et je pars du principe que Centreon-Syslog est installé et configuré par défaut sur un serveur Centreon Enterprise Server (CES) dont l’adresse IP est 192.168.0.11. Je nomme sender le serveur qui doit envoyer les messages syslog sur le serveur Centreon-Syslog.

Envoyer tous les messages à un serveur Centreon-Syslog

Pour envoyer tous les messages à un serveur Centreon-Syslog, il suffit d’ajouter la ligne suivante au fichier /etc/rsyslog.conf sur le sender:

*.* @@192.168.0.11:514

Dans la ligne ci-dessus:

• *.* signifie “tous les messages”
• @@192.168.0.11 : signifie “seront envoyés à l’adresse IP 192.168.0.11
• :514 signifie “sur le port 514″

Remarque: chaque serveur (le serveur Centreon-Syslog comme le serveur envoyant les messages) doivent avoir un nom d’hôte réel. Si ces deux serveurs possèdent le même nom d’hôte, vous ne pourrez savoir quel est le serveur qui a envoyé le message. Cette configuration se fait par la commande setup puis “Configuration du Réseau”, “Edit DNS Configuration” et en modifiant la première ligne. Pensez à sauvegarder la configuration par la bouton “Save” et à modifier le fichier /etc/hosts.

Enfin, il faut redémarrer rsyslog sur le sender :

/etc/init.d/rsyslog restart

Aucune action n’est nécessaire sur le serveur Centreon-Syslog (c’est la magie CES ).

 Filtrer les messages : où réaliser cette action?

Dans la configuration ci-dessus, tous les messages sont envoyés. Cela n’est pas forcément négatif si:

• le réseau est capable d’encaisser cette charge supplémentaire
• le serveur Centreon-Syslog est correctement dimensionné pour intégrer tous ces messages dans la base de données
• l’espace disque du serveur hébergeant la base de données n’est pas limité

Dans tous les autres cas, il faut filtrer les messages pour éviter de les envoyer. Ce filtrage peut se faire à deux endroits. Le choix ne se fait pas à pile ou face mais selon la stratégie définie. Le filtrage peut être fait :

• soit sur le serveur Centreon-Syslog : tous les messages sont reçus, seuls les messages considérés comme importants sont stockés en base. Les autres sont stockés dans les fichiers textes uniquement. Cela évite de surcharger la base de données tout en centralisant le stockage des logs.
• soit sur chaque sender : chaque sender filtre les messages à envoyer pour éviter de saturer le réseau ou le serveur Centreon-Syslog.

Aucune des deux stratégies n’est la meilleure! Il faut choisir selon les critères suivants:

1. performances du réseau et du serveur Centreon-Syslog
2. besoin de centraliser ou non les messages syslog
3. capacité de stockage du serveur Centreon-Syslog

Filtrer les messages selon leur “facilité” et/ou leur criticité

Dès que le choix est fait, il faut maintenant définir quelles données vont être stockées. Pour cela, il est possible de filtrer par:

• “facilité” : cela correspond à l’origine du message, au type de programme l’ayant généré. Exemples : le kernel, les news, les mails, les crons, … Attention : ce n’est pas le nom du programme mais son type (“mail” est utilisé en lieu et place de postifx/exim/sendmail).
• “criticité” : la gravité du message.

Le filtre se fait de la façon suivante:

facilité.criticité

Le caractère “.” est utilisé pour séparer la facilité de la criticité. Il est possible d’utiliser le caractère “*” pour définir “tous”. Exemples:

• kern.* : tous les messages du kernel
• *.err : tous les messages de criticité “err” ou supérieure

Exemple de configuration: modifier le fichier /etc/rsyslog.conf en ajoutant les deux directives suivantes:

kern.* @@192.168.0.11:514
*.notice @@192.168.0.11:514


Penser à redémarrer rsyslog après cette modification!

Suite de l’article précédent sur La découverte de Centreon-Syslog. Si vous redémarrez RSyslog, vous trouverez ces messages d’erreur dans /var/log/messages:

rsyslogd: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c3 as the first rsyslogd option.
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad immark
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: MarkMessagePeriod 1200
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad imuxsock


Pour supprimer ces erreurs, il faut modifier le fichier /etc/sysconfig/rsyslog et remplacer la ligne suivante:

SYSGLOD_OPTIONS="-c3"

Par:

SYSLOGD_OPTIONS="-c3"

La correction est mise en évidence en rouge. Sauvegarder le fichier et redémarrer rsyslog:

/etc/init.d/rsyslog restart

Bien entendu, j’ai prévenu le responsable de Centreon-Syslog pour qu’il corrige ce problème.

Dans le cas d’erreurs systèmes ou de configuration, les serveurs Linux/Unix écrivent des messages dans des “logs”. Ce sont des fichiers textes contenant la date de l’erreur, sa criticité, le programme l’ayant généré et le message lui-même. C’est le fameux système syslog, généralement remplacé par ses successeurs rsyslog ou syslog-ng. Étant donné que ce sont des fichiers textes, ils sont lisibles par tous les outils systèmes comme sed/grep/awk/less/tail… L’enchaînement des commandes permet de filtrer et de rechercher le message d’erreur à une date et une heure précise et contenant le mot clé recherché. Les applications installées sur le système génèrent elles-aussi des messages d’erreur. Une bonne application doit envoyer ses messages à syslog afin qu’il les stocke dans ses fichiers.

Cependant, pour faire ces recherches, un compte administrateur est nécessaire sur le système. Admettons qu’un responsable d’application ait besoin de rechercher des messages dans les journaux, doit-il disposer d’un compte administrateur sur le serveur? Dans les services informatiques de taille moyenne, ce n’est pas problématique : les personnes installant les applications et les administrateurs sont les mêmes. Dans les services informatiques de taille plus importante, le responsable d’application n’a pas forcément les connaissances système suffisantes. Il ne doit pas avoir un compte administrateur pour éviter toute erreur de manipulation. De plus, si le serveur est partagé et pour des raisons de sécurité, ce responsable d’application ne doit pas non plus accéder à toutes les logs. La problématique est qu’il doit être suffisamment autonome pour éviter de solliciter les administrateurs systèmes… sans avoir accès à toutes les logs ni toutes les commandes systèmes. Comment lui donner un accès aux logs? La commande sudo, si bien configurée, est une première réponse. Mais elle ne sera pas simple à configurer.

Une autre solution est de centraliser la collecte de toutes les logs et de les présenter dans une application dédiée. Le mieux est encore d’intégrer cette interface directement dans l’outil de supervision. C’est possible avec Centreon et son module Centreon-Syslog. Cet article détaille l’utilisation de Centreon-Syslog.

Description du module

Centreon-Syslog permet d’afficher dans l’interface Centreon les messages syslog stockés dans une base de données. Il suffit de configurer tous les équipements réseaux et les serveurs pour qu’ils transfèrent leurs logs au serveur Centreon. Ce dernier, avec le module installé et correctement paramétré, stockera tous les événements syslog dans sa base de données et permettra de les visualiser grâce à son interface.

Installation

L’installation du module est beaucoup plus simple si vous utilisez Centreon Enterprise Server (CES). La version “Standard” suffit pour disposer du module. Je vous invite à télécharger la dernière version de CES afin de profiter de tous les avantages de cette distribution Linux dédiée à la supervision Centreon. Une fois CES installée, la vie est beaucoup plus simple:

yum install centreon-syslog-server centreon-syslog-frontend

Ensuite, vous devez vous rendre dans l’interface Centreon, dans le menu “Administration –> Modules” et cliquer sur l’icône tout à droite du module Centreon-Syslog et ensuite valider l’installation.

Configuration basique

Dans ce premier article, nous allons voir une configuration basique. Nous allons juste faire en sorte que le serveur de supervision stocke ses logs dans la base de données créée par le module Centreon-Syslog. Avantage de Centre Enterprise Server : c’est déjà fait! RSyslog est déjà configuré pour stocker toutes ses logs dans la base de données.

Cependant, il est nécessaire de modifier le mot de passe permettant l’accès à la base de données dans l’interface du module. Pour ce faire, toujours dans le menu “Administration –> Modules” , il faut cliquer sur le lien “Configuration” en dessous du titre “Syslog”. Ce lien se trouve dans le menu gauche. Pour identifier plus facilement, je l’ai encadré de rouge dans la capture d’écran ci-dessous:

Menu de configuration pour Centreon Syslog

Ensuite, il est nécessaire de modifier le mot de passe. Par défaut, il est vide. Or un mot de passe a été généré pour l’utilisateur MySQL “centreon-syslog”. Pour le connaître, il suffit de regarder la dernière ligne du fichier /etc/rsyslog.conf:
[root@ces ~]# tail -n 1 /etc/rsyslog.conf
*.* >127.0.0.1,centreon_syslog,centreon_syslog,Btjh1203;sysMysql
Le mot de passe créé automatiquement par Centreon Syslog est en rouge. Il suffit de saisir le même mot de passe pour le champ “Password of Database user” et sauvegarder.

Utilisation de l’interface

Ci-dessous, une vidéo présentant rapidement l’utilisation de l’interface temps-réel de Centreon-Syslog.

Une deuxième vidéo présentant l’interface de recherche de Centreon-Syslog.

Interface vide?

Si jamais vous vous demandez pourquoi la partie “Search” est vide, c’est parce que vous êtes… impatient! En fait, une tâche cron est lancée toutes les nuits et archive les messages dans des tables spécifiques afin d’accélérer la recherche et le filtrage. Comme ce script n’a jamais été lancé, la page de recherche ne fonctionne pas. Bref, “ça ira mieux demain!”.