Fehlerbehebung bei verwalteten Lambda-Instanzen - AWS Lambda
Probleme bei der Drosselung und SkalierungProbleme mit der ParallelitätLeistungsproblemeProbleme mit dem KapazitätsanbieterProbleme bei der Überwachung und BeobachtbarkeitWeitere HilfeNächste Schritte

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung bei verwalteten Lambda-Instanzen

Probleme bei der Drosselung und Skalierung

Hohe Fehlerraten bei der Skalierung

Problem: Es treten Drosselungsfehler (HTTP 429) auf, wenn der Traffic schnell zunimmt.

Ursache: Lambda Managed Instances werden asynchron auf der Grundlage der CPU-Ressourcenauslastung und der Mehrparallelität skaliert. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, wenn Lambda Instances und Ausführungsumgebungen entsprechend der Nachfrage skaliert.

Lösung:

  • Passen Sie die Zielressourcenauslastung an: Wenn Ihr Workload vorhersehbare Verkehrsmuster aufweist, legen Sie eine niedrigere Zielressourcenauslastung fest, um zusätzlichen Spielraum für Datenverkehrsspitzen zu haben.

  • Kapazität vor der Erwärmung: Erhöhen Sie den Datenverkehr bei einem geplanten Anstieg des Datenverkehrs über einen längeren Zeitraum schrittweise, damit die Skalierung Schritt halten kann.

  • Überwachen Sie die Skalierungsmetriken: Verfolgen Sie die Messwerte für Drosselungsfehler, um den Grund für Drosselungen und Probleme mit der Kapazitätsskalierung zu verstehen.

  • Überprüfen Sie die Funktionskonfiguration: Stellen Sie sicher, dass Ihre Funktionsspeicher- und vCPU-Einstellungen mehrere gleichzeitige Ausführungen unterstützen. Erhöhen Sie bei Bedarf die Funktionsspeicher- oder vCPU-Zuweisung.

Langsames Herunterskalieren

Problem: Es dauert lange, bis Instances herunterskaliert werden, nachdem der Traffic zurückgegangen ist.

Ursache: Lambda Managed Instances werden schrittweise herunterskaliert, um die Verfügbarkeit aufrechtzuerhalten und schnelle Kapazitätsänderungen zu vermeiden, die sich auf die Leistung auswirken könnten.

Lösung:

Dieses Verhalten wird erwartet. Lambda skaliert Instanzen konservativ herunter, um Stabilität zu gewährleisten. Überwachen Sie Ihre CloudWatch Metriken, um die Anzahl der laufenden Instanzen zu verfolgen.

Probleme mit der Parallelität

Bei Ausführungsumgebungen mit geringer Parallelität kommt es zu Drosselungen

Problem: Ihre Funktionen werden trotz verfügbarer Kapazität gedrosselt.

Ursache: Ausführungsumgebungen mit sehr niedriger maximaler Parallelität können Schwierigkeiten haben, effektiv zu skalieren. Lambda Managed Instances sind für Anwendungen mit mehreren gleichzeitigen Vorgängen konzipiert.

Lösung:

  • Erhöhen Sie die maximale Parallelität: Wenn Ihre Funktionsaufrufen nur sehr wenig CPU verbrauchen, erhöhen Sie die Einstellung für maximale Parallelität auf 64 pro vCPU.

  • Funktionscode optimieren: Überprüfen Sie Ihren Funktionscode, um den CPU-Verbrauch pro Aufruf zu reduzieren und so eine höhere Parallelität zu ermöglichen.

  • Passen Sie den Funktionsspeicher und die vCPU an: Stellen Sie sicher, dass Ihre Funktion über ausreichende Ressourcen verfügt, um mehrere gleichzeitige Aufrufe zu verarbeiten.

Probleme mit der Thread-Sicherheit (Java-Laufzeit)

Problem: Ihre Java-Funktion erzeugt falsche Ergebnisse oder es treten unter Last Rennbedingungen auf.

Ursache: Mehrere Threads führen die Handler-Methode gleichzeitig aus, und der gemeinsame Status ist nicht threadsicher.

