المراقبة والتشخيص

التطبيقات والخدمات الموزعة التي تعمل في السحابة هي بطبيعتها قطع معقدة من البرامج التي تشمل العديد من الأجزاء المتحركة. في بيئة الإنتاج، من المهم أن تكون قادرًا على تتبع الطريقة التي يستفيد بها المستخدمون من نظامك، وتتبع استخدام الموارد، ومراقبة صحة نظامك وأدائه بشكل عام. يمكنك استخدام هذه المعلومات كمساعدة تشخيصية للكشف عن المشكلات وتصحيحها، وأيضا للمساعدة في اكتشاف المشاكل المحتملة ومنع حدوثها.

المراقبة والتشخيص

يمكنك استخدام المراقبة للحصول على نظرة ثاقبة حول مدى أداء النظام. والرصد جزء حاسم في الحفاظ على أهداف جودة الخدمة. تتضمن السيناريوهات الشائعة لجمع بيانات المراقبة ما يلي:

• تأكد من أن النظام لا يزال سليمًا.
• تعقب مدى توفر النظام وعناصر مكونه.
• حافظ على الأداء لضمان عدم انخفاض معدل النقل للنظام بشكل غير متوقع مع زيادة حجم العمل.
• اضمن أن يفي النظام بأي اتفاقيات على مستوى الخدمة (SLAs) المنشأة مع العملاء.
• احمي خصوصية وأمان النظام والمستخدمين وبياناتهم.
• تعقب العمليات التي يتم تنفيذها لأغراض التدقيق أو التنظيم.
• راقب الاستخدام اليومي للنظام وحدد الاتجاهات التي قد تؤدي إلى مشاكل إذا لم تتم معالجتها.
• تعقب المشكلات التي تحدث، من التقرير الأولي إلى تحليل الأسباب المحتملة، والتعديل، وتحديثات البرامج والنشر.
• تتبع العمليات وتصحيح إصدارات البرامج.

تصف الأقسام التالية هذه الخيارات بمزيد من التفصيل. تتم مناقشة المعلومات الخاصة بكل سيناريو بالتنسيق التالي:

1. نظرة عامة موجزة على السيناريو.
2. المتطلبات النموذجية لهذا السيناريو.
3. بيانات الأجهزة الأولية المطلوبة لدعم السيناريو، والمصادر المحتملة لهذه المعلومات.
4. كيف يمكن تحليل هذه البيانات الأولية ودمجها لإنشاء معلومات تشخيصية ذات معنى.

مراقبة السلامة

النظام سليم إذا كان قيد التشغيل وقادر على معالجة الطلبات. الغرض من مراقبة السلامة هو إنشاء لقطة من الصحة الحالية للنظام بحيث يمكنك التحقق من أن جميع مكونات النظام تعمل كما هو متوقع.

متطلبات المراقبة الصحية

يجب تنبيه المشغل بسرعة (في غضون ثوان) إذا اعتبر أي جزء من النظام غير صحي. وينبغي أن يكون المشغل قادراً على التأكد من أجزاء النظام التي تعمل بشكل طبيعي، والأجزاء التي تواجه مشاكل. يمكن تمييز صحة النظام من خلال نظام إشارة المرور:

• أحمر لعدم الصحة (توقف النظام)
• أصفر لصحة جزئية (يعمل النظام بوظائف مخفضة)
• أخضر لصحة كاملة

نظام مراقبة صحية شاملة تمكنك من التنقل للأسفل لعرض الحالة الصحية للأنظمة الفرعية والمكونات. على سبيل المثال، إذا تم تصوير النظام الكلي على أنه سليم جزئياً، فيجب أن يكون المشغل قادراً على التكبير وتحديد الوظائف غير المتوفرة حالياً.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

يمكن إنشاء البيانات الأولية المطلوبة لدعم مراقبة السلامة نتيجة:

• تتبع تنفيذ طلبات المستخدم. يمكن استخدام هذه المعلومات لتحديد الطلبات التي نجحت، والتي فشلت، والمدة التي يستغرقها كل طلب.
• مراقبة المستخدم الاصطناعية . تحاكي هذه العملية الخطوات التي يقوم بها المستخدم وتتبع سلسلة من الخطوات المعرفة مسبقاً. يجب التقاط نتائج كل خطوة.
• تسجيل الاستثناءات والأخطاء والتحذيرات. يمكن التقاط هذه المعلومات نتيجة لعبارات التتبع المضمنة في التعليمات البرمجية للتطبيق، بالإضافة إلى استرداد المعلومات من سجلات الأحداث لأي خدمات يشير إليها النظام.
• مراقبة صحة أي خدمات تابعة لجهة خارجية يستخدمها النظام. قد تتطلب هذه المراقبة استرداد البيانات الصحية التي توفرها هذه الخدمات وتحليلها. قد تأخذ هذه المعلومات مجموعة متنوعة من التنسيقات.
• مراقبة نقطة النهاية. يتم وصف هذه الآلية بمزيد من التفصيل في قسم "مراقبة التوافر".
• جمع معلومات الأداء المحيطة، مثل استخدام وحدة المعالجة المركزية في الخلفية أو نشاط الإدخال/الإخراج (بما في ذلك الشبكة).

تحليل البيانات الصحية

يتمثل التركيز الأساسي لمراقبة الصحة في الإشارة بسرعة إلى ما إذا كان النظام قيد التشغيل أم لا. يؤدي التحليل الفعّال للبيانات الفورية إلى تشغيل تنبيه إذا تم اكتشاف مكون حرج على أنه غير صحي. (يفشل في الاستجابة لسلسلة متتالية من عمليات اختبار الاتصال، على سبيل المثال.) يمكن للمشغل بعد ذلك اتخاذ الإجراء التصحيحي المناسب.

قد يتضمن النظام الأكثر تقدماً عنصراً تنبؤيًا يقوم بإجراء تحليل بارد على أحمال العمل الأخيرة والحالية. يمكن للتحليل البارد اكتشاف الاتجاهات وتحديد ما إذا كان من المحتمل أن يظل النظام سليماً أو ما إذا كان النظام سيحتاج إلى موارد إضافية. يجب أن يستند هذا العنصر التنبؤي إلى مقاييس الأداء الهامة، مثل:

• معدل الطلبات الموجهة إلى كل خدمة أو نظام فرعي.
• أوقات الاستجابة لهذه الطلبات.
• حجم البيانات المتدفقة من وإلى كل خدمة.

إذا تجاوزت قيمة أي مقياس حداً محدداً، يمكن للنظام رفع تنبيه لتمكين عامل التشغيل أو التحجيم التلقائي (إذا كان متوفراً) من اتخاذ الإجراءات الوقائية اللازمة للحفاظ على صحة النظام. قد تتضمن هذه الإجراءات إضافة موارد، أو إعادة تشغيل خدمة واحدة أو أكثر من الخدمات التي فشلت، أو تطبيق التقييد على طلبات ذات أولوية أقل.

مراقبة التوفر

يتطلب النظام السليم حقاً توفر المكونات والأنظمة الفرعية التي تشكل النظام. ترتبط مراقبة التوفر ارتباطاً وثيقاً بالمراقبة الصحية. ولكن في حين أن الرصد الصحي يوفر نظرة فورية على الصحة الحالية للنظام، فإن رصد التوافر يهتم بتتبع توافر النظام ومكوناته لإنشاء إحصاءات حول وقت تشغيل النظام.

في العديد من الأنظمة، يتم تكوين بعض المكونات (مثل قاعدة البيانات) مع التكرار المضمن للسماح بتجاوز الفشل السريع في حالة حدوث خطأ خطير أو فقدان الاتصال. من الناحية المثالية، يجب ألا يدرك المستخدمون أن مثل هذا الفشل قد حدث. ولكن من منظور مراقبة التوفر، من الضروري جمع أكبر قدر ممكن من المعلومات حول مثل هذه الإخفاقات لتحديد السبب واتخاذ إجراءات تصحيحية لمنعها من التكرار.

قد تعتمد البيانات المطلوبة لتعقب التوفر على عدد من العوامل ذات المستوى الأدنى. قد تكون العديد من هذه العوامل خاصة بالتطبيق والنظام والبيئة. يلتقط نظام المراقبة الفعال بيانات التوفر التي تتوافق مع هذه العوامل منخفضة المستوى ثم يجمعها لإعطاء صورة شاملة للنظام. على سبيل المثال، في نظام التجارة الإلكترونية، قد تعتمد وظائف الأعمال التي تمكن العميل من تقديم الطلبات على المستودع حيث يتم تخزين تفاصيل الطلب ونظام الدفع الذي يتعامل مع المعاملات النقدية لدفع هذه الطلبات. ومن ثم فإن توفر جزء إيداع الطلبات في النظام هو دالة لتوافر المستودع والنظام الفرعي للدفع.

متطلبات مراقبة التوفر

يجب أن يكون المشغل قادراً أيضاً على عرض التوفر التاريخي لكل نظام ونظام فرعي، واستخدام هذه المعلومات لاكتشاف أي اتجاهات قد تتسبب في فشل نظام فرعي واحد أو أكثر بشكل دوري. (هل تبدأ الخدمات في الفشل في وقت معين من اليوم يتوافق مع ساعات ذروة المعالجة؟)

وينبغي أن يوفر حل الرصد عرضاً فورياً وتاريخياً لتوافر كل نظام فرعي أو عدم توفره. كما يجب أن تكون قادرة على تنبيه عامل التشغيل بسرعة عند فشل خدمة واحدة أو أكثر أو عندما لا يتمكن المستخدمون من الاتصال بالخدمات. هذه ليست مسألة مراقبة كل خدمة فحسب، ولكن أيضاً فحص الإجراءات التي ينفذها كل مستخدم إذا فشلت هذه الإجراءات عند محاولة الاتصال بخدمة. إلى حد ما، درجة من فشل الاتصال أمر طبيعي وقد يكون بسبب أخطاء عابرة. ولكن قد يكون من المفيد السماح للنظام برفع تنبيه لعدد حالات فشل الاتصال إلى نظام فرعي محدد يحدث خلال فترة معينة.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

كما هو الحال مع مراقبة السلامة، يمكن إنشاء البيانات الأولية المطلوبة لدعم مراقبة التوفر نتيجة لمراقبة المستخدم الاصطناعي وتسجيل أي استثناءات وأخطاء وتحذيرات قد تحدث. بالإضافة إلى ذلك، يمكن الحصول على بيانات التوفر من إجراء مراقبة نقطة النهاية. يمكن أن يعرض التطبيق نقطة نهاية صحية واحدة أو أكثر، كل اختبار الوصول إلى منطقة وظيفية داخل النظام. يمكن لنظام المراقبة اختبار اتصال كل نقطة نهاية باتباع جدول زمني محدد وجمع النتائج (النجاح أو الفشل).

يجب تسجيل جميع المهلات وفشل اتصال الشبكة ومحاولات إعادة محاولة الاتصال. يجب أن تكون جميع البيانات في الوقت المحدد.

تحليل بيانات التوفر

يجب تجميع بيانات الأجهزة وربطها لدعم أنواع التحليل التالية:

• التوفر الفوري للنظام والأنظمة الفرعية.
• معدلات فشل التوفر للنظام والأنظمة الفرعية. من الناحية المثالية، يجب أن يكون المشغل قادراً على ربط حالات الفشل بأنشطة محددة: ماذا كان يحدث عندما فشل النظام?
• عرض تاريخي لمعدلات فشل النظام أو أي أنظمة فرعية عبر أي فترة محددة، والحمل على النظام (عدد طلبات المستخدم، على سبيل المثال) عند حدوث فشل.
• أسباب عدم توفر النظام أو أي أنظمة فرعية. على سبيل المثال، قد تكون الأسباب هي عدم تشغيل الخدمة، فقدان الاتصال، الاتصال ولكن التوقيت خارج، والاتصال ولكن إرجاع الأخطاء.

يمكنك حساب النسبة المئوية لتوفر الخدمة على مدى فترة زمنية باستخدام الصيغة التالية:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

وهذا مفيد لأغراض اتفاقية مستوى الخدمة. (يتم وصف مراقبة اتفاقية مستوى الخدمة بمزيد من التفصيل لاحقا في هذا التوجيه.) يعتمد تعريف وقت التعطل على الخدمة. على سبيل المثال، تعرف خدمة إنشاء خدمات الفريق Visual Studio وقت التعطل على أنه الفترة (إجمالي الدقائق المتراكمة) التي لا تتوفر خلالها خدمة الإنشاء. تعتبر الدقيقة غير متوفرة إذا كانت جميع طلبات HTTP المستمرة إلى Build Service لتنفيذ العمليات التي بدأها العميل طوال الدقيقة إما أن تؤدي إلى رمز خطأ أو لا ترجع استجابة.

مراقبة الأداء

مع وضع النظام تحت ضغط متزايد (عن طريق زيادة حجم المستخدمين)، يزداد حجم مجموعات البيانات التي يصل إليها هؤلاء المستخدمون، ويصبح احتمال فشل مكون واحد أو أكثر احتمالاً. في كثير من الأحيان، يسبق فشل المكون انخفاض في الأداء. إذا كنت قادراً على اكتشاف مثل هذا الانخفاض، يمكنك اتخاذ خطوات استباقية لمعالجة الموقف.

التكلفة الإجمالية تعتمد على عدد من العوامل. يتم قياس كل عامل عادة من خلال مؤشرات الأداء الرئيسية (KPIs)، مثل عدد معاملات قاعدة البيانات في الثانية أو حجم طلبات الشبكة التي يتم صيانتها بنجاح في إطار زمني محدد. قد تكون بعض مؤشرات الأداء الرئيسية هذه متاحة كمقاييس أداء محددة، في حين أن البعض الآخر قد يكون مشتقاً من مجموعة من المقاييس.

متطلبات مراقبة الأداء

