Freigeben über


Bewährte Methode zum Konfigurieren der EventLog-Weiterleitung in Windows Server 2012 R2

In diesem Artikel wird die bewährte Methode zum Konfigurieren der EventLog-Weiterleitung in einer großen Umgebung in Windows Server 2012 R2 vorgestellt.

Ursprüngliche KB-Nummer: 4494356

Übersicht

Es gibt wichtige Skalierbarkeitskorrekturen, die für Windows Server 2016, Windows Server 2019 im kumulativen Update vom 25. Februar 2020 eingeführt wurden.

Siehe "Verbessert die Skalierbarkeit der Ereignisweiterleitung, um die Threadsicherheit zu gewährleisten und Ressourcen zu erhöhen.", aufzählung in den folgenden beiden Artikeln:

Ereignislatenz

Sobald Ereignisse auf dem Client generiert werden, dauert der Ereignisweiterleitungsmechanismus einige Zeit, um sie an den Sammler weiterzuleiten.

Diese Verzögerung kann durch die Abonnementkonfiguration verursacht werden, z. B. den DeliveryMaxLatency-Parameter , die Leistung des Sammelsammlers, die Weiterleitung oder das Netzwerk.

Notiz

Stellen Sie sicher, dass die Ereignisse nicht auf dem Client überschrieben werden, bevor sie weitergeleitet werden. Dieses Problem muss in der Regel nur verwaltet werden, wenn die Clients eine große Anzahl von Ereignissen generieren, z. B. einen ausgelasteten Server oder das DC-Weiterleitungsprotokoll.

Einschränkung und Systemanforderung

Sie stellen die EventLog Forwarding in einer großen Umgebung bereit. Sie stellen beispielsweise 40.000 bis 100.000 Quellcomputer bereit. In diesem Fall wird empfohlen, mehr als einen Collector mit 2.000 bis maximal 4.000 Clients pro Sammler bereitzustellen.

Darüber hinaus wird empfohlen, mindestens 16 GB RAM und vier (4) Prozessoren auf dem Sammler zu installieren, um eine durchschnittliche Auslastung von 2.000 bis 4.000 Clients zu unterstützen, die ein oder zwei Abonnements konfiguriert haben.

Schnelle Datenträger werden empfohlen, und das ForwardedEvents-Protokoll kann auf einem anderen Datenträger platziert werden, um eine bessere Leistung zu erzielen.

Die Speicherauslastung des Windows-Ereignissammlerdiensts hängt von der Anzahl der Verbindungen ab, die vom Client empfangen werden. Die Anzahl der Verbindungen hängt von den folgenden Faktoren ab:

  • Die Häufigkeit der Verbindungen
  • Die Anzahl der Abonnements
  • Die Anzahl der Clients
  • Das Betriebssystem der Clients

For example, for the default values of 4.000 clients and five to seven subscriptions, the memory that is used by the Windows Event Collector service may quickly exceed 4 GB and continue to grow. Dies kann dazu führen, dass der Computer nicht reagiert.

Häufigkeit der Clientverbindungen

Drei Parameter steuern die Häufigkeit der Clientverbindungen:

  • Refresh= (angegeben in der Konfigurations-URL des Gruppenrichtlinienobjekts)
  • DeliveryMaxLatency (im Abonnement angegeben)
  • HeartbeatInterval (im Abonnement angegeben)

Der Refresh=-Parameter im Gruppenrichtlinienobjekt

Dieser Parameter wird in Sekunden gemessen. Er steuert, wie häufig der Client eine Verbindung mit der /WEC-URL herstellt, um die verfügbaren Abonnements auflisten zu können.

Der Sammler antwortet, indem eine Liste der Abonnements bereitgestellt wird, die für den Client aktiviert sind. Die Antwort enthält die Lesezeichen für jeden Kanal und die Xpath-Abfrage. Sobald der Client die Informationen empfängt, beginnt er mit dem Senden der Ereignisse oder der Taktpakete an die /Subscriptions-URL. Wenn sich die Abonnements nicht häufig ändern, kann dieser Parameter so konfiguriert werden, dass er alle paar Stunden oder sogar weniger häufig überprüft wird.

DeliveryMaxLatency

Steuert die Häufigkeit der Clientverbindungen. Für eine große Bereitstellung können Sie ein Abonnement für dringende Ereignisse erstellen, die auf eine 5-Minuten-Häufigkeit festgelegt sind, und ein weiteres für weniger dringende Ereignisse, die auf eine 2-Stunden-Häufigkeit festgelegt sind.

