Event Tracing for Windows : Vu de l’intérieur

Vous vous demandez peut-être pourquoi
Microsoft développe un autre moyen d’analyse
des données de performances alors qu’existe
déjà  le Performance Monitor. Réponse : Microsoft
voulait offrir un outil léger aux développeurs
d’applications et aux administrateurs
pour superviser les applications et les processus
dans des environnements de production,
sans trop ralentir le système. En effet, appliquer
Performance Monitor à  des serveurs de production
en mode 24 x 7 sans penser que leurs
performances en seront affectées, n’est pas
réaliste. Et Microsoft a conçu ETW dans cette
optique. ETW y parvient grâce à  une architecture
qui combine des composants en mode
kernel et en mode utilisateur optimisés pour
écrire rapidement des événements dans une application log ou de consommation.
Comme le montre la figure 1, l’architecture ETW est constituée de plusieurs
composants : un traceur d’événements, un log ou une application de consommation,
des providers et une application de contrôle. Le traceur d’événements
crée des sessions de journalisation en mode kernel ou mode utilisateur qui effectuent la trace proprement dite.
Windows 2003 et XP peuvent accepter
jusqu’à  62 sessions de journalisation,
tandis que Win2K peut aller jusqu’à  31.
Chaque session a un pool de buffers
dédié dans lequel le traceur d’événements
écrit les données d’événements.
Windows crée des buffers pour chaque
processeur, de sorte que si une application
crée un événement sur le processeur
0, le traceur d’événements
écrit l’événement dans le buffer de
trace de ce processeur. On peut préciser
le nombre minimum et maximum
de buffers que Windows doit créer
pour une session de journalisation
donnée. Par défaut, Windows crée les
buffers dans la zone mémoire pool non
pagée du système, ce qui signifie que
Windows ne pagera pas les données
d’événements des buffers sur disque si
le système est en manque de mémoire.
Cette situation par défaut est un avantage
du point de vue des performances
pour la session de journalisation, parce
que les buffers seront toujours en mémoire
quand ils seront nécessaires.
Cependant, quand vous établissez la
session de journalisation, vous pouvez
indiquer que les buffers utilisent plutôt
la mémoire de pool pagée.
Le traceur d’événements met sur
chaque événement un tampon horodateur
qui contient les informations
suivantes :

• heure de l’événement
• ID du processus sous lequel l’événement
  est survenu

• ID du thread sous lequel l’événement
  est survenu

• temps de CPU en mode utilisateur
• temps de CPU en mode kernel

Quand vous installez une session
de trace, vous pouvez préciser la résolution
du tampon horodateur. Ce peut
être une résolution de 100 millisecondes
(ms) à  100 nanosecondes, selon
le mécanisme par lequel le traceur
d’événements obtient le tampon horodateur.
Plus la résolution est basse, et
moins la performance du système sera
affectée pendant une session de trace.
Mais vous verrez moins de résolution
dans les données journalisées.
Quand les buffers sont pleins, le
traceur d’événements écrit des données
d’événements dans le log ou dans
l’application de consommation. Si une
application de consommation a besoin
d’une journalisation immédiate, le
traceur d’événements écrit des données
d’événements dans l’application
de consommation pratiquement en
temps réel. Sur un système classique,
l’overhead de ETW est d’environ 5 %
de la CPU pour journaliser 20 000 événements
par seconde. Le traceur
d’événements journalise les événements
dans des fichiers binaires spéciaux
avec une extension .etl. Ces fichiers
binaires ne sont pas lisibles par
l’homme mais vous pouvez utiliser les
outils décrits plus loin pour les convertir
en fichiers texte, HTML ou CSV
(comma-separated value).
Le provider se trouve au coeur du
sous-système ETW. Les providers peuvent
être les applications en mode utilisateur
ou les drivers en mode kernel.
Ils sont la source des données d’événements:
ce sont les applications qui envoient
les événements au traceur
d’événements. Ainsi, si un développeur
crée une application qui effectue
des transactions sur une base de données,
il écrit un provider qui impute les
événements au traceur d’événements
chaque fois qu’une transaction démarre
et s’arrête. Les providers ne sont
actifs que quand une session a été
créée dans le traceur d’événements qui
appelle ce provider.
Dans Windows 2003, XP et Win2K,
Microsoft fournit des providers prêts à 
l’emploi pour divers services système,
dont AD (Active Directory), LDAP
(Lightweight Directory Access Protocol),
IIS (Internet Information Services)
6.0, ASP.NET Netlogon, et LSA
(Local Security Authority). Microsoft
offre également un provider kernel
Windows intégré pour des opérations
au niveau système, comme la création
et la suppression de processus, la création
et la suppression de threads, l’I/O
disque, l’I/O de fichier, le trafic TCP et UDP, les défauts de page, l’I/O de registre,
les chargements d’images exécutables
et les commutateurs de
contexte. Dans cet article, je me concentre
principalement sur les providers
internes (in-the-box). Vous pouvez
bien sûr écrire les vôtres. Dans ce
cas, consultez la documentation sur la
trace d’événements de MSDN (Microsoft
Developer Network) à  http://
msdn/microsoft.com/library/en-us/
perfmon/base/event_tracing.asp.
L’application de contrôle crée des
sessions de journalisation, définit leurs
paramètres initiaux (tailles des buffers,
résolution du tampon horodateur, par
exemple) et démarre et arrête les
sessions de journalisation à  l’heure
programmée. Microsoft offre plusieurs
applications de contrôle externes, évoquées
dans la section « Outils ETW », ciaprès.
La principale caractéristique de
l’architecture ETW est que chacun de
ses composants (traceur d’événements,
application de contrôle) fonctionne
de manière indépendante. Le
provider, le traceur d’événements,
l’application de contrôle peuvent
s’ignorer mutuellement. Très souple,
cette architecture permet d’utiliser facilement
des données générées par
ETW dans des buts très divers. ETW
fournit également aux développeurs
d’applications un excellent cadre pour
tester l’impact de leurs applications sur
les systèmes Windows sans être obligés
de construire eux-mêmes une fonction
de journalisation.