在您的 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、交换空间和网络错误）的了解可以大致提供您整体数据库健康状况的良好指示。
一些其他您可能想要关注的指标包括连接、共享缓冲区使用和磁盘使用。将《numbackends》变量与《max_connections》（《pg_settings》视图）相关联可以引起对较慢查询和必须创建新连接以执行请求的应用程序的注意，而不是使用已活跃的连接。您宁愿保持一小批连接保持活跃，也不愿意不断地启动新连接和终止空闲连接。
关注共享缓冲区使用对于读取或更新数据非常重要。共享缓冲区缓存是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用户在构建什么。
