Comment tirer parti de la trace d’événements

trace d’événements
donne un bon aperçu de la charge de
travail d’authentification actuelle sur le
serveur et sur la quantité de ressources
que chaque événement de connexion
requiert. Fort de cette information,
vous pourrez ensuite déterminer la
charge supplémentaire que créeront
les utilisateurs additionnels.
La trace peut être mise en place de
diverses manières. La première méthode
consiste à  programmer une session
de trace AD pour qu’elle démarre
pendant la période de pic des
connexions dans un environnement
de production en collectant des données
pendant suffisamment longtemps
pour déterminer l’impact de chaque
événement de connexion sur le DC. La
deuxième technique consiste à  valider
le tracing dans un environnement de
laboratoire contrôlé pour déterminer
l’overhead moyen par transaction de
connexion, puis à  extrapoler l’overhead
moyen par rapport au nombre
d’utilisateurs attendus sur le système.
L’exécution d’une session de trace AD
dans un environnement de production
influencera bien sûr la performance du
DC. Même si la session entraînera probablement
moins de 5 % d’overhead
de CPU, certains administrateurs pourraient
bien ne pas pouvoir exécuter
une session de trace dans leurs environnements
de production. C’est
pourquoi nous allons examiner de plus
près l’approche en laboratoire.
Pour exécuter la session de trace
AD en laboratoire, utilisons le snap-in
Performance Logs and Alerts pour instaurer
deux sessions de journalisation
sur un DC Windows 2003. Une session
de journalisation utilisera les providers
non-système pour capturer les événements
qui représentent la charge de
travail AD sur un DC pendant une
connexion. La seconde session utilisera
le provider système pour capturer
des statistiques sur le kernel. Ces données
kernel supplémentaires vous permettront
de générer un rapport de
charge de travail à  la fois précis et complet.
Pour établir la première session,
choisissez l’option Nonsystem providers
dans le snap-in et ajoutez tous les
fournisseurs associés à  AD (c’est-à dire,
Active Directory : Kerberos, Active
Directory : Netlogon, Active Directory :
SAM, Local Security Authority, NTLM
Security Protocol, et Windows NT
Active Directory Service). Pour établir
la seconde session, choisissez l’option
Events logged by system provider et
cochez, au minimum, les cases Process
creations/deletions, Thread creations/
deletions, Disk input/output et
Network TCP/IP.
Après avoir établi les deux sessions
de journalisation de trace, démarrez
manuellement chacune d’elles puis
connectez-vous à  AD sur la machine
Windows 2003. Une fois le processus
de connexion terminé, arrêtez les deux
sessions de journalisation. Utilisez tracerpt.
exe pour combiner les deux fichiers
.etl résultants et générer les rapports
CSV, récapitulatif et charge de
travail.
Si l’on examine un fichier .csv classique,
on y voit beaucoup d’événements
différents. Ils représentent les
transactions que Microsoft a codées
dans ses providers et ils correspondent
à  un ensemble d’actions qui sont exécutées.
Comme l’exemple .csv de la figure
3 le montre, de tels événements
ne brillent pas par leur clarté.
La première ligne d’un fichier .csv
contient des informations d’en-tête
qui identifient chaque champ de données.
Par exemple, l’exemple de la figure 3 contient sept champs de données
:

• Event Name – spécifie le nom de
  l’événement. Dans ce cas, c’est
  GetASTicket qui est la demande du
  client pour le Kerberos Authentication
  Service.

• Type – spécifie le type d’événement.
  En principe, ce champ contiendra
  Start ou End, pour marquer le début
  et la fin d’un événement.

• TID – liste l’ID thread (en hexadécimal)
  sous lequel l’événement courant
  s’exécute.

• Clock-Time – indique l’heure à  laquelle
  l’événement s’est produit.
  L’heure présente un format Integer8,
  qui est une valeur de 64 bits contenant
  le nombre d’intervalles de 100
  nanosecondes écoulées depuis
  12:00 A.M, 1er janvier, 1601. Malgré
  son opacité, Microsoft utilise fréquemment
  le format Integer8 pour
  des services, comme WMI et AD.

• Kernel(ms) – spécifie le temps, en
  tics d’horloge, utilisé pour cet événement,
  subdivisé en temps de CPU en
  mode kernel. Les tics d’horloge se
  convertissent en temps réel d’après
  le cycle d’horloge d’un PC classique,
  qui est de 1 tic d’horloge toutes les
  10 ms. Par exemple, 100 tics d’horloge
  équivaudraient à  une seconde
  (100 x 10). A noter que le temps de
  CPU représenté ici et pour le temps
  utilisateur est un peu trompeur
  parce que la valeur indiquée est le
  temps à  partir du point auquel le
  thread courant a démarré, jusqu’au
  moment où le traceur d’événements
  déclenche l’événement. Par conséquent,
  pour générer des temps de
  CPU, vous devrez compter sur le rapport
  de charge de travail.

