enregistrement asynchrone via rsyslogd (8) et augmentation du tampon d'écriture
Sur un site Web très fréquenté fonctionnant dans des conteneurs virtuels (VMware) et dépourvu de stockage local, nous avons réussi à augmenter considérablement le débit (demandes par seconde) en passant de la journalisation directement dans les fichiers journaux (qui résident sur le stockage réseau distant) à rsyslogd.
Nous avons essentiellement passé de la journalisation synchrone à la journalisation asynchrone. Les employés du serveur Web écrivent en utilisant syslog (3) dans une mémoire tampon et rsyslogd (8) envoie les données à un fichier réel en parallèle, à son rythme, de sorte les processus ne bloquent pas sur IO lors de la journalisation.
Jusqu'ici tout va bien. Le problème est qu’il est impossible d’écrire de manière occasionnelle rsyslogd (par exemple, une panne de réseau momentanée/prolongée) et que la mémoire tampon entrante se remplisse rapidement.
Mes questions sont:
- Un client peut-il jamais bloquer en écrivant à rsyslogd en utilisant syslog (3)?
- Existe-t-il un moyen de regarder rsyslogd stats, par ex. quelle est la taille de la mémoire tampon?
- Existe-t-il un moyen d'augmenter la taille du tampon entrant rsyslogd?
La réponse à votre première question est la suivante:
Oui, tout appel à syslog () bloque. Peut-être pendant une très courte période, mais il s'agit toujours d'un appel synchrone impliquant un descripteur de fichier. Voir
man 3 syslogpour plus de détails.
À moins que vos serveurs utilisent des architectures et des primitives asynchrones, il y aura toujours des verrouillages. Cela peut être atténué, mais pas éliminé, par exemple en utilisant un fil séparé pour la journalisation. Pour les deux autres questions, je ne le sais pas vraiment, mais l'inspection du code source de rsyslogd (ainsi que de 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 l’UDP: 514 "protocole réseau syslog", vous apportez la possibilité de créer des verrous presque à zéro. Avec le inconvénient de la perte possible de certains enregistrements lors de fortes charges.
First, sur les serveurs "d'origine", vous devez vous assurer que toute la journalisation s'effectue via syslog. Par exemple, dans Apache2, vous devez spécifier:
ErrorLog "syslog:daemon"
Pour les autres serveurs, veuillez vous reporter à la page de manuel appropriée. Si vous ne pouvez pas vous en assurer, n'oubliez pas que la connexion à un système de fichiers peut créer
Second, dans la configuration rsyslogd d'origine, vous demandez de diriger tout le trafic syslog de l'installation choisie ("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
avoir deux copies des journaux à envoyer à deux serveurs différents en même temps.
Troisième, sur le (s) serveur (s) de destination, vous activez la réception du message syslog sur UDP: 514. Il se trouve dans le fichier de configuration rsyslogd (de destination) et est normalement désactivé par defualt (il suffirait de supprimer les # # précédents:
$ModLoad imudp
$UDPServerRun 514
quatrième, facultatif mais fortement recommandé, je voudrais également activer les horodatages à haute résolution:
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
De plus, cette option est normalement désactivée par défaut (pourquoi sur Terre?).
Autant que je me souvienne, le mode par défaut de la file de messages principale dans rsyslog est un tableau de taille fixe. Il a une limite pour 10k éléments environ. Essayez de changer ceci en file d'attente de liste chaînée, il devrait gérer vos rafales de messages occasionnels beaucoup mieux.
Oui, il y a FixedArray et LinkedList files d'attente.