🥇 Freundschaft zwischen ELK und Exchange. Teil 1

Ich beginne eine Artikelreihe, in der ich meine Erfahrungen beim Anschluss von Exchange und ELK teilen möchte. Dieses Stack hilft dabei, große Mengen an Protokolldaten zu verarbeiten, ohne sich fragen zu müssen, bei welcher Größe die gewohnten Logging-Tools aufhören, uns zu helfen. Lass uns den neuen Kämpfer im Umgang mit Logs näher kennenlernen.

Exchange verfügt über ein recht ausgeklügeltes Logging-System. Die gefragtesten Protokolle sind die Tracking-Logs, die den Schritt-für-Schritt-Verlauf einer bestimmten E-Mail innerhalb der Mail-Organisation verfolgen; die Webserver-Logs, die jede neue Sitzung eines Benutzers im System protokollieren, und die Protokolle spezifischer Webanwendungen mit unterschiedlicher Detaillierung der Sitzung. Zudem kann Exchange rohe Protokolle der Protokolle SMTP, IMAP und POP3 speichern.

Welche Tools können wir zur Arbeit mit Logs verwenden:

Der integrierte Befehl Get-MessageTrackingLog: praktisch zur Verarbeitung von Tracking-Logs;
Das Tool logparser: für das Logging nutzt es eine Pseudo-SQL-Sprache zur Suche und arbeitet ziemlich schnell;
Externer SQL-Server: für besonders spezifische Fälle (zum Beispiel die Analyse von Daten über lange Zeiträume).

All dies funktioniert ganz gut, wenn wir ein paar Server haben und das Volumen der verarbeiteten Logs in Dutzenden oder Hunderten von Gigabyte gemessen wird. Was aber, wenn die Anzahl der Server in die Dutzende geht und die Größe der Logs über ein Terabyte steigt? In diesem Fall beginnt dieses Schema wahrscheinlich zu brechen.

Und so sieht es aus: Get-MessageTrackingLog beginnt wegen Zeitüberschreitung auszufallen, logparser stößt an die Grenzen der 32-Bit-Architektur, und der Export in den SQL-Server bricht im ungünstigsten Moment zusammen, ohne viele Zeilen von Exceptions vom Dienst verarbeiten zu können.

Hier kommt ein neuer Spieler ins Spiel – das ELK-Stack, das speziell darauf ausgelegt ist, riesige Mengen an Logs in akzeptabler Zeit und mit einem erträglichen Ressourcenverbrauch zu jonglieren.

Im ersten Teil werde ich ausführlich darüber berichten, wie man filebeat einrichtet, das zum ELK-Stack gehört — verantwortlich für das Lesen und Senden einfacher Textdateien, in die verschiedene Anwendungen ihre Logs schreiben. In den folgenden Artikeln werden wir genauer auf die Komponenten Logstash und Kibana eingehen.

Installation

Also, die Archivdatei des filebeat-Agenten kann von dieser Website heruntergeladen werden.

Wir werden die Installation durch einfaches Entpacken des Inhalts der Zip-Datei durchführen. Beispielsweise in c:Program Filesfilebeat. Dann müssen wir das PowerShell-Skript ausführen install-service-filebeat.ps1, der im Lieferumfang enthalten ist, um den Filebeat-Dienst zu installieren.

Jetzt sind wir bereit, die Konfigurationsdatei einzurichten.

Fehlertoleranz

Filebeat gewährleistet die Zustellung von Protokollen an das Protokollsammlungssystem. Dies wird durch das Führen eines Registers von Einträgen in Protokolldateien umgesetzt. Im Register werden Informationen über die Einträge gespeichert, die aus den Protokolldateien gelesen wurden, und es werden spezifische Einträge markiert, die erfolgreich an ihren Bestimmungsort geliefert wurden.

Wenn ein Eintrag nicht zugestellt werden kann, wird Filebeat versuchen, ihn erneut zu senden, bis die empfangende Systeme eine Zustellbestätigung erhalten oder die ursprüngliche Protokolldatei im Zuge der Rotation gelöscht wird.

Beim Neustart des Filebeat-Dienstes liest das System die Informationen über die zuletzt gelesenen und gelieferten Einträge aus dem Register und liest die Einträge in den Protokolldateien basierend auf den Informationen im Register.

Dies minimiert das Risiko des Verlusts von Informationen über Protokolle, die an die Elastic Logstash-Server gesendet werden müssen, bei unerwarteten Ausfällen und bei Wartungsarbeiten an den Servern.

Weitere Informationen dazu können in den Abschnitten der Dokumentation nachgelesen werden,: Wie Filebeat den Zustand von Dateien beibehält und Wie Filebeat die Zustellung mindestens einmal gewährleistet?

Einstellungen

Die gesamte Konfiguration erfolgt in einer Datei im Format yml, die in mehrere Abschnitte unterteilt ist. Lassen Sie uns einige von ihnen betrachten, die am Prozess der Protokollsammlung von Exchange-Servern beteiligt sind.

Abschnitt zur Protokollverarbeitung

