Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Résolution des problèmes liés aux instances gérées Lambda ## Problèmes de limitation et de dimensionnement ### étranglement occasionnel **Problème : ** vous rencontrez des erreurs d'étranglement (HTTP 429) pendant les opérations normales. **Cause : Les instances gérées ** Lambda peuvent rejeter les nouvelles invocations afin de protéger les appels déjà en cours. Si le taux d'utilisation de vos environnements d'exécution est constamment élevé, les nouvelles invocations peuvent être limitées. **Solution :** + **Surveillez les indicateurs de dimensionnement : ** examinez le graphique des raisons de l'étranglement pour comprendre la raison des problèmes d'étranglement et de mise à l'échelle des capacités. Dans l'exemple suivant, un processeur trop élevé provoque des ralentissements. + **Vérifiez la configuration des fonctions : ** assurez-vous que la mémoire de vos fonctions et les paramètres du processeur virtuel prennent en charge les exécutions multisimultanées. Augmentez la mémoire des fonctions ou l'allocation du processeur virtuel si nécessaire. S'il `ExecutionEnvironmentVCPUUtilization` est élevé, essayez d'ajouter plus de processeurs virtuels par fonction. ``` aws lambda update-function \ --function-name my-function \ ... --memory-size 8192 ``` S'il `ExecutionEnvironmentMemoryUtilization` est élevé, essayez d'ajouter de la mémoire par processeur virtuel : ``` aws lambda update-function \ --function-name my-function \ --capacity-provider-config '{ "LambdaManagedInstancesCapacityProviderConfig": { "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0 } }' ``` ### Accélérations lors de la mise à l'échelle **Problème : ** vous rencontrez des erreurs de limitation (HTTP 429) lorsque le trafic augmente rapidement. **Cause : Les instances gérées ** Lambda évoluent de manière asynchrone en fonction de l'utilisation des ressources du processeur et de la saturation multisimultanéité. Si votre trafic fait plus que doubler en 5 minutes, vous risquez de rencontrer des problèmes à mesure que Lambda fait évoluer les instances et les environnements d'exécution pour répondre à la demande. **Solutions :** + **Ajustez l'utilisation des ressources cibles : ** si votre charge de travail présente des modèles de trafic prévisibles, définissez une utilisation des ressources cible plus faible afin de conserver une marge de manœuvre supplémentaire en cas de rafales de trafic. ``` aws lambda create-capacity-provider \ --name my-capacity-provider \ ... --capacity-provider-scaling-config '{ "ScalingMode": "Manual", "ScalingPolicies": [ { "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization", "TargetValue": 30.0 } ] }' ``` + **Pre-warm capacité : ** pour les augmentations de trafic planifiées, utilisez l'`PutFunctionScalingConfig`API pour préchauffer la capacité supplémentaire. ``` aws lambda put-function-scaling-config \ --function-name my-function \ --qualifier 1 \ --function-scaling-config '{ "MinExecutionEnvironments": 100 }' ``` ### Réduction lente **Problème : ** les instances mettent beaucoup de temps à être réduites après une diminution du trafic. **Cause : Les instances gérées ** Lambda sont progressivement réduites pour maintenir la disponibilité et éviter les changements de capacité rapides qui pourraient avoir un impact sur les performances. **Solution :** Ce comportement est normal. Lambda réduit les instances de manière conservatrice pour garantir la stabilité. Surveillez vos CloudWatch statistiques pour suivre le nombre d'instances en cours d'exécution. ## Problèmes de simultanéité ### Environnements d'exécution avec de faibles limites d'expérience de simultanéité **Problème : ** Vos fonctions sont ralenties malgré la disponibilité de la capacité. **Cause : Les environnements ** d'exécution dont la simultanéité maximale est très faible peuvent avoir des difficultés à évoluer efficacement. Les instances gérées Lambda sont conçues pour les applications multisimultanées. **Solutions :** + **Augmentez la simultanéité maximale : ** si les invocations de vos fonctions utilisent très peu de processeur, augmentez le paramètre de simultanéité maximale à 64 par processeur virtuel. ``` aws lambda update-function \ --function-name ordering-api-backend \ --capacity-provider-config '{ "LambdaManagedInstancesCapacityProviderConfig": { "PerExecutionEnvironmentMaxConcurrency": 32 } }' ``` + **Optimisez le code de fonction : ** révisez votre code de fonction pour réduire la consommation du processeur par appel, ce qui permet une plus grande simultanéité. + **Réglez la mémoire des fonctions et le processeur virtuel : ** assurez-vous que votre fonction dispose de suffisamment de ressources pour gérer plusieurs appels simultanés. ### Problèmes de sécurité des threads (environnement d'exécution Java) **Problème : ** Votre fonction Java produit des résultats incorrects ou se heurte à des conditions de concurrence lorsqu'elle est chargée. **Cause : ** plusieurs threads exécutent la méthode du gestionnaire simultanément et l'état partagé n'est pas sécurisé pour les threads. **Solution :** + Utilisez `AtomicInteger` ou `AtomicLong` pour les compteurs au lieu de types primitifs + Remplacez `HashMap` par `ConcurrentHashMap`. + Utiliser `Collections.synchronizedList()` pour emballer `ArrayList` + À utiliser `ThreadLocal` pour un état spécifique à la demande + Accédez aux ID de trace depuis l'objet Lambda Context, et non depuis les variables d'environnement Pour obtenir des conseils détaillés, consultez la [ documentation relative à l'environnement d'exécution ](lambda-managed-instances-java-runtime.md) Java pour les instances gérées Lambda. ### Problèmes d'isolation des états (Node.js exécution) **Problème : ** votre Node.js fonction renvoie des données provenant de différentes requêtes ou est corrompue. **Cause : Les variables ** globales sont partagées lors d'appels simultanés sur le même thread de travail. Lorsque les opérations asynchrones permettent de contrôler, d'autres invocations peuvent modifier l'état partagé. **Solution :** + Installation et utilisation `@aws/lambda-invoke-store` pour tous les états spécifiques à la demande + Remplacez les variables globales par `InvokeStore.set()` et `InvokeStore.get()` + Utiliser des noms de fichiers uniques dans `/tmp` les ID de demande + Accédez aux ID de trace en utilisant `InvokeStore.getXRayTraceId()` plutôt des variables d'environnement Pour obtenir des conseils détaillés, consultez la [ documentation relative à l'](lambda-managed-instances-nodejs-runtime.md)Node.js environnement d'exécution pour les instances gérées Lambda. ### Conflits de fichiers (environnement d'exécution Python) **Problème : ** Votre fonction Python lit des données incorrectes à partir de fichiers au format`/tmp`. **Cause : ** plusieurs processus partagent le `/tmp` répertoire. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données. **Solution :** + Utilisez des noms de fichiers uniques avec des ID de demande : `/tmp/request_{context.request_id}.txt` + Utiliser le verrouillage des fichiers avec `fcntl.flock()` pour les fichiers partagés + Nettoyez les fichiers temporaires avec `os.remove()` After Use Pour obtenir des conseils détaillés, consultez la [ documentation relative à l'environnement d'exécution ](lambda-managed-instances-python-runtime.md) Python pour les instances gérées Lambda. ## Problèmes de performance ### Utilisation élevée de la mémoire **Problème : ** Vos fonctions présentent une forte utilisation de la mémoire ou des erreurs de mémoire insuffisante. **Cause : ** Chaque requête simultanée en Python s'exécute dans un processus distinct avec son propre espace mémoire. L'utilisation totale de la mémoire est égale à la mémoire par processus multipliée par les processus simultanés. **Solution :** + Surveillez la `MemoryUtilization` métrique dans CloudWatch + Réduisez le `MaxConcurrency` réglage si l'utilisation de la mémoire approche de la limite de mémoire de la fonction + Augmenter l'allocation de mémoire des fonctions pour permettre une plus grande simultanéité + Optimisez l'utilisation de la mémoire en chargeant les données à la demande plutôt que pendant l'initialisation ### Des performances incohérentes **Problème : les performances des ** fonctions varient considérablement d'une invocation à l'autre. **Cause : ** Lambda peut sélectionner différents types d'instances en fonction de la disponibilité, ou des fonctions peuvent être exécutées sur des instances dont la disponibilité des ressources varie. **Solution :** + **Spécifiez les types d'instances autorisés : ** si vous avez des exigences de performances spécifiques, configurez les types d'instances autorisés dans votre fournisseur de capacité afin de limiter les types d'instances que Lambda peut sélectionner. + **Surveillez les indicateurs au niveau de l'instance : effectuez un ** suivi `CPUUtilization` et `MemoryUtilization` au niveau du fournisseur de capacité pour identifier les contraintes en matière de ressources. + **Passez en revue les indicateurs de capacité : ** vérifiez `vCPUAvailable` et `MemoryAvailable` assurez-vous que des ressources suffisantes sont disponibles sur vos instances. ## Problèmes liés aux fournisseurs de capacités ### La version de la fonction ne devient pas ACTIVE **Problème : la version de ** votre fonction reste en attente après la publication. **Cause : ** Lambda lance des instances gérées et démarre des environnements d'exécution. Ce processus prend du temps, en particulier pour la première version de fonction sur un nouveau fournisseur de capacité. **Solution :** Attendez que Lambda termine le processus d'initialisation. Lambda lance trois instances par défaut pour la résilience AZ et démarre trois environnements d'exécution avant de marquer la version de votre fonction comme ACTIVE. Cela prend généralement plusieurs minutes. ### Impossible de supprimer le fournisseur de capacité **Problème : un message d'erreur s'affiche lorsque ** vous tentez de supprimer un fournisseur de capacité. **Cause : ** Vous ne pouvez pas supprimer un fournisseur de capacité auquel sont associées des versions de fonctions. **Solution :** 1. Identifiez toutes les versions de fonctions à l'aide du fournisseur de capacité à l'aide de l'`ListFunctionVersionsByCapacityProvider`API. 1. Supprimez ou mettez à jour ces versions de fonctions pour supprimer l'association de fournisseur de capacité. 1. Réessayez de supprimer le fournisseur de capacité. ### Messages d'erreur génériques lors de la publication des fonctions **Problème : ** vous rencontrez des messages d'erreur génériques tels que « Une erreur interne s'est produite lors de la publication » lors de la publication des fonctions. **Solution :** + **Vérifiez les autorisations IAM : ** assurez-vous de disposer de l'`lambda:PassCapacityProvider`autorisation pour le fournisseur de capacité que vous essayez d'utiliser. + **Vérifiez la configuration du fournisseur de capacité : ** confirmez que votre fournisseur de capacité est à l'état ACTIF à l'aide de l'`GetCapacityProvider`API. + **Vérifiez la configuration du VPC : ** assurez-vous que les sous-réseaux et les groupes de sécurité spécifiés dans votre fournisseur de capacité sont correctement configurés et accessibles. + **Vérifiez les AWS CloudTrail journaux : ** consultez CloudTrail les journaux pour obtenir des informations détaillées sur les erreurs relatives à l'échec de l'opération. ## Problèmes de surveillance et d'observabilité ### CloudWatch Métriques manquantes **Problème : ** vous ne voyez pas les mesures attendues CloudWatch pour votre fournisseur de capacité ou vos fonctions. **Cause : Les ** métriques sont publiées à intervalles de 5 minutes. Les nouveaux fournisseurs de capacité ou les nouvelles fonctions peuvent ne pas disposer de métriques immédiatement. **Solution :** Attendez au moins 5 à 10 minutes après la publication d'une version de fonction avant de vous attendre à ce que les métriques apparaissent dans CloudWatch. Vérifiez que vous recherchez l'espace de noms (`AWS/Lambda`) et les dimensions (`CapacityProviderName``FunctionName`, ou`InstanceType`) corrects. ### Impossible de trouver les CloudWatch journaux **Problème : ** Votre fonction s'exécute correctement, mais vous ne trouvez pas de journaux dans les CloudWatch journaux. **Cause : Les instances gérées ** Lambda s'exécutent dans votre VPC et nécessitent une connectivité réseau pour envoyer des journaux à CloudWatch Logs. Sans configuration de connectivité VPC appropriée, vos fonctions ne peuvent pas atteindre le point de terminaison du service CloudWatch Logs. **Solution :** Configurez la connectivité VPC pour permettre à vos fonctions d'envoyer des CloudWatch journaux à Logs. Trois possibilités s’offrent à vous : **Option 1 : point de terminaison VPC pour les CloudWatch journaux (recommandé pour la production) ** 1. Ouvrez la console Amazon VPC à l'adresse [ console.aws.amazon. com/vpc/](https://console.aws.amazon.com/vpc/). 1. Dans le panneau de navigation, choisissez **Points de terminaison**. 1. Choisissez **Créer un point de terminaison**. 1. Pour **Service category (Catégorie de service)**, choisissez **Services AWS **. 1. Dans le ** champ Nom du service**, sélectionnez `com.amazonaws.region.logs` (remplacez `region` par votre AWS région). 1. Pour ** VPC**, sélectionnez le VPC utilisé par votre fournisseur de capacité. 1. Pour ** Sous-réseaux**, sélectionnez les sous-réseaux dans lesquels vous souhaitez créer des interfaces réseau de terminaux. Pour assurer la haute disponibilité, sélectionnez les sous-réseaux dans plusieurs zones de disponibilité. 1. Pour les groupes ** de sécurité**, sélectionnez les groupes de sécurité qui autorisent le trafic HTTPS entrant (port 443) à partir du groupe de sécurité de votre fonction. 1. Activez le DNS ** privé ** pour le terminal. 1. Choisissez **Créer un point de terminaison**. **Option 2 : sous-réseau public avec passerelle Internet ** Si votre fournisseur de capacité utilise des sous-réseaux publics, assurez-vous que : 1. Une passerelle Internet est connectée à votre VPC 1. La table de routage achemine le `0.0.0.0/0` trafic vers la passerelle Internet 1. Les groupes de sécurité autorisent le trafic HTTPS sortant sur le port 443 **Option 3 : sous-réseau privé avec passerelle NAT ** Si votre fournisseur de capacité utilise des sous-réseaux privés, assurez-vous que : 1. Une passerelle NAT existe dans un sous-réseau public 1. La table de routage du sous-réseau privé achemine le `0.0.0.0/0` trafic vers la passerelle NAT 1. La table de routage des sous-réseaux publics achemine `0.0.0.0/0` le trafic vers une passerelle Internet 1. Les groupes de sécurité autorisent le trafic HTTPS sortant sur le port 443 Pour obtenir des conseils détaillés sur les options de connectivité VPC, consultez la section Connectivité [ VPC pour les instances gérées Lambda. ](lambda-managed-instances-networking.md) ### Difficulté à corréler les journaux des demandes simultanées **Problème : ** les journaux des différentes demandes sont entrelacés, ce qui rend difficile le suivi des demandes individuelles. **Cause : L'entrelacement des ** journaux est un comportement normal et normal dans les systèmes multisimultanés. **Solution :** + **Utilisez la journalisation structurée au format JSON : ** incluez l'ID de demande dans toutes les instructions de journal + **Java : ** utilisez Log4j avec `ThreadContext` pour inclure automatiquement l'ID de demande + **Node.js: à ** utiliser `console.log()` avec le formatage JSON et à inclure `InvokeStore.getRequestId()` + **Python : ** utilisez le module de journalisation standard au format JSON et incluez `context.request_id` Pour obtenir des conseils détaillés, consultez les pages de documentation spécifiques à l'exécution. ## Aide supplémentaire Si les problèmes persistent après avoir essayé ces solutions : 1. **Analysez CloudWatch les métriques : ** vérifiez les métriques du fournisseur de capacité et de l'environnement d'exécution pour identifier les contraintes en matière de ressources ou les problèmes de dimensionnement. 1. **Consultez AWS CloudTrail les journaux : ** consultez CloudTrail les journaux pour obtenir des informations détaillées sur les appels d'API et les erreurs. 1. **Contacter le AWS support : ** si vous ne parvenez pas à résoudre le problème, contactez le AWS support en fournissant des informations sur la configuration de votre fournisseur de capacité, la configuration des fonctions et les messages d'erreur spécifiques que vous rencontrez. ## Étapes suivantes + En savoir plus sur les fournisseurs de [ capacité pour les instances gérées Lambda ](lambda-managed-instances-capacity-providers.md) + Comprendre la [ mise à l'échelle pour les instances gérées Lambda ](lambda-managed-instances-scaling.md) + Consultez les guides spécifiques à l'exécution pour [ Java ](lambda-managed-instances-java-runtime.md) et [ Node.js ](lambda-managed-instances-nodejs-runtime.md) Python [Runtime Python pour les instances gérées Lambda](lambda-managed-instances-python-runtime.md) + Surveillez les instances gérées Lambda à l'aide de métriques [ CloudWatch ](lambda-managed-instances-monitoring.md) + Passez en revue [ les meilleures pratiques pour les instances gérées Lambda ](lambda-managed-instances-best-practices.md)