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 fonctions Web Lambda

Commencez par l'état de la ressource, la réponse HTTP et les journaux de la demande. Les fonctions Web exposent un état distinct pour la fonction, la révision, le point de terminaison et chaque région d'un point de PerRegion terminaison MultiRegion ou d'un point de terminaison. La défaillance d'une ressource ne change pas toujours l'état des autres.

Collecter des informations de diagnostic

Problèmes de déploiement et de démarrage

Pour éviter les échecs de déploiement répétés, validez la configuration et le démarrage dans une révision de test avant de créer une révision de production.

Erreurs de CLI et de package

Défaillances des requêtes HTTP

Limites des en-têtes de demande

Deux limites s'appliquent aux en-têtes de demande. Lambda limite le bloc d'en-tête à 128 KiB et rejette les demandes plus importantes avant qu'elles n'atteignent votre fonction. Le serveur Node.js HTTP de votre fonction limite également le nombre de lignes d'en-tête qu'il accepte. Les deux renvoient des champs d'en-tête de demande HTTP 431 trop grands, comme indiqué dans le tableau suivant. Pour les limites de la plateforme, voirLimites d'en-têtes.

La limite de taille compte chaque octet de la tête de requête lorsque le client l'envoie. Cela inclut la ligne de requête, chaque ligne d'en-tête (y compris Host les en-têtes ajoutés par la bibliothèque cliente) et les terminateurs de ligne. Les en-têtes ajoutés par Lambda ne sont pas pris en compte dans la limite de taille.

Lorsqu'une demande dépasse la limite de taille, Lambda la rejette avant qu'elle n'atteigne votre fonction. La demande ne produit donc aucun appel ni entrée dans le journal de l'application. L'en-tête de lambda-web-error-type réponse identifie la cause.

La limite de Node.js nombre compte les lignes d'en-tête, et non les noms d'en-tête distincts. Un en-tête répété trois fois compte trois fois. Par conséquent, une demande qui accumule x-forwarded-for ou suit des en-têtes par le biais d'une chaîne de proxys peut atteindre la limite. Aucun en-tête ne doit paraître inhabituel pour que cela se produise. La limite est mesurée en fonction de la demande que reçoit votre fonction, qui inclut les en-têtes ajoutés par Lambda. Par conséquent, un client qui envoie un peu moins de 1 000 lignes d'en-tête peut l'atteindre. Lorsque cela se produit, la demande atteint votre environnement d'exécution et le Node.js serveur la rejette lors de l'analyse. Votre gestionnaire ne fonctionne pas. La réponse contient les lambda-web-logstream en-têtes lambda-web-request-id et, mais pas l'lambda-web-error-typeen-tête.

Si votre application doit accepter un nombre de lignes d'en-tête supérieur à celui Node.js autorisé par défaut, augmentez la Node.js limite dans le code de votre serveur. Définissez server.maxHeadersCount le nombre de lignes d'en-tête à accepter ou définissez-le 0 pour désactiver le contrôle du Node.js comptage. La limite de taille de 128 KiB s'applique toujours.

const server = http.createServer(handler);
server.maxHeadersCount = 2000;
server.listen(port, host);

Il n'est pas nécessaire de modifier la limite de taille de l'Node.jsen-tête. Les environnements d'Node.jsexécution gérés le définissent pour qu'il corresponde à la limite de plate-forme, de sorte que la limite de plate-forme s'applique à la taille de l'en-tête. Vous ne pouvez pas augmenter la limite de plate-forme à partir du code de l'application.

Pour respecter les limites, déplacez l'état en bloc hors des en-têtes vers le corps de la demande, supprimez les cookies et réduisez les en-têtes de proxy et de suivi redondants avant que la demande n'atteigne le point de terminaison. Si une CloudFront distribution se trouve devant le point de terminaison, transmettez uniquement les en-têtes dont votre application a besoin dans la politique de demande d'origine.

Types d'erreur liés aux fonctions Web

