إختبار وثيقة جدول المحتويات

المقدمة

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

البدء السريع

غالبا ما يتم العثور على أن مشاكل واجهة المستخدم الرسومية (GUI) ل APIC البطيئة هي نتيجة لمعدل مرتفع من طلبات API التي تم الحصول عليها من برنامج نصي أو تكامل أو تطبيق. يقوم Access.log الخاص ب APIC بتسجيل كل طلب من طلبات API التي تمت معالجتها. يمكن تحليل Access.log for APIC بسرعة باستخدام البرنامج النصي Access Log Analyzer ضمن مشروع ACI-TAC-Scripts الخاص بمجموعة Github DataCenter.

معلومات أساسية

APIC كخادم ويب - NGINX

NGINX هو DME المسؤول عن نقاط نهاية API المتوفرة على كل APIC. إذا كان NGINX معطلا، فلا يمكن معالجة طلبات واجهة برمجة التطبيقات (API). إذا كان NGINX محتقنا، فإن واجهة برمجة التطبيقات (API) تكون مزدحمة. تقوم كل واجهة برمجة تطبيقات بتشغيل عملية NGINX الخاصة بها، لذلك من الممكن أن يكون هناك فقط واجهة برمجة تطبيقات فردية واحدة يمكن أن تواجه مشاكل NGINX إذا كانت واجهة برمجة التطبيقات هذه مستهدفة من قبل أي مستعلم عدواني.

تقوم واجهة برمجة تطبيقات APIC بتنفيذ طلبات API متعددة لملء كل صفحة. بالمثل، فإن كل أوامر عرض APIC (CLI نمط NXOS) هي مغلفات للبرامج النصية ل Python التي تقوم بالعديد من طلبات API، وتعالج الاستجابة، ثم تخدمها للمستخدم.

السجلات ذات الصلة

منهجية

عزل المشغل الأولي

ما الذي يؤثر؟

• (أ) المناطق التي تتأثر بها المناطق المشمولة بالبروتوكول؛ واحد، كثير، أو كل APICs؟
• وين التسويف مبين؛ من خلال واجهة المستخدم أو أوامر واجهة سطر الأوامر (CLI) أو كليهما؟
• ما هي الصفحات أو الأوامر الخاصة بواجهة المستخدم بطيئة؟

كيف يجري إختبار البطء؟

• هل يظهر هذا عبر مستعرضات متعددة لمستخدم واحد؟
• هل يقوم عدة مستخدمين بالإبلاغ عن البطء أو عن مجموعة واحدة/فرعية فقط من المستخدمين؟
• هل يشارك المستخدمون المتضررون في موقع جغرافي مماثل أو مسار شبكة من المستعرض إلى APIC؟

متى لاحظنا البطء اولا؟

• هل تمت إضافة تكامل ACI أو برنامج نصي مؤخرا؟
• هل تم تمكين ملحق المستعرض مؤخرا؟
• هل كان هناك تغيير حديث في تكوين قائمة التحكم في الوصول (ACI)؟

التحقق من إستخدام NGINX وصحته

تنسيق إدخال Access.log

access.log هو ميزة ل NGINX، وبالتالي، فهو لا أعلم APIC. يمثل كل سطر طلب HTTP واحد الذي تلقته APIC. راجع هذا السجل لفهم إستخدام NGINX لواجهة برمجة تطبيقات (APIC).

تنسيق access.log الافتراضي على ACI الإصدار 5.2+:

log_format proxy_ip '$remote_addr ($http_x_real_ip) - $remote_user [$time_local]'
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

يمثل هذا السطر إدخال access.log عند تنفيذ moquery -c fvTenant:

127.0.0.1 (-) - - [07/Apr/2022:20:10:59 +0000]"GET /api/class/fvTenant.xml HTTP/1.1" 200 15863 "-" "Python-urllib"

خريطة مثال access.log entry to log_format:

Access.Log Behaviors

إرتفاع معدل الطلبات يشتعل على مدى فترة زمنية طويلة:

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

استجابات متناسقة بمعدل 4xx أو 5xx:

• إن وجد، عينت الخطأ رسالة من nginx.bin.log

يمكن تحليل Access.log for APIC بسرعة باستخدام البرنامج النصي Access Log Analyzer ضمن مشروع ACI-TAC-Scripts الخاص بمجموعة Github DataCenter.

التحقق من إستخدام مورد NGINX

يمكن التحقق من وحدة المعالجة المركزية (CPU) الخاصة ب NGINX واستخدام الذاكرة باستخدام الأمر top من APIC:

top - 13:19:47 up 29 days, 2:08, 11 users, load average: 12.24, 11.79, 12.72
Tasks: 785 total, 1 running, 383 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.5 us, 2.0 sy, 0.0 ni, 94.2 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 13141363+total, 50360320 free, 31109680 used, 49943636 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 98279904 avail Mem

PID   USER PR NI VIRT    RES   SHR   S %CPU %MEM TIME+     COMMAND 
21495 root 20 0  4393916 3.5g 217624 S 2.6  2.8  759:05.78 nginx.bin

يمكن أن يرتبط الاستخدام المرتفع لموارد NGINX مباشرة بارتفاع معدل الطلبات التي تمت معالجتها.

التحقق من المراكز

لا يعد عطل NGINX نموذجيا للمشكلات الخاصة بواجهة المستخدم الرسومية (GUI) ل APIC البطيئة. ومع ذلك، إذا تم العثور على مراكز NGINX، فقم بإرفاقها ب TAC SR للتحليل. ارجع إلى دليل الدعم الفني لقائمة التحكم في الوصول (ACI) للحصول على خطوات للتحقق من المراكز.

التحقق من زمن انتقال العميل إلى الخادم

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

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

علامة تبويب شبكة أدوات تطوير المستعرض

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

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

مثال على المستعرض الذي ينتظر 1.1 دقيقة لكي يستجيب APIC

تحسينات لصفحات واجهة مستخدم معينة

صفحة مجموعة النهج:

معرف تصحيح الأخطاء من Cisco CSCvx14621 - يتم تحميل واجهة المستخدم الرسومية (GUI) ل APIC ببطء على سياسات IPG في علامة التبويب "البنية".

الواجهة الموجودة ضمن صفحة المخزون:

معرف تصحيح الأخطاء من Cisco CSCvx90048 - الحمل الأولي من "الطبقة 1 تشكيل الواجهة المادية" علامة التبويب التشغيلية طويل/يحفز على "تجميد".

توصيات عامة للعميل > زمن انتقال الخادم

تتيح بعض المستعرضات، مثل Firefox، المزيد من إتصالات الويب لكل مضيف بشكل افتراضي.

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

تعمل الشبكة الخاصة الظاهرية (VPN) والمسافة التي تصل إلى APIC على زيادة بطء واجهة المستخدم الإجمالي نظرا لطلبات مستعرض العميل ووقت سفر إستجابة APIC. يقلل مربع الانتقال المحلي جغرافيا إلى APICs بشكل كبير المتصفح إلى أوقات السفر APIC.

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

إذا كان خادم ويب (NGINX على APIC) يعالج كمية كبيرة من طلبات الويب الطويلة، فقد يؤثر ذلك على أداء الطلبات الأخرى المتلقاة بالتوازي.

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

وقت إستجابة النظام - تمكين الحساب لوقت إستجابة الخادم

في 4.2(1)+، يمكن للمستخدم تمكين "حساب أداء النظام" الذي يتتبع طلبات واجهة برمجة التطبيقات (API) التي استغرقت وقتا طويلا لمعالجتها ويسلط الضوء عليها.

يمكن تمكين الحساب من النظام - إعدادات النظام - أداء النظام

بمجرد تمكين "الحساب"، يمكن للمستخدم الانتقال إلى عناوين APIC معينة ضمن وحدات التحكم لعرض أبطأ طلبات API خلال آخر 300 ثانية.

