Protokolle mit Logstash und der DCR-basierten API an Microsoft Sentinel streamen

das Logstash-Ausgabe-Plug-In von Microsoft Sentinel unterstützt Pipelinetransformationen und erweiterte Konfigurationen über Datensammlungsregeln (Data Collection Rules, DCRs). Das Plug-In leitet Protokolle aus externen Datenquellen an benutzerdefinierte oder Standardtabellen in Log Analytics oder Microsoft Sentinel weiter.

In diesem Artikel erfahren Sie, wie Sie das Logstash-Plug-In einrichten, um Daten mithilfe von DCRs in Log Analytics oder Microsoft Sentinel mit vollständiger Kontrolle über das Ausgabeschema zu streamen.

Mit dem Plug-In haben Sie folgende Möglichkeiten:

• Steuern Sie die Konfiguration der Spaltennamen und -typen.
• Führen Sie Erfassungszeittransformationen wie Filtern oder Anreicherung durch.
• Erfassen Sie benutzerdefinierte Protokolle in einer benutzerdefinierten Tabelle, oder erfassen Sie einen Syslog-Eingabedatenstrom in der Log Analytics-Syslog-Tabelle.

Die Erfassung in Standardtabellen ist nur auf Standardtabellen beschränkt, die für die erfassung benutzerdefinierter Protokolle unterstützt werden.

Weitere Informationen zum Arbeiten mit der Logstash-Datensammlungs-Engine finden Sie unter Erste Schritte mit Logstash.

Architekturübersicht

Die Logstash-Engine besteht aus drei Komponenten:

• Eingabe-Plug-Ins: Angepasste Sammlung von Daten aus verschiedenen Quellen.
• Filter-Plug-Ins: Manipulation und Normalisierung von Daten nach angegebenen Kriterien.
• Ausgabe-Plug-Ins: Angepasstes Senden von gesammelten und verarbeiteten Daten an verschiedene Ziele.

Das Plug-In sendet JSON-formatierte Daten mithilfe der Protokollerfassungs-API an Ihren Log Analytics-Arbeitsbereich. Die Daten werden in benutzerdefinierten Protokollen oder einer Standardtabelle erfasst.

• Erfahren Sie mehr über die Protokollerfassungs-API.

Stellen Sie das Microsoft Sentinel-Output-Plugin in Logstash bereit

Führen Sie die folgenden Schritte aus, um das Plug-In einzurichten:

• Überprüfen Sie die Voraussetzungen für das Logstash-Plugin
• Installieren des Plug-Ins
• Erstellen einer Beispieldatei
• Erstellen der erforderlichen DCR-bezogenen Ressourcen
• Konfigurieren der Logstash-Konfigurationsdatei
• Logstash neu starten
• Zeigen Sie eingehende Protokolle in Microsoft Sentinel an
• Überwachungsprotokolle des Ausgabe-Plug-Ins überwachen

Voraussetzungen für das Logstash-Plug-In

• Installieren Sie eine unterstützte Version von Logstash. Das Plug-In unterstützt die folgenden Logstash-Versionen:

  • 7.0 bis 7.17.13

  • 8.0 - 8.9 (diese Versionen erfordern laut Logstash ein Sicherheitsupdate)

  • 8.11 - 8.15 (diese Versionen erfordern laut Logstash ein Sicherheitsupdate)

  • 8.19.2 (diese Version erfordert laut Logstash ein Sicherheitsupdate)

  • 9.0.8 (diese Version erfordert laut Logstash ein Sicherheitsupdate)

  • 9.1.10 (diese Version erfordert laut Logstash ein Sicherheitsupdate)

  • 9.2.4 - 9.2.5 (diese Versionen erfordern laut Logstash ein Sicherheitsupdate)

  • 9.3.3

  • 9.4.0

    Hinweis

    Wenn Sie Logstash 8 verwenden, wird empfohlen, ECS in der Pipeline zu deaktivieren.

• Vergewissern Sie sich, dass Sie über einen Log Analytics-Arbeitsbereich mit mindestens Mitwirkender Rechten verfügen.

• Vergewissern Sie sich, dass Sie über Berechtigungen zum Erstellen von DCR-Objekten im Arbeitsbereich verfügen.

Installieren des Plug-Ins

Das Microsoft Sentinel Ausgabe-Plug-In ist in der Logstash-Sammlung auf RubyGems verfügbar.

