إضافة تقارير صحة Service Fabric المخصصة
يقدم Azure Service Fabric نموذج صحة مصمما لوضع علامة على حالات المجموعة والتطبيق غير الصحية على كيانات معينة. يستخدم نموذج الصحة مراقبي الصحة (مكونات النظام ومراقبين النظام). يتمثل الهدف في التشخيص والإصلاح السهل والسريع. يحتاج كتاب الخدمة إلى التفكير مقدماً بشأن الصحة. يجب الإبلاغ عن أي حالة يمكن أن تؤثر على الصحة، خاصةً إذا كانت يمكن أن تساعد في الإبلاغ عن المشاكل القريبة من الأصل. يمكن للمعلومات الصحية توفير الوقت والجهد في تصحيح الأخطاء والفحص. تكون الفائدة واضحة بشكل خاص بمجرد تشغيل الخدمة وتشغيلها على نطاق واسع على السحابة (خاصة أو Azure).
يراقب مراقبو Service Fabric الحالات المحددة للاهتمام. ويبلغون عن تلك الظروف استناداً إلى وجهة نظرهم المحلية. يجمع مخزن السلامة بيانات السلامة التي يرسلها جميع المراقبين لتحديد ما إذا كانت الكيانات تتمتع بحالة جيدة عمومًا أم لا. يهدف النموذج إلى أن يكون غنياً ومرناً وسهل الاستخدام. تحدد جودة تقارير الحماية دقة عرض سلامة نظام المجموعة. يمكن أن تؤثر النتائج الإيجابية الخاطئة التي تظهر بشكل خاطئ مشكلات غير صحية سلبًا على الترقيات أو الخدمات الأخرى التي تستخدم بيانات السلامة. ومن الأمثلة على هذه الخدمات خدمات الإصلاح وآليات التنبيه. لذلك، توجد حاجة ماسة إلى بعض التفكير لتقديم تقارير تلتقط الحالات ذات الأهمية بأفضل طريقة ممكنة.
لتصميم وتنفيذ تقارير الصحة، يجب على مراقبي النظام ومكونات النظام القيام بما يلي:
- تحديد الحالة التي يهتمون بها، والطريقة التي تتم مراقبتها بها، والتأثير على وظيفة المجموعة أو التطبيق. بناءً على هذه المعلومات، حدد خاصية تقارير الصحة والحالة الصحية.
- تحديد الكيان الذي ينطبق عليه التقرير.
- تحديد مكان إعداد التقارير، من داخل الخدمة أو من مراقب نظام داخلي أو خارجي.
- حدد مصدراً يستخدم لتحديد هوية المراقب.
- اختر استراتيجية إعداد التقارير، إما بشكل دوري أو عند الانتقالات. يوصى باختيار طريقة إعداد التقارير، بشكل دوري، لأنها تتطلب تعليمات برمجية أبسط وأقل عرضة للأخطاء.
- حدد المدة التي يجب أن يبقى فيها التقرير عن الحالات غير الصحية في متجر الصحة وكيفية مسحه. باستخدام هذه المعلومات، حدد وقت بقاء التقرير وسلوك الإزالة عند انتهاء الصلاحية.
كما ذكرنا، يمكن إجراء الإبلاغ من الأماكن التالية:
- النسخة المتماثلة لخدمة Service Fabric المراقبة.
- يتم نشر مراقبي النظام الداخليين كخدمة Service Fabric (على سبيل المثال، خدمة Service Fabric بلا حالة التي تراقب الحالات وتصدر التقارير). يمكن نشر مراقبي النظام في جميع العقد أو يمكن أن تكون مرتبطة بالخدمة المراقبة.
- مراقبي النظام الداخليين الذين يعملون على عقد Service Fabric ولكنهم لم يتم تنفيذهم كخدمات Service Fabric.
- مراقبي النظام الخارجيون الذين يفحصون المورد من خارج مجموعة Service Fabric (على سبيل المثال، خدمة المراقبة مثل Gomez).
ملاحظة
جاهزة للاستخدام، يتم ملء المجموعة بتقارير الصحة التي ترسلها مكونات النظام. اقرأ المزيد في استخدام تقارير صحة النظام لاستكشاف الأخطاء وإصلاحها. يجب إرسال تقارير المستخدم على كيانات الصحة التي تم إنشاؤها بالفعل بواسطة النظام.
بمجرد أن يصبح تصميم تقارير الصحة واضحاً، يمكن إرسال تقارير الصحة بسهولة. يمكنك استخدام FabricClient للإبلاغ عن حالة المجموعة إذا كانت المجموعة غير آمنة أو إذا كان عميل Fabric يتمتع بامتيازات المسؤول. يمكن إعداد التقارير من خلال واجهة برمجة التطبيقات باستخدام FabricClient.HealthManager.ReportHealth أو من خلال PowerShell أو من خلال REST. تقارير جمع مكتبات التكوين لتحسين الأداء.
ملاحظة
حالة التقرير متزامنة، ولا تمثل سوى أعمال التحقق من الصحة من جانب العميل. لا تعني حقيقة قبول التقرير من قِبل عميل الصحة أو العناصر Partition أو CodePackageActivationContext أنه تم تطبيقه في المتجر. يتم إرساله بشكل غير متزامن وربما يتم تجميعه مع تقارير أخرى. قد لا تزال المعالجة على الخادم تفشل: قد يكون رقم التسلسل تالفاً، أو قد تم حذف الكيان الذي يجب تطبيق التقرير عليه، وما إلى ذلك.
عميل الصحة
يتم إرسال تقارير الصحة إلى مدير الصحة من خلال عميل صحة موجود في عميل Fabric. يقوم مدير الصحة بحفظ التقارير في مخزن الصحة. يمكن تكوين عميل الصحة باستخدام الإعدادات التالية:
- HealthReportSendInterval: التأخير بين وقت إضافة التقرير إلى العميل ووقت إرساله إلى مدير الصحة. يُستخدم لتجميع التقارير في رسالة واحدة، بدلاً من إرسال رسالة واحدة لكل تقرير. يعمل التجميع على تحسين الأداء. الإعداد الافتراضي: 30 ثانية.
- HealthReportRetrySendInterval: الفاصل الزمني الذي يقوم فيه عميل الصحة بإعادة إرسال تقارير الصحة المتراكمة إلى مدير الصحة. الإعداد الافتراضي: 30 ثانية، الحد الأدنى: 1 ثانية.
- HealthOperationTimeout: فترة المهلة لإرسال رسالة تقرير إلى مدير الصحة. إذا انتهت مهلة الرسالة، يقوم عميل الصحة بإعادة المحاولة حتى يؤكد مدير الصحة أن التقرير قد تمت معالجته. الإعداد الافتراضي: دقيقتان.
ملاحظة
عندما يتم تجميع التقارير، يجب أن يظل عميل Fabric مستمراً لـ HealthReportSendInterval على الأقل لضمان إرسالها. في حالة فقدان الرسالة أو تعذر على مدير الصحة تطبيقها بسبب أخطاء مؤقتة، يجب إبقاء عميل Fabric مستمراً لفترة أطول لإعطائه فرصة لإعادة المحاولة.
يأخذ التخزين المؤقت على العميل الطابع الفريد للتقارير في الاعتبار. على سبيل المثال، إذا كان مراقب سيئ يُبلغ عن 100 تقرير في الثانية عن نفس الخاصية لنفس الكيان، فسيتم استبدال التقارير بالإصدار الأخير. يوجد تقرير واحد على الأكثر في قائمة انتظار العميل. في حالة تكوين التجميع، يكون عدد التقارير المرسلة إلى مدير الصحة واحداً فقط لكل فترة إرسال. يعد هذا التقرير هو آخر تقرير مضاف، ويعكس الحالة الحالية للكيان.
حدد معلمات التكوين عند إنشاء FabricClient عن طريق تمرير FabricClientSettings مع القيم المطلوبة للإدخالات المتعلقة بالصحة.
ينشئ المثال التالي عميل Fabric ويحدد أنه يجب إرسال التقارير عند إضافتها. في المهلات والأخطاء التي يمكن إعادة معالجتها، تحدث عمليات إعادة المحاولة كل 40 ثانية.
var clientSettings = new FabricClientSettings()
{
HealthOperationTimeout = TimeSpan.FromSeconds(120),
HealthReportSendInterval = TimeSpan.FromSeconds(0),
HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);
نوصي بالاحتفاظ بالإعدادات الافتراضية لعميل Fabric، والتي تم تعيين HealthReportSendInterval على 30 ثانية. يضمن هذا الإعداد الأداء الأمثل بسبب التجمع. بالنسبة إلى التقارير المهمة التي يجب إرسالها في أسرع وقت ممكن، استخدم HealthReportSendOptions مع true فوري في واجهة برمجة تطبيقات FabricClient.HealthClient.ReportHealth. تتجاوز التقارير الفورية الفاصل الزمني للدفع. استخدم هذه العلامة بعناية؛ نريد الاستفادة من تجميع عميل الصحة كلما أمكن ذلك. يكون الإرسال الفوري مفيداً أيضاً عند إغلاق عميل Fabric (على سبيل المثال، حددت العملية حالة غير صالحة وتحتاج إلى إيقاف التشغيل لمنع الآثار الجانبية). يضمن أفضل جهد لإرسال التقارير المتراكمة. عند إضافة تقرير واحد بعلامة فورية، يقوم عميل الصحة بتجميع كافة التقارير المتراكمة منذ آخر إرسال.
يمكن تحديد نفس المعلمات عند إنشاء اتصال بمجموعة من خلال PowerShell. في المثال التالي، يتم بدء اتصال بنظام مجموعة محلية:
PS C:\> Connect-ServiceFabricCluster -HealthOperationTimeoutInSec 120 -HealthReportSendIntervalInSec 0 -HealthReportRetrySendIntervalInSec 40
True
ConnectionEndpoint :
FabricClientSettings : {
ClientFriendlyName : PowerShell-1944858a-4c6d-465f-89c7-9021c12ac0bb
PartitionLocationCacheLimit : 100000
PartitionLocationCacheBucketCount : 1024
ServiceChangePollInterval : 00:02:00
ConnectionInitializationTimeout : 00:00:02
KeepAliveInterval : 00:00:20
HealthOperationTimeout : 00:02:00
HealthReportSendInterval : 00:00:00
HealthReportRetrySendInterval : 00:00:40
NotificationGatewayConnectionTimeout : 00:00:00
NotificationCacheUpdateTimeout : 00:00:00
}
GatewayInformation : {
NodeAddress : localhost:19000
NodeId : 1880ec88a3187766a6da323399721f53
NodeInstanceId : 130729063464981219
NodeName : Node.1
}
على غرار واجهة برمجة التطبيقات، يمكن إرسال التقارير باستخدام -Immediate مفتاح التبديل ليتم إرسالها على الفور، بغض النظر عن قيمة HealthReportSendInterval.
بالنسبة ل REST، يتم إرسال التقارير إلى بوابة Service Fabric، التي تحتوي على عميل Fabric داخلي. بشكل افتراضي، يتم تكوين هذا العميل لإرسال تقارير مجمعة كل 30 ثانية. يمكنك تغيير الفاصل الزمني الدفعي باستخدام إعداد HttpGatewayHealthReportSendInterval تكوين الكتلة في HttpGateway. كما ذكرنا، فإن الخيار الأفضل هو إرسال التقارير مع Immediate true.
ملاحظة
للتأكد من أن الخدمات غير المصرح بها لا يمكنها الإبلاغ عن حالة الكيانات الموجودة في المجموعة، قم بتكوين الخادم لقبول الطلبات من العملاء المؤمّنين فقط. يجب أن يكون الأمان ممكّناً لـ FabricClient المستخدم للإبلاغ حتى تتمكن من الاتصال بالمجموعة (على سبيل المثال، من خلال Kerberos أو مصادقة الشهادة). اقرأ المزيد حول أمان المجموعة.
الإبلاغ من داخل الخدمات ذات الامتيازات المنخفضة
إذا لم يكن لدى خدمات Service Fabric حق وصول المسؤول إلى المجموعة، فيمكنك الإبلاغ عن حالة الكيانات من السياق الحالي من خلال Partition أو CodePackageActivationContext.
- بالنسبة للخدمات بلا حالة، استخدم IStatelessServicePartition.ReportInstanceHealth للإبلاغ عن مثيل الخدمة الحالي.
- بالنسبة للخدمات ذات الحالة الخاصة، استخدم IStatefulServicePartition.ReportReplicaHealth للإبلاغ عن النسخة المتماثلة الحالية.
- استخدم IServicePartition.ReportPartitionHealth للإبلاغ عن كيان القسم الحالي.
- استخدم CodePackageActivationContext.ReportApplicationHealth للإبلاغ عن التطبيق الحالي.
- استخدم CodePackageActivationContext.ReportDeployedApplicationHealth للإبلاغ عن التطبيق الحالي الذي تم نشره على العقدة الحالية.
- استخدم CodePackageActivationContext.ReportDeployedServicePackageHealth للإبلاغ عن حزمة خدمة للتطبيق المنشور على العقدة الحالية.
ملاحظة
داخلياً، يحتفظ كل من Partition و CodePackageActivationContext بعميل صحة تم تكوينه باستخدام الإعدادات الافتراضية. كما هو موضح لعميل الصحة، يتم تجميع التقارير وإرسالها على مؤقت. يجب أن تظل العناصر مستمرة حتى تتاح لك فرصة إرسال التقرير.
يمكنك تحديد HealthReportSendOptions عند إرسال التقارير من خلال Partition وCodePackageActivationContext واجهات برمجة التطبيقات الصحية. إذا كانت لديك تقارير مهمة يجب إرسالها في أسرع وقت ممكن، فاستخدم HealthReportSendOptions مع التقارير الفورية true. تتجاوز التقارير الفورية فترة التجميع لعميل الصحة الداخلي. كما ذكرنا من قبل، استخدم هذه العلامة بحذر؛ نريد الاستفادة من خدمة عملاء الصحة كلما أمكن ذلك.
تصميم تقارير الصحة
تتمثل الخطوة الأولى في إنشاء تقارير عالية الجودة في تحديد الحالات التي يمكن أن تؤثر على صحة الخدمة. يمكن أن تساعد أي حالة في تحديد المشكلات في الخدمة أو المجموعة عند بدئها، أو قبل حدوث المشكلة، يمكن أن توفر مليارات الدولارات. تشمل الفوائد تقليل وقت التعطل، وتقليل قضاء الوقت في ساعات متأخرة في فحص المشكلات وإصلاحها، وزيادة رضا العملاء.
بمجرد تحديد الحالات، يحتاج كتاب مراقبي النظام إلى معرفة أفضل طريقة لمراقبتها لتحقيق التوازن بين النفقات الإضافية والفائدة. على سبيل المثال، ضع في اعتبارك خدمة تقوم بإجراء عمليات حسابية معقدة تستخدم بعض الملفات المؤقتة على مشاركة. يمكن ل مراقب النظام مراقبة الحصة لضمان توفر مساحة كافية. يمكنه الاستماع إلى إشعارات تغييرات الملف أو الدليل. يمكنه الإبلاغ عن تحذير إذا تم الوصول إلى حد مقدماً، والإبلاغ عن خطأ إذا كانت المشاركة ممتلئة. في حالة التحذير، يمكن لنظام إصلاح بدء تنظيف الملفات القديمة على المشاركة. عند حدوث خطأ، يمكن لنظام الإصلاح نقل النسخة المتماثلة للخدمة إلى عقدة أخرى. لاحظ كيف يتم وصف الحالة من حيث الصحة: الحالة التي يمكن اعتبارها صحية (صحي) أو غير صحية (تحذير أو خطأ).
بمجرد تعيين تفاصيل المراقبة، يحتاج كاتب مراقب النظام إلى معرفة كيفية تنفيذ المراقبة. إذا كان من الممكن تحديد الحالات من داخل الخدمة، فيمكن أن يكون مراقب النظام جزءاً من الخدمة الخاضعة للمراقبة نفسها. على سبيل المثال، يمكن لتعليمات الخدمة البرمجية التحقق من استخدام المشاركة، ثم الإبلاغ في كل مرة يتم فيها محاولة كتابة ملف. وتتمثل ميزة هذا النهج في أن إعداد التقارير بسيط. يجب توخي الحذر لمنع أخطاء مراقب النظام من التأثير على وظائف الخدمة.
لا يعد الإبلاغ من داخل الخدمة الخاضعة للمراقبة دائماً خياراً. قد لا يتمكن مراقب النظام داخل الخدمة من اكتشاف الحالات. قد لا يكون لديه المنطق أو البيانات لاتخاذ القرار. قد تكون النفقات الإضافية لمراقبة الحالات مرتفعة. قد لا تكون الحالات أيضا خاصة بالخدمة، ولكنها تؤثر بدلاً من ذلك على التفاعلات بين الخدمات. يتمثل الخيار الآخر في أن يكون لدينا مراقبي نظام في المجموعة كعمليات منفصلة. يراقب مراقبي النظام الحالات وتبلغ عنها، دون التأثير على الخدمات الرئيسية بأي شكل من الأشكال. على سبيل المثال، يمكن تنفيذ مراقب النظام هذا كخدمات بلا حالة في نفس التطبيق، أو نشرها على جميع العقد أو على نفس العقد مثل الخدمة.
في بعض الأحيان، لا يكون مراقب النظام الذي يعمل في المجموعة خياراً أيضاً. إذا كانت الحالة المراقبة هي توفر الخدمة أو وظائفها كما يراها المستخدمون، فمن الأفضل أن يكون مراقبي النظام في نفس مكان عملاء المستخدم. وهناك، يمكنهم اختبار العمليات بالطريقة نفسها التي سيستدعي بها المستخدمون. على سبيل المثال، يمكنك الحصول على مراقب نظام يبقى خارج المجموعة، ويصدر طلبات إلى الخدمة، ويتحقق من زمن انتقال النتيجة وصحتها. (بالنسبة لخدمة الآلة الحاسبة، على سبيل المثال، هل يقوم 2+2 بإرجاع 4 في فترة زمنية معقولة؟)
بمجرد الانتهاء من تفاصيل مراقب النظام، يجب أن تقرر معرف المصدر الذي يحدده بشكل فريد. إذا كان هناك مراقبي نظام متعددين من نفس النوع يبقون في المجموعة، فيجب عليهم الإبلاغ عن كيانات مختلفة، أو إذا كانوا يبلغون عن نفس الكيان، فاستخدم معرف مصدر أو خاصية مختلفة. بهذه الطريقة، يمكن أن تتواجد تقاريرهم. يجب أن تلتقط خاصية تقارير الصحة الحالة الخاضعة للمراقبة. (بالنسبة للمثال السابق، يمكن أن تكون الخاصية ShareSize.) إذا تم تطبيق تقارير متعددة على نفس الحالة، فيجب أن تحتوي الخاصية على بعض المعلومات الديناميكية التي تسمح بتواجد التقارير معاً. على سبيل المثال، إذا كانت هناك حاجة إلى مراقبة مشاركات متعددة، يمكن أن يكون اسم الخاصية ShareSize-sharename.
ملاحظة
لا تستخدم المخزن الصحي للاحتفاظ بمعلومات الحالة. يجب الإبلاغ عن المعلومات المتعلقة بالصحة فقط باعتبارها معلومات صحية، لأن هذه المعلومات تؤثر على التقييم الصحي للكيان. لم يتم تصميم المتجر الصحي كمتجر للأغراض العامة. يستخدم منطق التقييم الصحي لتجميع جميع البيانات في الحالة الصحية. لا يؤثر إرسال المعلومات غير المتعلقة بالصحة (مثل الإبلاغ عن الحالة الصحية OK) على الحالة الصحية المجمعة، ولكن يمكن أن يؤثر سلباً على أداء المخزن الصحي.
تتمثل نقطة القرار المحورية التالية في الكيان الذي يجب الإبلاغ عنه. في معظم الأحيان، تحدد الحالة بوضوح الكيان. اختر الكيان بأفضل دقة ممكنة. إذا كانت الحالة تؤثر على جميع النسخ المتماثلة في القسم، فقم بإعداد تقرير عن القسم وليس عن الخدمة. ولكن توجد حالات صعبة تتطلب مزيداً من التفكير. إذا كانت الحالة تؤثر على الكيان، مثل نسخة متماثلة، ولكن الرغبة في وضع علامة على الحالة لأكثر من مدة دورة حياة النسخة المتماثلة، فيجب الإبلاغ عنها في القسم. خلاف ذلك، عند حذف النسخة المتماثلة، يقوم مخزن الصحة بتنظيف جميع تقاريره. يجب على كتّاب مراقب النظام التفكير في دورة حياة الكيان والتقرير. يجب أن يكون واضحاً وقت تنظيف التقرير من المتجر (على سبيل المثال، عندما لا يتم الإبلاغ عن خطأ في كيان ما لم يعد سارياً).
لنلق نظرة على مثال يجمع النقاط التي وصفناها. ضع في اعتبارك تطبيق Service Fabric الذي يتكون من خدمة مستمرة رئيسية الحالة وخدمات ثانوية بلا حالة يتم نشرها على جميع العقد (نوع خدمة ثانوي واحد لكل نوع من المهام). تحتوي الخدمة الرئيسية على قائمة انتظار معالجة تحتوي على أوامر ليتم تنفيذها بواسطة خدمات ثانوية. تعمل الخدمات الثانوية بتنفيذ الطلبات الواردة وإرسال إشارات الاستلام مرة أخرى. ويتمثل أحد الحالات التي يمكن مراقبتها في طول قائمة انتظار المعالجة الرئيسية. إذا وصل طول قائمة الانتظار الرئيسية إلى حد ما، فسيتم الإبلاغ عن تحذير. يشير التحذير إلى أن الخدمات الثانوية لا يمكنها التعامل مع الحمل. إذا وصلت قائمة الانتظار إلى الحد الأقصى للطول وتم إسقاط الأوامر، فسيتم الإبلاغ عن خطأ، حيث يتعذر استرداد الخدمة. يمكن أن تكون التقارير على الخاصية QueueStatus. يعيش مراقب النظام داخل الخدمة، ويتم إرساله بشكل دوري على النسخة المتماثلة الأساسية الرئيسية. مدة الاستمرار دقيقتان، ويتم إرسالها بشكل دوري كل 30 ثانية. إذا تعطل الإعداد الأساسي، فسيتم مسح التقرير تلقائياً من المتجر. إذا كانت النسخة المتماثلة للخدمة قيد التشغيل، ولكنها وصلت إلى طريق مسدود أو بها مشكلات أخرى، فستنتهي صلاحية التقرير في المخزن الصحي. في هذه الحالة، يتم تقييم الكيان بالخطأ.
حالة أخرى يمكن مراقبتها هي وقت تنفيذ المهمة. تقوم الخدمة الرئيسية بتوزيع المهام على الموظفين الثانويين بناءً على نوع المهمة. اعتماداً على التصميم، يمكن للخدمة الرئيسية استقصاء الخدمات الثانوية لحالة المهمة. يمكن أيضاً انتظار الخدمات الثانوية لإرسال إشارات الاستلام عند الانتهاء. في الحالة الثانية، يجب توخي الحذر لاكتشاف المواقف التي تنتهي فيها الخدمات الثانوية أو تفقد الرسائل. يتمثل أحد الخيارات في أن تقوم الخدمات الرئيسية بإرسال طلب اختبار اتصال إلى نفس الخدمات الثانوية، والتي تعيد حالتها. في حالة عدم تلقي أي حالة، تعتبرها الخدمات الثانوية أنها فاشلة وتعيد جدولة المهمة. يفترض هذا السلوك أن المهام خاملة.
يمكن ترجمة الحالة المراقبة كتحذير إذا لم يتم تنفيذ المهمة في وقت معين (t1، على سبيل المثال 10 دقائق). إذا لم تكتمل المهمة في الوقت المناسب (t2، على سبيل المثال 20 دقيقة)، يمكن ترجمة الحالة المراقبة على أنها خطأ. يمكن إعداد هذه التقارير بطرق متعددة:
- تقدم النسخة المتماثلة الأولية الرئيسية تقارير عن نفسها بشكل دوري. يمكنك الحصول على خاصية واحدة لجميع المهام المعلقة في قائمة الانتظار. إذا استغرقت مهمة واحدة على الأقل وقتاً أطول، فإن حالة التقرير في الخاصية PendingTasks هي تحذير أو خطأ بالشكل المناسب. في حالة عدم وجود مهام معلقة أو تم بدء تنفيذ جميع المهام، تكون حالة التقرير على ما يرام. المهام ثابتة. إذا تعطلت المهمة الابتدائية، يمكن أن تستمر المهمة الابتدائية التي تمت ترقيتها حديثاً في تقديم التقارير بشكل صحيح.
- تقوم عملية مراقب نظام أخرى (على السحابة أو في بيئة خارجية) بالتحقق من المهام (من الخارج، بناءً على نتيجة المهمة المطلوبة) لمعرفة ما إذا كانت قد اكتملت أم لا. إذا لم يلتزموا بالحدود، فسيتم إرسال تقرير عن الخدمة الرئيسية. كما يتم إرسال تقرير عن كل مهمة يتضمن معرف المهمة، مثل PendingTask+taskId. يجب إرسال التقارير فقط عن الحالات غير الصحية. اضبط الوقت للاستمرار لبضع دقائق، وحدد التقارير المراد إزالتها عند انتهاء صلاحيتها لضمان التنظيف.
- الخدمات الثانوية التي تقوم بتنفيذ مهمة تقارير عندما تستغرق وقتا أطول من المتوقع لتشغيلها. وتقدم تقارير عن مثيل الخدمة في الخاصية PendingTasks. يحدد التقرير مثيل الخدمة الذي به مشكلات، لكنه لا يلتقط الموقف الذي ينتهي فيه المثيل. يتم تنظيف التقارير بعد ذلك. ويمكنها الإبلاغ عن الخدمة الثانوية. إذا أكملت الخدمات الثانوية المهمة، فإن المثيل الثانوي يمسح التقرير من المخزن. لا يلتقط التقرير الموقف الذي فقدت فيه رسالة الإقرار ولا تنتهي المهمة من وجهة نظر الخدمة الرئيسية.
ومع ذلك، يتم الإبلاغ في الحالات الموضحة أعلاه، ويتم تسجيل التقارير في صحة التطبيق عند تقييم الصحة.
إعداد التقارير بشكل دوري مقابل بشكل انتقالي
باستخدام نموذج تقارير الصحة، يمكن لمراقب النظام إرسال التقارير بشكل دوري أو بشكل انتقالي. تتمثل الطريقة الموصى بها لإعداد تقارير مراقب النظام في إعداد التقارير بشكل دوري، لأن التعليمات البرمجية أبسط بكثير وأقل عرضة للأخطاء. يجب أن يسعى مراقب النظام إلى أن يكون بسيطاً قدر الإمكان لتجنب الأخطاء التي تؤدي إلى ظهور تقارير غير صحيحة. تؤثر التقارير غير الصحية غير الصحيحة على التقييمات الصحية والسيناريوهات بناءً على الصحة، بما في ذلك الترقيات. التقارير الصحية غير الصحيحة تخفي مشكلات في المجموعة، وهو أمر غير مرغوب فيه.
لإعداد التقارير الدورية، يمكن تنفيذ مراقب النظام باستخدام مؤقت. في رد الاتصال بالمؤقت، يمكن لمراقب النظام التحقق من الحالة وإرسال تقرير بناءً على الحالة الحالية. ليست هناك حاجة لمعرفة التقرير الذي تم إرساله مسبقاً أو إجراء أي تحسينات من حيث الرسائل. لدى عميل الصحة منطق تجميع للمساعدة في الأداء. بينما يتم الاحتفاظ بعميل الصحة في حالة استمرار، فإنه يعيد المحاولة داخلياً حتى يتم الاعتراف بالتقرير من قبل المتجر الصحي أو ينشئ مراقب النظام تقريراً جديداً بنفس الكيان والخصائص والمصدر.
يتطلب الإبلاغ عن المراحل الانتقالية معالجة دقيقة للحالة. يراقب مراقب النظام بعض الحالات ويبلغ فقط عندما تتغير الحالات. يتمثل الجانب الإيجابي لهذا النهج في أن هناك حاجة إلى عدد أقل من التقارير. ويتمثل الجانب السلبي في أن منطق مراقب النظام معقد. يجب أن يحافظ مراقب النظام على الحالات أو التقارير، بحيث يمكن فحصها لتحديد تغييرات الحالة. عند تجاوز الفشل، يجب توخي الحذر عند إضافة التقارير، ولكن عند عدم إرسالها بعد إلى المتجر الصحي. يجب أن يكون رقم التسلسل في تزايد مستمر. إذا لم يكن الأمر كذلك، يتم رفض التقارير باعتبارها تالفة. في الحالات النادرة التي يحدث فيها فقدان للبيانات، قد تكون هناك حاجة إلى التزامن بين حالة المراقب وحالة المخزن الصحي.
يعتبر الإبلاغ عن عمليات الانتقال أمراً منطقياً بالنسبة للخدمات التي تقدم تقارير عن نفسها، من خلال Partition أو CodePackageActivationContext. عند إزالة العنصر المحلي (النسخة المتماثلة أو حزمة الخدمة المنشورة/التطبيق المنشور)، تتم أيضاً إزالة جميع تقاريره. هذا التنظيف التلقائي يخفف من الحاجة إلى التزامن بين المراقب والمخزن الصحي. إذا كان التقرير خاصاً بالقسم الأصل أو التطبيق الأصل، فيجب توخي الحذر عند تجاوز الفشل لتجنب التقارير التالفة في المخزن الصحي. يجب إضافة المنطق للحفاظ على الحالة الصحيحة ومسح التقرير من المتجر عند عدم الحاجة إليه.
تنفيذ التقارير الصحية
بمجرد وضوح تفاصيل الكيان والتقرير، يمكن إرسال التقارير الصحية من خلال واجهة برمجة تطبيقات أو PowerShell أو REST.
واجهة برمجة التطبيقات (API)
للإبلاغ من خلال واجهة برمجة التطبيقات، تحتاج إلى إنشاء تقرير صحي خاص بنوع الكيان الذي تريد الإبلاغ عنه. أعط التقرير للعميل الصحي. بدلاً من ذلك، قم بإنشاء معلومات صحية ومررها لأساليب إعداد التقارير الصحيحة في Partition أو CodePackageActivationContext للإبلاغ عن الكيانات الحالية.
يوضح المثال التالي تقارير دورية من مراقب النظام داخل المجموعة. يتحقق مراقب النظام ما إذا كان يمكن الوصول إلى مورد خارجي من داخل العقدة. يتم طلب المورد من خلال بيان الخدمة داخل التطبيق. إذا كان المورد غير متوفر، فلا يزال بإمكان الخدمات الأخرى داخل التطبيق العمل بشكل صحيح. لذلك، يتم إرسال التقرير على كيان حزمة الخدمة المنشورة كل 30 ثانية.
private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });
public static void SendReport(object obj)
{
// Test whether the resource can be accessed from the node
HealthState healthState = this.TestConnectivityToExternalResource();
// Send report on deployed service package, as the connectivity is needed by the specific service manifest
// and can be different on different nodes
var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
ApplicationName,
ServiceManifestName,
NodeName,
new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));
// TODO: handle exception. Code omitted for snippet brevity.
// Possible exceptions: FabricException with error codes
// FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
// FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}
PowerShell
يمكنك إرسال التقارير الصحية من خلال Send-ServiceFabricEntityTypeHealthReport.
يوضح المثال التالي تقارير دورية عن قيم وحدة المعالجة المركزية على العقدة. يجب إرسال التقارير كل 30 ثانية، ولديهم وقت للبقاء لمدة دقيقتين. إذا انتهت صلاحيتها، فلدى المراقب مشاكل، لذلك يتم تقييم العقدة بالخطأ. عندما تكون نسبة استخدام وحدة المعالجة المركزية أعلى من حد معين، فلدى التقرير حالة صحية بالتحذير. عندما تظل نسبة استخدام وحدة المعالجة المركزية فوق الحد لأكثر من الوقت الذي تم تكوينه، فسيتم الإبلاغ عنها على أنها خطأ. خلاف ذلك، يرسل المراقب الحالة الصحية OK.
PS C:\> Send-ServiceFabricNodeHealthReport -NodeName Node.1 -HealthState Warning -SourceId PowershellWatcher -HealthProperty CPU -Description "CPU is above 80% threshold" -TimeToLiveSec 120
PS C:\> Get-ServiceFabricNodeHealth -NodeName Node.1
NodeName : Node.1
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='PowershellWatcher', Property='CPU', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Ok
SequenceNumber : 5
SentAt : 4/21/2015 8:01:17 AM
ReceivedAt : 4/21/2015 8:02:12 AM
TTL : Infinite
Description : Fabric node is up.
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Ok = 4/21/2015 8:02:12 AM
SourceId : PowershellWatcher
Property : CPU
HealthState : Warning
SequenceNumber : 130741236814913394
SentAt : 4/21/2015 9:01:21 PM
ReceivedAt : 4/21/2015 9:01:21 PM
TTL : 00:02:00
Description : CPU is above 80% threshold
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Warning = 4/21/2015 9:01:21 PM
في المثال التالي، يتم الإبلاغ عن تحذير مؤقت على نسخة متماثلة. يتم الحصول أولاً على معرف القسم ثم معرف النسخة المتماثلة للخدمة المستهدفة. ثم يرسل تقريراً من PowershellWatcher على الخاصية ResourceDependency. يتم الاهتمام بالتقرير لمدة دقيقتين فقط، ويتم إزالته من المتجر تلقائياً.
PS C:\> $partitionId = (Get-ServiceFabricPartition -ServiceName fabric:/WordCount/WordCount.Service).PartitionId
PS C:\> $replicaId = (Get-ServiceFabricReplica -PartitionId $partitionId | where {$_.ReplicaRole -eq "Primary"}).ReplicaId
PS C:\> Send-ServiceFabricReplicaHealthReport -PartitionId $partitionId -ReplicaId $replicaId -HealthState Warning -SourceId PowershellWatcher -HealthProperty ResourceDependency -Description "The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes." -TimeToLiveSec 120 -RemoveWhenExpired
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId $partitionId -ReplicaOrInstanceId $replicaId
PartitionId : 8f82daff-eb68-4fd9-b631-7a37629e08c0
ReplicaId : 130740415594605869
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='PowershellWatcher', Property='ResourceDependency', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : State
HealthState : Ok
SequenceNumber : 130740768777734943
SentAt : 4/21/2015 8:01:17 AM
ReceivedAt : 4/21/2015 8:02:12 AM
TTL : Infinite
Description : Replica has been created.
RemoveWhenExpired : False
IsExpired : False
Transitions : ->Ok = 4/21/2015 8:02:12 AM
SourceId : PowershellWatcher
Property : ResourceDependency
HealthState : Warning
SequenceNumber : 130741243777723555
SentAt : 4/21/2015 9:12:57 PM
ReceivedAt : 4/21/2015 9:12:57 PM
TTL : 00:02:00
Description : The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes.
RemoveWhenExpired : True
IsExpired : False
Transitions : ->Warning = 4/21/2015 9:12:32 PM
REST
أرسل التقارير الصحية باستخدام طلبات REST مع POST التي تنتقل إلى الكيان المطلوب وتحتوي على وصف التقرير الصحي في النص الأساسي. على سبيل المثال، راجع كيفية إرسال REST تقارير صحة المجموعة أو تقارير صحة الخدمة. يتم دعم جميع الكيانات.
الخطوات التالية
استنادا إلى البيانات الصحية، يمكن لكتاب الخدمة ومسؤولي المجموعات/التطبيقات التفكير في طرق لاستيعاب المعلومات. على سبيل المثال، يمكنهم إعداد تنبيهات بناءً على الحالة الصحية لإيقاف المشكلات الخطيرة قبل أن تؤدي إلى الانقطاعات. يمكن للمسؤولين أيضا إعداد أنظمة إصلاح لإصلاح المشكلات تلقائياً.
مقدمة حول مراقبة صحة Service Fabric
كيفية الإبلاغ عن صحة الخدمة والتحقق منها
استخدام تقارير صحة النظام لاستكشاف الأخطاء وإصلاحها
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