Lösung:

  • Verwenden Sie AtomicInteger or AtomicLong für Zähler anstelle von primitiven Typen

  • Ersetze durch HashMap ConcurrentHashMap

  • Zum Collections.synchronizedList() Einwickeln verwenden ArrayList

  • Wird ThreadLocal für einen anforderungsspezifischen Status verwendet

  • Greifen Sie IDs vom Lambda Context-Objekt aus auf die Ablaufverfolgung zu, nicht über Umgebungsvariablen

Eine ausführliche Anleitung finden Sie in der Dokumentation Java Runtime for Lambda Managed Instances.

Probleme mit der Statusisolierung (Laufzeit von Node.js)

Problem: Ihre Funktion Node.js gibt Daten aus verschiedenen Anfragen zurück oder es kommt zu Datenbeschädigungen.

Ursache: Globale Variablen werden von mehreren gleichzeitigen Aufrufen desselben Worker-Threads gemeinsam genutzt. Wenn asynchrone Operationen die Kontrolle übernehmen, können andere Aufrufe den gemeinsamen Status ändern.

Lösung:

  • Installation und Verwendung @aws/lambda-invoke-store für alle anforderungsspezifischen Zustände

  • Ersetzen Sie globale Variablen durch und InvokeStore.set() InvokeStore.get()

  • Verwenden Sie eindeutige Dateinamen in /tmp mit Anfrage IDs

  • Access Trace IDs mit Umgebungsvariablen InvokeStore.getXRayTraceId() anstelle von Umgebungsvariablen

Eine ausführliche Anleitung finden Sie in der Dokumentation Node.js Runtime for Lambda Managed Instances.

Dateikonflikte (Python-Laufzeit)

Problem: Ihre Python-Funktion liest falsche Daten aus Dateien in/tmp.

Ursache: Das /tmp Verzeichnis wird von mehreren Prozessen gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen.

Lösung:

  • Verwenden Sie bei Anfrage IDs eindeutige Dateinamen: /tmp/request_{context.request_id}.txt

  • Verwenden Sie das Sperren von Dateien mit fcntl.flock() für gemeinsam genutzte Dateien

  • Bereinigen Sie temporäre Dateien mit „os.remove()Nach dem Gebrauch“

Eine ausführliche Anleitung finden Sie in der Dokumentation zur Python-Laufzeit für Lambda Managed Instances.

Leistungsprobleme

Hohe Speicherauslastung

Problem: Bei Ihren Funktionen kommt es zu hoher Speicherauslastung oder zu out-of-memory Fehlern.

Ursache: Jede gleichzeitige Anforderung in Python wird in einem separaten Prozess mit eigenem Speicherplatz ausgeführt. Die gesamte Speichernutzung entspricht dem Speicher pro Prozess multipliziert mit gleichzeitigen Prozessen.

Lösung:

  • Überwachen Sie die Metrik in MemoryUtilization CloudWatch

  • Reduzieren Sie die MaxConcurrency Einstellung, wenn sich die Speichernutzung dem Speicherlimit der Funktion nähert

  • Erhöhen Sie die Speicherzuweisung für Funktionen, um eine höhere Parallelität zu unterstützen

  • Optimieren Sie die Speichernutzung, indem Sie Daten bei Bedarf statt während der Initialisierung laden

Inkonsistente Leistung

Problem: Die Funktionsleistung variiert zwischen Aufrufen erheblich.

Ursache: Lambda kann je nach Verfügbarkeit unterschiedliche Instanztypen auswählen, oder Funktionen werden möglicherweise auf Instanzen mit unterschiedlicher Ressourcenverfügbarkeit ausgeführt.

Lösung:

  • Zulässige Instanztypen angeben: Wenn Sie bestimmte Leistungsanforderungen haben, konfigurieren Sie zulässige Instance-Typen in Ihrem Kapazitätsanbieter, um die Instance-Typen einzuschränken, die Lambda auswählen kann.

  • Überwachen Sie Metriken auf Instanzebene: Verfolgen Sie CPUUtilization und verfolgen Sie sie MemoryUtilization auf Ebene des Kapazitätsanbieters, um Ressourcenbeschränkungen zu identifizieren.

  • Überprüfen Sie vCPUAvailable die Kapazitätskennzahlen: Stellen Sie sicherMemoryAvailable, dass auf Ihren Instances ausreichend Ressourcen verfügbar sind.

Probleme mit dem Kapazitätsanbieter

Die Funktionsversion kann nicht AKTIV werden