• Befolgen Sie die Anweisungen im Logstash-Dokument Arbeiten mit Plug-ins, um das Plug-in microsoft-sentinel-log-analytics-logstash-output-plugin zu installieren. Führen Sie zum Installieren in einer vorhandenen Logstash-Installation den folgenden Befehl aus:

  logstash-plugin install microsoft-sentinel-log-analytics-logstash-output-plugin
  

• Wenn Ihr Logstash-System keinen Internetzugriff hat, befolgen Sie die Anweisungen im Dokument Logstash Offline Plug-In-Verwaltung , um ein Offline-Plug-In-Paket vorzubereiten und zu verwenden. (Dazu muss ein weiteres Logstash-System mit Internetzugriff erstellt werden.)

Erstellen einer Beispieldatei

In diesem Abschnitt erstellen Sie eine Beispieldatei in einem der folgenden Szenarien:

• Erstellen Sie eine Beispieldatei für benutzerdefinierte Protokolle
• Erstellen einer Beispieldatei zum Erfassen von Protokollen in der Syslog-Tabelle

Erstellen Sie eine Beispieldatei für benutzerdefinierte Protokolle

In diesem Szenario konfigurieren Sie das Logstash-Eingabe-Plug-In so, dass Ereignisse an Microsoft Sentinel gesendet werden. In diesem Beispiel wird das Generatoreingabe-Plug-In verwendet, um Ereignisse zu simulieren. Sie können jedes andere Eingabe-Plug-In verwenden.

In diesem Beispiel sieht die Logstash-Konfigurationsdatei wie folgt aus:

input {
      generator {
            lines => [
                 "This is a test log message"
            ]
           count => 10
      }
}

Führen Sie die folgenden Schritte aus, um die Beispieldatei zu erstellen:

1. Kopieren Sie die folgende Ausgabe-Plug-In-Konfiguration in Ihre Logstash-Konfigurationsdatei.

   output {
       microsoft-sentinel-log-analytics-logstash-output-plugin {
         create_sample_file => true
         sample_file_path => "<enter the path to the file in which the sample data will be written>" #for example: "c:\\temp" (for windows) or "/tmp" for Linux. 
       }
   }
   

