Surveillance et journalisation - AWS AppSync
Installation et configurationCloudWatch métriquesCloudWatch journauxRéférence du type de journalAnalyser vos journaux avec CloudWatch Logs InsightsAnalysez vos journaux avec OpenSearch ServiceMigration du format de journal

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 et journalisation

Pour surveiller votre API AWS AppSync GraphQL et résoudre les problèmes liés aux requêtes, vous pouvez activer la connexion à Amazon Logs. CloudWatch

Installation et configuration

Pour activer la journalisation automatique sur une API GraphQL, utilisez la AWS AppSync console.

  1. Connectez-vous à la AppSyncconsole AWS Management Console et ouvrez-la.

  2. Sur la page API, choisissez le nom d'une API GraphQL.

  3. Sur la page d'accueil de votre API, dans le volet de navigation, sélectionnez Paramètres.

  4. Sous Journalisation, procédez de la façon suivante :

    1. Activez Activer les journaux.

    2. Pour une journalisation détaillée au niveau de la demande, cochez la case sous Inclure le contenu détaillé. (facultatif)

    3. Sous Niveau de journalisation du résolveur de champs, choisissez votre niveau de journalisation préféré au niveau du champ (aucun, erreur ou tout). (facultatif)

    4. Sous Créer ou utiliser un rôle existant, choisissez Nouveau rôle pour créer un nouveau rôle AWS Identity and Access Management (IAM) qui permet d' AWS AppSync écrire CloudWatch des journaux. Vous pouvez également choisir Rôle existant pour sélectionner le nom de ressource Amazon (ARN) d'un rôle IAM existant dans votre AWS compte.

  5. Choisissez Enregistrer.

Configuration manuelle des rôles IAM

Si vous choisissez d'utiliser un rôle IAM existant, celui-ci doit accorder AWS AppSync les autorisations requises pour écrire des journaux. CloudWatch Pour le configurer manuellement, vous devez fournir un ARN de rôle de service afin de AWS AppSync pouvoir assumer ce rôle lors de l'écriture des journaux.

Dans la console IAM, créez une nouvelle politique dont le nom AWSAppSyncPushToCloudWatchLogsPolicy a la définition suivante :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Créez ensuite un nouveau rôle portant ce nom AWSAppSyncPushToCloudWatchLogsRoleet associez la politique nouvellement créée au rôle. Modifiez la relation de confiance pour ce rôle comme suit :

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "appsync.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

Copiez l'ARN du rôle et utilisez-le lors de la configuration de la journalisation pour une API AWS AppSync GraphQL.

CloudWatch métriques

Vous pouvez utiliser CloudWatch des métriques pour surveiller et émettre des alertes concernant des événements spécifiques susceptibles d'entraîner des codes d'état HTTP ou une latence. Les métriques suivantes sont émises :

4XXError

Erreurs résultant de demandes non valides en raison d'une configuration client incorrecte. Généralement, ces erreurs se produisent n'importe où en dehors du traitement GraphQL. Par exemple, ces erreurs peuvent se produire lorsque la demande inclut une charge utile JSON incorrecte ou une requête incorrecte, lorsque le service est limité ou lorsque les paramètres d'autorisation sont mal configurés.

Unité : nombre. Utilisez la statistique Somme pour obtenir le total des occurrences de ces erreurs.

5XXError

Erreurs rencontrées lors de l'exécution d'une requête GraphQL. Cela peut se produire, par exemple, lors de l'appel d'une requête pour un schéma vide ou incorrect. Cela peut également se produire lorsque l'ID ou la AWS région du groupe d'utilisateurs Amazon Cognito n'est pas valide. Cela peut également se produire en cas AWS AppSync de problème lors du traitement d'une demande.

Unité : nombre. Utilisez la statistique Somme pour obtenir le total des occurrences de ces erreurs.

Latency

Le délai entre le moment où il AWS AppSync reçoit une demande d'un client et le moment où il renvoie une réponse au client. Cela n'inclut pas la latence du réseau rencontrée pour une réponse afin d'atteindre les appareils finaux.

Unité : milliseconde. Utilisez la statistique Moyenne pour évaluer les latences attendues.

Requests

