استكشاف أخطاء مخرجات Stream Analytics وإصلاحها
تصف هذه المقالة المشكلات المشتركة مع اتصالات إخراج Azure Stream Analytics وكيفية استكشاف مشاكل الإخراج. تتطلب العديد من خطوات استكشاف الأخطاء وإصلاحها تمكين الموارد وسجلات التشخيص الأخرى لوظيفة Stream Analytics الخاصة بك. إذا لم يكن لديك تمكين سجلات الموارد، انظر استكشاف الأخطاء في Azure Stream Analytics باستخدام سجلات الموارد .
الوظيفة لا تنتج مخرجات
تحقق من الاتصال بالمخرجات باستخدام زر اتصال الاختبار لكل مخرج.
انظر إلى مهمة Monitor Stream Analytics باستخدام مدخل Microsoft Azure على علامة التبويب Monitor. نظرا لتجميع القيم، يتم تأخير المقاييس لبضع دقائق.
- إذا كانت قيمة Input Events أكبر من الصفر، فيمكن للوظيفة قراءة بيانات الإدخال. إذا كانت قيمة Input Events ليست أكبر من الصفر، فهناك مشكلة في مدخلات الوظيفة. راجع استكشاف أخطاء اتصالات الإدخال وإصلاحها للحصول على مزيد من المعلومات. إذا كانت وظيفتك تحتوي على مدخلات بيانات مرجعية، فقم بتطبيق التقسيم بالاسم المنطقي عند النظر إلى Input Events metric. إذا لم تكن هناك أحداث إدخال من البيانات المرجعية الخاصة بك وحدها، فمن المحتمل أن هذا يعني أن مصدر الإدخال هذا لم يتم تكوينه بشكل صحيح لجلب مجموعة البيانات المرجعية الصحيحة.
- إذا كانت قيمة أخطاء تحويل البيانات أكبر من الصفر وتتسلق، انظر أخطاء بيانات Stream Analytics للحصول على معلومات مفصلة حول أخطاء تحويل البيانات.
- إذا كانت قيمة أخطاء وقت التشغيل أكبر من الصفر، فإن وظيفتك تتلقى البيانات ولكنها تولد أخطاء أثناء معالجة الاستعلام. للعثور على الأخطاء، انتقل إلى سجلات التدقيق ، ثم تصفية على حالة فاشل .
- إذا كانت قيمة أحداث الإدخال أكبر من الصفر وقيمة أحداث الإخراج تساوي صفرا، فإن إحدى العبارات التالية صحيحة:
- أسفرت معالجة الاستعلام عن عدم حدوث أي إخراج.
- قد تكون الأحداث أو الحقول مشوهة، مما يؤدي إلى عدم وجود ناتج بعد معالجة الاستعلام.
- لم تتمكن الوظيفة من دفع البيانات إلى مصدر الإخراج لأسباب الاتصال أو المصادقة.
تشرح رسائل سجل العمليات المذكورة تفاصيل إضافية، بما في ذلك ما يحدث، باستثناء الحالات التي يقوم فيها منطق الاستعلام بتصفية جميع الأحداث. إذا أدت معالجة الأحداث المتعددة إلى حدوث أخطاء، فإن الأخطاء تتجمع كل 10 دقائق.
تأخر الإخراج الأول
عند بدء وظيفة Stream Analytics، تتم قراءة أحداث الإدخال. لكن، يمكن أن يكون هناك تأخير في الناتج، في ظروف معينة.
يمكن أن تساهم القيم الزمنية الكبيرة في عناصر الاستعلام الزمني في تأخير الناتج. لإنتاج الإنتاج الصحيح عبر نوافذ زمنية كبيرة، تقرأ وظيفة البث البيانات من آخر وقت ممكن لملء نافذة الوقت. يمكن أن تصل البيانات إلى سبعة أيام مضت. لا ينتج أي ناتج حتى تتم قراءة أحداث المدخلات المعلقة. يمكن أن تظهر هذه المشكلة عندما يقوم النظام بترقية وظائف البث. عندما تتم الترقية، تستأنف الوظيفة. تحدث مثل هذه الترقيات بشكل عام مرة كل شهرين.
استخدم السلطة التقديرية عند تصميم استعلام Stream Analytics الخاص بك. إذا كنت تستخدم نافذة زمنية كبيرة للعناصر الزمنية في بناء الاستعلام الخاص بالوظيفة، فقد يؤدي ذلك إلى تأخير الإخراج الأول عند بدء الوظيفة أو إعادة تشغيلها. أكثر من عدة ساعات، حتى سبعة أيام، تعتبر نافذة زمنية كبيرة.
أحد التخفيفات لهذا النوع من التأخير في الناتج الأول هو استخدام تقنيات موازاة الاستعلام، مثل تقسيم البيانات. أو يمكنك إضافة المزيد من وحدات البث لمعدل النقل حتى تلحق الوظيفة بالركب. لمزيد من المعلومات، راجع الاعتبارات عند إنشاء وظائف Stream Analytics .
تؤثر هذه العوامل على حسن توقيت الناتج الأول:
استخدام الركام النافذ، مثل شرط GROUP BY للهبوط والقفز والنوافذ المنزلقة:
- بالنسبة لتجمعات نوافذ الهبوط أو القفز، تولد النتائج في نهاية الإطار الزمني للنافذة.
- بالنسبة للنافذة المنزلقة، تولد النتائج عندما يدخل حدث ما أو يخرج من النافذة المنزلقة.
- إذا كنت تخطط لاستخدام حجم نافذة كبير، مثل أكثر من ساعة، فمن الأفضل اختيار نافذة القفز أو الانزلاق. توفر لك أنواع النوافذ هذه رؤية الإخراج بشكل متكرر.
استخدام الوصلات الزمنية، مثل الانضمام إلى DATEDIFF:
- تتولد المباريات بمجرد وصول كلا جانبي الأحداث المطابقة.
- يتم إنشاء البيانات التي تفتقر إلى التطابق، مثل LEFT OUTER JOIN، في نهاية نافذة DATEDIFF، لكل حدث على الجانب الأيسر.
استخدام الوظائف التحليلية الزمنية، مثل ISFIRST و LAST و LAG ذات المدة المحدودة:
- بالنسبة للوظائف التحليلية، يتم توليد الناتج لكل حدث. ليس هناك تأخير.
يتخلف الناتج عن الركب
خلال التشغيل العادي للوظيفة، قد يكون للإنتاج فترات زمنية أطول وأطول. إذا تأخر الناتج بهذه الطريقة، يمكنك تحديد الأسباب الجذرية من خلال فحص العوامل التالية:
- ما إذا كان يتم تقييد المتلقي
- ما إذا كان متلقي انتقال البيانات من الخادم مقيدا
- ما إذا كان منطق المعالجة في الاستعلام حسابيًا أم لا
لتفاصيل الإخراج، حدد مهمة الدفق في مدخل Microsoft Azure، ثم حدد الرسم التخطيطي للوظيفة. لكل مدخل، هناك مقياس حدث متراكم لكل قسم. إذا استمر المقياس في الزيادة، فهذا مؤشر على أن موارد النظام مقيدة. من المحتمل أن تكون الزيادة بسبب تقييد مصدر الإنتاج، أو ارتفاع استخدام وحدة المعالجة المركزية. للمزيد من المعلومات، راجع تصحيح الأخطاء المستند إلى البيانات باستخدام الرسم التخطيطي للوظيفة.
تحذير من انتهاك رئيسي مع إخراج قاعدة بيانات Azure SQL
عندما تقوم بتكوين قاعدة بيانات Azure SQL كمخرج لوظيفة Stream Analytics، فإنها تقوم بإدخال السجلات في جدول الوجهة. بشكل عام، تضمن Azure Stream Analytics التسليم مرة واحدة على الأقل إلى حوض الإخراج. لا يزال بإمكانك تحقيق التسليم مرة واحدة بالضبط لإخراج SQL عندما يكون لجدول SQL قيد فريد محدد.
عند إعداد قيود رئيسية فريدة على جدول SQL، تقوم Azure Stream Analytics بإزالة السجلات المكررة. يقوم بتقسيم البيانات إلى دفعات وإدخال الدفعات بشكل متكرر حتى يتم العثور على سجل مكرر واحد. تتجاهل عملية الانقسام والإدراج التكرارات واحدة تلو الأخرى. بالنسبة لوظيفة البث التي تحتوي على العديد من الصفوف المكررة، فإن العملية غير فعالة وتستغرق وقتًا طويلاً. إذا رأيت رسائل تحذير متعددة من الانتهاكات الرئيسية في سجل النشاط الخاص بك للساعة السابقة، فمن المحتمل أن إخراج SQL الخاص بك يبطئ الوظيفة بأكملها.
لحل هذه المشكلة، قم بتكوين المؤشر الذي يتسبب في انتهاك المفتاح من خلال تمكين خيار IGNORE_DUP_KEY. يسمح هذا الخيار لـ SQL بتجاهل القيم المكررة أثناء الإدخال بالجملة. قاعدة بيانات Azure SQL تنتج ببساطة رسالة تحذير بدلاً من خطأ. نتيجة لذلك، لم تعد Azure Stream Analytics تنتج أخطاء رئيسية في الانتهاكات.
لاحظ الملاحظات التالية عند تشكيل IGNORE_DUP_KEY لعدة أنواع من الفهارس:
- لا يمكنك ضبط IGNORE_DUP_KEY على مفتاح أساسي أو قيد فريد يستخدم ALTER INDEX. تحتاج إلى إسقاط المؤشر وإعادة إنشائه.
- يمكنك ضبط IGNORE_DUP_KEY باستخدام ALTER INDEX لمؤشر فريد. يختلف هذا المثال عن مفتاح أساسي/قيد فريد ويتم إنشاؤه باستخدام تعريف CREATE INDEX أو INDEX.
- لا ينطبق خيار IGNORE_DUP_KEY على فهارس متجر الأعمدة لأنه لا يمكنك فرض التفرد عليها.
منطق إعادة تجربة إخراج SQL
عندما تتلقى وظيفة Stream Analytics مع إخراج SQL الدُفعة الأولى من الأحداث، تحدث الخطوات التالية:
- تحاول الوظيفة الاتصال بـ SQL.
- تجلب الوظيفة مخطط جدول الوجهة.
- تتحقق الوظيفة من أسماء الأعمدة وأنواعها مقابل مخطط جدول الوجهة.
- تقوم الوظيفة بإعداد جدول بيانات في الذاكرة من سجلات المخرجات في الدفعة.
- تكتب الوظيفة جدول البيانات إلى SQL باستخدام BulkCopy API .
خلال هذه الخطوات، يمكن أن يشهد مخرج SQL الأنواع التالية من الأخطاء:
الأخطاء العابرة التي يعاد تجربتها باستخدام استراتيجية إعادة المحاولة التراجعية الأسية. يعتمد الحد الأدنى من فترة إعادة المحاولة على رمز الخطأ الفردي، لكن الفترات عادة ما تكون أقل من 60 ثانية. يمكن أن يكون الحد الأقصى خمس دقائق على الأكثر.
فشل الدخول و قضايا جدار الحماية يعاد محاكمتها بعد 5 دقائق على الأقل من المحاولة السابقة وتعاد محاكمتها حتى تنجح.
يتم التعامل مع أخطاء البيانات، مثل أخطاء الصب وانتهاكات قيود المخطط، بسياسة خطأ المخرجات. يتم التعامل مع هذه الأخطاء عن طريق إعادة تجربة الدفعات المقسمة الثنائية حتى يتم التعامل مع السجل الفردي الذي يسبب الخطأ عن طريق التخطي أو إعادة المحاولة. الانتهاك الرئيسي لقيد المفتاح الفريد هو يتم التعامل معه دائمًا .
يمكن أن تحدث أخطاء غير عابرة عندما تكون هناك مشكلات في خدمة SQL أو عيوب في الرمز الداخلي. على سبيل المثال، عندما تصل أخطاء مثل (الرمز 1132) Elastic Pool إلى حد التخزين الخاص به، فإن الإعادات لا تحل الخطأ. في هذه السيناريوهات، تجارب وظيفة Stream Analytics التدهور .
BulkCopyيمكن أن تحدث المهلة خلالBulkCopyفي الخطوة 5.BulkCopyيمكن تجربة مهلة التشغيل من حين لآخر. الحد الأدنى للوقت الافتراضي للتكوين هو خمس دقائق ويتم مضاعفته عند الضرب على التوالي. بمجرد أن تتجاوز المهلة 15 دقيقة، يتم تقليل الحد الأقصى لحجم الدفعة إلىBulkCopyالنصف حتى يترك 100 حدث لكل دفعة.هام
بالنسبة لوظائف ASA غير المتصلة بالشبكة، يرجى عدم الاعتماد على عنوان IP المصدر للاتصالات القادمة من ASA بأي شكل من الأشكال. يمكن أن تكون عناوين IP عامة أو خاصة اعتمادا على عمليات البنية الأساسية للخدمة التي تحدث من وقت لآخر.
أسماء الأعمدة صغيرة في Azure Stream Analytics (1.0)
عند استخدام مستوى التوافق الأصلي (1.0)، تقوم Azure Stream Analytics بتغيير أسماء الأعمدة إلى أحرف صغيرة. تم إصلاح هذا السلوك لدى مستويات التوافق اللاحقة. للحفاظ على الحالة، انتقل إلى مستوى التوافق 1.1 أو بعد ذلك. للمزيد من المعلومات، راجع مستوى التوافق لوظائف Stream Analytics.
الحصول على المساعدة
لمزيد من المساعدة، جرب صفحة سؤال Microsoft Q&A الخاصة بنا ل Azure Stream Analytics.