• User(ms) – indique le temps, en tics
  d’horloge, utilisé pour cet événement,
  subdivisé en temps de CPU en
  mode utilisateur.

• User Data – contient toute donnée
  associée que Microsoft a jugé bon
  d’inclure dans la transaction. Ici,
  Microsoft a fourni quatre éléments
  d’information supplémentaires. La
  première valeur, 0x00000025, est un
  flag ID d’instance qui n’est pas pertinent
  pour cette discussion. La
  deuxième valeur, « administrator »,
  indique l’ID utilisateur demandant le
  service d’authentification, tandis que
  la troisième valeur, « krbtgt/DOMAINA
  », est le nom du service d’octroi
  de ticket Kerberos fonctionnant
  sur le domaine appelé DOMAINA. La
  dernière valeur, « DOMAINA », est le
  nom du domaine de destination.

A ce stade, vous vous demandez
peut-être « Comment interpréter utilement
les données d’événements ? »
Malheureusement, Microsoft n’a pas
documenté les données que AD et les
providers associés fournissent. Heureusement,
tous les providers de trace
d’événements sont enregistrés dans le
namespace WMI. Et donc on peut utiliser
des outils comme WMI CIM Studio
pour trouver les transactions de
chaque provider et les champs de données
dans ces transactions. WMI CIM
Studio peut être téléchargé au
Microsoft Download Center. Vous pouvez trouver les providers
enregistrés dans le chemin
Root\WMI\EventTrace.
La figure 4 montre l’information
que fournit WMI CIM Studio pour la
transaction GetASTicket. On voit que
WMI CIM Studio fait référence aux
transactions en tant que classes et aux
champs de données en tant que propriétés.
Même si les noms de propriétés
de WMI ne correspondent pas exactement
aux en-têtes des champs de
données du fichier .csv, les noms de
propriétés sont suffisamment semblables
pour que vous puissiez déterminer
les champs de données dans le
fichier .csv.
Si vous ne voulez pas travailler sur
les données brutes du fichier .csv, vous
pouvez utiliser le rapport de charge de
travail. Celui de la figure 5 a été généré
par tracerpt.exe à  partir de la trace logon
AD. Pour fournir ce rapport, tracerpt.
exe a transformé les données
brutes du fichier .csv en statistiques
utiles, comme le nombre total de transactions.
Pour calculer le nombre total
de transactions GetASTicket, par
exemple, tracerpt.exe a accouplé les
événements Start and EndType de
GetASTicket dans les données brutes
de .csv. Après quoi, tracerpt.exe a
compté le nombre de couples ou
paires.
Ce rapport contient une autre statistique
: Response Time(ms), qui représente
le temps total consacré à  une
transaction. Une valeur 0 signifie que le
rapport n’a pas été formaté pour montrer
le nombre de décimales requises
pour présenter une valeur très petite
(0.00023, par exemple). Par conséquent,
tracerpt.exe arrondit le nombre
à  0.
Le rapport de charge de travail
de la figure 5 montre que 14 types différents de transactions sont survenues
pendant une connexion utilisateur.
Chacune de ces transactions
demande un certain temps pour s’exécuter
et prend du temps de CPU. Par
ailleurs, certaines transactions s’exécutent
plus d’une fois. Le fichier .csv indique
la durée de chaque transaction
entre le début et la fin et le nombre de
tics d’horloge que chaque transaction
prend. Donc, en utilisant l’information
des deux rapports, on peut totaliser les
temps de CPU pour déterminer la
charge de CPU sur le DC pour une session
de connexion utilisateur. Par
exemple, si l’on importe le fichier .csv
dans Excel, on peut le trier par nom de
transaction et ajouter les temps de CPU
kernel et utilisateur pour chaque
couple début-fin pour obtenir le temps
de CPU total pour chaque type de transaction.
Un tel résultat offre plus de
granularité que la statistique du rapport
de charge de travail.
Il faut rappeler que vous ne regardez
que AD et ses sous-systèmes associés,
comme Kerberos et le processus
LSA. Cette trace ne capture pas d’autres
événements associés à  la connexion,
comme le téléchargement
d’un profil utilisateur ou la saisie d’une
information de stratégie de groupe. Si
nécessaire, vous pouvez recourir à  certains
autres providers pour capturer
des données sur ces événements : par
exemple, le provider Windows Kernel
pour capturer des mesures d’I/O fichier.
Sachez aussi qu’il ne suffit pas de
multiplier simplement la charge générée
par une journalisation utilisateur
sur le DC par le nombre d’utilisateurs,
pour obtenir la charge globale. La
charge est par nature non linéaire
parce que AD et d’autres transactions
bénéficient d’autres processus comme
le cache mémoire. Par conséquent,
pour connaître vraiment la charge au
fur et à  mesure qu’on ajoute des utilisateurs,
il faut répéter le test de trace
de charge en augmentant progressivement
le nombre d’utilisateurs, pour
déterminer la relation entre le nombre
d’utilisateurs et la charge de CPU globale.