2 votes

Le transfert de rsyslog vers syslog-ng par TCP ne fonctionne pas (bien que les paquets atteignent le serveur).

Nous utilisons syslog-ng sur notre serveur syslog central (syslog-ng-2.1.4-9.el5 sur CentOS 5.9). Nous étions heureux d'envoyer des journaux en utilisant syslogd et rsyslog à partir d'un mélange d'hôtes Linux et Solaris sur UDP jusqu'à hier, quand il m'est apparu clairement que nous perdions un nombre important d'entrées (oui, j'aurais dû tenir compte de tous les avertissements).

J'essaie de passer à l'utilisation du TCP. J'ai envie (pour le moment) de m'en tenir à syslog-ng au centre et à rsyslog sur les expéditeurs et je crois comprendre que cela devrait fonctionner. Le serveur syslog central possède plusieurs interfaces virtuelles qui sont utilisées pour segmenter les ensembles de journaux par fonction (c'est pourquoi les instructions udp() et tcp() spécifient l'adresse IP à laquelle se lier).

J'ai activé les écouteurs TCP du côté de syslog-ng (voir l'extrait du fichier de configuration ci-dessous) - netstat -l montre les écouteurs sur le port 514. Comme test, j'ai changé la clause de transfert sur un hôte (CentOS 6.4 avec rsyslog-5.8.10-6.el6.x86_64) de @unixlog à @@unixlog. Je vois les paquets arriver au serveur central et les paquets revenir (en regardant avec tcpdump sur unixlog) donc je pense que j'ai éliminé les problèmes avec iptables mais rien n'apparaît dans le fichier de sortie. Je viens d'essayer de désactiver iptables pendant un certain temps pour vérifier cela - même chose.

Je n'ai pas essayé d'activer le débogage pour syslog-ng parce que c'est un serveur occupé - ma prochaine étape sera probablement de mettre en place un serveur syslog-ng de test et d'y faire pointer un seul hôte. Avant de faire cela, y a-t-il autre chose que je devrais regarder ? Dois-je modifier le format des messages transférés ? Ma lecture de la documentation de Syslog-ng 2.x suggère que cela devrait fonctionner sans aucune modification. J'ai essayé de modifier l'option de niveau de compatibilité avec laquelle rsyslog est appelé. avec laquelle rsyslog est appelé. Il était initialement défini à 5, j'ai essayé 0 4 et de supprimer complètement le paramètre - aucune différence de comportement.

Rsyslog.conf sur l'expéditeur (avec commentaires et fichiers locaux supprimés)

$ModLoad imuxsock
$ModLoad imklog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
*.err;kern.debug;daemon.notice;mail.crit                @unixlog.ncl.ac.uk
local3.debug                                            @cmdloghost.ncl.ac.uk

Extrait de rsyslog.conf sur unixlog

options {
  long_hostnames(off);
  sync(0);
  create_dirs(yes);
};

destination d_syslog {
  file("/var/log/incoming/syslogs/$HOST/syslog.$YEAR$MONTH$DAY.log");
};

# unixlog is 10.8.232.202
source unixlog_net { udp(ip(10.8.232.202)); tcp(ip(10.8.232.202)); };

log {
  source(unixlog_net);
  destination(d_syslog);
};

3voto

Paul Haldane Points 4367

Le problème était tcpwrappers, ce qui était évident une fois que j'ai configuré une instance syslog-ng de test et l'ai exécutée avec la sortie de débogage activée. L'ajout de la clause suivante au fichier /etc/hosts.allow a permis de résoudre le problème

syslog-ng: 10.0.0.0/255.0.0.0

Nous avons également réalisé que nous n'avions pas traité les messages internes de syslog-ng (qui auraient pu nous indiquer le problème). J'ai maintenant ajouté les lignes suivantes pour le faire ...

# Deal with syslog-ng's own messages
source s_internal { internal(); };
destination d_internal {file("/var/log/syslog-ng.log"); };
log { source(s_internal); destination(d_internal); };

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X