مشاركة عبر

تحسين استعلامات السجل في Azure Monitor

  • مقالة

تستخدم سجلات Azure Monitor Azure Data Explorer لتخزين بيانات السجل وتشغيل الاستعلامات لتحليل تلك البيانات. يقوم بإنشاء مجموعات Azure Data Explorer وإدارتها وصيانتها نيابة عنك، وتحسينها لحمل عمل تحليل السجل الخاص بك. عند تشغيل استعلام، يتم تحسينه وتوجيهه إلى مجموعة Azure Data Explorer المناسبة التي تخزن بيانات مساحة العمل.

تستخدم سجلات Azure Monitor وAzure Data Explorer العديد من آليات تحسين الاستعلام التلقائي. توفر التحسينات التلقائية دفعة كبيرة، ولكن هناك بعض الحالات التي يمكنك فيها تحسين أداء الاستعلام بشكل كبير. تشرح هذه المقالة اعتبارات الأداء والعديد من الأساليب لإصلاحها.

معظم التقنيات شائعة للاستعلامات التي يتم تشغيلها مباشرة على Azure Data Explorer وسجلات Azure Monitor. تتم أيضا مناقشة العديد من اعتبارات سجلات Azure Monitor الفريدة. لمزيد من نصائح تحسين Azure Data Explorer، راجع أفضل ممارسات الاستعلام.

الاستعلامات المحسّنة تعني:

  • تشغيل أسرع وتقليل المدة الإجمالية لتنفيذ الاستعلام.
  • لديك فرصة أقل للاعتماد أو الرفض.

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

فيما يلي مقطع فيديو تفصيلي حول تحسين الاستعلامات.

جزء تفاصيل الاستعلام

بعد تشغيل استعلام في Log Analytics، حدد Query details في الزاوية السفلية اليسرى من الشاشة لفتح جزء Query Details . يعرض هذا الجزء نتائج العديد من مؤشرات الأداء للاستعلام. يتم وصف مؤشرات الأداء هذه في القسم التالي.

لقطة شاشة تعرض جزء تفاصيل الاستعلام في Azure Monitor Log Analytics.

مؤشرات أداء الاستعلام

تتوفر مؤشرات أداء الاستعلام التالية لكل استعلام يتم تنفيذه:

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

إجمالي وحدة المعالجة المركزية

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

يعتبر الاستعلام الذي يستخدم أكثر من 100 ثانية من وحدة المعالجة المركزية استعلاما يستهلك موارد زائدة. يعتبر الاستعلام الذي يستخدم أكثر من 1000 ثانية من وحدة المعالجة المركزية استعلاما مسيئا وقد يتم تقييده.

يتم قضاء وقت معالجة الاستعلام في:

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

بالإضافة إلى الوقت المستغرق في عقد معالجة الاستعلام، تقضي سجلات Azure Monitor الوقت في:

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

لم يتم تضمين هذا الوقت في الاستعلام إجمالي وقت وحدة المعالجة المركزية.

التصفية المبكرة للسجلات قبل استخدام وظائف CPU عالية

بعض أوامر ووظائف الاستعلام ثقيلة في استهلاك وحدة المعالجة المركزية الخاصة بهم. هذه الحالة صحيحة بشكل خاص للأوامر التي تحلل JSON وXML أو تستخرج تعبيرات عادية معقدة. يمكن أن يحدث هذا التحليل بشكل صريح عبر وظائف parse_json() أو parse_xml() أو ضمنيا عندما يشير إلى أعمدة ديناميكية.

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

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

//less efficient
SecurityEvent
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // Problem: irrelevant results are filtered after all processing and parsing is done
| summarize count() by FileHash, FilePath

//more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32"  // exact removal of results. Early filter is not accurate enough
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

تجنب استخدام البنود التي تم تقييمها

الاستعلامات التي تحتوي على where عبارات في عمود تم تقييمه بدلاً من الأعمدة الموجودة فعلياً في مجموعة البيانات تفقد فاعليتها. تمنع التصفية على الأعمدة التي تم تقييمها بعض تحسينات النظام عند معالجة مجموعات كبيرة من البيانات.

