Resolución de problemas de una GUI de Slow APIC

Introducción

Este documento describe la metodología general para resolver problemas de una experiencia de GUI de APIC lenta.

Inicio rápido

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.

Antecedentes

APIC como servidor web: NGINX

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.

Registros relevantes

Metodología

Aislar desencadenador inicial

¿Qué se ve afectado?

• Qué APIC se ven afectados; ¿uno, varios o todos los APIC?
• ¿Dónde se ve la lentitud? mediante la interfaz de usuario, comandos CLI o ambos?
• ¿Qué páginas o comandos específicos de la interfaz de usuario son lentos?

¿Cómo se experimenta la lentitud?

• ¿Se ve esto en varios navegadores para un solo usuario?
• ¿Varios usuarios informan de lentitud o solo un único/subconjunto de usuarios?
• ¿Los usuarios afectados comparten una ubicación geográfica o ruta de red similar desde el navegador al APIC?

¿Cuándo se notó por primera vez la lentitud?

• ¿Se ha agregado recientemente una secuencia de comandos o integración de ACI?
• ¿Se ha habilitado recientemente una extensión de explorador?
• ¿Ha habido algún cambio reciente en la configuración de ACI?

Comprobar el uso y el estado de NGINX

Formato de entrada de Access.log

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:

Comportamientos de Access.log

Ráfagas de solicitudes de alta velocidad durante un período de tiempo prolongado:

• Las ráfagas continuas de más de 40 solicitudes por segundo pueden causar lentitud en la interfaz de usuario
• Identificar qué host(s) son responsables de las consultas
• Reduzca o desactive el origen de las consultas para ver si esto mejora el tiempo de respuesta de APIC.

Respuestas 4xx o 5xx coherentes:

• Si se encuentra, identifique el mensaje de error de nginx.bin.log

Comprobación del uso de recursos NGINX

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.

Comprobar si hay núcleos

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.

Comprobar latencia cliente a servidor

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.

Ficha Red de herramientas de desarrollo del explorador

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.

Ejemplo de un navegador que espera 1,1 minutos para que el APIC responda

Mejoras para Páginas Específicas de la IU

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".

Recomendaciones generales para cliente > Latencia del servidor

Ciertos navegadores, como Firefox, permiten más conexiones web por host de forma predeterminada.

• Compruebe si este parámetro se puede configurar en la versión del explorador que se utilice
• Esto es más importante para las páginas de múltiples consultas, como la página Grupo de Políticas

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.

Comprobar solicitudes Long-Web

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.

Tiempo de respuesta del sistema - Habilitar cálculo para el tiempo de respuesta del servidor

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.

El cálculo se puede habilitar desde Sistema - Configuración del sistema - Rendimiento del sistema

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.

Sistema - Controladores - Carpeta de controladores - APIC x - Tiempo de respuesta del servidor

Tiempo de respuesta del sistema - Supervisión

Si tiene un escenario en el que la respuesta de la interfaz de usuario se ralentiza aleatoriamente pero no hay supervisión activa para saber con qué frecuencia ocurre, puede utilizar uno de los 2 enfoques

Opción 1:  Un enfoque de suscripción para obtener el tiempo de respuesta del fabric de forma constante. Este paso requiere un servidor externo para ejecutar la secuencia de comandos que enviará la solicitud de suscripción y las actualizaciones.

Opción 2:  Una secuencia de comandos a petición ejecutada en el propio APIC y las salidas masajeadas en LV. Esta puede ser una opción más fácil debido a la menor dependencia

Opción 1. Enfoque de suscripción

Paso 1:  (también mencionado anteriormente) Cambio global único en el APIC. No intrusivo pero bueno para seguir siempre las prácticas de cambio estándar.

Vaya a Sistema—>Configuración del sistema—>Rendimiento del sistema

Habilitar cálculos

Establecer umbral de respuesta en 50000ms

No cambie los demás parámetros

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.

Paso 2:

• Se necesita un host externo con un entorno python3 que pueda acceder al APIC. Debe instalar la solicitud de módulos python y websocket-client.
• La secuencia de comandos se suscribirá a una clase de objeto específica que realiza un seguimiento de los tiempos de respuesta.

    Ubicación de Git para apic_query_subscription_slow.py —> https://wwwin-github.cisco.com/CX-ACI/lv_accloganalyzer

