提升 Amazon RDS 和 Amazon Aurora 的性能可见性和事件监控

关键要点

在这篇文章中，我们将探讨如何通过各种工具提升 Amazon RDS 和 Amazon Aurora 的性能监控。这包括使用 PerformanceInsights、增强监控、主引擎日志和更多工具，确保数据库性能和事件的可见性，以便进行更深入的故障排查和分析。

客户常常询问如何改善对其工作负载性能以及计划和非计划事件的可见性与监控，尤其是在 （Amazon RDS）和 数据库上。本文将提供一些见解，指导如何主动启用和设置仪器，以便捕获所有细节并用于分析。

在我与 AWS 客户合作的八年中，我帮助他们利用 Amazon RDS 和 Aurora 实现目标，我遇到过许多希望深入了解操作系统指标（如自管理数据库上的 top 和 vmstat 指标）和希望了解 Amazon RDS Multi-AZ实例为何切换到备用可用区的数据库管理员。在本文中，我将概述提供上述信息及更多内容的各种监控工具，并为每种工具提供一些额外提示，同时指向可以深入了解每种工具工作原理的资源。

如果你更喜欢观看视频，可以查看 。

Amazon RDS 和 Aurora 工具

我们将从专门针对 Amazon RDS 和 Aurora 的工具开始。随后，我们将讨论其他 AWS 服务，这些服务提供特定的见解，帮助你更好地使用 RDS和 Aurora。

Performance Insights

使用轻量级方法来捕获数据库会话和查询性能元数据，并将其与实例的 CloudWatch指标结合，提供预配置和可自定义的仪表板视图。我特别喜欢你可以深入分析，查看哪些查询运行得最久和最频繁，精确到秒。此元数据存储在数据库实例之外，以最小化 Performance Insights对工作负载的影响。我建议在所有生产实例中始终启用此功能，以便拥有数据库性能的历史记录，并且可以比较某个查询当前的表现与以往的表现。更多信息可参考 ，或查看这个快速 。

冷知识：启用 Performance Insights 或修改其保留设置不会导致数据库宕机或中断。此外，默认的数据保留时间为 7 天，且没有额外费用。

增强监控

我仍然记得在 2015 年 12 月看到 的推出时的兴奋。在此之前，客户经常询问有关 RDS 实例性能的深入信息，比如在 Linux 提示符下运行 top、vmstat 和 iostat所得到的数据。增强监控不仅提供了这些信息，某些引擎还收集了超过 50 种不同的指标。我特别喜欢增强监控的两个功能：

• 它将提取的元数据写入 ，可以交互和程序化访问原始指标值，从而允许创造性地分析这些数据，例如使用第三方监控工具来提取数据并与应用性能关联。这也意味着指标不会写入 RDS 或 Aurora 实例本身，因此启用增强监控对数据库的影响很小。此外，值得注意的是，。最后，增强监控元数据的默认保留时间为 30 天，但你可以修改 。
• 你可以定义增强监控的数据收集间隔为 1、5、10、15、30 或 60 秒（60 为默认值，1 为最详细）。我特别喜欢 1 秒间隔，原因有二：它与 Performance Insights 用于收集数据库元数据的间隔相匹配，并且这是显示非常短期的超负荷（通常是 CPU、I/O 或网络）并导致查询延迟增加的最佳选择。

冷知识：启用增强监控或修改其收集间隔不会导致数据库宕机或中断。

引擎主日志

我的 DBA 同事会告诉你，数据库主引擎活动日志是两类事件的重要信息来源：

• 当怀疑数据库内部进程时——例如，检查点、重做日志或数据块刷新到磁盘。（你可以在日志中搜索关键字，如“checkpoint”、“redo”或“flush”。）
• 当发生崩溃、故障转移、关机或启动时。（常用的关键字是“start”、“shut”、“crash”或“ready”。）

Amazon RDS 和 Aurora 默认向客户提供这些日志文件，以便你可以

从实例中。每个引擎都有自己的命名约定——MySQL、MariaDB 和 SQL Server 称其为 error logs ，Oracle 称之为 alert logs ，而 PostgreSQL 称之为 postgresql logs 。

提示：对于引擎日志，“无新闻即好消息”的说法确实适用。如果某个时间间隔内没有日志，说明引擎未认为有必要警告任何问题——在这一期间没有发生关机、启动、崩溃或故障转移。

冷知识：Amazon RDS 和 Aurora 会自动管理日志轮换和保留。

额外的数据库活动审计

在某些数据库实例中，根据工作负载的重要性，你可能希望记录数据库发生的所有事项，谁在何时从哪个 IP地址登录？上周六哪个时间戳最后一次删除了表以便进行精确的时间恢复？谁在何时更新了应用程序的设置表？数据库审计可以回答这些问题，但由于工作负载的开销以及并非所有客户都需要此功能，因此需要为你的实例启用审计。此外，审计功能由数据库引擎提供，因此每个引擎的启用程序均不同。有关如何在 Amazon RDS 和 Aurora 中为每种数据库引擎启用审计的信息，请参考以下资源：

日志查询与保留使用 CloudWatch Logs

除了每个引擎的主日志文件和审计日志文件外，一些引擎还有其他可能有用的日志形式。例如，MySQL 和与 MySQL 兼容的引擎可以通过

记录超过定义秒数的查询。考虑到所有这些不同的日志形式，日志文件的数量和大小可能会增长。然而，数据库实例并不是保持或访问这些日志文件的最佳场所。因此，AmazonRDS 和 Aurora 提供了一项 的功能。以下是将数据库日志导出到 CloudWatch Logs 的一些良好理由：