لفحص أداء النظام، يحتاج عامل التشغيل عادةً إلى رؤية المعلومات التي تتضمن:

• معدلات الاستجابة لطلبات المستخدم.
• قم بزيادة عدد الطلبات المتزامنة.
• حجم حركة مرور الشبكة.
• المعدلات التي يتم بها إكمال المعاملات التجارية.
• متوسط وقت معالجة الطلبات.

قد يكون من المفيد أيضاً توفير الأدوات التي تمكن عامل التشغيل من المساعدة في اكتشاف الارتباطات، مثل:

• عدد المستخدمين المتزامنين مقابل أوقات زمن انتقال الطلب (المدة التي يستغرقها بدء معالجة الطلب بعد إرسال المستخدم له).
• عدد المستخدمين المتزامنين مقابل متوسط وقت الاستجابة (المدة التي يستغرقها إكمال الطلب بعد بدء المعالجة).
• حجم الطلبات مقابل عدد أخطاء المعالجة.

إلى جانب هذه المعلومات الوظيفية عالية المستوى، يجب أن يكون المشغل قادراً على الحصول على عرض مفصل للأداء لكل مكون في النظام. يتم توفير هذه البيانات عادةً من خلال عدادات الأداء منخفضة المستوى التي تتعقب المعلومات مثل:

• استخدام الذاكرة.
• عدد المواضيع.
• وقت معالجة وحدة المعالجة المركزية.
• طلب طول قائمة الانتظار.
• معدلات إدخال/إخراج القرص أو الشبكة والأخطاء.
• عدد البايت المكتوبة.
• مؤشرات البرامج الوسيطة، مثل طول قائمة الانتظار.

يجب أن تسمح جميع المرئيات للمشغل بتحديد فترة زمنية. قد تكون البيانات المعروضة لقطة للحالة الحالية و/أو طريقة عرض تاريخية للأداء.

يجب أن يكون عامل التشغيل قادراً على رفع تنبيه استناداً إلى أي مقياس أداء لأي قيمة محددة خلال أي فاصل زمني محدد.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

يمكنك جمع بيانات عالية المستوى (معدل النقل، وعدد المستخدمين المتزامنين، وعدد المعاملات التجارية، ومعدلات الخطأ، وما إلى ذلك) من خلال مراقبة تقدم طلبات المستخدمين عند وصولهم وتمريرهم عبر النظام. يتضمن ذلك دمج عبارات التتبع في النقاط الرئيسية في التعليمات البرمجية للتطبيق، بالإضافة إلى معلومات التوقيت. يجب التقاط جميع الأخطاء والاستثناءات والتحذيرات ببيانات كافية لربطها بالطلبات التي تسببت فيها. يعد سجل خدمات معلومات الإنترنت (IIS) مصدرا مفيدا آخر.

إذا كان ذلك ممكناً، يجب عليك أيضاً التقاط بيانات الأداء لأي أنظمة خارجية يستخدمها التطبيق. قد توفر هذه الأنظمة الخارجية عدادات الأداء الخاصة بها أو ميزات أخرى لطلب بيانات الأداء. إذا لم يكن ذلك ممكناً، فقم بتسجيل معلومات مثل وقت البدء ووقت الانتهاء لكل طلب يتم إجراؤه على نظام خارجي، بالإضافة إلى حالة (نجاح العملية أو فشلها أو تحذيرها). على سبيل المثال، يمكنك استخدام نهج ساعة الإيقاف لطلبات الوقت: بدء مؤقت عند بدء الطلب ثم إيقاف المؤقت عند انتهاء الطلب.

قد تتوفر بيانات الأداء منخفضة المستوى للمكونات الفردية في النظام من خلال الميزات والخدمات مثل عدادات الأداء Windows وتشخيص Azure.

تحليل بيانات أداء الاستعلام

يتكون جزء كبير من عمل التحليل من تجميع بيانات الأداء حسب نوع طلب المستخدم و/أو النظام الفرعي أو الخدمة التي يتم إرسال كل طلب إليها. مثال على طلب المستخدم هو إضافة عنصر إلى عربة التسوق أو تنفيذ عملية السداد مع الخروج في نظام التجارة الإلكترونية.

من المتطلبات الشائعة الأخرى تلخيص بيانات الأداء في النسب المئوية المحددة. على سبيل المثال، قد يحدد عامل التشغيل أوقات الاستجابة ل 99 بالمائة من الطلبات و95 بالمائة من الطلبات و70 بالمائة من الطلبات. قد تكون هناك أهداف SLA أو أهداف أخرى محددة لكل قيمة مئوية. وينبغي الإبلاغ عن النتائج الجارية في الوقت الفعلي تقريبا للمساعدة في الكشف عن المشكلات الفورية. وينبغي أيضاً تجميع النتائج على مدى فترة أطول لأغراض إحصائية.

في حالة مشكلات زمن الانتقال التي تؤثر على الأداء، يجب أن يكون المشغل قادرا على تحديد سبب الازدحام بسرعة عن طريق فحص زمن الانتقال لكل خطوة ينفذها كل طلب. لذلك يجب أن توفر بيانات الأداء وسيلة لربط مقاييس الأداء لكل خطوة لربطها بطلب معين.

اعتمادا على متطلبات المرئيات، قد يكون من المفيد إنشاء وتخزين مكعب بيانات يحتوي على طرق عرض البيانات الأولية. يمكن أن يسمح مكعب البيانات هذا بالاستعلام المخصص المعقد وتحليل معلومات الأداء.

مراقبه الأمان

يجب أن تنفذ جميع الأنظمة التجارية التي تتضمن بيانات حساسة بنية أمنية. عادة ما يكون تعقيد آلية الأمان دالة على حساسية البيانات. في نظام يتطلب مصادقة المستخدمين، يجب عليك تسجيل:

• جميع محاولات تسجيل الدخول، سواء فشلت أو نجحت.
• جميع العمليات التي يتم تنفيذها بواسطة المستخدم المصادق عليه وتفاصيل جميع الموارد التي يتم الوصول إليها من قبل.
• عندما يقوم مستخدم بإنهاء جلسة عمل وتسجيل الخروج.

قد تكون المراقبة قادرة على المساعدة في اكتشاف الهجمات على النظام. على سبيل المثال، قد يشير عدد كبير من محاولات تسجيل الدخول الفاشلة إلى هجوم بالقوة الغاشمة. قد يكون الارتفاع غير المتوقع في الطلبات نتيجة لهجوم موزع لقطع الخدمة (DDoS). يجب أن تكون مستعداً لمراقبة جميع الطلبات إلى جميع الموارد بغض النظر عن مصدر هذه الطلبات. قد يعرض النظام الذي يحتوي على ثغرة أمنية في تسجيل الدخول الموارد إلى العالم الخارجي عن طريق الخطأ دون مطالبة المستخدم بتسجيل الدخول فعلياً.

متطلبات مراقبة الأمان

يجب أن تمكن الجوانب الأكثر أهمية لمراقبة الأمان عامل التشغيل من:

• الكشف عن محاولات الاختراق من قبل كيان غير مصادق عليه.
• تحديد المحاولات التي تقوم بها الكيانات لتنفيذ عمليات على البيانات التي لم يتم منحها حق الوصول إليها.
• تحديد ما إذا كان النظام، أو جزء من النظام، يتعرض لهجوم من الخارج أو داخله. (على سبيل المثال، قد يحاول مستخدم مصادق عليه ضار إسقاط النظام.)

لدعم هذه المتطلبات، يجب إعلام عامل التشغيل إذا:

• يقوم حساب واحد بإجراء محاولات تسجيل دخول فاشلة متكررة خلال فترة محددة.
• يحاول حساب واحد مصادق عليه بشكل متكرر الوصول إلى مورد محظور خلال فترة محددة.
• يحدث عدد كبير من الطلبات غير المصادق عليها أو غير المصرح بها خلال فترة محددة.

يجب أن تتضمن المعلومات المقدمة إلى عامل التشغيل عنوان المضيف للمصدر لكل طلب. إذا كانت انتهاكات الأمان تنشأ بانتظام من نطاق معين من العناوين، فقد يتم حظر هؤلاء المضيفين.

يتمثل أحد الأجزاء الرئيسية في الحفاظ على أمان النظام في القدرة على الكشف بسرعة عن الإجراءات التي تنحرف عن النمط المعتاد. يمكن عرض معلومات مثل عدد طلبات تسجيل الدخول الفاشلة و/أو الناجحة بصريا للمساعدة في اكتشاف ما إذا كان هناك ارتفاع في النشاط في وقت غير عادي. (مثال على هذا النشاط هو المستخدمون الذين يقومون بتسجيل الدخول في الساعة 3:00 صباحا وينفذون عددا كبيرا من العمليات عند بدء يوم عملهم في الساعة 9:00 صباحا). يمكن أيضاً استخدام هذه المعلومات للمساعدة في تكوين التحجيم التلقائي المستند إلى الوقت. على سبيل المثال، إذا لاحظ المشغل أن عددا كبيرا من المستخدمين يسجلون الدخول بانتظام في وقت معين من اليوم، فيمكن للمشغل الترتيب لبدء خدمات مصادقة إضافية للتعامل مع حجم العمل، ثم إيقاف تشغيل هذه الخدمات الإضافية عند مرور الذروة.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

الأمن هو جانب شامل لمعظم الأنظمة الموزعة. من المحتمل أن يتم إنشاء البيانات ذات الصلة في نقاط متعددة في جميع أنحاء النظام. يجب أن تفكر في اعتماد نهج إدارة معلومات الأمان والأحداث (SIEM) لجمع المعلومات المتعلقة بالأمان التي تنتج عن الأحداث التي يثيرها التطبيق ومعدات الشبكة والخوادم وجدران الحماية وبرامج مكافحة الفيروسات وعناصر منع الاختراق الأخرى.

يمكن أن تتضمن مراقبة الأمان بيانات من أدوات ليست جزءاً من تطبيقك. يمكن أن تتضمن هذه الأدوات المساعدة التي تحدد أنشطة فحص المنفذ من قبل الوكالات الخارجية، أو عوامل تصفية الشبكة التي تكشف عن محاولات الحصول على وصول غير مصادق عليه إلى التطبيق والبيانات.

في جميع الحالات، يجب أن تمكن البيانات المجمعة المسؤول من تحديد طبيعة أي هجوم واتخاذ الإجراءات المضادة المناسبة.

تحليل بيانات الأمان

ميزة مراقبة الأمان هي مجموعة متنوعة من المصادر التي تنشأ منها البيانات. غالبا ما تتطلب التنسيقات المختلفة ومستوى التفاصيل تحليلاً معقداً للبيانات الملتقطة لربطها معا في سلسلة متماسكة من المعلومات. وبصرف النظر عن أبسط الحالات (مثل الكشف عن عدد كبير من عمليات تسجيل الدخول الفاشلة، أو المحاولات المتكررة للوصول غير المصرح به إلى الموارد الهامة)، قد لا يكون من الممكن إجراء أي معالجة آلية معقدة لبيانات الأمان. بدلاً من ذلك، قد يكون من الأفضل كتابة هذه البيانات، الطابع الزمني ولكن بخلاف ذلك في شكلها الأصلي، إلى مستودع آمن للسماح بتحليل يدوي للخبراء.

مراقبة اتفاقية مستوى الخدمة

العديد من الأنظمة التجارية التي تدعم دفع العملاء تقدم ضمانات حول أداء النظام في شكل اتفاقيات مستوى الخدمة. بشكل أساسي، تنص اتفاقيات مستوى الخدمة على أن النظام يمكنه التعامل مع حجم محدد من العمل ضمن إطار زمني متفق عليه ودون فقدان المعلومات الهامة. يتعلق رصد اتفاقية مستوى الخدمة بضمان قدرة النظام على تلبية اتفاقيات مستوى الخدمة القابلة للقياس.

غالباً ما يتم تعريف اتفاقيات مستوى الخدمة من حيث:

• توفر النظام بشكل عام. على سبيل المثال، قد تضمن المؤسسة توفر النظام بنسبة 99.9 في المائة من الوقت. وهذا يعادل ما لا يزيد عن 9 ساعات من وقت التعطل في السنة، أو ما يقرب من 10 دقائق في الأسبوع.
• معدل النقل التشغيلي. غالبا ما يتم التعبير عن هذا الجانب كعلامات واحدة أو أكثر من علامات المياه العالية، مثل ضمان أن النظام يمكنه دعم ما يصل إلى 100,000 طلب مستخدم متزامن أو التعامل مع 10,000 معاملة تجارية متزامنة.
• وقت الاستجابة التشغيلية. وقد يقدم النظام أيضاً ضمانات لمعدل معالجة الطلبات. مثال على ذلك هو أن 99 في المئة من جميع المعاملات التجارية سوف تنتهي في غضون ثانيتين، ولن تستغرق أي معاملة واحدة أكثر من 10 ثوان.

متطلبات مراقبة اتفاقية مستوى الخدمة

على أعلى مستوى، يجب أن يكون المشغل قادراً على تحديد ما إذا كان النظام تلبية اتفاقيات مستوى الخدمة المتفق عليها أم لا في لمحة. وإذا لم يكن الأمر كما هو، يجب أن يكون المشغل قادراً على التنقل لأسفل وفحص العوامل الأساسية لتحديد أسباب الأداء دون المستوى.

تتضمن المؤشرات النموذجية عالية المستوى التي يمكن تصويرها بصرياً ما يلي:

• النسبة المئوية لوقت تشغيل الخدمة.
• معدل نقل التطبيق (يقاس من حيث المعاملات الناجحة و/أو العمليات في الثانية).
• عدد طلبات التطبيق الناجحة/الفاشلة.
• عدد أخطاء التطبيق والنظام والاستثناءات والتحذيرات.

وينبغي أن تكون جميع هذه المؤشرات قادرة على التصفية حسب فترة زمنية محددة.

