Aspnetcore: Ereignisquelle? Diagnosequelle? Beide?

@rynowak - haben wir

Ein paar kurze Gedanken, die ich innerlich oft wiederholt habe, aber äußerlich bin ich mir nicht sicher...

Ereignisquelle

Angenommen, jede Verwendung von EventSource impliziert auch die Verwendung eines Out-of-Process-Logging-Mechanismus wie LTTNG oder ETW. EventSource ist großartig, wenn Sie einige Datenpunkte mit Low-Fidelity-Informationen abfeuern möchten, die später betrachtet und wahrscheinlich zu einer Art Statistik oder Zusammenfassung zusammengefasst werden. Ich sage mit niedriger Genauigkeit , weil die gemeinsame Nutzung für Eventsource zu Rohr ist die Ereignisse in eine Datei (ETW) und sie dann postmortale Analyse zu tun verwenden. Tools, die Daten von EventSource wie PerfView betrachten, verfügen über spezielle Kenntnisse einiger Ereignisse (JIT, GC), aber für die Ereignisse, die Sie schreiben, zeigen sie eine generische Ansicht. Das Anzeigen einer generischen Ansicht oder Zusammenfassungen/Tabellen von Daten funktioniert, weil es sich um einfache Typen handelt. Sie können natürlich spezielle Tools erstellen, aber der übliche Fall ist die Verwendung von PerfView.

Die nächste Aussage wird offensichtlich erscheinen, aber mein Grund für diese Erwähnung wird hoffentlich in einem Moment klar. Mit EventSource wird die Interpretation der von Ihnen ausgelösten Ereignisse im Voraus bestimmt. Alle Daten, die Sie aufzeichnen möchten, werden vom Autor der Komponente festgelegt und haben eine feste Bedeutung, die normalerweise mit dem Ereignisnamen verbunden ist. Bei EventSource sagt man oft Dinge wie "4096 Byte Daten lesen" oder "Datei in 5,6ms geladen". Diese kleinen Tatsachenbehauptungen können in Zusammenfassungen wie "150 ms für Datei-I/O" zusammengefasst oder gezielt untersucht werden, wenn es sich um Ausreißer handelt.

Diagnosequelle

Nehmen Sie an, dass jede Verwendung von DiagnosticSource während des Prozesses durch ein 'Plugin' oder ein anderes Protokollierungssystem erfolgt, das Ihre Daten in aussagekräftige Nuggets destilliert. DiagnosticSource ist großartig, wenn Sie den vollständigen Kontext des Anwendungsstatus an einen Listener übergeben möchten und dieser Listener basierend auf dem Zugriff auf den Anwendungsstatus seine eigene Interpretation hinzufügt. DiagnosticSource hat auch kein natives Protokollierungsformat und kein allgemeines Verständnis seiner Datenpunkte (da es sich normalerweise nicht um einfache Typen handelt) - es erfordert ein zusätzliches System, um etwas zu erstellen, das Benutzer sehen möchten.

DiagnosticSource-Ereignisse sind in der Regel umfangreicher und sagen Dinge wie "Ich bin dabei, eine Anfrage zu verarbeiten" oder "Ich habe eine von Middleware ausgelöste Ausnahme abgefangen". Dies sind immer noch Tatsachenbehauptungen, aber der Umfang ist viel größer. Da Tools Zugriff auf reichhaltigen Kontext haben, können sie alle Informationen erfassen, die je nach Kontext sinnvoll sind. Letztendlich wird der Satz von Informationen, der von einem Tool wie Application Insights erfasst wird, nicht vom ASP.NET-Team definiert. Wir stellen ihnen den gesamten Kontext zur Verfügung, den wir haben, und sie erfassen, was sie für wichtig halten.

