Amazon Aurora
Aurora 用户指南 (API 版本 2014-10-31)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

Performance Insights API

当为支持的引擎类型启用 Performance Insights 时,Amazon RDS Performance Insights API 将提供对 RDS 实例性能的可见性。Amazon CloudWatch Logs 为 AWS 服务提供了权威的监控指标来源。Performance Insights 提供数据库负载(以平均有效会话数形式测量并以二维时间序列数据集形式提供给 API 使用者)的域特定视图。数据的时间维度提供所查询时间范围的每个时间点的数据库负载数据。每个时间点将分解与所请求维度相关的整体负载,如相应时间点测量的 SQLWait-eventUserHost

Amazon RDS Performance Insights 用于监控您的 Amazon RDS 数据库实例,使您可以分析数据库性能和排查数据库性能问题。查看 Performance Insights 数据的一种方法是在 AWS 管理控制台中。Performance Insights 还提供公有 API,以便您可以查询自己的数据。此 API 可用于将数据卸载到数据库中,将 Performance Insights 数据添加到现有监控控制面板中,或构建监控工具。要使用 Performance Insights API,请在您的 Amazon RDS 数据库实例之一上启用 Performance Insights。有关启用 Performance Insights 的信息,请参阅 启用 Performance Insights

有关 Performance Insights API 的更多信息,请参阅 Amazon RDS Performance Insights API 参考

Performance Insights 的 AWS CLI

您可以使用 AWS CLI 查看 Performance Insights 数据。可以通过在命令行上输入以下内容来查看 Performance Insights 的 AWS CLI 命令的帮助。

aws pi help

如果您尚未安装 AWS CLI,请参阅 AWS CLI 用户指南 中的安装 AWS 命令行界面来了解有关安装它的信息。

检索时间序列指标

GetResourceMetrics 操作从 Performance Insights 数据中检索一个或多个时间序列指标。GetResourceMetrics 需要指标和时间段,并返回包含数据点列表的响应。

例如,AWS 管理控制台在 Performance Insights 控制面板的两个位置使用 GetResourceMetricsGetResourceMetrics 用于填充 Counter Metrics (计数器指标) 图表和 Database Load (数据库负载) 图表,如下图所示。


					“Counter Metrics (计数器指标)”和“Database Load (数据库负载)”图表

GetResourceMetrics 返回的所有指标都是标准的时间序列指标,但有一个例外。例外是 db.load,它是 Performance Insights 中的核心指标。此指标显示在 Database Load (数据库负载) 图表中。db.load 指标不同于其他时间序列指标,因为您可以将它分为称为维度的子组件。在上图中,按组成 db.load 的等待状态对 db.load 进行细分和分组。

有关使用 get-resource-metrics AWS CLI 命令的信息,请参阅 get-resource-metrics

对于 --metric-queries 选项,请指定一个或多个要获取其结果的查询。每个查询包括必需的 Metric 和可选的 GroupByFilter 参数。以下是 --metric-queries 选项规范的示例。

{ "Metric": "string", "GroupBy": { "Group": "string", "Dimensions": ["string", ...], "Limit": integer }, "Filter": {"string": "string" ...} }

Performance Insights 的 AWS CLI 示例

下面是使用 Performance Insights 的 AWS CLI 的几个示例。

检索计数器指标

下图显示 AWS 管理控制台中的两个计数器指标图表。


					计数器指标图表。

以下示例显示如何收集 AWS 管理控制台 用于生成两个计数器指标图表的相同数据。

针对 Linux、OS X 或 Unix:

aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID \ --start-time 2018-10-30T00:00:00Z \ --end-time 2018-10-30T01:00:00Z \ --period-in-seconds 60 \ --metric-queries '[{"Metric": "sys.cpu.user.avg" }, {"Metric": "sys.cpu.system.avg"}]'

对于 Windows:

aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID ^ --start-time 2018-10-30T00:00:00Z ^ --end-time 2018-10-30T01:00:00Z ^ --period-in-seconds 60 ^ --metric-queries '[{"Metric": "sys.cpu.user.avg" }, {"Metric": "sys.cpu.system.avg"}]'

还可以通过为 --metrics-query 选项指定文件来使命令更易于读取。以下示例为该选项使用名为 query.json 的文件。此文件具有以下内容。