2. Stellen Sie sicher, dass der Dateipfad, auf den verwiesen wird, bereits vorhanden ist, und starten Sie dann Logstash.

   Das Plugin schreibt zehn Datensätze in eine Sample-Datei namens sampleFile<epoch seconds>.json unter dem konfigurierten Pfad, sobald 10 zu samplende Ereignisse vorliegen oder wenn der Logstash-Prozess ordnungsgemäß beendet wird. Beispiel: c:\temp\sampleFile1648453501.json. Hier sehen Sie einen Teil einer Beispieldatei, die das Plug-In erstellt:

   [
           {
               "host": "logstashMachine",
               "sequence": 0,
               "message": "This is a test log message",
               "ls_timestamp": "2022-03-28T17:45:01.690Z",
               "ls_version": "1"
           },
           {
               "host": "logstashMachine",
               "sequence": 1
       ...
   
       ]    
   

   Das Plug-In fügt automatisch diese Eigenschaften zu jedem Datensatz hinzu:

   • ls_timestamp: Der Zeitpunkt, zu dem der Datensatz vom Eingabe-Plug-In empfangen wird
   • ls_version: Die Logstash-Pipeline-Version.

   Sie können diese Felder entfernen, wenn Sie den DCR erstellen.

Erstellen einer Beispieldatei zum Erfassen von Protokollen in der Syslog-Tabelle

In diesem Szenario konfigurieren Sie das Logstash-Eingabe-Plug-In so, dass Syslog-Ereignisse an Microsoft Sentinel gesendet werden.

1. Wenn Sie noch keine Syslog-Nachrichten an Ihren Logstash-Computer weitergeleitet haben, können Sie den Protokollierungsbefehl verwenden, um Nachrichten zu generieren. Beispiel (für Linux):

   logger -p local4.warn --rfc3164 --tcp -t CEF "0|Microsoft|Device|cef-test|example|data|1|here is some more data for the example" -P 514 -d -n 127.0.0.1
   

   Hier ist ein Beispiel für das Logstash-Eingabe-Plug-In:

   input {
        syslog {
            port => 514
       }
   }
   

2. Kopieren Sie die folgende Ausgabe-Plug-In-Konfiguration in Ihre Logstash-Konfigurationsdatei.

   output {
       microsoft-sentinel-log-analytics-logstash-output-plugin {
         create_sample_file => true
         sample_file_path => "<enter the path to the file in which the sample data will be written>" #for example: "c:\\temp" (for windows) or "/tmp" for Linux. 
       }
   }
   

3. Stellen Sie sicher, dass der Dateipfad bereits vorhanden ist, und starten Sie dann Logstash.

   Das Plugin schreibt zehn Datensätze in eine Sample-Datei namens sampleFile<epoch seconds>.json unter dem konfigurierten Pfad, sobald 10 zu samplende Ereignisse vorliegen oder wenn der Logstash-Prozess ordnungsgemäß beendet wird. Beispiel: c:\temp\sampleFile1648453501.json. Hier sehen Sie einen Teil einer Beispieldatei, die das Plug-In erstellt:

   [
           {
               "logsource": "logstashMachine",
               "facility": 20,
               "severity_label": "Warning",
               "severity": 4,
               "timestamp": "Apr  7 08:26:04",
               "program": "CEF:",
               "host": "127.0.0.1",
               "facility_label": "local4",
               "priority": 164,
               "message": "0|Microsoft|Device|cef-test|example|data|1|here is some more data for the example",
               "ls_timestamp": "2022-04-07T08:26:04.000Z",
               "ls_version": "1"
           }
   ]    
   
   

   Das Plug-In fügt automatisch diese Eigenschaften zu jedem Datensatz hinzu:

   • ls_timestamp: Der Zeitpunkt, zu dem der Datensatz vom Eingabe-Plug-In empfangen wird
   • ls_version: Die Logstash-Pipeline-Version.

   Sie können diese Felder entfernen, wenn Sie den DCR erstellen.

Erstellen der erforderlichen DCR-Ressourcen

Um das Microsoft Sentinel DCR-basiertes Logstash-Plug-In zu konfigurieren, erstellen Sie zuerst die DCR-bezogenen Ressourcen.

In diesem Abschnitt erstellen Sie Ressourcen, die für Ihre DCR in einem der folgenden Szenarien verwendet werden sollen:

• DCR-Ressourcen zur Aufnahme in eine benutzerdefinierte Tabelle erstellen
• Erstellen Sie DCR-Ressourcen zur Erfassung in einer Standardtabelle

DCR-Ressourcen zur Aufnahme in eine benutzerdefinierte Tabelle erstellen

Um die Daten in eine benutzerdefinierte Tabelle aufzunehmen, gehen Sie wie folgt vor (basierend auf dem Tutorial zum Senden von Daten an Azure Monitor-Protokolle mithilfe der REST-API (Azure-Portal)):

1. Überprüfen Sie die Voraussetzungen.

2. Konfigurieren Sie die Anwendung.

3. Fügen Sie eine benutzerdefinierte Protokolltabelle hinzu.

4. Analysieren und filtern Sie Beispieldaten mithilfe der Beispieldatei, die Sie im vorherigen Abschnitt erstellt haben.

5. Sammeln Sie Informationen aus dem DCR.

6. Weisen Sie dem DCR Berechtigungen zu.

   Überspringen Sie den Schritt Beispieldaten senden.

Wenn Sie auf Probleme stoßen, sehen Sie sich die Schritte zur Fehlerbehebung der Logs Ingestion API an.

Erstellen Sie DCR-Ressourcen zur Erfassung in einer Standardtabelle

Um die Daten in eine Standardtabelle wie Syslog oder CommonSecurityLog zu erfassen, verwenden Sie einen Prozess, der auf dem Tutorial „Senden von Daten an Azure Monitor-Protokolle mithilfe der REST-API (Resource Manager-Vorlagen)“ basiert. In diesem Tutorial wird zwar erläutert, wie Daten in einer benutzerdefinierten Tabelle erfasst werden, Sie können den Prozess jedoch problemlos anpassen, um Daten in einer Standardtabelle zu erfassen. Die folgenden Schritte zeigen relevante Änderungen in den Schritten an.

1. Überprüfen Sie die Voraussetzungen.

2. Details zum Arbeitsbereich erfassen.

3. Konfigurieren sie eine Anwendung.

   Überspringen Sie den Schritt Neue Tabelle im Log Analytics-Arbeitsbereich erstellen. Dieser Schritt ist beim Erfassen von Daten in einer Standardtabelle nicht relevant, da die Tabelle bereits in Log Analytics definiert ist.

4. Erstellen Sie den DCR. In diesem Schritt:

   • Gib die von dir erstellte Beispieldatei in Create a Sample File bereit.
   • Verwenden Sie die von Ihnen erstellte Beispieldatei, um die streamDeclarations -Eigenschaft zu definieren. Jedes der Felder in der Beispieldatei sollte über eine entsprechende Spalte mit demselben Namen und dem entsprechenden Typ verfügen (siehe beispiel unten).
   • Konfigurieren Sie den Wert der outputStream Eigenschaft mit dem Namen der Standardtabelle anstelle der benutzerdefinierten Tabelle. Im Gegensatz zu benutzerdefinierten Tabellen haben Standardtabellennamen nicht das _CL Suffix.
   • Das Präfix des Tabellennamens sollte Microsoft- anstelle von Custom- sein. In diesem Beispiel ist der Wert der Eigenschaft outputStreamMicrosoft-Syslog.

5. Weisen Sie einem DCR Berechtigungen zu.

   Überspringen Sie den Schritt Beispieldaten senden.

Wenn Sie auf Probleme stoßen, sehen Sie sich die Schritte zur Fehlerbehebung der Logs Ingestion API an.

Beispiel: DCR, die Daten in die Syslog-Tabelle aufnimmt

Beachten Sie diese Punkte:

• Die streamDeclarations Spaltennamen und -typen sollten mit den Beispieldateifeldern identisch sein, aber Sie müssen nicht alle angeben. Im folgenden DCR werden beispielsweise die PRIFelder , type und ls_version in der streamDeclarations Spalte weggelassen.
• Die dataflows-Eigenschaft wandelt die Eingabe in das Syslog-Tabellenformat um und setzt outputStream auf Microsoft-Syslog.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "dataCollectionRuleName": {
      "type": "String",
      "metadata": {
        "description": "Specifies the name of the Data Collection Rule to create."
      }
    },
    "location": {
      "defaultValue": "[resourceGroup().location]",
      "type": "String",
      "metadata": {
        "description": "Specifies the location in which to create the Data Collection Rule."
      }
    },
    "workspaceResourceId": {
      "type": "String",
      "metadata": {
        "description": "Specifies the Azure resource ID of the Log Analytics workspace to use."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.Insights/dataCollectionRules",
      "apiVersion": "2021-09-01-preview",
      "name": "[parameters('dataCollectionRuleName')]",
      "location": "[parameters('location')]",
      "properties": {
        "streamDeclarations": {
          "Custom-SyslogStream": {
            "columns": [
              { "name": "ls_timestamp", "type": "datetime" },
              { "name": "timestamp", "type": "datetime" },
              { "name": "message", "type": "string" },
              { "name": "facility_label", "type": "string" },
              { "name": "severity_label", "type": "string" },
              { "name": "host", "type": "string" },
              { "name": "logsource", "type": "string" }
            ]
          }
        },
        "destinations": {
          "logAnalytics": [
            {
              "workspaceResourceId": "[parameters('workspaceResourceId')]",
              "name": "clv2ws1"
            }
          ]
        },
        "dataFlows": [
          {
            "streams": ["Custom-SyslogStream"],
            "destinations": ["clv2ws1"],
            "transformKql": "source | project TimeGenerated = ls_timestamp, EventTime = todatetime(timestamp), Computer = logsource, HostName = logsource, HostIP = host, SyslogMessage = message, Facility = facility_label, SeverityLevel = severity_label",
            "outputStream": "Microsoft-Syslog"
          }
        ]
      }
    }
  ],
  "outputs": {
    "dataCollectionRuleId": {
      "type": "String",
      "value": "[resourceId('Microsoft.Insights/dataCollectionRules', parameters('dataCollectionRuleName'))]"
    }
  }
}

