Ich habe die Haproxy-Protokollierung über rsyslogd eingerichtet, mit den Tipps vonDieser Artikel, und alles scheint einwandfrei zu funktionieren. Die Protokolldateien enthalten die Protokollmeldungen.
Allerdings wird jede Protokollnachricht von Haproxy auch unter angezeigt /var/log/syslog. Das bedeutet, dass das Syslog nach dem Live-Schalten des Servers ziemlich nutzlos ist, da es mit Haproxy-Protokollnachrichten überfüllt sein wird.
Ich möchte diese Nachrichten herausfiltern /var/log/syslog. Nachdem ich die rsyslogd-Dokumentation durchgesehen hatte, versuchte ich, die Datei /etc/rsyslog.d/50-default.conffolgendermaßen zu ändern:
*.*;auth,authpriv.none;haproxy.none -/var/log/syslog
Ich habe das ;haproxy.noneTeil einfach hinzugefügt. Nach dem Neustart von rsyslogd funktionierte es überhaupt nicht mehr, bis ich meine Änderungen rückgängig machte.
Was mache ich falsch?
Antwort1
Sie können auch Folgendes tun, um sicherzustellen, dass sie nicht in andere Protokolle gelangen:
local0.* -/var/log/haproxy.log
& ~
Das & ~bedeutet, dass die Übereinstimmung mit der obigen Zeile für die restlichen Regeln nirgendwo anders angegeben werden darf.
Antwort2
Die Verwendung von & ~wurde in v7 von rsyslogd abgelehnt, und Sie werden & stopstattdessen ermutigt, zu verwenden. Weitere Informationen hierzu finden Sie in diesem Abschnitt derv7-Kompatibilitätsseite.
Die Aktionen omruleset und discard (~) sind veraltet.
Beide funktionieren weiterhin, wurden aber durch bessere Alternativen ersetzt.
Die Discard-Aktion (Tilde-Zeichen) wurde durch die RainerScript-Direktive „stop“ ersetzt. Sie gilt als intuitiver und bietet eine etwas bessere Performance.
Das Modul omruleset wurde durch die RainerScript-Direktive „call“ ersetzt. Call ermöglicht die Ausführung eines Regelsatzes wie eine Subroutine und tut dies mit einer viel höheren Leistung als omruleset. Beachten Sie, dass omruleset aus einer asynchronen Warteschlange ausgeführt werden könnte. Dies war eher ein Nebeneffekt als ein gewünschter Effekt und wird von der Call-Anweisung nicht unterstützt. Wenn dieser Effekt benötigt wird, kann er einfach simuliert werden, indem die aufgerufenen Regelsatzaktionen asynchron ausgeführt werden (was in jedem Fall die richtige Art ist, damit umzugehen).
Beachten Sie, dass die veralteten Module bei Verwendung Warnmeldungen ausgeben. Sie geben an, dass das Konstrukt veraltet ist und welche Anweisung als Ersatz verwendet werden soll. Dies hat keine Auswirkungen auf den Betrieb: Beide Module sind noch voll funktionsfähig und werden im v7-Zeitraum nicht entfernt.
Für HAProxy also stattdessen so etwas:
$ more /etc/rsyslog.d/haproxy.conf
local2.* /var/log/haproxy.log
& stop
Die Funktionsweise besteht darin, dass & stoprsyslogd angewiesen wird, alle weiteren Nachrichten zu verwerfen, die den zuvor übereinstimmenden Regeln bis zu diesem Zeitpunkt entsprachen. Um sicherzustellen, dass diese Regel frühzeitig erkannt wird, können Sie den Namen der Datei von /etc/rsyslog.d/haproxy.confin ändern /etc/rsyslog.d/00-haproxy.conf.
Antwort3
Ok, ich habe es herausgefunden. So /etc/rsyslog.d/20-haproxy.confsieht meins aus:
$ModLoad imudp
$UDPServerRun 514
local0.* -/var/log/haproxy_0.log
local1.* -/var/log/haproxy_1.log
Ich habe die Zeile geändert in 50-default.conf:
*.*;auth,authpriv,local0,local1.none -/var/log/syslog
Und jetzt scheint es das zu tun, was ich will.
Antwort4
Ich möchte die Reihenfolge der Datei nicht ändern, also füge ich stattdessen ein local0.none hinzu..Zeileneintrag. Die Konfiguration sieht folgendermaßen aus:
*.info;mail.none;authpriv.none;cron.none;local2.none /var/log/messages
local2.* /var/log/haproxy.log
(Getestet auf CentOS 7)
Hoffentlich hilft das!