[ { "Metric": "sys.cpu.user.avg" }, { "Metric": "sys.cpu.system.avg" } ]

运行以下命令来使用此文件。

针对 Linux、OS X 或 Unix:

aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID \ --start-time 2018-10-30T00:00:00Z \ --end-time 2018-10-30T01:00:00Z \ --period-in-seconds 60 \ --metric-queries file://query.json

对于 Windows:

aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID ^ --start-time 2018-10-30T00:00:00Z ^ --end-time 2018-10-30T01:00:00Z ^ --period-in-seconds 60 ^ --metric-queries file://query.json

上一个示例为各选项指定了以下值:

  • --service-type – 对于 Amazon RDS 来说为 RDS

  • --identifier – 数据库实例的资源 ID

  • --start-time--end-time – 要查询的期间的 ISO 8601 DateTime 值,支持多种格式

它查询一小时时间范围:

  • --period-in-seconds – 对于每分钟查询来说为 60

  • --metric-queries – 两个查询的数组,每个查询只用于一个指标。

    指标名称使用点在有用的类别中分类指标,最后一个元素是函数。在示例中,对于每个查询来说,此函数是 avg。与 Amazon CloudWatch 一样,支持的函数为 minmaxtotalavg

响应类似于以下内容。

{ "Identifier": "db-XXX", "AlignedStartTime": 1540857600.0, "AlignedEndTime": 1540861200.0, "MetricList": [ { //A list of key/datapoints "Key": { "Metric": "sys.cpu.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 sys.cpu.user.avg metric ] }, { "Key": { "Metric": "sys.cpu.system.avg" //Metric2 }, "DataPoints": [ { "Timestamp": 1540857660.0, //Minute1 "Value": 12.0 }, { "Timestamp": 1540857720.0, //Minute2 "Value": 13.5 }, //... 60 datapoints for the sys.cpu.system.avg metric ] } ] //end of MetricList } //end of response

响应具有 IdentifierAlignedStartTimeAlignedEndTime。但 --period-in-seconds 值为 60,开始和结束时间已与分钟对齐。如果 --period-in-seconds3600,则开始和结束时间已与小时对齐。

响应中的 MetricList 具有许多条目,每个条目具有 KeyDataPoints 条目。每个 DataPoint 具有 TimestampValue。每个 Datapoints 列表具有 60 个数据点,因为查询针对一小时内的每分钟数据,具有 Timestamp1/Minute1Timestamp2/Minute2 等,一直到 Timestamp60/Minute60

因为查询用于两个不同的计数器指标,响应 MetricList 中有两个元素。

检索首要等待事件的数据库负载平均值

以下示例是 AWS 管理控制台用于生成堆栈区域线图的相同查询。此示例检索按前七个等待事件划分负载的最后一个小时的 db.load.avg。命令与 检索计数器指标 中的命令相同。不过,query.json 文件具有以下内容。

[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.wait_event", "Limit": 7 } } ]

运行以下命令。

针对 Linux、OS X 或 Unix:

aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID \ --start-time 2018-10-30T00:00:00Z \ --end-time 2018-10-30T01:00:00Z \ --period-in-seconds 60 \ --metric-queries file://query.json

对于 Windows:

aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID ^ --start-time 2018-10-30T00:00:00Z ^ --end-time 2018-10-30T01:00:00Z ^ --period-in-seconds 60 ^ --metric-queries file://query.json

此示例指定指标 db.load.avg 和前七个等待事件的 GroupBy。有关此示例的有效值的详细信息,请参阅 Performance Insights API 参考 中的 DimensionGroup

响应类似于以下内容。

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

在此响应中,MetricList 中有八个条目。有一个有关总 db.load.avg 的条目,还有七个条目,其中每个条目关于按前七个等待事件之一划分的 db.load.avg。与第一个示例不同,因为具有分组维度,所以必须具有一个用于每个指标分组的键。不能像在基本计数器指标使用案例中那样每个指标只有一个键。

检索首要 SQL 的数据库负载平均值

以下示例按前 10 个 SQL 语句对 db.wait_events 进行分组。有两个不同的 SQL 语句组:

  • db.sql – 完整的 SQL 语句,例如 select * from customers where customer_id = 123

  • db.sql_tokenized – 令牌化的 SQL 语句,例如 select * from customers where customer_id = ?

在分析数据库性能时,将仅参数不同的 SQL 语句视为一个逻辑项目很有用。因此,您在查询时可以使用 db.sql_tokenized。不过,尤其在您对说明计划感兴趣时,查看带参数的完整 SQL 语句和查询按 db.sql 进行的分组有时会更有用。令牌化和完整 SQL 之间存在父-子关系,多个完整 SQL(子级)分组在同一令牌化 SQL(父级)下。

此示例中的命令类似于 检索首要等待事件的数据库负载平均值 中的命令。不过,query.json 文件具有以下内容。

[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.sql_tokenized", "Limit": 10 } } ]

下面的示例使用了 db.sql_tokenized

针对 Linux、OS X 或 Unix:

aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID \ --start-time 2018-10-29T00:00:00Z \ --end-time 2018-10-30T00:00:00Z \ --period-in-seconds 3600 \ --metric-queries file://query.json

对于 Windows:

aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID ^ --start-time 2018-10-29T00:00:00Z ^ --end-time 2018-10-30T00:00:00Z ^ --period-in-seconds 3600 ^ --metric-queries file://query.json

此示例查询 24 小时,以秒为单位的期间为一小时。

此示例指定指标 db.load.avg 和前七个等待事件的 GroupBy。有关此示例的有效值的详细信息,请参阅 Performance Insights API 参考 中的 DimensionGroup

响应类似于以下内容。

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

此响应的 MetricList 中具有 11 个条目(1 个总计,10 个首要令牌化 SQL),其中每个条目具有 24 个每小时 DataPoints

对于令牌化 SQL,每个维度列表中具有三个条目:

  • db.sql_tokenized.statement – 令牌化 SQL 语句。

  • db.sql_tokenized.db_id – 用于引用 SQL 的本机数据库 ID,或 Performance Insights 为您生成的合成 ID(如果本机数据库 ID 不可用)。此示例返回 pi-2372568224 合成 ID。

  • db.sql_tokenized.statement – Performance Insights 中的查询的 ID。

    在 AWS 管理控制台中,此 ID 称为支持 ID。它如此命名是因为 ID 是 AWS Support 可检查以帮助您解决数据库问题的数据。AWS 极其重视您的数据的安全性和隐私,几乎所有数据都使用您的 AWS KMS 密钥进行加密存储。因此,AWS 中的任何人都无法查看这些数据。在上一个示例中,tokenized_statementtokenized.db_id 都进行了加密存储。如果您的数据库出现问题,AWS Support 可以通过引用支持 ID 来帮助您。

在查询时,在 GroupBy 中指定 Group 可能很方便。不过,要更精细地控制返回的数据,请指定维度列表。例如,如果所需的所有内容是 db.sql_tokenized.statement,则可将 Dimensions 属性添加到 query.json 文件中。

[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.sql_tokenized", "Dimensions":["db.sql_tokenized.statement"], "Limit": 10 } } ]

检索按 SQL 筛选的数据库负载平均值


						按 SQL 图表筛选。

上图显示选择了特定查询,并且首要平均活动会话堆栈区域线图限定为该查询。虽然查询仍针对前七个总体等待事件,已筛选响应的值。筛选条件使它只考虑与特定筛选条件匹配的会话。

此示例中的相应 API 查询类似于 检索首要 SQL 的数据库负载平均值 中的命令。不过,query.json 文件具有以下内容。

[ { "Metric": "db.load.avg", "GroupBy": { "Group": "db.wait_event", "Limit": 5 }, "Filter": { "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" } } ]

针对 Linux、OS X 或 Unix:

aws pi get-resource-metrics \ --service-type RDS \ --identifier db-ID \ --start-time 2018-10-30T00:00:00Z \ --end-time 2018-10-30T01:00:00Z \ --period-in-seconds 60 \ --metric-queries file://query.json

对于 Windows:

aws pi get-resource-metrics ^ --service-type RDS ^ --identifier db-ID ^ --start-time 2018-10-30T00:00:00Z ^ --end-time 2018-10-30T01:00:00Z ^ --period-in-seconds 60 ^ --metric-queries file://query.json

响应类似于以下内容。

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

在此响应中,根据 query.json 文件中指定的令牌化 SQL AKIAIOSFODNN7EXAMPLE 的贡献筛选所有值。键还可能遵循与没有筛选条件的查询不同的顺序,因为前五个等待事件影响了筛选的 SQL。