الخادم يعمل؛ هل الخدمة تعمل فعلًا؟
تجاوز اختبار ping بسيناريو حقيقي للمستخدم وفحص اعتماد أساسي وتنبيه يمكن التصرف بناءً عليه لتقييم سلامة الخدمة.

مصدر المفهوم: Monitoring Distributed Systems Google SRE. وخطة الرصد والمثال الوارد أدناه عرض مستقل لبيئة صغيرة.
يمكن للخادم أن يرد على الرنين، ولكن لا يمكن للمستعمل فتح تقرير. إنه ليس تناقضاً، فقد قيسنا شيئين مختلفين. وفي رأيي، ينبغي أن يعطي الرصد إجابة واضحة واحدة على الأقل للسؤال: " لا يزال عمل المستخدم الرئيسي قائما؟ "
نحدد الصحة للطبقة
| استعراض. | أي عروض؟ |
|---|---|
| استجابة الشبكة. | جزء من الوصول للمضيف |
| وصلة الميناء | من الممكن التواصل مع المستمع |
| إجابة بسيطة على البرنامج | العيش على الطريق المفحص |
| أخذ عمل حقيقي. | نجاح نفس سيناريو المستخدم |
لا أحد وحده يضمن صحة النظام بأكمله بل إن الاستجابة الناجحة من جانب مبادرة HTTP قد تكون مجرد صفحة خطأ جيدة من البرنامج؛ وتحديد المحتوى الذي تتوقعه ووقت الاستجابة.
ابدأ بسيناريو صغير
وفي مثال افتراضي، نرصد نظام الإبلاغ. نحن نختار حساب اختبار مع الحد الأدنى من الوصول، تقرير صغير مع بيانات غير حساسة ونتيجة يمكن التعرف عليها. ينبغي أن يكون الاختبار منخفض التكلفة، ولا تكشف المعلومات السرية في السجل ولا تجعل سجلا تشغيليا جديدا.
إذا كان البرنامج منفصلاً، قم بقياس معالته الأساسية. غير أن الاستعراض الحي الذي تجريه العملية لجميع الخدمات الخارجية قد يؤدي إلى إعادة إطلاق غير مجدية عندما تفشل المعالين. فالقرار " هل هو على استعداد لقبول الطلب؟ "
ويجب أن يكون للتحذيرات وجهة وإجراءات.
- ماذا فشل للمستعمل؟
- متى وأين يرون؟
- من المسؤول عن الإجابة وما هو أول استعراض مقترح؟
إن اقتراحي يتمثل في توجيه إنذار مفيد أولا ثم زيادة عدد الخرائط. لوحة أن جميع الأضواء خضراء لكن المستعمل غير راضٍ ربما سيراقب السؤال الخطأ
الدراسة ذات الصلة: خدمة وثائقية.