من المحتمل أن يتكون تطبيق السحابة من عدد من الأنظمة الفرعية والمكونات. يجب أن يكون عامل التشغيل قادراً على تحديد مؤشر عالي المستوى ومعرفة كيفية تكوينه من صحة العناصر الأساسية. على سبيل المثال، إذا كان وقت تشغيل النظام الإجمالي أقل من قيمة مقبولة، يجب أن يكون عامل التشغيل قادرا على التكبير وتحديد العناصر التي تساهم في هذا الفشل.

لأغراض التنبيه، يجب أن يكون النظام قادراً على رفع حدث إذا تجاوز أي من المؤشرات عالية المستوى حداً محدداً. وينبغي أن تكون التفاصيل ذات المستوى الأدنى لمختلف العوامل التي تشكل المؤشر الرفيع المستوى متاحة كبيانات سياقية لنظام التنبيه.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

البيانات الأولية المطلوبة لدعم مراقبة اتفاقية مستوى الخدمة مشابهة للبيانات الأولية المطلوبة لمراقبة الأداء، جنباً إلى جنب مع بعض جوانب مراقبة الصحة والتوافر. (راجع هذه الأقسام لمزيد من التفاصيل.) يمكنك التقاط هذه البيانات من خلال:

• تنفيذ مراقبة نقطة النهاية.
• تسجيل الاستثناءات والأخطاء والتحذيرات.
• تتبع تنفيذ طلبات المستخدم.
• مراقبة توفر أي خدمات تابعة لجهة خارجية يستخدمها النظام.
• استخدام مقاييس الأداء والعدادات.

يجب أن تكون جميع البيانات محددة التوقيت وطوابع زمنية.

تحليل بيانات اتفاقية مستوى الخدمة

يجب تجميع بيانات الأجهزة لإنشاء صورة للأداء العام للنظام. يجب أن تدعم البيانات المجمعة أيضا التنقل لأسفل لتمكين فحص أداء الأنظمة الفرعية الأساسية. على سبيل المثال، يجب أن تكون قادراً على:

• حساب العدد الإجمالي لطلبات المستخدم خلال فترة محددة وتحديد معدل نجاح هذه الطلبات وفشلها.
• اجمع بين أوقات الاستجابة لطلبات المستخدم لإنشاء عرض شامل لأوقات استجابة النظام.
• تحليل تقدم طلبات المستخدم لتقسيم وقت الاستجابة الإجمالي للطلب إلى أوقات الاستجابة لعناصر العمل الفردية في هذا الطلب.
• تحديد التوفر الإجمالي للنظام كنسبة مئوية من وقت التشغيل لأي فترة محددة.
• تحليل النسبة المئوية لتوفر الوقت للمكونات والخدمات الفردية في النظام. قد يتضمن ذلك تحليل السجلات التي أنشأتها خدمات الجهات الخارجية.

وهناك حاجة إلى العديد من النظم التجارية للإبلاغ عن أرقام الأداء الحقيقية مقابل اتفاقيات مستوى الخدمة المتفق عليها لفترة محددة، عادة ما تكون شهر. يمكن استخدام هذه المعلومات لحساب الأرصدة أو أشكال أخرى من السداد للعملاء إذا لم يتم استيفاء اتفاقيات مستوى الخدمة خلال تلك الفترة. يمكنك حساب توفر خدمة باستخدام التقنية الموضحة في القسم تحليل بيانات التوفر.

لأغراض داخلية، قد تتعقب المؤسسة أيضاً عدد وطبيعة الحوادث التي تسببت في فشل الخدمات. Learning كيفية حل هذه المشكلات بسرعة، أو القضاء عليها تماماً، سيساعد على تقليل وقت التعطل وتلبية اتفاقيات مستوى الخدمة.

التدقيق

اعتماداً على طبيعة التطبيق، قد تكون هناك لوائح قانونية أو غيرها من اللوائح القانونية التي تحدد متطلبات مراجعة عمليات المستخدمين وتسجيل جميع الوصول إلى البيانات. يمكن أن يوفر التدقيق دليلاً يربط العملاء بطلبات محددة. يُعد تأكيد الصلاحية عاملاً مهمًا في العديد من أنظمة الأعمال عبر الإنترنت للمساعدة في الحفاظ على الثقة بين العميل والأعمال المسؤولة عن التطبيق أو الخدمة.

متطلبات التدقيق

يمكن للمحلل تتبع تسلسل العمليات التجارية التي يقوم بها المستخدمون بحيث يمكنك إعادة إنشاء إجراءات المستخدمين. قد يكون تتبع تسلسل العمليات ضروريًا كمسألة تسجيل، أو كجزء من تحقيق الطب الشرعي.

تعد معلومات التدقيق حساسة للغاية. من المحتمل أن تتضمن البيانات التي تحدد مستخدمي النظام، جنباً إلى جنب مع المهام التي يقومون بتنفيذها. ولهذا السبب، من المرجح أن تتخذ معلومات التدقيق شكل تقارير لا تتوفر إلا للمحللين الموثوق بهم بدلاً من أن تكون نظاماً تفاعلياً يدعم التنقل لأسفل في العمليات الرسومية. يجب أن يكون المحلل قادراً على إنشاء مجموعة من التقارير. على سبيل المثال، قد تسرد التقارير جميع أنشطة المستخدمين التي تحدث خلال إطار زمني محدد، أو تفصل ترتيب النشاط لمستخدم واحد، أو تسرد تسلسل العمليات التي يتم إجراؤها مقابل مورد واحد أو أكثر.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

ويمكن أن تشمل المصادر الرئيسية لمعلومات مراجعة الحسابات ما يلي:

• نظام الأمان الذي يدير مصادقة المستخدم.
• سجلات التتبع التي تسجل نشاط المستخدم.
• سجلات الأمان التي تتبع كافة متطلبات الشبكة.

قد يكون تنسيق بيانات التدقيق والطريقة التي يتم تخزينها بها مدفوعاً بالمتطلبات التنظيمية. على سبيل المثال، قد لا يكون من الممكن تنظيف البيانات بأي شكل من الأشكال. (يجب تسجيله بتنسيقه الأصلي.) يجب حماية الوصول إلى المستودع حيث يحتفظ به لمنع العبث.

تحليل بيانات التدقيق

يجب أن يكون المحلل قادراً على الوصول إلى البيانات الأولية بالكامل، في شكلها الأصلي. بصرف النظر عن متطلبات تقرير التدقيق المشترك، فإن أدوات تحليل هذه البيانات متخصصة وخارجية عن النظام.

مراقبة الاستخدام

تتعقب مراقبة الاستخدام كيفية استخدام مزايا ومكونات أي تطبيق. يمكن للمشغل استخدام البيانات المجمعة من أجل:

• تحديد الميزات التي تستخدمها بكثرة وتحديد أي نقاط فعالة محتملة في النظام. قد تستفيد عناصر حركة استخدام الشبكة العالية من التقسيم الوظيفي أو حتى النسخ المتماثل لنشر التحميل بشكل متساوي أكثر. يمكن للمشغل أيضاً استخدام هذه المعلومات للتأكد من الميزات التي يتم استخدامها بشكل غير متكرر والمرشحين المحتملين للتقاعد أو الاستبدال في إصدار مستقبلي من النظام.

• جمع معلومات حول الأحداث التشغيلية للنظام في ظل الاستخدام العادي. على سبيل المثال، في موقع التجارة الإلكترونية، يمكنك تسجيل المعلومات الإحصائية حول عدد العمليات وحجم العملاء المسؤولين عنها. يمكن استخدام هذه المعلومات لتخطيط السعة مع زيادة عدد العملاء.

• الكشف (ربما بشكل غير مباشر) عن رضا المستخدم عن أداء أو وظائف النظام. على سبيل المثال، إذا كان عدد كبير من العملاء في نظام تجارة إلكتروني يتخلون بانتظام عن عربات التسوق الخاصة بهم، فقد يعني هذا السلوك وجود مشكلة في وظيفة الدفع.

• إنشاء معلومات الفوترة. قد يفرض تطبيق تجاري أو خدمة متعددة المستأجرين رسوماً على العملاء مقابل الموارد التي يستخدمونها.

• فرض الحصص النسبية. إذا تجاوز المستخدم في نظام متعدد المستأجرين حصته المدفوعة من وقت المعالجة أو استخدام الموارد خلال فترة محددة، يمكن أن يكون وصوله محدوداً أو يمكن تقييد المعالجة.

متطلبات مراقبة الاستخدام

لفحص استخدام النظام، يحتاج عامل التشغيل عادةً إلى رؤية المعلومات التي تتضمن:

• عدد الطلبات التي يقوم كل نظام فرعي بمعالجتها وتوجيهها لكل مورد.
• العمل الذي يقوم به كل مستخدم.
• حجم موقع تخزين البيانات الذي يشغله كل مستخدم.
• الموارد التي يصل إليها كل مستخدم.

يجب أن يكون عامل التشغيل قادراً أيضاً على إنشاء الرسوم البيانية. على سبيل المثال، قد يعرض الرسم البياني المستخدمين الأكثر تعطشاً للموارد، أو الموارد أو ميزات النظام التي يتم الوصول إليها بشكل متكرر.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

يمكن إجراء تتبع الاستخدام على مستوى عال نسبياً. يمكن أن يلاحظ تعقب الاستخدام أوقات بدء ونهاية كل طلب وطبيعة الطلب، مثل القراءة والكتابة وما إلى ذلك، اعتماداً على المورد المعني. يمكنك الحصول على هذه المعلومات عن طريق:

• تتبع نشاط المستخدم.
• تسجيل عدادات الأداء التي تقيس الاستخدام لكل مورد.
• مراقبة استهلاك الموارد من قبل كل مستخدم.

لأغراض القياس، تحتاج أيضاً إلى أن تكون قادراً على تحديد المستخدمين المسؤولين عن تنفيذ العمليات والموارد التي تستخدمها هذه العمليات. يجب أن تكون المعلومات التي تم جمعها مفصلة بما يكفي لإعداد الفواتير الدقيقة.

تعقب المشكلة

قد يقوم العملاء والمستخدمون الآخرون بالإبلاغ عن مشكلات في حالة حدوث أحداث أو سلوك غير متوقع في النظام. يتعلق تعقب المشاكل بإدارة هذه المشكلات، وربطها بالجهود المبذولة لحل أي مشاكل أساسية في النظام، وإعلام العملاء بالحلول المحتملة.

متطلبات لتعقب المشكلة

غالباً ما يقوم المشغلون بتعقب المشكلات باستخدام نظام منفصل يمكنهم من تسجيل تفاصيل المشاكل التي يبلغ عنها المستخدمون والإبلاغ عنها. يمكن أن تتضمن هذه التفاصيل المهام التي كان المستخدم يحاول تنفيذها، وأعراض المشكلة، وتسلسل الأحداث، وأي رسائل خطأ أو تحذير تم إصدارها.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

مصدر البيانات الأولي لبيانات تعقب المشكلة هو المستخدم الذي أبلغ عن المشكلة في المقام الأول. قد يتمكن المستخدم من توفير بيانات إضافية مثل:

• تفريغ الأعطال إذا كان التطبيق يتضمن مكون يعمل على سطح المكتب الخاص بالمستخدم.
• لقطة شاشة.
• تاريخ ووقت حدوث الخطأ، بالإضافة إلى أي معلومات بيئية أخرى مثل موقع المستخدم.

يمكن استخدام هذه المعلومات للمساعدة في جهود تصحيح الأخطاء والمساعدة في إنشاء تراكم للإصدارات المستقبلية من البرنامج.

تحليل بيانات تعقب المشاكل

قد يقوم مستخدمون مختلفون بالإبلاغ عن نفس المشكلة. وينبغي أن يربط نظام تعقب المشكلة بين التقارير الشائعة.

وينبغي تسجيل التقدم المحرز في جهود تصحيح الأخطاء مقابل كل تقرير من تقارير المشكلات. عند حل المشكلة، يمكن إبلاغ العميل بالحل.

إذا قام مستخدم بالإبلاغ عن مشكلة لها حل معروف في نظام تعقب المشكلات، قم بإبلاغ المستخدم بالحل على الفور.

عمليات التتبع وإصدارات برامج تصحيح الأخطاء

عندما يقوم مستخدم بالإبلاغ عن وجود مشكلة، المستخدم غالباً ما يكون على علم فقط بالتأثير الفوري الذي تحدثه المشكلة على عملياته. يمكن للمستخدم فقط الإبلاغ عن نتائج تجربته الخاصة إلى الشخص المسؤول عن صيانة النظام. هذه التجارب هي أحد الأعراض المرئية لواحدة أو أكثر من المشاكل الأساسية. في كثير من الحالات، يجب على المحلل البحث في التسلسل الزمني للعمليات الأساسية لتحديد السبب الأساسي للمشكلة. تسمى هذه العملية تحليل السبب الأساسي.

متطلبات التتبع وتصحيح الأخطاء

لتتبع الأحداث غير المتوقعة والمشاكل الأخرى، من الضروري أن توفر بيانات المراقبة معلومات كافية لتمكين المحلل من تتبع أصول هذه المشكلات وإعادة إنشاء تسلسل الأحداث التي حدثت. يجب أن تكون هذه المعلومات كافية لتمكين المحلل من تشخيص السبب الأساسي لأي مشاكل. يمكن للمطور بعد ذلك إجراء التعديلات اللازمة لمنع تكرارها.

متطلبات مصادر البيانات والأجهزة وجمع البيانات

يمكن أن يتضمن استكشاف الأخطاء وإصلاحها تتبع جميع الطرق (ومعلماتها) التي تم استدعاؤها كجزء من عملية لبناء بنية تصور التدفق المنطقي عبر النظام عندما يقدم العميل طلباً محددا. يجب التقاط الاستثناءات والتحذيرات التي ينشئها النظام نتيجة لهذا التدفق وتسجيلها.

