View a markdown version of this page

Problembehandlung bei Lambda Managed Instances - AWS Lambda
Probleme mit 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.

Problembehandlung bei Lambda Managed Instances

Probleme mit der Drosselung und Skalierung

Gelegentliche Drosselung

Problem: Während des normalen Betriebs treten Drosselungsfehler (HTTP 429) auf.

Ursache: Lambda Managed Instances lehnen möglicherweise neue Aufrufe ab, um bereits ausgeführte Aufrufe zu schützen. Wenn Ihre Ausführungsumgebungen konstant stark ausgelastet sind, werden neue Aufrufe möglicherweise gedrosselt.

Lösung:

  • Überwachen Sie die Skalierungsmetriken: Sehen Sie sich das Diagramm mit den Gründen der Drosselung an, um die Ursache für Probleme mit der Drosselung und Kapazitätsskalierung zu verstehen. Im folgenden Beispiel führt eine hohe CPU-Auslastung zu Drosselungen.

  • Ü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. Wenn ExecutionEnvironmentVCPUUtilization der Wert hoch ist, versuchen Sie, mehr vCPU pro Funktion hinzuzufügen.

    aws lambda update-function \
  --function-name my-function \
  ...
  --memory-size 8192

    Wenn ExecutionEnvironmentMemoryUtilization der Wert hoch ist, versuchen Sie, mehr Arbeitsspeicher pro vCPU hinzuzufügen:

    aws lambda update-function \
  --function-name my-function \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0
    }
  }'

Drosselt beim Hochskalieren

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

Ursache: Lambda Managed Instances werden asynchron basierend auf der CPU-Ressourcenauslastung und der Auslastung mehrerer Parallelitäten skaliert. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, da Lambda Instances und Ausführungsumgebungen entsprechend der Nachfrage hochskaliert.

Lösungen:

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

    aws lambda create-capacity-provider \
  --name my-capacity-provider \
  ...
  --capacity-provider-scaling-config '{
    "ScalingMode": "Manual",
    "ScalingPolicies": [
      {
        "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization",
        "TargetValue": 30.0
      }
    ]
  }'

  • Pre-warm Kapazität: Verwenden Sie bei geplanten Datenverkehrszuwächsen die PutFunctionScalingConfig API, um zusätzliche Kapazitäten vorzuwärmen.

    aws lambda put-function-scaling-config \
  --function-name my-function \
  --qualifier 1 \
  --function-scaling-config '{
    "MinExecutionEnvironments": 100
  }'

Langsames Herunterskalieren

Problem: Es dauert lange, bis Instances herunterskaliert sind, nachdem der Traffic abnimmt.

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 Instances konservativ herunter, um Stabilität zu gewährleisten. Überwachen Sie Ihre CloudWatch Metriken, um die Anzahl der laufenden Instances zu verfolgen.

Probleme mit der Parallelität

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

Problem: Ihre Funktionen werden gedrosselt, obwohl Kapazität verfügbar ist.

Ursache: In Ausführungsumgebungen mit sehr niedriger maximaler Parallelität kann es zu Schwierigkeiten bei der effektiven Skalierung kommen. Lambda Managed Instances sind für Anwendungen konzipiert, die mehrere Anwendungen gleichzeitig ausführen.

Lösungen:

  • Erhöhen Sie die maximale Parallelität: Wenn Ihre Funktionsaufrufe sehr wenig CPU beanspruchen, erhöhen Sie die maximale Parallelitätseinstellung auf bis zu 64 pro vCPU.

    aws lambda update-function \
  --function-name ordering-api-backend \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "PerExecutionEnvironmentMaxConcurrency": 32
    }
  }'

  • 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 genügend Ressourcen verfügt, um mehrere gleichzeitige Aufrufe zu verarbeiten.

Probleme mit der Thread-Sicherheit (Java-Laufzeit)

Problem: Ihre Java-Funktion liefert falsche Ergebnisse oder es kommt unter Last zu Rennbedingungen.

Ursache: Mehrere Threads führen die Handler-Methode gleichzeitig aus, und Shared State ist nicht threadsicher.

Lösung:

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

  • Ersetze HashMap durch ConcurrentHashMap

  • Zum Collections.synchronizedList() Wickeln verwenden ArrayList

  • Wird ThreadLocal für einen anforderungsspezifischen Status verwendet

  • Greifen Sie über das Lambda-Context-Objekt auf Trace-IDs zu, nicht auf Umgebungsvariablen

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

Probleme mit der Zustandsisolierung (Node.js Laufzeit)

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

Ursache: Globale Variablen werden bei gleichzeitigen Aufrufen im selben Worker-Thread 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 /tmp mit Anforderungs-IDs

  • Greifen Sie auf Trace-IDs InvokeStore.getXRayTraceId() anstelle von Umgebungsvariablen zu

