معالجة الأخطاء وإعادة المحاولات في Azure Functions
معالجة الأخطاء في Azure Functions مهمة لتجنب فقدان البيانات والأحداث الفائتة، إلى جانب مراقبة سلامة تطبيقك.
توضح هذه المقالة استراتيجيات عامة لمعالجة الأخطاء في وجود ارتباطات إلى أخطاء خاصة بالربط.
معالجة الأخطاء
يمكن أن تأتي الأخطاء التي تظهر في Azure Functions من أي من الأصول التالية:
- استخدام مشغلات وروابط Azure Functions المضمنة
- استدعاءات واجهات برمجة التطبيقات لخدمات Azure الأساسية
- الاستدعاءات إلى نقاط نهاية REST
- الاستدعاءات إلى مكتبات العميل أو الحزم أو واجهات برمجة تطبيقات الجهات الخارجية
يعد اتباع ممارسات معالجة الأخطاء الجيدة أمرا مهما لتجنب فقدان البيانات أو الرسائل الفائتة. تتضمن ممارسات معالجة الأخطاء الموصى بها الإجراءات التالية:
- تمكين Application Insights
- استخدام معالجة الأخطاء المنظمة
- تصميم للتكبد
- تنفيذ نهج إعادة المحاولة (عند الاقتضاء)
استخدام معالجة الأخطاء المنظمة
يعد تسجيل الأخطاء وتسجيلها أمرا بالغ الأهمية لمراقبة صحة التطبيق الخاص بك. يجب أن يتضمن المستوى الأعلى من أي تعليمة برمجية للدالة كتلة try/catch. في كتلة catch، يمكنك التقاط الأخطاء وتسجيلها.
نهج إعادة المحاولة (معاينة)
يمكن تعريف نهج إعادة المحاولة على أي وظيفة لأي نوع مشغل في تطبيق الوظائف. يعيد نهج إعادة المحاولة تنفيذ دالة حتى التنفيذ الناجح أو حتى يحدث الحد الأقصى لعدد مرات إعادة المحاولة. يمكن تعريف نهج إعادة المحاولة لجميع الوظائف في التطبيق أو للوظائف الفردية. بشكل افتراضي، لن يعيد تطبيق الوظائف محاولة الرسائل (بصرف النظر عن المشغلات المحددة التي لها نهج إعادة المحاولة على مصدر المشغل).
ملاحظة
تتوفر نهج إعادة المحاولة فقط في إصدار وقت تشغيل Azure Function ~3 أو أحدث.
يتم تقييم نهج إعادة المحاولة كلما ينتج عن التنفيذ استثناء غير صحيح. كأفضل ممارسة، يجب عليك التقاط جميع الاستثناءات في التعليمات البرمجية الخاصة بك وإعادة تسجيل أي أخطاء يجب أن تؤدي إلى إعادة المحاولة. لن تتم كتابة نقاط التحقق من مراكز الأحداث وAzure Cosmos DB حتى تكتمل سياسة إعادة المحاولة للتنفيذ، ما يعني إيقاف التقدم في هذا القسم مؤقتا حتى تكتمل الدفعة الحالية.
خيارات نهج إعادة المحاولة
تتوفر الخيارات التالية لتعريف نهج إعادة المحاولة.
الحد الأقصى لعدد مرات إعادة المحاولة هو الحد الأقصى لعدد مرات إعادة محاولة التنفيذ قبل الفشل النهائي. قيمة تعني -1 إعادة المحاولة إلى أجل غير مسمى. يتم تخزين عدد إعادة المحاولة الحالي في ذاكرة المثيل. من المحتمل أن يكون للمثيل فشل بين محاولات إعادة المحاولة. عندما يفشل مثيل أثناء نهج إعادة المحاولة، يتم فقدان عدد مرات إعادة المحاولة. عند وجود حالات فشل في المثيل، يمكن لمشغلات مثل مراكز الأحداث وAzure Cosmos DB وتخزين قائمة الانتظار استئناف المعالجة وإعادة محاولة الدفعة على مثيل جديد، مع إعادة تعيين عدد إعادة المحاولة إلى الصفر. لا تستأنف المشغلات الأخرى، مثل HTTP والمؤقت، على مثيل جديد. وهذا يعني أن الحد الأقصى لعدد مرات إعادة المحاولة هو أفضل جهد، وفي بعض الحالات النادرة يمكن إعادة محاولة تنفيذ أكثر من الحد الأقصى، أو لمشغلات مثل HTTP وموقت إعادة محاولة أقل من الحد الأقصى.
تتحكم استراتيجية إعادة المحاولة في كيفية تصرف عمليات إعادة المحاولة. فيما يلي خياران مدعومان لإعادة المحاولة:
| خيار | الوصف |
|---|---|
fixedDelay |
يسمح لكمية محددة من الوقت بالانقضاء بين كل إعادة محاولة، |
exponentialBackoff |
تنتظر إعادة المحاولة الأولى الحد الأدنى من التأخير. في عمليات إعادة المحاولة اللاحقة، تتم إضافة الوقت بشكل أسي إلى المدة الأولية لكل إعادة محاولة، حتى يتم الوصول إلى الحد الأقصى للتأخير. يضيف التراجع الأسي بعض العشوائية الصغيرة إلى التأخيرات في عمليات إعادة المحاولة المرحلية في سيناريوهات معدل النقل العالي. |
تكوين مستوى التطبيق
يمكن تعريف نهج إعادة المحاولة لجميع الوظائف في تطبيق باستخدام host.json الملف.
تكوين مستوى الدالة
يمكن تعريف نهج إعادة المحاولة لدالة معينة. يأخذ التكوين الخاص بالدالة أولوية على التكوين على مستوى التطبيق.
إعادة محاولة التأخير الثابت
تتطلب عمليات إعادة المحاولة حزمة NuGet Microsoft.Azure.WebJobs>= 3.0.23
[FunctionName("EventHubTrigger")]
[FixedDelayRetry(5, "00:00:10")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}
إعادة محاولة التراجع الأسي
تتطلب عمليات إعادة المحاولة حزمة NuGet Microsoft.Azure.WebJobs>= 3.0.23
[FunctionName("EventHubTrigger")]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}
| خاصية function.json | خاصية السمة | الوصف |
|---|---|---|
| strategy | غير متوفر | مطلوب استراتيجية إعادة المحاولة لاستخدامها. القيم الصالحة هي fixedDelay أو exponentialBackoff. |
| maxRetryCount | غير متوفر | مطلوب الحد الأقصى لعدد المحاولات المسموح بها لكل تنفيذ وظيفة. تعني -1 إعادة المحاولة إلى أجل غير مسمى. |
| delayInterval | غير متوفر | التأخير المستخدم بين عمليات إعادة المحاولة fixedDelay عند استخدام استراتيجية. حدد كسلسلة بالتنسيق HH:mm:ss. |
| minimumInterval | غير متوفر | الحد الأدنى لتأخير إعادة المحاولة عند استخدام exponentialBackoff استراتيجية. حدد كسلسلة بالتنسيق HH:mm:ss. |
| maximumInterval | غير متوفر | الحد الأقصى لتأخير إعادة المحاولة عند استخدام إستراتيجية exponentialBackoff. حدد كسلسلة بالتنسيق HH:mm:ss. |
قيود إعادة المحاولة أثناء المعاينة
- بالنسبة لمشاريع .NET، قد تحتاج إلى سحب إصدار من Microsoft.Azure.WebJobs>= 3.0.23 يدويا.
- في خطة الاستهلاك، قد يتم تحجيم التطبيق إلى الصفر أثناء إعادة محاولة الرسائل النهائية في قائمة انتظار.
- في خطة الاستهلاك، قد يتم تقليل حجم التطبيق أثناء إجراء عمليات إعادة المحاولة. للحصول على أفضل النتائج، اختر فاصلا زمنيا <لإعادة المحاولة = 00:01:00 و <= 5 محاولات إعادة المحاولة.
استخدام دعم إعادة المحاولة أعلى مرونة المشغل
نهج إعادة محاولة تطبيق الوظائف مستقل عن أي عمليات إعادة محاولة أو مرونة يوفرها المشغل. لن يقوم نهج إعادة محاولة الوظيفة إلا بطبقة أعلى إعادة المحاولة المرنة للمشغل. على سبيل المثال، إذا كنت تستخدم ناقل خدمة Azure، يكون عدد تسليم الرسائل في قوائم الانتظار 10 بشكل افتراضي. يعني عدد التسليم الافتراضي بعد 10 محاولات تسليم لرسالة قائمة انتظار، سيقوم ناقل خدمة Microsoft Azure بحرف غير مستخدم للرسالة. يمكنك تعريف نهج إعادة المحاولة لدالة تحتوي على مشغل ناقل خدمة Microsoft Azure، ولكن ستتم طبقة إعادة المحاولة أعلى محاولات تسليم ناقل خدمة Microsoft Azure.
على سبيل المثال، إذا استخدمت عدد تسليم ناقل خدمة Microsoft Azure الافتراضي وهو 10، وحددت نهج إعادة محاولة دالة من 5. سيتم إلغاء ترتيب الرسالة أولا، ما يؤدي إلى زيادة حساب تسليم ناقل الخدمة إلى 1. إذا فشل كل تنفيذ، بعد عشر محاولات لتشغيل نفس الرسالة، فسيتم وضع علامة على تلك الرسالة على أنها مهجورة. سيعيد ناقل خدمة Microsoft Azure طلب الرسالة على الفور، وسيشغل الدالة ويتزايد عدد التسليم إلى 2. وأخيرا، بعد 50 محاولة نهائية (10 عمليات تسليم ناقل خدمة * خمس محاولات إعادة محاولة للوظيفة لكل تسليم)، سيتم التخلي عن الرسالة وتشغيل رسالة غير مستخدمة على ناقل الخدمة.
تحذير
لا يوصى بتعيين عدد التسليم لمشغل مثل قوائم انتظار ناقل خدمة Microsoft Azure إلى 1، مما يعني أن الرسالة ستكون غير مستخدمة مباشرة بعد دورة إعادة محاولة دالة واحدة. وذلك لأن المشغلات توفر المرونة مع عمليات إعادة المحاولة، في حين أن نهج إعادة محاولة الوظيفة هو أفضل جهد وقد يؤدي إلى أقل من العدد الإجمالي المطلوب من عمليات إعادة المحاولة.
المشغلات ذات المرونة الإضافية أو إعادة المحاولة
تدعم المشغلات التالية عمليات إعادة المحاولة في مصدر المشغل:
بشكل افتراضي، تعيد معظم المشغلات محاولة الطلبات حتى خمس مرات. بعد إعادة المحاولة الخامسة، سيكتب كل من تخزين قائمة انتظار Azure رسالة إلى قائمة انتظار غير قابلة للتسمم. ستكتب قائمة انتظار ناقل خدمة Microsoft Azure الافتراضية ونهج الموضوع رسالة إلى قائمة انتظار غير مستخدمة بعد 10 محاولات.
رموز أخطاء الربط
عند التكامل مع منتجات Azure، قد تنشأ أخطاء من واجهات برمجة التطبيقات للمنتجات الأساسية. تتوفر المعلومات المتعلقة بالأخطاء الخاصة بالربط في قسم الاستثناءات وأكواد الإرجاع في المقالات التالية: