أستكشاف أخطاء واجهة مستخدم APIC بطيئة وإصلاحها

المقدمة

يصف هذا المستند المنهجية العامة لاستكشاف أخطاء تجربة واجهة المستخدم الرسومية (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 متعددة لملء كل صفحة. وبالمثل، فإن جميع أوامر "show" لواجهة سطر الأوامر (CLI) الخاصة بواجهة سطر الأوامر (NXOS Style) هي برامج تضمين للبرامج النصية ل Python التي تنفذ طلبات واجهة برمجة تطبيقات متعددة، وتعالج الاستجابة، ثم تخدمها للمستخدم.

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

اسم ملف السجل	الموقع	أي دعم فني هو في	التعليقات
access.log	/var/log/dme/log	APIC 3of3	ACI لا أعلم، تعطي سطر واحد لكل طلب API
خطأ.log	/var/log/dme/log	APIC 3of3	عدم تطابق ACI، يعرض أخطاء NGINX (متضمنا التقييد)
nginx.bin.log	/var/log/dme/log	APIC 3of3	محدد لواجهة التحكم في الوصول (ACI)، يقوم بتسجيل حركات DME
nginx.bin.warnplus.log	/var/log/dme/log	APIC 3of3	يحتوي "محدد قائمة التحكم في الوصول (ACI)" على سجلات تشكل تحذيرا+ خطورة

منهجية

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

ما الذي يؤثر؟

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

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

• هل يظهر هذا عبر مستعرضات متعددة لمستخدم واحد؟
• هل يقوم عدة مستخدمين بالإبلاغ عن البطء أو عن مجموعة واحدة/فرعية فقط من المستخدمين؟
• هل يشارك المستخدمون المتضررون في موقع جغرافي مماثل أو مسار شبكة من المستعرض إلى 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:

حقل log_format	محتوى من مثال	التعليقات
$remote_addr	127.0.0.1	IP الخاص بالمضيف الذي أرسل هذا الطلب
$http_x_real_ip	-	IP لآخر طالب إذا كانت الوكلاء قيد الاستخدام
$remote_user	-	غير مستخدم بشكل عام. تحقق من nginx.bin.log لتعقب المستخدم الذي سجل الدخول لتنفيذ الطلبات
$time_local	07/APR/2022:20:10:59 +000	عند معالجة الطلب
طلب $	احصل على /api/class/fvTenant.xml http/1.1	أسلوب HTTP (GET، POST، DELETE) و URI
حالة $	200	رمز حالة إستجابة HTTP
$body_bytes_sent	1586	حجم حمولة الاستجابة
$http_reference	-	-
$http_user_agent	بايثون أورليب	نوع العميل الذي أرسل الطلب

Access.Log Behaviors

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

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

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

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

التحقق من إستخدام مورد 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 1. لا يعالج NGINX ل APIC 2 و 3 هذه الطلبات.
• وبشكل عام، يتسبب ما يزيد عن 15 طلبا من طلبات واجهة برمجة التطبيقات في الثانية على مدى فترة زمنية طويلة في إضعاف 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 بشكل مستقل.

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.يحتوي السجل على إدخالات تشير إلى الوقت الذي تم فيه تنشيط التقييد (المنطقة 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 التي تحدث من قبل العملاء المهتمين بالاستعلام. فهم العميل الذي يدعم الطلب وعزل الحلول النهائية في منطق التطبيق/البرنامج النصي.