Resolución
TargetResponseTime equivale al campo target_processing_time de los registros de acceso del equilibrador de carga de aplicación.
Los siguientes problemas pueden provocar un aumento en la métrica TargetResponseTime.
Los hosts no funcionan correctamente
Para resolver los destinos del equilibrador de carga de aplicación que no funcionan correctamente, consulta ¿Cómo soluciono los errores en las comprobaciones de estado de los equilibradores de carga de aplicación?
Las instancias de backend se ven sobrecargadas por el exceso de solicitudes
Consulta la estadística de suma de las métricas RequestCount y ActiveConnectionCount de Amazon CloudWatch para el equilibrador de carga de aplicación. Si la suma aumenta con el aumento de TargetResponseTime, es posible que demasiadas solicitudes sobrecarguen las instancias de backend.
Para resolver este problema, configura un grupo de escalamiento automático para las instancias de backend. Para obtener más información, consulta Tutorial: Configuración de una aplicación escalada y con carga equilibrada.
Hay un alto uso de la CPU en las instancias de backend
Comprueba la métrica CPUUtilization de CloudWatch en relación con las instancias de backend. Si el uso de la CPU es alto o hay un aumento en el uso, actualiza las instancias a un tipo de instancia más grande.
Un destino está defectuoso
Si tienes destinos defectuosos, sigue los siguientes pasos:
- Activa los registros de acceso del equilibrador de carga.
- Descarga los registros de acceso para el intervalo de tiempo en el que TargetResponseTime es alto. Por ejemplo, para descargar los registros de acceso entre las 03:00 del 2022-02-01T y las 03:35 del 2022-02-01T, ejecuta el siguiente comando:
aws s3 cp s3://bucket-name[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/2022/02/01/ ./alblogs --recursive --exclude "*" --include "*20220201T03[0123]*"
Nota: Sustituye bucket-name por el nombre de tu bucket, aws-account-id por el ID de tu cuenta de AWS y region por la región de AWS en la que se encuentra la cuenta.
Después de descargar los registros de acceso, ejecuta los siguientes comandos para analizarlos.
Registros de acceso a ELB
Los registros de acceso de Elastic Load Balancing (ELB) se comprimen en formato .gzip. Para extraer los registros, ejecuta el siguiente comando:
gzip -dr ./alblogs
Latencia máxima
Para obtener la latencia máxima de target_processing_time, ejecuta uno de los siguientes comandos.
Archivo de registro comprimido:
zcat *.log.gz | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'
Archivo de registro sin comprimir:
cat *.log | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'
Recuento del número de solicitudes
Para contar el número de solicitudes que tienen target_processing_time ">=N" segundos por destino, modifica N con el número de segundos según tus requisitos. Ejecuta uno de los siguientes comandos.
Archivo de registro comprimido:
zcat *.log.gz | awk '{if($7 >= N){print $5}}' | sort | uniq -c
Archivo de registro sin comprimir:
cat *.log | awk '{if($7 >= N){print $5}}' | sort | uniq -c
Resultado de ejemplo:
12 10.10.20.111:80 12 10.10.60.163:80
254 10.10.70.7:80
6 10.10.80.109:80
20656 10.3.19.141:80
En el resultado del ejemplo anterior, el destino con la dirección IP 10.3.19.141 es responsable de la mayor parte del aumento de TargetResponseTime. En este caso, comprueba el sistema operativo (OS) y la aplicación web del destino.
Hay problemas con las dependencias de las aplicaciones web que se ejecutan en instancias de backend
Para identificar el retraso en la respuesta del destino, ejecuta una captura de paquetes en el destino. Para el sistema operativo Linux, utiliza tcpdump.
Para capturar una transmisión HTTP POST entrante y saliente completa que incluya la solicitud y la respuesta HTTP en el puerto TCP/80, ejecuta el siguiente comando:
tcpdump -i any -ns 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F'
Para capturar una transmisión HTTP GET entrante y saliente completa que incluya la solicitud y la solicitud HTTP en el puerto TCP/80, ejecuta el siguiente comando:
tcpdump -i any -ns 0 -A 'tcp dst port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F'
Ejemplos de salidas:
14:04:12.186593 IP 10.10.30.219.13000 > 10.10.60.10.http: Flags [P.], seq 641705534:641705793, ack 1587610435, win 106, options [nop,nop,TS val 1165674323 ecr 263805247],
length 259: HTTP: GET / HTTP/1.1 E..7."@...I. .. < 2..P&?.>^..C...j9...... Ez.S..Y?GET / HTTP/1.1 X-Forwarded-For: 54.66.76.204 X-Forwarded-Proto: http X-Forwarded-Port: 80 Host: labalbinternet-1236602672.ap-southeast-2.elb.amazonaws.com
X-Amzn-Trace-Id: Root=1-6254355c-15db4904726649b66a1e47d7 User-Agent: curl/7.79.1 Accept: */* ................
14:04:21.187892 IP 10.10.60.10.http > 10.10.30.219.13000: Flags [P.], seq 1:592, ack 259, win 488, options [nop,nop,TS val 263814250
ecr 1165674323], length 591: HTTP: HTTP/1.1 200 OK E...\.@.@.l. < ...P2.^..C&?.A....qn..... ..|jEz.SHTTP/1.1 200 OK Date: Mon, 11 Apr 2022 14:04:12 GMT Server: Apache/2.4.52 () OpenSSL/1.0.2k-fips X-Powered-By: PHP/7.2.34 Upgrade: h2,h2c
Connection: Upgrade Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 159 PHP file name: /index.php<br> ................
Nota: En los resultados del ejemplo anterior, HTTP GET responde a las 14:04:12 y el destino responde a las 14:04:21. TargetResponseTime es de aproximadamente 9 segundos. Para rastrear el registro en los registros de acceso, utiliza X-Amzn-Trace-Id: Root.
Para un archivo de registro comprimido, ejecuta el siguiente comando:
zcat *.log.gz | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'
Para un archivo de registro sin comprimir, ejecuta el siguiente comando:
cat *.log | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'
Resultado de ejemplo:
0.008 9.002 0.000