مقدمة حول مراقبة سلامة Service Fabric

مقالة
06/01/2023

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

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

راجع هذه الصفحة للحصول على فيديو تدريبي يصف نموذج سلامة Service Fabric وكيفية استخدامه:

ملاحظة

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

مخزن السلامة

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

الكيانات السليمة والتدرج الهرمي

يتم تنظيم الكيانات السليمة في تدرج هرمي منطقي يسجل التفاعلات والتبعيات بين مختلف الكيانات. يقوم مخزن السلامة تلقائيًا بإنشاء الكيانات السليمة والتدرج الهرمي استنادًا إلى التقارير المستلمة من مكونات Service Fabric.

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

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

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

الكيانات السليمة هي:

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

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

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

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

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

الحالات الصحية

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

حالات السلامة الممكنة هي:

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

نهج السلامة

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

ملاحظة

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

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

نهج السلامة لنظام المجموعة

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

ويتضمن نهج السلامة للمجموعات ما يلي:

ConsiderWarningAsError. تحديد ما إذا كان يجب التعامل مع تقارير الحماية التحذيرية على أنها أخطاء أثناء تقييم السلامة. الافتراضي: False.
MaxPercentUnhealthyApplications. يحدد النسبة المئوية القصوى المسموح بها للتطبيقات التي يمكن أن تكون غير سليمة قبل اعتبار نظام المجموعة على أنه خطأ.
MaxPercentUnhealthyNodes. يحدد النسبة المئوية القصوى المسموح بها للعقد التي يمكن أن تكون غير سليمة قبل اعتبار نظام المجموعة على أنه خطأ. في أنظمة المجموعات الكبيرة، تكون بعض العقد دائمًا معطلة أو خارج الخدمة للإصلاح، لذلك يجب تكوين هذه النسبة لتحمل ذلك.
ApplicationTypeHealthPolicyMap. يمكن استخدام خريطة نهج السلامة لنوع التطبيق أثناء تقييم سلامة نظام المجموعة لوصف أنواع التطبيقات الفردية. بشكل افتراضي، يتم وضع جميع التطبيقات في تجمع وتقييمها باستخدام MaxPercentUnhealthyApplications. إذا كان يجب التعامل مع بعض أنواع التطبيقات بشكل مختلف، يمكن إخراجها من التجمع العمومي. بدلاً من ذلك، يتم تقييمها مقابل النسب المئوية المقترنة باسم نوع تطبيقها في الخريطة. على سبيل المثال، في مجموعة هناك الآلاف من التطبيقات من أنواع مختلفة، وعدد قليل من مثيلات تطبيق التحكم من نوع تطبيق خاص. يجب ألا تكون تطبيقات التحكم خطأ أبدًا. يمكنك تحديد تطبيقات MaxPercentUnhealthyApps العامة إلى 20% لتحمل بعض حالات الفشل، ولكن بالنسبة لنوع التطبيق "ControlApplicationType" قم بتعيين MaxPercentUnhealthyApplications إلى 0. وبهذه الطريقة، إذا كانت بعض التطبيقات العديدة غير سليمة، ولكن أقل من النسبة المئوية العمومية غير السليمة، فسيتم تقييم نظام المجموعة إلى «تحذير». لا تؤثر حالة سلامة التحذير على ترقية نظام المجموعة أو المراقبة الأخرى التي يتم تشغيلها بواسطة حالة السلامة «خطأ». ولكن حتى تطبيق تحكم واحد عن طريق الخطأ من شأنه أن يجعل نظام المجموعة غير سليم، مما يؤدي إلى التراجع أو إيقاف ترقية نظام المجموعة مؤقتاً، اعتمادًا على تكوين الترقية. بالنسبة لأنواع التطبيقات المعرفة في الخريطة، يتم إخراج جميع مثيلات التطبيقات من مجموعة التطبيقات العمومية. ويتم تقييمها استناداً إلى العدد الإجمالي لتطبيقات نوع التطبيق، باستخدام MaxPercentUnhealthyApplications المحدد من المخطط. تبقى جميع التطبيقات المتبقية في نظام المجموعة العمومي، ويتم تقييمها باستخدام MaxPercentUnhealthyApplications.

