El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe la metodología general para resolver problemas de una experiencia de GUI de APIC lenta.
Se observa con frecuencia que los problemas de la GUI de APIC lenta son el resultado de una alta tasa de solicitudes de API originadas en un script, integración o aplicación. El archivo access.log de un APIC registra cada solicitud de API procesada. El access.log de un APIC se puede analizar rápidamente con el script Access Log Analyzer dentro del proyecto Github Datacenter group aci-tac-scripts.
NGINX es el DME responsable de los terminales API disponibles en cada APIC. Si NGINX no funciona, no se pueden gestionar las solicitudes de API. Si NGINX está congestionado, la API también lo está. Cada APIC ejecuta su propio proceso NGINX, por lo que es posible que solo un APIC pueda tener problemas de NGINX si solo ese APIC es el objetivo de cualquier consultor agresivo.
La interfaz de usuario de APIC realiza varias solicitudes de API para rellenar cada página. Del mismo modo, todos los comandos 'show' de APIC (CLI de estilo NXOS) son contenedores para scripts de Python que realizan varias solicitudes de API, controlan la respuesta y, a continuación, se la proporcionan al usuario.
Nombre de archivo de registro |
Ubicación |
¿En qué soporte técnico se encuentra? |
Comentarios |
access.log |
/var/log/dme/log |
APIC 3de3 |
Independiente de ACI, ofrece 1 línea por solicitud de API |
error.log |
/var/log/dme/log |
APIC 3de3 |
Independiente de ACI, muestra errores nginx (limitación incluida) |
nginx.bin.log |
/var/log/dme/log |
APIC 3de3 |
específico de ACI, registra las transacciones de DME |
nginx.bin.warnplus.log |
/var/log/dme/log |
APIC 3de3 |
Las opciones específicas de ACI contienen registros con advertencia+ gravedad. |
¿Qué se ve afectado?
¿Cómo se experimenta la lentitud?
¿Cuándo se notó por primera vez la lentitud?
access.log es una función de NGINX y, por lo tanto, es independiente de APIC. Cada línea representa 1 solicitud HTTP que el APIC recibió. Consulte este registro para comprender el uso de NGINX de un APIC.
El formato predeterminado de access.log en ACI versión 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"';
Esta línea representa una entrada access.log cuando se realiza un 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"
Mapa de la entrada access.log de ejemplo a log_format:
campo log_format |
Contenido del ejemplo |
Comentarios |
$remote_addr |
127.0.0.1 |
IP del host que envió esta solicitud |
$http_x_real_ip |
- |
IP del último solicitante si hay proxies en uso |
$remote_user |
- |
Generalmente no se utiliza. Marque nginx.bin.log para realizar un seguimiento del usuario que ha iniciado sesión para realizar solicitudes |
$time_local |
07/Abr/2022:20:10:59 +0000 |
Cuándo se procesó la solicitud |
$request |
GET /api/class/fvTenant.xml HTTP/1.1 |
Método Http (GET, POST, DELETE) y URI |
$status |
200 |
|
$body_bytes_sent |
1586 |
tamaño de carga útil de respuesta |
$http_referer |
- |
- |
$http_user_agent |
Python-urllib |
Qué tipo de cliente envió la solicitud |
Ráfagas de solicitudes de alta velocidad durante un período de tiempo prolongado:
Respuestas 4xx o 5xx coherentes:
El uso de memoria y CPU de NGINX se puede verificar con el comando top del 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
Un uso elevado de los recursos NGINX puede estar directamente relacionado con una alta tasa de solicitudes procesadas.
Una caída de NGINX no es típica para problemas de GUI de Slow APIC. Sin embargo, si se encuentran núcleos NGINX, adjúntelos a un TAC SR para su análisis. Consulte la guía de soporte técnico de ACI para conocer los pasos para comprobar los núcleos.
Si no se encuentran solicitudes rápidas pero un usuario sigue mostrando lentitud en la interfaz de usuario, el problema puede ser la latencia de cliente (navegador) a servidor (APIC).
En estos casos, valide la ruta de datos desde el navegador al APIC (distancia geográfica, VPN, etc.). Si es posible, implemente y pruebe el acceso desde un servidor de acceso directo ubicado en la misma región geográfica o Data Center que los APIC para aislar. Validar si otros usuarios presentan una latencia similar.
Todos los exploradores tienen la capacidad de validar solicitudes y respuestas HTTP mediante su kit de herramientas Desarrollo de explorador, normalmente en una ficha Red.
Esta herramienta se puede utilizar para validar la cantidad de tiempo que se tarda en cada etapa de las solicitudes originadas en el navegador, como se muestra en la imagen.
Página Grupo de Políticas:
La GUI de Cisco bug ID CSCvx14621 - APIC se carga lentamente en las políticas IPG en la pestaña Fabric.
Interfaz en la página Inventario:
ID de bug de Cisco CSCvx90048 - La carga inicial de la ficha operativa "Configuración de interfaz física de capa 1" es larga/induce la "congelación".
Ciertos navegadores, como Firefox, permiten más conexiones web por host de forma predeterminada.
La VPN y la distancia al APIC aumentan la lentitud general de la interfaz de usuario, dadas las solicitudes del navegador del cliente y el tiempo de viaje de respuesta del APIC. Un cuadro de salto geográficamente local a los APIC reduce significativamente el tiempo de viaje del navegador a APIC.
Si un servidor web (NGINX en APIC) gestiona un gran volumen de solicitudes web largas, esto puede afectar al rendimiento de otras solicitudes recibidas en paralelo.
Esto es especialmente cierto en el caso de los sistemas que tienen bases de datos distribuidas, como los APIC. Una única solicitud de API puede requerir solicitudes y búsquedas adicionales enviadas a otros nodos del fabric, lo que puede dar lugar a tiempos de respuesta esperadamente más largos. Una ráfaga de estas solicitudes web largas en un período de tiempo reducido puede aumentar la cantidad de recursos necesarios y provocar tiempos de respuesta inesperadamente más largos. Además, las solicitudes recibidas pueden agotar el tiempo de espera (90 segundos), lo que se traduce en un comportamiento inesperado del sistema desde la perspectiva del usuario.
En 4.2(1)+, un usuario puede habilitar el "Cálculo del rendimiento del sistema", que realiza un seguimiento de las solicitudes de API y las resalta, que tardaron mucho tiempo en gestionarse.
Una vez que se habilita "Cálculo", un usuario puede navegar a APIC específicos bajo Controladores para ver las solicitudes de API más lentas en los últimos 300 segundos.
Disponible en 4.2(1)+, un usuario puede habilitar el acelerador de solicitudes contra HTTP y HTTPS de forma independiente.
Cuando está habilitado:
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"
Como regla general, el acelerador de solicitudes solo sirve para proteger el servidor (APIC) de los síntomas similares a DDOS inducidos por clientes agresivos con consultas. Comprender y aislar el cliente agresivo en la solicitud para las soluciones finales en la lógica de aplicación/script.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
04-Jan-2023 |
Se añadió la sección de tiempo de respuesta del sistema y la sección de aceleración de solicitud NGINX |
1.0 |
17-May-2022 |
Versión inicial |