En raison de la limitation de débit par rsyslog, /var/log/messages affiche de nombreuses entrées de message supprimées :
... Nov 7 14:23:14 thx1138 rsyslogd-2177: imuxsock lost 516 messages from pid 159386 due to rate-limiting Nov 7 14:23:15 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 159386 due to rate-limiting Nov 7 14:23:20 thx1138 rsyslogd-2177: imuxsock lost 512 messages from pid 159386 due to rate-limiting Nov 7 14:23:21 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 159386 due to rate-limiting Nov 7 14:29:50 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 238300 due to rate-limiting ...
C'est un comportement attendu. rsyslogd fonctionne correctement. Les entrées concernant les messages supprimés sont des entrées normales. Par défaut, rsyslogd accepte 200 messages en 5 secondes à partir d'un seul processus. Si ce seuil est dépassé, les messages seront supprimés. Ainsi, dans le cas de l'exemple d'entrée ci-dessous, le processus 77845 a envoyé environ 436 messages en 5 secondes. En raison de la limitation du débit, rsyslogd en a supprimé 236.
... Nov 6 15:46:48 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 77845 due to rate-limiting Nov 6 15:46:52 thx1138 rsyslogd-2177: imuxsock lost 236 messages from pid 77845 due to rate-limiting PID 77845 ...
La définition des paramètres suivants avec les valeurs indiquées ci-dessous désactivera la limitation de débit et aucun message ne sera supprimé.
# vi /etc/rsyslog.conf $SystemLogRateLimitInterval 0 $SystemLogRateLimitBurst 0 $IMUXSockRateLimitBurst 0 $IMUXSockRateLimitInterval 0 $IMUXSockRateLimitSeverity 7 ...
On peut s'attendre à ce que chaque entrée gérée par rsyslog soit entrée dans le fichier de messages. Ce n'est pas le cas. Le fichier rsyslog.conf le fichier a une section appelée RULES qui régit où rsyslog écrit les messages. Par défaut, seuls les messages du noyau, les messages d'information et les messages d'urgence sont écrits dans le fichier de messages. D'autres messages sont écrits dans d'autres fichiers. Par exemple, les messages traitant de l'authentification des utilisateurs vont à /var/log/secure et les messages traitant du courrier vont dans /var/log/maillog .
Étant donné que rsyslog écrit des messages dans différents fichiers en fonction de leur type, la désactivation de la limitation de débit entraînera l'écriture de tous les messages dans leurs fichiers journaux désignés, et pas seulement dans le fichier de messages. Vous pouvez voir cela en action en procédant comme suit :
1. Faites une sauvegarde de votre /etc/rsyslogd.conf fichier.
# cp -p /etc/rsyslog.conf /etc/rsyslog.conf_orig
2. Désactivez la limitation de débit comme indiqué dans le message ci-dessous en fonction de la version de votre système d'exploitation.
Comment désactiver ou étendre la limite de taux de journalisation du système sur CentOS/RHEL 6Comment désactiver ou étendre la limite de taux de journalisation du système sur CentOS/RHEL 7
3. Notez la taille des fichiers journaux dans /var/log :
# ls -la /var/log
4. Redémarrez rsyslog.
# service rsyslog restart ### CentOS/RHEL 6 # systemctl restart rsyslog ### CentOS/RHEL 7
5. Attendez environ 1 heure.
6. Annulez les modifications apportées à l'étape 2.
7. Redémarrez rsyslog.
# service rsyslog restart ### CentOS/RHEL 6 # systemctl restart rsyslog ### CentOS/RHEL 7
8. Notez les tailles des fichiers journaux dans /var/log.
Les résultats de ceci seront que :
- La taille d'un ou de plusieurs fichiers journaux autres que le fichier de messages dans /var/log a considérablement augmenté.
- Les entrées dans un ou plusieurs des fichiers journaux ont augmenté en fréquence pendant la période où la limitation du débit a été désactivée.
- Peu ou pas d'entrées ont été vues dans le fichier de messages. Comme on le voit dans cet exemple, les messages étaient supprimés jusqu'à ce que la limitation du débit soit désactivée et que rsyslog redémarre à 14h30. Entre 14h30 et 15h33 il n'y a qu'une seule entrée pour rngd à 14h44. Après avoir activé la limitation du débit, les messages abandonnés recommencent.
Nov 7 14:23:21 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 159386 due to rate-limiting Nov 7 14:29:50 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 238300 due to rate-limiting Nov 7 14:30:02 thx1138 kernel: Kernel logging (proc) stopped. Nov 7 14:30:02 thx1138 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="13439" x-info="http://www.rsyslog.com"] exiting on signal 15. Nov 7 14:30:02 thx1138 kernel: imklog 5.8.10, log source = /proc/kmsg started. Nov 7 14:30:02 thx1138 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="242406" x-info="http://www.rsyslog.com"] start Nov 7 14:44:15 thx1138 rngd[13453]: read error Nov 7 15:32:58 thx1138 kernel: Kernel logging (proc) stopped. Nov 7 15:32:58 thx1138 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="242406" x-info="http://www.rsyslog.com"] exiting on signal 15. Nov 7 15:32:59 thx1138 kernel: imklog 5.8.10, log source = /proc/kmsg started. Nov 7 15:32:59 thx1138 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="175797" x-info="http://www.rsyslog.com"] start Nov 7 15:34:25 thx1138 rsyslogd-2177: imuxsock begins to drop messages from pid 179680 due to rate-limiting Nov 7 15:35:56 thx1138 rsyslogd-2177: imuxsock lost 193 messages from pid 179680 due to rate-limiting
Donc, d'après ce qui précède, nous pouvons voir que la désactivation de la limitation du débit fonctionne réellement, mais pas comme on pourrait s'y attendre. Les éléments suivants doivent être pris en compte en ce qui concerne la limitation du débit :
1. Une rafale aléatoire et peu fréquente de messages n'est pas nécessairement une indication d'un problème. Cependant, une répétition soutenue continue de messages abandonnés peut être étudiée. Si les messages abandonnés se produisent fréquemment et qu'un grand nombre d'entre eux sont abandonnés, une enquête sur la nature de ces messages (avertissements d'erreurs informatifs ou réels) est nécessaire. Vous pouvez utiliser le test ci-dessus pour voir où vont les messages, puis consulter les journaux dans /var/log pour déterminer si un problème existe vraiment ou notez.
2. Soyez prudent lorsque vous modifiez les paramètres de limite de débit dans rsyslogd.conf ou désactivez complètement la limitation de débit. Moins il y a de messages supprimés, plus il faut de traitement pour les consigner. Trop de messages peuvent entraîner des problèmes de performances et, dans des circonstances extrêmes, même des expulsions.