Archives par mot-clé : syslog

Quelques retours sur Centreon-Syslog

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.

Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux

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.

Continuer la lecture de Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux

Centreon-Syslog : suppression des messages d’erreur au redémarrage de rsyslog

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.

Centreon Syslog : découverte

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. Continuer la lecture de Centreon Syslog : découverte