Aspnetcore: Sumber Acara? Sumber Diagnostik? Kedua?

@rynowak - apakah kami memiliki panduan tentang ini yang dapat kami bagikan?

Beberapa pemikiran cepat yang saya ulangi berkali-kali secara internal, tetapi saya tidak yakin tentang eksternal ...

Sumber Acara

Asumsikan bahwa setiap penggunaan EventSource juga menyiratkan penggunaan mekanisme logging di luar proses seperti LTTNG atau ETW. EventSource sangat bagus ketika Anda ingin mengaktifkan beberapa titik data dengan informasi fidelitas rendah untuk dilihat nanti, dan lebih mungkin dikompilasi menjadi semacam statistik atau ringkasan. Saya katakan kesetiaan rendah karena penggunaan umum untuk EventSource adalah untuk menyalurkan peristiwa ke file (ETW) dan kemudian menggunakannya untuk melakukan analisis postmortem. Alat yang melihat data dari EventSource seperti PerfView memiliki pengetahuan khusus tentang beberapa peristiwa (JIT, GC) tetapi untuk peristiwa yang Anda tulis, mereka menunjukkan tampilan umum. Menampilkan tampilan umum atau ringkasan/tabel data berfungsi karena semuanya bertipe sederhana. Anda tentu saja dapat membuat alat khusus, tetapi kasus yang umum adalah menggunakan sesuatu seperti PerfView.

Pernyataan berikutnya akan tampak jelas, tetapi alasan saya untuk menyebutkannya mudah-mudahan akan menjadi jelas dalam beberapa saat. Dengan EventSource, interpretasi peristiwa yang Anda aktifkan ditentukan sebelumnya. Semua data yang ingin Anda rekam ditentukan oleh pembuat komponen dan memiliki arti yang tetap, biasanya terkait dengan nama peristiwa. Dengan EventSource Anda sering mengatakan hal-hal seperti "membaca 4096 byte data" atau "memuat file dalam 5.6ms". Pernyataan fakta kecil ini dapat dikompilasi menjadi ringkasan seperti "150 ms yang dihabiskan untuk melakukan file i/o" atau dibor secara khusus jika itu adalah outlier.

DiagnostikSumber

Asumsikan bahwa setiap penggunaan DiagnosticSource sedang dilakukan dalam proses oleh 'plugin' atau sistem logging lain yang akan menyaring data Anda menjadi nugget yang berarti. DiagnosticSource sangat bagus ketika Anda ingin meneruskan konteks lengkap status aplikasi ke listener dan listener itu akan menambahkan interpretasi mereka sendiri berdasarkan akses ke status aplikasi. DiagnosticSource juga tidak memiliki format logging asli, dan tidak ada pemahaman umum tentang titik datanya (karena biasanya bukan tipe sederhana) - ini memerlukan sistem tambahan untuk membuat sesuatu yang ingin dilihat pengguna.

Acara DiagnosticSource cenderung lebih tebal dan mengatakan hal-hal seperti "Saya akan memproses permintaan" atau "Saya menangkap pengecualian yang dilemparkan oleh middleware". Ini masih merupakan pernyataan fakta, tetapi cakupannya jauh lebih besar. Karena alat memiliki akses ke konteks yang kaya, mereka bebas untuk menangkap informasi apa pun yang bermakna menurut konteksnya. Pada akhirnya kumpulan informasi yang ditangkap oleh alat seperti Wawasan Aplikasi tidak ditentukan oleh tim ASP.NET. Kami memberi mereka semua konteks yang kami miliki dan mereka menangkap apa yang mereka anggap penting.

Anda juga dapat menyalurkan data DiagnosticSource ke EventSource melalui jembatan. Saya secara pribadi belum melakukan ini, tetapi saya tampaknya bermaksud untuk menghindari menggandakan jumlah kode diagnostik yang diperlukan di beberapa tempat. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 Saya tidak akan berasumsi bahwa Anda akan menggunakan DiagnosticSource di semua tempat yang sama seperti yang Anda lakukan pada EventSource. Saya tidak yakin bagaimana strategi yang memanfaatkan ini akan dimainkan, saya belum mencobanya.

Bagi kami, area ini telah berubah beberapa kali. Kami mulai di sini dengan bermitra dengan Glimpse, kami akhirnya bermitra dengan Wawasan Aplikasi. Sepanjang jalan beberapa hal lain telah dibangun di atas Sumber Diagnostik tetapi saya tidak yakin apa status alat-alat lain itu sekarang.

Rencana Kami

Saya tidak dapat berbicara dengan strategi yang lebih besar seputar EventSource atau DiagnosticSource - tetapi saya dapat menjawab bagaimana pendapat saya tentang mereka dan bagaimana sebagian besar tim memandang pendekatan kami. Kami tidak membuat DiagnosticSource sebagai pengganti EventSource. Dalam pikiran saya, ini melayani konsumen dan serangkaian skenario yang berbeda.

Kami menambahkan peristiwa sumber diagnostik yang menurut kami akan menambah banyak nilai. Beberapa di antaranya berjalan sangat jauh karena mereka seperti ekstensibilitas bagi orang lain untuk membangun diagnostik. Saya berani memastikan bahwa hosting mungkin memiliki 3-5 titik sumber diagnostik dan MVC mendekati 10. Saya tidak yakin apakah ada tempat yang saat ini kami lacak untuk menambahkan lebih banyak. Jika ada yang benar-benar membutuhkan, kami akan mempertimbangkannya.

Kami sedang membangun sumber acara. Ini adalah sesuatu yang akrab dengan teknisi dukungan lapangan kami, dan umumnya merupakan bagian penting dari analisis kinerja untuk tim di Microsoft. Kami masih mencoba untuk memecahkan kekosongan yang ditinggalkan oleh tidak adanya penghitung kinerja. Tim .NET bekerja untuk membuat EventCounters (dibangun di atas EventSource) sebagai pengganti yang sesuai. Alasan utama keterlambatan tim ASP.NET berinvestasi lebih banyak di EventSource adalah karena untuk sementara waktu tidak jelas apa strateginya untuk non-Windows. Kami ingin menghindari membangun hal tambahan lain di masa mendatang jika EventSource tidak cocok untuk platform *nix. Itu sudah dibersihkan.

Ada dokumen bagus di sini: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener dengan beberapa pemikiran dari beberapa orang yang lebih bertanggung jawab atas strategi di bidang ini.

Untukmu

Yah, sepertinya Anda bisa melakukan keduanya atau salah satunya. Saya tidak terlalu paham dengan apa yang sedang Anda kerjakan, jadi berikut ini adalah beberapa saran umum.

Pertama, pikirkan siapa konsumen Anda. Apakah ini untuk Anda? (perf) Apakah ini untuk pengembang aplikasi? (debugging dan pemecahan masalah) Apakah ini untuk pembuat alat? Apakah alat berjalan postmortem atau di dalam aplikasi?

Kedua, pikirkan tentang berapa banyak tempat yang Anda rencanakan untuk diinstrumentasi dan jenis data apa yang menurut Anda bermakna. Bagaimana konsumen memahami dan menafsirkan data ini? Apakah titik data individu bermakna atau haruskah data dikumpulkan?

Kami secara berkala menutup masalah 'diskusi' yang tidak diperbarui dalam jangka waktu yang lama.

Kami mohon maaf jika hal ini menyebabkan ketidaknyamanan. Kami meminta jika Anda masih mengalami masalah, harap catat masalah baru dengan informasi terbaru dan kami akan menyelidikinya.