Eine ausführliche Anleitung finden Sie in der Dokumentation zur Node.js Laufzeit von 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 eindeutige Dateinamen mit Anforderungs-IDs: /tmp/request_{context.request_id}.txt

  • Verwenden Sie das Sperren von Dateien mit fcntl.flock()

  • Löschen Sie temporäre Dateien mit os.remove() after use

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 einer hohen Speicherauslastung oder es kommt zu Fehlern aufgrund unzureichenden Speichers.

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

Lösung:

  • Überwachen Sie die Metrik in MemoryUtilization CloudWatch

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

  • Erhöhen Sie die Speicherzuweisung der Funktion, 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 erheblich zwischen den Aufrufen.

Ursache: Lambda wählt möglicherweise je nach Verfügbarkeit unterschiedliche Instanztypen aus, oder Funktionen werden möglicherweise auf Instances 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 diese MemoryUtilization auf Ebene des Kapazitätsanbieters, um Ressourcenbeschränkungen zu identifizieren.

  • Überprüfen Sie die Kapazitätskennzahlen: Prüfen Sie vCPUAvailable und stellen MemoryAvailable Sie sicher, dass auf Ihren Instances ausreichend Ressourcen verfügbar sind.

Probleme mit dem Kapazitätsanbieter

Die Funktionsversion wird nicht AKTIV

Problem: Ihre Funktionsversion bleibt nach der Veröffentlichung im Status Ausstehend.

Ursache: Lambda startet Managed Instances und startet Ausführungsumgebungen. Dieser Vorgang benötigt Zeit, insbesondere für die erste Funktionsversion auf einem neuen Kapazitätsanbieter.

Lösung:

Warten Sie, bis Lambda den Initialisierungsvorgang 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: Sie erhalten eine Fehlermeldung, wenn Sie versuchen, einen Kapazitätsanbieter zu löschen.

Ursache: Sie können einen Kapazitätsanbieter nicht löschen, dem Funktionsversionen zugeordnet sind.

Lösung:

  1. Identifizieren Sie alle Funktionsversionen mithilfe des Kapazitätsanbieters mit der ListFunctionVersionsByCapacityProvider API.

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

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

Allgemeine Fehlermeldungen beim Veröffentlichen 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 ACTIVE befindet.

  • VPC-Konfiguration überprüfen: Stellen Sie sicher, dass die in Ihrem Kapazitätsanbieter angegebenen Subnetze und Sicherheitsgruppen korrekt konfiguriert sind und darauf zugegriffen werden kann.

  • AWS CloudTrail Protokolle überprüfen: Überprüfen Sie die CloudTrail Protokolle auf detaillierte Fehlerinformationen zum fehlgeschlagenen Vorgang.

Probleme bei der Überwachung und Beobachtbarkeit

Fehlende Metriken CloudWatch

Problem: Sie sehen keine erwarteten Metriken 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 bis 10 Minuten, bevor Sie erwarten, dass Metriken angezeigt werden CloudWatch. Vergewissern Sie sich, dass Sie den richtigen Namespace (AWS/Lambda) und die richtigen Dimensionen (CapacityProviderNameFunctionName, oderInstanceType) verwenden.

Protokolle können nicht gefunden CloudWatch werden

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

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

Lösung:

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

Option 1: VPC-Endpunkt für CloudWatch Protokolle (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 Servicenamen die Option com.amazonaws.region.logs (durch Ihre AWS Region region ersetzen) aus.

  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 Subnetze in mehreren Availability Zones, um eine hohe Verfügbarkeit zu erzielen.

  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 Routing-Tabelle leitet 0.0.0.0/0 den Verkehr an das Internet-Gateway weiter

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

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 Datenverkehr an das NAT-Gateway weiter

  3. Die öffentliche Subnetz-Routing-Tabelle leitet den 0.0.0.0/0 Datenverkehr 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 verschachtelt, was es schwierig macht, einzelne Anfragen nachzuverfolgen.

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

Lösung:

  • Verwenden Sie die strukturierte Protokollierung im JSON-Format: Schließen Sie die Anforderungs-ID in alle Protokollanweisungen ein

  • Java: Verwenden Sie Log4j mit, um die ThreadContext Anforderungs-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 schließen Sie Folgendes ein 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. Wenden Sie sich an den AWS Support: Wenn Sie das Problem nicht lösen können, kontaktieren Sie den AWS Support mit Einzelheiten zur Konfiguration Ihres Kapazitätsanbieters, zur Funktionskonfiguration und zu den spezifischen Fehlermeldungen, auf die Sie stoßen.

Nächste Schritte