Le nombre de demandes (requêtes + mutations) traitées par toutes les API de votre compte, par région.

Unité : nombre. Le nombre de demandes traitées dans une région donnée.

TokensConsumed

Les jetons sont alloués en Requests fonction de la quantité de ressources (temps de traitement et mémoire utilisée) qu'un utilisateur Request consomme. En général, chacun Request consomme un jeton. Toutefois, ceux Request qui consomment de grandes quantités de ressources se voient attribuer des jetons supplémentaires selon les besoins.

Unité : nombre. Le nombre de jetons alloués aux demandes traitées dans une région donnée.

NetworkBandwidthOutAllowanceExceeded
Note

Dans la AWS AppSync console, sur la page des paramètres du cache, l'option Cache Health Metrics vous permet d'activer cette métrique de santé liée au cache.

Les paquets réseau ont été abandonnés parce que le débit dépassait la limite de bande passante agrégée. Cela est utile pour diagnostiquer les goulots d'étranglement dans une configuration de cache. Les données sont enregistrées pour une API particulière en les spécifiant API_Id dans la appsyncCacheNetworkBandwidthOutAllowanceExceeded métrique.

Unité : nombre. Nombre de paquets abandonnés après avoir dépassé la limite de bande passante pour une API spécifiée par ID.

EngineCPUUtilization
Note

Dans la AWS AppSync console, sur la page des paramètres du cache, l'option Cache Health Metrics vous permet d'activer cette métrique de santé liée au cache.

L'utilisation du processeur (pourcentage) allouée au processus Redis. Cela est utile pour diagnostiquer les goulots d'étranglement dans une configuration de cache. Les données sont enregistrées pour une API particulière en les spécifiant API_Id dans la appsyncCacheEngineCPUUtilization métrique.

Unité : Pourcentage. Pourcentage de processeur actuellement utilisé par le processus Redis pour une API spécifiée par ID.

Abonnements en temps réel

Toutes les métriques sont émises dans une dimension : GraphQLAPIID. Cela signifie que toutes les métriques sont couplées avec des ID d'API GraphQL. Les métriques suivantes sont liées aux abonnements GraphQL sur Pure : WebSockets

ConnectRequests

Le nombre de demandes de WebSocket connexion adressées à AWS AppSync, y compris les tentatives réussies et infructueuses.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes de connexion.

ConnectSuccess

Le nombre de WebSocket connexions réussies à AWS AppSync. Il est possible d'avoir des connexions sans abonnements.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences de connexions réussies.

ConnectClientError

Le nombre de WebSocket connexions rejetées en AWS AppSync raison d'erreurs côté client. Cela peut indiquer que le service est limité ou que les paramètres d'autorisation sont mal configurés.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences des erreurs de connexion côté client.

ConnectServerError

Nombre d'erreurs survenues AWS AppSync lors du traitement des connexions. Cela se produit généralement lorsqu'un problème inattendu prend place côté serveur.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs de connexion côté serveur.

DisconnectSuccess

Le nombre de WebSocket déconnexions réussies de AWS AppSync.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total d'occurrences de déconnexions réussies.

DisconnectClientError

Nombre d'erreurs client survenues AWS AppSync lors de la déconnexion des WebSocket connexions.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs de connexion.

DisconnectServerError

Nombre d'erreurs de serveur survenues AWS AppSync lors de la déconnexion WebSocket des connexions.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs de connexion.

SubscribeSuccess

Le nombre d'abonnements enregistrés avec succès AWS AppSync via WebSocket. Il est possible d'avoir des connexions sans abonnement, mais il n'est pas possible d'avoir des abonnements sans connexions.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le nombre total des occurrences d'abonnements réussis.

SubscribeClientError

Le nombre d'abonnements rejetés en AWS AppSync raison d'erreurs côté client. Cela peut se produire lorsqu'une charge utile JSON est incorrecte, que le service est limité ou que les paramètres d'autorisation sont mal configurés.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs d'abonnement côté client.

SubscribeServerError

Nombre d'erreurs survenues AWS AppSync lors du traitement des abonnements. Cela se produit généralement lorsqu'un problème inattendu prend place côté serveur.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le nombre total d'occurrences des erreurs d'abonnement côté serveur.