• Es necesario registrar la sesión de terminal en el servidor externo y alguien tendrá que verificar el terminal para asegurarse de que está recibiendo los datos constantemente.

python apic_query_subscription_slow.py -a <anyapicip> -u <username>

cargue el registro de sesión de terminal una vez cada 24 horas en el caso TAC 

Paso 3: Recopile las salidas del TAC y los registros de acceso para los registros de eventos y las consultas de API completas que llegan las últimas 24 horas todos los días a una hora determinada.

Para los Fabrics ACI que ejecutan versiones anteriores a la 5.3/6.0(3d), hay una secuencia de comandos Collect TacOutput disponible dentro del repositorio aci-tac-scripts que sirve a una interfaz similar como el comando trigger tacoutput:

apic# /tmp/collectTacOutputs.sh
Select corresponding numbers of objects to collect. Separate numbers with commas. *Note, topSystem, fabricNode, and firmwareARunning are automatically included.
Ex: 1,2,3,4,5
1. faultInfo *collected unfiltered
2. faultRecord
3. eventRecord
4. aaaModLR
5. polDeploymentRecord
6. epRecord
7. healthRecord
8. healthInst *collected unfiltered
Enter selections: 3
Enter record start date (format: 2019-12-15T00:00:00) *default is one month prior to current date: 2019-12-25T00:00:00
Enter record end date (format: 2019-12-15T00:00:00) *default is current date: 2020-01-05T00:00:00

...script collection runs...

Extraiga el archivo tacoutputxx.tgz y cárguelo en el caso

Nota: Para los fabric de ACI que ejecutan la versión 5.3/6.0(3d) y versiones posteriores, la salida de accionamiento proporciona una interfaz de recopilación simplificada para eventos, fallos, auditoría y otras salidas de resolución de problemas). No es necesario que utilice el guión.

## Desde cualquier APIC, .

mkdir /data/techsupport/apicname_srnumber
cd /var/log/dme/log
cp  access* /data/techsupport/apicname_srnumber
cd /data/techsupport/
tar -zcvfapicname_srnumber.tgz /data/techsupport/apicname_srnumber

upload adapicname_srnumber.tgz al caso

Ejemplo de laboratorio para la ejecución de scripts desde un host externo:

(my-virtual-env-3.7.13) root@aci-fab1-esxi2-oob:~# python apic_query_subscription_slowui.py -a 10.122.141.98 -u rgatti
Logging into APIC 10.122.141.98
rgatti password:
********** WebSocket Subscription URIS and IDs **********

WebSocket Subscription Status Code: 101

https://10.122.141.98/api/class/commRequestData.json?subscription=yes
- Subscription ID: 72059449487065089

