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.

Surveillance des fonctions Web Lambda

AWS Lambda Les fonctions Web publient des statistiques et des journaux sur Amazon CloudWatch. Utilisez-les pour identifier les problèmes de performance, les erreurs de débogage et définir des alarmes qui vous alertent lorsque le taux d'erreur augmente lors des déploiements Canary ou des changements de trafic.

Pour une fonction Web qui traite des demandes dans plusieurs cas Région AWS, Lambda collecte des métriques et des journaux dans chaque région où les demandes sont exécutées. Il centralise les métriques des demandes et se connecte à la région d'origine de la fonction Web, afin que vous puissiez surveiller l'ensemble de l'application à partir d'un seul endroit. Les indicateurs d'utilisation et de limitation restent dans la région où ils sont émis, car les quotas qu'ils décrivent s'appliquent par région.

Chaque type de télémétrie répond à une question différente :

Pour résoudre les problèmes dans la région où une demande a été exécutée, utilisez le groupe de journaux régional/aws/lambda/web/function-name.local, dans lequel les environnements d'exécution rédigent des journaux. Lambda centralise les journaux de manière asynchrone dans le groupe de journaux de la région d'/aws/lambda/web/function-nameorigine. Pour plus d'informations sur les régions d'origine et la réplication, consultezMulti-Region déploiement.

Le schéma suivant montre comment Lambda écrit et centralise la télémétrie entre les régions. Les métriques de demande dans l'espace de AWS/Lambda/Web noms et les journaux sont centralisées dans la région d'origine. Les métriques d'utilisation de l'espace de AWS/Lambda/Web/Usage noms restent dans chaque région.

Facturation par télémétrie

La télémétrie pour les fonctions Web est facturée comme suit :

Pour les prix actuels, consultez les CloudWatchtarifs Amazon.

Considérations relatives à la télémétrie

Passez en revue les comportements suivants avant de créer des tableaux de bord, des alarmes ou des automatismes sur la télémétrie des fonctions Web.

AWS X-Ray suivi

Si une demande inclut un X-Amzn-Trace-Id en-tête, Lambda le transmet sans modification à votre application. Lambda n'ajoute pas d'en-tête de trace aux demandes qui n'en incluent pas, et les fonctions Web ne créent pas de segments de service Lambda. Étant donné que les appelants définissent cet en-tête, considérez sa valeur comme une entrée client. Pour enregistrer des traces, envoyez les données de trace de votre code directement à X-Ray, par exemple avec le AWS Distro for OpenTelemetry, et autorisez votre rôle d'exécution à écrire sur X-Ray.

Latence de centralisation

Les métriques et les journaux atteignent la région d'origine de manière asynchrone. En régime permanent, Lambda centralise généralement les métriques et les journaux en quelques minutes. La télémétrie peut arriver plus tard lors d'une interruption de service.

Lorsque vous créez un point de terminaison qui s'exécute dans plusieurs régions, Lambda configure la centralisation des métriques pour chaque région de réplication. CloudWatch plusieurs minutes peuvent s'écouler une fois que le point de terminaison est devenu actif dans une région pour commencer à centraliser ses indicateurs à partir de cette région. Les métriques émises avant cette date restent uniquement dans cette région et ne sont pas ajoutées ultérieurement à la région d'origine.

Tenez compte de cette latence dans l'automatisation du déploiement. Si un pipeline crée une fonction Web ou un point de terminaison, puis vérifie immédiatement les métriques ou les journaux dans la région d'origine, laissez le temps à la première télémétrie d'arriver plutôt que de considérer son absence comme un échec.

Télémétrie dans chaque région

Lambda écrit la télémétrie dans chaque région où les demandes sont exécutées, puis en centralise une partie dans la région d'origine. Ce sur quoi vous pouvez compter dans chaque région dépend du type de télémétrie :

Interruptions de service

Les perturbations de l'infrastructure, telles qu'une panne de zone de disponibilité, peuvent retarder la télémétrie, et certains indicateurs et événements du journal peuvent être perdus. Si la région d'origine est affectée, les statistiques et les journaux centralisés dans la région d'origine peuvent être retardés ou indisponibles. Les mesures d'utilisation et les groupes de .local journaux dans les autres régions ne dépendent pas de la centralisation et continuent de recevoir des données télémétriques provenant de ces régions.

La télémétrie est émise dans la mesure du possible. Dans de rares cas, la télémétrie peut être supprimée ou dupliquée. Ne considérez pas la télémétrie des fonctions Web comme un enregistrement d'audit. Pour auditer les modifications de configuration et les appels, utilisez. AWS CloudTrail Pour plus d’informations, consultez Journalisation des appels d'API de fonction Web à l'aide de AWS CloudTrail.

Autorisations nécessaires

La journalisation nécessite les autorisations Amazon CloudWatch Logs logs:CreateLogGrouplogs:CreateLogStream, et logs:PutLogEvents dans le rôle d'exécution de votre fonction Web. Sans eux, Lambda ne peut pas créer de groupes de journaux ni écrire des événements de journal, et la sortie de votre application est perdue. Pour un exemple de politique, consultez Rôle d'exécution.

Lambda publie les métriques dans les AWS/Lambda/Web/Usage espaces de noms AWS/Lambda/Web et eux-mêmes, elles n'ont donc pas besoin d'autorisation dans le rôle d'exécution, y compris. cloudwatch:PutMetricData Le format de métrique intégré n'appelle pas PutMetricData directement, mais il nécessite les mêmes autorisations Amazon CloudWatch Logs, car Lambda extrait les métriques de vos événements de journal.