وقت تحويل بيانات السجل في مراقب Azure

Azure Monitor هي خدمة بيانات واسعة النطاق تخدم الآلاف من العملاء الذين يرسلون تيرابايت من البيانات كل شهر بوتيرة متزايدة. وغالبًا ما تتوارد أسئلة حول الوقت الذي يستغرقه توفر بيانات السجل بعد جمعها. وتفسر هذه المقالة العوامل المختلفة التي تؤثر في زمن الانتقال هذا.

زمن الانتقال الوسطي

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

العوامل التي تؤثر في زمن الانتقال

يمكن تقسيم إجمالي وقت الاستيعاب لمجموعة معينة من البيانات إلى المناطق عالية المستوى التالية:

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

يتم وصف تفاصيل زمن الانتقال المختلف المقدم في هذه العملية في الأقسام التالية.

زمن انتقال مجموعة العامل

يختلف الوقت

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

نوع البيانات	تكرار عملية الجمع	ملاحظات
أحداث Windows وأحداث Syslog ومقاييس الأداء	يتم جمعها على الفور
عدادات أداء Linux	تم الاستقصاء في فواصل زمنية مدتها 30 ثانية
سجلات IIS وسجلات النص	تم جمعها بعد تغييرات الطابع الزمني	بالنسبة لسجلات IIS، يتأثر هذا الجدول بجدول التمرير الذي تم تكوينه على IIS.
حل النسخ المتماثل لـ Active Directory	تقييم كل خمسة أيام	يجمع العامل السجلات فقط عند اكتمال التقييم.
حل تقييم Active Directory	تقييم أسبوعي للبنية الأساسية ل Active Directory	يجمع العامل السجلات فقط عند اكتمال التقييم.

تردد عامل التحميل

أقل من دقيقة واحدة

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

الشبكة

يختلف

قد تؤثر شروط الشبكة سلبا على زمن انتقال هذه البيانات للوصول إلى نقطة نهاية تجميع البيانات.

مقاييس Azure وسجلات الموارد وسجل النشاط

من 30 ثانية إلى 15 دقيقة

تضيف بيانات Azure مزيدا من الوقت لتصبح متاحة في نقطة نهاية تجميع البيانات للمعالجة:

• تتوفر مقاييس النظام الأساسي ل Azure في أقل من دقيقة في قاعدة بيانات المقاييس، ولكنها تستغرق 3 دقائق أخرى لتصديرها إلى نقطة نهاية جمع البيانات.
• تضيف سجلات الموارد عادة من 30 إلى 90 ثانية، اعتمادا على خدمة Azure. تقوم بعض خدمات Azure (على وجه التحديد، قاعدة بيانات Azure SQL وشبكة Azure الظاهرية) بالإبلاغ عن سجلاتها في فواصل زمنية مدتها 5 دقائق. والعمل جار لتحسين هذه المرة بشكل أكبر. لفحص زمن الانتقال هذا في البيئة الخاصة بك، راجع الاستعلام التالي.
• تتوفر سجلات النشاط للتحليل في 3 إلى 10 دقائق.

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

يختلف

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

• يستقصي حل Microsoft 365 سجلات النشاط باستخدام واجهة برمجة تطبيقات نشاط الإدارة، والتي لا توفر حاليا أي ضمانات زمن انتقال في الوقت الفعلي تقريبا.
• يتم جمع بيانات حلول Windows Analytics (تحديث التوافق، على سبيل المثال) بواسطة الحل بمعدل تكرار يومي.

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

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

من 30 إلى 60 ثانية

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

بعد استيعاب سجلات السجل في البنية الأساسية لبرنامج ربط العمليات التجارية Azure Monitor (كما هو محدد في خاصية _TimeReceived )، تتم كتابتها إلى التخزين المؤقت لضمان عزل المستأجر والتأكد من عدم فقدان البيانات. تضيف هذه العملية عادة من 5 إلى 15 ثانية.

تنفذ بعض الحلول خوارزميات أثقل لتجميع البيانات واشتقاق الرؤى أثناء تدفق البيانات. على سبيل المثال، يحسب Application Insights بيانات خريطة التطبيق؛ تجمع Azure Network Performance Monitoring البيانات الواردة على فترات زمنية مدتها 3 دقائق، ما يضيف زمن انتقال لمدة 3 دقائق بشكل فعال.

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

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

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

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

الحماية من الاندفاع

عادة أقل من دقيقة واحدة، ولكن يمكن أن يكون أكثر

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

وقت الفهرس

5 دقائق أو أقل

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

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

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

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

الخطوة	الخاصية أو الدالة	التعليقات
السجل الذي تم إنشاؤه في مصدر البيانات	TimeGenerated إذا لم يقم مصدر البيانات بتعيين هذه القيمة، فسيتم تعيينها إلى نفس وقت _TimeReceived.	إذا كانت القيمة Time Generated أقدم من يومين في وقت المعالجة، فسيتم إسقاط الصف.
السجل الذي تم تلقيه بواسطة نقطة نهاية جمع البيانات	_TimeReceived	هذا الحقل غير محسن للمعالجة الجماعية ولا يجب استخدامه لتصفية مجموعات البيانات الكبيرة.
سجل مخزن في مساحة العمل ومتاح للاستعلامات	ingestion_time()	نوصي باستخدام ingestion_time() إذا كانت هناك حاجة لتصفية السجلات التي تم تناولها في نافذة زمنية معينة فقط. في مثل هذه الحالات، نوصي أيضا بإضافة TimeGenerated عامل تصفية مع نطاق أكبر.

تأخر زمن انتقال التحويل

يمكنك قياس زمن انتقال سجل معين عن طريق مقارنة نتيجة الدالة ingestion_time() بالخاصية TimeGenerated . يمكن استخدام هذه البيانات مع تجميعات مختلفة لاكتشاف كيفية تصرف زمن انتقال الاستيعاب. افحص بعض النسب المئوية لوقت الاستيعاب للحصول على رؤى لكميات كبيرة من البيانات.

على سبيل المثال، سيظهر لك الاستعلام التالي أجهزة الكمبيوتر التي كان لها أعلى وقت تحويل في خلال الساعات الـ8 السابقة:

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

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

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

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

استخدم الاستعلام التالي لإظهار وقت استيعاب الكمبيوتر حسب البلد/المنطقة التي يوجد بها، والذي يستند إلى عنوان IP الخاص بهم:

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry 

قد يكون لأنواع البيانات المختلفة التي تنشأ من العامل زمن انتقال مختلف، لذلك يمكن استخدام الاستعلامات السابقة مع أنواع أخرى. استخدم الاستعلام التالي لفحص وقت تحويل خدمات Azure المتنوعة:

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

استخدم نفس منطق الاستعلام لتشخيص شروط زمن الانتقال لبيانات Application Insights:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

يمكن إقران الاستعلامين أعلاه بأي جدول Application Insights آخر غير "الطلبات".

الموارد التي تتوقف عن الاستجابة

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

Heartbeat استخدم الجدول للتحقق من توفر جهاز ظاهري لأنه يتم إرسال رسالة كشف أخطاء الاتصال مرة واحدة في الدقيقة من قبل العامل. واستخدم الاستعلامات التالية لوضع قائمة بأجهزة الكمبيوتر النشطة التي لم ترسل تقريرًا برسالة كشف أخطاء الاتصال مؤخرًا:

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc 

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

اقرأ اتفاقية مستوى الخدمة ل Azure Monitor.