Aspnetcore: Source de l'événement ? Source de diagnostic ? Tous les deux?

@rynowak - avons-nous des conseils à ce sujet que nous pouvons partager ?

Quelques réflexions rapides que j'ai répétées plusieurs fois en interne, mais je ne suis pas sûr de l'externe...

Source de l'événement

Supposons que toute utilisation d'EventSource implique également l'utilisation d'un mécanisme de journalisation hors processus comme LTTNG ou ETW. EventSource est idéal lorsque vous souhaitez générer des points de données avec des informations de faible fidélité à examiner plus tard, et plus probablement compilées dans une sorte de statistiques ou de résumé. Je dis basse fidélité car l'utilisation courante d'EventSource consiste à rediriger les événements vers un fichier (ETW), puis à les utiliser pour effectuer une analyse post-mortem. Les outils qui examinent les données d'EventSource comme PerfView ont une connaissance particulière de certains événements (JIT, GC) mais pour les événements que vous écrivez, ils affichent une vue générique. L'affichage d'une vue générique ou de résumés/tableaux de données fonctionne car ce sont tous des types simples. Vous pouvez bien sûr créer des outils spécialisés, mais le cas courant consiste à utiliser quelque chose comme PerfView.

La prochaine déclaration va sembler évidente, mais ma raison pour la mentionner deviendra, espérons-le, claire dans un instant. Avec EventSource, l'interprétation des événements que vous déclenchez est déterminée à l'avance. Toutes les données que vous souhaitez enregistrer sont spécifiées par l'auteur du composant et ont une signification fixe, généralement associée au nom de l'événement. Avec EventSource, vous dites souvent des choses comme "lire 4096 octets de données" ou "fichier chargé en 5,6 ms". Ces petites déclarations de faits peuvent être compilées dans des résumés tels que "150 ms passés à faire des E/S de fichiers" ou explorées spécifiquement si elles sont aberrantes.

Source de diagnostic

Supposons que toute utilisation de DiagnosticSource soit effectuée en cours de processus par un « plugin » ou un autre système de journalisation qui va distiller vos données en pépites significatives. DiagnosticSource est idéal lorsque vous souhaitez transmettre le contexte complet de l'état de l'application à un auditeur et que cet auditeur va ajouter sa propre interprétation en fonction de l'accès à l'état de l'application. DiagnosticSource n'a pas non plus de format de journalisation natif, et aucune compréhension générique de ses points de données (car ce ne sont généralement pas des types simples) - il nécessite un système supplémentaire pour créer quelque chose que les utilisateurs veulent voir.

Les événements de DiagnosticSource ont tendance à être plus volumineux et disent des choses comme "Je suis sur le point de traiter une demande" ou "J'ai intercepté une exception levée par un middleware". Ce sont encore des déclarations de fait, mais la portée est beaucoup plus large. Étant donné que les outils ont accès à un contexte riche, ils sont libres de capturer toute information significative en fonction du contexte. En fin de compte, l'ensemble des informations capturées par un outil comme Application Insights n'est pas défini par l'équipe ASP.NET. Nous leur fournissons tout le contexte dont nous disposons et ils capturent ce qu'ils pensent être important.

Vous pouvez également rediriger les données DiagnosticSource vers EventSource via un pont. Je ne l'ai pas personnellement fait, mais je semble vouloir éviter de doubler la quantité de code de diagnostic nécessaire à certains endroits. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 Je ne supposerais pas que vous utiliseriez DiagnosticSource dans tous les mêmes endroits que EventSource. Je ne sais pas comment une stratégie tirant parti de cela se déroulerait, je ne l'ai pas essayée.

Pour nous, ce domaine a changé quelques fois. Nous avons commencé ici en nous associant à Glimpse, nous sommes finalement arrivés à un partenariat avec Application Insights. En cours de route, quelques autres éléments ont été construits sur la source de diagnostic, mais je ne suis pas sûr de l'état actuel de ces autres outils.

Nos plans

Je ne peux pas parler de la stratégie plus large autour d'EventSource ou de DiagnosticSource - mais je peux répondre à ce que je pense d'eux et à la façon dont la plupart de l'équipe considère notre approche. Nous n'avons pas créé DiagnosticSource pour remplacer EventSource. Dans mon esprit, cela sert un consommateur différent et un ensemble de scénarios.

Nous ajoutons des événements de source de diagnostic où nous pensons que cela ajoutera beaucoup de valeur. Quelques-uns d'entre eux vont très loin parce qu'ils sont comme une extensibilité pour que quelqu'un d'autre puisse établir des diagnostics. Je dirais que l'hébergement a peut-être 3 à 5 points de source de diagnostic et MVC en a plus de 10. Je ne sais pas s'il y a des endroits que nous suivons actuellement pour en ajouter d'autres. Si quelqu'un a un besoin réel, nous le considérerons.

Nous sommes en train de créer une source d'événement. C'est quelque chose que nos ingénieurs d'assistance sur le terrain connaissent bien, et c'est généralement une partie importante de l'analyse des performances pour les équipes de Microsoft. Nous essayons toujours de combler le vide laissé par l'absence de compteurs de performances. L'équipe .NET travaille à faire des EventCounters (construits sur EventSource) des remplacements appropriés. La principale raison du retard de l'équipe ASP.NET à investir davantage dans EventSource est que pendant un certain temps, il n'était pas clair quelle serait la stratégie pour les non-Windows. Nous voulions éviter de construire une autre chose supplémentaire à l'avenir si EventSource n'allait être pour les plates - formes * nix. Cela a été éclairci.

Il y a une bonne doc ici : https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener avec quelques réflexions de certaines personnes qui sont plus étroitement responsable de la stratégie dans ce domaine.

Pour toi

Eh bien, il semble que vous puissiez faire les deux ou l'un ou l'autre. Je ne suis pas très familier avec ce sur quoi vous travaillez, donc ce qui suit est un conseil général.

Tout d'abord, pensez à qui est votre consommateur. Est-ce pour vous ? (perf) C'est pour les développeurs d'applications ? (débogage et dépannage) Est-ce pour les auteurs d'outils ? Les outils s'exécutent-ils post-mortem ou à l'intérieur de l'application ?

Deuxièmement, réfléchissez au nombre d'endroits que vous prévoyez d'instrumenter et au type de données que vous pensez avoir du sens. Comment les consommateurs comprendront-ils et interpréteront-ils ces données ? Les points de données individuels sont-ils significatifs ou les données doivent-elles être agrégées ?

Nous fermons périodiquement les problèmes de « discussion » qui n'ont pas été mis à jour depuis longtemps.

Nous nous excusons si cela cause des inconvénients. Nous vous demandons si vous rencontrez toujours un problème, veuillez enregistrer un nouveau problème avec des informations mises à jour et nous enquêterons.