Protokolle sind eine wesentliche Komponente von IT-Systemen und helfen Ihnen bei folgenden Aufgaben:

• Überwachung der Infrastrukturleistung
• Erkennung von Anwendungsfehlern
• Durchführung von Ursachenanalysen
• Untersuchung von Sicherheitszwischenfällen
• Nachverfolgung von Benutzerverhalten
• … und mehr

Um Protokolle optimal nutzen zu können, benötigen Sie ein robustes Log-Management-System, das mit den verschiedenen strukturierten und unstrukturierten Formaten der Protokolle umgehen kann.

Eine gut konzipierte Log-Management-Lösung erfasst, analysiert und speichert Protokolle unabhängig von ihrem Format. Sie können damit also Daten aus verschiedenen Systemen durchsuchen, analysieren und korrelieren, um Trends zu ermitteln, Dashboards zusammenzustellen und sogar Warnungen zu erstellen, die Ihre Geschäftsabläufe verbessern.

In diesem Artikel geht es um allgemeine Protokollformate sowie häufig in IT-Systemen genutzte Formate.

Eine kurze Einführung in Protokollformate

Das Protokollformat legt fest, wie der Inhalt einer Protokolldatei interpretiert werden soll. In der Regel definiert ein Format folgende Punkte:

• Ob die Protokollinhalte strukturiert oder unstrukturiert sind
• Ob die Daten im Klartext oder binär vorliegen
• Welche Art von Kodierung die Protokolldatei verwendet
• Wie Datensätze voneinander abgegrenzt werden

Protokollformate können auch die in der Protokolldatei enthaltenen Felder und die Datentypen für diese Felder definieren, z. B. name=text oder age=number. Spezielle Felder wie Zeitstempel haben meist vordefinierte Formate (z. B. ISO 8601, die so angezeigt werden: 2022-07-10 15:21:00.000).

Bei Anwendungen sind die verfügbaren Protokollformate in der Regel vorgegeben. In einigen Fällen überlässt die Anwendung dem Benutzer die Wahl des Formats (z. B. JSON oder CSV). Bei Hardwaregeräten legt meist der Hersteller fest, welche Protokollarten verwendet werden.

Strukturierte, halbstrukturierte und unstrukturierte Protokolle

Protokolldateien haben ein strukturiertes, halbstrukturiertes oder unstrukturiertes Format.

Strukturierte Protokollformate haben ein eindeutiges durchgängiges Muster und können sowohl von Menschen als auch Maschinen gelesen werden. Die Felder werden häufig durch Kommata (z. B. in CSV-Dateien), Leerzeichen oder Bindestriche getrennt. Mitunter werden sie auch mit einem Gleichheitszeichen (=) verbunden (z. B. name=Jane oder city=Paris).

Die meisten Log-Management-Systeme verfügen über vorkonfigurierte integrierte Parser und können problemlos strukturierte Protokollformate verarbeiten. Dies ist ein Beispiel für eine strukturierte Protokolldatei:

[{
  "Env" : "Prod",
  "ServerName" : "LAPTOP123",
  "AppName" : "Console1.vmhost.exe",
  "AppLoc" : "C:\Test\stackify-api-dotnet\dst\ConsoleApplication1\bin\Debug\Console1.vmhost.exe",
  "Logger" : "StackifyLib.net",
  "Msgs" : [{
    "Msg" : "Incoming metrics data",
    "data" : "{"clientid":12345}",
    "EpochMs" : 1445345672470,
    "Level" : "INFO",
    "id" : "0c12301b-e4ge-11e6-8933-897567896a4"
  }]
}]

Unstrukturierte Protokollformate haben kein bestimmtes Muster, sind aber dennoch für Menschen leicht lesbar. Das macht es schwierig, Ereignisse voneinander zu trennen und die Schlüssel-Wert-Paare während des Parsens zu extrahieren. Wenn das Log-Management-System keinen integrierten Parser besitzt, müssen unstrukturierte Protokolle individuell geparst werden, was häufig zusätzliche manuelle Arbeit bedeutet.

2018-10-25 11:56:35,008 INFO [LAPTOP321-1-3] c.a.c.d.RFC4519DirectoryMembershipsIterable Found 7 children for 7 groups in 2 ms
Starting process to remove.
Process started.
Process completed.

