Le Blog Amazon Web Services
Gagnez en visibilité sur les performances de GraphQL grâce aux logs AWS Appsync
8 Septembre 2021 : Amazon Elasticsearch Service a été renommé en Amazon OpenSearch Service. Voir les détails.
Les fonctionnalités de logs AWS AppSync vous permettent de mieux appréhender les performances de vos requêtes GraphQL et les caractéristiques d’utilisation de vos schémas. Les logs simplifient l’identification des résolveurs (“resolvers”) présentant une plus grande latence et pouvant donc être à l’origine de faibles performances. Ils permettent aussi d’identifier les champs du schéma les moins utilisés, et d’évaluer l’impact de leur suppression. Ces fonctionnalités étaient parmi les plus demandées par nos clients.
AWS AppSync est un service GraphQL managé qui simplifie le développement d’application en vous permettant de créer une API flexible et sécurisée permettant de manipuler et combiner des données depuis une ou plusieurs sources. AWS AppSync émet des évènements de log structurés au format JSON. Cela permet leur intégration transparente avec des services d’analyse de logs tels que Amazon CloudWatch Logs Insights et Amazon Elasticsearch Service (Amazon ES), ou d’autres solutions.
De nouveaux champs ont aussi été ajoutés aux logs pour augmenter la visibilité sur la performance et la santé de vos opérations GraphQL :
- Pour chercher et analyser un ou plusieurs types de logs, des requêtes GraphQL ou des actions diverses de l’API GraphQL, de nouveaux champs (
logType,requestIdetgraphQLAPIId) sont disponibles pour chaque évènement émis par AWS AppSync, - Pour identifier rapidement les erreurs et les goulots d’étranglements responsables de faibles performances, de nouveaux champs ont été ajoutés aux logs existants au niveau des requêtes. Ces champs contiennent des informations concernant les code de réponses HTTP (
HTTPStatusResponseCode) et la latence d’une requête GraphQL (latency), - Pour exécuter et identifier les requêtes lancées sur n’importe quel champ dans votre schéma GraphQL, de nouveaux champs sont disponibles dans les logs existant au niveau des champs. Ces nouveaux champs contiennent des informations concernant le parent (
parentType) et le nom (fieldName) d’un champ GraphQL, - Pour gagner en visibilité sur le temps de résolution d’un champ GraphQL, l’ARN du resolver (
resolverARN) est présent dans les informations tracées pour les champs GraphQL dans les logs au niveau des champs.
Cet article montre comment obtenir plus de visibilité sur la performance et la santé de vos opérations GraphQL en utilisant CloudWatch Logs Insights et Amazon ES. En pré-requis, il est nécessaire d’activer le logging au niveau des champs pour votre API GraphQL afin que AWS AppSync puisse émettre des logs vers CloudWatch Logs.
Analyse des logs grâce à CloudWatch Logs Insights
Il est possible d’analyser les logs d’AWS AppSync grâce à CloudWatch Logs Insights pour identifier les goulots d’étranglements en terme de performance et les causes des problèmes opérationnels. Cela peut, par exemple, être utilisé pour identifier les resolvers le plus long, le resolver le plus (ou moins) fréquemment invoqué, et le resolver provoquant le plus d’erreurs.
CloudWatch Logs Insights ne nécessite aucune mise en place. En effet, AWS AppSync émet automatiquement les logs vers CloudWatch Logs lorsque le logging au niveau des champs est activé sur une API GraphQL.
Les exemples suivants sont des requêtes donnant accès à un aperçu exploitable des performances et de la santé de vos opérations GraphQL. Pour simplifier, ces exemples ont été ajoutés en tant qu’échantillon de requête dans la console CloudWatch Logs Insights.
Dans la console CloudWatch, naviguez vers Logs, Insights, sélectionnez le groupe de log AWS AppSync correspondant à votre API GraphQL, et choisissez ensuite Sample Queries, AWS AppSync queries.
Afficher le top 10 des requêtes GraphQL par latence
fields requestId, latency
| filter logType = "RequestSummary"
| limit 10
| sort latency desc
Afficher le top 10 des resolvers par latence
fields resolverArn, duration
| filter logType = "Tracing"
| limit 10
| sort duration desc
Resolvers les plus appelés
fields ispresent(resolverArn) as isRes
| stats count() as invocationCount by resolverArn
| filter isRes and logType "Tracing"
| limit 10
| sort invocationCount desc
Resolvers avec le plus d’erreurs dans les templates de mapping
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
Les résultats des requêtes CloudWatch Log Insights peuvent être exportés vers des tableaux de bord CloudWatch. Un template de tableau de bord CloudWatch pour AWS AppSync logs a été ajouté dans le dépôt GitHub AWS Samples.
Analyse des logs avec Amazon ES
Il est possible de rechercher, analyser et visualiser les logs d’AWS AppSync avec Amazon ES pour identifier les goulots d’étranglements en terme de performance et les causes originelles de problèmes opérationnels. Non seulement cela peut se faire pour les resolvers avec le maximum de latence et d’erreurs, mais il est aussi possible d’utiliser Kibana pour créer des tableaux de bords avec des visualisations plus élaborées. Kibana est un outil open source pour l’exploration et la visualisation de données disponible avec Amazon ES.
Il est à noter que cette solution induit les coûts associés au cluster Amazon Elasticsearch Service. Ces coûts sont liés à la taille du cluster donc au type d’instance et de stockage EBS utilisés. L’ensemble des éléments de tarification sont disponibles sur la page de présentation du service. Pour démarrer, les utilisateurs ayant choisi de profiter de l’offre gratuite d’AWS peuvent utiliser Amazon Elasticsearch Service gratuitement, avec jusqu’à 750 heures par mois d’utilisation d’une instance t2.small.elasticsearch et 10 Go par mois de stockage facultatif Amazon EBS (magnétique ou à usage général).
Pour démarrer avec Amazon ES :
- Créez un cluster Amazon ES, si vous n’en avez pas déjà un,
- Dans la console CloudWatch Logs, sélectionnez le groupe de log de votre API GraphQL,
- Choisissez Actions, Stream to Amazon Elasticsearch Service et sélectionnez le cluster Amazon ES vers lequel envoyer vos logs. Vous pouvez ajouter un modèle de filtre de logs pour envoyer un ensemble de logs spécifique. L’exemple ci-dessous correspond à un modèle de filtre pour envoyer les évènements de logs concernant les “RequestSummary”, le “Tracing” et les “ExecutionSummary” de GraphQL pour AWS AppSync
{ ($.logType = "Tracing") || ($.logType = "RequestSummary") || ($.logType = "ExecutionSummary") }
Il est possible de créer des tableaux de bord Kibana pour identifier les goulots d’étranglement en terme de performance et surveiller de manière continue vos opérations GraphQL.
Par exemple, pour débugger un problème de performance, commencez par visualiser le P90 pour la latence de vos requêtes GraphQL et creusez ensuite les latences de chaque resolver.
Suivez les étapes ci-dessous pour mettre en place un tableau de bord Kibana contenant ces visualisations:
- Lancez Kibana et choisissez Dashboard, Create new dashboard,
- Choisissez Add. Comme Visualization Type, choisissez Line,
- Pour le filtre de recherche dans les index Elasticsearch, utilisez cwl*. Elasticsearch indexe les logs envoyés depuis CloudWatch Logs (incluant les logs AWS AppSync) avec le préfixe “cwl-”. Pour différencier les logs AWS AppSync des autres logs CloudWatch Logs envoyés à Amazon ES, il est recommandé d’ajouter un filtre supplémentaire avec l’expression
graphQLAPIID.keyword=<AWS AppSync GraphQL API ID>, - Pour obtenir les données des logs AWS AppSync concernant les requêtes, choisissez Add Filter et utilisez l’expression
logType.keyword=RequestSummary, - Choisissez Metrics, Y-Axis. Pour Aggregation, choisissez Percentile; pour Field, choisissez @timestamp; et pour Interval, choisissez Minute. Cela permet de placer la latence des requêtes GraphQL sur l’axe vertical,
- Choisissez Buckets, X-Axis. Pour Aggregation, choisissez Data Histogram; pour Field, choisissez @timestamp; et pour Interval, choisissez Minute. Cela permet de visualiser les latences des requêtes GraphQL regroupées par intervalle d’une minute. Modifiez cet intervalle pour voir ces latences groupées de manière plus grossière ou plus fine en fonction de la densité de vos données,
- Sauvegardez votre widget et ajoutez au tableau de bord Kibana :
- Pour construire un widget permettant de visualiser le P90 des latences de chaque resolver, répétez les étapes 1 à 4 précédentes. A l’étape 4, changez l’expression de filtre par
logType.keyword=Tracingpour obtenir les latences des resolvers depuis AWS AppSync Logs, - Répétez l’étape 5 en utilisant duration comme choix de Field, puis répétez l’étape 6,
- Choisissez Add sub-buckets, Split Series. Pour Sub Aggregation, utilisez Terms et pour Field, choisissez
resolverArn.keyword. Cela permet de visualiser les latences individuelles de chaque resolver, - Sauvegardez votre widget, et ajoutez le au tableau de bord Kibana :
Voici un tableau de bord Kibana complet contenant les widgets pour le P90 des latences de requêtes ainsi que les latences individuelles des resolvers :
Disponibilité
Veuillez vous reporter aux tableaux de disponibilité par région pour voir dans quelles régions ces fonctionnalités de logging sont disponibles.
Les évènements de log émis à partir du 8 Mai 2019 utilisent ce nouveau format de log. Pour analyser des requêtes GraphQL datant d’avant le 8 Mai 2019, un script de migration est disponible pour mettre à jour d’anciens logs au nouveau format dans le dépôt GitHub sample.
Ecrit par Shankar Raju, Software Development Engineer chez AWS & Nader Dabit, Sr. Developer Advocate chez AWS. Traduit en Français par Olivier Chappe, Architecte Solutions AWS Game Tech, LinkedIn.