على سبيل المثال، تنتج الاستعلامات التالية نفس النتيجة بالضبط. ولكن الثاني أكثر كفاءة لأن الشرط where يشير إلى عمود مضمن:

//less efficient
Syslog
| extend Msg = strcat("Syslog: ",SyslogMessage)
| where  Msg  has "Error"
| count 

//more efficient
Syslog
| where  SyslogMessage  has "Error"
| count

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

//less efficient
SecurityEvent
| where tolower(Process) == "conhost.exe"
| count 

//more efficient
SecurityEvent
| where Process =~ "conhost.exe"
| count

استخدم أوامر التجميع الفعالة والأبعاد في التلخيص والجمع

بعض أوامر التجميع مثل max()وsum ()وcount ()وavg () لها تأثير منخفض على وحدة المعالجة المركزية بسبب منطقها. الأوامر الأخرى أكثر تعقيدا وتتضمن استدلالات وتقديرات تسمح بتنفيذها بكفاءة. على سبيل المثال، يستخدم dcount() خوارزمية HyperLogLog لتوفير تقدير قريب لعدد مميز من مجموعات كبيرة من البيانات دون حساب كل قيمة فعليا.

تقوم الدالات المئوية بتقريبات مماثلة باستخدام أقرب خوارزمية النسبة المئوية للرتبة. تتضمن عديد من الأوامر مَعلمات اختيارية لتقليل تأثيرها. على سبيل المثال، تحتوي الوظيفة makeet() على معلمة اختيارية لتحديد الحد الأقصى لحجم المجموعة، والذي يؤثّر بشكل كبير على وحدة المعالجة المركزية والذاكرة.

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

على سبيل المثال، تنتج الاستعلامات التالية نفس النتيجة تماما لأنه CounterPath دائما ما يتم تعيين واحد إلى واحد إلى CounterName و ObjectName. الثاني أكثر كفاءة لأن بعد التجميع أصغر:

//less efficient
Perf
| summarize avg(CounterValue) 
by CounterName, CounterPath, ObjectName

//make the group expression more compact improve the performance
Perf
| summarize avg(CounterValue), any(CounterName), any(ObjectName) 
by CounterPath

قد يتأثر استهلاك وحدة المعالجة المركزية أيضا بالشروط where أو الأعمدة الموسعة التي تتطلب حوسبة مكثفة. جميع مقارنات السلسلة التافهة، مثل equal == وstartswith، لها نفس تأثير وحدة المعالجة المركزية تقريبا. تؤثر تطابقات النص المتقدمة بشكل أكبر. على وجه التحديد، عامل التشغيل لديه أكثر كفاءة من عامل تشغيل contains . نظرا لتقنيات معالجة السلسلة، من الأكثر كفاءة البحث عن سلاسل أطول من أربعة أحرف من السلاسل القصيرة.

على سبيل المثال، تنتج الاستعلامات التالية نتائج مماثلة، اعتمادا على Computer نهج التسمية. ولكن الثاني أكثر كفاءة:

//less efficient – due to filter based on contains
Heartbeat
| where Computer contains "Production" 
| summarize count() by ComputerIP 

//less efficient – due to filter based on extend
Heartbeat
| extend MyComputer = Computer
| where MyComputer startswith "Production" 
| summarize count() by ComputerIP 

//more efficient
Heartbeat
| where Computer startswith "Production" 
| summarize count() by ComputerIP

إشعار

يعرض هذا المؤشر وحدة المعالجة المركزية فقط من المجموعة المباشرة. في استعلام متعدد المناطق، سيمثل واحدة فقط من المناطق. في استعلام متعدد مساحات العمل، قد لا يتضمن كافة مساحات العمل.

تجنب تحليل XML وJSON الكامل عند عمل تحليل السلسلة

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

على سبيل المثال، يقوم الاستعلام التالي بإرجاع نفس النتائج تماما مثل الاستعلامات السابقة دون إجراء تحليل XML كامل. يقوم الاستعلام ببعض الافتراضات حول بنية ملف XML، مثل FilePath العنصر يأتي بعد FileHash ولا يحتوي أي منها على سمات:

//even more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| summarize count() by FileHash, FilePath
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before

البيانات المستخدمة للاستعلام المعالج

