Surveillance et journalisation - AWS AppSync

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 votreAWS AppSync API GraphQL et aide à déboguer les problèmes liés aux demandes, vous pouvez activer la journalisation sur Amazon CloudWatch Bûches.

Installation et configuration

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

  1. Connectez-vous à la consoleAWSconsole AppSync.

  2. Dans la pageAPI, choisissez le nom d'une API GraphQL.

  3. Dans la page d'accueil de votre API, dans le volet de navigation, choisissezParamètres.

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

    1. Activation d'Activer les journaux.

    2. (Facultatif) Pour une journalisation détaillée au niveau des demandes, cochez la case sousInclure du contenu détaillé.

    3. (Facultatif) SousNiveau de journalisation du solveur de champ, choisissez votre niveau de journalisation préféré au niveau du champ (Aucun,Erreur, ouTous).

    4. SousCréation ou utilisation d'un rôle existant, choisissezNouveau rôlepour créer un nouveauAWS Identity and Access Management(IAM) qui permetAWS AppSync pour écrire des journaux dans CloudWatch. Ou bien, choisissezRôle existantpour sélectionner l'Amazon Resource Name (ARN) d'un rôle IAM existant dans votreAWS.

  5. Choisissez Save (Enregistrer).

Configuration manuelle du rôle IAM

Si vous choisissez d'utiliser un rôle IAM existant, le rôle doit accorder.AWS AppSync autorisations requises pour écrire des journaux dans CloudWatch. Pour le configurer manuellement, vous devez fournir un ARN de rôle de service afin queAWS AppSync peut assumer le rôle lors de la rédaction des journaux.

Dansconsole IAM, créez une stratégie avec le nomAWSAppSyncPushToCloudWatchLogsPolicyqui comporte la définition suivante :

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

Ensuite, créez un nouveau rôle avec le nom.Rôle Push to CloudWatch Logs d'AWS App Syncet attachez la stratégie nouvellement créée au rôle. Modifiez la relation d'approbation de 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 d'unAWS AppSync API GraphQL.

mesures CloudWatch

Vous pouvez utiliser CloudWatch métriques pour surveiller et fournir des alertes sur des événements spécifiques susceptibles d'entraîner des codes de statut HTTP ou par latence. Les métriques suivantes sont émises.

4XXError

Erreurs résultant de demandes non valides en raison d'une configuration incorrecte du client. En général, ces erreurs peuvent se produire n'importe où en dehors de GraphQL.En traitement. Par exemple, ces erreurs peuvent se produire lorsque la requête inclut une charge utile JSON incorrecte ou une requête incorrecte, lorsque le service rencontre un goulets d'étranglement 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 lacoursed'une requête GraphQL. Par exemple, cela peut se produire lorsque vous invoquez une requête pour un schéma vide ou incorrect. Cela peut également se produire lorsque l'ID de pool d'utilisateurs Amazon Cognito ouAWSLa région n'est pas valide. Sinon, cela pourrait également se produire siAWS AppSync rencontre un problème lors du traitement d'une demande.

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

Latency

Délai entre le moment où 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é : Millisecondes. Utilisez la statistique Moyenne pour évaluer les latences attendues.

Requests

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

Unité : Nombre. Nombre de toutes les demandes traitées dans une région particulière.

TokensConsumed

Les jetons sont alloués àRequestsen fonction de la quantité de ressources (temps de traitement et mémoire utilisée) qu'unRequestconsomme. Généralement, chaqueRequestconsomme un jeton. Cependant, unRequestqui consomme de grandes quantités de ressources se voit attribuer des jetons supplémentaires au besoin.

Unité : Nombre. Nombre de jetons alloués aux demandes traitées dans une région particulière.

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 WebSockets purs :

ConnectSuccess

Nombre de succès WebSocket connexions àAWSAppSync. 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 qui ont été rejetées parAWS AppSync en raison d'erreurs côté client. Cela peut impliquer que le service rencontre un goulets d'étranglement 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 retournées par 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

Nombre de succès WebSocket déconnexions deAWSAppSync.

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

DisconnectClientError

Nombre d'erreurs client retournées parAWS AppSync lors de la déconnexion 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 retournées parAWS AppSync lors de la déconnexion WebSocket connexions.

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