UnsubscribeSuccess

Le nombre de demandes de désabonnement traitées avec succès.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes de désabonnement réussies.

UnsubscribeClientError

Le nombre de demandes de désabonnement rejetées en AWS AppSync raison d'erreurs du côté du client.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total d'occurrences des erreurs de demande de désabonnement côté client.

UnsubscribeServerError

Nombre d'erreurs survenues AWS AppSync lors du traitement des demandes de désabonnement. Cela se produit généralement lorsqu'un problème inattendu prend place côté serveur.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total d'occurrences des erreurs de demande de désabonnement côté serveur.

PublishDataMessageSuccess

Nombre de messages d'événement d'abonnement qui ont été publiés avec succès.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des messages d'événement d'abonnement qui ont été publiés avec succès.

PublishDataMessageClientError

Nombre de messages d'événement d'abonnement qui n'ont pas pu être publiés en raison d'erreurs côté client.

Unit: Compte. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs d'événement d'abonnement de publication côté client.

PublishDataMessageServerError

Nombre d'erreurs survenues AWS AppSync lors de la publication des messages d'événements d'abonnement. Cela se produit généralement lorsqu'un problème inattendu prend place côté serveur.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences d'erreurs d'événement d'abonnement de publication côté serveur.

PublishDataMessageSize

Taille des messages d'événement d'abonnement publiés.

Unité : octets.

ActiveConnections

Le nombre de WebSocket connexions simultanées entre les clients et AWS AppSync en 1 minute.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le nombre total de connexions ouvertes.

ActiveSubscriptions

Nombre d'abonnements simultanés provenant de clients en 1 minute.

Unité : nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des abonnements actifs.

ConnectionDuration

Durée pendant laquelle la connexion reste ouverte.

Unité : millisecondes. Utilisez la statistique Average (Moyenne) pour évaluer la durée de connexion.

OutboundMessages

Le nombre de messages mesurés publiés avec succès. Un message mesuré équivaut à 5 kB de données livrées.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages mesurés publiés avec succès.

InboundMessageSuccess

Nombre de messages entrants traités avec succès. Chaque type d'abonnement invoqué par une mutation génère un message entrant.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages entrants traités avec succès.

InboundMessageError

Le nombre de messages entrants dont le traitement a échoué en raison de demandes d'API non valides, telles que le dépassement de la limite de charge utile de l'abonnement de 240 kB.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages entrants présentant des échecs de traitement liés à l'API.

InboundMessageFailure

Nombre de messages entrants dont le traitement a échoué en raison d'erreurs provenant de AWS AppSync.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages entrants présentant des échecs de traitement AWS AppSync associés.

InboundMessageDelayed

Le nombre de messages entrants retardés. Les messages entrants peuvent être retardés lorsque le quota de débit de messages entrants ou le quota de débit de messages sortants est dépassé.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages entrants qui ont été retardés.

InboundMessageDropped

Le nombre de messages entrants abandonnés. Les messages entrants peuvent être supprimés lorsque le quota de débit de messages entrants ou le quota de débit de messages sortants est dépassé.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de messages entrants qui ont été supprimés.

InvalidationSuccess

Le nombre d'abonnements invalidés (désabonnés) avec succès par une mutation avec. $extensions.invalidateSubscriptions()

Unité : nombre. Utilisez la statistique Sum pour récupérer le nombre total d'abonnements désabonnés avec succès.

InvalidationRequestSuccess

Nombre de demandes d'invalidation traitées avec succès.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes d'invalidation traitées avec succès.

InvalidationRequestError

Le nombre de demandes d'invalidation dont le traitement a échoué en raison de demandes d'API non valides.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes d'invalidation présentant des échecs de traitement liés à l'API.

InvalidationRequestFailure

Le nombre de demandes d'invalidation dont le traitement a échoué en raison d'erreurs provenant de AWS AppSync.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes d'invalidation associées à des échecs de AWS AppSync traitement.

InvalidationRequestDropped

Le nombre de demandes d'invalidation abandonnées lorsque le quota de demandes d'invalidation a été dépassé.

