دليل استكشاف الأخطاء وإصلاحها لناقل خدمة Azure

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

مشكلات الاتصال

انتهاء المهلة عند الاتصال بالخدمة

اعتمادا على بيئة المضيف والشبكة، قد تحدث مشكلة اتصال للتطبيقات إما TimeoutExceptionعلى أنها أو OperationCanceledExceptionأو ServiceBusException مع Reason ServiceTimeout وغالبا ما تحدث عندما لا يتمكن العميل من العثور على مسار شبكة إلى الخدمة.

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

• تحقق من صحة اسم المجال سلسلة الاتصال أو المؤهل بالكامل الذي حددته عند إنشاء العميل. للحصول على معلومات حول كيفية الحصول على سلسلة الاتصال، راجع الحصول على سلسلة الاتصال ناقل خدمة Microsoft Azure.
• تحقق من أذونات جدار الحماية والمنفذ في بيئة الاستضافة الخاصة بك. تحقق من فتح منفذي Advanced Message Queuing Protocol (AMQP) 5671 و5672 وأن نقطة النهاية مسموح بها من خلال جدار الحماية.
• حاول استخدام خيار نقل مأخذ توصيل ويب، الذي يتصل باستخدام المنفذ 443. للحصول على التفاصيل، راجع تكوين النقل.
• تحقق مما إذا كانت شبكتك تحظر عناوين IP محددة. للحصول على التفاصيل، راجع ما هي عناوين IP التي أحتاج إلى السماح بها؟
• إذا كان ذلك ممكنا، فتحقق من تكوين الوكيل. للحصول على التفاصيل، راجع: تكوين النقل
• لمزيد من المعلومات حول استكشاف أخطاء اتصال الشبكة وإصلاحها، راجع: [مشكلات الاتصال أو الشهادة أو المهلة][#connectivity-certificate-or-timeout-issues].

فشل مصافحة طبقة مأخذ التوصيل الآمن (SSL)

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

أخطاء استنفاد مأخذ التوصيل

يجب أن تفضل التطبيقات معاملة أنواع ناقل خدمة Microsoft Azure على أنها قاعدة بيانات أحادية، وإنشاء مثيل واحد واستخدامه طوال مدة بقاء التطبيق. ينتج عن كل ServiceBusClient جديد إنشاء اتصال AMQP جديد، والذي يستخدم مأخذ توصيل. يدير نوع ServiceBusClient الاتصال لكافة الأنواع التي تم إنشاؤها من هذا المثيل. يدير كل ServiceBusReceiver وServiceBusSessionReceiver وServiceBusSender وServiceBusProcessor ارتباط AMQP الخاص به للكيان المرتبط بناقل الخدمة. عند استخدام ServiceBusSessionProcessor، يتم إنشاء ارتباطات AMQP متعددة اعتمادا على عدد الجلسات التي تتم معالجتها بشكل متزامن.

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

لا تعمل إضافة مكونات إلى سلسلة الاتصال

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

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

بديل "TransportType=AmqpWebSockets"

لتكوين مآخذ ويب كنوع النقل، راجع تكوين النقل.

بديل "المصادقة = الهوية المدارة"

للمصادقة باستخدام الهوية المدارة، راجع: بيانات اعتماد الهوية والوصول المشترك. لمزيد من المعلومات حول المكتبة Azure.Identity ، راجع المصادقة وAzure SDK.

تسجيل الدخول والتشخيص

مكتبة عميل ناقل خدمة Microsoft Azure مجهزة بالكامل لتسجيل المعلومات على مستويات مختلفة من التفاصيل باستخدام .NET EventSource لإرسال المعلومات. يتم تنفيذ التسجيل لكل عملية ويتبع نمط وضع علامة على نقطة بداية العملية واكتمالها وأي استثناءات تمت مواجهتها. يتم أيضا تسجيل المعلومات الإضافية التي قد تقدم نتيجة تحليلات في سياق العملية المقترنة.

تمكين التسجيل

تتوفر سجلات عميل ناقل خدمة Microsoft Azure لأي EventListener من خلال الاشتراك في المصادر التي تبدأ ب Azure-Messaging-ServiceBus أو عن طريق الاشتراك في جميع المصادر التي لها السمة AzureEventSource. لتسهيل تسجيل السجلات من مكتبات عميل Azure، تقدم AzureEventSourceListenerالمكتبة Azure.Core المستخدمة من قبل ناقل خدمة Microsoft Azure .

لمزيد من المعلومات، راجع: التسجيل باستخدام Azure SDK ل .NET.

تتبع موزع

تدعم مكتبة عميل ناقل خدمة Microsoft Azure التتبع الموزع من خلال التكامل مع Application Insights SDK. كما أنه يحتوي على دعم تجريبي لمواصفات OpenTelemetry عبر نوع .NET ActivitySource المقدم في .NET 5. لتمكين ActivitySource الدعم للاستخدام مع OpenTelemetry، راجع دعم ActivitySource.

لاستخدام دعم GA DiagnosticActivity، يمكنك التكامل مع Application Insights SDK. يمكن العثور على مزيد من التفاصيل في ApplicationInsights باستخدام Azure Monitor.

تنشئ المكتبة النطاقات التالية:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

معظم الامتدادات تفسيرية ذاتيا ويتم بدء تشغيلها وإيقافها أثناء العملية التي تحمل اسمها. النطاق الذي يربط الآخرين معا هو Message. الطريقة التي يتم بها تتبع الرسالة هي عبر Diagnostic-Id التي تم تعيينها في الخاصية ServiceBusMessage.ApplicationProperties بواسطة المكتبة أثناء عمليات الإرسال والجدولة. في Application Insights، Message يتم عرض الامتدادات كارتباط بالامتدادات الأخرى المختلفة التي تم استخدامها للتفاعل مع الرسالة، على سبيل المثال، ServiceBusReceiver.Receive سيتم ربط النطاق ServiceBusSender.Send والامتداد والامتداد ServiceBusReceiver.Complete من Message النطاق. فيما يلي مثال لما يبدو عليه هذا في Application Insights:

في لقطة الشاشة أعلاه، ترى المعاملة الشاملة التي يمكن عرضها في Application Insights في المدخل. في هذا السيناريو، يرسل التطبيق رسائل ويستخدم ServiceBusSessionProcessor لمعالجتها. Message يرتبط النشاط ب ServiceBusSender.Sendو ServiceBusReceiver.ReceiveServiceBusSessionProcessor.ProcessSessionMessageو و.ServiceBusReceiver.Complete

إشعار

لمزيد من المعلومات، راجع التتبع الموزع والارتباط من خلال مراسلة ناقل خدمة Microsoft Azure.

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

لا يمكن إرسال دفعة بمفاتيح أقسام متعددة

عندما يرسل تطبيق دفعة إلى كيان ممكن للقسم، يجب أن يكون لكل الرسائل المضمنة في عملية إرسال واحدة نفس PartitionKey. إذا كان الكيان الخاص بك ممكنا للجلسة، فإن نفس المطلب ينطبق على الخاصية SessionId . لإرسال رسائل ذات قيم أو مختلفةPartitionKey، قم بتجميع الرسائل في مثيلات منفصلة ServiceBusMessageBatch أو تضمينها في استدعاءات منفصلة إلى التحميل الزائد SendMessagesAsync الذي يأخذ مجموعة من ServiceBusMessage المثيلات.SessionId

فشل إرسال الدفعة

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

استكشاف مشكلات جهاز الاستقبال وإصلاحها

عدد الرسائل التي تم إرجاعها لا يتطابق مع الرقم المطلوب في تلقي الدفعة

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

يتم فقدان تأمين الرسالة أو الجلسة قبل وقت انتهاء صلاحية التأمين

تستخدم خدمة ناقل خدمة Microsoft Azure بروتوكول AMQP، وهو أمر ذي حالة. نظرا لطبيعة البروتوكول، إذا تم فصل الارتباط الذي يربط العميل والخدمة بعد تلقي رسالة، ولكن قبل تسوية الرسالة، لا يمكن تسوية الرسالة عند إعادة توصيل الارتباط. يمكن فصل الارتباطات بسبب فشل عابر قصير الأجل في الشبكة أو انقطاع في الشبكة أو بسبب فرض الخدمة مهلة الخمول لمدة 10 دقائق. تتم إعادة توصيل الارتباط تلقائيا كجزء من أي عملية تتطلب الارتباط، أي تسوية الرسائل أو تلقيها. في هذه الحالة، تتلقى ServiceBusException مع Reason MessageLockLost أو SessionLockLost حتى إذا لم يمر وقت انتهاء صلاحية التأمين بعد.

كيفية استعراض الرسائل المجدولة أو المؤجلة

يتم تضمين الرسائل المجدولة والمؤجلة عند النظرة الخاطفة للرسائل. يمكن تحديدها بواسطة الخاصية ServiceBusReceivedMessage.State . بمجرد أن يكون لديك SequenceNumber لرسالة مؤجلة، يمكنك تلقيها مع تأمين عبر الأسلوب ReceiveDeferredMessagesAsync .

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

كيفية استعراض رسائل الجلسة عبر جميع جلسات العمل

يمكنك استخدام ServiceBusReceiver عادي لإضافة نظرة خاطفة عبر جميع الجلسات. لق نظرة خاطفة على جلسة عمل معينة، يمكنك استخدام ServiceBusSessionReceiver، ولكن تحتاج إلى الحصول على تأمين جلسة عمل.

NotSupportedException الذي تم طرحه عند الوصول إلى نص الرسالة

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

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

تجديد القفل التلقائي لا يعمل

يعتمد التجديد التلقائي على وقت النظام لتحديد وقت تجديد تأمين لرسالة أو جلسة عمل. إذا لم يكن وقت النظام دقيقا، على سبيل المثال، تكون ساعتك بطيئة، فقد لا يحدث تجديد التأمين قبل فقدان القفل. تأكد من دقة وقت النظام إذا لم يعمل تجديد القفل التلقائي.

يبدو أن المعالج معلق أو لديه مشكلات في زمن الانتقال عند استخدام التزامن العالي

غالبا ما يحدث هذا السلوك بسبب تجويع مؤشر الترابط، خاصة عند استخدام معالج الجلسة واستخدام قيمة عالية جدا ل MaxConcurrentSessions، بالنسبة إلى عدد الذاكرات الأساسية على الجهاز. أول شيء يجب فحصه هو التأكد من أنك لا تقوم بالمزامنة بشكل مفرط في أي من معالجات الأحداث الخاصة بك. المزامنة غير المتزامنة هي طريقة سهلة للتسبب في حالات التوقف التام وتجويع مؤشر الترابط. حتى إذا كنت لا تقوم بالمزامنة عبر غير متزامن، فإن أي تعليمة برمجية مزامنة خالصة في المعالجات الخاصة بك يمكن أن تساهم في تجويع مؤشر الترابط. إذا حددت أن هذه ليست المشكلة، على سبيل المثال، لأن لديك تعليمة برمجية غير متزامنة خالصة، يمكنك محاولة زيادة [TryTimeout][TryTimeout]. فهو يخفف الضغط على تجمع مؤشر الترابط عن طريق تقليل عدد مفاتيح تبديل السياق والمهلات التي تحدث عند استخدام معالج الجلسة على وجه الخصوص. القيمة الافتراضية ل [TryTimeout][TryTimeout] هي 60 ثانية، ولكن يمكن تعيينها حتى ساعة واحدة. نوصي بالاختبار مع TryTimeout تعيين إلى 5 دقائق كنقطة بداية والتكرار من هناك. إذا لم تعمل أي من هذه الاقتراحات، فأنت تحتاج ببساطة إلى توسيع نطاقها إلى مضيفين متعددين، ما يقلل من التزامن في التطبيق الخاص بك، ولكن تشغيل التطبيق على مضيفين متعددين لتحقيق التزامن الكلي المطلوب.

قراءة المزيد:

• تصحيح تجويع تجمع مؤشر الترابط
• تشخيص تجويع تجمع مؤشر ترابط .NET Core مع PerfView (لماذا لا تشبع خدمتي جميع الذاكرات الأساسية أو يبدو أنها تتوقف)
• تشخيص مشكلات استنفاد تجمع مؤشر الترابط في تطبيقات .NET Core (فيديو)

يستغرق معالج الجلسة وقتا طويلا جدا لتبديل جلسات العمل

يمكن تكوين هذا باستخدام [SessionIdleTimeout][SessionIdleTimeout]، الذي يخبر المعالج بمدة الانتظار لتلقي رسالة من جلسة عمل، قبل التخلي عن رسالة أخرى والانتقال إليها. من المفيد إذا كان لديك العديد من جلسات العمل قليلة الملء، حيث تحتوي كل جلسة على عدد قليل من الرسائل. إذا كنت تتوقع أن تحتوي كل جلسة على العديد من الرسائل التي تتشابك، يمكن أن يكون تعيينها منخفضا جدا عكس الإنتاجية، لأنها تؤدي إلى إغلاق غير ضروري لجلسة العمل.

يتوقف المعالج على الفور

غالبا ما تتم ملاحظة ذلك لسيناريوهات العرض التوضيحي أو الاختبار. StartProcessingAsync إرجاع مباشرة بعد بدء المعالج. لن يؤدي استدعاء هذا الأسلوب إلى حظر التطبيق الخاص بك والحفاظ عليه على قيد الحياة أثناء تشغيل المعالج، لذلك تحتاج إلى بعض الآليات الأخرى للقيام بذلك. بالنسبة إلى العروض التوضيحية أو الاختبارات، يكفي فقط إضافة Console.ReadKey() مكالمة بعد بدء تشغيل المعالج. بالنسبة لسيناريوهات الإنتاج، من المحتمل أن ترغب في استخدام نوع من تكامل إطار العمل مثل [BackgroundService][BackgroundService] لتوفير خطافات دورة حياة التطبيق المناسبة التي يمكن استخدامها لبدء المعالج والتخلص منه.

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

للحصول على معلومات عامة حول المعاملات في ناقل خدمة Microsoft Azure، راجع [نظرة عامة على معالجة معاملات ناقل خدمة Microsoft Azure][المعاملات].

العمليات المدعومة

لا يتم دعم جميع العمليات عند استخدام المعاملات. للاطلاع على قائمة المعاملات المدعومة، راجع [العمليات ضمن نطاق المعاملة][عمليات المعاملات].

المهلة

مهلة المعاملة بعد [فترة زمنية][TransactionTimeout]، لذلك من المهم أن تلتزم المعالجة التي تحدث داخل نطاق المعاملة بهذه المهلة.

لا تتم إعادة محاولة العمليات في معاملة

وهو كذلك بسبب طبيعة تصميمه. ضع في اعتبارك السيناريو التالي - تحاول إكمال رسالة داخل معاملة، ولكن هناك بعض الأخطاء العابرة التي تحدث، على سبيل المثال، ServiceBusException مع من Reason ServiceCommunicationProblem. لنفترض أن الطلب يقوم بذلك بالفعل إلى الخدمة. إذا كان العميل سيعيد المحاولة، فسترى الخدمة طلبين كاملين. لن يتم الانتهاء من أول اكتمال حتى يتم تنفيذ المعاملة. لا يمكن تقييم الإكمال الثاني حتى قبل انتهاء الإكمال الأول. تنتظر المعاملة على العميل اكتمال الانتهاء. يؤدي هذا إلى توقف تام حيث تنتظر الخدمة العميل لإكمال المعاملة، ولكن العميل ينتظر أن تعترف الخدمة بالعملية الكاملة الثانية. ستهل المعاملة في النهاية بعد دقيقتين، ولكن هذه تجربة مستخدم سيئة. لهذا السبب، لا نقوم بإعادة محاولة العمليات داخل معاملة.

المعاملات عبر الكيانات لا تعمل

لتنفيذ المعاملات التي تتضمن كيانات متعددة، تحتاج إلى تعيين الخاصية ServiceBusClientOptions.EnableCrossEntityTransactions إلى true. للحصول على التفاصيل، راجع عينة [المعاملات عبر الكيانات][CrossEntityTransactions].

الحصص النسبية

يمكن العثور على معلومات حول حصص ناقل خدمة Microsoft Azure [هنا][ServiceBusQuotas].

مشكلات الاتصال أو الشهادة أو المهلة

تساعدك الخطوات التالية في استكشاف مشكلات الاتصال/الشهادة/المهلة لجميع الخدمات ضمن *.servicebus.windows.net وإصلاحها.

• استعرض للوصول إلى أو wgethttps://<yournamespace>.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>
  

• قم بتشغيل الأمر التالي للتحقق من حظر أي منفذ على جدار الحماية. المنافذ المستخدمة هي 443 (HTTPS) و5671 و5672 (AMQP) و9354 (Net Messaging/SBMP). اعتماداً على المكتبة التي تستخدمها، يتم أيضاً استخدام منافذ أخرى. إليك الأمر النموذجي الذي يتحقق مما إذا كان المنفذ 5671 محظورا. C

  tnc <yournamespacename>.servicebus.windows.net -port 5671
  

  على نظام Linux:

  telnet <yournamespacename>.servicebus.windows.net 5671
  

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

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

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

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

• للعثور على عناوين IP المناسبة لإضافتها إلى قائمة السماح لاتصالاتك، راجع ما هي عناوين IP التي أحتاج إلى إضافتها إلى قائمة السماح.

في 30 سبتمبر 2026، سنتقاعد دعم بروتوكول SBMP ناقل خدمة Azure، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات SDK ناقل خدمة Azure باستخدام بروتوكول AMQP، الذي يوفر تحديثات أمان مهمة وقدرات محسنة، قبل ذلك التاريخ.

لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

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

العلامات

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

السبب

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

نوع الحل

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

الوصول غير المصرح به: مطلوب إرسال المطالبات

العلامات

قد ترى هذا الخطأ عند محاولة الوصول إلى موضوع ناقل خدمة Microsoft Azure من Visual Studio على كمبيوتر محلي باستخدام هوية مدارة معينة من قبل المستخدم مع أذونات الإرسال.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

السبب

لا تملك الهوية أذونات للوصول إلى موضوع "ناقل الخدمة".

نوع الحل

لحل هذا الخطأ، قم بتثبيت مكتبة Microsoft.Azure.Services.AppAuthentication. لمزيد من المعلومات، راجع مصادقة التطوير المحلي.

لمعرفة كيفية تعيين أذونات للأدوار، راجع مصادقة هوية مدارة باستخدام معرف Microsoft Entra للوصول إلى موارد ناقل خدمة Azure.

استثناء ناقل الخدمة: فشل وضع الرمز المميز

العلامات

تتلقى رسالة الخطأ التالية:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

في 30 سبتمبر 2026، سنتقاعد مكتبات SDK ناقل خدمة Azure WindowsAzure.ServiceBus وMicrosoft.Azure.ServiceBus و com.microsoft.azure.servicebus، والتي لا تتوافق مع إرشادات Azure SDK. سننهي أيضا دعم بروتوكول SBMP، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات Azure SDK، والتي توفر تحديثات أمان هامة وقدرات محسنة، قبل ذلك التاريخ.

على الرغم من أنه لا يزال من الممكن استخدام المكتبات القديمة بعد 30 سبتمبر 2026، إلا أنها لن تتلقى بعد ذلك الدعم والتحديثات الرسمية من Microsoft. لمزيد من المعلومات، راجع إعلان إيقاف الدعم.

السبب

تجاوز عدد رموز المصادقة المميزة للارتباطات المتزامنة في اتصال واحد بمساحة اسم ناقل خدمة Microsoft Azure الحد الأقصى: 1000.

نوع الحل

قم بإحدى الخطوات التالية:

• قلل عدد الارتباطات المتزامنة في اتصال واحد أو استخدم اتصال جديد
• استخدم عدد تطوير البرامج لناقل خدمة Microsoft Azure، ما يضمن عدم حصول هذا الموقف (مستحسن)

لا تعمل أقفال الموارد عند استخدام وحدة البيانات SDK

العلامات

لقد قمت بتكوين تأمين حذف على مساحة اسم ناقل خدمة Microsoft Azure، ولكن يمكنك حذف الموارد في مساحة الاسم (قوائم الانتظار والموضوعات وما إلى ذلك) باستخدام مستكشف ناقل الخدمة.

السبب

يتم الاحتفاظ بتأمين المورد في Azure Resource Manager (مستوى التحكم) ولا يمنع استدعاء SDK لمستوى البيانات من حذف المورد مباشرة من مساحة الاسم. يستخدم مستكشف ناقل خدمة Microsoft Azure المستقل SDK لمستوى البيانات، لذلك يمر الحذف.

نوع الحل

نوصي باستخدام واجهة برمجة التطبيقات المستندة إلى Azure Resource Manager عبر مدخل Microsoft Azure أو PowerShell أو CLI أو قالب Resource Manager لحذف الكيانات بحيث يمنع تأمين المورد حذف الموارد عن طريق الخطأ.

لم يعد الكيان متوفرا

العلامات

ترى خطأ بأن الكيان لم يعد متوفرا.

السبب

ربما تم حذف المورد. اتبع هذه الخطوات لتحديد سبب حذف الكيان.

• تحقق من سجل النشاط لمعرفة ما إذا كان هناك طلب Azure Resource Manager للحذف.
• تحقق من السجل التشغيلي لمعرفة ما إذا كان هناك استدعاء مباشر لواجهة برمجة التطبيقات للحذف. لمعرفة كيفية جمع سجل تشغيلي، راجع مراقبة ناقل خدمة Azure. للحصول على المخطط ومثال لسجل عملية، راجع سجلات العمليات
• تحقق من سجل العملية لمعرفة ما إذا كان autodeleteonidle هناك حذف ذي صلة.

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

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

• استثناءات Azure Resource Manager. تسرد استثناءات تم إنشاؤها عند التفاعل مع ناقل خدمة Azure باستخدام Azure Resource Manager (عبر قوالب أو مكالمات مباشرة).
• استثناءات الرسائل. يوفر قائمة الاستثناءات التي تم إنشاؤها بواسطة .NET Framework لناقل خدمة Azure.