Konfigurieren der Logstash-Konfigurationsdatei

Das Plug-In unterstützt zwei Authentifizierungsmethoden: Dienstprinzipal (Clientanmeldeinformationen) und verwaltete Identität (kennwortlos). Wählen Sie die Methode aus, die zu Ihrer Umgebung passt.

Dienstprinzipalauthentifizierung

Um die Logstash-Konfigurationsdatei so zu konfigurieren, dass sie die Logs mittels Service Principal-Authentifizierung in eine benutzerdefinierte Tabelle einführt, rufen Sie folgende Werte client_idab: , client_secret, , tenant_iddata_collection_endpoint, dcr_id, und stream_name.

Nachdem Sie die erforderlichen Werte abgerufen haben:

1. Ersetzen Sie den Ausgabeabschnitt der Logstash-Konfigurationsdatei, die Sie im vorherigen Schritt erstellt haben, durch das folgende Beispiel.
2. Ersetzen Sie die Platzhalterzeichenfolgen im folgenden Beispiel durch die werte, die Sie abgerufen haben.
3. Stellen Sie sicher, dass Sie das create_sample_file Attribut in falseändern.

Beispiel: Konfiguration des Dienstprinzipal-Ausgabe-Plug-Ins

output {
    microsoft-sentinel-log-analytics-logstash-output-plugin {
      client_id => "<enter your client_id value here>"
      client_secret => "<enter your client_secret value here>"
      tenant_id => "<enter your tenant id here>"
      data_collection_endpoint => "<enter your logsIngestion URI here>"
      dcr_id => "<enter your DCR immutableId here>"
      stream_name => "<enter your stream name here>"
      create_sample_file=> false
      sample_file_path => "c:\\temp"
    }
}

