تحسين المرونة من خلال نسخ مساحة عمل Log Analytics عبر المناطق (معاينة)

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

فيما يلي فيديو يوفر نظرة عامة سريعة حول كيفية عمل النسخ المتماثل لمساحة عمل Log Analytics:

هام

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

الأذونات المطلوبة

الإجراء الأذونات المطلوبة
تمكين النسخ المتماثل لمساحة العمل Microsoft.OperationalInsights/workspaces/write والأذونات Microsoft.Insights/dataCollectionEndpoints/write ، كما هو منصوص عليه في الدور المضمن لمساهم المراقبة، على سبيل المثال
التبديل والعودة (تجاوز فشل المشغل وإرجاع الموارد) Microsoft.OperationalInsights/locations/workspaces/failoverو Microsoft.OperationalInsights/workspaces/failbackو والأذونات Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action ، كما هو منصوص عليه في الدور المضمن لمساهم المراقبة، على سبيل المثال
التحقق من حالة مساحة العمل Microsoft.OperationalInsights/workspaces/read أذونات إلى مساحة عمل Log Analytics، كما هو منصوص عليه في دور مساهم المراقبة المضمن، على سبيل المثال

كيفية عمل النسخ المتماثل لمساحة عمل Log Analytics

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

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

مساحة العمل الثانوية هي مساحة عمل "ظل" لأغراض المرونة فقط. لا يمكنك رؤية مساحة العمل الثانوية في مدخل Microsoft Azure، ولا يمكنك إدارتها أو الوصول إليها مباشرة.

عند تمكين النسخ المتماثل لمساحة العمل، يرسل Azure Monitor سجلات جديدة تم استيعابها إلى مساحة العمل الأساسية إلى منطقتك الثانوية أيضا. لا يتم نسخ السجلات التي يتم استيعابها إلى مساحة العمل قبل تمكين النسخ المتماثل لمساحة العمل.

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

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

هام

بعد التبديل إلى المنطقة الثانوية، إذا لم تتمكن المنطقة الأساسية من معالجة بيانات السجل الواردة، يقوم Azure Monitor بالتخزين المؤقت للبيانات في المنطقة الثانوية لمدة تصل إلى 11 يوما. خلال الأيام الأربعة الأولى، يعيد Azure Monitor تلقائيا محاولة نسخ البيانات نسخا متماثلا بشكل دوري.

رسم تخطيطي يوضح تدفقات الاستيعاب أثناء الوضع العادي وأوضاع التبديل.

المناطق المدعومة

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

مجموعات المناطق والمناطق هذه مدعومة حاليا:

مجموعة المنطقة المناطق ملاحظات
أمريكا الشمالية شرق الولايات المتحدة النسخ المتماثل غير مدعوم من منطقة شرق الولايات المتحدة 2 أو منها.
East US 2 النسخ المتماثل غير مدعوم من منطقة شرق الولايات المتحدة أو منها.
غرب الولايات المتحدة
West US 2
Central US
South Central US
وسط كندا
‏‏أوروبا أوروبا الغربية
أوروبا الشمالية
جنوب المملكة المتحدة
غرب المملكة المتحدة
وسط غرب ألمانيا
وسط فرنسا

متطلبات موقع البيانات

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

دعم Sentinel والخدمات الأخرى

تتوافق الخدمات والميزات المختلفة التي تستخدم مساحات عمل Log Analytics مع النسخ المتماثل لمساحة العمل والتبديل. تستمر هذه الخدمات والميزات في العمل عند التبديل إلى مساحة العمل الثانوية.

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

بعض تجارب Azure Monitor، بما في ذلك Application Insights وVM Insights، متوافقة حاليا جزئيا فقط مع النسخ المتماثل لمساحة العمل والتبديل. للحصول على القائمة الكاملة، راجع القيود والقيود.

تمكين وتعطيل النسخ المتماثل لمساحة العمل

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

هام

النسخ المتماثل لمساحات عمل Log Analytics المرتبطة بمجموعة مخصصة غير مدعوم حاليا.

تمكين النسخ المتماثل لمساحة العمل

لتمكين النسخ المتماثل على مساحة عمل Log Analytics، استخدم هذا PUT الأمر:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

