Wie behebe ich ein Problem bei der Erhöhung der TargetResponseTime-Metrik für einen Application Load Balancer?

Kurzbeschreibung

TargetResponseTime ist die Zeit in Sekunden, die zwischen dem Zeitpunkt, an dem die Anforderung den Load Balancer verlässt, und dem Zeitpunkt, an dem eine Antwort vom Ziel empfangen wird, verstrichen ist. Dies entspricht dem Feld target_processing_time in den Zugriffsprotokollen des Application Load Balancer.

Mögliche Ursachen für eine Erhöhung der TargetResponseTime sind:

• Die Hosts befinden sich in einem fehlerhaften Zustand.
• Die Backend-Instances werden von zu vielen Anfragen überfordert.
• Die CPU-Auslastung der Backend-Instances ist hoch.
• Eines oder mehrere der Ziele sind fehlerhaft.
• Es gibt Probleme mit Webanwendungsabhängigkeiten, die auf Backend-Instances ausgeführt werden.

Auflösung

Die Hosts befinden sich in einem fehlerbehafteten Zustand.

Stellen Sie sicher, dass alle Ziele des Application Load Balancer fehlerfrei sind. Siehe Wie behebe ich Fehler bei Zustandsprüfungen für Application Load Balancers?

Die Backend-Instances werden von zu vielen Anfragen überfordert.

Überprüfen Sie die Summenstatistik der Amazon CloudWatch RequestCount- und ActiveConnectionCount-Metriken für Ihren Application Load Balancer. Eine Summenerhöhung, die mit der Erhöhung von TargetResponseTime zusammenfällt, kann darauf hinweisen, dass die Backend-Instances durch die Anforderungslast überfordert sind.

Um dieses Problem zu lösen, konfigurieren Sie eine Auto-Scaling-Gruppe für Ihre Backend-Instances. Siehe Tutorial Einrichten einer automatisch skalierten Anwendung mit Lastausgleich.

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

Überprüfen Sie die CloudWatch-CPU-Auslastungsmetrik Ihrer Backend-Instances. Wenn die CPU-Auslastung hoch ist oder die Auslastung zunimmt, führen Sie ein Upgrade Ihrer Instances auf einen größeren Instance-Typ durch.

Eines oder mehrere Ziele sind fehlerhaft.

Gehen Sie folgendermaßen vor, um das Problem zu lösen, wenn Sie fehlerhafte Ziele haben:

1.    Aktivieren Sie die Zugriffsprotokollierung für Ihren Load Balancer.

2.    Laden Sie die Zugriffsprotokolle für den Zeitraum herunter, in dem die TargetResponseTime hoch ist. Um beispielsweise die Zugriffsprotokolle zwischen 2022-02-01T 03:00 und 2022-02-01T 03:35 mit der AWS-Befehlszeilenschnittstelle (AWS-CLI) herunterzuladen:

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

Hinweis: Ersetzen Sie bucket-name durch den Namen Ihres Buckets, aws-account-id durch die ID Ihres AWS-Kontos und Region durch die AWS-Region, in der sich Ihr Konto befindet.

3.    Verwenden Sie Befehlszeilen-Tools, um die Zugriffsprotokolle zu analysieren:

Elastic Load Balancing (ELB)-Zugriffsprotokolle werden in einem .gzip-Format komprimiert.

Optionaler Schritt: Verwenden Sie den folgenden Befehl, um die Protokolle zu extrahieren:

$   gzip -dr ./alblogs

Beispielszenarien

Führen Sie den folgenden Befehl aus, um die maximale Latenz für target_processing_time zu erhalten.

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}'

-oder-

Um die Anzahl der Anforderungen zu zählen, die eine target_processing_time „>=N“ Sekunden pro Ziel haben, modifizieren Sie N mit der Anzahl der Sekunden für Ihre Anforderungen.

Beispielbefehl für eine komprimierte Protokolldatei:

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

Beispielbefehl für eine 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

Im vorherigen Beispiel ist das Ziel mit der IP-Adresse 10.3.19.141 für den größten Teil der Erhöhung von TargetResponseTime verantwortlich. Überprüfen Sie in diesem Fall das Betriebssystem und die Webanwendung für das Ziel.

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

Führen Sie eine Paketerfassung auf dem Ziel durch, um die Verzögerung der Zielantwort zu ermitteln. Verwenden Sie für Linux OS tcpdump.

So erfassen Sie eine vollständige ein- und ausgehende POST-HTTP-Übertragung, einschließlich HTTP-Anfrage und -Antwort auf Port TCP/80:

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'

So erfassen Sie eine vollständige eingehende und ausgehende GET-HTTP-Übertragung, einschließlich HTTP-Anfrage und -Antwort auf Port TCP/80:

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'

Beispiel-Ausgaben:

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. Sie können X-Amzn-Trace-Id: Root verwenden, um diesen Datensatz in den Zugriffsprotokollen nachzuverfolgen.

Beispielbefehl für eine komprimierte Protokolldatei:

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

Beispielbefehl für eine unkomprimierte Protokolldatei:

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

Beispielausgabe:

0.008 9.002 0.000

---