Aspnetcore: EventSource؟ مصدر التشخيص؟ كلاهما؟
أرى مشكلات تم فتحها بواسطة anurse عبر عدة EventSource (مثل https://github.com/aspnet/Security/issues/1518 على سبيل المثال) ، ولكن لا يوجد نشاط فعلي حتى الآن ؛ لا يوجد أثر لـ EventSource في أي مكان في MVC.
لقد كنت أكتب مجموعة من التعليمات البرمجية لاستهلاك DiagnosticSource التتبع باستخدام عناصر Activity مؤخرًا ، لذلك كنت آمل نوعًا ما أن تضيف تلك المستودعات نفسها دعمًا DiagnosticSource .
هل هناك خطة طويلة الأجل لدعم أحدهما على الآخر؟ يبدو أنهم يفعلون نفس الشيء. من الواضح أنه على نظام التشغيل Windows EventSource يكتب إلى ETW ، بينما في Linux أعتقد أنه قيد التنفيذ؟
أي دليل سيكون محل تقدير.
markrendle
ال 3 كومينتر
rynowak - هل لدينا إرشادات حول هذا يمكننا مشاركتها؟
Eilon
في ١٠ يناير ٢٠١٨
بعض الأفكار السريعة التي كررتها عدة مرات داخليًا ، لكني لست متأكدًا منها خارجيًا ...
EventSource
افترض أن أي استخدام لـ EventSource يعني أيضًا استخدام آلية تسجيل خارج العملية مثل LTTNG أو ETW. يعد EventSource أمرًا رائعًا عندما تريد إطلاق بعض نقاط البيانات بمعلومات منخفضة الدقة ليتم النظر إليها لاحقًا ، وعلى الأرجح يتم تجميعها في نوع من الإحصائيات أو الملخص. أقول دقة منخفضة لأن الاستخدام الشائع لـ EventSource هو توجيه الأحداث إلى ملف (ETW) ثم استخدامها لإجراء تحليل ما بعد الوفاة. الأدوات التي تنظر إلى البيانات من EventSource مثل PerfView لها معرفة خاصة ببعض الأحداث (JIT ، GC) ولكن بالنسبة للأحداث التي تكتبها ، فإنها تعرض طريقة عرض عامة. يعمل عرض طريقة عرض عامة أو ملخصات / جداول البيانات لأنها كلها أنواع بسيطة. يمكنك بالطبع إنشاء أدوات متخصصة ، ولكن الحالة الشائعة هي استخدام شيء مثل PerfView.
سيبدو البيان التالي واضحًا ، لكن من المأمول أن يتضح سبب ذكره في غضون لحظة. باستخدام EventSource ، يتم تحديد تفسير الأحداث التي تطلقها مسبقًا. يتم تحديد جميع البيانات التي تريد تسجيلها بواسطة مؤلف المكون ولها معنى ثابت ، وعادة ما يرتبط باسم الحدث. باستخدام EventSource ، غالبًا ما تقول أشياء مثل "قراءة 4096 بايت من البيانات" أو "تحميل الملف في 5.6 مللي ثانية". يمكن تجميع هذه العبارات الصغيرة عن الحقائق في ملخصات مثل "150 مللي ثانية تم إنفاقها في إجراء ملف i / o" أو حفرها تحديدًا إذا كانت القيم المتطرفة.
مصدر التشخيص
افترض أن أي استخدام لـ DiagnosticSource يتم إجراؤه من خلال "مكون إضافي" أو نظام تسجيل آخر يقوم بتقطير بياناتك إلى شذرات ذات معنى. يعتبر DiagnosticSource أمرًا رائعًا عندما تريد تمرير السياق الكامل لحالة التطبيق إلى مستمع وسيضيف هذا المستمع تفسيره الخاص بناءً على الوصول إلى حالة التطبيق. لا يحتوي مصدر التشخيص أيضًا على تنسيق تسجيل أصلي ، ولا يوجد فهم عام لنقاط البيانات الخاصة به (نظرًا لأنها ليست أنواعًا بسيطة في العادة) - فهي تتطلب نظامًا إضافيًا لإنشاء شيء يريد المستخدمون رؤيته.
تميل أحداث DiagnosticSource إلى أن تكون أكثر كثافة وتقول أشياء مثل "أنا على وشك معالجة طلب" أو "اكتشفت استثناءًا تم إلقاؤه بواسطة البرامج الوسيطة". لا تزال هذه بيانات واقعية ، لكن النطاق أكبر بكثير. نظرًا لأن الأدوات لديها إمكانية الوصول إلى سياق غني ، فهي تتمتع بحرية التقاط أي معلومات ذات مغزى وفقًا للسياق. في النهاية ، لم يتم تحديد مجموعة المعلومات التي تم التقاطها بواسطة أداة مثل Application Insights من قبل فريق ASP.NET. نحن نقدم لهم كل السياق الذي لدينا ويلتقطون ما يعتقدون أنه مهم.
يمكنك أيضًا تمرير بيانات DiagnosticSource إلى EventSource عبر جسر. لم أفعل هذا شخصيًا ، لكن يبدو أنني أنوي تجنب مضاعفة مقدار كود التشخيص اللازم في بعض الأماكن. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 لن أفترض أنك ستستخدم DiagnosticSource في جميع نفس الأماكن التي تريدها EventSource. لست متأكدًا من كيفية تنفيذ استراتيجية الاستفادة من ذلك ، لم أجربها.
بالنسبة لنا ، تغيرت هذه المنطقة عدة مرات. بدأنا هنا من خلال الشراكة مع Glimpse ، وفي النهاية دخلنا في شراكة مع Application Insights. على طول الطريق ، تم إنشاء بعض الأشياء الأخرى فوق مصدر التشخيص ، لكنني لست متأكدًا من حالة تلك الأدوات الأخرى في الوقت الحالي.
خططنا
لا يمكنني التحدث إلى الإستراتيجية الأكبر حول EventSource أو DiagnosticSource - لكن يمكنني الإجابة عن رأيي في كل منهما وكيف يرى معظم الفريق نهجنا. لم ننشئ DiagnosticSource كبدائل لـ EventSource. في رأيي أنه يخدم مستهلكًا مختلفًا ومجموعة من السيناريوهات.
نضيف أحداث مصدر التشخيص حيث نعتقد أنها ستضيف الكثير من القيمة. عدد قليل من هؤلاء يقطع شوطًا طويلاً حقًا لأنهم مثل القابلية للتمدد لشخص آخر لبناء التشخيص. أجرؤ على أن الاستضافة لديها ربما 3-5 نقاط مصدر تشخيصية وأن MVC لديها أقرب إلى 10. لست متأكدًا مما إذا كانت هناك أي أماكن نتتبعها حاليًا لإضافة المزيد. إذا كان لدى أي شخص حاجة حقيقية فإننا نعتبرها.
نحن نقوم ببناء مصدر الحدث. هذا شيء يعرفه مهندسو الدعم الميداني لدينا ، وهو بشكل عام جزء مهم من تحليل الأداء للفرق في Microsoft. ما زلنا نحاول حل الفراغ الذي خلفه غياب عدادات الأداء. يعمل فريق .NET على جعل EventCounters (المبنية على EventSource) بدائل مناسبة. السبب الرئيسي للتأخير في استثمار فريق ASP.NET بشكل أكبر في EventSource هو أنه لفترة لم يكن من الواضح ما هي الإستراتيجية لغير Windows. أردنا تجنب بناء شيء إضافي آخر في المستقبل إذا كان ل EventSource لن يكون ذلك لمنصات شىء *. تم توضيح ذلك.
يوجد مستند جيد هنا: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-Diagnosticsourcediagnosticlistener مع بعض الأفكار من بعض الأشخاص الأكثر أهمية مسؤول بشكل وثيق عن الاستراتيجية في هذا المجال.
لك
حسنًا ، يبدو أنه يمكنك فعل الأمرين أو أحدهما. لست على دراية كبيرة بما تعمل عليه ، لذا ما يلي هو بعض النصائح العامة.
أولاً ، فكر في هوية مستهلكك. هل هذا لك (perf) هل هذا لمطوري التطبيقات؟ (تصحيح الأخطاء واستكشاف الأخطاء وإصلاحها) هل هذا لمؤلفي الأدوات؟ هل الأدوات تعمل بعد الوفاة أم داخل التطبيق؟
ثانيًا ، فكر في عدد الأماكن التي تخطط لاستخدامها وأنواع البيانات التي تعتقد أنها ذات مغزى. كيف سيفهم المستهلكون ويفسرون هذه البيانات؟ هل نقاط البيانات الفردية ذات مغزى أم ينبغي تجميع البيانات؟
rynowak
في ٢٢ يناير ٢٠١٨
نقوم بشكل دوري بإغلاق قضايا "المناقشة" التي لم يتم تحديثها منذ فترة طويلة من الزمن.
نأسف إذا تسبب هذا في أي إزعاج. نطلب إذا كنت لا تزال تواجه مشكلة ، فيرجى تسجيل مشكلة جديدة بمعلومات محدثة وسنقوم بالتحقيق في الأمر.
aspnet-hello
في ١١ يوليو ٢٠١٨
القضايا ذات الصلة
ermithun
·
3تعليقات
Kevenvz
·
3تعليقات
aurokk
·
3تعليقات
ipinak
·
3تعليقات
Pixel-Lord
·
3تعليقات
التعليق الأكثر فائدة
بعض الأفكار السريعة التي كررتها عدة مرات داخليًا ، لكني لست متأكدًا منها خارجيًا ...
EventSource
افترض أن أي استخدام لـ EventSource يعني أيضًا استخدام آلية تسجيل خارج العملية مثل LTTNG أو ETW. يعد EventSource أمرًا رائعًا عندما تريد إطلاق بعض نقاط البيانات بمعلومات منخفضة الدقة ليتم النظر إليها لاحقًا ، وعلى الأرجح يتم تجميعها في نوع من الإحصائيات أو الملخص. أقول دقة منخفضة لأن الاستخدام الشائع لـ EventSource هو توجيه الأحداث إلى ملف (ETW) ثم استخدامها لإجراء تحليل ما بعد الوفاة. الأدوات التي تنظر إلى البيانات من EventSource مثل PerfView لها معرفة خاصة ببعض الأحداث (JIT ، GC) ولكن بالنسبة للأحداث التي تكتبها ، فإنها تعرض طريقة عرض عامة. يعمل عرض طريقة عرض عامة أو ملخصات / جداول البيانات لأنها كلها أنواع بسيطة. يمكنك بالطبع إنشاء أدوات متخصصة ، ولكن الحالة الشائعة هي استخدام شيء مثل PerfView.
سيبدو البيان التالي واضحًا ، لكن من المأمول أن يتضح سبب ذكره في غضون لحظة. باستخدام EventSource ، يتم تحديد تفسير الأحداث التي تطلقها مسبقًا. يتم تحديد جميع البيانات التي تريد تسجيلها بواسطة مؤلف المكون ولها معنى ثابت ، وعادة ما يرتبط باسم الحدث. باستخدام EventSource ، غالبًا ما تقول أشياء مثل "قراءة 4096 بايت من البيانات" أو "تحميل الملف في 5.6 مللي ثانية". يمكن تجميع هذه العبارات الصغيرة عن الحقائق في ملخصات مثل "150 مللي ثانية تم إنفاقها في إجراء ملف i / o" أو حفرها تحديدًا إذا كانت القيم المتطرفة.
مصدر التشخيص
افترض أن أي استخدام لـ DiagnosticSource يتم إجراؤه من خلال "مكون إضافي" أو نظام تسجيل آخر يقوم بتقطير بياناتك إلى شذرات ذات معنى. يعتبر DiagnosticSource أمرًا رائعًا عندما تريد تمرير السياق الكامل لحالة التطبيق إلى مستمع وسيضيف هذا المستمع تفسيره الخاص بناءً على الوصول إلى حالة التطبيق. لا يحتوي مصدر التشخيص أيضًا على تنسيق تسجيل أصلي ، ولا يوجد فهم عام لنقاط البيانات الخاصة به (نظرًا لأنها ليست أنواعًا بسيطة في العادة) - فهي تتطلب نظامًا إضافيًا لإنشاء شيء يريد المستخدمون رؤيته.
تميل أحداث DiagnosticSource إلى أن تكون أكثر كثافة وتقول أشياء مثل "أنا على وشك معالجة طلب" أو "اكتشفت استثناءًا تم إلقاؤه بواسطة البرامج الوسيطة". لا تزال هذه بيانات واقعية ، لكن النطاق أكبر بكثير. نظرًا لأن الأدوات لديها إمكانية الوصول إلى سياق غني ، فهي تتمتع بحرية التقاط أي معلومات ذات مغزى وفقًا للسياق. في النهاية ، لم يتم تحديد مجموعة المعلومات التي تم التقاطها بواسطة أداة مثل Application Insights من قبل فريق ASP.NET. نحن نقدم لهم كل السياق الذي لدينا ويلتقطون ما يعتقدون أنه مهم.
يمكنك أيضًا تمرير بيانات DiagnosticSource إلى EventSource عبر جسر. لم أفعل هذا شخصيًا ، لكن يبدو أنني أنوي تجنب مضاعفة مقدار كود التشخيص اللازم في بعض الأماكن. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 لن أفترض أنك ستستخدم DiagnosticSource في جميع نفس الأماكن التي تريدها EventSource. لست متأكدًا من كيفية تنفيذ استراتيجية الاستفادة من ذلك ، لم أجربها.
بالنسبة لنا ، تغيرت هذه المنطقة عدة مرات. بدأنا هنا من خلال الشراكة مع Glimpse ، وفي النهاية دخلنا في شراكة مع Application Insights. على طول الطريق ، تم إنشاء بعض الأشياء الأخرى فوق مصدر التشخيص ، لكنني لست متأكدًا من حالة تلك الأدوات الأخرى في الوقت الحالي.
خططنا
لا يمكنني التحدث إلى الإستراتيجية الأكبر حول EventSource أو DiagnosticSource - لكن يمكنني الإجابة عن رأيي في كل منهما وكيف يرى معظم الفريق نهجنا. لم ننشئ DiagnosticSource كبدائل لـ EventSource. في رأيي أنه يخدم مستهلكًا مختلفًا ومجموعة من السيناريوهات.
نضيف أحداث مصدر التشخيص حيث نعتقد أنها ستضيف الكثير من القيمة. عدد قليل من هؤلاء يقطع شوطًا طويلاً حقًا لأنهم مثل القابلية للتمدد لشخص آخر لبناء التشخيص. أجرؤ على أن الاستضافة لديها ربما 3-5 نقاط مصدر تشخيصية وأن MVC لديها أقرب إلى 10. لست متأكدًا مما إذا كانت هناك أي أماكن نتتبعها حاليًا لإضافة المزيد. إذا كان لدى أي شخص حاجة حقيقية فإننا نعتبرها.
نحن نقوم ببناء مصدر الحدث. هذا شيء يعرفه مهندسو الدعم الميداني لدينا ، وهو بشكل عام جزء مهم من تحليل الأداء للفرق في Microsoft. ما زلنا نحاول حل الفراغ الذي خلفه غياب عدادات الأداء. يعمل فريق .NET على جعل EventCounters (المبنية على EventSource) بدائل مناسبة. السبب الرئيسي للتأخير في استثمار فريق ASP.NET بشكل أكبر في EventSource هو أنه لفترة لم يكن من الواضح ما هي الإستراتيجية لغير Windows. أردنا تجنب بناء شيء إضافي آخر في المستقبل إذا كان ل EventSource لن يكون ذلك لمنصات شىء *. تم توضيح ذلك.
يوجد مستند جيد هنا: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-Diagnosticsourcediagnosticlistener مع بعض الأفكار من بعض الأشخاص الأكثر أهمية مسؤول بشكل وثيق عن الاستراتيجية في هذا المجال.
لك
حسنًا ، يبدو أنه يمكنك فعل الأمرين أو أحدهما. لست على دراية كبيرة بما تعمل عليه ، لذا ما يلي هو بعض النصائح العامة.
أولاً ، فكر في هوية مستهلكك. هل هذا لك (perf) هل هذا لمطوري التطبيقات؟ (تصحيح الأخطاء واستكشاف الأخطاء وإصلاحها) هل هذا لمؤلفي الأدوات؟ هل الأدوات تعمل بعد الوفاة أم داخل التطبيق؟
ثانيًا ، فكر في عدد الأماكن التي تخطط لاستخدامها وأنواع البيانات التي تعتقد أنها ذات مغزى. كيف سيفهم المستهلكون ويفسرون هذه البيانات؟ هل نقاط البيانات الفردية ذات مغزى أم ينبغي تجميع البيانات؟