أحد العوامل الهامة في معالجة الاستعلام هو حجم البيانات التي يتم مسحها ضوئيا واستخدامها لمعالجة الاستعلام. يستخدم Azure Data Explorer تحسينات قوية تقلل حجم البيانات بشكل كبير مقارنةً بأنظمة البيانات الأساسية الأخرى. ومع ذلك، هناك عوامل هامة في الاستعلام يمكن أن تؤثر على حجم البيانات المستخدمة.

يعتبر الاستعلام الذي يعالج أكثر من 2000 كيلوبايت من البيانات استعلاما يستهلك موارد زائدة. يعتبر الاستعلام الذي يعالج أكثر من 20000 كيلوبايت من البيانات استعلاما مسيئا وقد يتم تقييده.

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

تجنب الاستخدام غير الضروري لمشغلي البحث والاتحاد

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

على سبيل المثال، تنتج الاستعلامات التالية نفس النتيجة بالضبط، ولكن الاستعلام الأخير هو الأكثر كفاءة:

// This version scans all tables though only Perf has this kind of data
search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer

// This version scans all strings in Perf tables – much more efficient
Perf
| search "Processor Time" 
| summarize count(), avg(CounterValue)  by Computer

// This is the most efficient version 
Perf 
| where CounterName == "% Processor Time"  
| summarize count(), avg(CounterValue)  by Computer

أضف عوامل تصفية مبكرة إلى الاستعلام

هناك طريقة أخرى لتقليل حجم البيانات وهي الحصول على شروط where في وقت مبكر من الاستعلام. يتضمن النظام الأساسي ل Azure Data Explorer ذاكرة تخزين مؤقت تتيح له معرفة الأقسام التي تتضمن البيانات ذات الصلة بشرط معين where . على سبيل المثال، إذا كان الاستعلام يحتوي على where EventID == 4624، فسيوزع الاستعلام فقط على العقد التي تتعامل مع الأقسام مع أحداث مطابقة.

ينتج عن استعلامات المثال التالي نفس النتيجة بالضبط، ولكن الثاني أكثر كفاءة:

//less efficient
SecurityEvent
| summarize LoginSessions = dcount(LogonGuid) by Account

//more efficient
SecurityEvent
| where EventID == 4624 //Logon GUID is relevant only for logon event
| summarize LoginSessions = dcount(LogonGuid) by Account

تجنب عمليات فحص متعددة لنفس بيانات المصدر باستخدام دالات التجميع الشرطي والدالة المجسدة

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

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

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

//Scans the SecurityEvent table twice and perform expensive join
SecurityEvent
| where EventID == 4624 //Login event
| summarize LoginCount = count() by Account
| join 
(
    SecurityEvent
    | where EventID == 4688 //Process execution event
    | summarize ExecutionCount = count(), ExecutedProcesses = make_set(Process) by Account
) on Account

//Scan only once with no join
SecurityEvent
| where EventID == 4624 or EventID == 4688 //early filter
| summarize LoginCount = countif(EventID == 4624), ExecutionCount = countif(EventID == 4688), ExecutedProcesses = make_set_if(Process,EventID == 4688)  by Account

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

//Scan SecurityEvent table twice
union(
SecurityEvent
| where EventID == 8002 
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| distinct FilePath
),(
SecurityEvent
| where EventID == 4799
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" * 
| distinct CallerProcessName1
)

//Single scan of the SecurityEvent table
SecurityEvent
| where EventID == 8002 or EventID == 4799
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" * //Relevant only for event 8002
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" *  //Relevant only for event 4799
| extend FilePath = iif(isempty(CallerProcessName1),FilePath,"")
| distinct FilePath, CallerProcessName1

عندما لا يسمح لك الاستعلام السابق بتجنب استخدام الاستعلامات الفرعية، فإن هناك تقنية أخرى تتمثل في التلميح لمحرك الاستعلام إلى وجود مصدر واحد للبيانات المستخدمة في كل منها باستخدام الدالة materialize(). هذه التقنية مفيدة عندما تأتي البيانات المصدر من دالة تستخدم عدة مرات داخل الاستعلام. Materialize يكون فعالا عندما يكون إخراج الاستعلام الفرعي أصغر بكثير من الإدخال. سيقوم محرك الاستعلام بتخزين المخرجات مؤقتاً وإعادة استخدامها في جميع التكرارات.

