سجلات التشخيص لبوابة التطبيق
توفر سجلات بوابة التطبيق معلومات مفصلة للأحداث المتعلقة بالمورد وعملياته. تتوفر هذه السجلات لأحداث مثل Access والنشاط وجدار الحماية والأداء (فقط ل V1). المعلومات الدقيقة في السجلات مفيدة عند استكشاف مشكلة وإصلاحها أو إنشاء لوحة معلومات تحليلات عن طريق استهلاك هذه البيانات الأولية.
تتوفر السجلات لجميع موارد Application Gateway؛ ومع ذلك، لاستهلاكها، يجب تمكين مجموعتها في موقع تخزين من اختيارك. يتم تمكين تسجيل الدخول إلى Azure Application Gateway بواسطة خدمة Azure Monitor. نوصي باستخدام مساحة عمل Log Analytics حيث يمكنك بسهولة استخدام استعلاماتها المحددة مسبقا وتعيين التنبيهات استنادا إلى شروط سجل محددة.
أنواع سجلات التشخيص
يمكنك استخدام أنواع مختلفة من السجلات في Azure لإدارة واستكشاف أخطاء application gateways وإصلاحها. يمكنك معرفة المزيد حول هذه الأنواع أدناه:
- سجل النشاط: يمكنك استخدام سجلات نشاط Azure (المعروفة سابقاً باسم سجلات التشغيل وسجلات التدقيق) لعرض جميع العمليات التي تم إرسالها إلى اشتراك Azure وحالتها. يتم تجميع إدخالات سجل النشاط بشكل افتراضي، ويمكنك lمشاهدتها في مدخل Microsoft Azure.
- سجل الوصول: يمكنك استخدام هذا السجل لعرض أنماط الوصول إلى بوابة التطبيق وتحليل المعلومات المهمة. يتضمن ذلك عنوان IP الخاص بالمتصل، وعنوان URL المطلوب، ووقت زمن انتقال الاستجابة، والتعليمة البرمجية للإرجاع، والبايت للداخل والخارج. حيث يتم جمع سجل الوصول كل 60 ثانية. يحتوي هذا التسجيل على سجل واحد لكل مثيل من Application Gateway. يتم تحديد مثيل Application Gateway بواسطة خاصية معرف المثيل.
- سجل الأداء: يمكنك استخدام هذا السجل لعرض كيفية أداء مثيلات Application Gateway. يلتقط هذا السجل معلومات الأداء لكل مثيل، بما في ذلك إجمالي الطلبات المقدمة، ومعدل النقل بالبايت، وإجمالي الطلبات المقدمة، وعدد الطلبات الفاشلة، وعدد المثيلات الخلفية السليمة وغير السليمة. يتم تجميع سجل الأداء كل 60 ثانية. يتوفر سجل الأداء فقط لـ v1 SKU. بالنسبة إلى v2 SKU، استخدم المقاييس لبيانات الأداء.
- سجل جدار الحماية: يمكنك استخدام هذا السجل لعرض الطلبات التي تم تسجيلها من خلال وضع الكشف أو المنع لـ application gateway التي تم تكوينها باستخدام جدار حماية تطبيق الويب. يتم جمع سجلات جدار الحماية كل 60 ثانية.
إشعار
تتوفر السجلات فقط للموارد المنشورة في نموذج توزيع Azure Resource Manager. لا يمكنك استخدام السجلات للموارد في نموذج النشر الكلاسيكي. للحصول على فهم أفضل للنموذجين، راجع مقالة فهم نشر Resource Manager والنشر الكلاسيكي.
مواقع التخزين
لديك الخيارات التالية لتخزين السجلات في موقعك المفضل.
مساحة عمل Log Analytic: يسمح لك هذا الخيار باستخدام الاستعلامات المعرفة مسبقا والمرئيات وتعيين التنبيهات استنادا إلى شروط سجل محددة. تعتمد الجداول المستخدمة بواسطة سجلات الموارد في مساحة عمل تحليلات السجل على نوع المجموعة التي يستخدمها المورد:
تشخيصات Azure: تتم كتابة البيانات إلى جدول تشخيصات Azure. تتم مشاركة جدول Azure Diagnostics بين نوع مورد متعدد، مع إضافة كل منها لحقول مخصصة خاصة به. عندما يتجاوز عدد الحقول المخصصة التي تم استيعابها في جدول تشخيصات Azure 500 حقل، لا تتم إضافة حقول جديدة كمستوى أعلى ولكن تتم إضافتها إلى حقل "AdditionalFields" كأزواج قيمة مفتاح ديناميكية.
خاص بالموارد (مستحسن): تتم كتابة البيانات إلى جداول مخصصة لكل فئة من فئات المورد. في الوضع الخاص بالمورد، يتم تعيين جدول كل فئة سجل محددة في إعداد التشخيص ضمن مساحة العمل المختارة. هذا له العديد من الفوائد، بما في ذلك:
- معالجة البيانات بسهولة في استعلامات السجل
- تحسين إمكانية اكتشاف المخططات وبنياتها
- الأداء المحسن من حيث زمن انتقال الاستيعاب وأوقات الاستعلام
- القدرة على تعيين حقوق التحكم في الوصول المستندة إلى دور Azure لجداول محددة
بالنسبة ل Application Gateway، ينشئ الوضع الخاص بالموارد ثلاثة جداول:
إشعار
يتوفر الخيار الخاص بالمورد حاليا في جميع المناطق العامة.
يمكن للمستخدمين الحاليين الاستمرار في استخدام تشخيصات Azure، أو يمكنهم اختيار جداول مخصصة عن طريق تبديل في إعدادات التشخيص إلى Resource specific، أو إلى Dedicated في وجهة API. الوضع المزدوج غير ممكن. يمكن أن تتدفق البيانات الموجودة في جميع السجلات إما إلى تشخيصات Azure أو إلى جداول مخصصة. ومع ذلك، يمكن أن يكون لديك إعدادات تشخيص متعددة حيث يكون تدفق بيانات واحد إلى تشخيص azure وآخر يستخدم موردا محددا في نفس الوقت.
تحديد الجدول الوجهة في تحليلات السجل: تستخدم جميع خدمات Azure في النهاية الجداول الخاصة بالموارد. كجزء من هذا الانتقال، يمكنك تحديد جدول خاص بتشخيص Azure أو مورد معين في إعداد التشخيص باستخدام زر تبديل. يتم تعيين التبديل إلى Resource specific بشكل افتراضي وفي هذا الوضع، يتم إرسال سجلات الفئات المحددة الجديدة إلى جداول مخصصة في Log Analytics، بينما تظل التدفقات الموجودة دون تغيير. انظر المثال الآتي.
تحويلات مساحة العمل: يتيح لك اختيار خيار Resource specific تصفية بياناتك وتعديلها قبل استيعابها مع تحويلات مساحة العمل. يوفر هذا تحكما دقيقا، مما يسمح لك بالتركيز على المعلومات الأكثر صلة من السجلات هناك عن طريق تقليل تكاليف البيانات وتعزيز الأمان. للحصول على إرشادات مفصلة حول إعداد تحويلات مساحة العمل، يرجى الرجوع إلى:البرنامج التعليمي: إضافة تحويل مساحة عمل إلى سجلات Azure Monitor باستخدام مدخل Microsoft Azure.
أمثلة على تحسين سجلات الوصول باستخدام تحويلات مساحة العمل
مثال 1: الإسقاط الانتقائي للأعمدة: تخيل أن لديك سجلات وصول إلى بوابة التطبيق مع 20 عمودا، ولكنك مهتم بتحليل البيانات من 6 أعمدة محددة فقط. باستخدام تحويل مساحة العمل، يمكنك عرض هذه الأعمدة الستة في مساحة العمل الخاصة بك، باستثناء الأعمدة ال 14 الأخرى بشكل فعال. على الرغم من أن البيانات الأصلية من تلك الأعمدة المستبعدة لن يتم تخزينها، إلا أن العناصر النائبة الفارغة لها لا تزال تظهر في شفرة السجلات. يعمل هذا النهج على تحسين التخزين ويضمن الاحتفاظ بالبيانات ذات الصلة فقط للتحليل.
إشعار
ضمن جزء Logs، يؤدي تحديد خيار Try New Log Analytics إلى منح تحكم أكبر في الأعمدة المعروضة في واجهة المستخدم الخاصة بك.
مثال 2: التركيز على رموز الحالة المحددة: عند تحليل سجلات الوصول، بدلا من معالجة جميع إدخالات السجل، يمكنك كتابة استعلام لاسترداد الصفوف التي تحتوي على رموز حالة HTTP معينة فقط (مثل 4xx و5xx). نظرا لأن معظم الطلبات تندرج بشكل مثالي ضمن فئتي 2xx و3xx (تمثل الاستجابات الناجحة)، فإن التركيز على رموز الحالة الإشكالية يضيق نطاق مجموعة البيانات. يسمح لك هذا النهج المستهدف باستخراج المعلومات الأكثر ملاءمة وقابلية للتنفيذ، ما يجعلها مفيدة وفعالة من حيث التكلفة.
استراتيجية الانتقال الموصى بها للانتقال من تشخيص Azure إلى جدول خاص بالموارد:
- تقييم استبقاء البيانات الحالي: حدد المدة التي يتم فيها الاحتفاظ بالبيانات حاليا في جدول تشخيص Azure (على سبيل المثال: افترض أن جدول التشخيص يحتفظ بالبيانات لمدة 15 يوما).
- إنشاء استبقاء خاص بالموارد: تنفيذ إعداد تشخيص جديد مع جدول خاص بالمورد.
- تجميع البيانات المتوازية: لفترة مؤقتة، اجمع البيانات بشكل متزامن في كل من تشخيصات Azure والإعدادات الخاصة بالموارد.
- تأكيد دقة البيانات: تحقق من أن جمع البيانات دقيق ومتسق في كلا الإعدادين.
- إزالة إعداد تشخيص Azure: قم بإزالة إعداد تشخيص Azure لمنع جمع البيانات المكررة.
مواقع التخزين الأخرى:
- حساب تخزين Azure: أفضل استخدام لحسابات التخزين للسجلات عند تخزين السجلات لمدة أطول ومراجعتها عند الحاجة.
- مراكز أحداث Azure: تعد مراكز الأحداث خيارا رائعا للتكامل مع أدوات إدارة معلومات الأمان والأحداث الأخرى (SIEM) للحصول على تنبيهات حول مواردك.
- تكاملات شركاء Azure Monitor.
تعرف على المزيد حول وجهات إعدادات تشخيص Azure Monitor .
تمكين تسجيل الدخول من خلال PowerShell
يتم تمكين تسجيل النشاط تلقائياً لكل مورد Resource Manager. يجب تمكين الوصول وتسجيل الأداء لبدء تجميع البيانات المتوفرة من خلال تلك السجلات. لتمكين تسجيل الدخول، استخدم الخطوات التالية:
لاحظ معرف مورد حساب التخزين الخاص بك، حيث يتم تخزين بيانات السجل. هذه القيم بالشكل: /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<اسم حساب التخزين>. يمكنك استخدام أي حساب تخزين في اشتراكك. يمكنك استخدام مدخل Microsoft Azure للبحث عن هذه المعلومات.
لاحظ معرّف مورد application gateway الذي تم تمكين التسجيل له. هذه القيمة هي النموذج: /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<اسم بوابة التطبيق>. يمكنك استخدام المدخل للعثور على هذه المعلومات.
تمكين التسجيل التشخيصي باستخدام أمر PowerShell cmdlet التالي:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
تلميح
لا تتطلب سجلات النشاط حساب تخزين منفصل. يؤدي استخدام التخزين للوصول وتسجيل الأداء إلى فرض رسوم الخدمة.
تمكين تسجيل الدخول عبر مدخل Microsoft Azure
في مدخل Azure، ابحث عن المورد وحدد Diagnostic settings.
بالنسبة لـ Application Gateway، تتوفر ثلاثة سجلات:
- سجل الوصول
- سجل الأداء
- سجل جدار الحماية
لبدء تجميع البيانات، حدد Turn on diagnostics.
توفر الصفحة Diagnostics settings الإعدادات اللازمة لسجلات التشخيص. في هذا المثال، يخزن «Log Analytics» السجلات. ويمكنك أيضاً استخدام مراكز الأحداث وحساب تخزين لحفظ سجلات التشخيص.
اكتب اسما للإعدادات، وتأكد من الإعدادات، وحدد Save.
سجل النشاط
يقوم Azure بإنشاء سجل النشاط بشكل افتراضي. يتم الاحتفاظ بالسجلات لمدة 90 يوماً في مخزن سجلات أحداث Azure. تعرف على المزيد حول هذه السجلات من خلال قراءة مقالة عرض الأحداث وسجل النشاط.
سجل الوصول
يتم إنشاء سجل الوصول فقط إذا قمت بتمكينه على كل مثيل Application Gateway، كما هو مفصّل في الخطوات السابقة. يتم تخزين البيانات في حساب التخزين الذي حددته عند تمكين التسجيل. يتم تسجيل كل وصول إلى Application Gateway بتنسيق JSON كما هو موضح أدناه.
لـ Application Gateway وWAF v2 SKU
إشعار
- للحصول على المعلومات المتعلقة بوكيل TLS/TCP، تفضل بزيارة مرجع البيانات.
- لا يزال يتم نقل بعض الأعمدة من جدول AzureDiagnostics المشترك إلى الجداول المخصصة. لذلك، تتوفر الأعمدة التي تحتوي على تفاصيل المصادقة المتبادلة حاليا فقط من خلال جدول AzureDiagnostics.
- تنشأ سجلات الوصول بقيمة clientIP 127.0.0.1 من عملية أمان داخلية تعمل على مثيلات بوابة التطبيق. يمكنك تجاهل إدخالات السجل هذه بأمان.
| قيمة | الوصف |
|---|---|
| instanceId | مثيل Application Gateway الذي قدم الطلب. |
| ClientIP | IP للعميل المباشر لبوابة التطبيق. إذا كان وكيل آخر أمام بوابة التطبيق الخاص بك، فهذا يعرض IP لوكيل الواجهة الأمامية هذا. |
| httpMethod | طريقة HTTP المستخدمة في الطلب. |
| requestUri | URI للطلب المستلم. |
| UserAgent | عامل المستخدم من عنوان طلب HTTP. |
| httpStatus | إرجاع التعليمة البرمجية لحالة HTTP إلى العميل من Application Gateway. |
| httpVersion | إصدار HTTP من الطلب. |
| receivedBytes | حجم الحزمة المتلقاة بالبايت. |
| sentBytes | حجم الحزمة المرسلة بالبايت. |
| clientResponseTime | الفرق الزمني (بالثوان) بين البايت الأول وبوابة تطبيق البايت الأخيرة المرسلة إلى العميل. مفيد في مراقبة وقت معالجة بوابة التطبيق للاستجابات أو العملاء البطيءين. |
| timeTaken | طول الوقت (بالثوان) الذي يستغرقه البايت الأول من طلب العميل ليتم معالجته وإرسال البايت الأخير الخاص به في الاستجابة للعميل. من المهم ملاحظة أن حقل الوقت المستغرق يتضمن عادةً الوقت الذي تنتقل فيه حزم الطلب والرد عبر الشبكة. |
| WAFEvaluationTime | المدة الزمنية (بالثوان) التي يستغرقها الطلب ليتم معالجته بواسطة WAF. |
| WAFMode | يمكن أن تكون القيمة إما الكشف أو الوقاية |
| transactionId | معرف فريد لربط الطلب المستلم من العميل |
| sslEnabled | ما إذا كان الاتصال بتجمعات الواجهة الخلفية يستخدم TLS. القيم الصالحة هي تشغيل وإيقاف. |
| sslCipher | مجموعة التشفير المستخدمة لاتصال TLS (إذا تم تمكين TLS). |
| sslProtocol | يكون بروتوكول SSL/TLS قيد الاستخدام (إذا تم تمكين TLS). |
| serverRouted | الخادم الخلفي الذي يقوم application gateway بتوجيه الطلب إليه. |
| serverStatus | التعليمة البرمجية لحالة HTTP للخادم الخلفي. |
| serverResponseLatency | زمن الانتقال (بالثواني)من خادم الواجهة الخلفية. |
| مضيف | العنوان المدرج في عنوان المضيف للطلب. إذا أعيدت كتابته باستخدام إعادة كتابة العنوان، فإن هذا الحقل يحتوي على اسم المضيف المحدث |
| originalRequestUriWithArgs | يحتوي هذا الحقل على عنوان URL للطلب الأصلي |
| requestUri | يحتوي هذا الحقل على عنوان URL بعد عملية إعادة الكتابة على Application Gateway |
| المصدرمصدر المصدر | منفذ المصدر المستخدم من قبل بوابة التطبيق عند بدء اتصال بالهدف الخلفي |
| originalHost | يحتوي هذا الحقل على اسم مضيف الطلب الأصلي |
| error_info | سبب الخطأ 4xx و5xx. يعرض رمز خطأ لطلب فاشل. مزيد من التفاصيل في معلومات رمز الخطأ. |
| نوع المحتوى | نوع المحتوى أو البيانات التي تتم معالجتها أو تسليمها بواسطة بوابة التطبيق |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
لمعيار Application Gateway وWAF SKU (v1)
| قيمة | الوصف |
|---|---|
| instanceId | مثيل Application Gateway الذي قدم الطلب. |
| ClientIP | إنشاء IP للطلب. |
| clientPort | إنشاء منفذ للطلب. |
| httpMethod | طريقة HTTP المستخدمة في الطلب. |
| requestUri | URI للطلب المستلم. |
| RequestQuery | Server-Routed: مثيل تجمع الخلفية الذي تم إرسال الطلب. X-AzureApplicationGateway-LOG-ID: معرف الارتباط المستخدم للطلب. يمكن استخدامه لاستكشاف مشكلات حركة المرور وإصلاحها على خوادم الواجهة الخلفية. SERVER-STATUS: رمز استجابة HTTP الذي تلقته بوابة التطبيق من النهاية الخلفية. |
| UserAgent | عامل المستخدم من عنوان طلب HTTP. |
| httpStatus | إرجاع التعليمة البرمجية لحالة HTTP إلى العميل من Application Gateway. |
| httpVersion | إصدار HTTP من الطلب. |
| receivedBytes | حجم الحزمة المتلقاة بالبايت. |
| sentBytes | حجم الحزمة المرسلة بالبايت. |
| timeTaken | المدة الزمنية (بالملي ثانية) التي تستغرقها معالجة الطلب وإرسال استجابته. يتم حساب هذا على أنه الفاصل الزمني من وقت تلقي Application Gateway للبايت الأول من طلب HTTP إلى الوقت الذي تنتهي فيه عملية إرسال الاستجابة. من المهم ملاحظة أن حقل الوقت المستغرق يتضمن عادةً الوقت الذي تنتقل فيه حزم الطلب والرد عبر الشبكة. |
| sslEnabled | ما إذا كان الاتصال بتجمعات الواجهة الخلفية يستخدم TLS/SSL. القيم الصالحة هي تشغيل وإيقاف. |
| مضيف | اسم المضيف الذي تم إرسال الطلب إليه إلى الخادم الخلفي. إذا تم تجاوز اسم مضيف الواجهة الخلفية، فإن هذا الاسم يعكس ذلك. |
| originalHost | اسم المضيف الذي تم تلقي الطلب من قبل بوابة التطبيق من العميل. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
معلومات رمز الخطأ
إذا لم تتمكن بوابة التطبيق من إكمال الطلب، فإنها تخزن أحد رموز السبب التالية في حقل error_info لسجل الوصول.
| أخطاء 4XX | (تشير رموز الخطأ 4xx إلى وجود مشكلة في طلب العميل، ولا يمكن لبوابة التطبيق الوفاء بها.) |
|---|---|
| ERRORINFO_INVALID_METHOD | أرسل العميل طلبا غير متوافق مع RFC. الأسباب المحتملة: العميل الذي يستخدم أسلوب HTTP غير مدعوم من قبل الخادم، الأسلوب الذي به خطأ إملائي، إصدار بروتوكول HTTP غير متوافق وما إلى ذلك. |
| ERRORINFO_INVALID_REQUEST | لا يمكن للخادم تلبية الطلب بسبب بناء جملة غير صحيح. |
| ERRORINFO_INVALID_VERSION | تلقت بوابة التطبيق طلبا بإصدار HTTP غير صالح أو غير معتمد. |
| ERRORINFO_INVALID_09_METHOD | أرسل العميل طلبا مع إصدار بروتوكول HTTP 0.9. |
| ERRORINFO_INVALID_HOST | القيمة المتوفرة في عنوان "المضيف" مفقودة أو منسقة بشكل غير صحيح أو لا تتطابق مع قيمة المضيف المتوقعة. على سبيل المثال، عندما لا يوجد مستمع أساسي، ولا يتطابق أي من أسماء مضيفي وحدات الاستماع متعددة المواقع مع المضيف. |
| ERRORINFO_INVALID_CONTENT_LENGTH | لا يتطابق طول المحتوى المحدد من قبل العميل في عنوان طول المحتوى مع الطول الفعلي للمحتوى في الطلب. |
| ERRORINFO_INVALID_METHOD_TRACE | أرسل العميل أسلوب HTTP TRACE، وهو غير مدعوم من قبل بوابة التطبيق. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | أغلق العميل الاتصال ببوابة التطبيق قبل انقضاء فترة مهلة الخمول. تحقق مما إذا كانت فترة مهلة العميل أكبر من فترة مهلة الخمول لبوابة التطبيق. |
| ERRORINFO_REQUEST_URI_INVALID | يشير إلى وجود مشكلة في معرف الموارد الموحد (URI) المتوفر في طلب العميل. |
| ERRORINFO_HTTP_NO_HOST_HEADER | أرسل العميل طلبا بدون عنوان المضيف. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | أرسل العميل طلب HTTP عادي إلى منفذ HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | يشير إلى أن العميل لا يرسل شهادة TLS صالحة ومكونة بشكل صحيح أثناء مصادقة TLS المتبادلة. |
| أخطاء 5XX | الوصف |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | بوابة التطبيق غير قادرة على العثور على أي خوادم خلفية نشطة أو يمكن الوصول إليها لمعالجة الطلبات الواردة |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | أغلق الخادم الخلفي الاتصال بشكل غير متوقع أو قبل معالجة الطلب بالكامل. قد يحدث هذا بسبب وصول الخادم الخلفي إلى حدوده، أو تعطله، وما إلى ذلك. |
| ERRORINFO_UPSTREAM_TIMED_OUT | تم إغلاق اتصال TCP الذي تم إنشاؤه مع الخادم حيث استغرق الاتصال وقتا أطول من قيمة المهلة المكونة. |
سجل الأداء
يتم إنشاء سجل الأداء فقط إذا قمت بتمكينه على كل مثيل Application Gateway، كما هو مفصل في الخطوات السابقة. يتم تخزين البيانات في حساب التخزين الذي حددته عند تمكين التسجيل. يتم إنشاء بيانات سجل الأداء في فترات زمنية مدتها دقيقة واحدة. وهي متاحة فقط ل v1 SKU. بالنسبة إلى v2 SKU، استخدم المقاييس لبيانات الأداء. يتم تسجيل البيانات التالية:
| قيمة | الوصف |
|---|---|
| instanceId | مثيل Application Gateway الذي يتم إنشاء بيانات الأداء من أجله. بالنسبة لبوابة تطبيق متعددة المثيلات، هناك صف واحد لكل مثيل. |
| healthyHostCount | عدد المضيفين الأصحاء في تجمع الخلفية. |
| unHealthyHostCount | عدد المضيفين غير السليمين في تجمع الخلفية. |
| requestCount | عدد الطلبات التي تقديمها. |
| زمن الوصول | متوسط زمن الوصول (بالملي ثانية) للطلبات من النسخة إلى النهاية الخلفية التي تخدم الطلبات. |
| failedRequestCount | عدد الطلبات الفاشلة. |
| معدل النقل | متوسط معدل النقل منذ السجل الأخير، مقاساً بالبايت في الثانية. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
إشعار
يتم حساب زمن الانتقال من وقت استلام البايت الأول من طلب HTTP إلى وقت إرسال البايت الأخير من استجابة HTTP. إنه مجموع وقت معالجة Application Gateway بالإضافة إلى تكلفة الشبكة حتى النهاية، بالإضافة إلى الوقت الذي تستغرقه حتى النهاية لمعالجة الطلب.
سجل جدار الحماية
يتم إنشاء سجل جدار الحماية فقط إذا قمت بتمكينه لكل application gateway، كما هو مفصل في الخطوات السابقة. كما يتطلب هذا السجل أيضاً تكوين جدار حماية تطبيق الويب على application gateway. يتم تخزين البيانات في حساب التخزين الذي حددته عند تمكين التسجيل. يتم تسجيل البيانات التالية:
| قيمة | الوصف |
|---|---|
| instanceId | مثيل Application Gateway الذي يتم من أجله إنشاء بيانات جدار الحماية. بالنسبة لبوابة تطبيق متعددة المثيلات، هناك صف واحد لكل مثيل. |
| clientIp | إنشاء IP للطلب. |
| clientPort | إنشاء منفذ للطلب. |
| requestUri | URL للطلب المستلم. |
| ruleSetType | نوع مجموعة القواعد. القيمة المتوفرة هي OWASP. |
| ruleSetVersion | إصدار مجموعة القواعد المستخدمة. القيم المتوفرة هي 2.2.9 و3.0. |
| ruleId | معرّف القاعدة للحدث المشغل. |
| رسالة | رسالة سهلة الاستخدام للحدث المشغل. يتم توفير المزيد من التفاصيل في قسم التفاصيل. |
| إجراء | الإجراءات المتخذة بناءً على الطلب. القيم المتاحة محظورة ومسموح بها (للقواعد المخصصة)، ومتوافقة (عندما تتطابق قاعدة مع جزء من الطلب)، ومكتشفة ومحظورة (كلاهما للقواعد الإلزامية، اعتماداً على ما إذا كان WAF في وضع الاكتشاف أو المنع). |
| موقع | الموقع الذي تم إنشاء السجل من أجله. حاليا، يتم سرد العمومية فقط لأن القواعد عمومية. |
| details | تفاصيل الحدث المشغل. |
| details.message | وصف القاعدة. |
| details.data | بيانات محددة تم العثور عليها عند الطلب تطابق القاعدة. |
| details.file | ملف التكوين الذي يحتوي على القاعدة. |
| details.line | رقم السطر في ملف التكوين الذي قام بتشغيل الحدث. |
| اسم المضيف | اسم المضيف أو عنوان IP لـ Application Gateway. |
| transactionId | معرّف فريد لمعاملة معينة يساعد في تجميع انتهاكات القواعد المتعددة التي حدثت في نفس الطلب. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
عرض سجل النشاط وتحليله
يمكنك عرض بيانات سجل النشاط وتحليلها باستخدام أي من الطرق التالية:
- أدوات Azure: يمكنك استرداد المعلومات من سجل النشاط من خلال Azure PowerShell أو Azure CLI أو Azure REST API أو مدخل Azure. تم تفصيل التعليمات الاسترشادية المُفصّلة لكل أسلوب في مقالة عمليات النشاط باستخدام إدارة الموارد "ARM".
- Power BI: إذا لم يكن لديك حساب Power BI بالفعل، فيمكنك تجربته مجاناً. باستخدام تطبيقات قالب Power BI، يمكنك تحليل بياناتك.
عرض وتحليل سجلات الوصول، والأداء، وجدار الحماية
يمكن أن تجمع سجلات Azure Monitor ملفات الحساب وسجل الأحداث من حساب تخزين كائن ثنائي كبير الحجم Blob storage. يتضمن تصورات وقدرات بحث قوية لتحليل سجلاتك.
يمكنك أيضاً الاتصال بحساب التخزين لديك واسترداد إدخالات سجل JSON للوصول وسجلات الأداء. بعد تنزيل ملفات JSON، يمكنك تحويلها إلى CSV وعرضها في Excel أو Power BI أو أي أداة أخرى لتصور البيانات.
تلميح
إذا كنت معتاداً على Visual Studio والمفاهيم الأساسية لتغيير قيم الثوابت والمتغيرات في C#، فيمكنك استخدام أدوات محول السجل المتوفرة من GitHub.
تحليل سجلات الوصول من خلال GoAccess
يمكنك أيضاً استخدام قالب Resource Manager الذي يقوم بتثبيت محلل السجلات الشائع GoAccess وتشغيله بالنسبة لسجلات الوصول في Application Gateway. يوفر GoAccess إحصاءات استخدام شبكة HTTP قيِّمة، مثل الزوار الفريدين، والملفات المطلوبة، والمضيفين، وأنظمة التشغيل، والمتصفحات ورموز حالة HTTP. لمزيد من التفاصيل، الرجاء مراجعة الملف التمهيدي في مجلد نموذج Resource Manager في GitHub.
الخطوات التالية
- تصور سجلات العداد والأحداث باستخدام سجلات Azure Monitor.
- تصور سجل نشاط Azure باستخدام مشاركة منشور مدونة Power BI.
- راجع عرض وتحليل سجلات نشاط Azure في Power BI والمزيد من منشورات المدونة.