********** WebSocket Subscription Messages **********
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.122.141.126","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-1","method":"GET","modTs":"2024-08-06T13:15:07.857-04:00","responseSize":"2313","responseTime":"1017","rn":"","startTime":"2024-08-06T13:12:38.334-04:00","status":"modified","url":"/api/node/class/firmwareOSource.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.26.164.186","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-2","method":"GET","modTs":"2024-08-06T13:15:07.857-04:00","responseSize":"252","responseTime":"1007","rn":"","startTime":"2024-08-06T13:13:39.145-04:00","status":"modified","url":"/api/node/mo/uni/infra/nodecfgcont/node-103.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.26.161.138","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-3","modTs":"2024-08-06T13:15:07.857-04:00","responseTime":"788","rn":"","startTime":"2024-08-06T13:14:24.351-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.24.131.101","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-4","modTs":"2024-08-06T13:15:07.857-04:00","responseTime":"784","rn":"","startTime":"2024-08-06T13:14:41.169-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.25.130.136","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-5","modTs":"2024-08-06T13:15:07.857-04:00","responseTime":"783","rn":"","startTime":"2024-08-06T13:12:29.028-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-1","modTs":"2024-08-06T13:15:51.533-04:00","responseSize":"3926","responseTime":"1013","rn":"","startTime":"2024-08-06T13:12:22.387-04:00","status":"modified","url":"/api/node/class/topSystem.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-2","modTs":"2024-08-06T13:15:51.533-04:00","responseSize":"905","responseTime":"208","rn":"","startTime":"2024-08-06T13:12:59.783-04:00","status":"modified","url":"/api/node/class/dnsProv.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-3","modTs":"2024-08-06T13:15:51.533-04:00","responseSize":"905","responseTime":"114","rn":"","startTime":"2024-08-06T13:10:59.781-04:00","status":"modified","url":"/api/node/class/dnsProv.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-4","modTs":"2024-08-06T13:15:51.533-04:00","responseSize":"905","responseTime":"98","rn":"","startTime":"2024-08-06T13:14:59.782-04:00","status":"modified","url":"/api/node/class/dnsProv.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-5","modTs":"2024-08-06T13:15:51.533-04:00","responseSize":"1075","responseTime":"46","rn":"","startTime":"2024-08-06T13:14:26.565-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-2/node-3/web/apiAvgResp/reqData-1","modTs":"2024-08-06T13:16:19.490-04:00","responseTime":"2392","rn":"","startTime":"2024-08-06T13:11:44.143-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-2/node-3/web/apiAvgResp/reqData-2","modTs":"2024-08-06T13:16:19.490-04:00","responseTime":"2389","rn":"","startTime":"2024-08-06T13:15:24.604-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-2/node-3/web/apiAvgResp/reqData-3","modTs":"2024-08-06T13:16:19.490-04:00","responseTime":"2384","rn":"","startTime":"2024-08-06T13:13:38.231-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-2/node-3/web/apiAvgResp/reqData-4","modTs":"2024-08-06T13:16:19.490-04:00","responseTime":"2384","rn":"","startTime":"2024-08-06T13:13:14.402-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-2/node-3/web/apiAvgResp/reqData-5","modTs":"2024-08-06T13:16:19.490-04:00","responseTime":"2383","rn":"","startTime":"2024-08-06T13:14:24.584-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.26.161.138","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-1","method":"POST","modTs":"2024-08-06T13:20:07.951-04:00","responseSize":"0","responseTime":"784","rn":"","startTime":"2024-08-06T13:19:24.361-04:00","status":"modified","url":"/uitelemetry/clicks"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.25.130.136","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-2","method":"POST","modTs":"2024-08-06T13:20:07.951-04:00","responseSize":"0","responseTime":"783","rn":"","startTime":"2024-08-06T13:18:34.821-04:00","status":"modified","url":"/uitelemetry/clicks"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.25.130.136","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-3","modTs":"2024-08-06T13:20:07.951-04:00","responseTime":"781","rn":"","startTime":"2024-08-06T13:17:03.705-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.25.130.136","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-4","modTs":"2024-08-06T13:20:07.951-04:00","responseTime":"781","rn":"","startTime":"2024-08-06T13:18:04.530-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"10.26.161.138","dn":"topology/pod-1/node-1/web/apiAvgResp/reqData-5","modTs":"2024-08-06T13:20:07.951-04:00","responseTime":"781","rn":"","startTime":"2024-08-06T13:18:24.354-04:00","status":"modified"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-1","modTs":"2024-08-06T13:20:51.568-04:00","responseSize":"905","responseTime":"1018","rn":"","startTime":"2024-08-06T13:16:59.784-04:00","status":"modified","url":"/api/node/class/dnsProv.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-2","modTs":"2024-08-06T13:20:51.568-04:00","responseSize":"405","responseTime":"148","rn":"","startTime":"2024-08-06T13:18:01.471-04:00","status":"modified","url":"/api/node/class/proxyServer.json"}}}]}
{"subscriptionId":["72059449487065089"],"imdata":[{"commRequestData":{"attributes":{"childAction":"","clientHostname":"192.168.1.1","dn":"topology/pod-1/node-2/web/apiAvgResp/reqData-3","modTs":"2024-08-06T13:20:51.568-04:00","responseSize":"3390","responseTime":"112","rn":"","startTime":"2024-08-06T13:17:29.488-04:00","status":"modified","url":"/api/node/class/pkiFabricSelfCAEp.json"}}}]}

Opción 2. Guión a demanda

En APIC CLI

bash
<paste the below directly on the APIC cli - modify the filename. The script will run for 1 hr>

let i=1
while [ $i -lt 60 ]
do
date
date >> /data/techsupport/commRequestData.txt
moquery -c commRequestData >> /data/techsupport/commRequestData_<date_time>.txt
sleep 60
let i=i+1
done

