Verwalten von Linux-Protokollen

Eine wichtige bewährte Methode für die Protokollierung besteht darin, Ihre Protokolle an einem einzigen Ort zu zentralisieren oder zu aggregieren, insbesondere wenn Sie mehrere Server oder Architekturebenen haben. Moderne Anwendungen verfügen häufig über mehrere Infrastrukturebenen, die eine Mischung aus lokalen Servern und Cloud-Diensten umfassen können. Der Versuch, die richtige Datei zu finden, um einen Fehler zu beheben, wäre unglaublich schwierig, und der Versuch, Probleme systemübergreifend zu korrelieren, wäre noch schwieriger., Es gibt nichts Frustrierenderes, als herauszufinden, dass die gewünschten Informationen nicht in einer Protokolldatei erfasst wurden oder dass die Protokolldatei, in der die Antwort hätte gespeichert werden können, nach einem Neustart des Servers verloren ging.

In diesem Abschnitt wird erläutert, wie Sie Zentralisierungsdienste zum Sammeln und Zentralisieren Ihrer Linux-Protokolldateien verwenden.

Vorteile

Vorteile der Zentralisierung von Protokollen

Die Zentralisierung Ihrer Protokolle erleichtert und beschleunigt die Suche nach Protokolldaten, da alle Ihre Protokolle an einem einzigen Ort zugänglich sind., Anstatt zu erraten, welcher Server über die richtige Datei verfügt, können Sie einfach auf Ihr Repository mit Protokolldaten zugreifen, um nach relevanten Ereignissen zu suchen. Die Zentralisierung ist ein wichtiger Bestandteil großer Managementlösungen, da sie Protokolle analysieren, analysieren und indizieren können, bevor sie an einem einzigen Ort gespeichert werden. Dies erleichtert und beschleunigt die Fehlerbehebung und Lösung von Produktionsproblemen. Auch die Zentralisierung bietet diese Vorteile.

• Protokolle werden an einem separaten Ort gesichert, um sie vor versehentlichem oder unbeabsichtigtem Verlust zu schützen., Dies hält sie auch zugänglich, falls Ihre Server ausfallen oder nicht mehr reagieren.
• Sie müssen keine SSH-oder ineffizienten Grep-Befehle verwenden, die wertvolle Rechenressourcen für komplexe Suchvorgänge verwenden können.
• Sie können den von Protokolldateien verwendeten Speicherplatz reduzieren.
• Ingenieure können Produktionsprobleme beheben, ohne direkt auf Systeme zuzugreifen.

Während eine zentralisierte Protokollverwaltung im Allgemeinen die bessere Option ist, bestehen immer noch einige Risiken wie eine schlechte Netzkonnektivität, die zu Datenverlust führt, oder Protokolle, die viel Netzwerkbandbreite verwenden., Wir werden in den folgenden Abschnitten besprechen, wie Sie diese Probleme intelligent angehen können.

beliebte

Beliebte Tools zum Zentralisieren von Protokollen

Die meisten Linux-Systeme zentralisieren Protokolle bereits mit einem Syslog-Daemon. Wie im Abschnitt Linux Logging Basics erläutert, ist syslog ein Dienst, der Protokolldateien von Diensten und Anwendungen sammelt, die auf dem Host ausgeführt werden. Es kann diese Protokolle in eine Datei schreiben oder sie über das Syslog-Protokoll an einen anderen Server weiterleiten., Es gibt mehrere Syslog-Implementierungen, die Sie verwenden können, einschließlich:

• Rsyslog-ein leichter Daemon, der auf den meisten gängigen Linux-Distributionen installiert ist.
• syslog-ng – der zweitbeliebteste Syslog-Daemon für Linux.
• logstash-ein schwerer Agent, der erweiterte Verarbeitung und Analyse tun kann. Es kann Syslog-Nachrichten mit dem Syslog-Eingabe-Plugin lesen und an eine beliebige Anzahl von Ausgabezielen weiterleiten.
• fluentd– ein weiterer Agent mit erweiterten Verarbeitungsfunktionen. Es unterstützt auch die Syslog-Eingabe mit dem in_syslog-Plugin.,

