معالجة الأخطاء وإعادة المحاولات في Azure Functions
تعد معالجة الأخطاء في Azure Functions أمرا مهما لمساعدتك على تجنب فقدان البيانات، وتجنب الأحداث الفائتة، ومراقبة صحة التطبيق الخاص بك. كما أنها طريقة مهمة لمساعدتك على فهم سلوكيات إعادة محاولة المشغلات المستندة إلى الحدث.
توضح هذه المقالة الاستراتيجيات العامة لمعالجة الأخطاء والاستراتيجيات المتوفرة لإعادة المحاولة.
هام
تمت إزالة دعم نهج إعادة المحاولة لمعاينة مشغلات معينة في ديسمبر 2022. نهج إعادة المحاولة للمشغلات المدعومة متاحة الآن بشكل عام (GA). للحصول على قائمة بالملحقات التي تدعم نهج إعادة المحاولة حاليا، راجع قسم إعادة المحاولة .
معالجة الأخطاء
يمكن أن تأتي الأخطاء التي تحدث في دالة Azure من:
- استخدام مشغلات الوظائف المضمنة والروابط.
- حالات استدعاء واجهات برمجة التطبيقات لخدمات Azure الأساسية.
- حالات استدعاء نقاط نهاية REST.
- حالات استدعاء مكتبات العميل أو الحزم أو واجهات برمجة تطبيقات الجهات الخارجية.
لتجنب فقدان البيانات أو الرسائل الفائتة، من المهم ممارسة معالجة الأخطاء بشكل جيد. يصف هذا الجدول بعض ممارسات معالجة الأخطاء الموصى بها ويوفر ارتباطات لمزيد من المعلومات.
التوصية | التفاصيل |
---|---|
تمكين Application Insights | تتكامل Azure Functions مع Application Insights لجمع بيانات الخطأ وبيانات الأداء وسجلات وقت التشغيل. يجب استخدام Application Insights لاكتشاف الأخطاء التي تحدث في عمليات تنفيذ الوظائف وفهمها بشكل أفضل. لمعرفة المزيد، يُرجى الرجوع إلى Monitor Azure وظائف. |
استخدم معالجة الأخطاء المنظمة | يعد حفظ الأخطاء وتسجيلها أمرًا بالغ الأهمية لمراقبة سلامة تطبيقك. يجب أن يشتمل المستوى الأعلى من أي تعليمة برمجية للوظيفة على كتلة محاولة/التقاط. في كتلة الالتقاط، يمكنك التقاط الأخطاء وتسجيلها. للحصول على معلومات حول الأخطاء التي قد تقدمها الروابط، راجع رموز أخطاء الروابط. اعتمادا على استراتيجية إعادة المحاولة المحددة، قد تقوم أيضا برفع استثناء جديد لتشغيل الدالة مرة أخرى. |
تخطيط استراتيجية إعادة المحاولة | توفر العديد من ملحقات روابط الوظائف دعما مضمنا لإعادة المحاولة وتتيح لك ملحقات أخرى تحديد نهج إعادة المحاولة، والتي يتم تنفيذها بواسطة وقت تشغيل الوظائف. بالنسبة للمشغلات التي لا توفر سلوكيات إعادة المحاولة، يجب أن تفكر في تنفيذ نظام إعادة المحاولة الخاص بك. لمزيد من المعلومات، راجع إعادة المحاولة. |
تصميم لتساوي القوى | قد يكون حدوث الأخطاء عند معالجة البيانات مشكلة لوظائفك، خاصة عند معالجة الرسائل. من المهم مراعاة ما يحدث عند حدوث الخطأ وكيفية تجنب المعالجة المكررة. للتعرّف على المزيد، راجع تصميم Azure Functions لغرض الإدخال المتطابق. |
إعادة المحاولات
هناك نوعان من عمليات إعادة المحاولة المتاحة لوظائفك:
- سلوكيات إعادة المحاولة المضمنة لملحقات المشغل الفردية
- إعادة محاولة النهج التي يوفرها وقت تشغيل الوظائف
يشير الجدول التالي إلى المشغّلات التي تشغّل إعادة محاولة الدعم ومكان تكوين سلوك إعادة المحاولة. كما أنه يرتبط بمزيد من المعلومات حول الأخطاء التي تأتي من الخدمات الأساسية.
المشغّل/الربط | إعادة محاولة المصدر | التكوين |
---|---|---|
Azure Cosmos DB | إعادة محاولة النهج | مستوى الدالة |
مخزن البيانات الثنائية الكبيرة | ملحق الربط | host.json |
Event Grid | ملحق الربط | اشتراك الحدث |
مراكز الأحداث | إعادة محاولة النهج | مستوى الدالة |
Kafka | إعادة محاولة النهج | مستوى الدالة |
مخزن قائمة الانتظار | ملحق الربط | host.json |
RabbitMQ | ملحق الربط | قائمة الرسائل الخامدة |
ناقل الخدمة | ملحق الربط | host.json* |
عدّاد الوقت | إعادة محاولة النهج | مستوى الدالة |
*يتطلب الإصدار 5.x من ملحق ناقل خدمة Azure. في إصدارات الملحقات الأقدم، يتم تنفيذ سلوكيات إعادة المحاولة بواسطة قائمة انتظار الرسائل غير المستخدمة لناقل خدمة Microsoft Azure.
نهُج إعادة المحاولة
تتيح لك Azure Functions تحديد نهج إعادة المحاولة لبعض أنواع المشغلات المحددة، والتي يتم فرضها بواسطة وقت التشغيل. تدعم أنواع المشغلات هذه حاليا نهج إعادة المحاولة:
دعم إعادة المحاولة هو نفسه لكل من نماذج برمجة v1 وv2 Python.
نهج إعادة المحاولة غير مدعومة في الإصدار 1.x من وقت تشغيل الوظائف.
تأمر سياسة إعادة المحاولة وقت التشغيل بإعادة تشغيل تنفيذ فاشل حتى يحدث إكمال ناجح أو يتم الوصول إلى العدد الأقصى لعمليات إعادة المحاولة.
يتم تقييم نهج إعادة المحاولة عندما تقوم دالة يتم تنفيذها بواسطة نوع مشغل مدعوم برفع استثناء غير صحيح. كأفضل ممارسة، يجب عليك التقاط جميع الاستثناءات في التعليمات البرمجية الخاصة بك ورفع استثناءات جديدة لأي أخطاء تريد أن تؤدي إلى إعادة المحاولة.
هام
لا تتم كتابة نقاط التحقق لمراكز الأحداث إلا بعد اكتمال نهج إعادة المحاولة للتنفيذ. وبسبب هذا السلوك، يتم إيقاف التقدم في القسم المحدد مؤقتا حتى يتم معالجة الدفعة الحالية.
يدعم الإصدار 5.x من ملحق Event Hubs قدرات إعادة المحاولة الإضافية للتفاعلات بين مضيف الوظائف ومركز الأحداث. لمزيد من المعلومات، راجع clientRetryOptions
في مرجع host.json مراكز الأحداث.
إستراتيجيات إعادة المحاولة
يمكنك تكوين إستراتيجيتين لإعادة المحاولة يدعمهما النهج:
يُسمح بفترة زمنية محددة كفاصل بين كل إعادة محاولة.
عند التشغيل في خطة Consumption، تتم محاسبتك فقط على الوقت الذي يتم فيه تنفيذ التعليمات البرمجية للدالة. لا تتم محاسبتك على وقت الانتظار بين عمليات التنفيذ في أي من إستراتيجيات إعادة المحاولة هذه.
الحد الأقصى لعدد مرات إعادة المحاولة
يمكنك تكوين الحد الأقصى لعدد المرات التي تتم فيها إعادة محاولة تنفيذ دالة قبل الفشل النهائي. يُخزَّن عدد مرات إعادة المحاولة الحالي في ذاكرة المثيل.
من الممكن أن يكون للمثيل فشل بين محاولات إعادة المحاولة. عند فشل مثيل أثناء سياسة إعادة المحاولة، يُفقد عدد مرات إعادة المحاولة. عند حدوث حالات فشل في المثيل، يمكن لمشغّل مراكز الأحداث استئناف المعالجة وإعادة محاولة الدُفعة على مثيل جديد، مع إعادة تعيين عدد مرات إعادة المحاولة إلى صفر. لا يستأنف مشغل المؤقت على مثيل جديد.
يعني هذا السلوك أن الحد الأقصى لعدد مرات إعادة المحاولة هو أفضل جهد. في بعض الحالات النادرة، يمكن إعادة محاولة تنفيذ أكثر من الحد الأقصى المطلوب لعدد المرات. بالنسبة لمشغلات المؤقت، يمكن أن تكون عمليات إعادة المحاولة أقل من الحد الأقصى للعدد المطلوب.
أمثلة على إعادة المحاولة
يتم توفير أمثلة لكل من استراتيجيات التأخير الثابت والتراجع الأسي. للاطلاع على أمثلة لاستراتيجية معينة، يجب أولا تحديد هذه الاستراتيجية في علامة التبويب السابقة.
يتم دعم عمليات إعادة المحاولة على مستوى الدالة مع حزم NuGet التالية:
- Microsoft.Azure.Functions.Worker.Sdk>= 1.9.0
- Microsoft.Azure.Functions.Worker.Extensions.EventHubs>= 5.2.0
- Microsoft.Azure.Functions.Worker.Extensions.Kafka>= 3.8.0
- Microsoft.Azure.Functions.Worker.Extensions.Timer>= 4.2.0
[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
FunctionContext context)
{
var logger = context.GetLogger(nameof(TimerFunction));
logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus.Next}");
}
الخاصية | الوصف |
---|---|
MaxRetryCount | مطلوب. الحد الأقصى لعدد المحاولات المسموح بها لكل تنفيذ وظيفة. تعني -1 إعادة المحاولة إلى أجل غير مسمى. |
DelayInterval | التأخير المستخدم بين عمليات إعادة المحاولة. حددها كسلسلة بالتنسيق HH:mm:ss . |
فيما يلي مثال على نهج إعادة المحاولة المحدد في ملف function.json :
{
"disabled": false,
"bindings": [
{
....
}
],
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 4,
"delayInterval": "00:00:10"
}
}
يمكنك تعيين هذه الخصائص على تعريفات نهج إعادة المحاولة:
الخاصية | الوصف |
---|---|
strategy | مطلوب. استراتيجية إعادة المحاولة لاستخدامها. القيم الصالحة هي fixedDelay أو exponentialBackoff . |
maxRetryCount | مطلوب. الحد الأقصى لعدد المحاولات المسموح بها لكل تنفيذ وظيفة. تعني -1 إعادة المحاولة إلى أجل غير مسمى. |
delayInterval | التأخير المستخدم بين عمليات إعادة المحاولة fixedDelay عند استخدام استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
minimumInterval | الحد الأدنى لتأخير إعادة المحاولة عند استخدام exponentialBackoff استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
maximumInterval | الحد الأقصى لتأخير إعادة المحاولة عند استخدام exponentialBackoff الاستراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
تعتمد الطريقة التي تحدد بها نهج إعادة المحاولة للمشغل على إصدار Node.js.
فيما يلي مثال على دالة مشغل المؤقت التي تستخدم استراتيجية إعادة محاولة تأخير ثابتة:
const { app } = require('@azure/functions');
app.timer('timerTriggerWithRetry', {
schedule: '0 */5 * * * *',
retry: {
strategy: 'fixedDelay',
delayInterval: {
seconds: 10,
},
maxRetryCount: 4,
},
handler: (myTimer, context) => {
if (context.retryContext?.retryCount < 2) {
throw new Error('Retry!');
} else {
context.log('Timer function processed request.');
}
},
});
تعتمد الطريقة التي تحدد بها نهج إعادة المحاولة للمشغل على إصدار Node.js.
فيما يلي مثال على دالة مشغل المؤقت التي تستخدم استراتيجية إعادة محاولة تأخير ثابتة:
import { app, InvocationContext, Timer } from '@azure/functions';
export async function timerTriggerWithRetry(myTimer: Timer, context: InvocationContext): Promise<void> {
if (context.retryContext?.retryCount < 2) {
throw new Error('Retry!');
} else {
context.log('Timer function processed request.');
}
}
app.timer('timerTriggerWithRetry', {
schedule: '0 */5 * * * *',
retry: {
strategy: 'fixedDelay',
delayInterval: {
seconds: 10,
},
maxRetryCount: 4,
},
handler: timerTriggerWithRetry,
});
يمكنك تعيين هذه الخصائص على تعريفات نهج إعادة المحاولة:
الخاصية | الوصف |
---|---|
strategy | مطلوب. استراتيجية إعادة المحاولة لاستخدامها. القيم الصالحة هي fixedDelay أو exponentialBackoff . |
maxRetryCount | مطلوب. الحد الأقصى لعدد المحاولات المسموح بها لكل تنفيذ وظيفة. تعني -1 إعادة المحاولة إلى أجل غير مسمى. |
delayInterval | التأخير المستخدم بين عمليات إعادة المحاولة fixedDelay عند استخدام استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
minimumInterval | الحد الأدنى لتأخير إعادة المحاولة عند استخدام exponentialBackoff استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
maximumInterval | الحد الأقصى لتأخير إعادة المحاولة عند استخدام exponentialBackoff الاستراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
فيما يلي مثال على دالة مشغل المؤقت التي تستخدم استراتيجية إعادة محاولة تأخير ثابتة:
import logging
from azure.functions import AuthLevel, Context, FunctionApp, TimerRequest
app = FunctionApp(http_auth_level=AuthLevel.ANONYMOUS)
@app.timer_trigger(schedule="*/1 * * * * *", arg_name="mytimer",
run_on_startup=False,
use_monitor=False)
@app.retry(strategy="fixed_delay", max_retry_count="3",
delay_interval="00:00:01")
def mytimer(mytimer: TimerRequest, context: Context) -> None:
logging.info(f'Current retry count: {context.retry_context.retry_count}')
if context.retry_context.retry_count == \
context.retry_context.max_retry_count:
logging.info(
f"Max retries of {context.retry_context.max_retry_count} for "
f"function {context.function_name} has been reached")
else:
raise Exception("This is a retryable exception")
يمكنك تعيين هذه الخصائص على تعريفات نهج إعادة المحاولة:
الخاصية | الوصف |
---|---|
strategy | مطلوب. استراتيجية إعادة المحاولة لاستخدامها. القيم الصالحة هي fixed_delay أو exponential_backoff . |
max_retry_count | مطلوب. الحد الأقصى لعدد المحاولات المسموح بها لكل تنفيذ وظيفة. تعني -1 إعادة المحاولة إلى أجل غير مسمى. |
delay_interval | التأخير المستخدم بين عمليات إعادة المحاولة fixed_delay عند استخدام استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
minimum_interval | الحد الأدنى لتأخير إعادة المحاولة عند استخدام exponential_backoff استراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
maximum_interval | الحد الأقصى لتأخير إعادة المحاولة عند استخدام exponential_backoff الاستراتيجية. حددها كسلسلة بالتنسيق HH:mm:ss . |
@FunctionName("TimerTriggerJava1")
@FixedDelayRetry(maxRetryCount = 4, delayInterval = "00:00:10")
public void run(
@TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
final ExecutionContext context
) {
context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}
رموز أخطاء الربط
عند التكامل مع خدمات Azure، قد تنشأ الأخطاء من واجهات برمجة التطبيقات للخدمات الأساسية. تتوفر المعلومات المتعلقة بالأخطاء الخاصة بالربط في أقسام "الاستثناءات ورموز الإرجاع" في المقالات التالية:
- Azure Cosmos DB
- Blob Storage
- شبكة الأحداث
- مراكز الأحداث
- مركز IoT
- مراكز الإعلامات
- تخزين قائمة الانتظار
- ناقل الخدمة
- تخزين الجدول