El resultado no es fácil de leer, que se puede aplicar como un masaje usando el siguiente script en LV.

Ubicación de Git para commrequests_processing.py —> https://wwwin-github.cisco.com/CX-ACI/lv_accloganalyzer
Copie la secuencia de comandos en la carpeta de secuencias de comandos local (por ejemplo, /users/rgatti/scripts).

Cómo ejecutar:

users/rgatti/dnld_695998256/cv1/jul14_2025/commrequestdata --> This is where we saved the commRequestData_<date_time>.txt file
python3 /users/rgatti/scripts/commrequests_processing.py -f commRequestData_jul14_4pm.txt > commRequestData_jul14_4pm.txt.formatted

Ejemplo: responseTime se utiliza para ordenar con el tiempo de respuesta más alto mostrado en la parte superior

rgatti@aci-logviewer2:~/dnld_695998256/cv1/jul14_2025/commrequestdata$ less commRequestData_jul14_4pm.txt.formatted 
Processing file: commRequestData_jul14_4pm.txt
 
clientHostname | dn                                              | method | responseCode | responseSize | responseTime | startTime                     | url                                                                                
---------------+-------------------------------------------------+--------+--------------+--------------+--------------+-------------------------------+------------------------------------------------------------------------------------
127.0.0.1      | topology/pod-2/node-5/web/apiAvgResp/reqData-1  | GET    | 200          | 14255310     | 31123        | 2025-07-14T15:08:38.598-05:00 | /api/class/fvRInfoHolder.json                                                      
127.0.0.1      | topology/pod-2/node-5/web/apiAvgResp/reqData-1  | GET    | 200          | 14255310     | 31123        | 2025-07-14T15:08:38.598-05:00 | /api/class/fvRInfoHolder.json                                                      
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-1  | GET    | 200          | 17050        | 29660        | 2025-07-14T15:08:39.262-05:00 | /api/node/class/fabricPathEp.json                                                  
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-2  | GET    | 200          | 111529       | 29658        | 2025-07-14T15:08:39.261-05:00 | /api/class/mgmtRsInBStNode.json                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-3  | GET    | 200          | 474          | 29631        | 2025-07-14T15:08:39.258-05:00 | /api/class/mgmtInstP.json                                                          
127.0.0.1      | topology/pod-2/node-4/web/apiAvgResp/reqData-1  | GET    | 200          | 13637        | 28933        | 2025-07-14T15:08:38.597-05:00 | /api/class/faultDelegate.json                                                      
127.0.0.1      | topology/pod-2/node-2/web/apiAvgResp/reqData-2  | GET    | 200          | 530          | 28243        | 2025-07-14T15:08:39.274-05:00 | /api/class/vzRsDenyRule.json                                                       
127.0.0.1      | topology/pod-2/node-2/web/apiAvgResp/reqData-1  | GET    | 200          | 30           | 28243        | 2025-07-14T15:08:39.273-05:00 | /api/class/fvRsProtBy.json                                                         
127.0.0.1      | topology/pod-2/node-2/web/apiAvgResp/reqData-2  | GET    | 200          | 530          | 28243        | 2025-07-14T15:08:39.274-05:00 | /api/class/vzRsDenyRule.json                                                       
127.0.0.1      | topology/pod-2/node-2/web/apiAvgResp/reqData-1  | GET    | 200          | 30           | 28243        | 2025-07-14T15:08:39.273-05:00 | /api/class/fvRsProtBy.json                                                         
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-1  | GET    | 200          | 18426168     | 27107        | 2025-07-14T15:40:33.874-05:00 | /api/mo/uni.xml                                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-1  | GET    | 200          | 18426168     | 27107        | 2025-07-14T15:40:33.874-05:00 | /api/mo/uni.xml                                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-4  | GET    | 200          | 18429959     | 25516        | 2025-07-14T15:08:46.841-05:00 | /api/mo/uni.xml                                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-2  | GET    | 200          | 719780       | 24794        | 2025-07-14T15:40:35.346-05:00 | /api/class/fabricPathEp.json                                                       
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-2  | GET    | 200          | 719780       | 24794        | 2025-07-14T15:40:35.346-05:00 | /api/class/fabricPathEp.json                                                       
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-5  | GET    | 200          | 18431710     | 24604        | 2025-07-14T15:08:56.167-05:00 | /api/mo/uni.xml                                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-3  | GET    | 200          | 452          | 23720        | 2025-07-14T15:40:36.395-05:00 | /api/class/mgmtOoB.json                                                            
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-3  | GET    | 200          | 452          | 23720        | 2025-07-14T15:40:36.395-05:00 | /api/class/mgmtOoB.json                                                            
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-6  | GET    | 200          | 18430138     | 23578        | 2025-07-14T15:08:49.945-05:00 | /api/mo/uni.xml                                                                    
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-1  | GET    | 200          | 14255310     | 21159        | 2025-07-14T15:38:59.233-05:00 | /api/class/fvRInfoHolder.json                                                      
127.0.0.1      | topology/pod-2/node-1/web/apiAvgResp/reqData-1  | GET    | 200          | 14255310     | 21159        | 2025-07-14T15:38:59.233-05:00 | /api/class/fvRInfoHolder.json                                                

