Bonne pratique pour configurer le transfert EventLog dans Windows Server 2012 R2

Cet article présente la meilleure pratique pour configurer le transfert EventLog dans un environnement volumineux dans Windows Server 2012 R2.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 4494356

Résumé

Des correctifs de scalabilité importants ont été déployés sur Windows Server 2016, Windows Server 2019 dans les mises à jour cumulatives du 25 février 2020.

Consultez « Améliore la scalabilité du transfert d’événements pour garantir la sécurité des threads et augmenter les ressources » dans les deux articles suivants :

Latence des événements

Dès que les événements sont générés sur le client, le mécanisme de transfert d’événements prend un certain temps pour les transférer au collecteur.

Ce délai peut être dû à la configuration de l’abonnement, comme le paramètre DeliveryMaxLatency , les performances du collecteur, du redirecteur ou du réseau.

Remarque

Assurez-vous que les événements ne sont pas remplacés sur le client avant d’être transférés. Nous devons généralement gérer ce problème uniquement lorsque les clients génèrent une grande quantité d’événements, tels qu’un serveur occupé ou le contrôleur de domaine qui transfère le journal de sécurité.

Limitation et configuration système requise

Vous déployez le transfert EventLog dans un environnement volumineux. Par exemple, vous déployez 40 000 à 100 000 ordinateurs sources. Dans ce cas, nous vous recommandons de déployer plusieurs collecteurs qui ont entre 2 000 et 4 000 clients par collecteur.

En outre, nous vous recommandons d’installer au moins 16 Go de RAM et quatre (4) processeurs sur le collecteur pour prendre en charge une charge moyenne de 2 000 à 4 000 clients pour lesquels un ou deux abonnements sont configurés.

Les disques rapides sont recommandés et le journal ForwardedEvents peut être placé sur un autre disque pour de meilleures performances.

L’utilisation de la mémoire du service Collecteur d’événements Windows dépend du nombre de connexions reçues par le client. Le nombre de connexions dépend des facteurs suivants :

  • Fréquence des connexions
  • Nombre d’abonnements
  • Nombre de clients
  • Système d’exploitation des clients

Par exemple, pour les valeurs par défaut de 4 000 clients et de cinq à sept abonnements, la mémoire utilisée par le service Collecteur d’événements Windows peut rapidement dépasser 4 Go et continuer à croître. Cela peut rendre l’ordinateur qui ne répond pas.

Fréquence des connexions clientes

Trois paramètres contrôlent la fréquence des connexions clientes :

  • Refresh= (spécifié dans l’URL de configuration de l’objet de stratégie de groupe)
  • DeliveryMaxLatency (spécifié dans l’abonnement)
  • HeartbeatInterval (spécifié dans l’abonnement)

Paramètre Refresh= dans l’objet de stratégie de groupe

Ce paramètre est mesuré en secondes. Il contrôle la fréquence à laquelle le client se connecte à l’URL /WEC pour énumérer les abonnements disponibles.

Le collecteur répond en fournissant une liste des abonnements activés pour le client. La réponse inclut les signets de chaque canal et la requête Xpath. Dès que le client reçoit les informations, il commence à envoyer les événements ou les paquets de pulsation à l’URL /Subscriptions. Si les abonnements ne changent pas fréquemment, ce paramètre peut être configuré pour case activée toutes les quelques heures, voire moins souvent.

DeliveryMaxLatency

Contrôle la fréquence des connexions clientes. Pour un déploiement volumineux, vous pouvez créer un abonnement pour les événements urgents défini sur une fréquence de 5 minutes, et un autre pour les événements moins urgents défini sur une fréquence de 2 heures.

HeartbeatInterval

Contrôle le status inactif dans la fenêtre status runtime de la console. Peut être défini sur la même valeur que DeliveryMaxLatency ou une valeur plus élevée pour donner aux clients un délai supplémentaire avant qu’ils ne soient marqués comme inactifs.

Paramètres personnalisés

Pour configurer des paramètres personnalisés, vous devez utiliser la ligne de commande pour exécuter Wecutil. Pour plus d’informations, consultez Wecutil.exe.

  • Vous pouvez répertorier l’abonnement configuré en tant que wecutil es.

  • Vous devez d’abord basculer l’abonnement sur « Personnalisé » :

    wecutil ss <SubscriptionName> /cm:"Custom"
    
  • Ensuite, définissez le paramètre DeliveryMaxLatency :

    wecutil ss <SubscriptionName> /dmlt:7200000
    

    (La valeur est en millisecondes : 7200000 = 2 heures)

  • Ajustez HeartbeatInterval à la même valeur. Ce paramètre affecte les status « inactifs » pour chaque client dans la console :

    wecutil ss <SubscriptionName> /hi:7200000
    

Optimisation de la distribution de l’abonnement

Les clients envoient les événements à l’URL /subscriptions. Ces connexions sont très importantes pour l’utilisation de la mémoire des collecteurs.

Les modes préconfigurés suivants sont disponibles.

  • Normal

    • Fournit une remise fiable des événements et n’essaie pas d’économiser la bande passante.
    • Le choix approprié, sauf si vous avez besoin d’un contrôle plus strict sur l’utilisation de la bande passante ou que vous exigez que les événements transférés soient remis le plus rapidement possible.
    • Utilise le mode de remise par extraction, traite par lot cinq éléments à la fois et définit un délai d’attente de traitement par lots de 15 minutes.
  • Réduire la bande passante

    • Vérifie que l’utilisation de la bande passante réseau pour la remise d’événements est strictement contrôlée.
    • Le choix approprié si vous souhaitez limiter la fréquence des connexions réseau pour remettre des événements.
    • Utilise le mode de remise push et définit un délai d’attente par lot de 6 heures et un intervalle de pulsation de 6 heures.
  • Réduire la latence

    • Vérifie que les événements sont remis avec un délai minimal.
    • Le choix approprié si vous collectez des alertes ou des événements critiques.
    • Utilise le mode de remise push et définit un délai d’expiration de lot de 30 secondes.

Le client se connecte au collecteur à la fréquence spécifiée pour envoyer les événements ou envoyer une pulsation. Les paramètres « Normal » par défaut peuvent entraîner une utilisation élevée de la mémoire en ayant entre 2 000 et 4 000 clients par collecteur.

Configurer le nom du collecteur

Vous pouvez configurer le nom du collecteur sur le client en configurant l’objet stratégie de groupe (GPO) suivant :
Configuration ordinateur/Modèles d’administration/Composants Windows/ Transfert d’événements/ Configurer le Gestionnaire d’abonnements cible

Vous pouvez également définir des paramètres de Registre dans la sous-clé suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager

Les objets de stratégie de groupe qui attribuent le collecteur à chaque client peuvent être filtrés à l’aide du paramètre de sécurité sur l’objet de stratégie de groupe lui-même ou d’un filtre WMI. Par exemple, si le nom de l’ordinateur se termine toujours par un chiffre (par exemple, computer1, computer2, etc.), nous pouvons créer des objets de stratégie de groupe pour pointer les clients vers 10 collecteurs différents.

Consolidation des abonnements

La configuration de plusieurs abonnements augmente le nombre de connexions. Les considérations présentées plus haut dans cet article s’appliquent à chaque abonnement.

Nous vous recommandons de configurer l’abonnement en modifiant la requête Xpath et en plaçant plusieurs requêtes dans le même abonnement.