Halbstrukturierte Protokolle sind für den Menschen leicht lesbar. Aufgrund ihres Schemas oder Musters können sie jedoch auch von Maschinen gelesen werden. Die Feld- und Ereignistrennzeichen sind hier etwas komplexer als Kommata oder Gleichheitszeichen. Allerdings haben sie immer ein Muster. Log-Management-Systeme können halbstrukturierte Protokolle verarbeiten, benötigen jedoch meist einen Parser, um Ereignisse aufzuteilen und Schlüssel-Wert-Paare zu extrahieren. Dies erfolgt in der Regel über reguläre Ausdrücke oder anderen Code.

Häufig genutzte Protokoll formate

Es gibt sehr unterschiedliche Protokollformate, die je nach System, Anwendung und Tool variieren. Bestimmte Protokollformate werden jedoch sehr häufig verwendet. Nachfolgend werfen wir einen Blick auf die wichtigsten von ihnen.

JSON

JavaScript Object Notation (JSON) ist eines der am häufigsten genutzten Protokollformate. JSON-Protokolle sind halbstrukturiert und enthalten mehrere Schlüssel-Wert-Paare. Mit JSON können Protokolle Daten in verschiedenen Ebenen verschachteln, wobei das Format für Menschen dennoch leicht lesbar bleibt. Zudem bietet JSON eine Möglichkeit, Datentypen wie Zeichenfolge, Zahl, boolescher Wert, Null bzw. leer, Objekt oder Array zu erhalten.

Als relativ neues Format nutzt JSON während der Übertragung und am Speicherort meist die UTF-8-Kodierung. Es kann daher sowohl von Unix-Derivaten als auch von Windows-Betriebssystemen gelesen werden. Es gibt keine Einschränkungen hinsichtlich der Menge oder Art der möglichen Felder, was für NoSQL-Datenbanken (oder schemalose) Datenbanken ideal ist. Es kann jedoch zusätzliche Arbeit bei der Protokollerstellung bedeuten, da die Feldtypen der Anwendungen mit denen der Protokollquellen übereinstimmen müssen.

Hier ist ein Beispiel für eine JSON-Protokolldatei:

{
  "timestamp": "2022-07-29T02:03:45.293Z",
  "message": "User Jane.Doe has logged in",
  "log": {
    "level": "info",
    "file": "auth.c",
    "line": 66,
  },
  "user": {
    "name": "jane.doe",
    "id": 235
  },
  "event": {
    "success": true
  }
}

Windows-Ereignisprotokolle

Windows-Ereignisprotokolle enthalten Daten zu Ereignissen, die im Windows-Betriebssystem auftreten. In den Windows-Ereignisprotokollen werden Sicherheits-, Anwendungs-, System- und DNS-Ereignisse festgehalten. Sie alle verwenden dasselbe Protokollformat.

Systemadministratoren nutzen Windows-Ereignisprotokolle häufig, um die Ursachen von System- oder Anwendungsfehlern zu ermitteln, Zwischenfälle zu untersuchen oder Benutzeranmeldungen nachzuverfolgen. Die Protokolle sind meist sehr ausführlich und enthalten Informationen wie Zeitstempel, Ereignis-ID, Benutzername, Hostname, Nachricht und Aufgabenkategorie.

So sieht ein Windows-Ereignisprotokoll beispielsweise aus:

An account was successfully logged on.
 
Subject:
    Security ID: SYSTEM
    Account Name: DESKTOP-LLHJ389$
    Account Domain: WORKGROUP
    Logon ID: 0x3E7
 
Logon Information:
    Logon Type: 7
    Restricted Admin Mode: -
    Virtual Account: No
    Elevated Token: No
 
Impersonation Level: Impersonation
 
New Logon:
    Security ID: AzureAD\RandyFranklinSmith
    Account Name: [email protected]
    Account Domain: AzureAD
    Logon ID: 0xFD5113F
    Linked Logon ID: 0xFD5112A
    Network Account Name: -
    Network Account Domain: -
    Logon GUID: {00000000-0000-0000-0000-000000000000}
 
Process Information:
    Process ID: 0x30c
    Process Name: C:\Windows\System32\lsass.exe
 
Network Information:
    Workstation Name: DESKTOP-LLHJ389
    Source Network Address: -
    Source Port: -
 
Detailed Authentication Information:
    Logon Process: Negotiate
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

CEF

Das Common Event Format (CEF) ist ein offenes, textbasiertes Protokollformat, das von Geräten und Anwendungen im Sicherheitsbereich verwendet wird. CEF wurde von ArcSight Enterprise Security Manager entwickelt und wird von SIEM- und Log-Management-Systemen bei der Erfassung und Zusammenführung von Daten genutzt.