المكان:

  • <subscription_id>: معرف الاشتراك المتعلق بمساحة العمل الخاصة بك.
  • <resourcegroup_name> : مجموعة الموارد التي تحتوي على مورد مساحة عمل Log Analytics.
  • <workspace_name>: اسم مساحة العمل الخاصة بك.
  • <primary_region>: المنطقة الأساسية لمساحة عمل Log Analytics.
  • <secondary_region>: المنطقة التي ينشئ فيها Azure Monitor مساحة العمل الثانوية.

للحصول على القيم المدعومة location ، راجع المناطق المدعومة.

PUT الأمر عبارة عن عملية طويلة الأمد قد تستغرق بعض الوقت لإكمالها. ترجع المكالمة الناجحة 200 رمز الحالة. يمكنك تعقب حالة التوفير لطلبك، كما هو موضح في حالة التحقق من توفير الطلب.

التحقق من حالة توفير الطلب

للتحقق من حالة التوفير لطلبك، قم بتشغيل هذا GET الأمر:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

المكان:

  • <subscription_id>: معرف الاشتراك المتعلق بمساحة العمل الخاصة بك.
  • <resourcegroup_name>: مجموعة الموارد التي تحتوي على مورد مساحة عمل Log Analytics.
  • <workspace_name>: اسم مساحة عمل Log Analytics.

GET استخدم الأمر للتحقق من أن حالة توفير مساحة العمل تتغير من Updating إلى Succeeded، ويتم تعيين المنطقة الثانوية كما هو متوقع.

إشعار

عند تمكين النسخ المتماثل لمساحات العمل التي تتفاعل مع Sentinel، قد يستغرق النسخ المتماثل الكامل لبيانات Watchlist و Threat Intelligence إلى مساحة العمل الثانوية ما يصل إلى 12 يوما.

إقران قواعد جمع البيانات بنقطة نهاية تجميع بيانات النظام

يمكنك استخدام قواعد جمع البيانات (DCR) لجمع بيانات السجل باستخدام عامل Azure Monitor وواجهة برمجة تطبيقات استيعاب السجلات.

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

لنسخ البيانات التي تجمعها باستخدام قواعد جمع البيانات، قم بربط قواعد جمع البيانات بنقطة نهاية تجميع بيانات النظام لمساحة عمل Log Analytics:

  1. في مدخل Microsoft Azure، حدد قواعد جمع البيانات.

  2. من شاشة قواعد تجميع البيانات، حدد قاعدة تجميع البيانات التي ترسل البيانات إلى مساحة عمل Log Analytics الأساسية.

  3. في صفحة نظرة عامة على قاعدة جمع البيانات، حدد تكوين DCE وحدد نقطة نهاية تجميع بيانات النظام من القائمة المتوفرة:

    لقطة شاشة توضح كيفية تكوين نقطة نهاية تجميع بيانات لقاعدة تجميع بيانات موجودة في مدخل Microsoft Azure. للحصول على تفاصيل حول System DCE، تحقق من خصائص كائن مساحة العمل.

هام

يمكن لقواعد تجميع البيانات المتصلة بنقطة نهاية تجميع بيانات النظام لمساحة العمل استهداف مساحة العمل المحددة فقط. يجب ألا تستهدف قواعد جمع البيانات وجهات أخرى، مثل مساحات العمل الأخرى أو حسابات Azure Storage.

تعطيل النسخ المتماثل لمساحة العمل

لتعطيل النسخ المتماثل لمساحة عمل، استخدم هذا PUT الأمر:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

المكان:

  • <subscription_id>: معرف الاشتراك المتعلق بمساحة العمل الخاصة بك.
  • <resourcegroup_name> : مجموعة الموارد التي تحتوي على مورد مساحة العمل.
  • <workspace_name>: اسم مساحة العمل الخاصة بك.
  • <primary_region>: المنطقة الأساسية لمساحة العمل الخاصة بك.

PUT الأمر عبارة عن عملية طويلة الأمد قد تستغرق بعض الوقت لإكمالها. ترجع المكالمة الناجحة 200 رمز الحالة. يمكنك تعقب حالة التوفير لطلبك، كما هو موضح في حالة التحقق من توفير الطلب.

مراقبة مساحة العمل وصحة الخدمة

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

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

إشعار

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

التبديل إلى مساحة العمل الثانوية

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

متى يجب التبديل؟

يمكنك تحديد وقت التبديل إلى مساحة العمل الثانوية والعودة إلى مساحة العمل الأساسية استنادا إلى الأداء المستمر والمراقبة الصحية ومعايير النظام ومتطلباته.

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

نوع المشكلة ونطاقها

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

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

