PostgreSQL 数据库中要监控的指标
作者：Margo Schaedel / 产品, 用例, 开发者
2018 年 8 月 16 日
导航至
概述
上个月，我写了一篇关于如何使用 Telegraf 和 InfluxDB 监控 PostgreSQL 数据库的指南，虽然我能够涵盖如何监控 PostgreSQL 的演练，但我没有机会涵盖在跟踪数据库健康状况时究竟应该关注什么。关于数据库性能，有几个关键指标您肯定需要跟踪，而且它们并非都是数据库特有的。例如，这篇关于 MySQL 数据库指标的博客文章为帮助您入门监控领域提供了一个很好的介绍和概述。
PostgreSQL 的统计信息收集器会自动收集大量关于自身活动的统计信息。在之前的文章中，我们看到 Telegraf PostgreSQL 插件从两个内置视图中提取数据： pg_stat_database 和 pg_stat_bgwriter。如果您想从其他视图中提取数据，您绝对应该查看这个扩展的 Telegraf 插件。在这篇文章中，我们将更深入地了解这些统计信息作为 PostgreSQL 数据库健康状况指标的重要性。
pg_stat_database 视图
pg_stat_database 视图记录有关给定集群中每个数据库的信息，包括数据库 ID (datid)；活跃连接到数据库的后端数量 (numbackends)；提交和回滚；磁盘块读取和共享缓冲区缓存命中；提取、插入、更新和删除的行数；冲突和死锁；创建的临时文件；以及花费在读取和写入数据上的持续时间。
pg_stat_bgwriter 视图
pg_stat_bgwriter 视图提供有关检查点进程的信息，以确定在更新或复制文件时数据库上施加了多少负载。这些变量涵盖了集群中所有数据库发生的检查点总数（包括计划的和请求的检查点），以及花费在检查点处理上的时间。buffers_checkpoint、 buffers_clean 和 buffers_backend 指示缓冲区如何写入磁盘。
基础知识 - 资源利用率
为了在 PostgreSQL 中写入、更新和查询任何内容，数据库需要有足够的资源来成功完成这些任务。PostgreSQL 与其他数据库一样，严重依赖各种系统资源，例如 CPU、网络带宽、磁盘空间/磁盘利用率和 RAM。因此，深入了解这些系统指标以及磁盘 IOPS、交换空间和网络错误等其他指标，通常可以很好地指示您的整体数据库的健康状况。
您可能想要密切关注的其他一些指标，PostgreSQL 会收集有关连接、共享缓冲区使用情况和磁盘使用情况的信息。跟踪与 max_connections （pg_settings 视图）相关的变量（如 numbackends），可以引起人们对可能存在的较慢查询以及应用程序必须创建新连接才能执行请求而不是使用已激活连接的问题的关注。您宁愿保持少量连接处于活动状态，也不愿不断启动新连接并终止空闲连接。
密切关注共享缓冲区使用情况对于读取或更新数据可能非常重要。共享缓冲区缓存是 PostgreSQL 在执行请求时首先检查的位置，如果在此处未找到块，则它需要从磁盘获取数据，之后数据将被缓存在数据库的共享缓冲区缓存中，也可能缓存在操作系统缓存中。这允许随后查询该数据，而无需访问磁盘上的数据。但是，这样做的缺点是某些数据最终可能会同时缓存在多个位置。密切关注 blks_hit 和 blks_read，它们分别代表共享缓冲区命中和从磁盘读取的块，但也要记住，数据有时会保存在操作系统缓存中，而 PostgreSQL 不会报告操作系统缓存。
最后，收集有关数据库磁盘使用情况的信息（请参阅 pg_table_size 或 pg_indexes_size）可以帮助阐明查询性能可能存在的问题。两者之间存在直接关系 - 随着表和索引大小的增加，查询不可避免地会花费更长的时间，从而需要分配更多的磁盘空间。表或索引大小的突然增加也可能暗示 VACUUM 进程（清理和删除死行的过程 - 在下面阅读更多内容）存在问题。
读/写吞吐量
监控读写查询吞吐量有助于确定您的应用程序是否能够向数据库添加数据并访问数据。此区域出现的问题通常会导致数据库其他部分出现问题，尤其是在复制和可靠性方面。为了确保可用性，密切关注您的读取和写入是一个不错的主意。
查看 tup_returned，读取或扫描的行数与 tup_fetched，提取的包含成功执行查询所需数据的行数。这两个变量应该始终保持非常接近的数字，这将表明数据库正在有效地执行读取查询，因为它不会扫描额外的行来满足查询要求。此外，您可能需要跟踪 temp_files 和 temp_bytes，因为 PostgreSQL 有时必须将数据临时写入磁盘才能成功执行各种查询（如果可用内存不足）。此区域中的高数字表明资源消耗查询的数量可能在增加。
您还需要确保您的写入性能达到标准，因此密切关注 tup_inserted、 tup_updated 和 tup_deleted 至关重要。更新和删除行的速率很高可能会导致死行数量增加（pg_stat_user_tables 视图中的 n_dead_tup），这是另一个需要密切关注的指标。大量死行（已删除且正在等待清理的行）表明清理过程可能存在问题 - 在 PostgreSQL 中，此过程称为 VACUUM 进程。本质上，它的工作是从表和索引中删除死行，以便为新行插入腾出空间。作为旁注，VACUUM 进程应定期运行，以确保持续的查询效率并定期更新 PostgreSQL 的内部统计信息。请记住，大量的死行（本质上是浪费的空间）肯定会长期降低您的查询速度。
如果您在读取和写入吞吐量中都遇到高变化率，则有必要检查表或行上是否存在来自锁的延迟（来自 pg_locks 视图的 lock），这些表或行当前正在经历或等待更新。与此相关的是数据库中是否存在任何死锁，当多个事务持有另一个事务执行查询所需的行或表上的锁时，就会发生死锁。如果可能，最好完全避免死锁的发生，方法是确保每次都以一致的顺序分配锁。
可靠性
如果您的数据对您来说非常重要，那么您可能正在保留它的多个副本（这样您就不会在崩溃事件中丢失所有数据），并且您希望它始终保持高度可用性。这就是 pg_stat_bgwriter 视图可以发挥巨大作用的地方。它跟踪许多检查点指标。
检查点是事务过程中的周期性时刻，可确保数据文件已更新到磁盘上的那一刻。如果这听起来令人困惑，请考虑文字处理器如何定期自动保存您正在处理的文件，如果您的程序崩溃，重新启动后，您将被带回到之前的自动保存版本。检查点在记录和更新的数据文件方面以类似的方式运行。通常，将更新后的数据刷新到磁盘的过程可能会导致大量的 I/O 负载，因此，检查点活动会间隔开，以避免性能损失。这意味着必须完成单个检查点，然后才能启动下一个检查点。
比较以下两个变量： checkpoints_req 和 checkpoints_timed。第一个显示请求的检查点数，而后者表示计划的检查点数。最好计划的检查点多于请求的检查点；反之亦然可能表明您的检查点无法跟上数据更新的速度，并表明数据库负载过重。
pg_stat_bgwriter 还显示有关 PostgreSQL 如何选择将内存（缓冲区）中的数据刷新到磁盘的指标。它可以通过三种不同的方式执行此操作
buffers_backend- 通过后端buffers_clean- 通过后台写入器buffers_checkpoint- 通过检查点进程
理想情况下，您希望大部分刷新通过检查点进程进行，但有时后台写入器会介入以帮助减轻检查点进程中经常发生的 I/O 负载。后端直接写入的缓冲区增加可能意味着写入密集型负载，该负载创建缓冲区的速度太快，检查点进程无法跟上。最终，密切关注这三个方面最符合您的利益。
总结
希望所有这些信息都可以与之前的教程结合使用，使您可以非常轻松地使用 Telegraf 和 InfluxDB 监控您的 PostgreSQL 数据库。如有任何问题或意见，请随时通过 Twitter @InfluxDB 和 @mschae16 与我们联系，或者您可以查看我们的社区论坛，了解其他 InfluxData 用户正在构建什么。
