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.
AWS CLI exemples de Performance Insights
Dans les sections suivantes, découvrez le AWS Command Line Interface (AWS CLI) pour Performance Insights et des AWS CLI exemples d'utilisation.
Rubriques
- Aide intégrée AWS CLI pour Performance Insights
- Récupération de métriques de compteur
- Récupération de la charge de base de données moyenne pour les principaux événements d'attente
- Récupération de la charge moyenne de la base de données pour le haut SQL
- Récupération de la charge moyenne de base de données filtrée par SQL
- Récupération du texte intégral d'une déclaration SQL
- Création d'un rapport d'analyse des performances pour une période donnée
- Récupération d'un rapport d'analyse des performances
- Établissement de la liste de tous les rapports d'analyse des performances pour l'instance de base de données
- Suppression d'un rapport d'analyse des performances
- Ajout d'une balise à un rapport d'analyse des performances
- Établissement de la liste de toutes les balises pour un rapport d'analyse des performances
- Suppression des balises d'un rapport d'analyse des performances
Aide intégrée AWS CLI pour Performance Insights
Vous pouvez consulter les données de Performance Insights à l'aide d AWS CLI. Vous pouvez consulter l'aide relative aux AWS CLI commandes de Performance Insights en saisissant ce qui suit sur la ligne de commande.
aws pi help
Si ce n'est pas le AWS CLI cas, reportez-vous à la section Installation du AWS CLI guide de l'AWS CLI utilisateur pour plus d'informations sur son installation.
Récupération de métriques de compteur
L'image suivante illustre deux graphiques de métriques de compteur dans AWS Management Console.
L'exemple suivant montre comment collecter les mêmes données que celles AWS Management Console utilisées pour générer les deux graphiques contre-métriques.
Pour LinuxmacOS, ou Unix :
aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID\ --start-time2018-10-30T00:00:00Z\ --end-time2018-10-30T01:00:00Z\ --period-in-seconds60\ --metric-queries '[{"Metric": "os.cpuUtilization.user.avg" }, {"Metric": "os.cpuUtilization.idle.avg"}]'
Dans Windows :
aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID^ --start-time2018-10-30T00:00:00Z^ --end-time2018-10-30T01:00:00Z^ --period-in-seconds60^ --metric-queries '[{"Metric": "os.cpuUtilization.user.avg" }, {"Metric": "os.cpuUtilization.idle.avg"}]'
Vous pouvez également simplifier la lecture d'une commande en spécifiant un fichier pour l'option --metrics-query. L'exemple suivant utilise un fichier nommé query.json pour l'option. Le contenu du fichier est le suivant.
[ { "Metric": "os.cpuUtilization.user.avg" }, { "Metric": "os.cpuUtilization.idle.avg" } ]
Exécutez la commande suivante pour utiliser le fichier.
Pour LinuxmacOS, ou Unix :
aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID\ --start-time2018-10-30T00:00:00Z\ --end-time2018-10-30T01:00:00Z\ --period-in-seconds60\ --metric-queries file://query.json
Dans Windows :
aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID^ --start-time2018-10-30T00:00:00Z^ --end-time2018-10-30T01:00:00Z^ --period-in-seconds60^ --metric-queries file://query.json
L'exemple précédent spécifie les valeurs suivantes pour les options :
-
--service-type—RDSpour Amazon RDS -
--identifier– ID de ressource de l'instance de base de données -
--start-timeet--end-time— Les ISO 8601DateTimevaleurs pour la période à interroger, avec plusieurs formats pris en charge
L'interrogation se déroule pendant un intervalle d'une heure :
-
--period-in-seconds–60pour une requête toutes les minutes -
--metric-queries– Tableau de deux requêtes s'appliquant chacune à une métrique.Le nom de la métrique utilise des points pour classifier la métrique dans une catégorie utile, l'élément final étant une fonction. Dans l'exemple, la fonction est
avgpour chaque requête. Comme pour Amazon CloudWatch, les fonctions prises en charge sontminmax,total, etavg.
La réponse ressemble à ce qui suit.
{ "Identifier": "db-XXX", "AlignedStartTime": 1540857600.0, "AlignedEndTime": 1540861200.0, "MetricList": [ { //A list of key/datapoints "Key": { "Metric": "os.cpuUtilization.user.avg" //Metric1 }, "DataPoints": [ //Each list of datapoints has the same timestamps and same number of items { "Timestamp": 1540857660.0, //Minute1 "Value": 4.0 }, { "Timestamp": 1540857720.0, //Minute2 "Value": 4.0 }, { "Timestamp": 1540857780.0, //Minute 3 "Value": 10.0 } //... 60 datapoints for the os.cpuUtilization.user.avg metric ] }, { "Key": { "Metric": "os.cpuUtilization.idle.avg" //Metric2 }, "DataPoints": [ { "Timestamp": 1540857660.0, //Minute1 "Value": 12.0 }, { "Timestamp": 1540857720.0, //Minute2 "Value": 13.5 }, //... 60 datapoints for the os.cpuUtilization.idle.avg metric ] } ] //end of MetricList } //end of response
La réponse contient les éléments Identifier, AlignedStartTime et AlignedEndTime. Étant donné que la valeur de --period-in-seconds était définie sur 60, les heures de début et de fin ont été arrondies à la minute près. Si --period-in-seconds était défini sur 3600, les heures de début et de fin auraient été arrondies à l'heure près.
L'élément MetricList dans la réponse comporte un certain nombre d'entrées, chacune associée à une entrée Key et DataPoints. Chaque élément DataPoint comporte une entrée Timestamp et Value. Chaque liste Datapoints répertorie 60 points de données, car les requêtes sont exécutées toutes les minutes pendant une heure, avec Timestamp1/Minute1, Timestamp2/Minute2, etc. jusqu'à Timestamp60/Minute60.
Étant donné que la requête s'applique à deux métriques de compteur différentes, contient deux élément MetricList.
Récupération de la charge de base de données moyenne pour les principaux événements d'attente
L'exemple suivant est la même requête que celle AWS Management Console utilisée pour générer un graphique linéaire à aires empilées. Il récupère la valeur de db.load.avg sur la dernière heure en divisant la charge conformément aux sept principaux événements d'attente. La commande est identique à la commande de la rubrique Récupération de métriques de compteur. Le contenu du fichier query.json est cependant différent :
[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.wait_event", "Limit": 7 } } ]
Exécutez la commande suivante.
Pour LinuxmacOS, ou Unix :
aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID\ --start-time2018-10-30T00:00:00Z\ --end-time2018-10-30T01:00:00Z\ --period-in-seconds60\ --metric-queries file://query.json
Dans Windows :
aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID^ --start-time2018-10-30T00:00:00Z^ --end-time2018-10-30T01:00:00Z^ --period-in-seconds60^ --metric-queries file://query.json
L'exemple spécifie la métrique de db.load.avg et exécute une action GroupBy pour les sept principaux événements d'attente. Pour plus de détails sur les valeurs valides pour cet exemple, reportez-vous DimensionGroupà la section Performance Insights API Reference.
La réponse ressemble à ce qui suit.
{ "Identifier": "db-XXX", "AlignedStartTime": 1540857600.0, "AlignedEndTime": 1540861200.0, "MetricList": [ { //A list of key/datapoints "Key": { //A Metric with no dimensions. This is the total db.load.avg "Metric": "db.load.avg" }, "DataPoints": [ //Each list of datapoints has the same timestamps and same number of items { "Timestamp": 1540857660.0, //Minute1 "Value": 0.5166666666666667 }, { "Timestamp": 1540857720.0, //Minute2 "Value": 0.38333333333333336 }, { "Timestamp": 1540857780.0, //Minute 3 "Value": 0.26666666666666666 } //... 60 datapoints for the total db.load.avg key ] }, { "Key": { //Another key. This is db.load.avg broken down by CPU "Metric": "db.load.avg", "Dimensions": { "db.wait_event.name": "CPU", "db.wait_event.type": "CPU" } }, "DataPoints": [ { "Timestamp": 1540857660.0, //Minute1 "Value": 0.35 }, { "Timestamp": 1540857720.0, //Minute2 "Value": 0.15 }, //... 60 datapoints for the CPU key ] }, //... In total we have 8 key/datapoints entries, 1) total, 2-8) Top Wait Events ] //end of MetricList } //end of response
Dans cette réponse, comporte huit entrée MetricList. Une entrée s'applique à la valeur totale de db.load.avg et les sept autres entrées s'appliquent à chacune des valeurs de db.load.avg divisées conformément à l'un des sept principaux événements d'attente. Contrairement au premier exemple qui comportait une dimension de regroupement, cet exemple doit définir un élément Key pour chaque regroupement de la métrique. Un seul élément Key peut être associé à chaque métrique, comme dans le cas d'utilisation de la métrique de compteur de base.
Récupération de la charge moyenne de la base de données pour le haut SQL
L'exemple suivant regroupe db.wait_events les 10 premières SQL déclarations. Il existe deux groupes différents pour les SQL déclarations :
-
db.sql— La SQL déclaration complète, telle queselect * from customers where customer_id = 123 -
db.sql_tokenized— La SQL déclaration tokenisée, telle queselect * from customers where customer_id = ?
Lors de l'analyse des performances d'une base de données, il peut être utile de considérer les SQL instructions dont les paramètres ne diffèrent que comme un élément logique. Vous pouvez donc utiliser db.sql_tokenized lors de l'interrogation. Toutefois, en particulier lorsque vous souhaitez expliquer des plans, il est parfois plus utile d'examiner des SQL instructions complètes avec des paramètres et de les regrouper par requêtesdb.sql. Il existe une relation parent-enfant entre tokenisé et fullSQL, plusieurs full SQL (enfants) étant regroupés sous le même SQL tokenisé (parent).
La commande illustrée dans cet exemple est identique à la commande de la rubrique Récupération de la charge de base de données moyenne pour les principaux événements d'attente. Le contenu du fichier query.json est cependant différent :
[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.sql_tokenized", "Limit": 10 } } ]
L'exemple suivant utilise db.sql_tokenized.
Pour LinuxmacOS, ou Unix :
aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID\ --start-time2018-10-29T00:00:00Z\ --end-time2018-10-30T00:00:00Z\ --period-in-seconds3600\ --metric-queries file://query.json
Dans Windows :
aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID^ --start-time2018-10-29T00:00:00Z^ --end-time2018-10-30T00:00:00Z^ --period-in-seconds3600^ --metric-queries file://query.json
Cet exemple demande plus de 24 heures, avec une heure period-in-seconds.
L'exemple spécifie la métrique de db.load.avg et exécute une action GroupBy pour les sept principaux événements d'attente. Pour plus de détails sur les valeurs valides pour cet exemple, reportez-vous DimensionGroupà la section Performance Insights API Reference.
La réponse ressemble à ce qui suit.
{ "AlignedStartTime": 1540771200.0, "AlignedEndTime": 1540857600.0, "Identifier": "db-XXX", "MetricList": [ //11 entries in the MetricList { "Key": { //First key is total "Metric": "db.load.avg" } "DataPoints": [ //Each DataPoints list has 24 per-hour Timestamps and a value { "Value": 1.6964980544747081, "Timestamp": 1540774800.0 }, //... 24 datapoints ] }, { "Key": { //Next key is the top tokenized SQL "Dimensions": { "db.sql_tokenized.statement": "INSERT INTO authors (id,name,email) VALUES\n( nextval(?) ,?,?)", "db.sql_tokenized.db_id": "pi-2372568224", "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" }, "Metric": "db.load.avg" }, "DataPoints": [ //... 24 datapoints ] }, // In total 11 entries, 10 Keys of top tokenized SQL, 1 total key ] //End of MetricList } //End of response
Cette réponse comporte 11 entrées MetricList (1 au total, 10 entrées les plus tokeniséesSQL), chaque entrée en comptant 24 par heure. DataPoints
Pour tokenizedSQL, chaque liste de dimensions comporte trois entrées :
-
db.sql_tokenized.statement— La déclaration tokenisée. SQL -
db.sql_tokenized.db_id— Soit l'ID de base de données natif utilisé pour faire référence à laSQL, soit un identifiant synthétique généré par Performance Insights pour vous si l'ID de base de données natif n'est pas disponible. Cet exemple renvoie l'ID synthétiquepi-2372568224. -
db.sql_tokenized.id– ID de la requête dans Performance Insights.Dans le AWS Management Console, cet ID est appelé Support ID. Il est nommé ainsi parce que l'ID est une donnée que le AWS Support peut examiner pour vous aider à résoudre un problème lié à votre base de données. AWS prend très au sérieux la sécurité et la confidentialité de vos données, et presque toutes les données sont stockées cryptées avec votre AWS KMS clé. Par conséquent, personne à l'intérieur ne AWS peut consulter ces données. Dans l'exemple précédent,
tokenized.statementettokenized.db_idsont tous les deux stockés sous forme chiffrée. Si vous rencontrez un problème avec votre base de données, le AWS Support peut vous aider en faisant référence à l'ID de support.
Lors de l'interrogation, il peut s'avérer utile de spécifier une entrée Group dans GroupBy. Toutefois, pour contrôler les données renvoyées de manière plus précise, spécifier la liste des dimensions. Par exemple, si db.sql_tokenized.statement est le seul élément nécessaire, un attribut Dimensions peut être ajouté au fichier query.json.
[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.sql_tokenized", "Dimensions":["db.sql_tokenized.statement"], "Limit": 10 } } ]
Récupération de la charge moyenne de base de données filtrée par SQL
L'image précédente indique qu'une requête particulière est sélectionnée et que le graphique en aires empilées Average active sessions (Sessions actives en moyenne) qui apparaît dans la section supérieure s'y applique. Bien que la requête concerne toujours les sept principaux événements d'attente globaux, la valeur de la réponse est filtrée. Le filtre permet à la requête de prendre uniquement en compte les sessions qui correspondent à un filtre en particulier.
La API requête correspondante dans cet exemple est similaire à la commande dansRécupération de la charge moyenne de la base de données pour le haut SQL. Le contenu du fichier query.json est cependant différent :
[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.wait_event", "Limit": 5 }, "Filter": { "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" } } ]
Pour LinuxmacOS, ou Unix :
aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID\ --start-time2018-10-30T00:00:00Z\ --end-time2018-10-30T01:00:00Z\ --period-in-seconds60\ --metric-queries file://query.json
Dans Windows :
aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID^ --start-time2018-10-30T00:00:00Z^ --end-time2018-10-30T01:00:00Z^ --period-in-seconds60^ --metric-queries file://query.json
La réponse ressemble à ce qui suit.
{ "Identifier": "db-XXX", "AlignedStartTime": 1556215200.0, "MetricList": [ { "Key": { "Metric": "db.load.avg" }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 1.4878117913832196 }, { "Timestamp": 1556222400.0, "Value": 1.192823803967328 } ] }, { "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "io", "db.wait_event.name": "wait/io/aurora_redo_log_flush" } }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 1.1360544217687074 }, { "Timestamp": 1556222400.0, "Value": 1.058051341890315 } ] }, { "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "io", "db.wait_event.name": "wait/io/table/sql/handler" } }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 0.16241496598639457 }, { "Timestamp": 1556222400.0, "Value": 0.05163360560093349 } ] }, { "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "synch", "db.wait_event.name": "wait/synch/mutex/innodb/aurora_lock_thread_slot_futex" } }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 0.11479591836734694 }, { "Timestamp": 1556222400.0, "Value": 0.013127187864644107 } ] }, { "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "CPU", "db.wait_event.name": "CPU" } }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 0.05215419501133787 }, { "Timestamp": 1556222400.0, "Value": 0.05805134189031505 } ] }, { "Key": { "Metric": "db.load.avg", "Dimensions": { "db.wait_event.type": "synch", "db.wait_event.name": "wait/synch/mutex/innodb/lock_wait_mutex" } }, "DataPoints": [ { "Timestamp": 1556218800.0, "Value": 0.017573696145124718 }, { "Timestamp": 1556222400.0, "Value": 0.002333722287047841 } ] } ], "AlignedEndTime": 1556222400.0 } //end of response
Dans cette réponse, toutes les valeurs sont filtrées en fonction de la contribution de tokenized SQL AKIAIOSFODNN7EXAMPLE spécifiée dans le fichier query.json. Les clés peuvent également suivre un ordre différent de celui d'une requête sans filtre, car ce sont les cinq principaux événements d'attente qui ont affecté le filtreSQL.
Récupération du texte intégral d'une déclaration SQL
L'exemple suivant récupère le texte intégral d'une SQL instruction pour une instance db-10BCD2EFGHIJ3KL4M5NO6PQRS5 de base de données. Le --group est db.sql et l'--group-identifier est db.sql.id. Dans cet exemple, my-sql-id représente un SQL identifiant récupéré en invoquant pi
get-resource-metrics oupi describe-dimension-keys.
Exécutez la commande suivante.
Pour LinuxmacOS, ou Unix :
aws pi get-dimension-key-details \ --service-type RDS \ --identifier db-10BCD2EFGHIJ3KL4M5NO6PQRS5 \ --group db.sql \ --group-identifiermy-sql-id\ --requested-dimensions statement
Dans Windows :
aws pi get-dimension-key-details ^ --service-type RDS ^ --identifier db-10BCD2EFGHIJ3KL4M5NO6PQRS5 ^ --group db.sql ^ --group-identifiermy-sql-id^ --requested-dimensions statement
Dans cet exemple, les détails des dimensions sont disponibles. Ainsi, Performance Insights récupère le texte intégral de la SQL déclaration, sans la tronquer.
{ "Dimensions":[ { "Value": "SELECT e.last_name, d.department_name FROM employees e, departments d WHERE e.department_id=d.department_id", "Dimension": "db.sql.statement", "Status": "AVAILABLE" }, ... ] }
Création d'un rapport d'analyse des performances pour une période donnée
L'exemple suivant crée un rapport d'analyse des performances avec l'heure de début 1682969503 et l'heure de fin 1682979503 pour la base de données db-loadtest-0.
aws pi create-performance-analysis-report \ --service-type RDS \ --identifier db-loadtest-0 \ --start-time 1682969503 \ --end-time 1682979503 \ --region us-west-2
La réponse est l'identifiant unique report-0234d3ed98e28fb17 du rapport.
{ "AnalysisReportId": "report-0234d3ed98e28fb17" }
Récupération d'un rapport d'analyse des performances
L'exemple suivant extrait les détails du rapport d'analyse pour le rapport report-0d99cc91c4422ee61.
aws pi get-performance-analysis-report \ --service-type RDS \ --identifier db-loadtest-0 \ --analysis-report-id report-0d99cc91c4422ee61 \ --region us-west-2
La réponse fournit le statut du rapport, l'identifiant, les détails temporels et les informations.
{ "AnalysisReport": { "Status": "Succeeded", "ServiceType": "RDS", "Identifier": "db-loadtest-0", "StartTime": 1680583486.584, "AnalysisReportId": "report-0d99cc91c4422ee61", "EndTime": 1680587086.584, "CreateTime": 1680587087.139, "Insights": [ ... (Condensed for space) ] } }
Établissement de la liste de tous les rapports d'analyse des performances pour l'instance de base de données
L'exemple suivant répertorie tous les rapports d'analyse des performances disponibles pour la base de données db-loadtest-0.
aws pi list-performance-analysis-reports \ --service-type RDS \ --identifier db-loadtest-0 \ --region us-west-2
La réponse répertorie tous les rapports avec l'ID du rapport, le statut et les détails temporels de la période.
{ "AnalysisReports": [ { "Status": "Succeeded", "EndTime": 1680587086.584, "CreationTime": 1680587087.139, "StartTime": 1680583486.584, "AnalysisReportId": "report-0d99cc91c4422ee61" }, { "Status": "Succeeded", "EndTime": 1681491137.914, "CreationTime": 1681491145.973, "StartTime": 1681487537.914, "AnalysisReportId": "report-002633115cc002233" }, { "Status": "Succeeded", "EndTime": 1681493499.849, "CreationTime": 1681493507.762, "StartTime": 1681489899.849, "AnalysisReportId": "report-043b1e006b47246f9" }, { "Status": "InProgress", "EndTime": 1682979503.0, "CreationTime": 1682979618.994, "StartTime": 1682969503.0, "AnalysisReportId": "report-01ad15f9b88bcbd56" } ] }
Suppression d'un rapport d'analyse des performances
L'exemple suivant supprime le rapport d'analyse pour la base de données db-loadtest-0.
aws pi delete-performance-analysis-report \ --service-type RDS \ --identifier db-loadtest-0 \ --analysis-report-id report-0d99cc91c4422ee61 \ --region us-west-2
Ajout d'une balise à un rapport d'analyse des performances
L'exemple suivant ajoute une balise avec une clé name et une valeur test-tag au rapport report-01ad15f9b88bcbd56.
aws pi tag-resource \ --service-type RDS \ --resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \ --tags Key=name,Value=test-tag \ --region us-west-2
Établissement de la liste de toutes les balises pour un rapport d'analyse des performances
L'exemple suivant répertorie toutes les balises pour le rapport report-01ad15f9b88bcbd56.
aws pi list-tags-for-resource \ --service-type RDS \ --resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \ --region us-west-2
La réponse répertorie la valeur et la clé de toutes les balises ajoutées au rapport :
{ "Tags": [ { "Value": "test-tag", "Key": "name" } ] }
Suppression des balises d'un rapport d'analyse des performances
L'exemple suivant montre comment supprimer la balise name du rapport report-01ad15f9b88bcbd56.
aws pi untag-resource \ --service-type RDS \ --resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \ --tag-keys name \ --region us-west-2
Une fois la balise supprimée, appeler le list-tags-for-resource API ne permet pas de répertorier cette balise.