Rsyslog ist die beliebteste Syslog-Implementierung und wird standardmäßig in vielen Linux-Distributionen installiert. Wenn Sie erweiterte Filter-oder benutzerdefinierte Analysefunktionen benötigen, ist Logstash die nächstbeliebteste Wahl. Logstash ist auch eng in den Elastic Stack integriert, der eine vollständige Protokollverwaltungslösung bietet. In diesem Handbuch konzentrieren wir uns auf die Verwendung von rsyslog, da es so weit verbreitet ist.

config

Rsyslog Konfigurieren.conf

Die rsyslog-Hauptkonfigurationsdatei befindet sich unter /etc/rsyslog.conf., Sie können zusätzliche Konfigurationsdateien im /etc/rsyslog speichern.d/ – Verzeichnis. Unter Ubuntu enthält dieses Verzeichnis beispielsweise , wodurch rsyslog angewiesen wird, die Systemprotokolle in eine Datei zu schreiben. Weitere Informationen zu den Konfigurationsdateien finden Sie in der rsyslog-Dokumentation.

Bei der Konfiguration von rsyslog werden Eingabequellen (bei denen rsyslog Protokolle empfängt) sowie Zielregeln für das Schreiben von Protokollen eingerichtet. Rsyslog bietet bereits Standardeinstellungen für den Empfang von Syslog-Ereignissen, sodass Sie normalerweise nur Ihren Zentralisierungsserver als Ausgabe hinzufügen müssen., Rsyslog verwendet RainerScript für seine Konfigurationssyntax. In diesem Beispiel leiten wir unsere Protokolle unter central.example.com über TCP-Port 514 an den Server weiter.

action(type="omfwd" protocol="tcp" target="central.example.com" port="514")

Alternativ können wir unsere Protokolle an eine Protokollverwaltungslösung senden. Cloud-basierte Protokollverwaltungsanbieter wie SolarWinds ® Loggly® stellen Ihnen einen Hostnamen und Port zur Verfügung, an den Sie Ihre Protokolle senden können, indem Sie einfach die Felder target und port ändern. Überprüfen Sie bei der Konfiguration von rsyslog die Dokumentation Ihres Anbieters..,

direct

Logging-Dateien und-Verzeichnisse

Rsyslog stellt das imfile-Modul zur Verfügung, mit dem Protokolldateien auf neue Ereignisse überwacht werden können. Auf diese Weise können Sie eine Datei oder ein Verzeichnis als Protokollquelle angeben. Rsyslog kann einzelne Dateien sowie ganze Verzeichnisse überwachen.

Zum Beispiel möchten wir Protokolldateien überwachen, die vom Apache-Server erstellt wurden. Wir können dies tun, indem wir eine neue Datei in /etc/rsyslog.d/ mit dem Namen apache.conf, das imfile-Modul laden und die Protokolldateien von Apache als Eingaben hinzufügen.,

Der Dateiparameter unterstützt Platzhalter für die Überwachung mehrerer Dateien sowie Verzeichnisse.

Protokoll

Welches Protokoll: UDP, TCP oder RELP?

Bei der Übertragung von Protokolldaten stehen drei Hauptprotokolle zur Auswahl: UDP, TCP und RELP.

UDP sendet Nachrichten ohne Zustellung oder Empfangsbestätigung (ACK). Es unternimmt einen einzigen Versuch, ein Paket zu senden, und wenn die Zustellung fehlschlägt, wird es nicht erneut versucht. Es ist viel schneller und verbraucht weniger Ressourcen als andere Protokolle, sollte aber nur in zuverlässigen Netzwerken wie localhost verwendet werden., UDP unterstützt auch keine Verschlüsselung von Protokollen.

TCP ist das am häufigsten verwendete Protokoll für das Streaming über das Internet, da vor dem Senden des nächsten Pakets ein ACK erforderlich ist. Wenn die Zustellung fehlschlägt, wird sie fortgesetzt, bis die Nachricht erfolgreich übermittelt wurde. TCP erfordert jedoch einen Handshake und eine aktive Verbindung zwischen Sender und Empfänger, die zusätzliche Netzwerkressourcen verwendet.

RELP (Reliable Event Logging Protocol) wurde speziell für rsyslog entwickelt und ist wohl das zuverlässigste dieser drei Protokolle., Es bestätigt den Empfang von Daten in der Anwendungsschicht und wird erneut gesendet, wenn ein Fehler vorliegt. Da dies weniger häufig vorkommt, müssen Sie sicherstellen, dass Ihr Ziel auch dieses Protokoll unterstützt.