لدعم تصحيح الأخطاء، يمكن للنظام توفير خطافات تمكن المشغل من التقاط معلومات الحالة في نقاط حاسمة في النظام. أو، يمكن للنظام تقديم معلومات مفصلة خطوة بخطوة مع تقدم العمليات المحددة. يمكن أن يفرض التقاط البيانات على هذا المستوى من التفاصيل حملاً إضافياً على النظام ويجب أن يكون عملية مؤقتة. يستخدم عامل التشغيل هذه العملية بشكل رئيسي عندما تحدث سلسلة غير عادية للغاية من الأحداث ويصعب نسخهاً نسخاً متماثلاً، أو عندما يتطلب الإصدار الجديد من عنصر واحد أو أكثر في نظام مراقبة دقيقة للتأكد من أن العناصر تعمل كما هو متوقع.

مسار المراقبة والتشخيص

وتشكل مراقبة نظام موزع على نطاق واسع تحدياً كبيراً. لا ينبغي بالضرورة النظر في كل سيناريو من السيناريوهات الموضحة في القسم السابق بشكل منفصل. من المحتمل أن يكون هناك تداخل كبير في بيانات المراقبة والتشخيص المطلوبة لكل حالة، على الرغم من أن هذه البيانات قد تحتاج إلى المعالجة وتقديمها بطرق مختلفة. لهذه الأسباب، يجب أن تأخذ نظرة شاملة للمراقبة والتشخيص.

يمكنك تصور عملية المراقبة والتشخيص بأكملها كمسار يتضمن المراحل الموضحة في الشكل 1.

الشكل 1 - مراحل مسار المراقبة والتشخيص.

يسلط الشكل 1 الضوء على كيفية الحصول على بيانات المراقبة والتشخيص من مجموعة متنوعة من مصادر البيانات. تهتم مراحل الأجهزة والمجموعة بتحديد المصادر التي تحتاج إلى التقاط البيانات منها، وتحديد البيانات التي يجب التقاطها، وكيفية التقاطها، وكيفية تنسيق هذه البيانات بحيث يمكن فحصها بسهولة. تأخذ مرحلة التحليل/التشخيص البيانات الأولية وتستخدمها لإنشاء معلومات مفيدة يمكن للمشغل استخدامها لتحديد حالة النظام. يمكن للمشغل استخدام هذه المعلومات لاتخاذ قرارات حول الإجراءات المحتملة لاتخاذها، ثم تغذية النتائج مرة أخرى في مراحل تقرير عن حالة النظام والمجموعة. تقدم مرحلة المرئيات/التنبيه طريقة عرض قابلة للاستهلاك لحالة النظام. يمكنه عرض المعلومات في الوقت الفعلي تقريباً باستخدام سلسلة من لوحات المعلومات. ويمكنه إنشاء تقارير ورسوم بيانية ومخططات لتوفير عرض تاريخي للبيانات التي يمكن أن تساعد في تحديد الاتجاهات طويلة الأجل. إذا كانت المعلومات تشير إلى أنه من المحتمل أن يتجاوز مؤشر الأداء الرئيسي الحدود المقبولة، يمكن لهذه المرحلة أيضاً تشغيل تنبيه إلى عامل تشغيل. في بعض الحالات، يمكن أيضاً استخدام تنبيه لتشغيل عملية تلقائية تحاول اتخاذ إجراءات تصحيحية، مثل التحجيم التلقائي.

لاحظ أن هذه الخطوات تشكل عملية تدفق مستمر حيث تحدث المراحل بالتوازي. من الناحية المثالية، يجب أن تكون جميع المراحل قابلة للتكوين ديناميكياً. وفي بعض النقاط، لا سيما عندما يكون النظام قد نشر حديثا أو يواجه مشاكل، قد يكون من الضروري جمع بيانات موسعة على أساس أكثر تواتراً. وفي أوقات أخرى، ينبغي أن يكون من الممكن العودة إلى الحصول على مستوى أساسي من المعلومات الأساسية للتحقق من أن النظام يعمل بشكل صحيح.

بالإضافة إلى ذلك، يجب اعتبار عملية المراقبة بأكملها حلاً مباشراً ومستمراً يخضع للضبط والتحسينات نتيجة للتعليقات. على سبيل المثال، قد تبدأ بقياس العديد من العوامل لتحديد صحة النظام. قد يؤدي التحليل بمرور الوقت إلى تحسين أثناء تجاهل المقاييس غير ذات الصلة، ما يتيح لك التركيز بشكل أكثر دقة على البيانات التي تحتاجها مع تقليل ضوضاء الخلفية.

مصادر بيانات المراقبة والتشخيص

ويمكن أن تأتي المعلومات التي تستخدمها عملية الرصد من عدة مصادر، كما هو موضح في الشكل 1. على مستوى التطبيق، تأتي المعلومات من سجلات التتبع المضمنة في التعليمات البرمجية للنظام. يجب على المطورين اتباع نهج قياسي لتتبع تدفق التحكم من خلال التعليمات البرمجية الخاصة بهم. يمكن لإدخال أسلوب في التطبيق إرسال رسالة تتبع تحدد اسم الأسلوب والوقت الحالي وقيمة كل معلمة وأي معلومات أخرى ذات صلة. يمكن أن يكون تسجيل أوقات الدخول والخروج مفيداً أيضاً.

يجب عليك تسجيل جميع الاستثناءات والتحذيرات، والتأكد من الاحتفاظ بتتبع كامل لأي استثناءات وتحذيرات متداخلة. من الناحية المثالية، يجب عليك أيضًا تسجيل المعلومات التي تحدد المستخدم الذي يقوم بتشغيل التعليمة البرمجية، جنبًا إلى جنب مع معلومات ارتباط النشاط (لتتبع الطلبات أثناء مرورها عبر النظام). ويجب عليك تسجيل محاولات الوصول إلى جميع الموارد مثل قوائم انتظار الرسائل وقواعد البيانات والملفات والخدمات التابعة الأخرى. يمكن استخدام هذه المعلومات لأغراض القياس والتدقيق.

تستخدم العديد من التطبيقات المكتبات وأطر العمل لأداء المهام الشائعة مثل الوصول إلى مخزن البيانات أو الاتصال عبر الشبكة. قد تكون هذه الأطر قابلة للتكوين لتوفير رسائل التتبع الخاصة بها ومعلومات التشخيص الأولية، مثل معدلات المعاملات وحالات نجاح وفشل نقل البيانات.

يمكن أن يكون مصدراً للمعلومات منخفضة المستوى على مستوى النظام، مثل عدادات الأداء التي تشير إلى معدلات الإدخال/الإخراج، واستخدام الذاكرة، واستخدام وحدة المعالجة المركزية. قد يتم أيضاً الإبلاغ عن أخطاء نظام التشغيل (مثل الفشل في فتح ملف بشكلٍ صحيح).

ضع في اعتبارك البنية الأساسية والمكونات الأساسية التي يعمل عليها نظامك. يمكن أن تكون جميع الأجهزة الظاهرية والشبكات الظاهرية وخدمات التخزين مصادر لعدادات أداء مهمة على مستوى البنية الأساسية وبيانات تشخيصية أخرى.

إذا كان تطبيقك يستخدم خدمات خارجية أخرى، مثل خادم ويب أو نظام إدارة قاعدة بيانات، فقد تنشر هذه الخدمات معلومات التتبع والسجلات وعدادات الأداء الخاصة بها. تتضمن الأمثلة طرق عرض الإدارة الديناميكية لـ SQL Server لتتبع العمليات التي يتم إجراؤها على قاعدة بيانات SQL Server وسجلات تتبع IIS لتسجيل الطلبات المقدمة إلى خادم ويب.

نظرًا لتعديل مكونات النظام ونشر إصدارات جديدة، فمن المهم أن تكون قادرًا على إسناد المشكلات والأحداث والمقاييس لكل إصدار. يجب ربط هذه المعلومات مرة أخرى بمسار الإصدار بحيث يمكن تعقب المشاكل مع إصدار معين من مكون بسرعة وتصحيحها.

قد تحدث مشكلات أمنية في أي وقت في النظام. على سبيل المثال، قد يحاول المستخدم تسجيل الدخول باستخدام معرف مستخدم أو كلمة مرور غير صالحة. فقد يحاول المستخدم المصادق عليه الحصول على وصول غير مصرح به إلى أحد الموارد. أو قد يقدم المستخدم مفتاحًا غير صالح أو قديمًا للوصول إلى المعلومات المشفرة. يجب دائما تسجيل المعلومات المتعلقة بالأمان للطلبات الناجحة والفشل.

يحتوي القسم Instrumenting an application على مزيد من الإرشادات حول المعلومات التي يجب التقاطها. ولكن يمكنك استخدام مجموعة متنوعة من الاستراتيجيات لجمع هذه المعلومات:

• مراقبة نظام المعلومات. تستخدم هذه الإستراتيجية مصادر داخلية داخل التطبيق وأطر عمل التطبيق ونظام التشغيل والبنية الأساسية. يمكن للتعليمة البرمجية التطبيق إنشاء بيانات المراقبة الخاصة به في نقاط بارزة أثناء دورة حياة طلب العميل. يمكن أن يتضمن التطبيق عبارات التتبع التي قد يتم تمكينها أو تعطيلها بشكل انتقائي حسب ما تمليه الظروف. فقد يكون من الممكن أيضًا حقن التشخيص بشكل ديناميكي باستخدام إطار عمل التشخيص. عادةً ما توفر هذه الأطر مكونات إضافية يمكن أن ترفق بنقاط أجهزة مختلفة في التعليمات البرمجية الخاصة بك وتسجل بيانات التتبع في هذه النقاط.

  بالإضافة إلى ذلك، قد تثير التعليمات البرمجية و/أو البنية الأساسية الأحداث في نقاط حرجة. يمكن لوكلاء المراقبة الذين تم تكوينهم للاستماع إلى هذه الأحداث تسجيل معلومات الحدث.

• مراقبة حقيقية للمستخدم. يسجل هذا النهج التفاعلات بين المستخدم والتطبيق ويلاحظ تدفق كل طلب واستجابة. يمكن أن يكون لهذه المعلومات غرض مزدوج: يمكن استخدامها لقياس الاستخدام من قبل كل مستخدم، ويمكن استخدامها لتحديد ما إذا كان المستخدمون يتلقون خدمة ذات جودة مناسبة (على سبيل المثال، أوقات الاستجابة السريعة وزمن الاستجابة المنخفض والحد الأدنى من الأخطاء). يمكنك استخدام البيانات التي تم تسجيلها لتحديد مجالات الاهتمام حيث تحدث حالات الفشل في أغلب الأحيان. يمكنك أيضًا استخدام البيانات لتحديد العناصر التي يتباطأ فيها النظام، ربما بسبب النقاط الفعالة في التطبيق أو أي شكل آخر من أشكال الاختناق. ففي حالة تنفيذ هذا الأسلوب بعناية، فقد يكون من الممكن إعادة بناء تدفقات المستخدمين من خلال التطبيق لأغراض التصحيح والاختبار.

  هام

  يجب أن تعتبر البيانات التي يتم تسجيلها من خلال مراقبة المستخدمين الحقيقيين شديدة الحساسية لأنها قد تتضمن مواد سرية. إذا قمت بحفظ البيانات المسجلة، فقم بتخزينها بأمان. إذا كنت ترغب في استخدام البيانات لأغراض مراقبة الأداء أو تصحيح الأخطاء، فقم بإزالة جميع معلومات التعريف الشخصية أولاً.

• مراقبة المستخدم الاصطناعية . في هذا النهج، تكتب عميل الاختبار الخاص بك الذي يحاكي مستخدمًا وينفذ سلسلة عمليات قابلة للتكوين ولكن نموذجية. يمكنك تتبع أداء عميل الاختبار للمساعدة في تحديد حالة النظام. كما يمكنك استخدام مثيلات متعددة لعميل الاختبار كجزء من عملية اختبار الحمل لتحديد كيفية استجابة النظام تحت الضغط ونوع مراقبة المخرجات التي يتم إنشاؤها في ظل هذه الظروف.

  إشعار

  يمكنك تنفيذ مراقبة حقيقية وتركيبية للمستخدم من خلال تضمين التعليمات البرمجية التي تتعقب وأوقات تنفيذ استدعاءات الطريقة والأجزاء المهمة الأخرى من التطبيق.

• جمع المعلومات. يستهدف هذا الأسلوب بشكل أساسي مراقبة أداء التطبيق وتحسينه. بدلاً من العمل على المستوى الوظيفي لمراقبة المستخدم الحقيقية والاصطناعية، فإنه يسجل المعلومات ذات المستوى الأدنى أثناء تشغيل التطبيق. يمكنك تنفيذ التنميط باستخدام أخذ عينات دورية لحالة تنفيذ أحد التطبيقات (تحديد أي جزء من التعليمات البرمجية يقوم التطبيق بتشغيله في وقت معين). يمكنك أيضًا استخدام الأجهزة التي تُدخل المجسات في التعليمة البرمجية عند نقاط التوصيل المهمة (مثل بداية استدعاء الطريقة ونهايتها) وتسجيل الطرق التي تم استدعاءها، وفي أي وقت، والمدة التي استغرقتها كل مكالمة. يمكنك بعد ذلك تحليل هذه البيانات لتحديد أجزاء التطبيق التي قد تسبب مشاكل في الأداء.

• مراقبة نقطة النهاية. تستخدم هذه التقنية واحدة أو أكثر من نقاط النهاية التشخيصية التي يعرضها التطبيق خصيصًا لتمكين المراقبة. توفر نقطة النهاية مسارًا إلى التعليمة البرمجية للتطبيق ويمكنها إرجاع معلومات حول صحة النظام. يمكن أن تركز نقاط النهاية المختلفة على جوانب مختلفة من الوظيفة. يمكنك كتابة عميل التشخيص الخاص بك الذي يرسل طلبات دورية إلى نقاط النهاية هذه واستيعاب الردود. لمزيد من المعلومات، راجع نمط مراقبة نقطة النهاية الصحية.