Unité : nombre. Utilisez la statistique Sum pour obtenir le nombre total de demandes d'invalidation abandonnées.

Comparaison des messages entrants et sortants

Lorsqu'une mutation est exécutée, les champs d'abonnement contenant la directive @aws_subscribe pour cette mutation sont invoqués. Chaque appel d'abonnement génère un message entrant. Par exemple, si deux champs d'abonnement spécifient la même mutation dans @aws_subscribe, deux messages entrants sont générés lorsque cette mutation est appelée.

Un message sortant équivaut à 5 kB de données livrées aux WebSocket clients. Par exemple, l'envoi de 15 Ko de données à 10 clients génère 30 messages sortants (15 kB* 10 clients/5 kB par message = 30 messages).

Vous pouvez demander des augmentations de quota pour les messages entrants ou sortants. Pour plus d'informations, consultez la section AWS AppSync Points de terminaison et quotas dans le guide de référence AWS général et les instructions pour demander une augmentation de quota dans le guide de l'utilisateur du Service Quotas.

Métriques améliorées

Les métriques améliorées émettent des données granulaires sur l'utilisation et les performances des API, telles que le nombre de AWS AppSync demandes et d'erreurs, la latence et les accès/échecs du cache. Toutes les données métriques améliorées sont envoyées à votre CloudWatch compte, et vous pouvez configurer les types de données qui seront envoyées.

Note

Des frais supplémentaires sont appliqués lors de l'utilisation de métriques améliorées. Pour plus d'informations, consultez les niveaux de tarification détaillés de la surveillance dans la section CloudWatchTarification d'Amazon.

Ces statistiques se trouvent sur les différentes pages de paramètres de la AWS AppSync console. Sur la page des paramètres de l'API, la section Mesures améliorées vous permet d'activer ou de désactiver les éléments suivants :

  1. Comportement des métriques du résolveur : ces options contrôlent la manière dont les métriques supplémentaires pour les résolveurs sont collectées. Vous pouvez choisir d'activer les métriques complètes du résolveur de demandes (métriques activées pour tous les résolveurs dans les demandes) ou les métriques par résolveur (métriques activées uniquement pour les résolveurs dont la configuration est définie sur activée). Les options suivantes sont disponibles :

    Métrique Dimension métrique Nom de la métrique Unité Description
    Erreurs GraphQL par résolveur API_ID, résolveur Erreur GraphQL Count Nombre d'erreurs GraphQL survenues par résolveur.
    Demandes par résolveur API_ID, résolveur Demande Count Le nombre d'invocations survenues lors d'une demande. Ceci est enregistré par résolveur.
    Latence par résolveur API_ID, résolveur Latence Milliseconde Le temps nécessaire pour terminer une invocation du résolveur. La latence est mesurée en millisecondes et est enregistrée par résolveur.
    Nombre de visites en cache par résolveur API_ID, résolveur CacheHit Count Le nombre de connexions au cache lors d'une demande. Cela ne sera émis que si un cache est utilisé. Les accès au cache sont enregistrés par résolveur.
    Erreurs de cache par résolveur API_ID, résolveur CacheMiss Count Le nombre de caches manquants lors d'une demande. Cela ne sera émis que si un cache est utilisé. Les erreurs de cache sont enregistrées par résolveur.

  2. Comportement des métriques des sources de données : ces options contrôlent la manière dont les métriques supplémentaires pour les sources de données sont collectées. Vous pouvez choisir d'activer les métriques complètes des sources de données des demandes (métriques activées pour toutes les sources de données dans les demandes) ou les métriques par source de données (métriques activées uniquement pour les sources de données dont la configuration est définie comme activée). Les options suivantes sont disponibles :

    Métrique Dimension métrique Nom de la métrique Unité Description
    Demandes par source de données API_ID, source de données Demande Count Le nombre d'invocations survenues lors d'une demande. Les demandes sont enregistrées par source de données. Si les demandes complètes sont activées, chaque source de données aura sa propre entrée CloudWatch.
    Latence par source de données API_ID, source de données Latence Milliseconde Le temps nécessaire pour terminer un appel de source de données. La latence est enregistrée par source de données.
    Erreurs par source de données API_ID, source de données Erreur GraphQL Count Nombre d'erreurs survenues lors d'un appel de source de données.

  3. Métriques d'opération : active les métriques au niveau des opérations GraphQL.

    Métrique Dimension métrique Nom de la métrique Unité Description
    Demandes par opération API_ID, Opération Demande Count Nombre de fois qu'une opération GraphQL spécifiée a été appelée.
    Erreurs GraphQL par opération API_ID, Opération Erreur GraphQL Count Nombre d'erreurs GraphQL survenues lors d'une opération GraphQL spécifiée.

