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](lambda-managed-instances-java-runtime.md). ### 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 ](lambda-managed-instances-nodejs-runtime.md) 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 ](lambda-managed-instances-python-runtime.md) 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. 1. Löschen oder aktualisieren Sie diese Funktionsversionen, um die Zuordnung zum Kapazitätsanbieter zu entfernen. 1. 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 (`CapacityProviderName``FunctionName`, oder`InstanceType`) 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/. ](https://console.aws.amazon.com/vpc/) 1. Wählen Sie im Navigationsbereich **Endpunkte** aus. 1. Wählen Sie **Endpunkt erstellen** aus. 1. Wählen Sie bei **Service category** (Servicekategorie) die Option **AWS services** (-Services) aus. 1. Wählen Sie als ** Servicenamen ** die Option `com.amazonaws.region.logs` (durch Ihre AWS Region `region` ersetzen) aus. 1. Wählen Sie für ** VPC ** die von Ihrem Kapazitätsanbieter verwendete VPC aus. 1. 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. 1. Wählen Sie für ** Sicherheitsgruppen Sicherheitsgruppen aus**, die eingehenden HTTPS-Verkehr (Port 443) aus der Sicherheitsgruppe Ihrer Funktion zulassen. 1. Aktivieren Sie ** Private DNS ** für den Endpunkt. 1. 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 1. Die Routing-Tabelle leitet `0.0.0.0/0` den Verkehr an das Internet-Gateway weiter 1. 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 1. Die Routing-Tabelle des privaten Subnetzes leitet den `0.0.0.0/0` Datenverkehr an das NAT-Gateway weiter 1. Die öffentliche Subnetz-Routing-Tabelle leitet den `0.0.0.0/0` Datenverkehr an ein Internet-Gateway weiter 1. 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. ](lambda-managed-instances-networking.md) ### 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. 1. ** AWS CloudTrail Protokolle ** überprüfen: In den CloudTrail Protokollen finden Sie detaillierte Informationen zu API-Aufrufen und Fehlern. 1. **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 + Erfahren Sie mehr über [ Kapazitätsanbieter für Lambda Managed Instances ](lambda-managed-instances-capacity-providers.md) + Machen Sie sich mit der [ Skalierung für Lambda Managed Instances vertraut ](lambda-managed-instances-scaling.md) + Lesen Sie die laufzeitspezifischen Anleitungen für [ Java ](lambda-managed-instances-java-runtime.md) und Python [ Node.js ](lambda-managed-instances-nodejs-runtime.md) [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md) + Überwachen Sie von Lambda verwaltete Instances mit Metriken [ CloudWatch ](lambda-managed-instances-monitoring.md) + Informieren Sie sich über [ bewährte Methoden für von Lambda verwaltete Instances ](lambda-managed-instances-best-practices.md)