مشغلات HTTP في Azure SRE Agent

مشغلات HTTP في Azure SRE Agent هي نقاط نهاية webhook تستخدمها الأنظمة الخارجية لاستدعاء وكيلك عند الطلب. عندما يفشل خط أنابيب التكامل المستمر والتسليم المستمر (CI/CD)، أو تكتشف أداة تنبيه وجود شذوذ، أو يرسل POST أي عميل HTTP طلبا، يستقبل الوكيل سياق الحدث ويبدأ العمل فورا.

المشكلة: التنبيهات وأعطال خطوط الأنابيب تحتاج إلى فرز يدوي

فريقك لديه بالفعل أدوات تنبيه، وقابلية الملاحظة، وسير العمل مثل Datadog وDynatrace وJira وSplunk وGrafana، وخطوط أنابيب CI/CD التي تتعطل. عندما يحدث خطأ ما، يكون الرد نفسه في كل مرة:

• يتم استدعاء المهندس: يفتح المهندس أداة المراقبة، يقرأ التنبيه، ثم يفتح السجلات والمقاييس وتاريخ النشر يدويا عبر عدة لوحات تحكم لمعرفة ما حدث.
• فشل خط الأنابيب: يجب على شخص ما أن يتوقف عما يفعله، ويتحقق من مخرجات البناء، ويربطه بالتغييرات الأخيرة، ويقرر ما إذا كان يجب التراجع أو إصلاحه للأمام.
• السياق مبعثر: تنبيه Datadog يقول: "ارتفاع المعالج في prod-api." السبب الجذري يتطلب ربط السجلات من ثلاث خدمات، وفحص النشرات الأخيرة، ومراجعة مسارات Dynatrace.

كيف تعمل محفزات HTTP

تتيح لك محفزات HTTP توصيل أي أداة تدعم webhooks مباشرة إلى نسخة وكيل SRE الخاصة بك. بدلا من أن يقوم مهندس بالفرز اليدوي، يأمر النظام الذي اكتشف المشكلة، سواء كان تنبيه Datadog، أو خلل في Dynatrace، أو انتقال سير عمل Jira، أو فشل في خط الأنابيب، الوكيل بالتحقيق. يتم نقل السياق تلقائيا.

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

المفاهيم الأساسية

المفهوم	طريقة العمل
المشغِّل	نقطة نهاية مسماة مع موجه، وكيل معين (افتراضي أو فرعي)، ومستوى استقلالية (مستقل أو مراجعة).
رابط الزناد	رابط الويب هوك الفريد الذي يتم إنشاؤه عند إنشاء محفز. هذا الرابط عبر webhook هو ما تسميه الأدوات الخارجية.
سياق JSON	تم إرسال جسم JSON اختياري مع الطلب POST . يصبح جزءا من طلب العميل حتى يكون له السياق الكامل.
محفوظات التنفيذ	يتم تسجيل كل استدعاء مع طابع زمني، ورابط موضوع، وحالة نجاح أو فشل.
تمكين/تعطيل	قم بتشغيل أو إيقاف المحفزات دون حذف. المشغلات المعطلة تعيد 404.

استدعاء محفز

استدعي عنوان URL الخاص بالمشغل بطلب HTTP POST :

curl -X POST \
  https://your-agent.sre.azure.com/api/v1/httptriggers/trigger/<TRIGGER_ID> \
  -H "Authorization: Bearer <ARM_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "datadog",
    "alert_title": "High error rate on checkout-api",
    "severity": "critical",
    "service": "checkout-api",
    "region": "eastus2",
    "metric": "error_rate",
    "value": "8.2%",
    "threshold": "5%"
  }'

الجزء	ما هو
عنوان URL	نقطة نهاية الويب هوك الفريدة للزناد. ابحث عنه في عرض تفاصيل الزناد تحت عنوان المحفز.
Authorization	رمز Azure Resource Manager Bearer. راجع المصادقة لاستدعاء المحفز.
نوع المحتوى	لابد أن ذلك إذا application/json كنت ترسل جثة JSON.
جسم JSON (اختياري)	أي بيانات JSON تريد أن يراها الوكيل. تصبح هذه البيانات جزءا من ملف الوكيل. أدرج أي سياق يساعد الوكيل في التحقيق، مثل اسم التنبيه، شدته، والخدمة المتأثرة.

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

المصادقة لاستدعاء المحفز

تتطلب نقطة النهاية الخاصة ب Trigger رمز حامل Azure Resource Manager في الرأس Authorization: Bearer <TOKEN> . يحتاج Microsoft.App/agents/threads/write المتصل إلى إذن بشأن مورد الوكيل.

طرق الحصول على الرمز

الطريقة	مناسب لـ	التفاصيل
كيان الخدمة	خطوط أنابيب CI/CD، الأنظمة الآلية	أنشئ تسجيل تطبيق، وخصص الدور في مورد الوكيل، واستخدم تدفق بيانات اعتماد العميل للحصول على رمز.
الهوية المدارة	Azure Hosted services (Azure Functions, Azure Virtual Machines, Azure Container Apps)	لا أسرار لتديرها. يتم التحقق تلقائيا من مورد Azure.
Azure CLI	الاختبار والتطوير	شغّل az account get-access-token --resource https://management.azure.com --query accessToken -o tsv.

ربط الأدوات الخارجية التي لا تدعم مصادقة Azure

أدوات مثل Datadog وDynatrace وJira وSplunk ترسل webhooks بصيغ مصادقتها الخاصة، وليس رموز Azure Resource Manager. لسد الفجوة، استخدم أحد الوسطاء التاليين.

وسيط	طريقة العمل
دالات Azure	يستقبل webhook، ويحصل على رمز Azure Resource Manager باستخدام هويته المدارة، ويعيد توجيه المكالمة إلى عنوان URL الخاص بالمشغل.
تطبيقات Azure Logic	سير العمل بدون كود يستقبل webhooks من أي مصدر ويستدعي واجهات Azure APIs مع مصادقة Azure Resource Manager مدمجة.
إدارة واجهة برمجة تطبيقات Azure	تجلس أمام عنوان URL الخاص بالمشغل وتتولى التحقق من صحة الرموز وتحويلها عبر السياسات.

الاستجابة

{
  "message": "HTTP trigger execution initiated",
  "executionTime": "2026-03-13T10:30:00Z",
  "threadId": "thread-abc123",
  "success": true
}

يعيد المحفز HTTP 202 (مقبول) فورا. يعالج الوكيل الطلب بشكل غير متزامن.

ما الذي يجعل هذا النهج مختلفا

مشغلات HTTP تربط أدوات التنبيه وCI/CD الحالية مباشرة بوكيلك دون وجود مهندس على الخطة. النظام الذي اكتشف المشكلة يأمر الوكيل بالتحقيق وينقل السياق الكامل تلقائيا. لا يوجد تبديل صفحات، ولا تبديل لوحة القيادة، ولا جمع سياقات يدوي.

قبل وبعد

قبل (الفرز اليدوي)	بعد (تفعيل HTTP)
تنبيه داتادوغ يطلق حريق. يتلقى المهندس اتصالا، يفتح ثلاث لوحات بيانات، ويبدأ التحقيق.	استدعاءات Webhook في Datadog تفعل. يقوم الوكيل بالتحقيق ونشر النتائج تلقائيا.
انقطاع في خط الأنابيب. يقوم المهندس بفحص سجلات البناء، ومراجعة الإقامة الدائمة، واتخاذ الخطوة التالية.	استدعاءات معالجة فشل خط الأنابيب تفعل. يقوم الوكيل بتحليل الفشل ويعلن عن السبب الجذري.
دايناتريس يكتشف شذوذا. المهندس يرتبط يدويا عبر الخدمات.	استدعاءات الشبكة في Dynatrace تفعل مع سياق الشذوذ. يقوم الوكيل بربط السجلات والمقاييس والنشرات.

المهام المجدولة مقابل مشغلات HTTP

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

استخدم الاثنين معا. استخدم المهام المجدولة للمراقبة الاستباقية ومحفزات HTTP للتعامل مع الأحداث التفاعلية.

حالات الاستخدام

تكامل البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD

عندما يفشل خط النشر، استدعي الوكيل لتحليل الفشل:

# In your pipeline's failure handler
curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"pipeline\": \"$PIPELINE_NAME\", \"run_id\": \"$RUN_ID\", \"error\": \"$ERROR_MESSAGE\"}"

تحقيق قائم على التنبيه

قم بتوصيل نظام التنبيه الخاص بك لتفعيل التحقيق الآلي عند حدوث تنبيهات حرجة:

{
  "alert_name": "Error rate > 5%",
  "severity": "P1",
  "service": "checkout-api",
  "region": "eastus2",
  "start_time": "2026-03-13T10:15:00Z"
}

فحوصات الامتثال للنشر

بعد اكتمال النشر، قم بتفعيل مراجعة الامتثال:

curl -X POST "$AGENT_TRIGGER_URL" \
  -H "Authorization: Bearer $ARM_TOKEN" \
  -d '{"deployment_id": "deploy-456", "environment": "production", "changes": ["config update", "image bump"]}'

مرجع واجهة برمجة التطبيقات

نقطة النهاية	الطريقة	الوصف
/api/v1/httptriggers	GET	اذكر جميع المحفزات.
/api/v1/httptriggers/create	POST	أنشئ محفزا جديدا.
/api/v1/httptriggers/{id}	GET	احصل على تفاصيل المحفز.
/api/v1/httptriggers/{id}	PUT	تحديث خصائص الزناد.
/api/v1/httptriggers/{id}	DELETE	احذف محفز.
/api/v1/httptriggers/{id}/enable	POST	فعل مشغلا.
/api/v1/httptriggers/{id}/disable	POST	عطل المحفز.
/api/v1/httptriggers/{id}/execute	POST	شغل الزناد يدويا.
/api/v1/httptriggers/{id}/executions	GET	احصل على سجل الإعدام.
/api/v1/httptriggers/trigger/{id}	POST	نقطة نهاية خارجية لشبكة الويبهوك.

استكشاف الأخطاء وإصلاحها

تريجر يعيد 404

• تحقق من أن الزناد مضبوط على تفعيل. المشغلات المعطلة تعيد 404.
• تحقق من صحة معرف المشغلات في الرابط.

401 غير مصرح به

• يجب أن يتطابق جمهور الرمز مع معرف تطبيق وكيل SRE، وليس https://management.azure.com.
• للحصول على رمز للاختبار، استخدم az account get-access-token --resource 59f0a04a-b322-4310-adc9-39ac41e9631e --query accessToken -o tsv.

يتم تنفيذ المحفز لكن الوكيل لا يتصرف

• تحقق من موضوع الوكيل. قد لا ينتج التوجيه الفارغ مخرجا مفيدا.
• تحقق من أن الوكيل الفرعي المختار يمتلك الأدوات اللازمة للمهمة.
• تحقق من سجل التنفيذ للحصول على تفاصيل الأخطاء.

الحدود

مورد	الحد
المحفزات لكل وكيل	لا يوجد حد صارم.
أقصى عدد من الأدوار لكل تنفيذ	250 دورة.
المصادقة	رمز حامل مطلوب لكل رابط مشغل.

المحتوى ذو الصلة

• المهام المجدولة
• أتمتة سير العمل
• إنشاء واختبار مشغل HTTP