Utilisation CloudWatch pour surveiller et enregistrer les données GraphQL API - 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.

Utilisation CloudWatch pour surveiller et enregistrer les données GraphQL API

Vous pouvez enregistrer et déboguer votre API GraphQL à l' CloudWatch aide de métriques CloudWatch et de journaux. Ces outils permettent aux développeurs de surveiller les performances, de résoudre les problèmes et d'optimiser efficacement leurs opérations GraphQL.

CloudWatch metrics est un outil qui fournit un large éventail de mesures pour surveiller les API performances et l'utilisation. Ces indicateurs se répartissent en deux catégories principales :

  1. APIMesures générales : elles permettent notamment 4XXError de suivre 5XXError les erreurs des clients et des serveurs, de mesurer Latency les temps de réponse, Requests de surveiller le nombre total d'APIappels et TokensConsumed de suivre l'utilisation des ressources.

  2. Mesures d'abonnement en temps réel : ces statistiques se concentrent sur WebSocket les connexions et les activités d'abonnement. Ils incluent des mesures relatives aux demandes de connexion, aux connexions réussies, aux inscriptions aux abonnements, à la publication de messages, ainsi qu'aux connexions et abonnements actifs.

Le guide présente également les métriques améliorées, qui fournissent des données plus détaillées sur les performances du résolveur, les interactions entre les sources de données et les opérations GraphQL individuelles. Ces indicateurs fournissent des informations plus approfondies, mais entraînent des coûts supplémentaires.

CloudWatch Logs est un outil qui active les fonctionnalités de journalisation pour votre GraphQLAPIs. Les journaux peuvent être définis à deux niveaux API :

  1. Journaux au niveau des demandes : ils capturent les informations générales des demandes, notamment les HTTP en-têtes, les requêtes GraphQL, les résumés des opérations et les enregistrements d'abonnements.

  2. Journaux au niveau des champs : ils fournissent des informations détaillées sur les résolutions des champs individuels, y compris les mappages des demandes et des réponses, et les informations de suivi pour chaque champ.

Vous pouvez configurer la journalisation, interpréter les entrées du journal et utiliser les données du journal pour le dépannage et l'optimisation. AWS AppSync fournit différents types de journaux qui révèlent les données d'exécution, d'analyse, de validation et de résolution des champs de votre requête.

Installation et configuration

Pour activer la journalisation automatique sur un GraphQLAPI, utilisez la AWS AppSync console.

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

  2. Sur la APIspage, choisissez le nom d'un GraphQLAPI.

  3. Sur votre page API d'accueil, 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 AWS AppSync d'écrire des journaux CloudWatch. Vous pouvez également choisir Rôle existant pour sélectionner le nom de ressource Amazon (ARN) d'un IAM rôle existant dans votre AWS compte.

  5. Choisissez Enregistrer.

Configuration manuelle des IAM rôles

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

Dans la IAMconsole, 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 le rôle ARN et utilisez-le lors de la configuration de la journalisation pour un AWS AppSync GraphQLAPI.

CloudWatch métriques

Vous pouvez utiliser CloudWatch des métriques pour surveiller et émettre des alertes concernant des événements spécifiques susceptibles de générer des codes HTTP d'état 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 JSON charge utile 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 APIs l'ensemble 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 car 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 un individu API en spécifiant le 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 un ID API spécifié.

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'CPUutilisation (pourcentage) allouée au OSS processus Redis. Cela est utile pour diagnostiquer les goulots d'étranglement dans une configuration de cache. Les données sont enregistrées pour un individu API en spécifiant le API_Id dans la appsyncCacheEngineCPUUtilization métrique.

Unité : Pourcentage. Le CPU pourcentage actuellement utilisé par le OSS processus Redis pour un ID API spécifié.

Abonnements en temps réel

Toutes les métriques sont émises dans une seule dimension : raphQLAPIIdG. Cela signifie que toutes les métriques sont couplées à GraphQL APIIDs. 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 JSON charge utile 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 côté 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

Le 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

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

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

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

Le 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 API demandes non valides.

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

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 API l'utilisation et les performances, 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 API paramètres, la section Mesures améliorées vous permet d'activer ou de désactiver les éléments suivants :

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 :

GraphQL errors per resolver (GraphQLError)

Le nombre d'erreurs GraphQL survenues par résolveur.

Dimension métrique :API_Id, Resolver

Unité : nombre.

Requests per resolver (Request)

Le nombre d'invocations survenues lors d'une demande. Ceci est enregistré par résolveur.