Problem: Ihre Funktionsversion befindet sich nach der Veröffentlichung weiterhin im Status „Ausstehend“.

Ursache: Lambda startet Managed Instances und startet Ausführungsumgebungen. Dieser Vorgang benötigt Zeit, insbesondere bei der ersten Funktionsversion eines neuen Kapazitätsanbieters.

Lösung:

Warten Sie, bis Lambda den Initialisierungsprozess abgeschlossen hat. Lambda startet standardmäßig drei Instances aus Gründen der AZ-Resilienz und startet drei Ausführungsumgebungen, bevor Ihre Funktionsversion als AKTIV markiert wird. Dies dauert in der Regel mehrere Minuten.

Der Kapazitätsanbieter kann nicht gelöscht werden

Problem: Beim Versuch, einen Kapazitätsanbieter zu löschen, wird eine Fehlermeldung angezeigt.

Ursache: Sie können keinen Kapazitätsanbieter löschen, an den Funktionsversionen angehängt sind.

Lösung:

  1. Identifizieren Sie mit der ListFunctionVersionsByCapacityProvider API alle Funktionsversionen, die den Kapazitätsanbieter verwenden.

  2. Löschen oder aktualisieren Sie diese Funktionsversionen, um die Zuordnung des Kapazitätsanbieters zu entfernen.

  3. Versuchen Sie erneut, den Kapazitätsanbieter zu löschen.

Generische Fehlermeldungen bei der Veröffentlichung von Funktionen

Problem: Beim Veröffentlichen von Funktionen treten generische Fehlermeldungen wie „Beim Publizieren ist ein interner Fehler aufgetreten“ auf.

Lösung:

  • Überprüfen Sie die IAM-Berechtigungen: Stellen Sie sicher, dass Sie über die entsprechenden lambda:PassCapacityProvider Berechtigungen für den Kapazitätsanbieter verfügen, den Sie verwenden möchten.

  • Überprüfen Sie die Konfiguration des Kapazitätsanbieters: Stellen Sie mithilfe der GetCapacityProvider API sicher, dass sich Ihr Kapazitätsanbieter im Status AKTIV befindet.

  • Überprüfen Sie die VPC-Konfiguration: Stellen Sie sicher, dass die in Ihrem Kapazitätsanbieter angegebenen Subnetze und Sicherheitsgruppen korrekt konfiguriert und zugänglich sind.

  • AWS CloudTrail Protokolle überprüfen: In den CloudTrail Protokollen finden Sie detaillierte Fehlerinformationen zu dem fehlgeschlagenen Vorgang.

Probleme bei der Überwachung und Beobachtbarkeit

Fehlende Metriken CloudWatch

Problem: Sie sehen keine erwarteten Kennzahlen CloudWatch für Ihren Kapazitätsanbieter oder Ihre Funktionen.

Ursache: Metriken werden in Intervallen von 5 Minuten veröffentlicht. Bei neuen Kapazitätsanbietern oder Funktionen sind Metriken möglicherweise nicht sofort verfügbar.

Lösung:

Warten Sie nach der Veröffentlichung einer Funktionsversion mindestens 5-10 Minuten, bevor Sie erwarten, dass Metriken in angezeigt werden CloudWatch. Vergewissern Sie sich, dass Sie sich den richtigen Namespace (AWS/Lambda) und die richtigen Dimensionen (CapacityProviderNameFunctionName, oderInstanceType) ansehen.

Protokolle können nicht gefunden CloudWatch werden

Problem: Ihre Funktion wird erfolgreich ausgeführt, aber Sie können keine CloudWatch Protokolle in Logs finden.

Ursache: Lambda Managed Instances werden in Ihrer VPC ausgeführt und benötigen Netzwerkkonnektivität, um Protokolle an Logs zu CloudWatch senden. Ohne die richtige VPC-Konnektivitätskonfiguration können Ihre Funktionen den Endpunkt des CloudWatch Logs-Dienstes nicht erreichen.

Lösung:

Konfigurieren Sie die VPC-Konnektivität, damit Ihre Funktionen CloudWatch Protokolle an Logs senden können. Sie haben drei Möglichkeiten:

Option 1: VPC-Endpunkt für CloudWatch Logs (für die Produktion empfohlen)

  1. Öffnen Sie die Amazon VPC-Konsole unter console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Endpunkte aus.

  3. Wählen Sie Endpunkt erstellen aus.

  4. Wählen Sie bei Service category (Servicekategorie) die Option AWS services (-Services) aus.

  5. Wählen Sie als Servicename die Option (durch Ihre Region ersetzen) aus. com.amazonaws.region.logs region AWS

  6. Wählen Sie für VPC die von Ihrem Kapazitätsanbieter verwendete VPC aus.

  7. Wählen Sie für Subnetze die Subnetze aus, in denen Sie Endpunkt-Netzwerkschnittstellen erstellen möchten. Wählen Sie für eine hohe Verfügbarkeit Subnetze in mehreren Availability Zones aus.

  8. Wählen Sie für Sicherheitsgruppen Sicherheitsgruppen aus, die eingehenden HTTPS-Verkehr (Port 443) aus der Sicherheitsgruppe Ihrer Funktion zulassen.

  9. Aktivieren Sie Private DNS für den Endpunkt.

  10. Wählen Sie Endpunkt erstellen aus.

Option 2: Öffentliches Subnetz mit Internet-Gateway

Wenn Ihr Kapazitätsanbieter öffentliche Subnetze verwendet, stellen Sie Folgendes sicher:

  1. Ein Internet-Gateway ist an Ihre VPC angeschlossen

  2. Die Routentabelle leitet den 0.0.0.0/0 Verkehr an das Internet-Gateway weiter

  3. Sicherheitsgruppen lassen ausgehenden HTTPS-Verkehr auf Port 443 zu

Option 3: Privates Subnetz mit NAT-Gateway

Wenn Ihr Kapazitätsanbieter private Subnetze verwendet, stellen Sie Folgendes sicher:

  1. Ein NAT-Gateway ist in einem öffentlichen Subnetz vorhanden

  2. Die Routing-Tabelle des privaten Subnetzes leitet den 0.0.0.0/0 Verkehr an das NAT-Gateway weiter

  3. Die öffentliche Subnetz-Routentabelle leitet den 0.0.0.0/0 Verkehr an ein Internet-Gateway weiter

  4. Sicherheitsgruppen ermöglichen ausgehenden HTTPS-Verkehr auf Port 443

Eine ausführliche Anleitung zu VPC-Konnektivitätsoptionen finden Sie unter VPC-Konnektivität für Lambda Managed Instances.

Schwierigkeiten beim Korrelieren von Protokollen aus gleichzeitigen Anfragen

Problem: Die Protokolle verschiedener Anfragen sind ineinander verschachtelt, was es schwierig macht, einzelne Anfragen nachzuverfolgen.

Ursache: Das Verschachteln von Protokollen wird erwartet und ist in Systemen mit mehreren gleichzeitigen Vorgängen Standard.

Lösung:

  • Strukturierte Protokollierung im JSON-Format verwenden: Geben Sie die Anforderungs-ID in alle Protokollanweisungen ein

  • Java: Verwenden Sie Log4j mit, um die ThreadContext Anfrage-ID automatisch einzubeziehen

  • Node.js: console.log() Mit JSON-Formatierung verwenden und einschließen InvokeStore.getRequestId()

  • Python: Verwenden Sie das Standard-Logging-Modul mit JSON-Formatierung und fügen Sie hinzu context.request_id

Eine ausführliche Anleitung finden Sie auf den laufzeitspezifischen Dokumentationsseiten.

Weitere Hilfe

Wenn Sie nach dem Ausprobieren dieser Lösungen weiterhin Probleme haben:

  1. CloudWatch Kennzahlen überprüfen: Überprüfen Sie die Kennzahlen zum Kapazitätsanbieter und zur Ausführungsumgebung, um Ressourcenbeschränkungen oder Skalierungsprobleme zu identifizieren.

  2. AWS CloudTrail Protokolle überprüfen: In den CloudTrail Protokollen finden Sie detaillierte Informationen zu API-Aufrufen und Fehlern.

  3. AWS Support kontaktieren: Wenn Sie das Problem nicht lösen können, wenden Sie sich mit Einzelheiten zur Konfiguration Ihres Kapazitätsanbieters, zur Funktionskonfiguration und zu den spezifischen Fehlermeldungen, auf die Sie stoßen, an den AWS Support.

Nächste Schritte