journalisation asynchrone via rsyslogd (8) et augmentation du tampon d'écriture


10

Sur un site Web à fort trafic fonctionnant dans des conteneurs virtuels (VMware) et manquant de stockage local, nous avons réussi à augmenter considérablement le débit (demandes par seconde) en passant de la connexion directe aux fichiers journaux (qui résident sur le stockage réseau distant) à rsyslogd .

Essentiellement, nous sommes passés de la journalisation synchrone à la journalisation asynchrone. Les travailleurs du serveur Web écrivent à l'aide de syslog (3) dans une mémoire tampon et rsyslogd (8) envoie les données dans un fichier réel en parallèle, et à son propre rythme, afin que les processus ne se bloquent pas sur les E / S lors de la journalisation.

Jusqu'ici tout va bien. Le problème est que rsyslogd est occasionnellement empêché d'écrire (par exemple une panne de réseau momentanée / prolongée) et que le tampon entrant se remplit rapidement.

Mes questions sont:

  • Un client peut-il bloquer lors de l'écriture dans rsyslogd à l' aide de syslog (3) ?
  • Existe-t-il un moyen de consulter les statistiques de rsyslogd , par exemple, la taille / la taille du tampon?
  • Existe-t-il un moyen d'augmenter la taille du tampon entrant rsyslogd ?

2
Avez-vous déjà résolu cela? Si oui, je serais intéressé à lire votre réponse.
djeikyb

1
@djeikyb: désolé non. Je vois de l'intérêt (votes sur la question) mais personne n'y a encore répondu. On dirait que cela nécessite une plongée en code source.
arielf

1
Vous ne dites pas quel serveur Web vous utilisez. Peut-être que vous ne devriez pas du tout utiliser syslog. Apache, par exemple, utilise-t-il syslog pour se connecter ou simplement écrire dans des fichiers journaux? La connexion à une base de données est une autre possibilité.
blujay

Réponses:


1

Pour autant que je me souvienne, le mode par défaut pour la file d'attente de messages principale dans rsyslog est un tableau de taille fixe. Il a une limite pour 10k éléments environ. Essayez de changer cela en file d'attente de liste liée, il devrait mieux gérer vos rafales de messages occasionnelles.

Oui, il y en a FixedArrayet des LinkedListfiles d'attente.


"Essayez de changer" ... Pouvez-vous être plus explicite? En regardant /etc/rsyslog.conf: je ne vois rien de lié aux types de files d'attente que vous mentionnez. Est-ce que cela nécessite un changement de code? Où et comment les configurer? Merci!
arielf

1

La réponse à votre première question est:

Oui, tout appel à syslog () bloque. Peut-être pour une très courte période, mais c'est toujours un appel synchrone impliquant un descripteur de fichier. Voir man 3 syslogpour plus de détails.

À moins que vos serveurs n'utilisent des architectures et des primitives asynchrones, il y aura toujours un certain verrouillage. Thsi peut être atténué, mais pas éliminé, par exemple en utilisant un fil de séparation pour la journalisation. Pour les deux autres questions, je ne sais pas vraiment, mais l'inspection du code source rsyslogd (ainsi que celui de la famille de fonctions syslog ()) est le seul moyen de le savoir.

Plus généralement, si vous déplacez la journalisation vers un serveur externe via le protocole UDP: 514 "network syslog protocol", vous apportez les possibilités de créer des verrous à presque zéro. Avec l' inconvénient de la perte possible d'une partie de l'exploitation forestière lors de charges élevées.

Tout d'abord , dans les serveurs "d'origine", vous devez vous assurer que toute la journalisation se produit via syslog. Par exemple, dans Apache2, vous devez spécifier:

ErrorLog "syslog:daemon"

Pour les autres serveurs, veuillez vous référer à la page de manuel appropriée. Si vous ne pouvez pas vous en assurer, veuillez garder à l'esprit que la connexion aux systèmes de fichiers peut créer

Deuxièmement , dans la configuration rsyslogd d'origine, vous demandez de diriger tout le trafic syslog pour l'installation que vous choisissez ("démon" dans cet exemple) vers un ou plusieurs serveurs syslog externes. Dans le fichier de configuration rsyslog, vous pouvez spécifier:

daemon.* @192.168.128.1
daemon.* @192.168.254.1

d'avoir deux copies des journaux à envoyer à deux serveurs différents en même temps.

Troisièmement , dans le ou les serveurs de destination, vous activez la réception du message syslog sur UDP: 514. Il se trouve dans le fichier de configuration (destination) rsyslogd et est normalement désactivé par defualt (il suffirait de supprimer les # principaux:

$ModLoad imudp
$UDPServerRun 514

Quatrièmement , facultatif mais fortement recommandé, j'activerais également des horodatages haute résolution:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

De plus, cette option est normalement désactivée par défaut (pourquoi sur Terre?).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.