Forum Linux.général rsyslog et appender java

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
24
jan.
2013

Bonjour à tous,
J'ai farfouillé un peu partout sur le web sans trouver mes réponses, je viens donc poster une question sur LE forum qui va bien… :-)

Les serveurs concernés sont des RHEL5 64bits et RHEL6 64bits
Je cherche à configurer un serveur rsyslog afin de rediriger les logs applicatifs d'instances jboss-portal et jboss-as.
Je suis arrivé à configurer le serveur syslog sans trop de mal, il suffit de configurer le fichier /etc/rsyslog.conf

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Côté clients, j'ai fait un test en redirigeant tous les logs vers le serveur syslog

*.*                                                     @syslogserver:514

C'est comme ça que je me suis rendu compte que tous les logs étaient enregistrés dans /var/log/messages

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

Les instances contiennent plusieurs applications java (ear) et a un fichier logback.xml permettant de rediriger les logs en local, c'est là que j'ai ajouté un "écouteur" ou appender pour rediriger le slogs sur le réseau

    <appender name="SYSLOG-USER" class="ch.qos.logback.classic.net.SyslogAppender">
        <syslogHost>syslogserver</syslogHost>
        <facility>USER</facility>
        <suffixPattern>[%thread] %logger %msg</suffixPattern>
    </appender>


    <root level="INFO">
        <appender-ref ref="console" />
        <appender-ref ref="SYSLOG-USER" />
    </root>

Ca logue ! c'est cool !! mais… il y a toujours un mais :-)
- Comment faire pour rediriger les logs sur le serveur syslog des applications dans un fichier spécifique ? afin de ne pas polluer /var/log/messages

A mon sens et d'après mon interprétation des fichiers de conf il y a 3 approches
- Soit on log directement depuis l'écouteur
- Soit on log en local
- Soit on log en local et en plus en redirige les logs sur le serveur syslog

Prenons un exemple :
Côté client dans /etc/rsyslog.conf
Est-ce possible d'utiliser un "localX" pour rediriger mes logs sur le serveur ? local8 n'existe pas , est-ce possible de le créer ? Est-ce possible que mon écouteur écrive dans local8 et que le serveur syslog du client redirige les logs sur le serveur ? ce serait à mon sens la solution idéale. comment identifier côté serveur ce client et rediriger ses logs dans /var/log/network/client1/jboss_instance1/appli1.log

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
local8.*                                                @serversyslog:514

Voilà le problème est posé… J'attends vos retour avec impatience …
A+
Mathieu

  • # plusieurs endroits en meme temps

    Posté par  . Évalué à 0. Dernière modification le 25 janvier 2013 à 09:39.

    alors deja depuis tes serveurs tu peux dire de logger à plusieurs endroits.

    ainsi tu trouves des lignes qui font doublons dans le fichier de config de syslog 

    *.*  /var/log/messages
daemon.log /var/log/daemon

    on peut donc en deduire que tu dois pouvoir faire

    *.*  /var/log/messages
*.* @serveursyslog:514

    apres il faut voir sur le serveursyslog, tu dois pouvoir trier ce que tu recois en fonction de l'emetteur
    pour le mettre dans un fichier à part.
    par exemple :

    /var/log/serveurRHEL5_64.log
    /var/log/serveurRHEL6_64.log

  • # Tri au niveau du serveur central rsyslog

    Posté par  . Évalué à 3.

    Rsyslog est capable de trier les messages grâce aux facilities mais dispose d'autres critères.
    Il peut trier sur le contenu du message, le syslogtag et d'autres choses encore.

    Voici un exemple :

    :syslogtag, contains, "dovecot" /var/log/dovecot/dovecot.log
    :syslogtag, contains, "dovecot" ~

    Je trie sur le critère du tag du message, j'envoie les messages qui matchent vers un fichier spécifique.
    La deuxième ligne me permet ensuite d'ignorer les messages précédemment matchés afin qu'ils ne se retrouvent pas dans d'autres fichiers de logs (tel que mail.info … dans mon cas).

    L'idée est donc de regarder les critères de tri proposés (bien que celui du syslogtag soit efficace) et de formater tes messages sur les clients en fonction de ce tri.
    Tu peux par exemple ajouter un nom de machine aux syslogtags afin de séparer les logs d'une même application tournant sur plusieurs clients.

    N'oublie pas de configurer logrotate pour tous ces nouveaux fichiers.

    • [^] # Re: Tri au niveau du serveur central rsyslog

      Posté par  . Évalué à -1.

      Yeah c'est exactement ce que je cherches …
      Pourrais tu me fournir des exemples précis de tes fichiers de conf ? Côté client et côté serveur ?

      Merci bcp !

      • [^] # Re: Tri au niveau du serveur central rsyslog

        Posté par  . Évalué à 0.

        exemple

        man apache

        car c'est dans la conf apache (par exemple)
        que tu regles ce qu'il va envoyer dans les logs.

        donc s'il envoie sa ligne de log habituel et que tu lui demande de rajouter "toto" au debut

        man syslog

        pour dire au receveur de filtrer ce qui contient "toto"

      • [^] # Re: Tri au niveau du serveur central rsyslog

        Posté par  . Évalué à 1.

        Voir la doc du filtrage de rsyslog

        L'exemple précédant fait parti de ma configuration rsyslog
        il utilise les "Property-Based Filters"

        Entraîne toi déjà sur le serveur central à maîtriser ce type de filtrage en utilisant les logs déjà présents sur le serveur ou en générant de faux logs avec la commande logger ( -t 'tag' pour configurer l'étiquette du message).
        Dès que tes règles seront en place, il ne te reste plus qu'à envoyer les logs de tes serveurs clients (tu peux utiliser cette technique de filtrage pour ne relayer que certains logs) vers le serveur central.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.