Consideraciones sobre el uso de API APIC

Punteros generales para garantizar que un script no dañe a Nginx

• Cada APIC ejecuta su propio NGINX DME.
  • Solo el NGINX de APIC 1 procesa las solicitudes al APIC 1. El NGINX de APIC 2 y 3 no procesa esas solicitudes.
• En general, más de 40 solicitudes de API por segundo durante un largo período de tiempo debilita al NGINX.
  
  • Si lo encuentra, reduzca la agresividad de las solicitudes.
  • Si el host de solicitudes no se puede modificar, considere Límites de velocidad NGINX en el APIC.

Abordar las ineficiencias de scripts

• No inicie/cierre sesión antes de cada solicitud de API.
  • El tiempo de espera predeterminado para un inicio de sesión es de 10 minutos. Esta misma sesión se puede utilizar para varias solicitudes y se puede actualizar para ampliar el tiempo de validez.
  • Consulte Guía de configuración de la API REST de Cisco APIC: acceso a la API REST: autenticación y mantenimiento de una sesión de API.
• Si la secuencia de comandos consulta muchos DN que comparten un elemento primario, en lugar de contraer las consultas en una única consulta primaria lógica con filtros de consulta.
  
  • Consulte Guía de configuración de la API REST de Cisco APIC - Redacción de consultas de la API REST - Aplicación de filtros de ámbito de consulta.
• Si necesita actualizaciones de un objeto o clase de objeto, considere las suscripciones de websocket en lugar de las solicitudes rápidas de API.

Acelerador de solicitud NGINX

Disponible en 4.2(1)+, un usuario puede habilitar el acelerador de solicitudes contra HTTP y HTTPS de forma independiente.

Nota: a partir de la versión 6.1(2) de ACI, la velocidad máxima admitida para esta función se redujo a 40 solicitudes por segundo (r/s) o a 2400 solicitudes por minuto (r/m) desde 10 000 r/m.

Fabric - Políticas de fabric - Carpeta de políticas - Carpeta de acceso a la gestión - predeterminada

Cuando está habilitado:

• NGINX se reinicia para aplicar los cambios del archivo de configuración
  • Una nueva zona, httpsClientTagZone, se escribe en nginx config
• La velocidad del acelerador se puede establecer en Solicitudes por minuto (r/m) o Solicitudes por segundo (r/s).
• El acelerador de solicitudes se basa en la implementación de límite de velocidad incluida en NGINX
  • Las solicitudes de API contra /api/ URI utilizan la velocidad del acelerador definida por el usuario + burst= (velocidad del acelerador x 2) + nodelay
    • Hay un acelerador no configurable (zone aaaApiHttps) para /api/aaaLogin y /api/aaaRefresh que limita la velocidad a 2r/s + ráfaga=4 + nodelay
  • El seguimiento del acelerador de solicitudes se realiza por dirección IP de cliente
  • Las solicitudes de API que se originan en el APIC de IP automática (UI + CLI) omiten el acelerador
  • Cualquier dirección IP de cliente que cruce el umbral de velocidad + ráfaga definido por el usuario recibe una respuesta 503 del APIC
  • Estos 503 se pueden correlacionar dentro de los registros de acceso
  • error.log tendrá entradas que indican cuándo se ha activado la regulación (zona httpsClientTagZone) y contra qué hosts del cliente

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.