مدة المشكلة

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

  • الاستيعاب: يمكن أن تؤثر المشكلات المتعلقة بمسار الاستيعاب في منطقتك الأساسية على النسخ المتماثل للبيانات إلى مساحة العمل الثانوية. أثناء التبديل، يتم إرسال السجلات بدلا من ذلك إلى البنية الأساسية لبرنامج ربط العمليات التجارية للاستيعاب في المنطقة الثانوية.

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

بيانات مساحة العمل الثانوية

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

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

تبديل المشغل

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

للتبديل إلى مساحة العمل الثانوية، استخدم هذا POST الأمر:

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2023-01-01-preview

المكان:

  • <subscription_id>: معرف الاشتراك المتعلق بمساحة العمل الخاصة بك.
  • <resourcegroup_name> : مجموعة الموارد التي تحتوي على مورد مساحة العمل.
  • <secondary_region>: المنطقة المراد التبديل إليها أثناء التبديل.
  • <workspace_name>: اسم مساحة العمل للتبديل إليها أثناء التبديل.

POST الأمر عبارة عن عملية طويلة الأمد قد تستغرق بعض الوقت لإكمالها. ترجع المكالمة الناجحة 202 رمز الحالة. يمكنك تعقب حالة التوفير لطلبك، كما هو موضح في حالة التحقق من توفير الطلب.

التبديل مرة أخرى إلى مساحة العمل الأساسية

تقوم عملية التبديل بإلغاء إعادة توجيه الاستعلامات وتسجيل طلبات الاستيعاب إلى مساحة العمل الثانوية. عند التبديل مرة أخرى، يعود Azure Monitor إلى استعلامات التوجيه وتسجيل طلبات الاستيعاب إلى مساحة العمل الأساسية.

عند التبديل إلى منطقتك الثانوية، يقوم Azure Monitor بنسخ السجلات من مساحة العمل الثانوية إلى مساحة العمل الأساسية. إذا كان الانقطاع يؤثر على عملية استيعاب السجل في المنطقة الأساسية، فقد يستغرق الأمر وقتا حتى يكمل Azure Monitor استيعاب السجلات المنسوخة نسخا متماثلا إلى مساحة العمل الأساسية.

متى يجب أن أرجع؟

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

حالة النسخ المتماثل للسجل

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

يمكنك الاستعلام عن مساحة العمل الأساسية في مدخل Microsoft Azure للمنطقة غير النشطة، كما هو موضح في تدقيق مساحة العمل غير النشطة.

صحة مساحة العمل الأساسية

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

  • تأكد من عدم وجود إعلامات حالة الخدمة المعلقة لمساحة العمل والمنطقة الأساسية.
  • تأكد من أن مساحة العمل الأساسية الخاصة بك تقوم ب استيعاب السجلات ومعالجة الاستعلامات كما هو متوقع.

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

تشغيل إعادة التشغيل

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

تقوم عملية التبديل بتحديث سجلات DNS. بعد تحديث سجلات DNS، قد يستغرق تلقي جميع العملاء إعدادات DNS المحدثة واستئناف التوجيه إلى مساحة العمل الأساسية وقتا.

للعودة إلى مساحة العمل الأساسية، استخدم هذا POST الأمر:

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2023-01-01-preview

المكان:

  • <subscription_id>: معرف الاشتراك المتعلق بمساحة العمل الخاصة بك.
  • <resourcegroup_name> : مجموعة الموارد التي تحتوي على مورد مساحة العمل.
  • <workspace_name>: اسم مساحة العمل للتبديل إليها أثناء التبديل.

POST الأمر عبارة عن عملية طويلة الأمد قد تستغرق بعض الوقت لإكمالها. ترجع المكالمة الناجحة 202 رمز الحالة. يمكنك تعقب حالة التوفير لطلبك، كما هو موضح في حالة التحقق من توفير الطلب.

تدقيق مساحة العمل غير النشطة

بشكل افتراضي، المنطقة النشطة لمساحة العمل هي المنطقة التي تقوم فيها بإنشاء مساحة العمل، والمنطقة غير النشطة هي المنطقة الثانوية، حيث يقوم Azure Monitor بإنشاء مساحة العمل المنسوخة نسخا متماثلا.

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

من المفيد الاستعلام عن المنطقة غير النشطة قبل التبديل بين المناطق للتحقق من أن مساحة العمل في المنطقة غير النشطة تحتوي على السجلات التي تتوقع رؤيتها هناك.

