Aufgrund der Ratenbegrenzung durch rsyslog zeigt /var/log/messages viele verworfene Nachrichteneinträge:
... 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 ...
Dies ist das erwartete Verhalten. rsyslogd funktioniert korrekt. Die Einträge bezüglich verworfener Nachrichten sind normale Einträge. Standardmäßig akzeptiert rsyslogd 200 Nachrichten in 5 Sekunden von einem einzelnen Prozess. Wenn dieser Schwellenwert überschritten wird, werden Nachrichten verworfen. Im Fall des Beispieleintrags unten hat der Prozess 77845 also etwa 436 Nachrichten in einem Zeitraum von 5 Sekunden gesendet. Aufgrund der Ratenbegrenzung hat rsyslogd 236 davon gelöscht.
... 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 ...
Wenn Sie die folgenden Parameter mit den unten gezeigten Werten einstellen, wird die Ratenbegrenzung deaktiviert und es werden keine Nachrichten gelöscht.
# vi /etc/rsyslog.conf $SystemLogRateLimitInterval 0 $SystemLogRateLimitBurst 0 $IMUXSockRateLimitBurst 0 $IMUXSockRateLimitInterval 0 $IMUXSockRateLimitSeverity 7 ...
Man kann erwarten, dass jeder von rsyslog behandelte Eintrag in die Nachrichtendatei eingetragen wird. Das ist nicht der Fall. Die rsyslog.conf Datei hat einen Abschnitt namens RULES das regelt, wohin rsyslog die Meldungen schreibt. Standardmäßig werden nur Kernel-Meldungen, Informationsmeldungen und Notfallmeldungen in die Meldungsdatei geschrieben. Andere Nachrichten werden in andere Dateien geschrieben. Beispielsweise gehen Nachrichten, die sich mit der Benutzerauthentifizierung befassen, an /var/log/secure und Nachrichten, die sich mit Mail befassen, gehen zu /var/log/maillog .
Da rsyslog Nachrichten basierend auf ihrem Typ in verschiedene Dateien schreibt, führt das Deaktivieren der Ratenbegrenzung dazu, dass alle Nachrichten in ihre festgelegten Protokolldateien geschrieben werden, nicht nur in die Nachrichtendatei. Sie können dies in Aktion sehen, indem Sie Folgendes tun:
1. Erstellen Sie eine Sicherungskopie Ihrer /etc/rsyslogd.conf Datei.
# cp -p /etc/rsyslog.conf /etc/rsyslog.conf_orig
2. Deaktivieren Sie die Ratenbegrenzung, wie im folgenden Beitrag beschrieben, abhängig von Ihrer Betriebssystemversion.
So deaktivieren oder erweitern Sie die Systemprotokollierungsratenbegrenzung unter CentOS/RHEL 6So deaktivieren oder erweitern Sie die Systemprotokollierungsratenbegrenzung unter CentOS/RHEL 7
3. Notieren Sie sich die Größe der Protokolldateien in /var/log:
# ls -la /var/log
4. Starten Sie rsyslog neu.
# service rsyslog restart ### CentOS/RHEL 6 # systemctl restart rsyslog ### CentOS/RHEL 7
5. Warten Sie etwa 1 Stunde.
6. Machen Sie die in Schritt 2 vorgenommenen Änderungen rückgängig.
7. Starten Sie rsyslog neu.
# service rsyslog restart ### CentOS/RHEL 6 # systemctl restart rsyslog ### CentOS/RHEL 7
8. Beachten Sie die Größe der Protokolldateien in /var/log.
Das Ergebnis davon wird sein:
- Die Größe einer oder mehrerer Protokolldateien außer der Nachrichtendatei in /var/log nahm stark zu.
- Die Häufigkeit der Einträge in einer oder mehreren der Protokolldateien nahm zu, während die Ratenbegrenzung deaktiviert war.
- Es wurden nur wenige Einträge in der Nachrichtendatei gesehen. Wie in diesem Beispiel zu sehen, wurden Nachrichten verworfen, bis die Ratenbegrenzung deaktiviert und rsyslog um 14:30 Uhr neu gestartet wurde. Zwischen 14:30 und 15:33 gibt es nur einen Eintrag für rngd um 14:44. Nach dem Aktivieren der Ratenbegrenzung beginnen die verworfenen Nachrichten erneut.
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
Aus dem Obigen können wir also sehen, dass die Deaktivierung der Ratenbegrenzung tatsächlich funktioniert, nur nicht so, wie man es erwarten würde. Folgendes muss bei der Ratenbegrenzung beachtet werden:
1. Eine zufällige und seltene Flut von Nachrichten ist nicht unbedingt ein Hinweis auf ein Problem. Es kann jedoch eine fortgesetzte anhaltende Wiederholung von verworfenen Nachrichten untersucht werden. Wenn gelöschte Nachrichten häufig auftreten und eine große Anzahl gelöscht wird, muss untersucht werden, was diese Nachrichten sind (Informationen oder tatsächliche Warnungen vor Fehlern). Sie können den obigen Test verwenden, um zu sehen, wohin die Nachrichten gehen, und dann die Protokolle in /var/log überprüfen, um festzustellen, ob ein Problem wirklich existiert, oder bemerken.
2. Seien Sie vorsichtig, wenn Sie die Ratenbegrenzungseinstellungen in rsyslogd.conf ändern oder die Ratenbegrenzung vollständig deaktivieren. Je weniger Nachrichten verworfen werden, desto mehr Verarbeitung ist erforderlich, um sie zu protokollieren. Zu viele Nachrichten können Leistungsprobleme und unter extremen Umständen sogar Räumungen verursachen.