Wie behebe ich einen Anstieg der TargetResponseTime-Metrik für einen Application Load Balancer?

Lösung

TargetResponseTime entspricht dem Feld target_processing_time in den Zugriffsprotokollen von Application Load Balancer.

Die folgenden Probleme können zu einer Erhöhung der TargetResponseTime-Metrik führen.

Die Hosts sind fehlerhaft

Informationen zur Behebung fehlerhafter Ziele von Application Load Balancer findest du unter So behebt man fehlgeschlagene Zustandsprüfungen für den Application Load Balancer

Die Backend-Instances werden von zu vielen Anforderungen überfordert

Überprüfe die Sum-Statistik der Amazon-CloudWatch-Metriken RequestCount und ActiveConnectionCount für den Application Load Balancer. Wenn die Summe mit dem Anstieg von TargetResponseTime zunimmt, überfordern möglicherweise zu viele Anforderungen die Backend-Instances.

Um dieses Problem zu beheben, konfiguriere eine Auto-Scaling-Gruppe für die Backend-Instances. Weitere Informationen findest du unter Tutorial: Richte eine Anwendung mit Skalierung und Load Balancing ein.

Es gibt eine hohe CPU-Auslastung auf den Backend-Instances

Überprüfe die CloudWatch-Metrik CPUUtilization der Backend-Instances. Wenn die CPU-Auslastung hoch ist oder es zu einem Anstieg der Auslastung kommt, führe ein Upgrade der Instances auf einen größeren Instance-Typ durch.

Ein Ziel ist fehlerhaft

Wenn bei dir fehlerhafte Ziele auftreten, führe die folgenden Schritte aus:

1. Aktiviere die Zugriffsprotokolle für den Load Balancer.
2. Lade die Zugriffsprotokolle für den Zeitraum herunter, in dem TargetResponseTime hoch ist. Um beispielsweise die Zugriffsprotokolle zwischen 2022-02-01T03:00 und 2022-02-01T03:35 herunterzuladen, führe den folgenden Befehl aus:

   aws s3 cp s3://bucket-name[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/2022/02/01/ ./alblogs --recursive --exclude "*" --include "*20220201T03[0123]*"

   Hinweis: Ersetze bucket-name durch den Namen des Buckets, aws-account-id durch die ID des AWS-Kontos und region durch die AWS-Region, in der sich dein Konto befindet.

Nachdem du die Zugriffsprotokolle heruntergeladen hast, führe die folgenden Befehle aus, um die Protokolle zu analysieren.

ELB-Zugriffsprotokolle

Elastic Load Balancing (ELB)-Zugriffsprotokolle werden im GZIP-Format komprimiert. Führe den folgenden Befehl aus, um die Protokolle zu extrahieren:

gzip -dr ./alblogs

Maximale Latenz

Führe einen der folgenden Befehle aus, um die maximale Latenz für target_processing_time zu ermitteln.

Komprimierte Protokolldatei:

zcat *.log.gz | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'

Unkomprimierte Protokolldatei:

cat *.log | awk '$7 != -1' | awk 'BEGIN{a=0}{if ($7>0+a) a=$7} END{print a}'

Die Anzahl der Anforderungen zählen

Um die Anzahl der Anforderungen zu zählen, die eine target_processing_time „>=N“ Sekunden pro Ziel haben, ändere N in die Anzahl der Sekunden, wie erforderlich. Führe einen der folgenden Befehle aus.

Komprimierte Protokolldatei:

zcat *.log.gz | awk '{if($7 >= N){print $5}}' | sort | uniq -c

Unkomprimierte Protokolldatei:

cat *.log | awk '{if($7 >= N){print $5}}' | sort | uniq -c

Beispielausgabe:

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

In der vorherigen Beispielausgabe ist das Ziel mit der IP-Adresse 10.3.19.141 für den Großteil des Anstiegs von TargetResponseTime verantwortlich. Überprüfe in diesem Fall das Betriebssystem (OS) und die Webanwendung für das Ziel.

Es gibt Probleme mit Webanwendungsabhängigkeiten, die auf Backend-Instances ausgeführt werden

Führe eine Paketerfassung auf dem Ziel durch, um die Verzögerung bei der Zielantwort zu ermitteln. Verwende bei Linux-Betriebssystemen tcpdump.

Führe den folgenden Befehl aus, um eine vollständige eingehende und ausgehende POST-HTTP-Übertragung zu erfassen, die die HTTP-Anforderung und -Antwort auf Port TCP/80 umfasst:

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'

Führe den folgenden Befehl aus, um eine vollständige eingehende und ausgehende GET-HTTP-Übertragung zu erfassen, die die HTTP-Anforderung und -Antwort auf Port TCP/80 umfasst:

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'

Beispielausgaben:

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

Hinweis: In den vorherigen Beispielausgaben reagiert GET-HTTP um 14:04:12 und das Ziel um 14:04:21. Die TargetResponseTime beträgt ungefähr 9 Sekunden. Um den Datensatz in den Zugriffsprotokollen zu verfolgen, verwende X-Amzn-Trace-Id: Root.

Führe für eine komprimierte Protokolldatei den folgenden Befehl aus:

zcat *.log.gz | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'

Führe für eine unkomprimierte Protokolldatei den folgenden Befehl aus:

cat *.log | awk '{if($20 ~ "1-6254355c-15db4904726649b66a1e47d7"){print $6,$7,$8 }}'

Beispielausgabe:

0.008 9.002 0.000