للحصول على أقصى تغطية، يجب استخدام مزيج من هذه الأساليب.

وضع علامة على تطبيق

يُعد تقرير حالة النظام جزءاً مهماً من عملية المراقبة. لا يمكنك اتخاذ قرارات ذات مغزى بشأن أداء وصحة النظام إلا إذا قمت أولاً بالتقاط البيانات التي تمكنك من اتخاذ هذه القرارات. باستخدام تقرير حالة النظام، يجب أن تكون المعلومات التي تجمعها كافية لتقييم الأداء وتشخيص المشكلات واتخاذ القرارات دون مطالبتك بتسجيل الدخول إلى خادم إنتاج بعيد لإجراء التتبع والتصحيح يدوياً. عادة ما تتضمن بيانات تقرير حالة النظام مقاييس ومعلومات مكتوبة لتتبع السجلات.

يمكن أن تكون محتويات سجل التتبع نتيجة لبيانات نصية يكتبها التطبيق أو بيانات ثنائية تم إنشاؤها نتيجة لحدث تتبع، إذا كان التطبيق يستخدم تتبع الأحداث لـ Windows (ETW). يمكن أيضاً إنشاء محتويات سجل التتبع من سجلات النظام التي تسجل الأحداث الناشئة عن أجزاء من البنية الأساسية، مثل خادم ويب. غالباً ما تُصمم رسائل السجل النصي بحيث يمكن للإنسان قراءتها، ولكن يجب أيضاً كتابتها بتنسيق يمكّن النظام الآلي من تحليلها بسهولة.

يجب عليك أيضاً تصنيف السجلات. لا تكتب جميع بيانات التتبع في سجل واحد، ولكن استخدم سجلات منفصلة لتسجيل إخراج التتبع من جوانب تشغيلية مختلفة للنظام. يمكنك بعد ذلك تصفية رسائل السجل بسرعة من خلال القراءة من السجل المناسب بدلاً من الاضطرار إلى معالجة ملف واحد طويل. عدم كتابة معلومات لها متطلبات أمان مختلفة (مثل معلومات التدقيق وتصحيح الأخطاء) إلى نفس السجل.

ستكون المقاييس عموماً مقياساً أو عدداً لبعض الجوانب أو الموارد في النظام في وقت محدد، مع واحدة أو أكثر من العلامات أو الأبعاد المرتبطة، وتسمى أحياناً عينة. لا يفيد مثيل واحد من القياس بمعزل عن غيره. بدلاً من ذلك، يجب التقاط المقاييس بمرور الوقت. المسألة الرئيسية التي يجب مراعاتها هي المقاييس التي يجب عليك تسجيلها وعدد مرات تكرارها. يمكن أن يؤدي توليد البيانات للمقاييس في كثير من الأحيان إلى فرض عبء إضافي كبير على النظام؛ في حين أن التقاط المقاييس نادراً ما يتسبب في تفويت الظروف التي تؤدي إلى حدث مهم. ستختلف الاعتبارات من قياس إلى قياس. على سبيل المثال، قد يختلف استخدام وحدة المعالجة المركزية على الخادم بشكل كبير بين اللحظة والأخرى، ولكن الاستخدام المرتفع يصبح مشكلة فقط إذا استمر لفترة طويلة على مدار عدة دقائق.

معلومات عن البيانات المترابطة

يمكنك بسهولة مراقبة عدادات الأداء الفردية على مستوى النظام، والتقاط مقاييس للموارد، والحصول على معلومات تتبع التطبيق من ملفات السجل المختلفة. تتطلب بعض أشكال المراقبة مرحلة التحليل والتشخيص في مسار المراقبة لربط البيانات التي يتم استردادها من عدة مصادر. وقد تتخذ هذه البيانات عدة أشكال في البيانات الأولية، ويجب تزويد عملية التحليل ببيانات تقرير حالة النظام الكافية لتعيين هذه الأشكال المختلفة. على سبيل المثال، على مستوى إطار عمل التطبيق، يمكن تحديد مهمة بواسطة معرّف مؤشر الترابط. ضمن أي تطبيق، قد يتم إقران نفس العمل بمعرّف المستخدم للمستخدم الذي يقوم بأداء تلك المهمة.

أيضاً، من غير المحتمل أن يكون تعيين 1:1 بين مؤشرات الترابط وطلبات المستخدم، لأن العمليات غير المتزامنة قد تعيد استخدام نفس مؤشرات الترابط لإجراء عمليات لأكثر من مستخدم واحد. لزيادة تعقيد الأمور، يمكن معالجة طلب واحد من خلال أكثر من مؤشر ترابط واحد بينما يتدفق التنفيذ عبر النظام. إذا كان ذلك ممكناً، فقم بربط كل طلب بمعرّف نشاط فريد يتم نشره عبر النظام كجزء من سياق الطلب. (تعتمد تقنية إنشاء معرّفات الأنشطة وتضمينها في معلومات التتبع على التقنية المُستخدمة لالتقاط بيانات التتبع.)

يجب أن يكون لدى جميع بيانات المراقبة نفس الطابع الزمني. للتناسق، سجل جميع التواريخ والأوقات باستخدام التوقيت العالمي المتفق عليه، ما يساعدك على تتبع تسلسل الأحداث بسهولة. سيساعدك هذا على تتبع تسلسلات الأحداث بسهولة أكبر.

المعلومات التي يجب تضمينها في بيانات تقرير حالة النظام

ضع في اعتبارك النقاط التالية عند تحديد بيانات تقرير حالة النظام التي تحتاج إلى جمعها:

• التأكد من أن المعلومات التي تم التقاطها بواسطة أحداث التتبع يمكن قراءتها آلياً وبشرياً. اعتماد مخططات محددة جيدا لهذه المعلومات للمساعدة في المعالجة الآلية لبيانات السجل عبر الأنظمة، وتوفير الاتساق لموظفي العمليات والمهندسين الذين يقومون بقراءة السجلات. قم بتضمين معلومات بيئية، مثل بيئة النشر والجهاز الذي يتم تشغيل العملية عليه وتفاصيل العملية ومكدس الاستدعاءات.

• تمكين جمع المعلومات فقط عند الضرورة حيث يمكنه فرض حمل كبير على النظام. باستخدام تقرير حالة النظام، يسجل جمع المعلومات حدثاً، مثل استدعاء الأسلوب، في كل مرة يحدث فيها؛ ولكن، أخذ العينات يسجل الأحداث المحددة فقط. يمكن أن يكون التحديد مستنداً إلى الوقت (مرة واحدة كل n ثانية)، أو يستند إلى التردد (مرة واحدة كل n طلبات). إذا كانت الأحداث تحدث بشكل متكرر، فقد يتسبب جمع معلومات بواسطة تقرير حالة النظام في حِمل كبير ما يؤثر على الأداء العام. وفي هذه الحالة، قد يكون نهج أخذ العينات هو الأفضل. ومع ذلك، إذا كان تكرار الأحداث منخفضاً، فقد يفتقدها أخذ العينات. وفي هذه الحالة، قد يكون تقرير حالة النظام هو النهج الأفضل.

• توفير سياق كاف لتمكين المطور أو المسؤول من تحديد مصدر كل طلب. قد يتضمن هذا شكلاً من أشكال معرف النشاط الذي يحدد مثيلاً معينا للطلب. قد يتضمن أيضاً معلومات يمكن استخدامها لربط هذا النشاط بالعمل الحسابي المنجز والموارد المستخدمة. لاحظ أن هذا العمل قد يتجاوز حدود العمليات والجهاز. بالنسبة للقياس، يجب أن يتضمن السياق أيضاً، إما بشكل مباشر أو غير مباشر، من خلال معلومات أخرى مترابطة، إشارة إلى العميل الذي تسبب في الطلب. يوفر هذا السياق معلومات قيمة حول حالة التطبيق في وقت التقاط بيانات المراقبة.

• تسجيل جميع الطلبات والمواقع أو المناطق التي يتم إجراء هذه الطلبات منها. يمكن أن تساعد هذه المعلومات في تحديد ما إذا كانت هناك أي نقاط فعالة خاصة بالموقع. يمكن أن تفيد هذه المعلومات أيضاً في تحديد ما إذا كان سيتم إعادة تقسيم التطبيق أو البيانات التي يستخدمها.

• تسجيل تفاصيل الاستثناءات والتقاطها بعناية. غالباً ما يتم فقدان معلومات التصحيح المهمة بسبب سوء معالجة الاستثناء. التقاط التفاصيل الكاملة للاستثناءات التي يطرحها التطبيق، بما في ذلك أي استثناءات داخلية ومعلومات سياق أخرى. تضمين مكدس الاستدعاءات، إن أمكن.

• كن متسقا في البيانات التي تلتقطها العناصر المختلفة للتطبيق الخاص بك، لأن هذا يمكن أن يساعد في تحليل الأحداث وربطها بطلبات المستخدم. التفكير في استخدام حزمة تسجيل شاملة وقابلة للتكوين لجمع المعلومات، بدلاً من الاعتماد على المطورين لاعتماد نفس النهج أثناء تنفيذهم لأجزاء مختلفة من النظام. جمع البيانات من عدادات الأداء الرئيسية، مثل حجم الإدخال/الإخراج الذي يتم إجراؤه، واستخدام الشبكة، وعدد الطلبات، واستخدام الذاكرة، واستخدام وحدة المعالجة المركزية. قد توفر بعض خدمات البنية الأساسية عدادات أداء محددة خاصة بها، مثل عدد الاتصالات بقاعدة بيانات، ومعدل تنفيذ المعاملات، وعدد المعاملات التي تنجح أو تفشل. قد تحدد التطبيقات أيضاً عدادات الأداء الخاصة بها.

• سجل جميع المكالمات التي يتم إجراؤها على الخدمات الخارجية، مثل أنظمة قواعد البيانات أو خدمات الويب أو الخدمات الأخرى على مستوى النظام التي تعد جزءا من البنية الأساسية. تسجيل معلومات حول الوقت المُستغرَق في إجراء كل استدعاء، ونجاح الاستدعاء أو فشله. إذا كان ذلك ممكناً، التقاط معلومات حول جميع محاولات إعادة المحاولة والفشل لأي أخطاء عابرة تحدث.

ضمان التوافق مع أنظمة بيانات تتبع الاستخدام

وفي كثير من الحالات، يتم توليد معلومات تقرير حالة النظام كسلسلة من الأحداث وتمريرها إلى نظام بيانات تتبع الاستخدام منفصل للمعالجة والتحليل. عادة ما يكون نظام بيانات تتبع الاستخدام مستقلاً عن أي تطبيق أو تقنية محددة، ولكن من المتوقع أن تتبع المعلومات تنسيقاً معيناً يتم تحديده بواسطة مخطط. يحدد المخطط بشكل فعال اتفاقاً يحدد حقول البيانات وأنواعها التي يمكن لنظام بيانات تتبع الاستخدام استيعابها. يجب تعميم المخطط للسماح بوصول البيانات من مجموعة من الأنظمة الأساسية والأجهزة.

يجب أن يتضمن المخطط الشائع الحقول الشائعة في جميع أحداث الأجهزة، مثل اسم الحدث ووقت الحدث وعنوان IP للمرسل والتفاصيل المطلوبة للربط بأحداث أخرى (مثل معرف المستخدم ومعرف الجهاز ومعرف التطبيق). تذكر أن أي عدد من الأجهزة قد يثير الأحداث، لذلك يجب ألا يعتمد المخطط على نوع الجهاز. بالإضافة إلى ذلك، قد تقوم أجهزة مختلفة برفع الأحداث لنفس التطبيق؛ قد يدعم التطبيق التجوال أو شكل آخر من أشكال التوزيع عبر الأجهزة.

قد يتضمن المخطط أيضاً حقول مجال ذات صلة بسيناريو معين شائع عبر تطبيقات مختلفة، مثل. قد تكون هذه معلومات حول الاستثناءات وأحداث بدء التطبيق وانتهاءه ونجاح و/أو فشل استدعاءات واجهة برمجة تطبيقات خدمة الويب. يجب أن تصدر جميع التطبيقات التي تستخدم نفس مجموعة حقول المجال نفس مجموعة الأحداث، ما يتيح إنشاء مجموعة من التقارير والتحليلات المشتركة.

وأخيراً، قد يحتوي المخطط على حقول مخصصة لالتقاط تفاصيل الأحداث الخاصة بالتطبيق.

أفضل الممارسات لتقرير حالة التطبيقات

تلخص القائمة التالية أفضل الممارسات لتقرير حالة تطبيق موزع يعمل في السحابة.

• اجعل السجلات سهلة القراءة والتحليل. استخدم تسجيل منظم حيثما أمكن. كن موجزاً ووصفياً في رسائل السجل.

• في جميع السجلات، حدد المصدر وقدم السياق ومعلومات التوقيت حيث تتم كتابة كل تسجيل سجل.

• استخدم نفس المنطقة الزمنية والتنسيق لجميع الطوابع الزمنية. استخدم نفس المنطقة الزمنية والتنسيق لجميع الطوابع الزمنية، ما يساعد على ربط الأحداث للعمليات التي تمتد عبر الأجهزة والخدمات التي تعمل في مناطق جغرافية مختلفة.

• قم بتصنيف السجلات وكتابة الرسائل إلى ملف السجل المناسب.

• لا تكشف عن معلومات حساسة حول النظام أو معلومات شخصية عن المستخدمين، على سبيل المثال: امسح هذه المعلومات قبل تسجيلها، ولكن تأكد من الاحتفاظ بالتفاصيل ذات الصلة. على سبيل المثال، قم بإزالة المعرّف وكلمة المرور من أي سلاسل اتصال بقاعدة البيانات، ولكن اكتب المعلومات المتبقية في السجل حتى يتمكن المحلل من تحديد أن النظام يصل إلى قاعدة البيانات الصحيحة. قم بتسجيل جميع الاستثناءات المهمة، وتمكين المسؤول من تشغيل تسجيل الدخول وإيقاف تشغيله لمستويات أقل من الاستثناءات والتحذيرات. التقاط وتسجيل جميع معلومات منطق إعادة المحاولة. يمكن أن تكون هذه البيانات مفيدة في مراقبة الصحة العابرة للنظام.

• تتبع استدعاءات العملية، مثل الطلبات إلى خدمات ويب خارجية أو قواعد بيانات.

• لا تخلط بين رسائل السجل ومتطلبات الأمان المختلفة في ملف السجل نفسه. على سبيل المثال، لا تكتب معلومات التصحيح ومعلومات التدقيق في نفس السجل.

• باستثناء أحداث التدقيق، تأكد من أن جميع استدعاءات التسجيل هي عمليات fire-and-forget ولا تمنع تقدم العمليات التجارية. تعتبر أحداث التدقيق استثنائية نظراً لأهميتها بالنسبة للأعمال حيث يمكن تصنيفها كجزء أساسي من العمليات التجارية.

• تأكد من أن التسجيل قابل للتوسعة وليست لديه أي تبعيات مباشرة على هدف محدد. على سبيل المثال، بدلاً من كتابة المعلومات باستخدام System.Diagnostics.Trace ، حدد واجهة مجردة (مثل ILogger ) تعرض طرق التسجيل والتي يمكن تنفيذها بأي وسيلة مناسبة.

• تأكد من أن جميع عمليات التسجيل آمنة من الفشل ولا تؤدي أبداً إلى أي أخطاء متتالية. يجب أن لا يطرح التسجيل أي استثناءات.

• تعامل مع تقرير حالة النظام كعملية تكرارية مستمرة وراجع السجلات بانتظام، وليس فقط عندما تكون هناك مشكلة.

جمع البيانات وتخزينها

تهتم مرحلة جمع عملية الرصد باسترداد المعلومات التي ينشئها تقرير عن حالة النظام، وتنسيق هذه البيانات لتسهيل استهلاك مرحلة التحليل/التشخيص، وحفظ البيانات المحولة في تخزين موثوق به. يمكن الاحتفاظ ببيانات الأجهزة التي تجمعها من أجزاء مختلفة من النظام الموزع في مجموعة متنوعة من المواقع وبأشكال مختلفة. على سبيل المثال، قد تنشئ التعليمات البرمجية للتطبيق ملفات سجل التتبع وتنشئ بيانات سجل أحداث التطبيق، بينما يمكن التقاط عدادات الأداء التي تراقب الجوانب الرئيسية للبنية الأساسية التي يستخدمها التطبيق الخاص بك من خلال تقنيات أخرى. كما قد توفر أي مكونات وخدمات تابعة لجهات خارجية يستخدمها التطبيق معلومات الأجهزة الخاصة بها بتنسيقات مختلفة، باستخدام ملفات تعقب منفصلة أو تخزين الكائنات الثنائية كبيرة الحجم أو حتى مخزن بيانات مخصص.

غالبا ما يتم تنفيذ جمع البيانات من خلال خدمة تجميع يمكن تشغيلها بشكل مستقل من التطبيق الذي ينشئ بيانات الأجهزة. يوضح الشكل 2 مثالاً على هذه البنية، مع تمييز النظام الفرعي لجمع بيانات الأجهزة.

الشكل 2 - جمع بيانات الأجهزة.

لاحظ أن هذه طريقة عرض مبسطة. خدمة المجموعة ليست بالضرورة عملية واحدة وقد تتضمن العديد من الأجزاء المكونة التي تعمل على أجهزة مختلفة، كما هو موضح في الأقسام التالية. بالإضافة إلى ذلك، إذا كان يجب إجراء تحليل بعض بيانات تتبع الاستخدام بسرعة (تحليل ساخن، كما هو موضح في قسم دعم التحليل النشط و الغير نشط لاحقا في هذا المستند)، فقد تؤدي المكونات المحلية التي تعمل خارج خدمة التجميع مهام التحليل على الفور. يصور الشكل 2 هذا الوضع لأحداث محددة. بعد المعالجة التحليلية، يمكن إرسال النتائج مباشرة إلى النظام الفرعي للتصور والتنبيه. يتم الاحتفاظ بالبيانات التي تخضع للتحليل النشط أو الغير نشط في التخزين أثناء انتظار المعالجة.

بالنسبة لتطبيقات وخدمات Azure، توفر Azure Diagnostics حلاً واحداً ممكناً لالتقاط البيانات. تجمع تشخيصات Azure البيانات من المصادر التالية لكل عقدة حساب، وتجمعها، ثم تحملها إلى Azure Storage:

• سجلات IIS
• فشل طلب سجلات IIS
• سجلات أحداث Windows
• عدادات الأداء
• تفريغ الأعطال
• سجلات البنية الأساسية لتشخيص Azure
• سجلات خطأ مخصصة
• سجلات .NET EventSource
• ETW المستند إلى بيان التطبيق

لمزيد من المعلومات، راجع المقالة Azure: أساسيات بيانات تتبع الاستخدام واستكشاف الأخطاء وإصلاحها.

استراتيجيات لجمع بيانات الأجهزة

بالنظر إلى الطبيعة المرنة للسحابة، ولتجنب ضرورة استرداد بيانات تتبع الاستخدام يدوياً من كل عقدة في النظام، يجب عليك ترتيب البيانات لنقلها إلى موقع مركزي ودمجها. في نظام يمتد عبر مراكز بيانات متعددة، قد يكون من المفيد أولاً جمع البيانات ودمجها وتخزينها على أساس كل منطقة على حدة، ثم تجميع البيانات الإقليمية في نظام مركزي واحد.

لتحسين استخدام النطاق الترددي، يمكنك اختيار نقل بيانات أقل إلحاحاً في مجموعات، على شكل دفعات. ولكن يجب ألا تتأخر البيانات إلى أجل غير مسمى، خاصةً إذا كانت تحتوي على معلومات حساسة تعتمد على الوقت.

سحب بيانات الأجهزة ودفعها

يمكن لنظام فرعي لجمع بيانات الأجهزة استرداد بيانات الأجهزة بنشاط من السجلات المختلفة والمصادر الأخرى لكل مثيل من التطبيق ( نموذج السحب). أو، يمكن أن يعمل كجهاز استقبال سلبي ينتظر إرسال البيانات من المكونات التي تشكل كل مثيل للتطبيق ( نموذج الدفع).

أحد النهج لتنفيذ نموذج السحب هو استخدام عوامل المراقبة التي تعمل محليا مع كل مثيل من التطبيق. عامل المراقبة هو عملية منفصلة تسترد (تسحب) بيانات تتبع الاستخدام التي تم جمعها في العقدة المحلية بشكل دوري وتكتب هذه المعلومات مباشرة إلى التخزين المركزي الذي تشترك فيه جميع مثيلات التطبيق. هذه هي الآلية التي تنفذها Azure Diagnostics. يمكن تكوين كل مثيل من دور ويب أو عامل Azure لالتقاط معلومات التشخيص ومعلومات التتبع الأخرى المخزنة محلياً. يقوم عامل المراقبة الذي يعمل جنباً إلى جنب مع كل مثيل بنسخ البيانات المحددة إلى Azure Storage. لمزيد من المعلومات، اطلع على تمكين التشخيصات في Azure Cloud Services والأجهزة الظاهرية الذي يوفر مزيداً من التفاصيل حول هذه العملية. تتم كتابة بعض العناصر مثل سجلات خدمات معلومات الإنترنت (IIS)، ومستودعات معلومات الأعطال، وسجلات الأخطاء المخصصة في تخزين الكائن الثنائي كبير الحجم. يتم تسجيل البيانات من سجل أحداث Windows وتتبع الأحداث لـ Windows (ETW) وعدادات الأداء في تخزين الجدول. يوضح الشكل 3 هذه الآلية.

الشكل 3 - استخدام عامل مراقبة لسحب المعلومات والكتابة إلى التخزين المشترك.

من الممكن استخدام النهج الموضح للتو لتخزين بيانات تتبع الاستخدام لتطبيق صغير يعمل على عدد محدود من العقد في موقع واحد. ومع ذلك، قد ينشئ تطبيق سحابي عالمي معقد وقابل للتطوير بدرجة كبيرة كميات هائلة من البيانات من مئات أدوار الويب والعاملين وأجزاء قاعدة البيانات والخدمات الأخرى. قد تؤدي إلى تحميل زائد بسهولة على نطاق الإدخال/الإخراج الترددي المتوفر في موقع مركزي واحد. لذلك، يجب أن يكون حل القياس عن بعد قابلاً للتطوير لمنعه من العمل كاختناق مع توسع النظام. بشكل مثالي، يجب أن يشتمل الحل على درجة من التكرار لتقليل مخاطر فقدان معلومات المراقبة المهمة (مثل بيانات التدقيق أو الفوترة) في حالة فشل جزء من النظام.

لمعالجة هذه المشكلات، يمكنك تنفيذ قائمة الانتظار، كما هو موضح في الشكل 4. في هذه البنية، يقوم عامل المراقبة المحلي (إذا كان يمكن تكوينه بشكل مناسب) أو خدمة جمع البيانات المخصصة (إن لم يكن كذلك) بنشر البيانات في قائمة انتظار. تأخذ عملية منفصلة تعمل بشكل غير متزامن (خدمة كتابة التخزين في الشكل 4) البيانات الموجودة في قائمة الانتظار هذه وتكتبها في التخزين المشترك. تعد قائمة انتظار الرسائل مناسبة لأنها توفر دلالات "مرة واحدة على الأقل" تساعد في ضمان عدم فقدان البيانات الموجودة في قائمة الانتظار بعد ترحيلها. يمكنك تنفيذ خدمة كتابة التخزين باستخدام دور عامل منفصل.

الشكل 4 - استخدام قائمة انتظار لتخزين بيانات الأجهزة مؤقتا.

يمكن لخدمة تجميع البيانات المحلية إضافة بيانات إلى قائمة انتظار مباشرة بعد استلامها. تعمل قائمة الانتظار كمخزن مؤقت، ويمكن لخدمة كتابة التخزين استرداد البيانات وكتابتها بالسرعة الخاصة بها. بشكل افتراضي، تعمل قائمة الانتظار على أساس الدخول أولاً والخروج أولاً. ولكن يمكنك تحديد أولويات الرسائل لتسريعها من خلال قائمة الانتظار إذا كانت تحتوي على بيانات يجب معالجتها بسرعة أكبر. لمزيد من المعلومات، راجع نمط قائمة انتظار الأولوية. بدلاً من ذلك، يمكنك استخدام قنوات مختلفة (مثل مواضيع ناقل خدمة Microsoft Azure) لتوجيه البيانات إلى وجهات مختلفة اعتماداً على شكل المعالجة التحليلية المطلوبة.

لقابلية التوسع، يمكنك تشغيل مثيلات متعددة من خدمة كتابة التخزين. إذا كان يوجد عدد كبير من الأحداث، فيمكنك استخدام Event Hubs لإرسال البيانات إلى حساب مختلف للمعالجة والتخزين.

دمج بيانات الأجهزة

توفر البيانات التي تم جمعها من مثيل واحد للتطبيق طريقة عرض محلية لصحة هذا المثيل وأدائه. لتقييم الصحة العامة للنظام، من الضروري دمج بعض جوانب البيانات في طرق العرض المحلية. يمكنك القيام بذلك بعد تخزين البيانات، ولكن في بعض الحالات يمكنك أيضاً القيام بذلك أثناء جمع البيانات. يمكن أن تمر بيانات الأجهزة من خلال خدمة منفصلة لدمج البيانات تجمع البيانات وتعمل كعملية تصفية وتنظيف. على سبيل المثال، يمكن دمج بيانات الأجهزة التي تتضمن نفس معلومات الارتباط مثل معرف النشاط. (من الممكن أن يبدأ المستخدم في تنفيذ عملية عمل على عقدة واحدة ثم يتم نقله إلى عقدة أخرى في حالة فشل العقدة، أو اعتمادا على كيفية تكوين موازنة التحميل.) يمكن لهذه العملية أيضا الكشف عن أي بيانات مكررة وإزالتها (إمكانية دائماً إذا كانت خدمة بيانات تتبع الاستخدام تستخدم قوائم انتظار الرسائل لدفع بيانات الأجهزة إلى التخزين). يوضح الشكل 5 مثالاً على هذه البنية.

الشكل 5 - استخدام خدمة منفصلة لدمج بيانات الأجهزة وتنظيفها.

تخزين بيانات الأجهزة

وقد بينت المناقشات السابقة عرضاً مبسطاً إلى حد ما للطريقة التي يتم بها تخزين بيانات الأجهزة. في الواقع، يمكن أن يكون من المنطقي تخزين أنواع مختلفة من المعلومات باستخدام التقنيات الأكثر ملاءمة للطريقة التي من المحتمل أن يستخدم بها كل نوع.

على سبيل المثال، يحتوي تخزين الكائنات الثنائية كبيرة الحجم وتخزين الجداول لـ Azure على بعض أوجه التشابه في طريقة الوصول إليهما. ولكن لديهم قيود في العمليات التي يمكنك تنفيذها باستخدامها، ونقاوة البيانات التي يحتفظون بها مختلفة تماماً. إذا كنت بحاجة إلى إجراء المزيد من العمليات التحليلية أو تتطلب إمكانات البحث في النص الكامل على البيانات، فقد يكون من الأنسب استخدام تخزين البيانات الذي يوفر إمكانات محسّنة لأنواع معينة من الاستعلامات والوصول إلى البيانات. على سبيل المثال:

• يمكن تخزين بيانات عداد الأداء في قاعدة بيانات SQL لتمكين التحليل المخصص.
• قد يتم تخزين سجلات التعقب بشكل أفضل في Azure Cosmos DB.
• يمكن كتابة معلومات الأمان إلى HDFS.
• يمكن تخزين المعلومات التي تتطلب البحث عن نص كامل من خلال Elasticsearch (والذي يمكنه أيضاً تسريع عمليات البحث باستخدام الفهرسة الغنية).

يمكنك تنفيذ خدمة إضافية تعمل بشكل دوري على استرداد البيانات من التخزين المشترك والأقسام وتصفية البيانات حسب الغرض منها، ثم كتابتها في مجموعة مناسبة من مخازن البيانات كما هو موضح في الشكل 6. تتمثل إحدى النُهج البديلة في تضمين هذه الوظيفة في عملية الدمج والتنظيف وكتابة البيانات مباشرة إلى مخازن البيانات هذه عند استردادها بدلاً من حفظها في منطقة تخزين مشتركة وسيطة. لدى كل نهج مزايا وعيوب. يؤدي تنفيذ خدمة تقسيم منفصلة إلى تقليل الحمل على خدمة الدمج والتنظيف، كما يتيح إعادة إنشاء بعض البيانات المقسمة على الأقل إذا لزم الأمر (اعتماداً على مقدار البيانات التي يتم الاحتفاظ بها في التخزين المشترك). ولكنه يستهلك موارد إضافية. كما قد يوجد تأخير بين استلام بيانات الأجهزة من كل مثيل تطبيق وتحويل هذه البيانات إلى معلومات قابلة للتنفيذ.

الشكل 6 - تقسيم البيانات وفقاً لمتطلبات التحليل والتخزين.

قد تكون بيانات الأجهزة نفسها مطلوبة لأكثر من غرض واحد. على سبيل المثال، يمكن استخدام عدادات الأداء لتوفير عرض تاريخي لأداء النظام بمرور الوقت. يمكن دمج هذه المعلومات مع بيانات الاستخدام الأخرى لإنشاء معلومات فوترة العميل. في هذه الحالات، قد يتم إرسال نفس البيانات إلى أكثر من وجهة واحدة، مثل قاعدة بيانات المستندات التي يمكن أن تعمل كمخزن طويل الأجل للاحتفاظ بمعلومات الفوترة، ومتجر متعدد الأبعاد للتعامل مع تحليلات الأداء المعقدة.

يجب عليك أيضاً مراعاة مدى السرعة المطلوبة للبيانات. يجب الوصول إلى البيانات التي توفر معلومات للتنبيه بسرعة، لذلك يجب الاحتفاظ بها في تخزين سريع للبيانات وفهرستها أو تنظيمها لتحسين الاستعلامات التي يقوم بها نظام التنبيه. في بعض الحالات، قد يكون من الضروري لخدمة بيانات تتبع الاستخدام التي تجمع البيانات على كل عقدة لتنسيق البيانات وحفظها محليا بحيث يمكن لمثيل محلي لنظام التنبيه إعلامك بسرعة بأي مشكلات. يمكن إرسال نفس البيانات إلى خدمة كتابة التخزين الموضحة في الصور السابقة وتخزينها مركزياً إذا كانت مطلوبة أيضاً لأغراض أخرى.

تعد المعلومات التي يتم استخدامها للتحليل بشكل متكرر، ولإعداد التقارير، ولاكتشاف الاتجاهات التاريخية أقل أهمية ويمكن تخزينها بطريقة تدعم جمع البيانات والاستعلامات المخصصة. لمزيد من المعلومات، راجع القسم دعم التحليل النشط و الغير نشط لاحقا في هذا المستند.

استدارة السجل واستبقاء البيانات

يمكن أن يولد تقرير عن حالة النظام كميات كبيرة من البيانات. يمكن الاحتفاظ بهذه البيانات في عدة أماكن، بدءاً من ملفات السجل الأولية وملفات التتبع والمعلومات الأخرى التي تم التقاطها في كل عقدة إلى طريقة العرض الموحدة والنظيفة والمقسمة لهذه البيانات الموجودة في التخزين المشترك. في بعض الحالات، بعد معالجة البيانات ونقلها، يمكن إزالة بيانات المصدر غير المنسقة الأصلية التي تم تخزينها محلياً. وفي حالات أخرى، قد يكون من الضروري أو المفيد حفظ البيانات غير المنسقة. على سبيل المثال، قد يكون من الأفضل ترك البيانات التي تم إنشاؤها لأغراض تصحيح الأخطاء متاحة في شكلها غير المنسق، ولكن يمكن بعد ذلك التخلص منها بسرعة بعد تصحيح أي أخطاء.

غالباً ما يكون لبيانات الأداء دورة حياة أطول بحيث يمكن استخدامها لتحديد اتجاهات الأداء ولتخطيط السعة. عادةً ما يتم الاحتفاظ بطريقة العرض المدمجة لهذه البيانات عبر الإنترنت لفترة محدودة لتمكين الوصول السريع. بعد ذلك، يمكن أرشفتها أو تجاهلها. قد تحتاج البيانات التي تم جمعها لعملاء القياس والفوترة إلى حفظها إلى أجل غير مسمى. بالإضافة إلى ذلك، قد تملي المتطلبات التنظيمية أن المعلومات التي تم جمعها لأغراض التدقيق والأمن تحتاج أيضاً إلى أرشفتها وحفظها. هذه البيانات حساسة أيضاً وقد تحتاج إلى تشفيرها أو حمايتها بطريقة أخرى لمنع العبث بها. يجب ألا تسجل أبداً كلمات مرور المستخدمين أو أي معلومات أخرى قد تُستخدم لارتكاب عملية احتيال تتعلق بالهوية. يجب حذف هذه التفاصيل من البيانات قبل تخزينها.

أخذ العينات لأسفل

من المفيد تخزين البيانات التاريخية حتى تتمكن من تحديد الاتجاهات طويلة المدى. بدلاً من حفظ البيانات القديمة بالكامل، قد يكون من الممكن تصغير عينة البيانات لتقليل الدقة وتوفير تكاليف التخزين. على سبيل المثال، بدلاً من حفظ مؤشرات الأداء دقيقة تلو دقيقة، يمكنك دمج البيانات التي مضى عليها أكثر من شهر لتكوين طريقة عرض ساعة تلو ساعة.

أفضل الممارسات لجمع معلومات التسجيل وتخزينها

تلخص القائمة التالية أفضل الممارسات لالتقاط معلومات التسجيل وتخزينها:

• يجب تشغيل خدمة التجميع كخدمة خارج العملية، ويجب أن تكون سهلة النشر.

• يجب أن تكون جميع المخرجات من عامل المراقبة أو خدمة جمع البيانات تنسيقاً غير محدد مستقل عن الجهاز أو نظام التشغيل أو بروتوكول الشبكة. على سبيل المثال، يمكنك إرسال معلومات بتنسيق ذاتي الوصف مثل JSON أو MessagePack أو Protobuf بدلاً من ETL/ETW. ويتيح استخدام تنسيقاً قياسياً للنظام إنشاء مسارات معالجة؛ يمكن دمج المكونات التي تقرأ البيانات وتحولها وترسلها بالتنسيق المتفق عليه بسهولة.

• يجب أن تكون عملية المراقبة وجمع البيانات آمنة من الفشل، ويجب ألا تؤدي إلى أي حالات خطأ متتالية.

• في حالة حدوث فشل مؤقت في إرسال المعلومات إلى متلقي البيانات، يجب أن تكون خدمة التجميع جاهزة لإعادة ترتيب بيانات تتبع الاستخدام بحيث يتم إرسال أحدث المعلومات أولاً. (قد تختار خدمة جمع البيانات أو عامل المراقبة حذف البيانات القديمة أو حفظها محلياً ونقلها لاحقاً للحاق بباقي البيانات وفقاً لظروفها الخاصة.)

تحليل البيانات وتشخيص المشكلات

جزء مهم من عملية الرصد والتشخيص هو تحليل البيانات التي تم جمعها للحصول على صورة عن الرفاه العام للنظام. يجب أن تكون قد حددت مؤشرات الأداء الرئيسية ومقاييس الأداء الخاصة بك، ومن المهم فهم كيفية هيكلة البيانات التي تم جمعها لتلبية متطلبات التحليل الخاصة بك. من المهم أيضاً فهم كيفية ترابط البيانات التي يتم التقاطها في مقاييس وملفات سجل مختلفة، لأن هذه المعلومات يمكن أن تكون مفتاحا لتعقب تسلسل الأحداث والمساعدة في تشخيص المشكلات التي تنشأ.

وكما هو موضح في القسم دمج بيانات الأجهزة، عادةً ما يتم التقاط البيانات الخاصة بكل جزء من النظام محلياً، ولكن عادة ما تحتاج إلى دمجها مع البيانات التي يتم إنشاؤها في مواقع أخرى تشارك في النظام. تتطلب هذه المعلومات ارتباطاً دقيقاً لضمان دمج البيانات بدقة. على سبيل المثال، قد تمتد بيانات الاستخدام لعملية ما إلى عقدة تستضيف موقع ويب يتصل به المستخدم، وعقدة تقوم بتشغيل خدمة منفصلة يتم الوصول إليها كجزء من هذه العملية، وتخزين البيانات الموجود على عقدة أخرى. يجب ربط هذه المعلومات لتوفير عرض شامل للمورد واستخدام المعالجة للعملية. قد تحدث بعض المعالجة المسبقة للبيانات وتصفيتها على العقدة التي يتم التقاط البيانات عليها، بينما من المرجح أن يحدث التجميع والتنسيق على عقدة مركزية.

دعم التحليل النشط و الغير نشط

إن تحليل البيانات وإعادة تنسيقها لأغراض التمثيل البياني باستخدام المخططات والإبلاغ والتنبيه قد يكون عملية معقدة تستهلك مجموعة الموارد. وبعض أشكال المراقبة تعد مهمة جداً من حيث التوقيت وتتطلب تحليلاً فورياً للبيانات لكي تكون فعالة. يعرف هذا باسم التحليل النشط. ومن الأمثلة على ذلك التحليلات المطلوبة للتنبيه وبعض جوانب المراقبة الأمنية (مثل الكشف عن هجوم على النظام). يجب أن تكون البيانات المطلوبة لهذه الأغراض متاحة ومهيكلة بسرعة للمعالجة الفعالة. في بعض الحالات، قد يكون من الضروري نقل معالجة التحليل إلى العقد الفردية حيث يتم الاحتفاظ بالبيانات.

بينما تعد بعض الأشكال الأخرى من التحليل أقل أهمية من حيث التوقيت، ولا تتطلب إلا بعض عمليات الحساب والتجميع بعد تلقي البيانات الأولية. وهذا ما يسمى التحليل الدافئ. غالباً ما يندرج تحليل الأداء ضمن هذه الفئة. في هذه الحالة، من غير المرجح أن يكون حدث أداء فردي معزول مهماً إحصائياً. (قد يكون سببه ارتفاع مفاجئ أو خلل.) يجب أن توفر البيانات من سلسلة من الأحداث صورة أكثر موثوقية لأداء النظام.

يمكن أيضا استخدام التحليل الدافئ للمساعدة في تشخيص المشكلات الصحية. على سبيل المثال، عادةً ما يتم علاج حدث حالة السلامة من خلال التحليل السريع وقد يقوم بإعداد تنبيه على الفور. يمكن للمشغل بعد ذلك التعمق في أسباب الحدث المتعلق بحالة سلامة النظام عن طريق فحص البيانات من المسار المتوسط. يجب أن تحتوي هذه البيانات على معلومات حول الأحداث التي أدت إلى المشكلة المتسببة في الحدث المتعلق بحالة سلامة النظام.

بعض أنواع المراقبة تولد المزيد من البيانات طويلة الأجل. يمكن إجراء هذا التحليل في وقت لاحق، ربما وفقاً لجدول زمني محدد مسبقاً. في بعض الحالات، قد يحتاج التحليل إلى إجراء تصفية معقدة لكميات كبيرة من البيانات التي تم التقاطها على مدى فترة زمنية. وهذا ما يسمى بالتحليل الغير نشط. الشرط الرئيسي هو أن يتم تخزين البيانات بأمان بعد التقاطها. على سبيل المثال، تتطلب مراقبة الاستخدام والتدقيق صورة دقيقة لحالة النظام في نقاط زمنية منتظمة، ولكن لا يجب أن تكون معلومات الحالة هذه متاحة للمعالجة مباشرة بعد جمعها.

يمكن للمشغل أيضاً استخدام تحليل البيانات التي يندر الوصول إليها لتوفير بيانات التحليل التنبؤي لحالة سلامة النظام. يمكن للمشغل جمع معلومات تاريخية خلال فترة محددة واستخدامها بالاقتران مع بيانات حالة السلامة الحالية (المستردة من المسار السريع) لاكتشاف الاتجاهات التي قد تسبب مشكلات في حالة السلامة قريباً. في هذه الحالات، قد يكون من الضروري رفع حالة التأهب والاستعداد ليسهل اتخاذ الإجراءات التصحيحية اللازمة.

ربط البيانات

يمكن أن توفر البيانات التي تلتقطها الأجهزة لقطة لحالة النظام، ولكن الغرض من التحليل هو جعل هذه البيانات قابلة للتنفيذ. على سبيل المثال:

• ما الذي تسبب في تحميل الإدخال/الإخراج المكثف على مستوى النظام في وقت محدد؟
• هل هو نتيجة لعدد كبير من عمليات قاعدة البيانات؟
• هل ينعكس ذلك على أوقات استجابة قاعدة البيانات، وعدد المعاملات في الثانية، وأوقات استجابة التطبيق التي تسير في نفس المنعطف؟

قطع البيانات عبر المزيد من الخوادم قد يكون إجراءً علاجياً محتملاً لتخفيف عبء تحميل البيانات على الخادم ونقلها إلى خوادم أخرى. بالإضافة إلى ذلك، يمكن أن تنشأ استثناءات نتيجة لخطأ في أي مستوى من مستويات النظام. حدوث استثناء في مستوى واحد غالباً يؤدي إلى خطأ آخر في المستوى أعلاه.

لذلك فمن المستحسن أن تقوم بربط أنواع مختلفة من رصد البيانات في كل مستوى لإنتاج عرض شامل لحالة النظام والتطبيقات التي تعمل على هذا النظام. يمكنك أيضاً استخدام هذه المعلومات لاتخاذ قرارات حول ما إذا كان النظام يعمل بشكل مقبول أم لا، وتحديد ما يمكن القيام به لتحسين جودة النظام.

كما هو موضح في القسم معلومات لربط البيانات ، يجب عليك التأكد من أن بيانات الأجهزة الأولية تتضمن معلومات كافية عن السياق ومعرف النشاط لدعم التجميعات المطلوبة للأحداث المرتبطة. بالإضافة إلى ذلك، قد تكون هذه البيانات في أشكال مختلفة، وقد يكون من الضروري تحليل هذه المعلومات لتحويلها إلى شكل موحَّد للتحليل.

استكشاف الأخطاء وإصلاحها وتشخيص المشكلات

يتطلب التشخيص القدرة على تحديد سبب الأخطاء أو السلوك غير المتوقع، بما في ذلك إجراء تحليل السبب الجذري. تتضمن المعلومات المطلوبة عادة ما يلي:

• معلومات مفصلة من سجلات الأحداث والتتبعات، إما عن النظام بأكمله أو عن نظام فرعي محدد خلال فترة زمنية محددة.
• تتبعات مكدس كاملة ناتجة عن استثناءات وأخطاء أي مستوى محدد الحادثة داخل النظام أو نظام فرعي محدد أثناء فترة محددة.
• معلومات الأعطال لأي عمليات فاشلة إما في أي مكان في النظام أو لنظام فرعي محدد أثناء نافذة زمنية محددة.
• يسجل النشاط تسجيل العمليات المنفذة إما من قِبل كافة المستخدمين أو للمستخدمين المحددين أثناء فترة محددة.

تحليل البيانات لأغراض استكشاف الأخطاء وإصلاحها غالباً ما يتطلب الفهم التقني العميق لبنية النظام والمكونات المختلفة التي تشكل الحل. ونتيجة لذلك، غالباً ما يتطلب الأمر قدراً كبيراً من التدخل اليدوي لتفسير البيانات، وتحديد سبب المشاكل، والتوصية بالإستراتيجية المناسبة لتصحيحها. قد يكون من المناسب ببساطة تخزين نسخة من هذه المعلومات في شكلها الأصلي وإتاحتها للتحليل البارد من جهة خبير.

تصور البيانات ورفع التنبيهات

وإحدى الجوانب المهمة لأي نظام مراقبة هو القدرة على عرض البيانات بطريقة تُمكّن عامل التشغيل من اكتشاف أي اتجاهات أو مشاكل بسرعة. تعتبر أيضًا القدرة على إبلاغ عامل التشغيل بسرعة إذا وقع حدث مهم قد يتطلب الاهتمام أمرًا ذا أهمية.

يمكن أن يتخذ عرض البيانات أشكالاً عدة، بما في ذلك التصور باستخدام لوحات المعلومات، والتنبيه والإبلاغ.

التصور باستخدام لوحات المعلومات

إن الطريقة الأكثر شيوعًا لتصور البيانات هي استخدام لوحات المعلومات التي تعرض المعلومات كسلسلة من المخططات، أو الرسوم البيانية، أو بعض التوضيحات الأخرى. يمكن وضع معلمات العناصر، ويمكن للمحلل تحديد المعلمات المهمة، مثل الفترة الزمنية، لأي حالة محددة.

يمكن تنظيم لوحات المعلومات في تسلسل هرمي. يمكن أن تعطي لوحات المعلومات على المستوى الأعلى عرضًا شاملاً لكل جانب من جوانب النظام ولكنها تُمكّن عامل التشغيل من التنقل وصولاً إلى التفاصيل. على سبيل المثال، يتعين للوحة المعلومات التي تعرض إجمالي إدخال/إخراج القرص في النظام أن تسمح للمُحلل بعرض معدلات الإدخال/إخراج لكل قرص فردي لتحديد ما إذا كان جهاز أو أكثر من الأجهزة المحددة مسئولاً عن النسبة غير المتناسبة لنقل البيانات. ومن الناحية المثالية، يجب أن تعرض لوحة المعلومات كذلك المعلومات ذات الصلة، مثل مصدر كل طلب (المستخدم أو النشاط) الذي يتسبب في هذا الإدخال/الإخراج. يمكن استخدام هذه المعلومات لتحديد ما إن كان ينبغي (وكيفية) نشر الحمل بتكافؤ عبر الأجهزة، وما إذا كان النظام سيعمل على نحو أفضل إذا أُضيفت المزيد من الأجهزة.

قد تستخدم لوحة المعلومات أيضًا ترميز الألوان أو بعض الإشارات المرئية الأخرى للإشارة إلى القيم التي تظهر شاذة أو التي تقع خارج النطاق المتوقع. باستخدام المثال السابق:

• يمكن تمييز معدل إدخال/إخراج القرص الذي يقترب من بلوغ سعته القصوى خلال فترةٍ ممتدةٍ (قرص سريع) باللون الأحمر.
• يمكن تمييز بمعدل إدخال/إخراج القرص الذي يعمل بشكل دوري عند الحد الأقصى على فترات قصيرة (قرص بطيء) باللون الأصفر.
• يمكن عرض القرص الذي يبين الاستخدام العادي باللون الأخضر.

لكي يعمل نظام لوحة المعلومات بفعالية، يجب أن يحتوي على البيانات الأولية للعمل بها. إذا كنت تنشئ نظام لوحة المعلومات الخاص بك، أو تستخدم لوحة معلومات طورتها مؤسسة أخرى، فيجب عليك فهم بيانات الأجهزة التي تحتاج إلى جمعها، وعلى أي مستويات من الدقة، وكيف يجب تنسيقها لاستهلاك لوحة المعلومات.

لا تعرض لوحة المعلومات الجيدة المعلومات فحسب، بل تُمكّن المحلل أيضًا من طرح أسئلة مرتجلة حول هذه المعلومات. توفر بعض الأنظمة أدوات للإدارة يمكن لعامل التشغيل استخدامها لإكمال هذه المهام واستكشاف البيانات الأساسية. بدلاً من ذلك، واستنادًا إلى المستودع المستخدم في الاحتفاظ بهذه المعلومات، قد يمكن الاستعلام عن هذه البيانات مباشرةً، أو استيرادها إلى أدوات مثل Microsoft Excel لمزيد من التحليل والإبلاغ.

طرح التنبيهات

يعد التنبيه عبارة عن عملية تحليل بيانات المراقبة والأجهزة وإنشاء الإعلامات في حالة اكتشاف حدث مهم.

يساعد التنبيه على ضمان بقاء النظام سليماً ومستجيباً وآمناً. ويعد جزءاً مهماً من أي نظام يوفر الأداء وقابلية الوصول وضمانات الخصوصية للمستخدمين حيث قد تحتاج إلى التصرف في البيانات على الفور. قد يحتاج عامل التشغيل إلى إعلامه بالحدث الذي شغل التنبيه. يمكن أيضاً استخدام التنبيه لاستدعاء وظائف النظام مثل التوسيع التلقائي.

يعتمد التنبيه على بيانات الأجهزة التالية:

• أحداث أمنية. إذا كانت سجلات الأحداث تشير إلى حدوث فشل متكرر في المصادقة و / أو التخويل، فقد يكون النظام عرضة للهجوم ويجب إبلاغ عامل التشغيل.
• مقاييس الأداء. يجب أن يستجيب النظام بسرعة إذا تجاوز مقياس أداء معين حدًا معينًا.
• معلومات التوفر. إذا تم اكتشاف خطأ، فقد يكون من الضروري إعادة تشغيل نظام فرعي واحد أو أكثر بسرعة، أو الفشل في الوصول إلى مورد احتياطي. قد تشير الأعطال المتكررة في النظام الفرعي إلى مخاوف أكثر خطورة.

قد يتلقى المشغلون معلومات التنبيه باستخدام العديد من قنوات التسليم مثل البريد الإلكتروني أو جهاز النداء أو رسالة نصية قصيرة (SMS). قد يتضمن التنبيه أيضاً إشارة إلى مدى خطورة الموقف. تدعم العديد من أنظمة التنبيه مجموعات المشتركين، ويمكن لجميع المشغلين الأعضاء في نفس المجموعة تلقي نفس مجموعة التنبيهات.

ويجب أن يكون نظام التنبيه قابلاً للتخصيص، ويمكن توفير القيم المناسبة من بيانات الأجهزة الأساسية كمعلمات. ويمكّن هذا النهج المشغل من تصفية البيانات والتركيز على تلك الحدود أو مجموعات القيم ذات الأهمية. لاحظ أنه في بعض الحالات، يمكن تقديم البيانات غير المنسقة للأجهزة إلى نظام التنبيه. في حالات أخرى، قد يكون من الأنسب توفير بيانات مجمعة. (على سبيل المثال، يمكن تشغيل تنبيه إذا تجاوز استخدام وحدة المعالجة المركزية لعقدة ما 90 بالمائة خلال الدقائق العشر الماضية). يجب أن تتضمن التفاصيل المقدمة إلى نظام التنبيه أي معلومات موجزة وسياقية مناسبة. يمكن أن تساعد هذه البيانات في تقليل احتمالية أن تؤدي أي نتائج أحداث إيجابية خاطئة إلى إصدار تنبيه.

إعداد التقرير

يتم استخدام التقارير لإنشاء طريقة عرض شاملة للنظام. وقد يتضمن بيانات تاريخية بالإضافة إلى المعلومات الحالية. وتندرج متطلبات التقارير في فئتين واسعتين: التقارير التشغيلية والتقارير الأمنية.

التقارير التشغيلية تتضمن عادةً الجوانب التالية:

• جمع الإحصائيات التي يمكنك استخدامها لفهم استخدام الموارد للنظام الشامل أو الأنظمة الفرعية المحددة أثناء نافذة زمنية محددة.
• تحديد الاتجاهات في استخدام الموارد للنظام الشامل أو الأنظمة الفرعية المحددة خلال فترة محددة.
• مراقبة الاستثناءات التي وقعت في النظام أو في أنظمة فرعية محددة خلال فترة محددة.
• تحديد كفاءة التطبيق في الموارد المنشورة، وفهم ما إذا كان يمكن تقليل حجم الموارد، والتكلفة المرتبطة بها، دون التأثير على الأداء دون داعٍ.

تهتم التقارير الأمنية بتعقب استخدام العملاء للنظام. وقد تشمل:

• تدقيق عمليات المستخدم. يتطلب هذا الأسلوب تسجيل الطلبات الفردية التي يكملها كل مستخدم، إلى جانب التواريخ والأوقات. يجب هيكلة البيانات لتُمكن المسؤول من لإعادة إنشاء تسلسل العمليات التي يكملها مستخدم خلال فترة محددة بسرعة.
• تتبع استخدام المورد من قبل المستخدم. يتطلب هذا الأسلوب تسجيل كيفية وصول كل طلب من المستخدم إلى الموارد المختلفة التي تُشكّل النظام، ولكم من الوقت. يمكن للمسؤول استخدام هذه البيانات لإعداد تقرير الاستخدام، حسب المستخدم، خلال فترة محددة، ربما لأغراض إصدار الفواتير.

في كثير من الحالات، يمكن أن تقوم عمليات معالجة الدفعة بإنشاء التقارير وفقًا لجدول زمني محدد. (زمن الانتقال ليس عادة مشكلة.) ولكن ينبغي أن تكون متاحة أيضاً للجيل على أساس مخصص إذا لزم الأمر. على سبيل المثال، إذا كنت تقوم بتخزين البيانات في قاعدة بيانات ارتباطية، مثل قاعدة بيانات azure SQL، يمكنك استخدام أداة مثل SQL Server Reporting Services لاستخراج البيانات وتنسيقها، وتقديمها على هيئة مجموعة من التقارير.

الخطوات التالية

• نظرة عامة على Azure Monitor
• مراقبة Microsoft Azure Storage وتشخيصها واستكشاف مشكلاتها وإصلاحها
• نظرة عامة على التنبيهات فيMicrosoft Azure
• عرض إعلامات حالة الخدمة باستخدام مدخل Azure
• ما هو Application Insights؟
• تشخيص الأداء لأجهزة Azure الظاهرية
• تنزيل وتثبيت SQL Server Data Tools (SSDT) Visual Studio

الموارد ذات الصلة

• تبين إرشادات التحجيم التلقائي كيفية تقليل النفقات العامة للإدارة عن طريق تقليل الحاجة إلى عامل تشغيل لمراقبة أداء النظام باستمرار واتخاذ قرارات حول إضافة الموارد أو إزالتها.
• مراقبة نقاط النهاية الصحية تنفيذ ميزة فحوصات وظيفية في أحد التطبيقات التي يمكن للأدوات الخارجية الوصول إليها من خلال نقاط النهاية المكشوفة على فترات منتظمة.
• يبين نمط قائمة انتظار الأولوية كيفية تحديد أولويات الرسائل المدرجة في قائمة الانتظار بحيث يتم تلقي الطلبات العاجلة ويمكن معالجتها قبل الرسائل الأقل إلحاحاً.