CloudWatch journaux

Vous pouvez configurer deux types de journalisation sur n'importe quelle API GraphQL nouvelle ou existante : au niveau de la demande et au niveau du champ.

Journaux au niveau des demandes

Lorsque la journalisation au niveau de la demande (inclure du contenu détaillé) est configurée, les informations suivantes sont enregistrées :

  • Le nombre de jetons consommés

  • La demande et la réponse des en-têtes HTTP

  • La requête GraphQL exécutée dans la requête

  • Le résumé général des opérations

  • Les abonnements à GraphQL nouveaux et anciens qui sont enregistrés

Journaux au niveau du terrain

Lorsque la journalisation au niveau des champs est configurée, les informations suivantes sont enregistrées :

  • Mappage des demandes généré avec la source et les arguments pour chaque champ

  • Le mappage de réponse transformé pour chaque champ, qui inclut les données résultant de la résolution de ce champ

  • Suivi des informations pour chaque champ

Si vous activez la journalisation, AWS AppSync gère les CloudWatch journaux. Le processus comprend la création de groupes de journaux et de flux de journaux, et la génération de rapports dans les flux de journaux avec ces journaux.

Lorsque vous activez la journalisation sur une API GraphQL et que vous envoyez des requêtes, vous AWS AppSync créez un groupe de journaux et enregistrez des flux sous le groupe de journaux. Le groupe de journaux est nommé selon le format /aws/appsync/apis/{graphql_api_id}. Dans chaque groupe de journaux, les journaux sont également divisés en flux de journaux. Ces derniers sont classés selon l'heure du dernier événement lors de la consignation des données.

Chaque événement du journal est étiqueté avec le x-amzn- RequestId de cette demande. Cela vous permet de filtrer les événements de connexion CloudWatch afin d'obtenir toutes les informations enregistrées concernant cette demande. Vous pouvez l'obtenir RequestId à partir des en-têtes de réponse de chaque requête AWS AppSync GraphQL.

La journalisation au niveau du champ est configurée avec les niveaux de journaux suivants :

  • Aucun : aucun journal au niveau du champ n'est capturé.

  • Erreur : enregistre les informations suivantes uniquement pour les champs erronés :

    • Section d'erreur dans la réponse du serveur

    • Erreurs au niveau du champ

    • Fonctions de demande/réponse générées qui ont été résolues pour les champs d'erreur

  • Tout : enregistre les informations suivantes pour tous les champs de la requête :

    • Informations de suivi au niveau du champ

    • Fonctions de demande/réponse générées qui ont été résolues pour chaque champ

Avantages de la surveillance

Vous pouvez utiliser la journalisation et les métriques pour identifier, dépanner et optimiser vos requêtes GraphQL. Par exemple, cela vous aidera à déboguer les problèmes de latence à l'aide des informations de suivi consignées pour chaque champ de la requête. Pour illustrer cela, supposons que vous utilisiez un ou plusieurs résolveurs imbriqués dans une requête GraphQL. Un exemple d'opération sur le terrain dans CloudWatch Logs peut ressembler à ce qui suit :

{
    "path": [
        "singlePost",
        "authors",
        0,
        "name"
    ],
    "parentType": "Post",
    "returnType": "String!",
    "fieldName": "name",
    "startOffset": 416563350,
    "duration": 11247
}

Cela peut correspondre à un schéma GraphQL, comme illustré ci-dessous :

type Post {
  id: ID!
  name: String!
  authors: [Author]
}

type Author {
  id: ID!
  name: String!
}

type Query {
  singlePost(id:ID!): Post
}