منطقة الاستعلام غير النشطة

للاستعلام عن بيانات السجل في المنطقة غير النشطة، استخدم أمر GET هذا:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

على سبيل المثال، لتشغيل استعلام بسيط مثل Perf | count اليوم الماضي في منطقتك الثانوية، استخدم:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

يمكنك التأكد من تشغيل Azure Monitor للاستعلام في المنطقة المقصودة عن طريق التحقق من هذه الحقول في LAQueryLogs الجدول، والذي يتم إنشاؤه عند تمكين تدقيق الاستعلام في مساحة عمل Log Analytics:

  • isWorkspaceInFailover: يشير إلى ما إذا كانت مساحة العمل في وضع التبديل أثناء الاستعلام. نوع البيانات منطقي (صواب، خطأ).
  • workspaceRegion: منطقة مساحة العمل المستهدفة بواسطة الاستعلام. نوع البيانات هو String.

مراقبة أداء مساحة العمل باستخدام الاستعلامات

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

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

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

مراقبة زمن انتقال الاستيعاب من طرف إلى طرف

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

  • زمن انتقال العامل: الوقت المطلوب من قبل العامل للإبلاغ عن حدث.
  • زمن انتقال مسار الاستيعاب (الخلفية): الوقت المطلوب لمسار الاستيعاب لمعالجة السجلات وكتابتها في مساحة العمل الخاصة بك.

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

توضح الأقسام التالية كيفية استخدام الاستعلامات للتحقق من زمن انتقال الاستيعاب لمساحة العمل الخاصة بك.

تقييم زمن انتقال الاستيعاب الأساسي لجداول معينة

ابدأ بتحديد زمن الانتقال الأساسي لجداول معينة على مدى عدة أيام.

ينشئ هذا الاستعلام المثال مخططا للنسبة المئوية 90 لزمن انتقال الاستيعاب في جدول Perf:

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

بعد تشغيل الاستعلام، راجع النتائج والمخطط المعروض لتحديد زمن الانتقال المتوقع لهذا الجدول.

المراقبة والتنبيه بشأن زمن انتقال الاستيعاب الحالي

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

يحسب هذا الاستعلام زمن انتقال الاستيعاب خلال الدقائق العشرين الماضية:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

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

تحديد مصدر زمن انتقال الاستيعاب

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

يرسم هذا الاستعلام مخططا لزمن الانتقال المئوية 90 للعوامل والمسار، بشكل منفصل:

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
	  PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

إشعار

على الرغم من أن المخطط يعرض بيانات النسبة المئوية 90 كأعمدة مكدسة، فإن مجموع البيانات في المخططين لا يساوي إجمالي القيمة المئوية للعرض 90.

مراقبة حجم الاستيعاب

يمكن أن تساعد قياسات حجم الاستيعاب في تحديد التغييرات غير المتوقعة في وحدة التخزين الإجمالية أو الخاصة بالجدول لمساحة العمل الخاصة بك. يمكن أن تساعدك قياسات حجم الاستعلام في تحديد مشكلات الأداء مع استيعاب السجل. تتضمن بعض قياسات الحجم المفيدة ما يلي:

  • إجمالي حجم الاستيعاب لكل جدول
  • حجم الاستيعاب المستمر (توقف)
  • حالات الاستيعاب الشاذة - الارتفاعات والانخفاضات في حجم الاستيعاب

توضح الأقسام التالية كيفية استخدام الاستعلامات للتحقق من وحدة تخزين الاستيعاب لمساحة العمل الخاصة بك.

مراقبة إجمالي حجم الاستيعاب لكل جدول

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

يحسب هذا الاستعلام إجمالي حجم الاستيعاب خلال الساعة الماضية لكل جدول بالميغابايت في الثانية (MBs):

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

التحقق من توقف الاستيعاب

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

يتحقق الاستعلام التالي من رسالة كشف أخطاء اتصال العامل للكشف عن مشكلات الاتصال:

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

مراقبة الحالات الشاذة في الاستيعاب

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

تحديد الحالات الشاذة باستخدام series_decompose_anomalies

series_decompose_anomalies() تحدد الدالة الحالات الشاذة في سلسلة من قيم البيانات. يحسب هذا الاستعلام حجم الاستيعاب بالساعة لكل جدول في مساحة عمل Log Analytics، ويستخدم series_decompose_anomalies() لتحديد الحالات الشاذة:

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