يعبر المثال التالي عن مقتطف من بيان نظام مجموعة. لتحديد الإدخالات في مخطط نوع التطبيق، ابدأ اسم المعلمة بـ "ApplicationTypeMaxPercentUnhealthyApplications-"، متبوعًا باسم نوع التطبيق.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="ApplicationTypeMaxPercentUnhealthyApplications-ControlApplicationType" Value="0" />
  </Section>
</FabricSettings>
```
NodeTypeHealthPolicyMap. يمكن استخدام مخطط نهج السلامة لنوع العقدة أثناء تقييم سلامة نظام المجموعة لوصف أنواع العقد الخاصة. يتم تقييم أنواع العقد مقابل النسب المئوية المقترنة باسم نوع العقدة في الخريطة. لا يؤثر تعيين هذه القيمة على المجموعة العمومية من العقد المستخدمة لـ MaxPercentUnhealthyNodes. على سبيل المثال، تحتوي المجموعة على مئات العقد من أنواع مختلفة، وعدد قليل من أنواع العقد التي تستضيف أعمالاً هامة. لا ينبغي أن تكون أي عقد في ذلك النوع معطلة. يمكنك تحديد MaxPercentUnhealthyNodes عمومي إلى 20% لتحمل بعض حالات الفشل لجميع العقد، ولكن بالنسبة لنوع العقدة SpecialNodeType، عين MaxPercentUnhealthyNodes إلى القيمة 0. وبهذه الطريقة، إذا كانت بعض العقد العديدة غير سليمة ولكنها أقل من النسبة المئوية العمومية غير السليمة، فسيتم تقييم نظام المجموعة على أنه بالحالة «تحذير». لا تؤثر حالة السلامة "تحذير" على ترقية نظام المجموعة أو المراقبة الأخرى التي يتم تشغيلها بواسطة حالة السلامة «خطأ». ولكن حتى عقدة واحدة من النوع SpecialNodeType بالحالة «خطأ» من شأنها أن تجعل نظام المجموعة غير سليم، وتؤدي إلى التراجع أو إيقاف ترقية نظام المجموعة مؤقتاً، اعتمادا على تكوين الترقية. وعلى العكس من ذلك، سيؤدي تعيين العقد العمومية MaxPercentUnhealthyNodes إلى 0 وتعيين النسبة المئوية القصوى للعقد غير السليمةSpecialNodeType على 100 مع عقدة واحدة من النوع SpecialNodeType في حالة «خطأ» إلى استمرار وضع نظام المجموعة في حالة خطأ لأن القيد العام يكون أكثر صرامة في هذه الحالة.

يعبر المثال التالي عن مقتطف من بيان نظام مجموعة. لتحديد الإدخالات في خريطة نوع العقدة، ابدأ اسم المعلمة بـ "NodeTypeMaxPercentUnhealthyNodes-"، متبوعًا باسم نوع العقدة.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="NodeTypeMaxPercentUnhealthyNodes-SpecialNodeType" Value="0" />
  </Section>
</FabricSettings>
```

نهج سلامة التطبيق

يصف نهج سلامة التطبيق كيفية إجراء تقييم للأحداث وتجميع الحالات التابعة للتطبيقات وعناصرها التابعة. يمكن تعريفه في بيان التطبيق، ApplicationManifest.xml، في حزمة التطبيق. إذا لم يتم تحديد أي نهج، يفترض Service Fabric أن الكيان غير سليم إذا كان لديه تقرير حماية أو عنصر تابع في حالة «تحذير» أو «خطأ». النهج القابلة للتكوين هي:

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

نهج السلامة لنوع الخدمة

يحدد نهج السلامة لنوع الخدمة كيفية تقييم وتجميع الخدمات والعناصر التابعة للخدمات. يحتوي النهج على:

MaxPercentUnhealthyPartitionsPerService. يحدد الحد الأقصى للنسبة المئوية المسموح بها من الأقسام غير السليمة قبل اعتبار الخدمة غير سليمة. النسبة المئوية الافتراضية: صفر.
MaxPercentUnhealthyReplicasPerPartition. يحدد الحد الأقصى المسموح به من النسخ المتماثلة غير السليمة قبل اعتبار القسم غير سليم. النسبة المئوية الافتراضية: صفر.
MaxPercentUnhealthyServices. يحدد الحد الأقصى للنسبة المئوية المسموح بها من الخدمات غير السليمة قبل اعتبار التطبيق غير سليم. النسبة المئوية الافتراضية: صفر.

يعد المثال التالي مقتطفًا من بيان تطبيق:

    <Policies>
        <HealthPolicy ConsiderWarningAsError="true" MaxPercentUnhealthyDeployedApplications="20">
            <DefaultServiceTypeHealthPolicy
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="10"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="FrontEndServiceType"
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="20"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="BackEndServiceType"
                   MaxPercentUnhealthyServices="20"
                   MaxPercentUnhealthyPartitionsPerService="0"
                   MaxPercentUnhealthyReplicasPerPartition="0">
            </ServiceTypeHealthPolicy>
        </HealthPolicy>
    </Policies>

تقييم السلامة

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

تجميع تقارير الحماية

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

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

تجميع تقرير الحماية مع تقرير الخطأ.

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

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

تجميع تقرير الحماية مع تقرير تحذير و

تجميع تقرير السلامة مع تقرير تحذير، وتعيين ConsiderWarningAsError إلى false (افتراضي).

تجميع سلامة العناصر التابعة

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

التجميع الصحي للكيانات التابعة.

تجميع العناصر التابعة على أساس نهج السلامة.

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

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

تقارير الحماية

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

لإرسال بيانات السلامة إلى مخزن السلامة، يحتاج المراسل إلى تحديد الكيان المتأثر وإنشاء تقرير حماية. لإرسال التقرير، استخدم واجهة برمجة تطبيقات FabricClient.HealthClient.ReportHealthHealth، أو قم بالإبلاغ عن واجهات برمجة تطبيقات السلامة المكشوفة على عناصر Partition أو CodePackageActivationContext، أو أوامر cmdlets لـ PowerShell، أو REST.

تقارير الحماية

تحتوي تقارير الحماية لكل كيان من الكيانات في نظام المجموعة على المعلومات التالية:

SourceId. سلسلة تحدد بشكل فريد مراسل حدث السلامة.
معرف الكيان. يحدد الكيان الذي يتم فيه تطبيق التقرير. وهو يختلف بناء على نوع الكيان:
- نظام المجموعة. لا شيء
- العقدة. اسم العقدة (سلسلة).
- التطبيق. اسم التطبيق (URI). يمثل اسم مثيل التطبيق الذي تم توزيعه في نظام المجموعة.
- الخدمة. اسم الخدمة (URI). يمثل اسم مثيل الخدمة الذي تم توزيعه في نظام المجموعة.
- القسم. معرف القسم (GUID). يمثل المعرف الفريد للقسم.
- النسخة المتماثلة. معرف النسخة المتماثلة للخدمة ذات الحالة أو معرف مثيل الخدمة عديم الحالة (INT64).
- DeployedApplication. اسم التطبيق (URI) واسم العقدة (سلسلة).
- DeployedServicePackage. اسم التطبيق (URI) واسم العقدة (سلسلة) واسم بيان الخدمة (سلسلة).
الخاصية. سلسلة (وليست قائمة تعداد ثابتة) تسمح للمراسل بتصنيف حدث السلامة لخاصية معينة للكيان. على سبيل المثال، يمكن للمراسل (أ) الإبلاغ عن سلامة خاصية "التخزين" لـ Node01، ويمكن للمراسل (ب) الإبلاغ عن حالة الخاصية "الاتصال" لـ Node01. في مخزن السلامة، يتم التعامل مع هذه التقارير كأحداث سلامة منفصلة لكيان Node01.
الوصف. سلسلة تسمح للمراسل بتقديم معلومات مفصلة حول حدث السلامة. SourceId، وProperty، وHealthState يجب أن تصف التقرير بالكامل. يضيف الوصف معلومات يمكن قراءتها من قبل الإنسان حول التقرير. يسهل النص على المسؤولين والمستخدمين فهم تقرير السلامة.
HealthState. قائمة تعداد تصف الحالة الصحية للتقرير. القيم المقبولة هي «جيد» و«تحذير» و«خطأ».
TimeToLive. فترة زمنية تشير إلى مدة صلاحية تقرير الحماية. إلى جانب RemoveWhenExpended، فإنه يتيح لمخزن السلامة معرفة كيفية تقييم الأحداث منتهية الصلاحية. بشكل افتراضي، تكون القيمة غير محدودة، ويكون التقرير صالحاً إلى الأبد.
RemoveWhenExpired. منطقي. إذا تم تعيينه إلى true، تتم إزالة تقرير الحماية منتهي الصلاحية تلقائياً من مخزن السلامة، ولا يؤثر التقرير على تقييم سلامة الكيان. يستخدم عندما يكون التقرير صالحاً لفترة زمنية محددة فقط، ولا يحتاج المراسل إلى مسحه صراحة. كما أنه يستخدم لحذف التقارير من مخزن السلامة (على سبيل المثال، يتم تغيير هيئة مراقبة وتتوقف عن إرسال التقارير بالمصدر السابق والخاصية السابقة). يمكنه إرسال تقرير مع قيمة قصيرة المدة لإعداد TimeToLive، جنباً إلى جنب مع RemoveWhenExpired لمسح أي حالة سابقة من مخزن السلامة. إذا تم تعيين القيمة إلى false، يتم التعامل مع التقرير منتهي الصلاحية على أنه خطأ في تقييم السلامة. تشير القيمة false لمخزن السلامة إلى أنه يجب على المصدر الإبلاغ بشكل دوري عن هذه الخاصية. إذا لم يحدث ذلك، يجب أن يكون هناك خطأ ما في هيئة المراقبة. يتم تسجيل سلامة هيئة المراقبة من خلال اعتبار الحدث «خطأ».
SequenceNumber. عدد صحيح موجب يحتاج إلى زيادة مستمرة، وهو يمثل ترتيب التقارير. يتم استخدامه من قبل مخزن السلامة للكشف عن التقارير القديمة التي يتم استلامها في وقت متأخر بسبب تأخيرات الشبكة أو غيرها من المشكلات. يتم رفض التقرير إذا كان رقم التسلسل أقل من أو يساوي أحدث رقم تم تطبيقه لنفس الكيان والمصدر والخاصية. إذا لم يتم تحديده، يتم إنشاء رقم التسلسل تلقائياً. من الضروري وضع رقم التسلسل فقط عند الإبلاغ عن انتقالات الحالة. في هذه الحالة، يحتاج المصدر إلى تذكر التقارير التي أرسلها والاحتفاظ بالمعلومات للاسترداد عند تجاوز الفشل.

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

أحداث الحماية

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

تحتوي بيانات التعريف المضافة على:

SourceUtcTimestamp. الوقت الذي تم فيه منح التقرير لعميل السلامة (التوقيت العالمي المتفق عليه).
LastModifiedUtcTimestamp. الوقت الذي تم فيه تعديل التقرير آخر مرة على جانب الخادم (التوقيت العالمي المتفق عليه).
IsExpired. علامة للإشارة إلى ما إذا كانت صلاحية التقرير قد انتهت عند تنفيذ الاستعلام بواسطة مخزن السلامة. يمكن انتهاء صلاحية الحدث فقط إذا كان RemoveWhenExpired بالقيمة «false». وإلا، فلن يتم إرجاع الحدث عن طريق الاستعلام، وتتم إزالته من المخزن.
LastOkTransitionAt، LastWarningTransitionAt، LastErrorTransitionAt. آخر مرة لانتقالات جيد / تحذير / خطأ. تعطي هذه الحقول تاريخ انتقالات الحالة الصحية للحدث.