CEF-Protokolle verwenden die UTF-8-Kodierung und enthalten ein gemeinsames Präfix, einen CEF-Header und eine variable Erweiterung, die eine Liste von Schlüssel-Wert-Paaren enthält.

Das Präfix enthält den Zeitstempel des Ereignisses und den Hostnamen. Der Header umfasst die CEF-Softwareversion, den Gerätehersteller, das Geräteprodukt, die Geräteversion, die Ereignisklassen-ID des Geräts, den Namen und den Schweregrad. Der Rest der Protokollnachricht besteht aus weiteren benutzerdefinierten Feldern, die detailliertere Informationen enthalten.

Dies ist ein Beispiel-Eintrag im CEF-Format:

CEF:0|Trend Micro|Deep Security Manager|<DSM version>|600|User Signed In|3|src=10.52.116.160 suser=admin target=admin msg=User signed in from 2001:db8::5

CLF

Das NCSA Common Log Format (CLF) ist eines der ältesten von Webservern verwendeten Protokollformate. CLF-Protokolle sind standardisierte, textbasierte Protokolldateien mit einem festen Format – d. h. die Felder können nicht angepasst werden. Jede Zeile einer solchen Protokolldatei enthält folgende Informationen:

• Remote-Host-Adresse
• Remote-Protokollname
• Benutzername
• Zeitstempel
• Anfrage und Protokollversion
• HTTP-Statuscode
• Gesendete Bytes

Bindestriche stehen für Felder, die keine Daten für dieses Ereignis enthalten, während Pluszeichen (+) für nicht unterstützte Zeichen stehen.

Dies ist ein Beispiel für ein CLF-Protokoll:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

ELF

Das Extended Log Format (ELF) kommt in Webanwendungen zum Einsatz. Es ähnelt CLF, bietet jedoch mehr Informationen und Flexibilität hinsichtlich der möglichen Felder. ELF-Protokolle enthalten Daten, die sich auf eine einzelne HTTP-Transaktion beziehen. Die Felder werden durch Leerzeichen voneinander getrennt, wobei ein Bindestrich für ein fehlendes Feld steht.

Am Anfang des Protokolls stehen Version, Datum, Uhrzeit, Software und eventuell relevante Kommentare. Davor steht ein Rautezeichen (#). Zudem enthält das Protokoll die Feldnamen, was dem Protokoll-Handler die ordnungsgemäße Analyse der Felder deutlich erleichtert.

W3C

Das erweiterte Protokolldateiformat W3C ist ein stark anpassbares Protokollformat, das von Windows IIS-Servern genutzt wird. Hier lässt sich konfigurieren, welche Felder enthalten sein sollen, sodass nur relevante Informationen aufgeführt werden und die Größe der Protokolldateien möglichst klein bleibt. Folgende Felder sind zum Beispiel enthalten:

• Zeitstempel
• Client-IP-Adresse
• Server-IP-Adresse
• URI-Stamm
• HTTP-Statuscode
• Gesendete Bytes
• Empfangene Bytes
• Benötigte Zeit
• Version

Einige Felder tragen das Präfix s (Server), c (Client), sc (Server-zu-Client-Aktion) oder cs (Client-zu-Server-Aktion), um anzuzeigen, ob es sich um die Server- oder Clientseite handelt.

So sieht ein W3C-Protokoll zum Beispiel aus:

#Software: Internet Information Services 6.0 
#Version: 1.0 
#Date: 2001-05-02 17:42:15 
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version 
17:42:15 172.16.255.255 GET /default.htm 200 HTTP/1.0

Vollständige Protokollierung und Einblicke – kostenlos

Falcon LogScale Community Edition (ehemals Humio) ist eine kostenlose moderne Log-Management-Plattform für die Cloud. Durch die Erfassung von Streaming-Daten erhalten Sie einen sofortigen Überblick über verteilte Systeme und können Zwischenfälle verhindern bzw. beheben.

Falcon LogScale Community Edition ist sofort kostenlos verfügbar und bietet folgende Vorteile:

• Erfassung von bis zu 16 GB pro Tag
• Speicherung bis zu 7 Tage
• Keine Kreditkarte erforderlich
• Unbegrenzter Zugriff ohne Testzeitraum
• Indexlose Protokollierung, Echtzeit-Warnungen und Live-Dashboards
• Zugriff auf unseren Marktplatz und zugehörige Pakete, einschließlich Leitfäden zur Entwicklung neuer Pakete
• Lernen und Kooperation in einer aktiven Gemeinschaft

Kostenlos testen