Wenn rsyslog beim Speichern von Protokollen auf ein Problem stößt, z. B. auf eine nicht verfügbare Netzwerkverbindung, werden die Protokolle in die Warteschlange gestellt, bis die Verbindung wiederhergestellt ist. Die Protokolle in der Warteschlange werden standardmäßig im Speicher gespeichert. Der Speicher ist jedoch begrenzt und wenn das Problem weiterhin besteht, können die Protokolle die Speicherkapazität überschreiten, was zu Datenverlust führen kann. Um dies zu verhindern, sollten Sie Datenträgerwarteschlangen verwenden.,

Warnung: Sie können Daten verlieren, wenn Sie Protokolle nur im Speicher speichern.

que

Zuverlässig mit festplattenunterstützten Warteschlangen senden

Rsyslog kann Ihre Protokolle auf die Festplatte in die Warteschlange stellen, wenn der Speicher voll ist. Festplattenunterstützte Warteschlangen machen den Transport von Protokollen zuverlässiger. Hier ist ein Beispiel, wie Sie eine Protokollweiterleitungsregel in rsyslog mit einer datenträgerunterstützten Warteschlange konfigurieren.

encrypt

Encrypt Logs Using TLS

Wenn Datensicherheit und Datenschutz ein Problem darstellen, sollten Sie die Verschlüsselung Ihrer Logs in Betracht ziehen. Sniffer und Zwischenhändler könnten Ihre Protokolldaten lesen, wenn Sie sie im Klartext über das Internet übertragen., Sie sollten Ihre Protokolle verschlüsseln, wenn sie private Informationen, sensible Identifikationsdaten oder von der Regierung regulierte Daten enthalten. Der rsyslog-Daemon kann Ihre Protokolle mithilfe des TLS-Protokolls verschlüsseln und Ihre Daten sicherer machen.

Die Aktivierung der TLS-Verschlüsselung hängt von Ihrem Logging-Setup ab. Im Allgemeinen umfasst es die folgenden Schritte.

1. Erstellen Sie eine Zertifizierungsstelle. Es gibt Beispielzertifikate im Verzeichnis /contrib/gnutls von rsyslog, die nur zum Testen geeignet sind, aber Sie müssen Ihre eigenen für die Produktion erstellen., Wenn Sie einen Protokollverwaltungsdienst verwenden, steht einer für Sie bereit.
2. Generieren Sie ein digitales Zertifikat für Ihren Server, um TLS zu aktivieren, oder verwenden Sie eines von Ihrem Protokollverwaltungsdienstanbieter.
3. Konfigurieren Sie Ihren rsyslog-Dienst so, dass TLS-verschlüsselte Daten an Ihren Protokollverwaltungsdienst gesendet werden.

Hier ist ein Beispiel rsyslog Konfiguration mit TLS Verschlüsselung. Ersetzen Sie CERT und DOMAIN_NAME durch Ihre eigene Servereinstellung.,

$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt$ActionSendStreamDriver gtls$ActionSendStreamDriverMode 1$ActionSendStreamDriverAuthMode x509/name$ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com

Protokollverwaltungsdienste wie SolarWinds Loggly stellen häufig eigene CAs und Zertifikate zur Verfügung, auf die Sie in Ihrer rsyslog-Konfiguration lediglich verweisen müssen. Wenn Sie beispielsweise TLS mit Loggly aktivieren, müssen Sie das Loggly-Zertifikat nur in Ihr /etc/rsyslog herunterladen.d / Verzeichnis, aktualisieren Sie Ihre Konfiguration und starten Sie den rsyslog-Dienst neu.

Laden Sie zuerst das Zertifikat herunter.

$ mkdir -pv /etc/rsyslog.d/keys/ca.d$ cd /etc/rsyslog.d/keys/ca.d$ curl -O https://logdog.loggly.com/media/logs-01.loggly.com_sha12.crt

Öffnen Sie dann die Konfigurationsdatei /etc/rsyslog.d/22-loggly.conf und fügen Sie Folgendes hinzu:

Starten Sie rsyslog schließlich neu.,

$ sudo service rsyslog restart

practice

Best Practices für die Anwendungsprotokollierung

Zusätzlich zu den Protokollen, die Linux standardmäßig erstellt, ist es auch eine gute Idee, Protokolle von wichtigen Anwendungen zu zentralisieren. Fast alle Linux – basierten Serveranwendungen schreiben ihre Statusinformationen in separaten, dedizierten Protokolldateien. Dazu gehören Datenbankprodukte wie PostgreSQL oder MySQL, Webserver wie Nginx oder Apache, Firewalls, Druck-und Dateifreigabedienste, Verzeichnis-und DNS-Server usw.

Das erste, was Administratoren nach der Installation einer Anwendung tun, ist die Konfiguration., Linux-Anwendungen haben in der Regel eine .conf Datei irgendwo im Verzeichnis / etc. Es kann auch woanders sein, aber das ist der erste Ort, an dem Leute nach Konfigurationsdateien suchen. Abhängig davon, wie komplex oder groß die Anwendung ist, kann die Anzahl der einstellbaren Parameter nur wenige oder Hunderte betragen. Weitere Informationen finden Sie in der Dokumentation der Anwendung oder versuchen Sie mithilfe des Befehls Suchen, die Datei selbst zu finden.

# locate postgresql.conf/usr/pgsql-9.4/share/postgresql.conf.sample/var/lib/pgsql/9.4/data/postgresql.conf

Legen Sie einen Standardspeicherort für Protokolldateien fest

Linux-Systeme speichern ihre Protokolldateien normalerweise im Verzeichnis /var/log., Dies funktioniert einwandfrei, überprüfen Sie jedoch, ob die Anwendung in einem bestimmten Verzeichnis unter /var/loggespeichert ist. Wenn ja, großartig. Wenn nicht, können Sie ein dediziertes Verzeichnis für die App unter /var/logerstellen. Warum? Das liegt daran, dass andere Anwendungen ihre Protokolldateien auch unter /var/log speichern und wenn Ihre App mehr als eine Protokolldatei speichert-vielleicht einmal täglich oder nach jedem Neustart des Dienstes-Es kann etwas schwierig sein, durch ein großes Verzeichnis zu kriechen, um die gewünschte Datei zu finden.,

Wenn mehr als eine Instanz der Anwendung in Ihrem Netzwerk ausgeführt wird, ist dieser Ansatz ebenfalls praktisch. Denken Sie an eine Situation, in der möglicherweise ein Dutzend Webserver in Ihrem Netzwerk ausgeführt werden. Wenn Ihre Protokolle auf einem zentralen Syslog-Server gespeichert sind, woher wissen Sie, welche Protokolldatei die Protokolle des Servers enthält? Wenn Sie jeden Server in einem separaten Verzeichnis anmelden, wissen Sie genau, wo Sie bei der Fehlerbehebung für einen Server suchen müssen.

Verwenden Sie einen statischen Dateinamen

Viele Anwendungen fügen ihrem Protokolldateinamen dynamische Daten hinzu, z. B. das aktuelle Datum oder den aktuellen Zeitstempel., Dies ist nützlich, um Protokolle automatisch nach Datum aufzuteilen, macht es jedoch für Dienste wie rsyslog schwieriger, die neueste Datei zu finden. Ein besserer Ansatz besteht darin, einen sich nicht ändernden Namen für Ihre Protokolldatei zu verwenden und dann logrotate zu verwenden, um einen Zeitstempel oder eine Nummer auf ältere Protokolldateien anzuwenden.

Protokolldateien anhängen und drehen

Anwendungen sollten an vorhandene Protokolldateien angehängt werden, anstatt sie zu überschreiben. Dadurch wird sichergestellt, dass alle Protokollzeilen erfasst werden und keine Daten verloren gehen, auch wenn die Anwendung neu gestartet wird. Protokolldateien können jedoch mit der Zeit sehr groß werden., Wenn Sie versuchen, die Ursache eines Problems zu finden, können Sie am Ende Zehntausende von Zeilen durchsuchen.

Wir empfehlen, Ihre Protokolle an eine einzelne Datei anzuhängen, aber wir empfehlen auch, die Anwendung so zu konfigurieren, dass sie ihre Protokolldateien von Zeit zu Zeit dreht. Tools wie logrotate können dies automatisch tun, indem Sie die aktuelle Protokolldatei an einen neuen Speicherort kopieren, ihm einen eindeutigen Namen geben und dann die aktuelle Protokolldatei abschneiden., Dies hat eine Reihe von Vorteilen, darunter:

1. Protokolle werden nach Datum und Uhrzeit auf Dateien aufgeteilt, so dass es einfach ist, Protokolle für ein bestimmtes Datum zu finden
2. Jede Protokolldatei ist viel kleiner, wodurch sie einfacher zu durchsuchen und einfacher über ein Netzwerk zu senden sind
3. Das Sichern von Protokolldateien ist viel einfacher und das Löschen oder Archivieren älterer Protokolle kann viel schneller erfolgen

Wie oft Sie Protokolldateien drehen, hängt davon ab, wie viele Protokolle Sie generieren. Als Faustregel gilt zunächst, dass Sie Ihre Protokolle einmal pro Tag drehen.

Richtlinien zur Aufbewahrung von Protokolldateien festlegen

Wie lange führen Sie eine Protokolldatei?, Das kommt definitiv auf geschäftliche Anforderungen an. Sie können aufgefordert werden, Protokollierungsinformationen im Wert von einer Woche aufzubewahren, oder es kann eine regulatorische Anforderung sein, Daten im Wert von 10 Jahren aufzubewahren. Was auch immer es ist, Protokolle müssen zu der einen oder anderen Zeit vom Server gehen.

Sofern nicht anders erforderlich, sollten Sie Logdateien im Wert von mindestens einem Monat online aufbewahren und an einen sekundären Speicherort (wie einen Logging-Server) kopieren. Alles, was älter ist, kann auf ein separates Medium geladen werden. Wenn Sie sich beispielsweise in AWS befinden, können Ihre älteren Protokolle in Glacier kopiert werden.,

Log-Dateien auf einem separaten Laufwerk speichern

Log-Dateien werden ständig geschrieben, was auf ausgelasteten Systemen zu hohen Festplatten-E / A führen kann. Als bewährte Methode sollten Sie /var/log auf einem separaten Speichergerät mounten. Dies verhindert, dass Protokolldateischreibvorgänge die Leistung Ihrer Anwendungen beeinträchtigen, insbesondere auf festplattenbasiertem Speicher. Dies verhindert auch, dass Protokolldateien das gesamte Laufwerk füllen, falls sie zu groß werden.

Formatieren Sie Ihre Logeinträge

Welche Informationen sollten Sie in jedem Logeintrag erfassen?

Das hängt davon ab, wofür Sie das Protokoll verwenden möchten., Möchten Sie es nur zur Fehlerbehebung verwenden oder möchten Sie alles erfassen, was passiert? Ist es eine gesetzliche Anforderung zu erfassen, was jeder Benutzer ausgeführt oder angezeigt wird?

Wenn Sie Protokolle zur Fehlerbehebung verwenden, speichern Sie nur Fehler, Warnungen oder schwerwiegende Meldungen. Es gibt beispielsweise keinen Grund, Debug-Nachrichten zu erfassen. Die App protokolliert möglicherweise standardmäßig Debug-Nachrichten, oder ein anderer Administrator hat dies möglicherweise für eine weitere Fehlersuche aktiviert, aber Sie müssen dies deaktivieren, da dies den Speicherplatz definitiv schnell füllen kann., Erfassen Sie mindestens das Datum, die Uhrzeit, den Namen der Clientanwendung, die Quell-IP oder den Hostnamen des Clients, die ausgeführte Aktion und die Nachricht selbst.

Betrachten Sie beispielsweise das Standardprotokollierungsverhalten von PostgreSQL. Protokolle werden in /var/log/postgresql gespeichert, und jede Datei beginnt mit postgresql – gefolgt vom Datum. Dateien werden täglich gedreht, und ältere Dateien werden mit einer Zahl angehängt, je nachdem, wann sie gedreht wurden. Jeder Protokollzeile können Felder wie der aktuelle Zeitstempel, der aktuelle Benutzer, der Datenbankname, die Sitzungs-ID und die Transaktions-ID vorangestellt werden., Sie können diese Einstellungen ändern, indem Sie die Konfigurationsdatei von PostgreSQL bearbeiten (/etc/postgresql/11/main/postgresql.conf unter Debian).