يمكن استخدام حقول انتقال الحالة للحصول على تنبيهات أكثر ذكاء أو معلومات عن أحداث الحماية "السابقة". وتقوم بتمكين سيناريوهات مثل:

التنبيه عندما يكون الموقع في حالة تحذير/خطأ لأكثر من X دقيقة. التحقق من الحالة لفترة من الوقت يتجنب التنبيهات بشأن الأحوال المؤقتة. على سبيل المثال، يمكن ترجمة تنبيه إذا كانت حالة السلامة تحذر لأكثر من خمس دقائق إلى (HealthState == Warning and Now - LastWarningTransitionTime > 5 دقائق).
التنبيه فقط عند تغير الأحوال في آخر X دقيقة. إذا كان هناك خطأ بالفعل في أحد التقارير قبل الوقت المحدد، فيمكن تجاهله لأنه تم الإبلاغ عنه مسبقًا بالفعل.
إذا كانت الخاصية تقوم بالتبديل بين التحذير والخطأ، فحدد المدة التي ظلت فيها بدون حماية (أي أنها ليست بحالة جيدة). على سبيل المثال، يمكن ترجمة تنبيه إذا لم تكن الخاصية محمية لأكثر من خمس دقائق إلى (HealthState! = Ok and Now - LastOkTransitionTime > 5 دقائق).

مثال: الإبلاغ عن سلامة التطبيق وتقييمها

يرسل المثال التالي تقرير حماية من خلال PowerShell على التطبيق fabric:/WordCount من المصدر MyWatchdog. يحتوي تقرير الحماية على معلومات حول "توافر" خاصية السلامة في حالة سليمة خاطئة، مع قيمة لا نهائية لـ TimeToLive. ثم يقوم بالاستعلام عن سلامة التطبيق، والتي ترجع أخطاء حالة السلامة المجمعة وأحداث السلامة المبلغ عنها في قائمة أحداث السلامة.

PS C:\> Send-ServiceFabricApplicationHealthReport –ApplicationName fabric:/WordCount –SourceId "MyWatchdog" –HealthProperty "Availability" –HealthState Error

PS C:\> Get-ServiceFabricApplicationHealth fabric:/WordCount -ExcludeHealthStatistics


ApplicationName                 : fabric:/WordCount
AggregatedHealthState           : Error
UnhealthyEvaluations            :
                                  Error event: SourceId='MyWatchdog', Property='Availability'.

ServiceHealthStates             :
                                  ServiceName           : fabric:/WordCount/WordCountService
                                  AggregatedHealthState : Error

                                  ServiceName           : fabric:/WordCount/WordCountWebService
                                  AggregatedHealthState : Ok

DeployedApplicationHealthStates :
                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_0
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_2
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_3
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_4
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_1
                                  AggregatedHealthState : Ok

HealthEvents                    :
                                  SourceId              : System.CM
                                  Property              : State
                                  HealthState           : Ok
                                  SequenceNumber        : 360
                                  SentAt                : 3/22/2016 7:56:53 PM
                                  ReceivedAt            : 3/22/2016 7:56:53 PM
                                  TTL                   : Infinite
                                  Description           : Application has been created.
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Error->Ok = 3/22/2016 7:56:53 PM, LastWarning = 1/1/0001 12:00:00 AM

                                  SourceId              : MyWatchdog
                                  Property              : Availability
                                  HealthState           : Error
                                  SequenceNumber        : 131032204762818013
                                  SentAt                : 3/23/2016 3:27:56 PM
                                  ReceivedAt            : 3/23/2016 3:27:56 PM
                                  TTL                   : Infinite
                                  Description           :
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Ok->Error = 3/23/2016 3:27:56 PM, LastWarning = 1/1/0001 12:00:00 AM

استخدام نموذج السلامة

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

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