Authentifizierung mit verwalteter Identität (kennwortlos)

Wenn du keine Service-Principal-Zugangsdaten (client_id, client_secret und tenant_id) angibst, authentifiziert sich das Plugin mit DefaultAzureCredential aus dem Azure SDK. DefaultAzureCredential versucht eine Abfolge von Authentifizierungsmethoden und verwendet die erste, die erfolgreich ist. In einer Serverumgebung werden die relevanten Methoden in folgender Reihenfolge versucht:

1. Umgebungsvariablen: Liest Zugangsdaten von Umgebungsvariablen wie AZURE_CLIENT_ID, AZURE_TENANT_ID, und AZURE_CLIENT_SECRET zur Authentifizierung als Service Principal.
2. Workload-Identität: Wenn das Plugin auf einem Azure-Host mit aktivierter Workload-Identität läuft (zum Beispiel AKS mit gesetzter UmgebungsvariableAZURE_FEDERATED_TOKEN_FILE), führt das Plugin einen OIDC-Tokenaustausch durch.
3. Verwaltete Identität: Wenn der Host eine verwaltete Identität aktiviert hat, authentifiziert sich das Plugin mit der Nutzung dieser Identität. Diese Methode umfasst Azure-VMs, Virtual Machine Scale Sets und Azure Arc-fähige Server.

Die vollständige Sequenz der Anmeldeinformationen, die DefaultAzureCredential ausprobiert, finden Sie unter Anmeldeinformationsketten in der Azure-Identitätsbibliothek für Java.

Erforderliche Konfiguration für die verwaltete Identität:

Beispiel: Verwaltete Identität

output {
    microsoft-sentinel-log-analytics-logstash-output-plugin {
      data_collection_endpoint => "<enter your DCE logsIngestion URI here>"
      dcr_id => "<enter your DCR immutableId here>"
      stream_name => "<enter your stream name here>"
    }
}

Optionale Konfiguration

Logstash neu starten

Starten Sie Logstash mit der aktualisierten Ausgabe-Plug-In-Konfiguration neu. Vergewissern Sie sich, dass Daten gemäß Ihrer DCR-Konfiguration in der richtigen Tabelle erfasst werden.

Zeigen Sie eingehende Protokolle in Microsoft Sentinel an

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob Protokolldaten Ihren Arbeitsbereich erreichen:

1. Vergewissern Sie sich, dass Nachrichten an das Ausgabe-Plug-In gesendet werden.

2. Wählen Sie im Microsoft Sentinel Navigationsmenü Protokolle aus. Erweitern Sie unter der Überschrift Tabellen die Kategorie Benutzerdefinierte Protokolle . Suchen Sie in der Konfiguration nach der Tabelle, die Sie mit dem Suffix _CL angegeben haben, und wählen Sie sie aus.

   

3. Um Datensätze in der Tabelle anzuzeigen, fragen Sie die Tabelle ab, indem Sie den Tabellennamen als Schema verwenden.

   

Überwachungsprotokolle des Ausgabe-Plug-Ins überwachen