Sie können DiagnosticSource-Daten auch über eine Bridge an EventSource weiterleiten. Ich habe dies nicht persönlich getan, aber ich möchte anscheinend vermeiden, dass die Menge des erforderlichen Diagnosecodes an einigen Stellen verdoppelt wird . https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 Ich würde nicht davon ausgehen, dass Sie DiagnosticSource in allen gleichen Orten wie EventSource. Ich bin mir nicht sicher, wie sich eine Strategie entwickeln würde, die dies nutzt, ich habe es nicht ausprobiert.

Für uns hat sich dieser Bereich ein paar Mal geändert. Wir begannen hier mit einer Partnerschaft mit Glimpse und kamen schließlich zur Partnerschaft mit Application Insights. Auf dem Weg dorthin wurden einige andere Dinge auf Diagnostic Source aufgebaut, aber ich bin mir nicht sicher, wie der Status dieser anderen Tools derzeit ist.

Unsere Pläne

Ich kann nicht mit der umfassenderen Strategie rund um EventSource oder DiagnosticSource sprechen - aber ich kann beantworten, wie ich von ihnen halte und wie der Großteil des Teams unseren Ansatz sieht. Wir haben DiagnosticSource nicht als Ersatz für EventSource erstellt. Meiner Meinung nach dient es einem anderen Verbraucher und einer Reihe von Szenarien.

Wir fügen Diagnosequellereignisse dort hinzu, wo wir denken, dass es einen großen Mehrwert bringt. Einige davon gehen sehr weit, weil sie wie eine Erweiterbarkeit für andere sind , um Diagnosen zu erstellen. Ich würde wagen, dass das Hosting vielleicht 3-5 diagnostische Quellpunkte hat und MVC näher an 10 hat. Ich bin mir nicht sicher, ob es Orte gibt, an denen wir derzeit weitere hinzufügen. Wenn jemand ein echtes Bedürfnis hat, würden wir es in Betracht ziehen.

Wir bauen eine Ereignisquelle auf. Dies ist etwas, mit dem unsere Außendiensttechniker vertraut sind, und es ist im Allgemeinen ein wichtiger Bestandteil der Leistungsanalyse für Teams bei Microsoft. Wir versuchen immer noch, die Lücke zu schließen, die das Fehlen von Leistungsindikatoren hinterlassen hat. Das .NET-Team arbeitet daran, EventCounter (aufgebaut auf EventSource) als geeigneten Ersatz zu erstellen. Der Hauptgrund für die Verzögerung bei den Investitionen des ASP.NET-Teams in EventSource ist, dass eine Zeit lang nicht klar war, wie die Strategie für Nicht-Windows aussehen würde. Wir wollten den Bau eines weiteren zusätzlichen , was in der Zukunft vermeiden , wenn es nicht für Eventsource * nix - Plattformen werden würde. Das ist geklärt.

Es gibt ein gutes Dokument hier: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener mit einigen Gedanken von einigen Leuten, die mehr sind eng für die Strategie in diesem Bereich verantwortlich.

Für dich

Nun, es klingt so, als ob Sie beides oder beides tun können. Ich bin nicht sehr vertraut mit dem, woran Sie arbeiten, daher sind die folgenden allgemeinen Ratschläge.

Denken Sie zunächst darüber nach, wer Ihr Verbraucher ist. Ist das für Sie? (perf) Ist das für Anwendungsentwickler? (Debugging und Fehlerbehebung) Ist dies für Tool-Autoren? Laufen die Tools postmortal oder in der App?

Zweitens, überlegen Sie, wie viele Orte Sie instrumentieren möchten und welche Art von Daten Ihrer Meinung nach aussagekräftig sind. Wie werden die Verbraucher diese Daten verstehen und interpretieren? Sind die einzelnen Datenpunkte aussagekräftig oder sollten Daten aggregiert werden?

Wir schließen regelmäßig Diskussionsthemen, die über einen langen Zeitraum nicht aktualisiert wurden.

Wir entschuldigen uns, wenn dies zu Unannehmlichkeiten führt. Wenn weiterhin ein Problem auftritt, bitten wir Sie, ein neues Problem mit aktualisierten Informationen zu melden und wir werden es untersuchen.