Standardmäßig zeigt jede Protokollzeile den Zeitstempel und die PostgreSQL-Prozess-ID gefolgt von der Protokollnachricht an.

Überwachen von Protokolldateien mit Imfile

Traditionell ist die häufigste Art und Weise für Anwendungen, ihre Daten zu protokollieren mit Dateien. Dateien lassen sich auf einem einzelnen Computer leicht suchen, skalieren jedoch nicht gut mit mehr Servern. Mit rsyslog können Sie Dateien auf Änderungen überwachen und neue Ereignisse in syslog importieren, wo Sie die Protokolle dann an einen zentralen Server weiterleiten können., Dies geschieht mit dem Modul imfile. Um das Modul zu aktivieren, erstellen Sie eine neue Konfigurationsdatei in /etc/rsyslog.d/ und fügen Sie dann eine Dateieingabe wie diese hinzu.

Fügen Sie nach dieser Konfiguration Ihre Ausgabestreams hinzu, und rsyslog sendet Protokolle aus der angegebenen Datei an das Ausgabeziel.

Melden Sie sich mit Imuxsock direkt am Syslog-Socket an

Ein Socket ähnelt einem UNIX-Dateihandle, außer er liest Daten in den Speicher, anstatt sie auf die Festplatte zu schreiben. Im Falle von Syslog können Sie Protokolle direkt an Syslog senden, ohne sie zuerst in eine Datei schreiben zu müssen.,

Dieser Ansatz nutzt Systemressourcen effizient, wenn Ihr Server durch Festplatten-E/A eingeschränkt ist oder Sie keine lokalen Dateiprotokolle benötigen. Der Nachteil dieses Ansatzes ist, dass der Socket eine begrenzte Warteschlangengröße hat. Wenn Ihr Syslog-Daemon ausfällt oder nicht mithalten kann, können Sie Protokolldaten verlieren.

Um die Socket-Protokollierung in rsyslog zu aktivieren, fügen Sie Ihrer rsyslog-Konfiguration die folgende Zeile hinzu (standardmäßig aktiviert).

$ModLoad imuxsock

Dies erstellt standardmäßig einen Socket bei /dev/log socket, aber Sie können dies ändern, indem Sie die SysSock.Name parameter., Sie können auch Optionen wie Ratenbegrenzung und Flusskontrolle einstellen. Weitere Informationen finden Sie in der rsyslog imuxsock Dokumentation.

UDP-Protokolle Mit Imupd

Einige Anwendungen geben Protokolldaten im UDP-Format aus, das Standardprotokoll beim Übertragen von Protokolldateien über ein Netzwerk oder Ihren Localhost. Ihr Syslog-Daemon empfängt diese Protokolle und kann sie in einem anderen Format verarbeiten oder übertragen. Alternativ können Sie die Protokolle an einen anderen Syslog-Server oder an eine Protokollverwaltungslösung senden.,

Verwenden Sie den folgenden Befehl, um rsyslog so zu konfigurieren, dass Syslog-Daten über UDP auf dem Standardport 514 akzeptiert werden.

$ModLoad imudp$UDPServerRun 514

Konfiguration auf vielen Servern verwalten

Wenn Sie nur wenige Server haben, können Sie die Protokollierung manuell konfigurieren. Sobald Sie ein paar Dutzend oder mehr Server haben, können Sie Tools nutzen, die dies einfacher und skalierbarer machen. Auf einer grundlegenden Ebene besteht das Ziel jedes Tools darin, Syslog auf jedem Ihrer Server zu aktivieren, eine Konfiguration anzuwenden und sicherzustellen, dass die Änderungen wirksam werden.,

Pssh

Mit Pssh (oder parallelem SSH) können Sie einen ssh-Befehl auf mehreren Servern parallel ausführen. Verwenden Sie eine pssh-Bereitstellung nur für eine kleine Anzahl von Servern. Wenn einer Ihrer Server fehlschlägt, müssen Sie ssh in den fehlgeschlagenen Server einspeisen und die Bereitstellung manuell durchführen. Wenn Sie mehrere fehlgeschlagene Server haben, kann die manuelle Bereitstellung lange dauern.

Puppet / Chef