Um die Konnektivität und Aktivität des Microsoft Sentinel Ausgabe-Plug-Ins zu überwachen, aktivieren Sie die entsprechende Logstash-Protokolldatei. Informationen zum Speicherort der Protokolldatei finden Sie im Dokument Logstash-Verzeichnislayout .

Wenn in dieser Protokolldatei keine Daten angezeigt werden, generieren und senden Sie einige Ereignisse lokal über die Eingabe- und Filter-Plug-Ins, um sicherzustellen, dass das Ausgabe-Plug-In Daten empfängt. Microsoft Sentinel unterstützt nur Probleme im Zusammenhang mit dem Ausgabe-Plug-In.

Netzwerksicherheit

Definieren Sie Netzwerkeinstellungen, und aktivieren Sie die Netzwerkisolation für das Microsoft Sentinel Logstash-Ausgabe-Plug-In.

Diensttags für virtuelle Netzwerke

Microsoft Sentinel Ausgabe-Plug-In unterstützt Azure VNET-Diensttags. Die Tags AzureMonitor und AzureActiveDirectory sind erforderlich.

Azure Virtual Network Diensttags können verwendet werden, um Netzwerkzugriffssteuerungen für Netzwerksicherheitsgruppen, Azure Firewall und benutzerdefinierte Routen zu definieren. Verwenden Sie Diensttags anstelle bestimmter IP-Adressen, wenn Sie Sicherheitsregeln und Routen erstellen. Für Szenarien, in denen Azure Virtual Network Diensttags nicht verwendet werden können, werden die Firewallanforderungen unten angegeben.

Firewallanforderungen

In der folgenden Tabelle sind die Firewallanforderungen für Szenarien aufgeführt, in denen Azure VNET-Diensttags nicht verwendet werden können.

Plug-In-Versionsverlauf

2.5.0

• Es wurde eine optionale Proxy-Konfiguration pro Plugin für Authentifizierungs- und Ingestionsdatenverkehr unter Verwendung von proxy, proxy_aad und proxy_endpoint hinzugefügt.
• Netty-Handler, HTTP-, HTTP/2- und DNS-Komponenten wurden von 4.1.133.Final auf 4.1.136.Final aktualisiert.
• Jackson Databind und Jackson Core wurden von 2.18.6 auf 2.18.8 aktualisiert.

2.4.0

• Worker-Threads werden nun als begrenzte, vom Executor geplante Durchläufe ausgeführt: Behebbare Ausnahmen werden protokolliert, und der Worker setzt den Vorgang im nächsten Zyklus fort; schwerwiegende JVM-Fehler werden protokolliert und erneut ausgelöst.
• Das ordnungsgemäße Herunterfahren wurde behoben, sodass laufende Batches (zuerst Batcher, dann Unifier, dann Sender) entleert werden, bevor die Worker angehalten werden, begrenzt auf max_graceful_shutdown_time_seconds.
• Konfigurierbare Upload-Timeouts connect_timeout_seconds (Standard 15) und write_timeout_seconds (Standard 60) hinzugefügt; Verbindungs- und Schreibtimeouts werden erneut versucht.
• Thread-ID, Ausnahmetyp, Batch-Größe und DCR-Stream wurden zu den Batch-Fehlerprotokollen hinzugefügt.

2.3.3

• Behebung des Verlusts numerischer und boolescher Typtreue: Felder, die auf Logstashs internen JRuby-Typen basieren (zum Beispiel Ports und Byte-Anzahlen), werden nun als native JSON-Zahlen und boolesche Werte beibehalten, anstatt in Zeichenfolgen umgewandelt zu werden, wodurch eine zuverlässige Erfassung in DCRs mit typisierten Spalten sichergestellt wird.

2.3.2

• Behebung des stillen Abbruchs von Worker-Threads, der durch nicht abgefangene Ausnahmen in der Verarbeitungsschleife des Workers verursacht wurde.
• Behebung einer NullPointerException im SenderWorker, wenn Azure eine LogsUploadException mit einer null-HTTP-Antwort zurückgibt.
• Es wurde eine resiliente Fehlerbehandlung mit aufeinanderfolgender Fehlerverfolgung hinzugefügt, um dauerhafte Arbeitsfehler zu reduzieren.
• Optionaler id Konfigurationswert für Telemetrie hinzugefügt.
• DCR-Stream wurde zur Sent-Batches-Protokollierung hinzugefügt.

2.3.0