لمزيد من المعلومات حول كيفية استخدام series_decompose_anomalies() للكشف عن الحالات الشاذة في بيانات السجل، راجع الكشف عن الحالات الشاذة وتحليلها باستخدام قدرات التعلم الآلي من KQL في Azure Monitor.

إنشاء كاشف الشذوذ الخاص بك

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

يحسب الاستعلام التالي:

  • حجم الاستيعاب المتوقع: لكل ساعة، حسب الجدول (استنادا إلى وسيط الوسيطات، ولكن يمكنك تخصيص المنطق)
  • حجم الاستيعاب الفعلي: لكل ساعة، حسب الجدول

لتصفية الاختلافات غير البسيطة بين وحدة التخزين المتوقعة وحجم الاستيعاب الفعلي، يطبق الاستعلام عاملي تصفية:

  • معدل التغيير: أكثر من 150٪ أو أقل من 66٪ من الحجم المتوقع، لكل جدول
  • حجم التغيير: يشير إلى ما إذا كان حجم الزيادة أو النقصان أكثر من 0.1٪ من الحجم الشهري لهذا الجدول
// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

مراقبة نجاح الاستعلام وفشله

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

يحسب هذا الاستعلام عدد الاستعلامات التي أرجعت رمز خطأ خادم:

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

القيود والمحددات

  • النسخ المتماثل لمساحات عمل Log Analytics المرتبطة بمجموعة مخصصة غير مدعوم حاليا.

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

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

  • عند تمكين النسخ المتماثل لمساحات العمل التي تتفاعل مع Sentinel، قد يستغرق النسخ المتماثل الكامل لبيانات Watchlist و Threat Intelligence إلى مساحة العمل الثانوية ما يصل إلى 12 يوما.

  • أثناء التبديل، لا يتم دعم عمليات إدارة مساحة العمل، بما في ذلك:

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

  • تقوم عملية تجاوز الفشل بتحديث سجلات نظام أسماء المجالات (DNS) لإعادة توجيه جميع طلبات الاستيعاب إلى منطقتك الثانوية للمعالجة. لدى بعض عملاء HTTP "اتصالات ملصقة" وقد يستغرق الأمر وقتا أطول لالتقاط DNS المحدث DNS. أثناء التبديل، قد يحاول هؤلاء العملاء استيعاب السجلات من خلال المنطقة الأساسية لبعض الوقت. قد تقوم ب استيعاب السجلات إلى مساحة العمل الأساسية باستخدام عملاء مختلفين، بما في ذلك عامل Log Analytics القديم، وعامل Azure Monitor، والرمز (باستخدام واجهة برمجة تطبيقات استيعاب السجلات أو واجهة برمجة تطبيقات مجموعة بيانات HTTP القديمة)، والخدمات الأخرى، مثل Sentinel.

  • هذه الميزات غير مدعومة حاليا أو معتمدة جزئيا فقط:

    ميزة يدعم
    خطط الجدول الإضافية ‏‏غير مدعومة. لا يقوم Azure Monitor بنسخ البيانات نسخا متماثلا في الجداول باستخدام خطة السجل المساعدة إلى مساحة العمل الثانوية. لذلك، هذه البيانات غير محمية من فقدان البيانات في حالة حدوث فشل إقليمي ولا تتوفر عند التبديل إلى مساحة العمل الثانوية.
    البحث في المهام، الاستعادة مدعوم جزئيا - تقوم عمليات البحث عن المهام والاستعادة بإنشاء جداول وملئها بنتائج البحث أو البيانات المستعادة. بعد تمكين النسخ المتماثل لمساحة العمل، يتم نسخ الجداول الجديدة التي تم إنشاؤها لهذه العمليات إلى مساحة العمل الثانوية. لا يتم نسخ الجداول التي تم ملؤها قبل تمكين النسخ المتماثل. إذا كانت هذه العمليات قيد التقدم عند التبديل، تكون النتيجة غير متوقعة. قد يكتمل بنجاح ولكن لا يتم نسخه نسخا متماثلا، أو قد يفشل، اعتمادا على صحة مساحة العمل والتوقيت الدقيق.
    Application Insights عبر مساحات عمل Log Analytics غير مدعوم
    تفاصيل الأجهزة الظاهرية (VM) غير مدعوم
    نتائج تحليلات الحاوية غير مدعوم
    ارتباطات خاصة غير مدعوم أثناء تجاوز الفشل