Der Abschnitt zur Protokollverarbeitung beginnt mit dem Feld:

filebeat.inputs:

Wir werden ein allgemeines Werkzeug zur Protokollsammlung verwenden:

- typ: log

Als nächstes geben wir den Status (aktiviert) und die Pfade zum Ordner mit den Protokollen an. Im Fall von IIS-Protokollen könnten die Einstellungen wie folgt aussehen:

    enabled: true
    paths:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log

Eine weitere wichtige Einstellung: wie Filebeat mehrzeilige Einträge lesen soll. Standardmäßig betrachtet Filebeat eine Zeile der Protokolldatei als einen Eintrag. Dies funktioniert gut, solange jedoch keine Ausnahmen im Protokoll auftreten, die mit einer fehlerhaften Dienstleistung zusammenhängen. In diesem Fall können die Ausnahmen aus mehreren Zeilen bestehen. Daher sollte Filebeat einen mehrzeiligen Eintrag als einen einzigen betrachten, wenn die nächste Zeile mit einem Datum beginnt. Das Format der Protokolle in Exchange ist so, dass jeder neue Eintrag in der Protokolldatei mit einem Datum beginnt. In der Konfiguration sieht diese Bedingung folgendermaßen aus:

mehrzeilig:
	muster: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negieren: true
	abgleich: nach

Es macht Sinn, Tags in den gesendeten Eintrag hinzuzufügen, zum Beispiel:

  tags: ['IIS', 'ex-srv1']

Und nicht vergessen, die Zeilen aus der Verarbeitung auszuschließen, die mit dem Hash-Zeichen beginnen:

  exclude_lines: ['^#']

So wird der Log-Leseblock aussehen:

filebeat.inputs:
- typ: log
  aktiviert: true
  pfade:
	- C:inetpublogsLogFilesW3SVC1*.log
	- C:inetpublogsLogFilesW3SVC2*.log
  mehrzeilig:
	muster: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
	negieren: true
	abgleich: nach
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']

Block für das Senden von Logs

Einzelne Einträge in der Log-Datei werden von Filebeat als JSON-Objekt gesendet, in dem der spezifische Log-Eintrag im einzigen Feld message enthalten ist. Wenn wir mit diesen Informationen arbeiten möchten, müssen wir dieses Feld vorher in separate Felder aufteilen. Dies kann zum Beispiel in Logstash geschehen. Er wird der Empfänger der Einträge von Filebeat sein. So könnte das im Konfigurationsfile von Filebeat aussehen:

output.logstash:
  hosts: ["logstash1.domain.com:5044"]

Wenn es mehrere Server gibt, kann die Lastverteilung aktiviert werden: dann wird Filebeat die Logs nicht an den ersten verfügbaren Server in der Liste senden, sondern die gesendeten Logs auf mehrere Server verteilen:

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true

Bei der Verarbeitung der Logs fügt Filebeat im gesendeten JSON neben dem Log-Eintrag, der im Feld message enthalten ist, eine bestimmte Menge an Metadaten hinzu, die sich auf die Größe des Dokuments auswirkt, das in Elastic gelangt. Diese Metadaten können selektiv aus der Sendung entfernt werden. Dies geschieht im Block processor mit dem Prozessor drop_fields. Ausschließen kann man beispielsweise die folgenden Felder:

processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Bei der Auswahl der auszuschließenden Felder sollte man vorsichtig sein, da einige von ihnen auf der Elastic-Seite zur Erstellung von Indizes verwendet werden könnten.

So wird der Log-Sendeblock aussehen:

output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
	fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Filebeat-Logging-Einstellungen

Es macht Sinn, die folgenden Logging-Einstellungen vorzunehmen:

Logging-Stufe: info;
Logs in Dateien auf standardmäßigen Orten (Verzeichnis logs, im Installationsverzeichnis von Filebeat) speichern;
Dateiname des Logs — filebeat;
Die letzten 10 Log-Dateien aufbewahren;
Die Rotation bei Erreichen der Größe von 1 MB starten.

Der endgültige Block der Protokollierungseinstellungen wird wie folgt aussehen:

logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Die endgültige Konfiguration

Wir haben die Konfiguration erstellt, und jetzt sieht sie wie folgt aus:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:inetpublogsLogFilesW3SVC1*.log
    - C:inetpublogsLogFilesW3SVC2*.log
  multiline:
    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
    negate: true
    match: after
  tags: ['IIS', 'ex-srv1']
  exclude_lines: ['^#']
 
output.logstash:
  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]
  loadbalance: true
 
processors:
- drop_fields:
    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]
 
logging.level: info
logging.to_files: true
logging.files:
  name: filebeat
  keepfiles: 10
  rotateeverybytes: 1048576

Es ist wichtig zu verstehen, dass das Format der Konfigurationsdatei — yml ist. Daher ist es wichtig, die Abstände und Bindestriche korrekt zu setzen.

Filebeat kann die Konfigurationsdatei überprüfen und, wenn der Syntax Fehler enthält, angeben, in welcher Zeile und an welcher Stelle die Syntax falsch ist. Die Überprüfung erfolgt wie folgt: