استكشاف مشكلات الاتصال وإصلاحها - مراكز الأحداث

تتوافر أسباب مختلفة تمنع تطبيقات العميل من الاتصال بمراكز الأحداث. قد تكون مشكلات الاتصال دائمة أو عابرة.

إذا حدثت المشكلة طوال الوقت (دائمة)، فتحقق من هذه الإعدادات والخيارات الأخرى المذكورة في قسم استكشاف مشكلات الاتصال الدائم وإصلاحها في هذه المقالة.

• سلسلة الاتصال
• إعدادات جدار الحماية لمؤسستك
• إعدادات جدار حماية IP
• إعدادات أمان الشبكة (نقاط نهاية الخدمة ونقاط النهاية الخاصة وما إلى ذلك)، والمزيد

بالنسبة للمشكلات العابرة، جرب الخيارات التالية التي يمكن أن تساعد في استكشاف المشكلات وإصلاحها. لمزيد من المعلومات، راجع استكشاف مشكلات الاتصال العابر وإصلاحها.

• الترقية إلى أحدث إصدار من SDK
• تشغيل الأوامر للتحقق من الحزم التي تم إسقاطها
• الحصول على تتبعات الشبكة.

استكشاف مشكلات الاتصال الدائم وإصلاحها

إذا لم يتمكن التطبيق من الاتصال بمراكز الأحداث، فاتبع الخطوات الواردة في هذا القسم لاستكشاف المشكلة وإصلاحها.

تحقق مما إذا كان هناك انقطاع في الخدمة

تحقق من وجود انقطاع في خدمات مراكز الأحداث موقع حالة خدمة.

التحقق من سلسلة الاتصال

تحقق من صحة سلسلة الاتصال الذي تستخدمه. راجع الحصول على سلسلة الاتصال للحصول على سلسلة الاتصال باستخدام مدخل Microsoft Azure أو CLI أو PowerShell.

بالنسبة لعملاء Kafka، تحقق من إجراء تكوين صحيح لملفات تكوين المنتج والمستهلك كل على حدة. لمزيد من المعلومات، راجع إرسال رسائل واستلامها باستخدام Kafka في مراكز الأحداث.

ما هي البروتوكولات التي يمكنني استخدامها لإرسال الأحداث وتلقيها؟

يمكن للمنتجين أو المرسلين استخدام بروتوكول وضع المراسلة المتقدمة في قائمة الانتظار (AMQP) أو Kafka أو بروتوكولات HTTPS لإرسال الأحداث إلى مركز أحداث.

يستخدم المستهلكون أو المستلمون AMQP أو Kafka لتلقي الأحداث من مركز أحداث. تدعم مراكز الأحداث نموذج السحب فقط للمستهلكين لتلقي الأحداث منه. حتى عند استخدام معالجات الأحداث لمعالجة الأحداث من مركز أحداث، يستخدم معالج الحدث داخليا نموذج السحب لتلقي الأحداث من مركز الأحداث.

AMQP

يمكنك استخدام بروتوكول AMQP 1.0 لإرسال الأحداث وتلقيها من Azure Event Hubs. يوفر AMQP اتصالات موثوقة وأداء وآمنة لكل من إرسال الأحداث واستقبالها. يمكنك استخدامه للبث عالي الأداء وفي الوقت الحقيقي ويتم دعمه من قبل معظم Azure Event Hubs SDKs.

واجهة برمجة تطبيقات HTTPS/REST

يمكنك فقط إرسال الأحداث إلى مراكز الأحداث باستخدام طلبات HTTP POST. لا تدعم مراكز الأحداث تلقي الأحداث عبر HTTPS. إنه مناسب للعملاء الخفيفين حيث لا يكون اتصال TCP المباشر ممكنا.

Apache Kafka

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

تجرد Azure SDKs بروتوكولات الاتصال الأساسية وتوفر طريقة مبسطة لإرسال الأحداث وتلقيها من مراكز الأحداث باستخدام لغات مثل C#، وJava، وPython، وJavaScript، وما إلى ذلك.

ما المنافذ التي أحتاج إلى فتحها على جدار الحماية؟

يمكنك استخدام البروتوكولات التالية مع لوحات الوصل الحدث Azure لإرسال الأحداث وتلقيها:

• بروتوكول متقدمة لوضع الرسائل في قائمة انتظار 1.0 (AMQP)
• بروتوكول نقل النص التشعبي 1.1 مع أمان طبقة النقل (HTTPS)
• Apache Kafka

راجع الجدول التالي المنافذ الصادرة تحتاج إلى فتح لاستخدام هذه البروتوكولات للاتصال مع لوحات الوصل الحدث Azure.

منفذ HTTPS مطلوب للاتصال الصادر أيضا عند استخدام AMQP عبر المنفذ 5671، لأن العديد من عمليات الإدارة التي تنفذها SDKs للعميل والحصول على الرموز المميزة من معرف Microsoft Entra (عند استخدامها) تعمل عبر HTTPS.

يستخدم Azure SDK الرسمي بشكل عام بروتوكول AMQP لإرسال الأحداث وتلقيها من مراكز الأحداث. خيار بروتوكول AMQP عبر WebSockets يعمل عبر منفذ TCP 443 تمامًا مثل HTTP API، ولكن يتطابق بخلاف ذلك وظيفيًا مع AMQP العادي. يحتوي هذا الخيار على زمن وصول اتصال أولي أعلى بسبب جولات تأكيد الاتصال الإضافية والمزيد من النفقات العامة كمقايضة لمشاركة منفذ HTTPS. إذا تم تحديد هذا الوضع، فمنفذ TCP 443 كافٍ للاتصال. تسمح الخيارات التالية بتحديد وضع AMQP أو AMQP WebSockets عادي:

ما هي عناوين IP التي أحتاج إلى السماح بها؟

عندما تعمل مع Azure، يتعين عليك أحياناً السماح بنطاقات عناوين IP أو عناوين URL معينة في جدار الحماية أو الوكيل الخاص بشركتك للوصول إلى جميع خدمات Azure التي تستخدمها أو تحاول استخدامها. تحقق من أن حركة المرور مسموح بها على عناوين IP المستخدمة من قبل لوحات الوصل الأحداث. لعناوين IP المستخدمة من قبل مراكز أحداث Azure: راجع نطاقات IP Azure وعلامات الخدمة - السحابة العامة.

أيضًا، تحقق من أن عنوان IP لمساحة الاسم مسموح به. للبحث عن عناوين IP الصحيحة للسماح باتصالاتك، اتبع الخطوات التالية:

1. تشغيل الأمر التالي من موجه الأوامر:

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. لاحظ أسفل عنوان IP الذي تم إرجاعه في Non-authoritative answer.

إذا كنت تستخدم مساحة اسم مستضافة في مجموعة قديمة (استنادا إلى الخدمات السحابية - CNAME تنتهي ب *.cloudapp.net) ومساحة الاسم زائدة عن الحاجة في المنطقة، فأنت بحاجة إلى اتباع بعض الخطوات الإضافية. إذا كانت مساحة الاسم الخاصة بك على نظام مجموعة أحدث (استنادا إلى مجموعة مقياس الجهاز الظاهري - CNAME تنتهي ب *.cloudapp.azure.com) وتكرار المنطقة، يمكنك تخطي الخطوات أدناه.

1. أولاً، تشغيل nslookup على مساحة الاسم.

   nslookup <yournamespace>.servicebus.windows.net
   

2. قم بتدوين الاسم في قسم إجابة غير موثوق بها، الموجود بأحد التنسيقات التالية:

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. تشغيل nslookup لكل واحد مع لاحقات s1 وs2 وs3 للحصول على عناوين IP من كافة المثيلات الثلاثة قيد التشغيل في ثلاث مناطق توفر،

   إشعار

   عنوان IP الذي يعرضه الأمر nslookupليس عنوان IP ثابتًا. ومع ذلك، يبقى ثابتًا حتى يتم حذف النشر الأساسي أو نقله إلى كتلة مختلفة.

ما هي IPs العميل إرسال الأحداث إلى أو تلقي الأحداث من مساحة الاسم الخاصة بي؟

أولا، قم بتمكين تصفية IP على مساحة الاسم.

بعد ذلك، قم بتمكين سجلات التشخيص لأحداث اتصال الشبكة الظاهرية لمراكز الأحداث باتباع الإرشادات الواردة في تمكين سجلات التشخيص. ترى عنوان IP الذي تم رفض الاتصال له.

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

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

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

تحقق مما إذا كان التطبيق يحتاج إلى التشغيل في شبكة فرعية معينة من شبكة ظاهرية

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

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

التحقق من إعدادات جدار حماية IP لمساحة الاسم خاصتك

تحقق أن عنوان IP العام للجهاز الذي يتم تشغيل التطبيق عليه غير محظور بواسطة جدار حماية IP.

بشكل افتراضي، يمكن الوصول إلى مساحات أسماء مراكز الأحداث من الإنترنت طالما أن الطلب يأتي مع مصادقة وتخويل صالحين. باستخدام جدار حماية IP، يمكنك تقييده بشكل أكبر على مجموعة من عناوين IPv4 أو IPv6 أو نطاقات العناوين فقط في رمز CIDR (توجيه بين المجالات بدون فئة).

يتم تطبيق قواعد جدار الحماية على مستوى مساحة اسم مراكز الأحداث. لذلك، تنطبق القواعد على جميع الاتصالات من العملاء الذين يستخدمون أي بروتوكول مدعوم. يتم رفض أي محاولة اتصال من عنوان IP لا يتطابق مع قاعدة IP المسموح بها في مساحة اسم Event Hubs باعتبارها غير مصرح بها. لم يُذكر في الاستجابة قاعدة IP. يتم تطبيق قواعد عامل تصفية IP بالترتيب، وتحدد القاعدة الأولى التي تطابق عنوان IP إجراء القبول أو الرفض.

لمزيد من المعلومات، راجع تكوين قواعد جدار حماية IP لمساحة اسم مراكز الأحداث. للتحقق مما إذا كان لديك مشكلات في تصفية IP أو شبكة ظاهرية أو سلسلة شهادات، راجع استكشاف مشكلات الشبكة وإصلاحها.

التحقق من إمكانية الوصول إلى مساحة الاسم باستخدام نقطة تقديم الخدمة الخاصة فقط

في حالة تكوين مساحة اسم مراكز الأحداث للوصول فقط عبر نقطة تقديم الخدمة الخاصة، تأكد من أن تطبيق العميل يسمح بالوصول إلى مساحة الاسم عبر نقطة تقديم الخدمة الخاصة.

تمكنك خدمة Azure Private Link من الوصول إلى مراكز الأحداث عبر نقطة تقديم الخدمة الخاصة في الشبكة الظاهرية. نقطة النهاية الخاصة هي واجهة شبكة اتصال تربطك بشكل خاص وآمن بخدمة مدعومة من ارتباط Azure الخاص. تستخدم نقطة النهاية الخاصة عنوان IP خاص من الشبكة الظاهرية؛ مما يؤدي إلى إدخال الخدمة إلى الشبكة الظاهرية. يمكن توجيه كافة حركة المرور إلى الخدمة من خلال نقطة النهاية الخاصة، لذلك لا توجد بوابات أو أجهزة NAT أو اتصالات ExpressRoute أو VPN أو عناوين IP عامة مطلوبة. قم بنقل البيانات بين شبكتك الظاهرية وخدمات الاجتياز عبر شبكة Microsoft الأساسية، مما يلغي التعرض للإنترنت العام. يمكنك الاتصال بمثيل مورد Azure، مما يمنحك أعلى مستوى من الدقة في التحكم في الوصول.

