نحن نأكل الفيل في أجزاء. مثال تطبيق استراتيجية مراقبة الصحة

مرحبا بالجميع!

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

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

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

استراتيجية الرصد

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

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

جوهر استراتيجية الرصد لدينا:

تقسيم التطبيق إلى مكونات.
لكل مكون ، تأتي مع الضوابط السيطرة.

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

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



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

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

نظام الرصد

لنفترض أننا قسمنا التطبيق إلى مكونات ، واخترعنا وننفّذ عمليات فحص لكل مكون ، لكن ماذا نفعل بنتائج هذه الاختبارات؟ كيف نعرف أن نوعا من الفحص فشل؟

سنحتاج إلى نظام مراقبة. سوف تقوم بالمهام التالية:

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

وصف موجز لنظام ASMO

أفضل تفسير بالقدوة. دعونا نرى كيف يتم تنظيم مراقبة تشغيل نظام ASMO.

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



لذلك ، فإن تكوين النظام نموذجي تمامًا: الموقع ، الوكيل ، المعدات. لنبدأ الرصد.

نحن تقسيم النظام إلى مكونات

يمكن تمييز المكونات التالية في نظام ASMO:

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

2. قاعدة البيانات
يتم تخزين البيانات المهمة للإبلاغ في قاعدة البيانات ؛ فمن الضروري التحقق من إنشاء نسخ احتياطية لقاعدة البيانات بنجاح.

3. الخادم
بواسطة الخادم نعني الأجهزة التي تعمل عليها التطبيقات. من الضروري التحقق من حالة الأقراص الصلبة ، RAM ، وحدة المعالجة المركزية.

4. وكيل
هذه هي خدمة Windows التي تقوم بالعديد من المهام المجدولة المختلفة. كحد أدنى ، تحتاج إلى التحقق من تشغيل الخدمة.

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

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

7. نقطة مراقبة الطريق (MPC)
سوف نعتبر هذا المكون قابلاً للخدمة إذا كانت جميع الأجهزة الموجودة في MPC صالحة للخدمة.

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

في نظام المراقبة ، ستبدو شجرة المكونات كما يلي:

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

لذلك ، قمنا بتقسيم النظام إلى مكونات ، والآن نحن بحاجة إلى الخروج بشيكات لكل مكون.

لمراقبة تطبيق الويب ، نستخدم الاختبارات التالية:

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

2. التحقق من مدة الدفع المجال
تحقق مهم جدا. عندما يتم ترك مجال بدون دفع ، لا يمكن للمستخدمين فتح الموقع. قد يستغرق الأمر عدة أيام لحل المشكلة. لا يتم تطبيق تغييرات DNS على الفور.

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

يوجد أدناه مكون "الحساب الشخصي" في نظام المراقبة:



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

ماذا يمكنني أن تحقق؟

لمزيد من المراقبة الكاملة لتطبيق الويب ، يمكنك إجراء الاختبارات التالية:

• عدد أخطاء JavaScript لكل فترة
• عدد الأخطاء على جانب تطبيق الويب (النهاية الخلفية) للفترة
• عدد الاستجابات غير الناجحة لتطبيق الويب (رمز الاستجابة 404 ، 500 ، إلخ.)
• متوسط ​​وقت تنفيذ الاستعلام

مراقبة خدمة ويندوز (وكيل)

في نظام ASMO ، يعمل الوكيل كجدول زمني للمهام ، والذي يؤدي في الخلفية المهام المجدولة.

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

نقوم بتقسيم مكون Agent إلى مكونات فرعية (مهام):



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

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

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

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

خوارزمية التحقق من الصحة

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

يتيح لك هذا الفحص اكتشاف المشكلات التالية:

1. تعمل المهمة ، لكنها تفشل.
2. توقفت المهمة عن التنفيذ ، على سبيل المثال ، تم تجميدها.

دعونا نفكر في كيفية حل هذه المشكلات بمزيد من التفصيل.

المشكلة 1 - المهمة تعمل ، لكنها تفشل
أدناه هي الحالة عند تنفيذ المهمة ، ولكن من 14:00 إلى 16:00 فشل.



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

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