النظام - وحدات التحكم - مجلد وحدات التحكم - APIC X - وقت إستجابة الخادم

اعتبارات إستخدام API

مؤشرات عامة للتأكد من أن البرنامج النصي لا يضر NGINX

• يقوم كل ملف APIC بتشغيل ملف NGINX DME الخاص به.
  • طلبات NGINX الخاصة ب APIC 1 فقط. لا يقوم APIC 2 و NGINX الخاص ب 3 بمعالجة هذه الطلبات.
• وبشكل عام، يتسبب ما يزيد عن 40 طلبا من طلبات واجهة برمجة التطبيقات في الثانية على مدى فترة زمنية طويلة في إضعاف NGINX.
  
  • وإذا وجدت، فقل من حدة الطلبات.
  • إذا تعذر تعديل مضيف الطلبات، فاعتبر حدود معدل NGINX على APIC.

أوجه القصور في البرامج النصية للعنوان

• عدم تسجيل الدخول/تسجيل الخروج قبل كل طلب من طلبات واجهة برمجة التطبيقات.
  • المهلة الافتراضية لجلسة عمل تسجيل دخول واحدة هي 10 دقائق. يمكن إستخدام نفس جلسة العمل هذه لطلبات متعددة ويمكن تحديثها لتمديد وقت الصلاحية.
  • راجع دليل تكوين واجهة برمجة التطبيقات (APIC) REST API من Cisco - الوصول إلى واجهة برمجة التطبيقات (REST) - المصادقة على جلسة عمل واجهة برمجة التطبيقات (API) وصيانتها.
• إذا كان البرنامج النصي الخاص بك يستعلم عن العديد من DNs التي تشترك في أصل، بدلا من طي الاستعلامات إلى استعلام أصل منطقي واحد باستخدام عوامل تصفية الاستعلام.
  
  • راجع دليل تكوين واجهة برمجة التطبيقات (APIC) REST API من Cisco - تكوين استعلامات REST API - تطبيق عوامل تصفية نطاق الاستعلام.
• إذا كنت بحاجة إلى تحديثات لكائن أو فئة كائن، ضع في الاعتبار اشتراكات WebSocket بدلا من طلبات API السريعة.

تقييد طلب NGINX

يستطيع المستخدم، المتوفر في 4.2(1)+، تمكين تقييد الطلب مقابل HTTP و HTTPS بشكل مستقل.

ملاحظة: بدءا من الإصدار 6.1(2) من واجهة برمجة التطبيقات، تم تخفيض المعدل الأقصى المدعوم لهذه الميزة إلى 40 طلبا في الثانية (r/s) أو 2400 طلب في الدقيقة (r/m) من 10000 r/m.

Fabric - سياسات البنية - مجلد السياسات - مجلد الوصول إلى الإدارة - الافتراضي

عند التمكين:

• تمت إعادة تشغيل NGINX لتطبيق تغييرات ملف التكوين
  • تمت كتابة منطقة جديدة، httpsClientTagZone، إلى تكوين nginx
• يمكن تعيين معدل الكبح في طلبات في الدقيقة (r/m) أو طلبات في الثانية (r/s).
• يعتمد تقييد الطلب على تنفيذ حد المعدل المضمن في NGINX
  • تستخدم طلبات واجهة برمجة التطبيقات (API) مقابل URI معدل الكبح المحدد بواسطة المستخدم + الاندفاع= (معدل الكبح x 2) + عدم التأخير
    • يوجد خانق غير قابل للتكوين (zone aaaApiHttps) ل /api/aaaLogin و/api/aaaRefresh أي حد للمعدل عند 2r/s + burst=4 + nodelay
  • يتم تعقب تقييد الطلب على أساس عنوان IP لكل عميل
  • طلبات API التي يتم الحصول عليها من APIC Self-IP (UI + CLI) تتجاوز كبح
  • أي عنوان IP للعميل الذي يعبر معدل الكبح المعرف من قبل المستخدم + حد الاندفاع يستلم إستجابة 503 من APIC
  • يمكن ربط هذه الأجهزة 503s داخل سجلات الوصول
  • يحتوي Error.log على إدخالات تشير إلى الوقت الذي تم فيه تنشيط التقييد (المنطقة httpsClientTagZone) وعلى أي مضيف من العملاء

