Vous lancez PktMon en mode multi‑file avec une limite à 5 MB et vous récupérez pourtant des blocs proches de 100–130 MB ? Ce comportement vient de la mécanique ETW, pas d’une simple « option qui ne marche pas ». Voici l’explication complète et des solutions concrètes.
Problème : PktMon ne respecte pas --file-size en mode multi‑file
Contexte : l’utilitaire PktMon (version 6.2.19041.4355) est démarré ainsi :
pktmon start --capture --comp nics --pkt-size 0 --file-size 5 --log-mode multi-file
Attendu : une rotation de fichiers .etl de ~5 MB chacun.
Observé : un premier fichier vide, puis à l’arrêt (pktmon stop) des segments très volumineux (~98–131 MB). Même après une longue capture, la majorité des fichiers varient entre 98 MB et 131 MB, très loin de la cible.
Diagnostic : d’où vient l’écart ?
La clé se trouve dans la pile Event Tracing for Windows (ETW), que PktMon utilise pour journaliser les paquets. Trois paramètres combinés expliquent les dépassements systématiques.
Taille des tampons ETW utilisée par PktMon
- PktMon fixe des tampons de 16 MB pour la session ETW qu’il crée.
- Le paramètre
--file-sizeest un seuil de rotation, pas une limite dure : dès qu’un tampon plein est « vidé » (flush), son contenu est écrit en entier dans le fichier courant. - Conséquence : même si la rotation est déclenchée à ~5 MB, l’écriture fait grossir le fichier par multiples de 16 MB.
Mise en tampon par processeur
- Par défaut (absence du drapeau
EVENT_TRACE_NO_PER_PROCESSOR_BUFFERING), ETW alloue des tampons par cœur logique. - Lors d’un flush, tous les tampons actifs sont écrits dans le fichier. Sur une machine multi‑cœur, la taille minimale écrite d’un coup est donc :
nombre_de_cœurs × 16 MB(hors en‑têtes).
Pas de vidage temporisé
- Le
FlushTimerde la session PktMon est à0: pas de purge périodique. - Résultat : la détection et la rotation n’interviennent qu’au remplissage complet d’un tampon (ou à l’arrêt), jamais « au fil de l’eau ».
Ce que cela donne en pratique
Une approximation simple de la taille minimale écrite lors du premier flush est :
taille_minimale ≈ (nombre_de_cœurs_logiques × 16 MB) + overhead_en-têtes
| Cœurs logiques | Taille attendue du premier segment (≈) | Ordre de grandeur constaté |
|---|---|---|
| 4 | 64 MB | 64–70 MB |
| 6 | 96 MB | 98–103 MB |
| 8 | 128 MB | 129–132 MB |
| 12 | 192 MB | ≈195 MB |
| 16 | 256 MB | ≈260 MB |
On retrouve exactement vos ~98 MB (machines 6 cœurs) et ~131 MB (8 cœurs), indépendamment de la cible --file-size 5. Ce n’est pas un « bug » de taille de fichier, mais une conséquence directe de la stratégie de tampons d’ETW telle que PktMon la configure.
Ce que signifie vraiment --file-size
Dans PktMon, --file-size désigne un seuil de rotation. Quand la taille du fichier courant dépasse ce seuil, la session passe au fichier suivant (en mode multi‑file). Pourtant, lors du flush, ETW déverse des tampons entiers. Vous obtenez donc :
- des fichiers strictement supérieurs au seuil (de plusieurs multiples de 16 MB),
- des tailles « quantifiées » par le produit
tampon × cœurs, - un premier « vrai » segment non vide uniquement au premier flush (souvent à l’arrêt).
Solutions et contournements
Selon vos contraintes (risque de perte, simplicité, outillage), choisissez l’une des trois approches ci‑dessous. Toutes permettent d’obtenir des segments proches de 5 MB ou de post‑traiter proprement les gros fichiers produits.
| Approche | Principe | Avantages | Inconvénients | Pour qui ? |
|---|---|---|---|---|
| Relog après capture | Accepter de gros .etl puis re‑segmenter (ITraceRelogger, PerfView, autre outil) en blocs de 5 MB. | Très simple à intégrer dans une chaîne CI/CD ; aucun risque de perte pendant la capture. | Espace disque temporaire important ; étape de post‑traitement supplémentaire. | Collectes longues en prod où la simplicité prime. |
| Réduire la taille des tampons (debug) | Lancer PktMon sous cdb et forcer BufferSize (ex. 64 KB) avant StartTraceW. | Segments bien plus proches de 5 MB ; pas de relog nécessaire. | Nécessite droits et symboles ; risque de Lost Events si tampons trop petits. | Lab, tests contrôlés, besoin de fichiers petits en direct. |
Contrôler la session ETW avec logman | Créer une session ETW indépendante (newfile) avec -bs 64 et -max 5; laisser PktMon émettre, mais confier la rotation à ETW. | Respect strict de ~5 MB ; maîtrise fine des buffers (-bs, -bn, -ft). | Commande plus verbeuse ; coordination avec PktMon (démarrage/arrêt) à prévoir. | Opérations, scripts de support, environnements multi‑cœurs chargés. |
Procédures détaillées
1) Post‑traitement (relog) en segments de 5 MB
Idée : vous laissez PktMon travailler comme il veut, puis vous découpez les .etl générés en « tranches » de 5 MB. Deux options courantes :
- Bibliothèque ITraceRelogger (API Windows) : relisez un
.etlsource et réécrivez plusieurs.etlde sortie tout en respectant un quota de taille. - PerfView : ouvrez le
.etl, filtrez si besoin, puis sauvegardez en segments (« Merge/Save As » avec découpe). C’est pratique pour un usage manuel ou semi‑automatisé.
Exemple de pipeline simplifié (PowerShell pseudo‑code) :
$inputEtl = "C:\capt\PktMon_2024-XX-YY.etl"
$outDir = "C:\capt\split"
$targetMB = 5
# Pseudo‑code : appeler votre relogger maison (ITraceRelogger) ou un outil CLI
relog-etl -Input $inputEtl -OutDir $outDir -ChunkMB $targetMB
Conseil : si vous automatisez, conservez le hash du fichier source et journalisez les offsets/horodatages de découpe pour pouvoir recoller chronologiquement à l’analyse.
2) Forcer des tampons plus petits à l’aide de cdb
But : contraindre la session ETW créée par PktMon à une taille de tampon réduite (ex. 64 KB au lieu de 16 MB), afin que chaque flush écrive de petites quantités.
- Pré‑requis : Debugging Tools for Windows (
cdb.exe), élévation administrateur, symboles configurés de préférence. - Principe : placer un point d’arrêt une fois sur
sechost!StartTraceW, modifier le champ BufferSize de la structureEVENT_TRACE_PROPERTIES(pointeur passé enr8sur x64), puis continuer.
Commande type (cmd) – adapter les guillemets selon votre shell :
cdb -G -c "bu /1 sechost!StartTraceW; g" ^
pktmon start --capture --comp nics --pkt-size 0 --file-size 5 --log-mode multi-file
Une fois arrêté sur StartTraceW, injectez la taille de tampon souhaitée (64 KB = 0x40 en unités de KB) :
ed @r8+0x30 0x40 ; EVENT_TRACE_PROPERTIES.BufferSize (en KB)
g ; reprendre l'exécution
Résultat attendu : la rotation produit des segments bien plus petits (proches, voire légèrement supérieurs à 5 MB). Attention : si le trafic est intense, des tampons trop petits peuvent entraîner des Lost Events. Surveillez les compteurs (voir plus bas).
Bonnes pratiques avec des tampons réduits
- Augmentez le nombre de tampons (MinimumBuffers/MaximumBuffers) si vous observez des pertes.
- Activez un FlushTimer non nul si vous contrôlez la session : un flush périodique réduit la pression au moment de la rotation.
- Testez à charge réelle : la stabilité ressentie en labo à 100 Mbps peut s’effondrer à 10 Gbps.
3) Déléguer la session et la rotation à logman
Cette méthode consiste à laisser PktMon générer les événements, mais à confier l’écriture/rotation à une session ETW utilisateur que vous pilotez avec logman. Vous contrôlez ainsi la taille des tampons (-bs), leur nombre (-nb/-bn) et la rotation (-mode newfile + -max), indépendamment des choix de PktMon.
- Démarrer PktMon pour activer le driver et définir la granularité des paquets (par ex.
--pkt-size 0pour capturer le paquet complet) et les composants (--comp nics). Évitez d’insister sur les options de fichier puisque la session ETW externe va gérer la sortie.
pktmon start --capture --comp nics --pkt-size 0
- Démarrer une session ETW « cap » dédiée au provider PktMon, avec de petits tampons et rotation stricte à 5 MB :
logman start cap -ets ^
-p Microsoft-Windows-PktMon 0x12 5 ^
-bs 64 ^
-max 5 -mode newfile ^
-o PktMon%%d.etl
-p: nom du provider PktMon (mots‑clés0x12à ajuster selon vos besoins) et niveau (5= Verbose typiquement).-bs 64: taille de tampon en KB (ici 64 KB).-max 5+-mode newfile: rotation automatique en segments de ~5 MB.-o PktMon%d.etl: patron de nommage pour la série de fichiers.
- Arrêt et collecte : stoppez d’abord PktMon (pour couper la source), puis la session
logman(pour fermer proprement le dernier segment) :
pktmon stop
logman stop cap -ets
Avantage majeur : ETW respecte strictement -max 5 lors de la rotation parce que chaque flush n’écrit que des tampons de 64 KB, et non 16 MB × cœurs. Vous obtenez en pratique des fichiers de 5–6 MB, très proches de l’objectif opérationnel.
Astuce : si vous constatez des pertes, augmentez le nombre de tampons :
logman stop cap -ets
logman start cap -ets -p Microsoft-Windows-PktMon 0x12 5 -bs 64 -bn 128 256 -max 5 -mode newfile -o PktMon%%d.etl
Ici -bn 128 256 demande 128 tampons minimum et 256 maximum.
Vérifier la qualité de la capture
Détecter les Lost Events
Deux indicateurs à surveiller :
- Compteurs ETW de la session (via
logman query -etsou outils d’analyse) : si des événements perdus apparaissent, augmentez-bs,-bnou baissez le niveau/les mots‑clés. - PerfView : dans Events, vérifiez les warnings de lost events et la pression sur les tampons.
Contrôler la taille effective des segments
Get-ChildItem .\PktMon*.etl | Select-Object Name,@{n="MB";e={[math]::Round($_.Length/1MB,2)}} | Sort-Object Name
En mode logman ci‑dessus, vous devriez voir une série régulière à ~5–6 MB.
Paramètres PktMon et équivalents ETW
| Option PktMon | Effet principal | Équivalent ETW (concept) | Remarques |
|---|---|---|---|
--pkt-size 0 | Capture le paquet complet. | Payload maximal dans les événements. | Augmente le débit d’événements et la pression sur les tampons. |
--log-mode multi-file | Rotation sur seuil. | Session fichier ETW avec newfile. | Le seuil n’est pas une limite dure ; dépend du flush. |
--file-size N | Seuil de rotation (MB). | -max N côté logman. | Écritures par tranches de « tampons », pas octet par octet. |
--comp nics | Émet les événements NICs. | Mots‑clés/ID d’événements du provider PktMon. | Combiner avec un filtrage si possible pour limiter le flux. |
FAQ opérationnelle
Pourquoi ai‑je un premier fichier vide ?
Parce que la session et le fichier sont créés immédiatement, mais aucun tampon n’a encore été flushé. Le premier flush intervient souvent à l’arrêt : c’est là que le second fichier (ou le premier « non vide ») apparaît avec ~100–130 MB selon le nombre de cœurs.
Peut‑on forcer PktMon à respecter strictement 5 MB sans session ETW externe ?
Pas avec la configuration par défaut : tant que PktMon crée des tampons de 16 MB par cœur et qu’il n’y a pas de flush temporisé, les rotations se feront par blocs massifs. D’où l’intérêt de l’approche logman (contrôle des tampons) ou de la réduction de BufferSize via cdb.
Réduire BufferSize ne va‑t‑il pas dégrader la capture ?
Potentiellement oui, si le volume d’événements dépasse la capacité cumulée des tampons. La parade : augmenter le nombre de tampons, activer un FlushTimer, filtrer le trafic (ports, protocoles) et surveiller les compteurs de pertes.
Pourquoi --file-size n’est‑il pas une « limite dure » ?
ETW n’écrit pas en continu octet par octet ; il déverse des tampons complets. --file-size est la condition qui déclenche le passage au fichier suivant, mais le bloc écrit au moment du flush peut dépasser très largement ce seuil.
Recettes prêtes à l’emploi
Capturer et obtenir des segments ~5 MB sans pertes
- Démarrez PktMon avec capture de paquets complets (sans insister sur la sortie) :
pktmon start --capture --comp nics --pkt-size 0
- Démarrez la session ETW contrôlée par
logman:
logman start cap -ets -p Microsoft-Windows-PktMon 0x12 5 -bs 64 -bn 256 512 -max 5 -mode newfile -o .\PktMon%%d.etl
- Arrêtez proprement à la fin :
pktmon stop
logman stop cap -ets
Cette recette donne des .etl de 5–6 MB de façon stable, tout en gardant de la marge pour absorber des pics grâce à -bn 256 512.
Découper après coup un gros .etl en blocs de 5 MB
Si votre chaîne de production produit déjà de gros .etl :
- Stockez le fichier source sur un volume rapide (évitez les NAS lents).
- Reloggez en segments de 5 MB (ITraceRelogger, PerfView).
- Compressez chaque bloc (ZIP) si vous devez transporter les segments.
- Conservez une carte d’horodatage (CSV) pour faciliter l’assemblage chronologique.
Guides de dimensionnement
Estimer la taille minimale d’un segment en mode PktMon « vanilla »
Avec des tampons de 16 MB par cœur, sans flush temporisé :
min_segment ≈ cores × 16 MB (+ en‑têtes)
Exemples concrets :
- 6 cœurs ⇒ ~96 MB (+ en‑têtes) ⇒ ≈98 MB observés
- 8 cœurs ⇒ ~128 MB (+ en‑têtes) ⇒ ≈131 MB observés
Dimensionner une session logman
- Trafic modéré (≤1 Gbps) :
-bs 64,-bn 128 256,-max 5. - Trafic soutenu (1–10 Gbps) :
-bs 128,-bn 256 512,-max 5. Ajuster au besoin si des pertes apparaissent. - Pics imprévisibles : conservez
-bsconservateur (64–128 KB) mais montez-bnpour donner de l’élasticité.
Bonnes pratiques supplémentaires
- Filtrer en amont : si possible, configurez des filtres PktMon (ports/protocoles/adresses) pour réduire le volume d’événements au strict nécessaire.
- Amorcer la rotation tôt : en mode
logman, un-ft(flush timer) non nul peut lisser l’écriture et éviter un gros bloc final au stop. - Surveiller en temps réel : un script qui lit périodiquement
Get-ChildItem PktMon*.etlpermet de valider que la rotation fonctionne (taille croissante puis passage au fichier suivant). - Automatiser l’archivage : compressez et poussez les segments vers un stockage objet avec un retention policy afin d’éviter le remplissage du disque.
Résumé exécutif
Si --file-size 5 ne donne pas des fichiers de 5 MB, c’est normal avec la configuration par défaut : PktMon s’appuie sur des tampons ETW de 16 MB par cœur et aucun flush temporisé. Le premier flush (souvent à l’arrêt) écrit donc ~cœurs × 16 MB, d’où des segments de 98–131 MB. Pour obtenir des fichiers proches de 5 MB, vous avez trois voies : relog après coup, forcer des tampons plus petits (via cdb), ou confier la session/rotation à logman avec -bs réduit et -max 5 -mode newfile. Dans la majorité des cas en production, logman est la solution la plus robuste.
Checklist rapide
- ✔️ Besoin immédiat de segments ~5 MB pendant la capture ? →
logman. - ✔️ Ok pour post‑traiter ? → Relog (ITraceRelogger / PerfView).
- ✔️ Labo/POC et contrôle fort ? →
cdbpour réduire BufferSize (surveiller Lost Events). - ✔️ Quel que soit le cas : surveiller les pertes et ajuster
-bs/-bn.
Annexe : script PowerShell utile
Ce petit script affiche la théorie vs. la réalité sur votre machine (estimation minimale avec tampons 16 MB vs. fichiers présents). Modifiez $cores si l’auto‑détection ne reflète pas votre config.
$cores = (Get-CimInstance -ClassName Win32_Processor | Measure-Object -Sum NumberOfLogicalProcessors).Sum
$minTheoriqueMB = $cores * 16
Write-Host ("Cœurs logiques :", $cores)
Write-Host ("Taille min. théorique d'un segment (PktMon par défaut) ≈ {0} MB" -f $minTheoriqueMB)
Get-ChildItem .\PktMon*.etl -ErrorAction SilentlyContinue |
Sort-Object Name |
Select-Object Name,@{n="Taille(MB)";e={[math]::Round($_.Length/1MB,2)}} |
Format-Table -Auto
Si vos premières rotations tombent à ~$minTheoriqueMB, vous êtes bien dans le cas décrit ; passez à la solution logman ci‑dessus pour des segments ~5 MB.
Points clés à retenir
- ETW écrit par tampons entiers : seuil de rotation ≠ limite dure.
- PktMon crée 1 tampon/par cœur de 16 MB → premiers segments massifs.
- Pas de flush timer → gros flush à l’arrêt.
- Trois solutions efficaces : relog, tampons réduits via
cdb, sessionlogmanpilotée. - Surveiller les pertes quand on réduit les tampons.
En appliquant l’une de ces approches, vous obtenez soit des segments nettement plus proches de 5 MB, soit un processus de post‑traitement fiable pour re‑segmenter sans perte de données.