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 :

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 :

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.

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 :

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

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.

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 :

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étriques d'opération : active les métriques au niveau des opérations GraphQL.

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 :

Journaux au niveau du terrain

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

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

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 :

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 à votre compte, APIs en fonction de 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 :

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

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

ExecutionSummary

{
    "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

{
    "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.