apic# less /var/log/dme/log/error.log
...
2023/04/17 20:19:14 [error] ... limiting requests, excess: 40.292 by zone "httpsClientTagZone", client: h.o.s.t, ... request: "GET /api/class/...", host: "a.p.i.c"
2023/04/17 20:19:14 [error] ... limiting requests, excess: 40.292 by zone "httpsClientTagZone", client: h.o.s.t, ... request: "GET /api/node/...", host: "a.p.i.c"

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

توصيات

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

تعطيل تسجيل قائمة التحكم في الوصول (ACL)

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

لمزيد من التفاصيل، راجع دليل تكوين أمان واجهة برمجة التطبيقات من Cisco (إرتباط دليل 5.2.x):
https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/5x/security-configuration/cisco-apic-security-configuration-guide-release-52x/security-policies-52x.html

الحد من تحويل Syslog إلى الأحداث الهامة

قم بتكوين النظام حتى يتم تحويل رسائل syslog فقط التي تحتوي على تنبيه الخطورة إلى EventRecords. تجنب تحويل مستوى المعلومات (والذي يتضمن ACL.Logging) لمنع الأحداث المزعجة من تجاوز APIC:

1. انتقل إلى سياسات البنية → الليفية → السياسات → المراقبة → السياسة المشتركة → نهج رسائل Syslog → الافتراضي.
2. قم بضبط عامل تصفية التسهيلات لتعيين خطورة syslog للتنبيه.

رموز الحدث غير الأساسي

منع رموز الأحداث (Squelch) غير ذات الصلة باحتياجات المراقبة الخاصة بك لتقليل الضوضاء.
لإسكات رمز حدث E4204939، أستخدم هذا الأمر على أي CLI لواجهة سطر الأوامر:

bash
icurl -k -sX POST -d '<fabricInst><monCommonPol><eventSevAsnP code="E4204939" sev="squelched"/></monCommonPol></fabricInst>' 'https://localhost/api/node/mo/uni/.xml’

للتحقق من:

bash
icurl -k -sX GET 'https://localhost/api/node/class/eventSevAsnP.xml' | xmllint --format -

بدلا من ذلك، تحقق عبر واجهة المستخدم:
نسيج > سياسات بنيوية > سياسات > مراقبة > سياسة عامة > سياسة تعيين خطورة الحدث

تحسين تحديثات اشتراك ND

بالنسبة للقنوات الليفية التي تتم إدارتها بواسطة إصدارات ND التي تسبق الإصدار 3.2.2 متر أو 4.1.1g، قم بالترقية إلى أحد هذه الإصدارات أو إصدار أحدث لتحسين فواصل تحديث الاشتراك. يتم تحديث الإصدارات السابقة كل 45 ثانية لكل عملية نقل بيانات، مما يمكن أن ينتج عنه، على نطاق واسع، أكثر من 300000 طلب APIC في اليوم. تزيد الإصدارات المحدثة مهلة الاشتراك إلى 3600 ثانية (ساعة واحدة)، مما يقلل من عمليات التحديث إلى حوالي 5000 في اليوم.

مراقبة الاستعلامات ذات الصلة ب Intersight

تقوم البنى التي تم تمكين ميزة Intersight بإنشاء استعلامات نظام أساسي دورية من موصل DC (كل 15 ثانية)، مما يضيف إلى حمل APIC.
في الإصدار 6.1.2 والإصدارات الأحدث، تم تحسين هذا الاستعلام لتقليل التكاليف.

ضبط نهج الاستبقاء للسجلات

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