لمزيد من المعلومات، الرجاء الرجوع إلىتكوين نقاط النهاية الخاصة. راجع التحقق من صحة عمل اتصال نقطة النهاية الخاصة لتأكيد استخدام نقطة نهاية خاصة.

استكشاف المشكلات المتصلة بالشبكة وإصلاحها

لاستكشاف المشاكل المتعلقة بالشبكة مع "مراكز الأحداث"، الرجاء اتباع الخطوات المذكورة أدناه:

استعرض للوصول إلى أو wgethttps://<yournamespacename>.servicebus.windows.net/. يساعد في التحقق مما إذا كان لديك تصفية IP أو مشكلات متعلقة بالشبكة الظاهرية أو سلسلة الشهادات (المشكلات الشائعة عند استخدام Java SDK).

نموذج على الرسالة الناجحة:

<feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

مثال على رسالة خطأ لوجود فشل:

<Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

استكشاف مشكلات الاتصال العابر وإصلاحها

إذا كنت تواجه مشكلات اتصال متقطعة، فانتقل إلى الأقسام التالية للحصول على تلميحات حول استكشاف الأخطاء وإصلاحها.

استخدام أحدث إصدار من SDK للعميل

قد تكون بعض مشكلات الاتصال العابرة قد تم إصلاحها في الإصدارات الأحدث من SDK مما تستخدمه. تأكد من أنك تستخدم أحدث إصدار من حزم SDK للعميل في تطبيقاتك. يتم تحسين SDKs باستمرار بإدخال ميزات جديدة / محدثة وإصلاحات الأخطاء؛ لذلك يرجى إجراء الاختبار الدائم باستخدام أحدث الحزم. تحقق من وجود ملاحظات الإصدار بحثًا عن وجود المشكلات التي تم إصلاحها والميزات المضافة/المحدثة.

للحصول على معلومات حول SDKs العميل راجع مقالة مراكز الأحداث-ووحدات Client SDKs.

قم بتشغيل الأمر للتحقق من الحزم التي تم إسقاطها

عند وجود مشكلات اتصال متقطعة، قم بتشغيل الأمر التالي للتحقق مما إذا كانت هناك أي حزم تم إسقاطها. يحاول هذا الأمر إنشاء 25 اتصال TCP مختلف كل ثانية مع الخدمة. بعد ذلك، يمكنك التحقق من عدد مرات النجاح/الإخفاق منها وكذلك الاطلاع على زمن انتقال اتصال TCP. يمكنك تنزيل الأداة psping من هنا .

.\psping.exe -n 25 -i 1 -q <yournamespacename>.servicebus.windows.net:5671 -nobanner     

يمكنك استخدام أوامر مكافئة إذا كنت تستخدم أدوات أخرى مثل tnc و ping وما إلى ذلك.

احصل على تتبع الشبكة إذا لم تساعدك الخطوات السابقة وقم بتحليلها باستخدام أدوات مثل Wireshark . اتصل بـ دعم Microsoft إذا لزم الأمر.

ترقيات/إعادة تشغيل الخدمة

قد تحدث مشكلات اتصال عابرة بسبب ترقيات الخدمة الخلفية وإعادة تشغيلها. عند حدوثها، قد ترى الأعراض التالية:

• قد يكون هناك انخفاض في الرسائل/الطلبات الواردة.
• قد يحتوي ملف السجل على رسائل خطأ.
• قد يتم قطع اتصال التطبيقات بالخدمة لبضع ثوان.
• قد يتم تقييد الطلبات بشكل لحظي.

إذا كانت التعليمة البرمجية للتطبيق تستخدم SDK، فإن سياسة إعادة المحاولة مضمنة بالفعل ونشطة. يعيد التطبيق الاتصال دون تأثير كبير على التطبيق/سير العمل. يضمن التقاط هذه الأخطاء العابرة، والتراجع ثم إعادة محاولة الاستدعاء أن التعليمات البرمجية الخاصة بك مرنة لهذه المشكلات العابرة.

الخطوات التالية

راجع المقالات التالية:

• استكشاف مشكلات المصادقة والتخويل وإصلاحها