المشكلة 2 - توقفت المهمة عن العمل (معلقة)
كيف يفهم نظام المراقبة أن المهمة مجمدة؟

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



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

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

ما هو وقت صلاحية الشيك؟

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

تحقق التقدم

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

خوارزمية التحقق من الصحة

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

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

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

رصد قاعدة البيانات

للتحكم في قاعدة البيانات في نظام ASMO ، نقوم بإجراء الاختبارات التالية:

1. تحقق من النسخ الاحتياطية
2. التحقق من مساحة القرص الحرة

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

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

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

أنها مريحة لاستخدام المقاييس للتحقق من المعلمات العددية.

Metric هو متغير رقمي يتم تمرير قيمته إلى نظام المراقبة. يتحقق نظام المراقبة من العتبات ويحسب حالة القياس.

فيما يلي صورة لشكل مكون "قاعدة البيانات" في نظام المراقبة:

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

لمراقبة الخادم ، نستخدم الفحوص والمقاييس التالية:

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

2. متوسط ​​قيمة ذاكرة الوصول العشوائي في المئة في الساعة
نحن نستخدم متوسط ​​القيمة في الساعة ، كما نحن لسنا مهتمين في السباقات النادرة.

3. متوسط ​​قيمة وحدة المعالجة المركزية في المئة في الساعة
نحن نستخدم متوسط ​​القيمة في الساعة ، كما نحن لسنا مهتمين في السباقات النادرة.

4. بينغ الاختيار
تحقق من أن الخادم متصل. نظام الرصد قادر على القيام بهذا الاختيار ، لا حاجة لكتابة التعليمات البرمجية.

فيما يلي صورة لما يشبه مكون "الخادم" في نظام المراقبة:

مراقبة المعدات

سأخبرك بكيفية تلقي البيانات. لكل نقطة من التحكم في الطرق (MPC) في برنامج جدولة المهام ، هناك مهمة ، على سبيل المثال ، "Polling MPC M2 km 200". المهمة مرة واحدة في 30 دقيقة تتلقى البيانات من جميع الأجهزة MPC.

مشكلة قناة التواصل
تقع معظم المعدات خارج المدينة ، وتستخدم شبكة GSM لنقل البيانات ، والتي لا تعمل بشكل مستقر (أي أنها غير موجودة).

نظرًا لفشل الشبكة بشكل متكرر ، بدا الأمر عند فحص استطلاع MPC لأول مرة في المراقبة على النحو التالي:



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



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

فيما يلي صورة لما يشبه الجهاز في نظام المراقبة:



! المهم
عندما تتوقف شبكة GSM عن العمل ، لا يتم استجواب جميع أجهزة MPC. لتقليل عدد الحروف من نظام المراقبة ، يشترك مهندسونا في إعلامات مشاكل المكونات بالنوع "MPC" ، وليس "الجهاز". يتيح لك ذلك تلقي إشعار واحد لكل MAC ، بدلاً من تلقي إشعار منفصل لكل جهاز.

نظام الرصد النهائي ASMO

فلنضعها جميعًا ونرى نوع مخطط المراقبة الذي لدينا.

استنتاج

لنلخص.
ماذا رصد لنا أداء ASMO؟

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

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

3. تقليل عدد مكالمات الدعم الفني
يتم الآن إصلاح العديد من المشكلات قبل معرفة المستخدمين عنها. المستخدمين لديهم أقل الاتصال الدعم الفني. كل هذا له تأثير جيد على سمعتنا.

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

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

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

يجب أن يعمل نظام المراقبة على خادم منفصل في مركز بيانات آخر.

إذا كنت لا تريد استخدام خادم مخصص في مركز البيانات الجديد ، يمكنك استخدام نظام المراقبة السحابية. تستخدم شركتنا نظام المراقبة السحابية Zidium ، لكن يمكنك استخدام أي نظام مراقبة آخر. تكلفة نظام المراقبة السحابية أقل من استئجار خادم جديد.

التوصيات:

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

, ! , . , , .

حظا سعيدا