Dimension métrique :API_Id, Resolver

Unité : nombre.

Latency per resolver (Latency)

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.

Dimension métrique :API_Id, Resolver

Unité : milliseconde.

Cache hits per resolver (CacheHit)

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.

Dimension métrique :API_Id, Resolver

Unité : nombre.

Cache misses per resolver (CacheMiss)

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.

Dimension métrique :API_Id, Resolver

Unité : nombre.

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 :

Requests per data source (Request)

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.

Dimension métrique :API_Id, Datasource

Unité : nombre.

Latency per data source (Latency)

Le temps nécessaire pour terminer l'invocation d'une source de données. La latence est enregistrée pour chaque source de données.

Dimension métrique :API_Id, Datasource

Unité : milliseconde.

Errors per data source (GraphQLError)

Nombre d'erreurs survenues lors d'un appel de source de données.

Dimension métrique :API_Id, Datasource

Unité : nombre.

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

Requests per operation (Request)

Le nombre de fois qu'une opération GraphQL spécifiée a été appelée.

Dimension métrique :API_Id, Operation

Unité : nombre.

GraphQL errors per operation (GraphQLError)

Nombre d'erreurs GraphQL survenues lors d'une opération GraphQL spécifiée.

Dimension métrique :API_Id, Operation

Unité : nombre.

CloudWatch journaux

Vous pouvez configurer deux types de journalisation sur n'importe quel GraphQL nouveau ou existant API : 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

  • Les HTTP en-têtes de demande et de réponse

  • 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 un GraphQL API 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 pour 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). startOffsetCela donne un décalage par rapport au début de l'opération de requête GraphQL. La durée est le temps total nécessaire pour résoudre le 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 entièrement structurésJSON. 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 la AWS AppSync API journalisation dans les CloudWatch journaux est configurée avec le niveau de journal du résolveur de champs défini sur Tous, AWS AppSync émet des informations de détection et de résolution des conflits vers le groupe de journaux. Cela donne un aperçu détaillé de la manière dont ils AWS AppSync API ont 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 :

  • REJECTED- Lorsque Automerge rejette la valeur du champ entrant en faveur de la valeur du serveur.

  • ADDED- Lorsqu'il est Automerge ajouté au champ entrant en raison de l'absence de valeur préexistante sur le serveur.

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

  • MERGED- Quand Automerge 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 kB-secondes de mémoire et en CPU temps de réponse. 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 5 000 ou 10 000 jetons de demande par seconde APIs à votre compte, selon la AWS région dans laquelle il est déployé. Si APIs chacun utilise en moyenne deux jetons par seconde, vous serez limité à 2 500 ou 5 000 demandes par seconde, respectivement. 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 AppSync Points 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 vosAPI. Les facteurs susceptibles d'augmenter le nombre de jetons par demande sont les suivants :

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

  • 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.

Limites de taille des journaux

Par défaut, si la journalisation a été activée, elle AWS AppSync enverra jusqu'à 1 Mo de journaux par demande. Les journaux dépassant cette taille seront tronqués. Pour réduire la taille des journaux, choisissez le niveau de ERROR journalisation pour les journaux au niveau du champ et désactivez la VERBOSE journalisation, ou désactivez complètement les journaux au niveau du champ si cela n'est pas nécessaire. Comme alternative au niveau de ALL journalisation, vous pouvez utiliser les métriques améliorées pour obtenir des métriques sur des résolveurs, des sources de données ou des opérations GraphQL spécifiques, ou utiliser les utilitaires de journalisation fournis AppSync par pour enregistrer uniquement les informations nécessaires.

Référence du type de journal

RequestSummary

  • requestId: identifiant unique de la demande.

  • graphQLAPIId: ID du GraphQL à l'origine de la API requête.

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

  • 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 du GraphQL à l'origine de la API requête.

  • startTime: horodatage de début du traitement GraphQL de la requête, au format 3339. RFC

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

  • 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 forme d'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 du GraphQL à l'origine de la API requête.

  • startOffset: le décalage de début 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: le type 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 de champ. 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 GraphQLAPI, 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 AWS AppSync API les journaux des autres CloudWatch 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 du journal AWS AppSync générés le 8 mai 2019 ou après cette date sont formatés de manière entièrement structuréeJSON. Pour analyser les requêtes GraphQL antérieures au 8 mai 2019, vous pouvez migrer les anciens journaux vers des journaux entièrement structurés à JSON 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.