Journalisation à distance
La configuration standard de gestion des journaux système effectue une rotation des fichiers journaux chaque semaine et les conserve pendant quatre rotations. Il est souvent souhaitable de conserver les journaux plus longtemps que la valeur par défaut de quatre semaines, en particulier lors de l'établissement des tendances de performances du système liées aux tâches, telles que les clôtures financières de fin de mois, qui ne sont exécutées qu'une fois par mois. En envoyant des messages de journal à un hôte de journal distant doté d'un stockage de masse dédié, les administrateurs peuvent conserver de grandes archives de journaux système pour leurs systèmes sans modifier la configuration de rotation des journaux par défaut, qui vise à empêcher les journaux de surcharger le stockage sur disque.
La collecte centralisée des messages du journal système peut également être très utile pour surveiller l'état des systèmes et identifier rapidement les problèmes. Il fournit également un emplacement de sauvegarde pour les messages du journal au cas où un système subirait une défaillance catastrophique du disque dur ou d'autres problèmes, ce qui entraînerait la non-disponibilité des journaux locaux. Dans ces situations, la copie des messages de journal qui résident sur l'hôte de journal central peut être utilisée pour aider à diagnostiquer le problème à l'origine du problème.
La journalisation système standardisée est implémentée dans Red Hat Enterprise Linux 7 par rsyslog service. Les programmes système peuvent envoyer des messages syslog au rsyslogd local service, qui redirigera ensuite ces messages vers des fichiers dans /var/log , des serveurs de journaux distants ou d'autres bases de données en fonction des paramètres de son fichier de configuration, /etc/rsyslog.conf .
Les messages de journal ont deux caractéristiques qui sont utilisées pour les classer. L'installation d'un message de journal indique le type de message dont il s'agit. La priorité, quant à elle, indique l'importance de l'événement consigné dans le message.
Niveaux de priorité Syslog
Priorité | Signification |
---|---|
urgence | Le système est inutilisable |
alerte | Action immédiate requise |
critique | Condition critique |
erreur | Condition d'erreur |
avertissement | Condition d'avertissement |
avis | État normal mais significatif |
infos | Messages d'information |
débogage | Messages de débogage |
Configuration d'un hôte de journal central
L'implémentation d'un hôte de journalisation central nécessite la configuration du service rsyslog sur deux types de systèmes :les systèmes distants d'où proviennent les messages de journalisation et l'hôte de journalisation central qui reçoit les messages. Sur l'hôte de journal central, le service rsyslog doit être configuré de sorte que les messages de journal des hôtes distants soient acceptés.
Pour configurer le service rsyslog sur l'hôte de journal central pour accepter les journaux distants, décommentez les lignes de réception TCP ou UDP dans la section modules du fichier /etc/rsyslog.conf fichier.
Pour la réception UDP :
# Provides UDP syslog reception $ModLoad imudp.so $UDPServerRun 514
pour la réception TCP :
# Provides TCP syslog reception $ModLoad imtcp.so $InputTCPServerRun 514
TCP fournit une livraison plus fiable des messages de journal distant, mais UDP est pris en charge par une plus grande variété de systèmes d'exploitation et de périphériques réseau.
Remarque :Le transport TCP simple des messages syslog est assez largement implémenté mais pas encore standardisé. La plupart des implémentations utilisent actuellement le port 514/TCP, qui est le port rshd hérité. Si le paquet rsh-server est installé sur le système et utilise l'ancien service rshd non sécurisé, cela entrera en conflit avec l'utilisation du port 514/TCP pour la réception syslog TCP en clair. Configurez le serveur de journalisation pour utiliser un port différent en modifiant le paramètre de $InputTCPServerRun.
Les règles contenues dans /etc/rsyslog.conf sont configurées par défaut pour prendre en charge la journalisation des messages sur un seul hôte. Par conséquent, il trie et regroupe les messages par établissement. Par exemple, les messages électroniques sont acheminés vers /var/log/maillog tandis que les messages générés par
le démon crond sont regroupés dans /var/log/cron pour faciliter la localisation de chaque type de message.
Bien que le tri des messages par l'installation soit idéal sur un seul hôte, il produit un résultat indésirable sur un hôte de journal central car il entraîne le mélange des messages provenant de différents hôtes distants. Sur un hôte de journal central, il est généralement plus optimal que les messages de journal des systèmes distants restent séparés les uns des autres. Cette séparation peut être obtenue en définissant des noms de fichiers journaux dynamiques à l'aide de la fonction de modèle de rsyslog.
Les modèles sont définis dans /etc/rsyslog.conf et peuvent être utilisés pour générer des règles avec des noms de fichiers journaux dynamiques. Une définition de modèle se compose du $template directive, suivi d'un nom de modèle, puis d'une chaîne représentant le texte du modèle. Le texte du modèle peut être rendu dynamique en utilisant des valeurs substituées à partir des propriétés d'un message de journal. Par exemple, pour diriger les messages cron syslog de différents systèmes vers différents fichiers sur un hôte de journal central, utilisez le modèle suivant pour générer des noms de fichiers journaux dynamiques basés sur HOSTNAME propriété de chaque message :
$template DynamicFile,"/var/log/loghost/%HOSTNAME%/cron.log"
Le nom de fichier dynamique créé à l'aide de la définition de modèle peut ensuite être référencé par le nom du modèle dans une règle comme suit :
cron.* ?DynamicFile
Sur les systèmes exécutant une journalisation extrêmement détaillée, il peut être souhaitable de désactiver la synchronisation du fichier journal après chaque opération d'écriture afin d'améliorer les performances. La synchronisation d'un fichier journal après chaque journalisation peut être omise en préfixant le nom du fichier journal avec le signe moins (-) dans une règle de journalisation. Cependant, le compromis de performances améliorées crée la possibilité de perte de données de journal si le système tombe en panne immédiatement après une tentative d'écriture.
Voici un autre exemple d'utilisation de modèles pour générer des noms de fichiers journaux dynamiques. Dans cet exemple, les messages du journal distant seront triés par leur nom d'hôte et leurs valeurs d'installation en faisant référence à HOSTNAME et syslogfacility-test Propriétés. Les messages de journal seront écrits dans les noms de fichiers journaux générés dynamiquement et aucune synchronisation ne sera effectuée après l'opération d'écriture.
$template DynamicFile,"/var/log/loghost/%HOSTNAME%/%syslogfacility-text%.log" *.* -?DynamicFileRemarque :Une liste complète des propriétés des messages syslog rendues disponibles par rsyslog peut être trouvée
dans la section Propriétés disponibles de la page de manuel rsyslog.conf(5).
Une fois la réception syslog activée et les règles souhaitées pour la séparation des journaux par hôte créées, redémarrez le service rsyslog pour que les modifications de configuration prennent effet. De plus, ajoutez les règles de pare-feu UDP et/ou TCP nécessaires pour autoriser le trafic syslog entrant, puis rechargez firewalld .
# systemctl restart rsyslog # firewall-cmd --add-port=514/udp --permanent # firewall-cmd --add-port=514/tcp --permanent # firewall-cmd --reload
Lorsque de nouveaux fichiers journaux sont créés, ils peuvent ne pas être inclus dans le calendrier de rotation des journaux existant de l'hôte de journal. Cela doit être corrigé pour s'assurer que les nouveaux fichiers journaux n'atteignent pas des tailles ingérables. Par exemple, pour inclure les nouveaux fichiers journaux des exemples précédents dans la rotation des journaux, ajoutez l'entrée suivante à la liste des fichiers journaux dans /etc/logrotate.d/syslog fichier de configuration.
/var/log/loghost/*/*.log
Redirection de la journalisation vers l'hôte de journal central
Une fois que l'hôte de journal central est configuré pour accepter la journalisation à distance, le service rsyslog peut être configuré sur des systèmes distants pour envoyer des journaux à l'hôte de journal central. Pour configurer une machine pour envoyer des journaux à un serveur rsyslog distant, ajoutez une ligne à la section rules dans le fichier /etc/rsyslog.conf. Au lieu du nom de fichier, utilisez l'adresse IP du serveur rsyslog distant. Pour utiliser UDP, préfixez l'adresse IP avec un seul signe @. Pour utiliser TCP, préfixez-le avec deux signes @ (@@).
Par exemple, pour que tous les messages avec des informations ou une priorité plus élevée soient envoyés à loghost.example.com via UDP, utilisez la ligne suivante :
Pour que tous les messages soient envoyés à loghost.example.com via TCP, utilisez la ligne suivante :
*.* @@loghost.example.com
Facultativement, le nom d'hôte du journal peut être ajouté avec :PORT , où PORT est le port utilisé par le serveur rsyslog distant. Si aucun port n'est donné, il suppose le port par défaut 514 .
Après avoir ajouté la ou les règles, redémarrez le service rsyslog et envoyez un message de test à l'aide de la commande logger :
[root@logclient ~]# logger "Test from logclient"
Vérifiez les journaux sur le serveur distant pour vous assurer que le message a bien été reçu.