• Funktionalität mit Logstash 9.4 aktiviert.
• Aktualisierung der Abhängigkeiten externer Bibliotheken (azure-sdk-bom, logback, slf4j, Netty).

2.2.1

• Fügt eine Logzeile auf Info-Ebene hinzu, wenn Stapel erfolgreich gesendet werden.

2.2.0

• Fügt die Möglichkeit hinzu, entweder neue oder alte Konfigurationswerte zu verwenden.

2.1.2

• Dokumentationsaktualisierungen.

2.1.0

• Ereignisnormalisierung korrigiert.

2.0.0

• Das Plug-In wurde von Ruby zu Java umgestaltet.
• ManagedIdentity-Authentifizierung hinzugefügt.
• Codebasis von GitHub in Azure DevOps verschoben.
• Geschlossene Codebasis.

1.2.0

• Fügt Authentifizierungsunterstützung für verwaltete Identitäten für Azure VMs/VMSS (systemseitig und benutzerseitig über IMDS) hinzu.
• Fügt Unterstützung für AKS-Workloadidentitäten mittels OIDC-Tokenaustausch hinzu.
• Fügt Azure Unterstützung für verwaltete Arc-Identitäten für Hybridserver und lokale Server hinzu.
• Erkennt die Authentifizierungsmethode zur Laufzeit basierend auf der Umgebung automatisch (Umgebungsvariablen für Workloadidentität, Arc-Agent oder IMDS-Fallback).
• Migriert den HTTP-Client von excon auf rest-client, um die Kompatibilität mit dem JRuby- und Logstash-Plugin-Ökosystem zu verbessern.
• Benennt Azure Active Directory-Verweise in Microsoft Entra ID um.

1.1.4

• Beschränkt excon die Bibliotheksversion auf niedriger als 1.0.0, um sicherzustellen, dass der Port immer verwendet wird, wenn ein Proxy verwendet wird.

1.1.3

• Ersetzt die Bibliothek, die zum Herstellen einer rest-client Verbindung mit Azure verwendet wird, durch die excon Bibliothek.

1.1.1

• Fügt Unterstützung für Azure Cloud der US-Regierung und microsoft Azure hinzu, die von 21Vianet in China betrieben werden.

1.1.0

• Ermöglicht das Festlegen verschiedener Proxywerte für API-Verbindungen.
• Aktualisiert die Version für die Protokollerfassungs-API auf 2023-01-01.
• Benennt das Plug-In in microsoft-sentinel-log-analytics-logstash-output-plugin um.

1.0.0

• Die erste Version für das Logstash-Ausgabe-Plug-In für Microsoft Sentinel. Dieses Plug-In verwendet Datensammlungsregeln (Data Collection Rules, DCRs) mit der Protokollerfassungs-API von Azure Monitor.

Bekannte Probleme

Bei Verwendung von Logstash, das auf einem Docker-Image von Lite Ubuntu installiert ist, wird möglicherweise die folgende Warnung angezeigt:

java.lang.RuntimeException: getprotobyname_r failed

Installieren Sie das netbase-Paket in Ihrer Dockerfile-Datei, um diesen Fehler zu beheben:

USER root
RUN apt install netbase -y

Weitere Informationen finden Sie unter JNR-Regression in Logstash 7.17.0 (Docker).

Wenn die Ereignisrate in Ihrer Umgebung niedrig ist, erhöhen Sie den Wert von max_waiting_time_for_batch_seconds und max_waiting_for_unifier_time_seconds auf 60 oder mehr. Sie können die Erfassungsnutzlast mithilfe von DCR-Metriken überwachen. Weitere Informationen zu den Wartezeitvariablen finden Sie in der optionalen Konfigurationstabelle .

Begrenzungen

• Die Erfassung in Standardtabellen ist nur auf Standardtabellen beschränkt, die für die erfassung benutzerdefinierter Protokolle unterstützt werden.

• Die Spalten des Eingabestreams in der streamDeclarations -Eigenschaft müssen mit einem Buchstaben beginnen. Wenn Sie eine Spalte mit anderen Zeichen (z. B @ . oder _) starten, schlägt der Vorgang fehl.

• Das TimeGenerated datetime-Feld ist erforderlich. Sie müssen dieses Feld in die KQL-Transformation einschließen.

• Für weitere mögliche Probleme lesen Sie bitte die Schritte zur Fehlerbehebung der Logs Ingestion API.