Puppet und Chef sind Konfigurationsmanagementtools, mit denen Sie alle Ihre Server automatisch konfigurieren und in denselben Status bringen können. Sie können Ihre Server überwachen und synchronisieren., Puppet und Chef sind leistungsstarke Tools, mit denen Software installiert, Dateien erstellt, Dienste neu gestartet und vieles mehr werden kann. Wenn Sie nicht sicher sind, welches für Ihr Bereitstellungskonfigurationsmanagement besser geeignet ist, können Sie den Vergleich der beiden Tools von InfoWorld zu schätzen wissen.

Einige Anbieter bieten auch Module oder Rezepte für die Konfiguration von syslog. Loggly stellt beispielsweise ein Puppet-Modul bereit, das rsyslog verwendet, um Protokolle von Ihren Agenten automatisch weiterzuleiten. Installieren Sie das Modul Loggly Puppet auf Ihrem Puppet Master und fügen Sie dann die folgende Konfiguration zu Ihrem Puppet Manifest hinzu.,

 # Send syslog events to Loggly class { 'loggly::rsyslog': customer_token => 'YOUR_CUSTOMER_TOKEN', }

Sobald Ihre Agenten aktualisiert sind, beginnen sie sich bei Loggly anzumelden.

Kubernetes

Kubernetes ist ein Orchestrierungstool zum Verwalten von Containern auf mehreren Knoten. Kubernetes bietet eine vollständige Protokollierungsarchitektur, die Containerprotokolle automatisch sammelt und in eine Datei auf dem Hostcomputer schreibt. Sie können Protokolle für einen bestimmten Pod anzeigen, indem Sie den Befehl kubectl logs <pod name> ausführen, der für den Zugriff auf Anwendungsprotokolle auf einem Remote-Server nützlich ist.,

Viele Protokollverwaltungslösungen bieten Agenten, die über Kubernetes bereitgestellt werden können, um sowohl Anwendungsprotokolle als auch Hostprotokolle zu erfassen. Loggly stellt beispielsweise ein DaemonSet bereit, das einen Protokollierungs-Pod für jeden Knoten in einem Cluster bereitstellt. Der Pod sammelt Protokolle von anderen Pods und vom Host selbst, und die Bereitstellung als DaemonSet stellt sicher, dass auf jedem Knoten immer eine Instanz ausgeführt wird. Das Protokollieren eines Kubernetes-Clusters mit Loggly ist so einfach wie das Ausführen der folgenden Befehle.

Docker

Docker verwendet Container, um Anwendungen unabhängig vom zugrunde liegenden Server auszuführen., Es wird häufig als Containerlaufzeit für Orchestratoren wie Kubernetes verwendet, kann jedoch als eigenständige Plattform verwendet werden. ZDNet hat einen ausführlichen Artikel über die Verwendung von Docker in Ihrem Rechenzentrum.,

Es gibt verschiedene Möglichkeiten, sich von Docker-Containern aus zu protokollieren, darunter:

• Protokollierung über den Docker-Protokollierungstreiber auf dem Host-System (die empfohlene Methode)
• Routing aller Containerprotokolle an einen einzelnen dedizierten Protokollierungscontainer (so funktioniert der Logspout-Container)
• Protokollierung in einem Sidecar-Protokollierungscontainer
• Hinzufügen eines Protokollierungsagenten zum Container

Sie können Docker-Container auch verwenden, um Protokolle vom Host zu sammeln.., Wenn in Ihrem Container ein Syslog-Dienst ausgeführt wird, können Sie entweder Protokolle vom Host über Syslog an den Container senden oder die Protokolldateien des Hosts innerhalb des Containers mounten und einen Dateiüberwachungsagenten zum Lesen der Dateien verwenden.

Herstellerskripte oder Agenten

Die meisten Protokollverwaltungslösungen bieten Skripte oder Agenten an, um das Senden von Daten von einem oder mehreren Servern relativ einfach zu machen. Schwergewichtige Agenten können zusätzliche Systemressourcen verbrauchen. Einige Anbieter integrieren vorhandene rsyslog-Daemons, um Protokolle weiterzuleiten, ohne wesentlich mehr Ressourcen zu verwenden., Loggly stellt beispielsweise ein Skript bereit, das Protokolle von rsyslog mithilfe des omfwd-Moduls an die Loggly-Aufnahmeserver weiterleitet.