Lorsqu'une demande adressée à un point de terminaison Web Function échoue, Lambda renvoie un en-tête de lambda-web-error-type réponse qui identifie le problème. La valeur utilise le format <Prefix>.<ErrorReason> : le préfixe indique où l'erreur s'est produite, et la raison indique la cause.

Par exemple, Runtime.RequestTimeout cela signifie que le runtime géré a signalé que votre fonction n'a pas répondu dans le délai d'expiration configuré et Application.InitCodeError que votre propre code d'initialisation a généré une erreur.

Lambda inclut l'lambda-web-error-typeen-tête lorsque l'erreur a été provoquée par la demande elle-même ou par votre fonction, sa configuration ou son code. Lambda omet l'en-tête pour les erreurs de service internes et pour les échecs d'autorisation, de sorte qu'aucun détail n'est révélé à un appelant non autorisé. Une valeur indique un problème sur le chemin entre la plateforme Lambda et votre fonction. Sur le chemin de la demande, l'erreur identifie l'endroit où la demande a échoué. Sur le chemin de réponse, utilisez la valeur associée à la télémétrie de votre application pour comprendre ce qui s'est passé.

Pour les mesures de régulation qui identifient la limite appliquée (pour les typesPlatform.AccountRequestThrottle, Platform.EndpointRequestThrottlePlatform.AccountActiveVCPUArm64Throttle, et Platform.EndpointMaxEnvThrottle d'erreur), voir. Indicateurs régionaux d'utilisation et de limitation

Des journaux ou des statistiques sont manquants

Si aucun journal d'application n'apparaît, il est possible que le rôle d'exécution ne dispose pas CloudWatch des autorisations Amazon Logs. Attachez la politique AWSLambdaBasicExecutionRole gérée au rôle d'exécution, ou accordez logs:CreateLogGrouplogs:CreateLogStream, etlogs:PutLogEvents. Pour les autorisations requises, consultez Rôle d'exécution.

Problèmes de stockage et de chiffrement du code

Problèmes liés MultiRegionaux PerRegionterminaux

Utilisez le regionalEndpoints champ pour identifier la région affectée. Comparez ses régions stateReason et updateStatusReason celles des régions saines. Vérifiez les quotas régionaux, les répliques AWS KMS clés, la disponibilité de l'environnement d'exécution et l'état de réplication de la révision. Après avoir corrigé la cause, répétez la mise à jour du terminal. Pour le modèle de réplication, voirMulti-Region déploiement.

Pour un MultiRegion point de terminaison, le routage basé sur la latence (qui dirige les demandes vers la région présentant la latence mesurée la plus faible) ne garantit pas que chaque demande soit dirigée vers la région à latence la plus faible. Effectuez un test à partir de l'emplacement du client concerné et inspectez les journaux de l'application pour déterminer quelle région a traité la demande. Pour un PerRegion point de terminaison, vérifiez également la configuration de votre DNS externe ou de votre routage frontal.

Problèmes de réseau et de connectivité

La plupart des problèmes de connectivité proviennent d'une révision de service qui ne contient aucune référence de connecteur ou qui fait référence à une ancienne version de connecteur, ou de sous-réseaux de connecteurs, de groupes de sécurité ou d'itinéraires qui bloquent le trafic.

Utilisez la séquence suivante pour isoler un problème de connectivité :

Les symptômes courants sont les suivants.

Il n'existe aucun accès interactif à un environnement d'exécution de fonctions Web. Utilisez les journaux des applications, les en-têtes de réponse des points de terminaison, les champs d'état des ressources, CloudWatch les métriques et les journaux de flux VPC pour diagnostiquer les défaillances.

Préparer un bundle d'escalade

Si les vérifications précédentes ne permettent pas d'identifier la cause, collectez les informations suivantes avant d'ouvrir un AWS Support dossier. Cela permet à l'ingénieur de support de corréler le fonctionnement du plan de contrôle, le déploiement régional, les demandes et la télémétrie :

Informations connexes