تقليل عدد الأعمدة التي تم استردادها

نظرا لأن Azure Data Explorer هو مخزن بيانات عمودي، فإن استرداد كل عمود مستقل عن الأعمدة الأخرى. يؤثّر عدد الأعمدة التي يتم استردادها بشكل مباشر على حجم البيانات الإجمالي. يجب عليك فقط تضمين الأعمدة في المخرجات المطلوبة عن طريق summarizing النتائج أو projecting الأعمدة المحددة.

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

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

//Less columns --> Less data
SecurityEvent
| summarize count() by Computer  

//More columns --> More data
SecurityEvent
| summarize count(), dcount(EventID), avg(Level) by Computer

الفترة الزمنية للاستعلام المعالج

يتم تقسيم جميع السجلات في سجلات Azure Monitor وفقا للعمود TimeGenerated . يرتبط عدد الأقسام التي يتم الوصول إليها ارتباطاً مباشراً بالفترة الزمنية. يعد تقليل النطاق الزمني هو الطريقة الأكثر فاعلية لضمان تنفيذ سريع للاستعلام.

يعتبر استعلام ذو فترة زمنية تزيد عن 15 يوما استعلاما يستهلك موارد زائدة. يعتبر الاستعلام الذي يزيد نطاقه الزمني عن 90 يوما استعلاما مسيئا وقد يتم تقييده.

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

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

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

تأكد من أن جميع الاستعلامات الفرعية تحتوي على عامل تصفية TimeGenerated

على سبيل المثال، في الاستعلام التالي، Perf سيتم مسح الجدول ضوئيا فقط لليوم الأخير. Heartbeat سيتم مسح الجدول ضوئيا لجميع محفوظاته، والتي قد تصل إلى عامين:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize IPs = makeset(ComputerIP, 10) by  Computer
) on Computer

من الحالات الشائعة التي يحدث فيها مثل هذا الخطأ عندما يتم استخدام arg_max() للعثور على أحدث تكرارات. على سبيل المثال:

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    //No time span filter in this part of the query
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

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

Perf
| where TimeGenerated > ago(1d)
| summarize avg(CounterValue) by Computer, CounterName
| join kind=leftouter (
    Heartbeat
    | where TimeGenerated > ago(1d) //filter for this part
    | summarize arg_max(TimeGenerated, *), min(TimeGenerated)   
by Computer
) on Computer

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

على سبيل المثال، سيقوم الاستعلام التالي بفحص جميع البيانات في Heartbeat Perf والجداول، وليس فقط في اليوم الأخير:

Heartbeat 
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | summarize arg_min(TimeGenerated,*) by Computer) 
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated) by Computer

لإصلاح الاستعلام:

let MinTime = ago(1d);
Heartbeat 
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer
| union (
    Perf 
    | where TimeGenerated > MinTime
    | summarize arg_min(TimeGenerated,*) by Computer) 
| summarize min(TimeGenerated) by Computer

حدود قياس الفترة الزمنية

يكون القياس دائماً أكبر من الوقت الفعلي المحدد. على سبيل المثال، إذا كان عامل التصفية في الاستعلام 7 أيام، فقد يقوم النظام بفحص 7.5 أو 8.1 أيام. ويرجع هذا التباين إلى أن النظام يقسم البيانات إلى مجموعات من أحجام المتغيرات. للتأكد من مسح جميع السجلات ذات الصلة ضوئيا، يقوم النظام بفحص القسم بأكمله. قد تغطي هذه العملية عدة ساعات وحتى أكثر من يوم.

هناك عديد من الحالات التي لا يستطيع فيها النظام توفير قياس دقيق للنطاق الزمني. يحدث هذا الموقف في معظم الحالات التي يكون فيها نطاق الاستعلام أقل من يوم أو في استعلامات متعددة مساحات العمل.

هام

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

عمر البيانات المعالجة