Dans les résultats du journal précédents, le chemin indique un seul élément de vos données renvoyées par l'exécution d'une requête nomméesinglePost(). Dans cet exemple, il représente le champ de nom du premier index (0). Le StartOffset donne un décalage par rapport au début de l'opération de requête GraphQL. La durée est le temps total de résolution du champ. Ces valeurs peuvent être utiles afin de déterminer la raison pour laquelle les données d'une source de données spécifique sont exécutées plus lentement que prévu, ou si un champ spécifique ralentit l'ensemble de la requête. Par exemple, vous pouvez choisir d'augmenter le débit provisionné pour une table Amazon DynamoDB ou de supprimer un champ spécifique d'une requête qui nuit aux performances globales de l'opération.

Depuis le 8 mai 2019, AWS AppSync génère des événements de journal sous forme de JSON entièrement structuré. Cela peut vous aider à utiliser les services d'analyse des CloudWatch journaux tels que Logs Insights et Amazon OpenSearch Service pour comprendre les performances de vos requêtes GraphQL et les caractéristiques d'utilisation de vos champs de schéma. Par exemple, vous pouvez identifier facilement les résolveurs rencontrant des latences importantes et qui pourraient être la cause profonde d'un problème de performances. Vous pouvez également identifier les champs utilisés le plus et le moins fréquemment dans votre schéma et évaluer l'impact des dépréciations des champs GraphQL.

Détection des conflits et journalisation des synchronisations

Si une AWS AppSync API a configuré la journalisation dans CloudWatch les journaux avec le niveau de journalisation du résolveur de champs défini sur Tous, les informations relatives à AWS AppSync la détection et à la résolution des conflits sont transmises au groupe de journaux. Cela fournit un aperçu détaillé de la manière dont l' AWS AppSync API a répondu à un conflit. Pour vous aider à interpréter la réponse, les informations suivantes sont fournies dans les journaux :

conflictType

Détermine si un conflit s'est produit en raison d'une incompatibilité de version ou de la condition fournie par le client.

conflictHandlerConfigured

État le gestionnaire de conflits configuré sur le résolveur au moment de la demande.

message

Fournit des informations sur la façon dont le conflit a été détecté et résolu.

syncAttempt

Nombre d'essais du serveur pour synchroniser les données avant de rejeter la demande.

data

Si le gestionnaire de conflits configuré l'estAutomerge, ce champ est renseigné pour indiquer la décision Automerge prise pour chaque champ. Les actions proposées peuvent être les suivantes :

  • REJETÉ - Automerge Lorsque la valeur du champ entrant est rejetée en faveur de la valeur du serveur.

  • AJOUTÉ - Lors de l'Automergeajout du champ entrant en raison de l'absence de valeur préexistante sur le serveur.

  • AJOUTÉ - Quand Automerge ajoute les valeurs entrantes aux valeurs de la liste qui existe sur le serveur.

  • AutomergeMERGED - Lorsque fusionne les valeurs entrantes avec les valeurs de l'ensemble existant sur le serveur.

Utiliser le nombre de jetons pour optimiser vos demandes

Un jeton est alloué aux requêtes consommant moins de 1 500 Ko de secondes de mémoire et de temps de vCPU. Les demandes dont la consommation de ressources est supérieure à 1 500 kB-secondes reçoivent des jetons supplémentaires. Par exemple, si une demande consomme 3 350 Ko de secondes, AWS AppSync alloue trois jetons (arrondis à la valeur entière suivante) à la demande. Par défaut, AWS AppSync alloue un maximum de 2 000 jetons de demande par seconde aux API de votre compte, par région. AWS Si vos API utilisent chacune en moyenne deux jetons par seconde, vous serez limité à 1 000 requêtes par seconde. Si vous avez besoin de plus de jetons par seconde que le montant alloué, vous pouvez soumettre une demande pour augmenter le quota par défaut pour le taux de jetons de demande. Pour plus d'informations, consultez les rubriques AWS AppSyncPoints de terminaison et quotas dans le Références générales AWS guide et Demande d'augmentation des quotas dans le Guide de l'utilisateur du Service Quotas.

