Suivi réseau dans Windows 7 : architecture
L’illustration ci-dessous montre l’architecture de suivi réseau de base dans Windows 7.
Le suivi réseau utilise l’infrastructure de suivi d’événements pour Windows (ETW) disponible dans Windows. Les composants réseau (tels que Winsock, TCP/IP, NDIS, capture de paquets, etc.) s’inscrivent en tant que fournisseurs de trace ETW et émettent des événements liés à l’activité réseau. Toute activité enregistrable d’importance peut être un événement journalisé dans ETW. Le suivi de ces composants réseau et captures de paquets peut être activé à l’aide du contexte de trace netsh qui agit comme un contrôleur ETW.
Les traces générées sont collectées dans un fichier de journal des traces d’événements (ETL). Ces fichiers ETL peuvent ensuite être analysés à l’aide d’un certain nombre d’outils, tels que Network Monitor 3.2 et versions ultérieures, observateur d'événements, netsh trace convert ou Tracerpt.exe.
Chaque événement ETW a un en-tête commun où ETW stocke des informations telles que les propriétés de l’événement, les horodatages et l’ID d’activité. (Pour plus d’informations sur les ID d’activité, consultez Écriture d’événements connexes dans un scénario de bout en bout). L’ID d’activité est utilisé pour mettre en corrélation les événements. En mode utilisateur, les ID d’activité sont stockés dans des threads, et tous les événements enregistrés dans un thread sont automatiquement marqués avec le même ID d’activité. En mode noyau, l’ID d’activité doit être transmis explicitement lorsqu’un événement est journalisé. Par défaut, les fichiers ETL sont corrélés pour regrouper des événements sous des ID d’activité spécifiques.
Pour plus d’informations sur les événements Windows et ETW, consultez Événements Windows.
Composants ETW dans le suivi réseau
Le suivi réseau utilise ETW comme mécanisme de suivi principal pour fournir des informations sur ce que font les sous-systèmes de mise en réseau. Il existe quatre composants main dans ETW : les sessions de suivi d’événements, les fournisseurs d’événements, les contrôleurs d’événements et les consommateurs d’événements.
La mise en mémoire tampon et la journalisation ont lieu dans les sessions de suivi d’événements, qui acceptent les événements des fournisseurs et créent des fichiers de trace.
Un fournisseur d’événements est une entité logique qui écrit des événements dans des sessions ETW. Un fournisseur d’événements peut être une application en mode utilisateur, une application managée, un pilote ou toute autre entité logicielle. Les fournisseurs d’événements s’inscrivent auprès d’ETW et écrivent des événements à partir de différents points du code en appelant l’API de journalisation ETW. En raison de l’instrumentation croissante des événements dans de nombreux composants de système d’exploitation, même une application ou un scénario simple dans Windows contient plusieurs composants qui sont des fournisseurs d’événements.
Un contrôleur d’événements démarre et arrête les sessions de suivi d’événements et active les fournisseurs. Lorsqu’un fournisseur d’événements est activé dynamiquement par l’application de contrôleur d’événements, le fournisseur envoie des événements à une session de suivi d’événements spécifique désignée par le contrôleur d’événements. Chaque événement envoyé par le fournisseur d’événements à la session de suivi des événements se compose d’un en-tête fixe, qui inclut les métadonnées d’événement et toutes les données personnalisées supplémentaires enregistrées par le fournisseur.
Un consommateur d’événements est une application qui lit les fichiers journaux ou écoute une session de suivi d’événements pour les événements en temps réel et les traite. Un exemple de consommateur d’événements est Microsoft Network Monitor 3.2, qui inclut la possibilité de lire et d’afficher les fichiers journaux produits par le suivi réseau dans Windows 7.
Les événements sont remis aux consommateurs d’événements dans l’ordre chronologique, et il existe différentes applications de consommateur d’événements qui affichent les événements dans des formats spécifiques. Lorsqu’un événement est journalisé dans une session, ETW ajoute des informations supplémentaires à l’en-tête d’événement, notamment l’horodatage, l’ID de processus et de thread, le numéro de processeur et les données d’utilisation du processeur du thread de journalisation. Ces données sont ensuite transmises aux consommateurs d’événements, ainsi que toutes les données personnalisées incluses par le fournisseur.
Les fournisseurs qui utilisent les nouvelles API de journalisation des événements doivent fournir un fichier XML appelé manifeste d’événement. Ce fichier fournit des métadonnées pour définir toutes les données personnalisées et les informations de disposition pour les événements écrits par le fournisseur. Une application consommateur à usage général utilise ensuite les API TDH (Trace Data Helper) pour récupérer les métadonnées d’événement, décoder les événements et les afficher.
Avec le suivi réseau dans Windows 7, le côté contrôleur d’événements/consommateur inclut une prise en charge du suivi basé sur un scénario de bout en bout, intégrée à l’ensemble des expériences de diagnostic et de support Windows. Un scénario définit une collection de fournisseurs d’événements impliqués dans le scénario. Le côté contrôleur d’événements/consommateur définit les scénarios (contextes) où le suivi peut être utilisé, y compris les fournisseurs appropriés pour des scénarios donnés entre les composants réseau. Le côté fournisseur d’événements inclut des événements de suivi de réseau standardisés provenant de différents composants de la pile réseau, qui peuvent être corrélés via des ID d’activité ETW. Les fournisseurs utilisent un schéma réseau commun qui normalise l’utilisation des concepts ETW tels que les mots clés, les niveaux, les tâches et les opcodes. Le schéma définit également des événements qui sont courants pour de nombreux composants réseau, tels que les événements d’erreur, les événements de suppression de paquets, les événements de schéma et les événements de transition d’état.