خدمة بيانات تعريف Azure: الأحداث المجدولة لأجهزة Linux الظاهرية
ينطبق على: ✔️ أجهزة Linux الظاهرية ✔️ مجموعات المقياس المرنة ✔️ مجموعات المقياس الموحدة
الأحداث المجدولة هي خدمة البيانات الوصفية من Azure التي تمنح التطبيق وقتًا للتحضير لصيانة الجهاز الظاهري (VM). حيث توفر معلومات حول أحداث الصيانة القادمة (على سبيل المثال، إعادة التشغيل) بحيث يمكن للتطبيق الخاص بك الاستعداد لها والحد من التعطيل. وهي متاحة لجميع أنواع الأجهزة الظاهرية Azure، بما في ذلك PaaS وIaaS على كل من Windows وLinux.
للحصول على معلومات حول الأحداث المجدولة على Windows، راجع الأحداث المجدولة لأجهزة Windows الظاهرية.
توفر الأحداث المجدولة إعلامات استباقية حول الأحداث القادمة، للحصول على معلومات تفاعلية حول الأحداث التي حدثت بالفعل، راجع معلومات توفر الجهاز الظاهري في Azure Resource Graph وإنشاء قاعدة تنبيه التوفر لجهاز Azure الظاهري.
إشعار
تتوفر الأحداث المجدولة بشكل عام في جميع مناطق Azure. راجع الإصدار وتوفر المنطقة للحصول على أحدث معلومات الإصدار.
لماذا تستخدم الأحداث المجدولة؟
يمكن للعديد من التطبيقات الاستفادة من الوقت المخصص للتحضير لصيانة الجهاز الظاهري. يمكن استخدام الوقت لتنفيذ مهام خاصة بالتطبيقات تعمل على تحسين التوفر، والموثوقية، وإمكانية الخدمة، بما في ذلك:
- نقطة التحقق والاستعادة.
- استنزاف الاتصال.
- تجاوز فشل نسخة متماثلة أساسية.
- إزالة من مجموعة موازنة تحميل.
- تسجيل الأحداث.
- إيقاف تشغيل آمن.
باستخدام الأحداث المجدولة، يمكن للتطبيق اكتشاف وقت حدوث الصيانة وتشغيل المهام للحد من تأثيرها.
توفر الأحداث المجدولة الأحداث في حالات الاستخدام التالية:
- الصيانة التي بدأها النظام الأساسي (على سبيل المثال، إعادة تهيئة الجهاز الظاهري، أو الترحيل المباشر، أو تحديثات حفظ الذاكرة للمضيف).
- يعمل الجهاز الظاهري على الأجهزة المضيفة المتدهورة التي من المتوقع فشلها قريباً.
- كان الجهاز الظاهري يعمل على مضيف عانى من فشل في الأجهزة.
- الصيانة التي يبدأها المستخدم (على سبيل المثال، يعيد المستخدم تشغيل جهاز ظاهري أو يعيد توزيعه).
- عمليات إخلاء مثيل مجموعة جهاز Spot الظاهري ومقياس Spot.
الأساسيات
تعرض خدمة بيانات التعريف معلومات حول تشغيل الأجهزة الظاهرية باستخدام نقطة نهاية REST التي يمكن الوصول إليها من داخل الجهاز الظاهري. تتوفر المعلومات عبر IP غير قابل للتوجيه ولا يتم كشفها خارج الجهاز الظاهري.
النطاق
يتم تسليم الأحداث المجدولة إلى ويمكن التعرف عليها من خلال:
- أجهزة ظاهرية مستقلة.
- جميع الأجهزة الظاهرية في خدمة سحابة Azure (كلاسيكية).
- جميع الأجهزة الظاهرية في مجموعة التوفر.
- كل الأجهزة الظاهرية في مجموعة مواضع مجموعة المقياس.
يتم تسليم الأحداث المجدولة لجميع الأجهزة الظاهرية (VMs) في مجموعة توفر كاملة أو مجموعة موضع لمجموعة مقياس الجهاز الظاهري لجميع الأجهزة الظاهرية الأخرى في نفس المجموعة أو تعيينها بغض النظر عن استخدام منطقة التوفر.
نتيجة لذلك، تحقق من الحقل Resources في الحدث لتحديد الأجهزة الظاهرية المتأثرة.
إشعار
ستتلقى الأجهزة الظاهرية المسرعة لوحدة معالجة الرسومات في مجموعة مقياس باستخدام مجال خطأ واحد (FD = 1) الأحداث المجدولة للمورد المتأثر فقط. لن يتم بث الأحداث إلى جميع الأجهزة الظاهرية في نفس مجموعة الموضع.
اكتشاف نقطة النهاية
بالنسبة إلى الأجهزة الظاهرية التي تدعم الشبكة الظاهرية، تتوفر خدمة بيانات التعريف من عنوان IP ثابت غير قابل للتوجيه، 169.254.169.254. نقطة النهاية الكاملة لأحدث إصدار من الأحداث المجدولة هي:
http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
إذا لم يتم إنشاء الجهاز الظاهري داخل شبكة ظاهرية، والحالات الافتراضية للخدمات السحابية والأجهزة الظاهرية الكلاسيكية، يلزم منطق إضافي لاكتشاف عنوان IP لاستخدامه. لمعرفة كيفية اكتشاف نقطة نهاية المضيف، راجع هذا النموذج.
توفر الإصدار والمنطقة
يتم إصدار خدمة الأحداث المجدولة. الإصدارات إلزامية. الإصدار الحالي هو 2020-07-01.
| إصدار | نوع الإصدار | المناطق | ملاحظات الإصدار |
|---|---|---|---|
| 2020-07-01 | التوفر العام | الكل | |
| 2019-08-01 | التوفر العام | الكل | |
| 2019-04-01 | التوفر العام | الكل | |
| 2019-01-01 | التوفر العام | الكل | |
| 2017-11-01 | التوفر العام | الكل | |
| 2017-08-01 | التوفر العام | الكل | |
| 2017-03-01 | معاينة | الكل |
إشعار
تم دعم الإصدارات الأولية السابقة للأحداث المجدولة {latest} كإصدار واجهة برمجة التطبيقات. لم يعد هذا التنسيق مدعوماً، وسيتم إهماله في المستقبل.
تمكين الأحداث المجدولة وتعطيلها
يتم تمكين الأحداث المجدولة لخدمتك في المرة الأولى التي تقدم فيها طلبًا للأحداث. يجب أن تتوقع استجابة متأخرة في مكالمتك الأولى لمدة تصل إلى دقيقتين وستبدأ في تلقي الأحداث في غضون 5 دقائق. يتم تعطيل الأحداث المجدولة للخدمة إذا لم تقدم طلبا إلى نقطة النهاية لمدة 24 ساعة.
الصيانة التي يبدأها المستخدم
تؤدي صيانة الأجهزة الظاهرية التي يبدؤها المستخدم عبر مدخل Azure، أو واجهة برمجة التطبيقات، أو CLI، أو PowerShell إلى حدث مجدول. يمكنك بعد ذلك اختبار منطق إعداد الصيانة في تطبيقك، ويمكن للتطبيق الخاص بك الاستعداد للصيانة التي يبدؤها المستخدم.
إذا قمت بإعادة تشغيل جهاز ظاهري، فستتم جدولة حدث بهذا النوع Reboot. إذا قمت بإعادة توزيع جهاز ظاهري، فستتم جدولة حدث بهذا النوع Redeploy. عادة ما يمكن الموافقة على الأحداث ذات مصدر حدث المستخدم على الفور لتجنب تأخير الإجراءات التي بدأها المستخدم. ننصح بوجود جهاز ظاهري أساسي وثانوي يتصل بالأحداث المجدولة التي ينشئها المستخدم ويوافق عليها في حالة عدم استجابة الجهاز الظاهري الأساسي. يمنع الموافقة الفورية على الأحداث التأخير في استرداد التطبيق الخاص بك مرة أخرى إلى حالة جيدة.
يتم دعم الأحداث المجدولة لمجموعات مقياس الجهاز الظاهري ترقيات نظام التشغيل الضيف أو إعادة الرسم لأحجام الأجهزة الظاهرية للأغراض العامة التي تدعم الاحتفاظ بالذاكرة التحديثات فقط. لا تعمل مع سلاسل G و M و N و H. يتم تعطيل الأحداث المجدولة لمجموعات مقياس الجهاز الظاهري ترقيات نظام التشغيل الضيف وإعادة الرسم بشكل افتراضي. لتمكين الأحداث المجدولة لهذه العمليات على أحجام الأجهزة الظاهرية المدعومة، قم أولا بتمكينها باستخدام OSImageNotificationProfile.
استخدام API
نظرة عامة عالية المستوى
هناك مكونان رئيسيان لمعالجة الأحداث المجدولة والتحضير والاسترداد. تتوفر جميع الأحداث المجدولة الحالية التي تؤثر على الجهاز الظاهري للقراءة عبر نقطة نهاية الأحداث المجدولة IMDS. عندما يصل الحدث إلى حالة طرفية، تتم إزالته من قائمة الأحداث. يوضح الرسم التخطيطي التالي انتقالات الحالة المختلفة التي يمكن أن يواجهها حدث مجدول واحد:
بالنسبة للأحداث في حالة EventStatus:"Scheduled"، ستحتاج إلى اتخاذ خطوات لإعداد حمل العمل الخاص بك. بمجرد اكتمال الإعداد، يجب عليك بعد ذلك الموافقة على الحدث باستخدام واجهة برمجة تطبيقات الحدث المجدولة. وإلا، تتم الموافقة على الحدث تلقائيا عند الوصول إلى الوقت NotBefore. إذا كان الجهاز الظاهري على البنية الأساسية المشتركة، فسينتظر النظام بعد ذلك حتى يوافق جميع المستأجرين الآخرين على نفس الجهاز أيضا على المهمة أو المهلة. بمجرد جمع الموافقات من جميع الأجهزة الظاهرية المتأثرة أو الوصول إلى NotBefore الوقت، ينشئ Azure حمولة حدث مجدولة جديدة مع EventStatus:"Started" ويشغل بدء حدث الصيانة. عندما يصل الحدث إلى حالة طرفية، تتم إزالته من قائمة الأحداث. وهذا بمثابة إشارة للعميل لاسترداد الأجهزة الظاهرية الخاصة به.
فيما يلي تعليمة psudeo البرمجية التي توضح عملية لكيفية قراءة الأحداث المجدولة وإدارتها في التطبيق الخاص بك:
current_list_of_scheduled_events = get_latest_from_se_endpoint()
#prepare for new events
for each event in current_list_of_scheduled_events:
if event not in previous_list_of_scheduled_events:
prepare_for_event(event)
#recover from completed events
for each event in previous_list_of_scheduled_events:
if event not in current_list_of_scheduled_events:
receover_from_event(event)
#prepare for future jobs
previous_list_of_scheduled_events = current_list_of_scheduled_events
نظرا لأن الأحداث المجدولة غالبا ما تستخدم للتطبيقات ذات متطلبات قابلية الوصول العالية، فهناك بعض الحالات الاستثنائية التي يجب مراعاتها:
- بمجرد اكتمال حدث مجدول وإزالته من الصفيف، لن يكون هناك أي تأثيرات أخرى دون حدث جديد بما في ذلك حدث EventStatus آخر:"مجدول"
- تراقب Azure عمليات الصيانة عبر الأسطول بأكمله وفي ظروف نادرة تحدد أن عملية الصيانة عالية جدا لا يمكن تطبيقها. في هذه الحالة، سينتقل الحدث المجدول مباشرة من "مجدول" إلى إزالته من صفيف الأحداث
- في حالة فشل الأجهزة، يتجاوز Azure الحالة "المجدولة" وينتقل فورا إلى حالة EventStatus:"Started".
- بينما لا يزال الحدث في حالة EventStatus:"Started"، قد يكون هناك تأثير آخر لمدة أقصر مما تم الإعلان عنه في الحدث المجدول.
كجزء من ضمان توفر Azure، لن تتأثر الأجهزة الظاهرية في مجالات الخطأ المختلفة بعمليات الصيانة الروتينية في نفس الوقت. ومع ذلك، قد يكون لديهم عمليات تسلسل واحد تلو الآخر. يمكن أن تتلقى الأجهزة الظاهرية في مجال خطأ واحد الأحداث المجدولة مع EventStatus:"Scheduled" بعد وقت قصير من اكتمال صيانة مجال خطأ آخر. بغض النظر عن البنية التي اخترتها، استمر دائما في التحقق من الأحداث الجديدة المعلقة مقابل الأجهزة الظاهرية الخاصة بك.
بينما تختلف التوقيتات الدقيقة للأحداث، يوفر الرسم التخطيطي التالي إرشادات تقريبية لكيفية متابعة عملية الصيانة النموذجية:
- EventStatus:"Scheduled" إلى مهلة الموافقة: 15 دقيقة
- مدة التأثير: 7 ثوان
- EventStatus:"Started" to Completed (تمت إزالة الحدث من صفيف الأحداث): 10 دقائق
ستؤدي جميع العمليات التي تؤثر على توفر الجهاز الظاهري إلى حدث مجدول، ولكن لن تظهر جميع الأحداث المجدولة في أسطح Azure الأخرى مثل سجلات نشاط Azure أو صحة الموارد. سيضمن التحقق من الأحداث المجدولة بانتظام أن لديك أحدث المعلومات حول أي تأثيرات قادمة على الأجهزة الظاهرية الخاصة بك.
الرؤوس
عند الاستعلام عن خدمة بيانات التعريف، يجب عليك توفير العنوان Metadata:true للتأكد من عدم إعادة توجيه الطلب عن غير قصد. العنوان Metadata:true مطلوب لجميع طلبات الأحداث المجدولة. يؤدي عدم تضمين العنوان في الطلب إلى استجابة "طلب غير صحيح" من خدمة بيانات التعريف.
الاستعلام عن الأحداث
يمكنك الاستعلام عن الأحداث المجدولة عن طريق إجراء الاستدعاء التالي:
عينة Bash
curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
نموذج PowerShell
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | ConvertTo-Json -Depth 64
عينة Python
import json
import requests
metadata_url ="http://169.254.169.254/metadata/scheduledevents"
header = {'Metadata' : 'true'}
query_params = {'api-version':'2020-07-01'}
def get_scheduled_events():
resp = requests.get(metadata_url, headers = header, params = query_params)
data = resp.json()
return data
تحتوي الاستجابة على صفيف من الأحداث المجدولة. يعني الصفيف الفارغ أنه لا توجد أحداث مجدولة حالياً. في حالة وجود أحداث مجدولة، تحتوي الاستجابة على صفيف من الأحداث.
{
"DocumentIncarnation": {IncarnationID},
"Events": [
{
"EventId": {eventID},
"EventType": "Reboot" | "Redeploy" | "Freeze" | "Preempt" | "Terminate",
"ResourceType": "VirtualMachine",
"Resources": [{resourceName}],
"EventStatus": "Scheduled" | "Started",
"NotBefore": {timeInUTC},
"Description": {eventDescription},
"EventSource" : "Platform" | "User",
"DurationInSeconds" : {timeInSeconds},
}
]
}
خصائص الحدث
| الخاصية | الوصف |
|---|---|
| تجسيد المستند | عدد صحيح يتزايد عند تغيير صفيف الأحداث. تحتوي المستندات ذات نفس التجسد على نفس معلومات الحدث، وستتم زيادة التجسيد عند تغيير حدث. |
| EventId | معرف فريد عمومي لهذا الحدث. مثال:
|
| EventType | أسباب التأثير في هذا الحدث. القيم:
|
| ResourceType | نوع المورد الذي يؤثر فيه هذا الحدث. القيم:
|
| الموارد | قائمة الموارد التي يؤثر فيها هذا الحدث. مثال:
|
| EventStatus | حالة هذا الحدث. القيم:
Completed أو حالة مماثلة على الإطلاق. لم يعد يتم إرجاع الحدث عند الانتهاء من الحدث. |
| NotBefore | الوقت الذي يمكن أن يبدأ بعده هذا الحدث. يضمن عدم بدء الحدث قبل هذا الوقت. سيكون فارغا إذا كان الحدث قد بدأ بالفعل مثال:
|
| الوصف | وصف هذا الحدث. مثال:
|
| EventSource | المنشئ للحدث. مثال:
|
| DurationInSeconds | المدة المتوقعة للانقطاع الناجم عن الحدث. قد تكون هناك تأثيرات ثانوية لمدة أقصر أثناء نافذة التأثير. مثال:
|
جدولة الأحداث
تتم جدولة كل حدث بحد أدنى من الوقت في المستقبل بناء على نوع الحدث. تنعكس هذه المرة في خاصية NotBefore للحدث.
| EventType | الحد الأدنى للإشعار |
|---|---|
| تجميد | 15 دقيقة |
| إعادة التشغيل | 15 دقيقة |
| إعادة التوزيع | 10 دقيقة |
| إنهاء | قابلية تكوين المستخدم: 5 إلى 15 دقيقة |
وهذا يعني أنه يمكنك الكشف عن جدول زمني مستقبلي للحدث على الأقل في الحد الأدنى لوقت الإشعار قبل وقوع الحدث. بمجرد جدولة حدث، سينتقل إلى Started الحالة بعد الموافقة عليه أو NotBefore مرور الوقت. ومع ذلك، في حالات نادرة، سيتم إلغاء العملية بواسطة Azure قبل أن تبدأ. في هذه الحالة، ستتم إزالة الحدث من صفيف الأحداث، ولن يحدث التأثير كما هو مجدول مسبقا.
إشعار
في بعض الحالات، يكون Azure قادراً على التنبؤ بفشل المضيف بسبب الأجهزة المتدهورة، وسيحاول التخفيف من تعطل الخدمة عن طريق جدولة الترحيل. ستتلقى الأجهزة الظاهرية المتأثرة حدثاً مجدولاً مع NotBefore عادة ما يكون بضعة أيام في المستقبل. يختلف الوقت الفعلي اعتماداً على تقييم مخاطر الفشل المتوقع. يحاول Azure إعطاء إشعار مسبق لمدة 7 أيام عندما يكون ذلك ممكنا، ولكن الوقت الفعلي يختلف وقد يكون أصغر إذا كان التنبؤ هو أن هناك فرصة كبيرة لفشل الأجهزة على وشك الفشل. لتقليل المخاطر على الخدمة، وفي حالة فشل الجهاز قبل بدء النظام الترحيل، نوصي بإعادة توزيع الجهاز الظاهري في أقرب وقت ممكن.
إشعار
في حالة تعرض العقدة المضيفة لفشل في الأجهزة، سيتجاوز Azure الحد الأدنى لفترة الإشعار ويبدأ على الفور عملية الاسترداد للأجهزة الظاهرية المتأثرة. وهذا يقلل من وقت الاسترداد في حالة عدم تمكن الأجهزة الظاهرية المتأثرة من الاستجابة. أثناء عملية الاسترداد، سيتم إنشاء حدث لجميع الأجهزة الظاهرية المتأثرة باستخدام EventType = Reboot وEventStatus = Started.
معدل الاقتراع
يمكنك استقصاء نقطة النهاية للتحديثات بشكل متكرر أو غير متكرر كما تريد. ومع ذلك، كلما طالت الفترة الزمنية بين الطلبات، زاد الوقت الذي قد تخسره للتفاعل مع حدث قادم. تحتوي معظم الأحداث على إشعار مسبق من 5 إلى 15 دقيقة، على الرغم من أنه في بعض الحالات قد يكون الإشعار المسبق أقل من 30 ثانية. للتأكد من أن لديك أكبر قدر ممكن من الوقت لاتخاذ إجراءات تخفيف، نوصيك باستطلاع رأي الخدمة مرة واحدة في الثانية.
بدء حدث
بعد أن تعلم بحدث قادم وتنتهي من منطقك لإيقاف التشغيل السريع، يمكنك الموافقة على الحدث المتميز عن طريق إجراء استدعاء POST إلى خدمة بيانات التعريف باستخدام EventId. يشير هذا الاستدعاء لـ Azure إلى أنه يمكنه تقصير الحد الأدنى من وقت الإعلام (عندما يكون ذلك ممكناً). قد لا يبدأ الحدث فورا عند الموافقة، في بعض الحالات يتطلب Azure موافقة جميع الأجهزة الظاهرية المستضافة على العقدة قبل المتابعة مع الحدث.
من المتوقع أن تكون عينة JSON التالية في نص الطلب POST. يجب أن يحتوي الطلب على قائمة بـ StartRequests. يحتوي كل StartRequest على EventId للحدث الذي تريد تسريعه:
{
"StartRequests" : [
{
"EventId": {EventId}
}
]
}
تقوم الخدمة دائما بإرجاع رمز نجاح 200 إذا تم تمرير معرف حدث صالح، حتى إذا وافق جهاز ظاهري آخر بالفعل على الحدث. يشير رمز الخطأ 400 إلى أن رأس الطلب أو البيانات الأساسية قد تم تكوينها بشكل غير صحيح.
إشعار
لن يتم متابعة الأحداث ما لم تتم الموافقة عليها إما عبر رسالة POST أو انقضاء الوقت NotBefore. يتضمن ذلك الأحداث التي يشغلها المستخدم مثل إعادة تشغيل الجهاز الظاهري من مدخل Microsoft Azure.
عينة Bash
curl -H Metadata:true -X POST -d '{"StartRequests": [{"EventId": "f020ba2e-3bc0-4c40-a10b-86575a9eabd5"}]}' http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
نموذج PowerShell
Invoke-RestMethod -Headers @{"Metadata" = "true"} -Method POST -body '{"StartRequests": [{"EventId": "5DD55B64-45AD-49D3-BBC9-F57D4EA97BD7"}]}' -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 | ConvertTo-Json -Depth 64
عينة Python
import json
import requests
def confirm_scheduled_event(event_id):
# This payload confirms a single event with id event_id
payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
response = requests.post("http://169.254.169.254/metadata/scheduledevents",
headers = {'Metadata' : 'true'},
params = {'api-version':'2020-07-01'},
data = payload)
return response.status_code
إشعار
يسمح الإقرار بحدث ما بالمضي قدماً في الحدث لجميع Resources في الحدث، وليس فقط الجهاز الظاهري الذي يقر بالحدث. لذلك، يمكنك اختيار انتخاب قائد لتنسيق الإقرار الذي قد يكون بسيطاً مثل الجهاز الأول في المجال Resources.
أمثلة على الردود
الأحداث التالية هي مثال تم رؤيته من قبل جهازين ظاهريين تم ترحيلهما مباشرة إلى عقدة أخرى.
DocumentIncarnation يتغير في كل مرة توجد فيها معلومات جديدة في Events. ومن شأن الموافقة على الحدث أن يسمح بمتابعة التجميد لكل من WestNO_0 وWestNO_1. DurationInSeconds يشير -1 إلى أن النظام الأساسي لا يعرف المدة التي ستستغرقها العملية.
{
"DocumentIncarnation": 1,
"Events": [
]
}
{
"DocumentIncarnation": 2,
"Events": [
{
"EventId": "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
"EventStatus": "Scheduled",
"EventType": "Freeze",
"ResourceType": "VirtualMachine",
"Resources": [
"WestNO_0",
"WestNO_1"
],
"NotBefore": "Mon, 11 Apr 2022 22:26:58 GMT",
"Description": "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
"EventSource": "Platform",
"DurationInSeconds": 5
}
]
}
{
"DocumentIncarnation": 3,
"Events": [
{
"EventId": "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
"EventStatus": "Started",
"EventType": "Freeze",
"ResourceType": "VirtualMachine",
"Resources": [
"WestNO_0",
"WestNO_1"
],
"NotBefore": "",
"Description": "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
"EventSource": "Platform",
"DurationInSeconds": 5
}
]
}
{
"DocumentIncarnation": 4,
"Events": [
]
}
عينة Python
يقوم النموذج التالي بالاستعلام عن خدمة بيانات التعريف للأحداث المجدولة والموافقة على كل حدث قائم:
#!/usr/bin/python
import json
import requests
from time import sleep
# The URL to access the metadata service
metadata_url ="http://169.254.169.254/metadata/scheduledevents"
# This must be sent otherwise the request will be ignored
header = {'Metadata' : 'true'}
# Current version of the API
query_params = {'api-version':'2020-07-01'}
def get_scheduled_events():
resp = requests.get(metadata_url, headers = header, params = query_params)
data = resp.json()
return data
def confirm_scheduled_event(event_id):
# This payload confirms a single event with id event_id
# You can confirm multiple events in a single request if needed
payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
response = requests.post(metadata_url,
headers= header,
params = query_params,
data = payload)
return response.status_code
def log(event):
# This is an optional placeholder for logging events to your system
print(event["Description"])
return
def advanced_sample(last_document_incarnation):
# Poll every second to see if there are new scheduled events to process
# Since some events may have necessarily short warning periods, it is
# recommended to poll frequently
found_document_incarnation = last_document_incarnation
while (last_document_incarnation == found_document_incarnation):
sleep(1)
payload = get_scheduled_events()
found_document_incarnation = payload["DocumentIncarnation"]
# We recommend processing all events in a document together,
# even if you won't be actioning on them right away
for event in payload["Events"]:
# Events that have already started, logged for tracking
if (event["EventStatus"] == "Started"):
log(event)
# Approve all user initiated events. These are typically created by an
# administrator and approving them immediately can help to avoid delays
# in admin actions
elif (event["EventSource"] == "User"):
confirm_scheduled_event(event["EventId"])
# For this application, freeze events less that 9 seconds are considered
# no impact. This will immediately approve them
elif (event["EventType"] == "Freeze" and
int(event["DurationInSeconds"]) >= 0 and
int(event["DurationInSeconds"]) < 9):
confirm_scheduled_event(event["EventId"])
# Events that may be impactful (for example, reboot or redeploy) may need custom
# handling for your application
else:
#TODO Custom handling for impactful events
log(event)
print("Processed events from document: " + str(found_document_incarnation))
return found_document_incarnation
def main():
# This will track the last set of events seen
last_document_incarnation = "-1"
input_text = "\
Press 1 to poll for new events \n\
Press 2 to exit \n "
program_exit = False
while program_exit == False:
user_input = input(input_text)
if (user_input == "1"):
last_document_incarnation = advanced_sample(last_document_incarnation)
elif (user_input == "2"):
program_exit = True
if __name__ == '__main__':
main()
الخطوات التالية
- راجع نماذج التعليمات البرمجية للأحداث المجدولة في مستودع GitHub للأحداث المجدولة لبيانات تعريف مثيل Azure.
- راجع نماذج التعليمات البرمجية لأحداث Node.js المجدولة في مستودع Azure Samples GitHub.
- اقرأ المزيد حول واجهات برمجة التطبيقات المتوفرة في خدمة بيانات تعريف المثيل.
- تعرف على الصيانة المخططة لأجهزة Linux الظاهرية في Azure.
- تعرّف على كيفية تسجيل الأحداث المجدولة باستخدام مركز أحداث Azure في مستودع Azure Samples GitHub.