يستخدم Azure Data Explorer العديد من طبقات التخزين: في الذاكرة وأقراص SSD المحلية والكائنات الثنائية كبيرة الحجم ل Azure الأبطأ بكثير. كلما كانت البيانات الأحدث، زادت فرصة تخزينها في مستوى أكثر أداء مع زمن انتقال أصغر، ما يقلل من مدة الاستعلام وCPU. بخلاف البيانات نفسها، يحتوي النظام أيضاً على ذاكرة تخزين مؤقت للبيانات الوصفية. كلما كانت البيانات أقدم، قل احتمال وجود بيانات التعريف الخاصة بها في ذاكرة التخزين المؤقت.

يعتبر الاستعلام الذي يعالج البيانات التي يزيد عمرها عن 14 يوماً استعلاماً يستهلك موارد زائدة.

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

يمكن أن تكون مثل هذه الحالات، على سبيل المثال:

  • عدم تعيين النطاق الزمني في Log Analytics باستعلام فرعي غير محدود. راجع المثال السابق.
  • استخدام API دون النطاق الزمني المعلمات الاختيارية.
  • استخدام عميل لا يفرض نطاقا زمنيا، على سبيل المثال، مثل موصل Power BI.

راجع الأمثلة والملاحظات في القسم السابق لأنها ذات صلة أيضا في هذه الحالة.

عدد المناطق

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

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

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

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

يعتبر الاستعلام الذي يمتد عبر أكثر من ثلاث مناطق استعلاما يستهلك موارد زائدة. يعتبر الاستعلام الذي يمتد عبر أكثر من ست مناطق استعلاما مسيئا وقد يتم تقييده.

هام

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

عدد مساحات العمل

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

يمكن أن ينتج استخدام مساحات عمل متعددة من مثيلات عندما:

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

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

يعتبر الاستعلام الذي يمتد عبر أكثر من خمس مساحات عمل استعلاما يستهلك موارد زائدة. لا يمكن أن تمتد الاستعلامات لأكثر من 100 مساحة عمل.

هام

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

تماثل

تستخدم سجلات Azure Monitor مجموعات كبيرة من Azure Data Explorer لتشغيل الاستعلامات. تختلف هذه المجموعات من حيث الحجم ومن المحتمل أن تحصل على ما يصل إلى عشرات عقد الحوسبة. يقوم النظام تلقائياً بقياس المجموعات وفقاً لمنطق وسعة وضع مساحة العمل.

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

تشمل سلوكيات الاستعلام التي يمكن أن تقلل من التوازي ما يلي:

  • استخدام دالات التسلسل والنافذة، مثل عامل تشغيل التسلسل، next()، prev()، ووظائف الصف . يمكن استخدام وظائف السلاسل الزمنية وتحليلات المستخدم في بعض هذه الحالات. قد يحدث التسلسل غير الفعال أيضا إذا لم يتم استخدام عوامل التشغيل التالية في نهاية الاستعلام: النطاق والفرز والنظام والأعلى والأعلى وsschema.
  • استخدام دالة التجميع dcount() يفرض على النظام أن يكون لديه نسخة مركزية من القيم المميزة. عندما يكون مقياس البيانات مرتفعا، ضع في اعتبارك استخدام المعلمات الاختيارية dcount للوظيفة لتقليل الدقة.
  • في كثير من الحالات، يقلل عامل التشغيل Join من التوازي الكلي. افحص shuffle join كبديل عندما يكون الأداء مشكلة.
  • في استعلامات نطاق الموارد، قد يتعطل التحكم في الوصول المستند إلى الدور (RBAC) في Kubernetes قبل التنفيذ أو عمليات التحقق من Azure RBAC في الحالات التي يوجد فيها عدد كبير من تعيينات دور Azure. قد يؤدي هذا الموقف إلى عمليات تحقق أطول من شأنها أن تؤدي إلى انخفاض التوازي. على سبيل المثال، قد يتم تنفيذ استعلام على اشتراك حيث توجد الآلاف من الموارد ولكل مورد العديد من تعيينات الأدوار على مستوى المورد، وليس على الاشتراك أو مجموعة الموارد.
  • إذا كان الاستعلام يعالج أجزاء صغيرة من البيانات، فسيكون توازيه منخفضا لأن النظام لن ينشره عبر العديد من عقد الحوسبة.

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

الوثائق المرجعية للغة استعلام Kusto