SubscribeSuccess

Nombre d'abonnements qui ont été enregistrés avec succès surAWSAppSync via WebSocket. Il est possible d'avoir des connexions sans abonnements, 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

Nombre d'abonnements qui ont été rejetés par AWS AppSync en raison d'erreurs côté client. Cela peut se produire lorsqu'une charge utile JSON est incorrecte, que le service rencontre un goulets d'étranglement 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 retournées par 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

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

Unité : Nombre. Utilisez la statistique Sum (Somme) pour obtenir le total des occurrences de des demandes d'échec d'abonnement.

UnsubscribeClientError

Nombre de demandes d'exclusion d'abonnement ayant été rejetées parAWS AppSync en raison d'erreurs côté client.

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

UnsubscribeServerError

Nombre d'erreurs retournées parAWS 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 (Somme) pour obtenir le total des occurrences d'erreurs 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 :Nombre. 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 retournées par AWS AppSync lors de la publication des messages d'événement 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

Nombre de simultanés WebSocket connexions entre les clients etAWS 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.

InvalidationSuccess

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

Unité : Nombre. Utilisez la statistique Sum (Somme) pour récupérer le nombre total d'abonnements qui ont été désabonnés avec succès pour obtenir.

CloudWatch Logs

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 requêtes

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

  • Nombre de jetons consommés

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

  • La requête GraphQL en cours d'exécution dans la demande

  • Résumé global des opérations

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

Journaux au niveau du champ

Lorsque la journalisation au niveau du champ est configurée, les informations suivantes sont consignées :

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

  • Mappage des réponses transformées pour chaque champ, ce qui inclut les données obtenues à la suite de la résolution de ce champ.

  • Suivi des informations pour chaque champ

Si vous activez la journalisation,AWS AppSync gère le CloudWatch Bûches. 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 effectuez des demandes,AWS AppSync crée un groupe de journaux et des flux de journaux 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 de journal est balisé avec l'ID x-amzn-RequestId de cette demande. Cela vous aide à filtrer les événements de journal dans CloudWatch pour obtenir toutes les informations enregistrées sur cette demande. Vous pouvez obtenir le RequestId à partir des en-têtes de réponse de chaque GraphQLAWS AppSync de la demande.

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- Consigne les informations suivantesseulementpour les champs comportant une erreur :
    • 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

  • Tous- Consigne les informations suivantes pourtouschamps 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 Les journaux peuvent ressembler à l'exemple ci-dessous :