HeartbeatInterval

Steuert den Inaktiven Status im Laufzeitstatusfenster der Konsole. Kann auf denselben Wert wie DeliveryMaxLatency oder einen größeren Wert festgelegt werden, um Kunden zusätzliche Zeit zu geben, bevor sie als inaktiv markiert werden.

Benutzerdefinierte Parameter

Um benutzerdefinierte Parameter zu konfigurieren, müssen Sie die Befehlszeile verwenden, um Wecutil auszuführen. Weitere Informationen finden Sie unter Wecutil.exe.

  • Sie können das konfigurierte Abonnement als wecutil es.

  • Sie müssen zuerst das Abonnement auf "Benutzerdefiniert" wechseln:

    wecutil ss <SubscriptionName> /cm:"Custom"
    
  • Legen Sie dann den DeliveryMaxLatency-Parameter fest:

    wecutil ss <SubscriptionName> /dmlt:7200000
    

    (Der Wert ist in Millisekunden angegeben: 7200000 = 2 Stunden)

  • Passen Sie HeartbeatInterval auf denselben Wert an. Diese Einstellung wirkt sich auf den Status "Inaktiv" für jeden Client in der Konsole aus:

    wecutil ss <SubscriptionName> /hi:7200000
    

Übermittlungsoptimierung für Abonnements

Die Clients senden die Ereignisse an die URL "/subscriptions". Diese Verbindungen sind für die Speicherauslastung von Sammlern sehr wichtig.

Die folgenden vorkonfigurierten Modi sind verfügbar.

  • Normal

    • Bietet eine zuverlässige Bereitstellung von Ereignissen und versucht nicht, Bandbreite zu sparen.
    • Die geeignete Wahl, es sei denn, Sie benötigen eine engere Kontrolle über die Bandbreitennutzung oder erfordern, dass weitergeleitete Ereignisse so schnell wie möglich übermittelt werden.
    • Verwendet den Pull-Übermittlungsmodus, stapelt fünf Elemente gleichzeitig und legt einen Batchtimeout von 15 Minuten fest.
  • Minimieren der Bandbreite

    • Stellt sicher, dass die Verwendung der Netzwerkbandbreite für die Ereignisübermittlung streng kontrolliert wird.
    • Die richtige Wahl, wenn Sie die Häufigkeit von Netzwerkverbindungen einschränken möchten, um Ereignisse zu liefern.
    • Verwendet den Pushübermittlungsmodus und legt einen Batchtimeout von 6 Stunden und ein Taktintervall von 6 Stunden fest.
  • Minimieren der Latenz

    • Stellt sicher, dass Ereignisse mit minimaler Verzögerung übermittelt werden.
    • Die richtige Wahl, wenn Sie Warnungen oder kritische Ereignisse sammeln.
    • Verwendet den Pushübermittlungsmodus und legt einen Batchtimeout von 30 Sekunden fest.

Der Client stellt eine Verbindung mit dem Sammler mit der angegebenen Häufigkeit zum Senden der Ereignisse oder zum Senden eines Takts hergestellt. Die Standardeinstellungen "Normal" können zu einer hohen Speicherauslastung führen, indem 2.000 bis 4.000 Clients pro Sammler vorhanden sind.

Konfigurieren des Sammelnamens

Sie können den Sammelnamen auf dem Client konfigurieren, indem Sie das folgende Gruppenrichtlinienobjekt (Group Policy Object, GPO) konfigurieren:
Computerkonfiguration/Administative Vorlagen/Windows-Komponenten/ Ereignisweiterleitung/ Zielabonnement-Manager konfigurieren

Alternativ können Sie Registrierungseinstellungen im folgenden Unterschlüssel vornehmen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager

Die GPOs, die den Sammler jedem Client zuweisen, können mithilfe der Sicherheitseinstellung für das Gruppenrichtlinienobjekt selbst oder mit einem WMI-Filter gefiltert werden. Wenn der Computername beispielsweise immer in einer Zahl endet (z. B. Computer1, Computer2 usw.), können wir GPOs erstellen, um die Clients auf 10 verschiedene Kollektoren zu verweisen.

Konsolidierung der Abonnements

Durch das Konfigurieren mehrerer Abonnements wird die Anzahl der Verbindungen erhöht. Die überlegungen, die weiter oben in diesem Artikel erläutert werden, gelten für jedes Abonnement.

Es wird empfohlen, das Abonnement zu konfigurieren, indem Sie die Xpath-Abfrage bearbeiten und mehrere Abfragen in dasselbe Abonnement einfügen.