مراقبة Azure Front Door
يجمع Azure Monitor المقاييس والسجلات من نظامك ويجمعها لمراقبة التوفر والأداء والمرونة، ويخطرك بالمشكلات التي تؤثر على نظامك. يمكنك استخدام مدخل Microsoft Azure أو PowerShell أو Azure CLI أو REST API أو مكتبات العميل لإعداد بيانات المراقبة وعرضها.
تتوفر مقاييس وسجلات مختلفة أنواع موارد مختلفة. توضح هذه المقالة أنواع بيانات المراقبة التي يمكنك جمعها لهذه الخدمة وطرق تحليل تلك البيانات.
توفر التقارير نظرة ثاقبة حول كيفية تدفق نسبة استخدام الشبكة عبر Azure Front Door وجدار حماية تطبيق الويب (WAF) وإلى تطبيقك.
هام
سيتم إيقاف Azure Front Door (الكلاسيكي) في 31 مارس 2027. لتجنب أي تعطيل للخدمة، من المهم ترحيل ملفات تعريف Azure Front Door (الكلاسيكية) إلى مستوى Azure Front Door Standard أو Premium بحلول مارس 2027. لمزيد من المعلومات، راجع إيقاف Azure Front Door (الكلاسيكي).
جمع البيانات باستخدام Azure Monitor
يصف هذا الجدول كيف يمكنك جمع البيانات لمراقبة خدمتك، وما يمكنك فعله بالبيانات بمجرد جمعها:
| البيانات المراد جمعها | الوصف | كيفية جمع البيانات وتوجيهها | مكان عرض البيانات | البيانات المعتمدة |
|---|---|---|---|---|
| بيانات القياس | المقاييس هي قيم رقمية تصف جانبا من النظام في نقطة زمنية معينة. يمكن تجميع المقاييس باستخدام الخوارزميات، مقارنة بالمقاييس الأخرى، وتحليلها للاتجاهات بمرور الوقت. | - يتم جمعها تلقائيا على فترات منتظمة. - يمكنك توجيه بعض مقاييس النظام الأساسي إلى مساحة عمل Log Analytics للاستعلام مع بيانات أخرى. تحقق من إعداد تصدير DS لكل مقياس لمعرفة ما إذا كان يمكنك استخدام إعداد تشخيص لتوجيه بيانات القياس. |
مستكشف المقاييس | مقاييس Azure Front Door المدعومة من Azure Monitor |
| بيانات سجل الموارد | السجلات هي أحداث النظام المسجلة مع طابع زمني. يمكن أن تحتوي السجلات على أنواع مختلفة من البيانات، وأن تكون نصا منظما أو حرا. يمكنك توجيه بيانات سجل الموارد إلى مساحات عمل Log Analytics للاستعلام والتحليل. | إنشاء إعداد تشخيص لجمع بيانات سجل الموارد وتوجيهها. | تحليلات السجل | بيانات سجل موارد Azure Front Door المدعومة من Azure Monitor |
| بيانات سجل النشاط | يوفر سجل نشاط Azure Monitor نظرة ثاقبة على الأحداث على مستوى الاشتراك. يتضمن سجل النشاط معلومات مثل وقت تعديل مورد أو بدء تشغيل جهاز ظاهري. | - يتم جمعها تلقائيا. - إنشاء إعداد تشخيص لمساحة عمل Log Analytics دون أي رسوم. |
سجل النشاط |
للحصول على قائمة بجميع البيانات التي يدعمها Azure Monitor، راجع:
المراقبة المضمنة ل Azure Front Door
تتبع السجلات جميع الطلبات التي تمر عبر Azure Front Door. قد يستغرق الأمر بضع دقائق حتى تتم معالجة السجلات وتخزينها.
هناك العديد من سجلات Front Door، والتي يمكنك استخدامها لأغراض مختلفة:
- يمكن استخدام سجلات الوصول لتحديد الطلبات البطيئة، وتحديد معدلات الخطأ، وفهم كيفية عمل سلوك التخزين المؤقت ل Front Door للحل الخاص بك.
- يمكن استخدام سجلات جدار حماية تطبيق الويب (WAF) للكشف عن الهجمات المحتملة، والكشف الإيجابي الخاطئ الذي قد يشير إلى الطلبات المشروعة التي حظرها WAF. لمزيد من المعلومات حول سجلات WAF، راجع مراقبة Azure Web Application Firewall وتسجيله.
- يمكن استخدام سجلات التحقيق الصحي لتحديد الأصول غير السليمة أو التي لا تستجيب للطلبات الواردة من بعض الملوثات العضوية الثابتة الموزعة جغرافيا في Front Door.
- توفر سجلات النشاط رؤية للعمليات التي يتم إجراؤها على موارد Azure، مثل تغييرات التكوين في ملف تعريف Azure Front Door.
تتضمن سجلات الوصول وسجلات WAF مرجع تعقب، والذي يتم نشره أيضا في الطلبات إلى الأصول وإلى استجابات العميل باستخدام X-Azure-Ref العنوان. يمكنك استخدام مرجع التتبع للحصول على طريقة عرض شاملة لمعالجة طلب التطبيق الخاص بك.
لا يتم تمكين سجلات الوصول وسجلات فحص السلامة وسجلات WAF بشكل افتراضي. لتمكين سجلات التشخيص وتخزينها، راجع تكوين سجلات Azure Front Door. يتم تجميع إدخالات سجل النشاط بشكل افتراضي، ويمكنك lمشاهدتها في مدخل Microsoft Azure.
سجل الوصول
يتم تسجيل معلومات حول كل طلب في سجل الوصول. يحتوي كل إدخال سجل وصول على المعلومات المدرجة في الجدول التالي.
| الخاصية | الوصف |
|---|---|
| TrackingReference | السلسلة المرجعية الفريدة التي تحدد طلبا يقدمه Azure Front Door. يتم إرسال مرجع التعقب إلى العميل وإلى الأصل باستخدام الرؤوس X-Azure-Ref . استخدم مرجع التعقب عند البحث عن طلب معين في سجلات الوصول أو WAF. |
| الوقت | تاريخ ووقت تسليم حافة Azure Front Door للمحتويات المطلوبة للعميل (بالتوقيت العالمي المتفق عليه). بالنسبة لاتصالات WebSocket، يمثل الوقت وقت إغلاق الاتصال. |
| HttpMethod | طريقة HTTP المستخدمة في الطلب: حذف، أو الحصول، أو رأس، أو خيارات، أو تصحيح، أو توزيع، أو وضع. |
| HttpVersion | إصدار HTTP الذي حدده العميل في الطلب. |
| RequestUri | عنوان URI للطلب المستلم. يحتوي هذا الحقل على النظام الكامل والمنفذ والمجال والمسار وسلسلة الاستعلام. |
| HostName | اسم المضيف في الطلب من العميل. إذا قمت بتمكين المجالات المخصصة ولديك مجال حرف بدل (*.contoso.com)، فإن قيمة حقل سجل HostName هي subdomain-from-client-request.contoso.com. إذا كنت تستخدم مجال Azure Front Door (contoso-123.z01.azurefd.net)، فإن قيمة حقل سجل HostName هي contoso-123.z01.azurefd.net. |
| RequestBytes | حجم رسالة طلب HTTP بالبايت، بما في ذلك رؤوس الطلب ونص الطلب. بالنسبة لاتصالات WebSocket، هذه القيمة هي إجمالي عدد وحدات البايت المرسلة من العميل إلى الخادم من خلال الاتصال. |
| ResponseBytes | حجم رسالة استجابة HTTP بالبايت. بالنسبة لاتصالات WebSocket، هذه القيمة هي إجمالي عدد وحدات البايت المرسلة من الخادم إلى العميل من خلال الاتصال. |
| UserAgent | عامل المستخدم الذي استخدمه العميل. عادة ما يعرف عامل المستخدم نوع المستعرض. |
| ClientIP | عنوان IP للعميل الذي قدم الطلب الأصلي. إذا كان X-Forwarded-For هناك عنوان في الطلب، أخذ عنوان IP للعميل من العنوان. |
| SocketIp | عنوان IP للاتصال المباشر بحافة Azure Front Door. إذا استخدم العميل وكيل HTTP أو موازن تحميل لإرسال الطلب، فإن قيمة SocketIp هي عنوان IP للوكيل أو موازن التحميل. |
| TimeTaken | المدة من الوقت الذي تلقت فيه حافة Azure Front Door طلب العميل إلى وقت إرسال البايت الأخير من الاستجابة إلى العميل، يتم قياسه بالثوان. يستبعد هذا المقياس زمن انتقال الشبكة والتخزين المؤقت ل TCP. بالنسبة لاتصالات WebSocket، فإنه يمثل مدة الاتصال من الإنشاء إلى الإغلاق. |
| RequestProtocol | البروتوكول المحدد من قبل العميل في الطلب. تتضمن القيم المحتملة: HTTP وHTTPS. بالنسبة إلى WebSocket، البروتوكولات هي WS وWSS. تحتوي الطلبات التي تم ترقيتها بنجاح إلى WebSocket على WS/WSS فقط. |
| SecurityProtocol | إصدار بروتوكول TLS/SSL المستخدم من قبل الطلب، أو فارغ إذا لم يستخدم الطلب التشفير. تتضمن القيم المحتملة: SSLv3، TLSv1، TLSv1.1، TLSv1.2. |
| تشفير الأمان | عندما تكون قيمة بروتوكول الطلب HTTPS، يشير هذا الحقل إلى تشفير TLS/SSL الذي تم التفاوض عليه من قبل العميل وAzure Front Door. |
| نقطة النهاية | اسم المجال لنقطة نهاية Azure Front Door، مثل contoso-123.z01.azurefd.net. |
| HttpStatusCode | تم إرجاع رمز حالة HTTP من Azure Front Door. إذا انتهت مهلة الطلب إلى الأصل، فإن قيمة حقل HttpStatusCode هي 0. إذا أغلق العميل الاتصال، فإن قيمة حقل HttpStatusCode هي 499. |
| Pop | نقطة حضور حافة Azure Front Door (PoP) التي استجابت لطلب المستخدم. |
| حالة ذاكرة التخزين المؤقت | كيفية معالجة ذاكرة التخزين المؤقت ل Azure Front Door للطلب. القيم الممكنة هي:
|
| القواعد المتطابقة | أسماء قواعد محرك القواعد التي تمت معالجتها. |
| اسم المسار | اسم المسار الذي تطابقه الطلب. |
| منفذ العميل | منفذ IP الخاص بالعميل الذي قدم الطلب. |
| المرجع | عنوان URL للموقع الذي أنشأ الطلب. |
| TimetoFirstByte | طول الوقت، بالثوان، من الوقت الذي تلقت فيه حافة Azure Front Door الطلب إلى الوقت الذي تم فيه إرسال البايت الأول إلى العميل، كما تم قياسه بواسطة Azure Front Door. هذه الخاصية لا تقيس بيانات العميل. |
| ErrorInfo | إذا حدث خطأ أثناء معالجة الطلب، يوفر هذا الحقل معلومات مفصلة حول الخطأ. القيم الممكنة هي:
|
| الأصل عنوان URL | عنوان URL الكامل للأصل حيث تم إرسال الطلب. يتكون عنوان URL من النظام ورأس المضيف والمنفذ والمسار وسلسلة الاستعلام. إعادة كتابة عنوان URL: إذا أعاد مشغل القواعد كتابة عنوان URL للطلب، يشير المسار إلى المسار المعاد كتابته. ذاكرة التخزين المؤقت على حافة PoP: إذا تم تقديم الطلب من ذاكرة التخزين المؤقت Azure Front Door، فإن الأصل هو N/A. طلب كبير: إذا كان المحتوى المطلوب كبيرا وكان هناك العديد من الطلبات المكتملة التي تعود إلى الأصل، يتوافق هذا الحقل مع الطلب الأول للأصل. لمزيد من المعلومات، راجع تقسيم الكائنات. |
| الأصل IP | عنوان IP للأصل الذي خدم الطلب. ذاكرة التخزين المؤقت على حافة PoP: إذا تم تقديم الطلب من ذاكرة التخزين المؤقت Azure Front Door، فإن الأصل هو N/A. طلب كبير: إذا كان المحتوى المطلوب كبيرا وكان هناك العديد من الطلبات المكتملة التي تعود إلى الأصل، يتوافق هذا الحقل مع الطلب الأول للأصل. لمزيد من المعلومات، راجع تقسيم الكائنات. |
| OriginName | اسم المضيف الكامل (اسم DNS) للأصل. ذاكرة التخزين المؤقت على حافة PoP: إذا تم تقديم الطلب من ذاكرة التخزين المؤقت Azure Front Door، فإن الأصل هو N/A. طلب كبير: إذا كان المحتوى المطلوب كبيرا وكان هناك العديد من الطلبات المكتملة التي تعود إلى الأصل، يتوافق هذا الحقل مع الطلب الأول للأصل. لمزيد من المعلومات، راجع تقسيم الكائنات. |
| نتيجة |
SSLMismatchedSNI هو رمز الحالة الذي يشير إلى طلب ناجح مع تحذير عدم تطابق بين SNI ورأس المضيف. يشير رمز الحالة هذا إلى واجهة المجال، وهي تقنية تنتهك شروط خدمة Azure Front Door. سيتم رفض الطلبات مع SSLMismatchedSNI بعد 22 يناير 2024. |
| قصاصة برمجية | يحدد هذا الحقل إشارة اسم الخادم (SNI) التي يتم إرسالها أثناء تأكيد اتصال TLS/SSL. يمكن استخدامه لتحديد قيمة SNI الدقيقة إذا كان SSLMismatchedSNI هناك رمز حالة. بالإضافة إلى ذلك، يمكن مقارنتها بقيمة المضيف في requestUri الحقل للكشف عن مشكلة عدم التطابق وحلها. |
سجل فحص السلامة
يسجل Azure Front Door كل طلب فحص صحة فاشل. يمكن أن تساعدك هذه السجلات على تشخيص المشكلات المتعلقة بالأصل. توفر لك السجلات المعلومات التي يمكنك استخدامها للتحقيق في سبب الفشل ثم إعادة الأصل إلى حالة صحية.
بعض السيناريوهات التي يمكن أن يكون هذا السجل مفيداً لها هي:
- لاحظت أنه تم إرسال حركة مرور Azure Front Door إلى مجموعة فرعية من الأصول. على سبيل المثال، قد تلاحظ أن ثلاثة فقط من أصل أربعة أصول تتلقى نسبة استخدام الشبكة. تريد معرفة ما إذا كانت الأصول تتلقى وتستجيب للفحوصات الصحية حتى تعرف ما إذا كانت الأصول سليمة أم لا.
- لقد لاحظت أن مقياس النسبة المئوية لصحة الأصل أقل مما كنت تتوقع. تريد معرفة الأصول التي يتم تسجيلها على أنها غير سليمة وسبب فشل التحقيق الصحي.
يحتوي كل إدخال سجل فحص صحة على المخطط التالي:
| الخاصية | الوصف |
|---|---|
| HealthProbeId | معرف فريد لتحديد طلب فحص السلامة. |
| الوقت | تاريخ ووقت إرسال فحص السلامة (بالتوقيت العالمي المتفق عليه). |
| HttpMethod | أسلوب HTTP المستخدم من قبل طلب فحص السلامة. تتضمن القيم GET و HEAD، استنادا إلى تكوين التحقيق الصحي. |
| نتيجة | حالة الفحص الصحي. القيمة هي إما نجاح أو وصف للخطأ الذي تلقاه التحقيق. |
| HttpStatusCode | رمز حالة HTTP الذي تم إرجاعه بواسطة الأصل. |
| ProbeURL | عنوان URL الهدف الكامل إلى المكان الذي تم إرسال طلب الفحص إليه. يتكون عنوان URL من النظام ورأس المضيف والمسار وسلسلة الاستعلام. |
| OriginName | اسم الأصل الذي تم إرسال الفحص الصحي إليه. يساعدك هذا الحقل على تحديد موقع الأصول المهمة إذا تم تكوين الأصل لاستخدام FQDN. |
| POP | حافة PoP التي أرسلت طلب الفحص. |
| الأصل IP | عنوان IP للأصل الذي تم إرسال التحقيق الصحي إليه. |
| TotalLatency | الوقت الذي أرسلت فيه حافة Azure Front Door طلب فحص السلامة إلى الأصل إلى وقت إرسال الأصل الاستجابة الأخيرة إلى Azure Front Door. |
| ConnectionLatency | الوقت المستغرق في إعداد اتصال TCP لإرسال طلب فحص HTTP إلى الأصل. |
| اختفاء حل DNS | الوقت المستغرق في تحليل DNS. يحتوي هذا الحقل على قيمة فقط إذا تم تكوين الأصل ليكون FQDN بدلا من عنوان IP. إذا تم تكوين الأصل لاستخدام عنوان IP، تكون القيمة N /A. |
يوضح المثال التالي قصاصة JSON البرمجية إدخال سجل فحص السلامة لطلب فحص صحة فاشل.
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
سجل جدار حماية تطبيق الويب
لمزيد من المعلومات حول سجلات جدار حماية تطبيق الويب Front Door (WAF)، راجع مراقبة Azure Web Application Firewall وتسجيله.
بالنسبة إلى Azure Front Door الكلاسيكي، تتضمن المراقبة المضمنة سجلات التشخيص.
سجلات التشخيص
توفر سجلات التشخيص معلومات غنية حول العمليات والأخطاء المهمة للتدقيق واستكشاف الأخطاء وإصلاحها. تختلف سجلات التشخيص عن سجلات النشاط.
توفر سجلات النشاط رؤى حول العمليات التي تم إجراؤها على موارد Azure. توفر سجلات التشخيص نظرة ثاقبة على العمليات التي يقوم بها موردك. لمزيد من المعلومات، راجع سجلات تشخيص Azure Monitor.
لتكوين سجلات التشخيص Azure Front Door (كلاسيكي) الخاص بك:
حدد ملف تعريف Front Door Azure (كلاسيكي) الخاص بك.
اختر Diagnostic settings.
حدد تشغيل التشخيصات. أرشفة سجلات التشخيص جنباً إلى جنب مع المقاييس إلى حساب التخزين أو دفقها إلى مركز الأحداث أو إرسالها إلى سجلاتAzure Monitor.
يوفر Front Door حالياً سجلات التشخيص. توفر سجلات التشخيص طلبات API فردية مع كل إدخال يحتوي على المخطط التالي:
| الخاصية | الوصف |
|---|---|
| BackendHostname | إذا تمت إعادة توجيه الطلب إلى الواجهة الخلفية، فإن هذا الحقل يمثل اسم مضيف الواجهة الخلفية. يكون هذا الحقل فارغا إذا تمت إعادة توجيه الطلب أو إعادة توجيهه إلى ذاكرة تخزين مؤقت إقليمية (عند تمكين التخزين المؤقت لقاعدة التحويل). |
| CacheStatus | بالنسبة لسيناريوهات التخزين المؤقت، يحدد هذا الحقل نتيجة/خطأ ذاكرة التخزين المؤقت في بروتوكول POP |
| ClientIP | عنوان IP للعميل الذي قدم الطلب. إذا كان هناك رأس X-Forwarded-For في الطلب، فسيتم اختيار عنوان IP للعميل من نفس العنوان. |
| منفذ العميل | منفذ IP الخاص بالعميل الذي قدم الطلب. |
| HttpMethod | طريقة HTTP المستخدمة في الطلب. |
| HttpStatusCode | تم إرجاع رمز حالة HTTP من الوكيل. إذا انتهت مهلة طلب الأصل، يتم تعيين قيمة HttpStatusCode إلى 0. |
| HttpStatusDetails | الحالة الناتجة عن الطلب. يمكن العثور على معنى قيمة السلسلة هذه في الجدول المرجعي للحالة. |
| HttpVersion | نوع الطلب أو الاتصال. |
| POP | الاسم المختصر للحافة التي وصل إليها الطلب. |
| RequestBytes | حجم رسالة طلب HTTP بالبايت، بما في ذلك رؤوس الطلب ونص الطلب. |
| RequestUri | URI للطلب المستلم. |
| ResponseBytes | البايت المرسلة من خادم الواجهة الخلفية كاستجابة. |
| RoutingRuleName | اسم قاعدة التحويل التي تطابق الطلب. |
| RulesEngineMatchNames | أسماء القواعد المطابقة للطلب. |
| SecurityProtocol | إصدار بروتوكول TLS/SSL المستخدم بواسطة الطلب أو إصدار فارغ إذا لم يكن هناك تشفير. |
| SentToOriginShield (مهمل) * راجع الملاحظات حول الإهمال في القسم التالي. |
إذا كان هذا صحيحاً، فهذا يعني أنه تم الرد على هذا الطلب من ذاكرة التخزين المؤقت للدرع الأصلي بدلاً من الحافة المنبثقة. درع الأصل هو ذاكرة تخزين مؤقت الأصل تستخدم لتحسين نسبة عدد مرات الدخول إلى ذاكرة التخزين المؤقت. |
| isReceivedFromClient | إذا كان هذا صحيحاً، فهذا يعني أن الطلب جاء من العميل. إذا كان خطأ، فإن الطلب هو خطأ في الحافة (POP التابع للطفل) ويتم الرد عليه من الفرع الأصلي (POP الأصلي). |
| TimeTaken | المدة الزمنية من البايت الأول للطلب إلى Front Door حتى آخر بايت من الاستجابة، بالثواني. |
| TrackingReference | سلسلة المرجع الفريدة التي تحدد طلباً مقدماً من قبل Front Door، يتم إرسالها أيضاً كرأس X-Azure-Ref إلى العميل. مطلوب للبحث عن تفاصيل في سجلات الوصول لطلب معين. |
| UserAgent | نوع المتصفح الذي استخدمه العميل. |
| ErrorInfo | يحتوي هذا الحقل على نوع الخطأ المحدد لمزيد من استكشاف الأخطاء وإصلاحها.
تتضمن القيم المحتملة: NoError: يشير إلى أنه لم يتم العثور على خطأ. CertificateError: خطأ عام في شهادة SSL. CertificateNameCheckFailed: اسم المضيف في شهادة SSL غير صالح أو غير مطابق. ClientDisconnected: فشل الطلب بسبب اتصال شبكة العميل. UnspecifiedClientError: خطأ عام للعميل. InvalidRequest: طلب غير صالح. قد يحدث بسبب عدم تكوين رأس ونص وعنوان URL بشكل غير صحيح. DNSFailure: فشل DNS. DNSNameNotResolved: تعذر تحليل اسم الخادم أو العنوان. OriginConnectionAborted: توقف الاتصال بالأصل فجأة. خطأ OriginConnectionError: خطأ اتصال أصل عام. OriginConnectionRefused: تعذر إنشاء الاتصال بالأصل. OriginError: خطأ أصل عام. OriginInvalidResponse: عرض الأصل استجابة غير صالحة أو غير معروفة. OriginTimeout: انتهت مدة المهلة لطلب الأصل. ResponseHeaderTooBig: أرجع الأصل حجماً كبيراً جداً من رأس الاستجابة. RestrictedIP: تم حظر الطلب بسبب عنوان IP المقيد. SSLHandshakeError: تعذر إنشاء اتصال مع الأصل بسبب فشل اهتزاز يد SSL. UnspecifiedError: حدث خطأ لا يتناسب مع أي من أخطاء الجدول. SSLMismatchedSNI: الطلب غير صالح لأن رأس رسالة HTTP لم يتطابق مع القيمة المقدمة في ملحق TLS SNI أثناء إعداد اتصال SSL/TLS. |
| نتيجة |
SSLMismatchedSNI هو رمز الحالة الذي يشير إلى طلب ناجح مع تحذير عدم تطابق بين SNI ورأس المضيف. يشير رمز الحالة هذا إلى واجهة المجال، وهي تقنية تنتهك شروط خدمة Azure Front Door. سيتم رفض الطلبات مع SSLMismatchedSNI بعد 22 يناير 2024. |
| قصاصة برمجية | يحدد هذا الحقل إشارة اسم الخادم (SNI) التي يتم إرسالها أثناء تأكيد اتصال TLS/SSL. يمكن استخدامه لتحديد قيمة SNI الدقيقة إذا كان SSLMismatchedSNI هناك رمز حالة. بالإضافة إلى ذلك، يمكن مقارنتها بقيمة المضيف في requestUri الحقل للكشف عن مشكلة عدم التطابق وحلها. |
تم الإرسال إلى إيقاف الدرع الأصل
يتم إهمال خاصية السجل الخام isSentToOriginShield واستبدالها بالحقل الجديد isReceivedFromClient. استخدم الحقل الجديد إذا كنت تستخدم الحقل المهمل بالفعل.
تتضمن السجلات الأولية السجلات التي تم إنشاؤها من كل من حافة CDN (POP التابع) ودرع الأصل. يشير درع الأصل إلى العقد الأصلية التي تقع إستراتيجياً في جميع أنحاء العالم. تتواصل هذه العقد مع الخوادم الأصلية وتقلل من حمل المرور على الأصل.
لكل طلب يذهب إلى درع الأصل، هناك إدخالان للسجل:
- واحد لعُقد الحافة
- واحد للدروع الأصلية
للتمييز بين الخروج أو الاستجابات من عقد الحافة مقابل درع الأصل، يمكنك استخدام الحقل isReceivedFromClient للحصول على البيانات الصحيحة.
إذا كانت القيمة خاطئة، فهذا يعني أنه تمت الاستجابة للطلب من درع الأصل إلى عقد الحافة. هذا النهج فعال لمقارنة السجلات الأولية ببيانات الفوترة. لا يتم تكبد رسوم للخروج من درع الأصل إلى العقد الطرفية. يتم تكبد رسوم للخروج من العقد الطرفية للعملاء.
نموذج استعلام Kusto لاستبعاد السجلات التي تم إنشاؤها على درع الأصل في Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
إشعار
بالنسبة إلى تكوينات التوجيه المختلفة وسلوكيات حركة المرور، قد تستجيب بعض الحقول مثل backendHostname و cacheStatus و isReceivedFromClient وحقل POP بقيم مختلفة. يوضح الجدول التالي القيم المختلفة لهذه الحقول لسيناريوهات مختلفة:
| السيناريوهات | عدد إدخالات السجل | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| قاعدة التحويل بدون تمكين التخزين المؤقت | 1 | التعليمة البرمجية لـ POP للحافة | الخلفية حيث تم توجيه الطلب | صواب | CONFIG_NOCACHE |
| قاعدة التحويل مع تمكين التخزين المؤقت. الوصول إلى ذاكرة التخزين المؤقت على حافة POP | 1 | التعليمة البرمجية لـ POP للحافة | فارغ | صواب | الوصول |
| قاعدة التحويل مع تمكين التخزين المؤقت. يخطئ ذاكرة التخزين المؤقت في حافة POP ولكن ذاكرة التخزين المؤقت وصلت إلى ذاكرة التخزين المؤقت الأصل POP | 2 | 1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. اسم مضيف POP للتخزين المؤقت الرئيسي 2. فارغ |
1. True 2. خطأ |
1. MISS 2. الوصول |
| قاعدة التحويل مع تمكين التخزين المؤقت. تفوت ذاكرة التخزين المؤقت في حافة POP ولكن ذاكرة التخزين المؤقت الجزئية أصابت ذاكرة التخزين المؤقت الأصل POP | 2 | 1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. اسم مضيف POP للتخزين المؤقت الرئيسي 2. 2. الخلفية التي تساعد على ملء ذاكرة التخزين المؤقت |
1. True 2. خطأ |
1. MISS 2. PARTIAL_HIT |
| قاعدة التحويل مع تمكين التخزين المؤقت. ذاكرة التخزين المؤقت PARTIAL_HIT عند حافة POP ولكن ذاكرة التخزين المؤقت وصلت إلى ذاكرة التخزين المؤقت الأصل POP | 2 | 1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. True 2. خطأ |
1. PARTIAL_HIT 2. الوصول |
| قاعدة التحويل مع تمكين التخزين المؤقت. يفتقد ذاكرة التخزين المؤقت في كل من ذاكرة التخزين المؤقت للحافة والذاكرة المؤقتة الأصلية POP | 2 | 1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. حافة رمز POP 2. كود POP مخبأ للوالدين |
1. True 2. خطأ |
1. MISS 2. MISS |
| خطأ في معالجة الطلب | غير متوفر |
إشعار
بالنسبة لسيناريوهات التخزين المؤقت، تكون قيمة حالة ذاكرة التخزين المؤقت PARTIAL_HIT عندما يتم تقديم بعض وحدات البايت لطلب من حافة Azure Front Door أو ذاكرة التخزين المؤقت للدروع الأصلية بينما يتم تقديم بعض وحدات البايت من الأصل للكائنات الكبيرة.
يستخدم Azure Front Door تقنية تُسمى تجميع العناصر. عند طلب ملف كبير، يسترد Azure Front Door أجزاء الملف الأصغر من الأصل. بعد أن يتلقى خادم Azure Front Door POP نطاقات كاملة أو نطاقات بايت للملف المطلوب، يطلب خادم حافة Azure Front Door الملف من الأصل في أجزاء تبلغ 8 ميغابايت.
بعد وصول القطعة إلى حافة Azure Front Door، يتم تخزينها مؤقتًا وتقديمها على الفور للمستخدم. ثم يقوم Azure Front Door بإعداد الجزء التالي بشكل متوازٍ. يضمن هذا الجلب المسبق بقاء المحتوى جزءاً واحداً قبل المستخدم، ما يقلل من زمن الانتقال. تستمر هذه العملية حتى يتم تنزيل الملف بالكامل (إذا طُلب ذلك)، أو تتوفر جميع نطاقات البايت (عند الطلب)، أو يغلق العميل الاتصال. لمزيد من المعلومات بشأن طلب نطاق البايت، راجع RFC 7233. Azure Front Door يخزن أي قطع عند استلامها. لا يلزم تخزين الملف بأكمله مؤقتاً في ذاكرة التخزين المؤقت للباب الأمامي. يتم تقديم الطلبات المقدمة للملف أو نطاقات البايت من ذاكرة التخزين المؤقت لـAzure Front Door. إذا لم يتم تخزين جميع الأجزاء مؤقتاً في Azure Front Door، فسيتم استخدام الجلب المسبق لطلب القطع من الأصل. يعتمد هذا التحسين على قدرة الخادم الأصلي على دعم طلبات نطاق البايت. إذا كان الخادم الأصلي لا يدعم طلبات نطاق البايت، فلن يكون هذا التحسين فعالاً.
استخدام أدوات Azure Monitor لتحليل البيانات
تتوفر أدوات Azure Monitor هذه في مدخل Microsoft Azure لمساعدتك في تحليل بيانات المراقبة:
تحتوي بعض خدمات Azure على لوحة معلومات مراقبة مضمنة في مدخل Microsoft Azure. تسمى لوحات المعلومات هذه رؤى، ويمكنك العثور عليها في قسم Insights في Azure Monitor في مدخل Microsoft Azure.
يسمح لك مستكشف المقاييس بعرض وتحليل المقاييس لموارد Azure. لمزيد من المعلومات، راجع تحليل المقاييس باستخدام مستكشف مقاييس Azure Monitor.
يسمح لك Log Analytics بالاستعلام عن بيانات السجل وتحليلها باستخدام لغة استعلام Kusto (KQL). لمزيد من المعلومات، راجع البدء في استعلامات السجل في Azure Monitor.
يحتوي مدخل Azure على واجهة مستخدم لعرض سجل النشاط وعمليات البحث الأساسية له. لإجراء تحليل أكثر تعمقا، قم بتوجيه البيانات إلى سجلات Azure Monitor وتشغيل استعلامات أكثر تعقيدا في Log Analytics.
يراقب Application Insights توفر تطبيقات الويب وأدائها واستخدامها، بحيث يمكنك تحديد الأخطاء وتشخيصها دون انتظار المستخدم للإبلاغ عنها.
يتضمن Application Insights نقاط الاتصال بأدوات التطوير المختلفة ويتكامل مع Visual Studio لدعم عمليات DevOps الخاصة بك. لمزيد من المعلومات، راجع مراقبة التطبيق لخدمة التطبيقات.
تتضمن الأدوات التي تسمح بتصور أكثر تعقيدا ما يلي:
- لوحات المعلومات التي تتيح لك دمج أنواع مختلفة من البيانات في جزء واحد في مدخل Microsoft Azure.
- المصنفات والتقارير القابلة للتخصيص التي يمكنك إنشاؤها في مدخل Microsoft Azure. يمكن أن تتضمن المصنفات النص والمقاييس واستعلامات السجل.
- Grafana، أداة منصة مفتوحة تتفوق في لوحات المعلومات التشغيلية. يمكنك استخدام Grafana لإنشاء لوحات معلومات تتضمن بيانات من مصادر متعددة غير Azure Monitor.
- Power BI، خدمة تحليلات الأعمال التي توفر مرئيات تفاعلية عبر مصادر بيانات مختلفة. يمكنك تكوين Power BI لاستيراد بيانات السجل تلقائيًا من Azure Monitor للاستفادة من هذه المرئيات.
تصدير بيانات Azure Monitor
يمكنك تصدير البيانات من Azure Monitor إلى أدوات أخرى باستخدام:
المقاييس: استخدم واجهة برمجة تطبيقات REST للمقاييس لاستخراج بيانات القياس من قاعدة بيانات مقاييس Azure Monitor. لمزيد من المعلومات، راجع مرجع Azure Monitor REST API.
السجلات: استخدم واجهة برمجة تطبيقات REST أو مكتبات العميل المقترنة.
تصدير بيانات مساحة عمل Log Analytics.
للبدء في Azure Monitor REST API، راجع معاينة واجهة برمجة تطبيقات REST لمراقبة Azure.
استخدام استعلامات Kusto لتحليل بيانات السجل
يمكنك تحليل بيانات سجل Azure Monitor باستخدام لغة استعلام Kusto (KQL). لمزيد من المعلومات، راجع تسجيل الاستعلامات في Azure Monitor.
استخدام تنبيهات Azure Monitor لإعلامك بالمشكلات
تسمح لك تنبيهات Azure Monitor بتحديد المشكلات ومعالجتها في النظام الخاص بك، وإعلامك بشكل استباقي عند العثور على شروط محددة في بيانات المراقبة قبل أن يلاحظها عملاؤك. يمكنك التنبيه على أي مقياس أو مصدر بيانات سجل في النظام الأساسي للبيانات Azure Monitor. هناك أنواع مختلفة من تنبيهات Azure Monitor اعتمادا على الخدمات التي تراقبها وبيانات المراقبة التي تجمعها. راجع اختيار النوع الصحيح من قاعدة التنبيه.
للحصول على أمثلة للتنبيهات الشائعة لموارد Azure، راجع نموذج استعلامات تنبيه السجل.
تنفيذ التنبيهات على نطاق واسع
بالنسبة لبعض الخدمات، يمكنك المراقبة على نطاق واسع عن طريق تطبيق نفس قاعدة التنبيه القياسي على موارد متعددة من نفس النوع موجودة في نفس منطقة Azure. توفر Azure Monitor Baseline Alerts (AMBA) طريقة شبه آلية لتنفيذ تنبيهات قياس النظام الأساسي الهامة ولوحات المعلومات والإرشادات على نطاق واسع.
الحصول على توصيات مخصصة باستخدام Azure Advisor
بالنسبة لبعض الخدمات، إذا حدثت ظروف حرجة أو تغييرات وشيكة أثناء عمليات الموارد، يتم عرض تنبيه على صفحة نظرة عامة على الخدمة في المدخل. يمكنك العثور على مزيد من المعلومات والإصلاحات الموصى بها للتنبيه في توصيات Advisor ضمن المراقبة في القائمة اليمنى. أثناء العمليات العادية، لا يتم عرض توصيات المستشار.
لمزيد من المعلومات حول Azure Advisor، راجع نظرة عامة على Azure Advisor.