{ "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édent,cheminaffiche un élément unique dans vos données renvoyées de l'exécution d'une requête nomméesinglePost(). Dans cet exemple, il représente lanomau premier index (0). LestartOffsetdonne un décalage par rapport au début de l'opération de requête GraphQL. Leduréecorrespond à la durée totale 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 alloué pour une table Amazon DynamoDB, ou supprimer un champ spécifique à partir d'une requête qui nuit aux bonnes performances d'exécution globale.

Depuis le 8 mai 2019, AWS AppSync génère les événements de journaux dans un format JSON entièrement structuré. Cela peut vous aider à utiliser les services d'analyse des journaux tels que CloudWatch Logs Insights et Amazon OpenSearch Service pour comprendre les performances de vos demandes 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 de synchronisation

Si unAWS AppSync L'API se connecte à CloudWatch Journaux configurés avec leNiveau de journalisation du solveur de champréglé àTous, puisAWS AppSync émet des informations de détection et de résolution des conflits au groupe de journaux. Cela fournit un aperçu granulaire de la façon dont leAWS AppSync L'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é estAutomerge, ce champ est renseigné pour indiquer quelle décisionAutomergepris pour chaque champ. Les actions proposées peuvent être les suivantes :

  • REJETÉS- LorsqueAutomergerejette la valeur du champ entrant en faveur de la valeur dans le serveur.

  • AJOUTÉE- LorsqueAutomergeajoute sur le champ entrant en raison de l'absence de valeur préexistante dans le serveur.

  • ANNEXÉ- LorsqueAutomergeajoute les valeurs entrantes aux valeurs de la liste qui existe dans le serveur.

  • FUSIONNÉ- LorsqueAutomergefusionne les valeurs entrantes aux valeurs de l'ensemble qui existe dans le serveur.

Utiliser le nombre de jetons pour optimiser vos demandes

Les demandes qui consomment moins ou égale à 1 500 KB-secondes de mémoire et de temps vCPU se voient attribuer un jeton. 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 KB-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, parAWSRégion . Si vos API utilisent chacune en moyenne deux jetons par seconde, vous serez limité à 1 000 demandes par seconde. Si vous avez besoin de plus de jetons par seconde que le montant alloué, vous pouvez soumettre une demande d'augmentation du quota par défaut pour le taux de jetons de demande. Pour de plus amples informations, veuillez consulterAWSPoints de terminaison et quotas AppSyncdans leAWSGuide de référence généraleetDemande d'augmentation de quotadans leGuide de l'utilisateur 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 qui peuvent 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 de requêtes et de réponses.

  • Nombre d'appels de résolveur par demande.

  • Volume de données retournées par les résolveurs.

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

  • Conceptions de schémas et de requêtes nécessitant des appels successifs de sources de données (par opposition aux appels parallèles ou par lots).

  • Configuration de la journalisation, en particulier le contenu des journaux au niveau du champ et complet.

Note

En plus deAWS AppSync métriques et 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 de 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 : latence de bout en bout de la demande, en nanosecondes, indiquée en tant que 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 : endTime horodatage de fin du traitement GraphQL de la demande, au format RFC 3339.

  • Durée : Duration Temps total de traitement GraphQL écoulé, en nanosecondes, indiqué en tant que nombre entier.

  • Version  : Version de schéma de l'ExecutionSummary.

  • parsing :
    • startOffset : Décalage de début de l'analyse, en nanosecondes, par rapport à l'appel, indiqué en tant que nombre entier.

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

  • validation :
    • startOffset : Décalage de début de la validation, en nanosecondes, par rapport à l'appel, indiqué en tant que nombre entier.

    • Durée : 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ébut de la résolution du champ, en nanosecondes, par rapport à l'appel, indiqué en tant que nombre entier.

  • Durée : 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.

  • chemin : 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" }

Analyse de 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 CloudWatch Console Logs Insights. DansConsole CloudWatch, choisissezLogs Insights, sélectionnez la caseAWS AppSync groupe de journaux pour votre API GraphQL, puis choisissezAWS AppSyncrequêtessousExemples de requêtes.

La requête suivante renvoie les 10 principales demandes GraphQL rencontrant 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 de CloudWatch Les requêtes Logs Insights peuvent être exportées vers CloudWatch tableaux de bord.

Analyse de vos journaux avec OpenSearch Service

Vous pouvez rechercher, analyser et visualiser votreAWS AppSync journaux avec Amazon OpenSearch Service permettant d'identifier les goulets d'étranglement des 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. De plus, vous pouvez utiliser OpenSearch Tableaux de bord pour créer des tableaux de bord avec de puissantes visualisations. OpenSearch Dashboards est un outil de visualisation et d'exploration de données open source disponible dans OpenSearch Service. A l'aide de OpenSearch Dans les tableaux de bord, vous pouvez surveiller en continu 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 demandes GraphQL et explorer en détail les latences P90 de chaque résolveur.

Lorsque vous utilisez OpenSearch Service, utilisation« CWL * »en tant que modèle de filtre à rechercher OpenSearch index. OpenSearch Le service indexe les journaux diffusés depuis CloudWatch Journaux avec un préfixe de« CWL- ». Pour différencierAWS AppSync Journaux API d'autres CloudWatch journaux envoyés à OpenSearch Service, nous vous recommandons d'ajouter une expression de filtre supplémentaire degraphQLAPIID.keyword=YourGraphQLAPIIDà votre recherche.

Migration du format des journaux

Journalisation d'événements quiAWS AppSync générés à partir du 8 mai 2019 sont au format JSON entièrement structuré. Pour analyser des demandes GraphQL antérieures au 8 mai 2019, vous pouvez migrer les anciens journaux vers un journal au format JSON entièrement structuré à l'aide d'un script disponible dans leExemple GitHub. 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 utiliserfiltres de métriquesdans CloudWatch pour transformer les données de journal en données numériques CloudWatch métriques, afin de pouvoir les représenter graphiquement ou les utiliser pour définir une alarme.