Un nombre élevé de jetons par demande peut indiquer qu'il est possible d'optimiser vos demandes et d'améliorer les performances de votre API. Les facteurs susceptibles d'augmenter le nombre de jetons par demande sont les suivants :

  • La taille et la complexité de votre schéma GraphQL.

  • La complexité des modèles de mappage des demandes et des réponses.

  • Le nombre d'appels au résolveur par demande.

  • La quantité de données renvoyées par les résolveurs.

  • La latence des sources de données en aval.

  • Modèles de schéma et de requête qui nécessitent des appels successifs à la source de données (par opposition aux appels en parallèle ou par lots).

  • Configuration de journalisation, en particulier au niveau du champ et contenu détaillé des journaux.

Note

Outre les AWS AppSync métriques et les journaux, les clients peuvent accéder au nombre de jetons consommés dans une demande via l'en-tête de réponsex-amzn-appsync-TokensConsumed.

Référence du type de journal

RequestSummary

  • requestId : identifiant unique de la demande.

  • graphQLAPIId : ID de l'API GraphQL effectuant la demande.

  • StatusCode : réponse au code d'état HTTP.

  • latence : nd-to-end latence E de la demande, en nanosecondes, sous forme de nombre entier.

{
     "logType": "RequestSummary",
     "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
     "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4",
     "statusCode": 200,
     "latency": 242000000
}

ExecutionSummary

  • requestId : identifiant unique de la demande.

  • graphQLAPIId : ID de l'API GraphQL effectuant la demande.

  • StartTime : horodatage de début du traitement GraphQL de la demande, au format RFC 3339.

  • EndTime : horodatage de fin du traitement GraphQL de la demande, au format RFC 3339.

  • durée : le temps de traitement total écoulé par GraphQL, en nanosecondes, sous forme d'entier.

  • version : version du schéma du ExecutionSummary.

  • parsing :

    • StartOffset : le décalage de départ pour l'analyse, en nanosecondes, par rapport à l'invocation, sous la forme d'un entier.

    • duration : temps consacré à l'analyse, en nanosecondes, indiqué en tant que nombre entier.

  • validation :

    • StartOffset : le décalage de départ pour la validation, en nanosecondes, par rapport à l'invocation, sous forme d'entier.

    • duration : temps consacré à la validation, en nanosecondes, indiqué en tant que nombre entier.

{
    "duration": 217406145,
    "logType": "ExecutionSummary",
    "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
    "startTime": "2019-01-01T06:06:18.956Z",
    "endTime": "2019-01-01T06:06:19.174Z",
    "parsing": {
        "startOffset": 49033,
        "duration": 34784
    },
    "version": 1,
    "validation": {
        "startOffset": 129048,
        "duration": 69126
    },
    "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4"
}

Tracing

  • requestId : identifiant unique de la demande.

  • graphQLAPIId : ID de l'API GraphQL effectuant la demande.

  • StartOffset : décalage de départ pour la résolution du champ, en nanosecondes, par rapport à l'invocation, sous forme d'entier.

  • duration : temps consacré à la résolution du champ, en nanosecondes, indiqué en tant que nombre entier.

  • fieldName : nom du champ en cours de résolution.

  • parentType : type de parent du champ en cours de résolution.

  • returnType : type de retour du champ en cours de résolution.

  • path : liste des segments de chemin, commençant à la racine de la réponse et se terminant par le champ en cours de résolution.

  • resolverArn : ARN du résolveur utilisé pour la résolution des champs. Peut ne pas être présent sur les champs imbriqués.

{
    "duration": 216820346,
    "logType": "Tracing",
    "path": [
        "putItem"
    ],
    "fieldName": "putItem",
    "startOffset": 178156,
    "resolverArn": "arn:aws:appsync:us-east-1:111111111111:apis/pmo28inf75eepg63qxq4ekoeg4/types/Mutation/fields/putItem",
    "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
    "parentType": "Mutation",
    "returnType": "Item",
    "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4"
}

Analyser vos journaux avec CloudWatch Logs Insights

Voici des exemples de requêtes que vous pouvez exécuter pour obtenir des informations exploitables sur les performances et l'état de vos opérations GraphQL. Ces exemples sont disponibles sous forme d'exemples de requêtes dans la console CloudWatch Logs Insights. Dans la CloudWatchconsole, choisissez Logs Insights, sélectionnez le groupe de AWS AppSync journaux pour votre API GraphQL, puis choisissez des AWS AppSync requêtes sous Exemples de requêtes.

La requête suivante renvoie les 10 principales requêtes GraphQL avec un maximum de jetons consommés :

filter @message like "Tokens Consumed"
| parse @message "* Tokens Consumed: *" as requestId, tokens
| sort tokens desc
| display requestId, tokens
| limit 10

La requête suivante renvoie les 10 principaux résolveurs rencontrant une latence maximale :

  fields resolverArn, duration
| filter logType = "Tracing"
| limit 10
| sort duration desc

La requête suivante renvoie les résolveurs les plus fréquemment appelés :

  fields ispresent(resolverArn) as isRes
| stats count() as invocationCount by resolverArn
| filter isRes and logType = "Tracing"
| limit 10
| sort invocationCount desc

La requête suivante renvoie les résolveurs rencontrant le plus grand nombre d'erreurs dans les modèles de mappage :

  fields ispresent(resolverArn) as isRes
| stats count() as errorCount by resolverArn, logType
| filter isRes and (logType = "RequestMapping" or logType = "ResponseMapping") and fieldInError
| limit 10
| sort errorCount desc

La requête suivante renvoie les statistiques de latence du résolveur :

  fields ispresent(resolverArn) as isRes
| stats min(duration), max(duration), avg(duration) as avg_dur by resolverArn
| filter isRes and logType = "Tracing"
| limit 10
| sort avg_dur desc

La requête suivante renvoie les statistiques de latence du champ :

  stats min(duration), max(duration), avg(duration) as avg_dur
  by concat(parentType, '/', fieldName) as fieldKey
| filter logType = "Tracing"
| limit 10
| sort avg_dur desc

Les résultats des requêtes CloudWatch Logs Insights peuvent être exportés vers des CloudWatch tableaux de bord.

Analysez vos journaux avec OpenSearch Service

Vous pouvez rechercher, analyser et visualiser vos AWS AppSync journaux avec Amazon OpenSearch Service afin d'identifier les goulots d'étranglement liés aux performances et les causes profondes des problèmes opérationnels. Vous pouvez identifier les résolveurs rencontrant la latence maximale et le maximum d'erreurs. En outre, vous pouvez utiliser les OpenSearch tableaux de bord pour créer des tableaux de bord dotés de puissantes visualisations. OpenSearch Dashboards est un outil de visualisation et d'exploration de données open source disponible dans OpenSearch Service. À l'aide OpenSearch des tableaux de bord, vous pouvez surveiller en permanence les performances et l'état de vos opérations GraphQL. Par exemple, vous pouvez créer des tableaux de bord pour visualiser la latence P90 de vos requêtes GraphQL et analyser les latences P90 de chaque résolveur.

Lorsque vous utilisez OpenSearch Service, utilisez « cwl* » comme modèle de filtre pour rechercher OpenSearch des index. OpenSearch Le service indexe les journaux diffusés depuis CloudWatch Logs avec le préfixe « cwl - ». Pour différencier les journaux d' AWS AppSync API CloudWatch des autres journaux envoyés au OpenSearch Service, nous vous recommandons d'ajouter une expression de filtre supplémentaire graphQLAPIID.keyword=YourGraphQLAPIID à votre recherche.

Migration du format de journal

Les événements de journal AWS AppSync générés le 8 mai 2019 ou après cette date sont formatés au format JSON entièrement structuré. Pour analyser les requêtes GraphQL antérieures au 8 mai 2019, vous pouvez migrer les anciens journaux vers du JSON entièrement structuré à l'aide d'un script disponible dans l'GitHub exemple. Si vous avez besoin d'utiliser le format de journal antérieur au 8 mai 2019, créez un ticket de support avec les paramètres suivants : définissez Type sur Account Management (Gestion de compte), puis définissez Category (Catégorie) sur General Account Question (Question d'ordre général sur le compte).

Vous pouvez également utiliser des filtres métriques CloudWatch pour transformer les données du journal en CloudWatch métriques numériques, afin de pouvoir les représenter graphiquement ou de définir une alarme.