• 为了节省磁盘空间，Amazon RDS 和 Aurora 定期轮换和删除实例的日志。另一方面，CloudWatch Logs 中的日志可以 。
• 从数据库实例直接下载大型文件或大量文件可能会显著消耗实例的 I/O 资源。然而，从 CloudWatch Logs 读取它们对此数据库实例的性能影响很小到几乎没有。
• CloudWatch Logs 具有很好的 ，让你更轻松和快捷地找到所需日志。
• CloudWatch Logs 还允许 。
• Aurora 实例在附加到实例的临时磁盘中存储日志——如果实例发生故障并被替换，日志可能会丢失。但通过发布日志，几乎所有日志（除了最后几个）都将被保留。

需要提醒的是：大多数日志需要由你启用，因此，仅将实例设置为将日志导出到 CloudWatch Logs 是不够的，如果它们最初没有生成的话。

RDS 事件

这是 Amazon RDS 最不为人知且使用最少的功能之一，但同时也是非常有用的！和监视错误日志文件以了解数据库内部发生的事情一样，监视 也同样重要，以了解支持数据库的 RDS 基础设施发生的事情。

冷知识 1：事件“数据库实例的恢复已开始。恢复时间将根据数据量的不同而有所变化。”意味着实例的硬件正在恢复。Amazon RDS 的恢复是通过迁移到新的 （AmazonEC2）主机来完成的。恢复时间会有所不同，原因有两个：首先，配置新主机需要一些时间；其次，新的主机到位后，数据库进程会启动崩溃恢复，该过程可能会根据恢复前的活动量而快速或缓慢。我建议查看数据库引擎的手册，因为每个引擎的崩溃恢复机制各不相同。

冷知识 2：事件“RDS Multi-AZ 主实例繁忙且无响应”是可获得的少数 之一。如果你看到这个事件，你需要加倍关注本文提到的其他监控工具，因为这些工具将有助于你找出为何实例会变得如此繁忙而变得无响应。

Amazon RDS 生成的事件涵盖实例和集群。你可以在 Amazon RDS 控制台上访问过去 24 小时的事件，通过编程访问时可以查看过去 14天的事件，例如使用 （AWS CLI）或 SDK。但我真正建议的是启用 ，这样你可以定义将它们发送到哪里及其存储保留。

Amazon RDS CloudWatch 指标

每个 RDS 和 Aurora 实例默认都会收集和发布 ，每分钟发布一次，且没有额外费用。Amazon RDS控制台提供了一个便捷的接口，以迅速浏览实例的当前状态，但为了进行分析和指标关联，我更倾向于使用更强大的，专门用于指标管理的 CloudWatch 接口。

冷知识：RDS 指标的 。例如，在 15 天后，我们无法看到 1 分钟的数据，但仍然可以看到 5分钟的相同度量指标。由于每个时间段的五个数据点已被聚合，我们可以看到它们的最小值、平均值和最大值。

提示：Amazon RDS 使用实例的名称在 CloudWatch中存储指标。这导致两个效果：首先，如果重命名一个实例，可能会让人觉得这个实例的指标被清除，但实际上，指标仍然与旧名称相关联，可以通过 CloudWatch控制台访问。其次，如果一个实例被删除，然后使用相同名称新建一个（或还原），新实例会显示其创建之前的指标，因为它也显示了之前实例的指标。

此外，Aurora 不仅发布实例指标，还将相同的指标值发布到集群名称，并根据实例是写入者还是读取者，分别发布到 WRITER 角色或 READER角色。请注意以下几点：

• 集群指标对设置适用于整个集群的警报非常有用，无论删除或添加更多实例，例如设置当任何实例的 CPU 利用率超过 90% 时发出警报。它们还对了解某个时间点集群中有多少健康实例非常有用，我们可以使用计数统计得知每分钟有多少实例报告了指标。
• 集群 WRITER 角色的指标是持续查看集群过去写入者性能的好方法，即使故障转移使得两个或更多实例在不同时间点变成集群的写入者。此角色一次只能报告一个实例。
• 集群 READER 角色的指标用于 ，以根据需要添加或删除读取者。然而，当集群至少有一个实例是读取者时，这些指标才会被填充。因此，支持自动扩展的集群必须始终有一个写入者和一个读取者。

此外，你可以 ，尽管你可能只想针对重要的指标进行警报设置，这些指标因所使用的引擎而异。例如，在 PostgreSQL 上，你可能会设定一个警报来 。

AWS 服务

在这一节中，我们讨论其他 AWS 服务如何提供补充 Amazon RDS 和 Aurora 的具体洞察。

AWS CloudTrail

类似于审计使你能够记录并了解通过数据库连接提交的命令， 允许你 ，通过各种途径（包括 CloudTrail 控制台、AWS CLI、CDK、第三方工具和直接到端点的 API 调用）用于 AWS 服务，包括 Amazon RDS 和 Aurora。

冷知识：CloudTrail 默认保存的 API 调用事件历史为 90 天——不需要启用或设置任何内容即可获取此事件历史。

AWS Health

是 AWS 用来通知客户 AWS 服务的性能和可用性，以及这些对你账户的影响的方式。主要包含两部分： ，它包含公共信息，不需要认证就可以访问；以及 ，提供特定于你账户资源的信息。

Amazon VPC

（AmazonVPC）有一些功能可以帮助排除连接问题。

VPC 流量日志

提供信息，显示在你的 VPC 中，网络接口的 IP 流量（和 TCP 连接）进出情况。

VPC 流量镜像

我常常听到客户问：“我可以对 RDS 或 Aurora 实例进行数据包捕获