enregistrement en temps réel

Question

J'ai une application qui a une boucle, partie d'un "Scheduler", qui fonctionne à tout moment et qui est le cœur de l'application. Un peu comme une boucle de jeu, juste que mon application est une application WPF et ce n'est pas un jeu. Naturellement, l'application se connecte à de nombreux points, mais le Scheduler fait un suivi sensible, et parfois il est impossible de simplement dire à partir des logs ce qui a pu se tromper (et par erreur je ne veux pas d'exceptions) ou l'état actuel. Étant donné que la boucle interne du planificateur s'exécute à de courts intervalles, vous ne pouvez pas effectuer de journalisation basée sur les E/S de fichier (ou en utilisant l'Observateur d'événements). D'abord, vous devez le regarder en temps réel, et deuxièmement, le fichier journal augmentera très rapidement. Donc, je pensais à des façons de montrer ces données à l'utilisateur dans le temps réel, certaines choses que je compte:

• Afficher les données en temps réel dans l'interface utilisateur
• Utilisez AllocConsole/WriteConsole pour afficher ces informations dans une console
• Utiliser une application console différente qui affiche ces informations, la communication entre le planificateur et l'application de la console en utilisant des tuyaux ou d'autres techniques IPC
• Utilisez Analyseur de performances Windows et en quelque sorte le nourrir avec ces informations
• ETW

Afficher dans l'interface utilisateur aurait ses problèmes. D'abord, il ne s'intègre pas avec l'interface utilisateur que j'avais en tête pour ma demande, et je ne veux pas compliquer l'interface utilisateur juste pour cela. Ce diagnostic ne se produirait que rarement. Deuxièmement, il y aura une protection des données non triviale, car le planificateur a son propre thread.

Une fenêtre de console séparée fonctionnerait probablement, mais je suis toujours inquiet si ce n'est pas trop de seuil. Allouer ma propre console, car il s'agit d'une application Windows, serait probablement mieux qu'une application de console différente (3), car je n'ai pas besoin de me soucier de la communication IPC et de la communication non bloquante. Cependant, un utilisateur peut fermer la console que j'ai allouée, et cela poserait problème dans ce cas. Avec un processus séparé, vous n'avez pas à vous en préoccuper.

En supposant qu'il existe une API pour Performance Monitor, il ne serait pas trop bien intégré avec mon application ou apparent aux utilisateurs. Utiliser ETW ne résout rien non plus, juste une idée aléatoire, j'ai encore besoin d'afficher cette information en quelque sorte. Ce que d'autres pensent, y aurait-il d'autres moyens que j'ai manqués?

Answer 1

Respectueusement - les réponses d'Adrian K et de Dima ne sont pas correctes. La bonne réponse est d'utiliser Event Tracing For Windows (ETW). C'est ce que nous utilisons pour toute la journalisation sous Windows. C'est extrêmement robuste et très performant. Par exemple, W7 enregistre un événement ETW sur de nombreux événements OS - tout le temps - y compris le changement de contexte du processeur. Avez-vous déjà utilisé le moniteur de performance dans W7? Il consomme des événements ETW du noyau.

Je vous recommande de faire tous votre journalisation avec ETW. Pourquoi? Plusieurs raisons:

1. Son omniprésent
2. Vous pouvez activer désactiver la journalisation dans votre processus en cours d'exécution. Aucun redémarrage de processus requis. (oui, d'autres bûcherons le font, mais d'autres non).
3. Il est conçu pour être inclus dans le code de livraison.
4. La consignation d'un événement est garantie comme non bloquante: elle ne provoque pas d'attente.
5. Nous fournissons lots des outils pour le traitement de trace ETW. notamment les outils de Xperf (link, link, link)

Un grand avantage de instrumentant vos chemins de performance avec des événements ETW est que vos événements peuvent être vu une seule pièce avec les événements du noyau à l'aide des outils de Xperf.

Il est également très facile d'écrire une application 'watch' qui surveille les événements ETW de vos composants. J'en ai un pour un de nos composants qui affiche simplement les événements sur la console.

I hautement recommandé recommandé de ne pas essayer et d'écrire votre propre système d'enregistrement haute performance. C'est difficile de bien faire, mais en termes de performance et de fiabilité. Le système Windows ETW est super-robuste et très performant.

Answer 2

Retour à l'essentiel - des préoccupations distinctes.

Ma solution habituelle serait d'utiliser les bibliothèques Microsoft Enterprise pour gérer la journalisation réelle; J'utiliserais une base de données comme référentiel, vous pourrez ensuite l'interroger à volonté, à partir de n'importe quelle application (votre existante ou quelque chose de totalement autonome). La chose que j'aime à propos de MS Ent Libs est que vous pouvez les configurer pour se connecter à une grande variété de types de référentiels. Vous pourriez les prolonger avec le cas échéant; Je ne suis pas sûr si vous voulez travailler de manière asynchrone pour les contraintes de performance/d'exécution. Je préfère la journalisation à une base de données car elle donne un bon niveau de contrôle: il est facile à interroger et assez facile à mamager les données. Ayant dia que les Lib Lib permettent la journalisation basée sur les fichiers - ce qui vous aiderait à gérer la taille des fichiers - mais utiliser un Db serait plus rapide que de lire un fichier. Je suppose que cela se résume à ce que vous entendez par "en temps réel" pour savoir si la journalisation sur une base de données serait assez rapide.- temps réel à un ordinateur est très différent de temps réel à une personne.

Vous pouvez vous connecter à la mémoire, puis parcourir de manière asynchrone ces entrées de journal et les enregistrer dans le journal de consignation (DB). Pour la création de rapports, vous pouvez utiliser la copie en mémoire pour afficher l'état «actuel» et vous reporter à la base de données pour des périodes plus longues ou plus longues dans le passé le plus lointain.