# 使用 Amazon CloudWatch 指标分析 Aurora PostgreSQL 的资源使用情况
Aurora 以 1 分钟为间隔自动将指标数据发送到 CloudWatch。您可以使用 CloudWatch 指标分析 Aurora PostgreSQL 的资源使用情况。您可以使用指标评估网络吞吐量和网络使用情况。
## 使用 CloudWatch 评估网络吞吐量
当您的系统使用情况接近实例类型的资源限制时，处理速度可能会变慢。您可以使用 CloudWatch **Logs Insights**（日志洞察）监控您的存储资源使用情况，并确保有充足的可用资源。必要时，您可以将数据库实例修改为更大的实例类。
Aurora 存储处理可能很慢，原因是：
+ 客户端与数据库实例之间的网络带宽不足。
+ 存储子系统的网络带宽不足。
+ 对于您的实例类型而言，工作负载很大。
您可以查询 CloudWatch **Logs Insights**（日志洞察）以生成 Aurora 存储资源使用情况的图表来监控资源。该图显示 CPU 利用率和指标，可帮助您决定是否纵向扩展到更大的实例大小。有关 CloudWatch **Logs Insights**（日志洞察）的查询语法的信息，请参阅 [CloudWatch Logs Insights 查询语法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)。
要使用 CloudWatch，您需要将 Aurora PostgreSQL 日志文件导出到 CloudWatch。您还可以修改现有集群，以将日志导出到 CloudWatch。有关将日志导出到 CloudWatch 的信息，请参阅 [开启将日志发布到 Amazon CloudWatch 的选项](AuroraPostgreSQL.CloudWatch.Publishing.md)。
您需要数据库实例的 **Resource ID**（资源 ID）才能查询 CloudWatch **Logs Insights**（日志洞察）。**Resource ID**（资源 ID）可在控制台的 **Configuration**（配置）选项卡中找到：
**要在日志文件中查询资源存储指标，请执行以下操作：**
1. 通过 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 打开 CloudWatch 控制台。
将显示 CloudWatch 概览主页。
1. 如果需要，更改 AWS 区域。从导航栏中，选择您的 AWS 资源所在的 AWS 区域。有关更多信息，请参阅[区域和端点](https://docs.aws.amazon.com/general/latest/gr/rande.html)。
1. 在导航窗格中，选择 **Logs**（日志），然后选择 **Logs Insights**（日志洞察）。
将出现 **Logs Insights**（日志洞察）页面。
1. 从下拉列表中，选择日志文件进行分析。
1. 在字段中输入以下查询，将 `` 替换为数据库集群的资源 ID：
`filter @logStream = | parse @message "\"Aurora Storage Daemon\"*memoryUsedPc\":*,\"cpuUsedPc\":*," as a,memoryUsedPc,cpuUsedPc | display memoryUsedPc,cpuUsedPc #| stats avg(xcpu) as avgCpu by bin(5m) | limit 10000`
1. 单击 **Run query**（运行查询）。
将显示存储利用率图表。
下图提供了 **Logs Insights**（日志洞察）页面和图表显示。
## 使用 CloudWatch 指标评估 Aurora PostgreSQL 数据库实例使用情况
您可以使用 CloudWatch 指标来观察您的实例吞吐量，并发现您的实例类是否为您的应用程序提供了足够的资源。有关数据库实例类限制的信息，请访问 [适用于 Aurora 的数据库实例类的硬件规格](Concepts.DBInstanceClass.Summary.md) 并找到数据库实例类的规格以了解您的网络性能。
如果您的数据库实例使用情况接近实例类限制，则性能可能会开始变慢。CloudWatch 指标可以证实这种情况，因此您可以计划手动纵向扩展到更大的实例类。
结合使用以下 CloudWatch 指标值，看看您是否接近实例类限制：
+ **NetworkThroughput** –Aurora 数据库集群中每个实例的客户端接收和发送的网络吞吐量。此吞吐量值不包括数据库集群中的实例与集群卷之间的网络流量。
+ **StorageNetworkThroughput** – Aurora 数据库集群中每个实例从 Aurora 存储子系统接收以及发送到此子系统的网络吞吐量。
将 **NetworkThroughput** 与 **StorageNetworkThroughput** 相加，以找出 Aurora 数据库集群中每个实例从 Aurora 存储子系统接收和发送到此系统的网络吞吐量。您的实例的实例类限制应大于这两个组合指标的总和。
在发送和接收时，您可以使用以下指标来查看来自客户端应用程序的网络流量的更多详细信息：
+ **NetworkReceiveThroughput** – Aurora PostgreSQL 数据库集群中每个实例从客户端接收的网络吞吐量。此吞吐量不包括数据库集群中的实例与集群卷之间的网络流量。
+ **NetworkTransmitThroughput** – Aurora 数据库集群中每个实例发送到客户端的网络吞吐量。此吞吐量不包括数据库集群中的实例与集群卷之间的网络流量。
+ **StorageNetworkReceiveThroughput** – 数据库集群中每个实例从 Aurora 存储子系统接收的网络吞吐量。
+ **StorageNetworkTransmitThroughput** – Aurora MySQL 数据库集群中每个实例发送到 Aurora 存储子系统的网络吞吐量。
将所有这些指标相加，以评估您的网络使用量与实例类限制的对比情况。实例类限制应大于这些组合指标的总和。
网络限制和存储的 CPU 利用率是相互的。当网络吞吐量增加时，CPU 利用率也会增加。监控 CPU 和网络使用情况可提供有关资源耗尽的方式和原因的信息。
为了帮助显著减少网络使用量，您可以考虑：
+ 使用更大的实例类。
+ 使用 `pg_partman` 分区策略。
+ 批量划分写入请求以减少总体事务量。
+ 将只读工作负载定向到只读实例。
+ 删除任何未使用的索引。
+ 检查是否有臃肿的对象和 VACUUM。如果出现严重臃肿，请使用 PostgreSQL 扩展 `pg_repack`。有关 `pg_repack` 的详细信息，请参阅 [Reorganize tables in PostgreSQL databases with minimal locks](https://reorg.github.io/pg_repack/)（使用最小锁定重新组织 PostgreSQL 数据库中的表）。