我建议你阅读 Data Egret 的 Alexey Lesovsky 的报告《PostgreSQL 监控基础》的文字记录
在本报告中，Alexey Lesovsky 将讨论会后统计数据的要点、它们的含义以及为什么它们应该出现在监测中； 关于监控中应包含哪些图表、如何添加它们以及如何解释它们。 该报告对于数据库管理员、系统管理员和对 Postgres 故障排除感兴趣的开发人员非常有用。
我叫 Alexey Lesovsky，我代表 Data Egret 公司。
关于我自己的几句话。 很久以前，我就开始担任系统管理员。
我管理各种不同的 Linux 系统，从事与 Linux 相关的各种工作，即虚拟化、监控、使用代理等。但在某些时候，我开始更多地使用数据库、PostgreSQL。 我真的很喜欢他。 从某个时候起，我开始将大部分工作时间都花在 PostgreSQL 上。 就这样我逐渐成为了一名 PostgreSQL DBA。
在我的职业生涯中，我一直对统计、监控和遥测等主题感兴趣。 当我担任系统管理员时，我与 Zabbix 密切合作。 我写了一小组脚本，比如 。 他在他那个时代很受欢迎。 在那里可以监视非常不同的重要事物，不仅是 Linux，还包括各种组件。
现在我正在研究 PostgreSQL。 我已经在写另一篇文章，让你可以使用 PostgreSQL 统计数据。 它被称为 （关于哈布雷的文章 - ).
一点介绍性的说明。 我们的客户、我们的客户有什么情况？ 存在某种与数据库相关的事故。 当数据库已经恢复后，部门主管或开发主管过来说道：“朋友们，我们需要监控数据库，因为发生了一些不好的事情，我们需要防止这种情况再次发生。” 这里开始了选择监控系统或调整现有监控系统的有趣过程，以便您可以监控您的数据库 - PostgreSQL、MySQL 或其他数据库。 同事们开始建议：“听说有这样那样的数据库。 我们就用它吧。” 同事们开始互相争论。 最后发现我们选择了某种数据库，但是其中的 PostgreSQL 监控表现得相当差，我们总是需要添加一些东西。 从 GitHub 获取一些存储库，克隆它们，调整脚本，并以某种方式自定义它们。 最终它变成了某种手工工作。
因此，在本次演讲中，我将尝试为您提供一些有关如何选择监控的知识，不仅适用于 PostgreSQL，还适用于数据库。 并为您提供知识，使您能够完成您的监控，以便从中获得一些好处，以便您可以受益地监控您的数据库，以便及时预防任何即将发生的紧急情况。
本报告中的想法可以直接适用于任何数据库，无论是 DBMS 还是 noSQL。 因此，不仅有 PostgreSQL，而且还会有很多关于如何在 PostgreSQL 中做到这一点的食谱。 将会有查询示例、PostgreSQL 用于监控的实体示例。 如果您的 DBMS 具有相同的功能，允许您将它们置于监控中，那么您也可以调整它们，添加它们，那就太好了。
我不会出现在报告中
讨论如何交付和存储指标。 我不会说任何关于数据后处理并将其呈现给用户的事情。 我不会说任何关于警报的事情。
但随着故事的进展，我会展示现有监控的不同截图，并以某种方式批评它们。 但尽管如此，我会尽量不提及品牌，以免为这些产品制造广告或反广告。 因此，一切巧合都是随机的，留给你想象。
首先我们先来了解一下什么是监控。 监控是一件非常重要的事情。 每个人都明白这一点。 但同时，监控与业务产品无关，不会直接影响公司的利润，因此始终将时间分配给剩余的监控。 如果我们有时间，那么我们会进行监控；如果我们没有时间，那么好吧，我们会将其放入待办事项中，有一天我们会返回这些任务。
因此，从我们的实践来看，当我们来到客户那里时，监控往往是不完整的，没有任何有趣的东西可以帮助我们更好地处理数据库。 因此监控始终需要完成。
数据库是如此复杂，也需要监控，因为数据库是信息存储库。 信息对于公司来说非常重要；它不能以任何方式丢失。 但与此同时，数据库是非常复杂的软件。 它们由大量组件组成。 其中许多组件都需要进行监控。
如果我们具体谈论 PostgreSQL，那么它可以以由大量组件组成的方案的形式表示。 这些组件相互作用。 同时，PostgreSQL还有所谓的Stats Collector子系统，它允许您收集有关这些子系统运行情况的统计数据，并为管理员或用户提供某种接口，以便他可以查看这些统计数据。
这些统计数据以一组特定的函数和视图的形式呈现。 它们也可以称为表格。 也就是说，使用常规的 psql 客户端，您可以连接到数据库，对这些函数和视图进行选择，并获取有关 PostgreSQL 子系统操作的一些具体数字。
您可以将这些数字添加到您最喜欢的监控系统中、绘制图表、添加功能并获得长期分析。
但在本报告中，我不会完整介绍所有这些功能，因为这可能需要一整天的时间。 我将逐字地讨论两、三或四件事，并告诉您它们如何帮助更好地进行监控。
如果我们谈论数据库监控，那么需要监控什么？ 首先，我们需要监视可用性，因为数据库是一种向客户端提供数据访问的服务，我们需要监视可用性，并提供其一些定性和定量特征。
我们还需要监视连接到数据库的客户端，因为它们既可以是正常客户端，也可以是可能损害数据库的有害客户端。 他们还需要受到监控并跟踪他们的活动。
当客户端连接到数据库时，很明显它们开始使用我们的数据，因此我们需要监视客户端如何使用数据：使用哪些表，以及在较小程度上使用哪些索引。 也就是说，我们需要评估客户创建的工作负载。
但工作量当然也包括请求。 应用程序连接到数据库，使用查询访问数据，因此评估数据库中的查询、监控它们的充分性、确保它们没有被歪曲编写、需要重写和制定一些选项以便它们运行得更快非常重要并具有更好的性能。
由于我们谈论的是数据库，因此数据库始终是后台进程。 后台进程有助于将数据库性能维持在良好的水平，因此它们自身需要一定量的资源来运行。 同时，它们可以与客户端请求资源重叠，因此贪婪的后台进程可以直接影响客户端请求的性能。 因此，还需要对它们进行监视和跟踪，以便后台进程不会出现扭曲。
而数据库监控方面的所有这些仍然保留在系统指标中。 但考虑到我们的大部分基础设施正在迁移到云端，单个主机的系统指标总是淡出背景。 但在数据库中它们仍然相关，当然，也有必要监控系统指标。
系统指标的一切或多或少都很好，所有现代监控系统都已经支持这些指标，但总的来说，一些组件仍然不够，需要添加一些东西。 我也会谈到它们，会有几张关于它们的幻灯片。
该计划的第一点是可达性。 什么是可达性？ 我理解的可用性是基础服务连接的能力，即基础被提升，它作为服务接受来自客户端的连接。 这种可访问性可以通过某些特征来评估。 在仪表板上显示这些特征非常方便。
大家都知道什么是仪表板。 这是当您看一眼总结了必要信息的屏幕时。 并且可以立即判断数据库是否有问题。
因此，数据库的可用性和其他关键特征应始终显示在仪表板上，以便您随时掌握这些信息。 一些额外的细节已经有助于事件调查，在调查某些紧急情况时，它们已经需要放置在辅助仪表板上，或隐藏在通往第三方监控系统的深入链接中。
一个众所周知的监控系统的示例。 这是一个非常酷的监控系统。 她收集了大量数据，但从我的角度来看，她对仪表板有一个奇怪的概念。 有一个“创建仪表板”的链接。 但是，当您创建仪表板时，您会创建一个包含两列的列表，即一个图表列表。 当您需要查看某些内容时，您可以开始用鼠标单击、滚动，寻找所需的图表。 这需要时间，即没有仪表板本身。 只有图表列表。
您应该向这些仪表板添加什么？ 您可以从响应时间等特征开始。 PostgreSQL 有 pg_stat_statements 视图。 默认情况下它是禁用的，但它是应始终启用和使用的重要系统视图之一。 它存储有关数据库中已执行的所有正在运行的查询的信息。
因此，我们可以从以下事实开始：我们可以使用上述字段将所有请求的总执行时间除以请求数。 但这是医院的平均温度。 我们可以从其他字段开始——最小查询执行时间、最大值和中位数。 我们甚至可以构建百分位数；PostgreSQL 有相应的函数。 我们可以得到一些数字来表征数据库对已完成请求的响应时间，即我们不执行假请求“select 1”并查看响应时间，但我们分析已完成请求的响应时间并绘制要么是一个单独的图，要么我们基于它构建一个图表。
监控系统当前生成的错误数量也很重要。 为此，您可以使用 pg_stat_database 视图。 我们重点关注 xact_rollback 字段。 该字段不仅显示数据库中发生的回滚次数，还考虑了错误次数。 相对而言，我们可以在仪表板中显示这个数字，看看我们当前有多少错误。 如果有很多错误，那么这是一个很好的理由来查看日志，看看它们是什么类型的错误以及它们发生的原因，然后投入并解决它们。
您可以添加转速表之类的东西。 这些是每秒的事务数和每秒的请求数。 相对而言，您可以将这些数字作为数据库当前的性能，并观察是否存在请求峰值、事务峰值，或者相反，是否由于某些后端出现故障而导致数据库负载不足。 重要的是要始终查看这个数字并记住，对于我们的项目来说，这种性能是正常的，但是上面和下面的值已经是某种有问题且难以理解的，这意味着我们需要看看为什么这些数字是好高。
为了估计事务数量，我们可以再次参考pg_stat_database视图。 我们可以将提交次数和回滚次数相加，得到每秒的事务数。
每个人都明白一笔交易可以容纳多个请求吗？ 因此TPS和QPS略有不同。
每秒的请求数可以从 pg_stat_statements 中获取，并简单计算所有已完成请求的总和。 很明显，我们将当前值与前一个值进行比较，减去它，得到增量，并得到数量。
如果需要，您可以添加其他指标，这也有助于评估我们数据库的可用性并监控是否存在任何停机时间。
这些指标之一是正常运行时间。 但 PostgreSQL 的正常运行时间有点棘手。 我会告诉你原因。 PostgreSQL 启动后，正常运行时间开始报告。 但如果在某个时刻，比如晚上运行某个任务，出现 OOM-killer 强行终止 PostgreSQL 子进程，那么在这种情况下 PostgreSQL 会终止所有客户端的连接，重置分片内存区域并开始恢复最后一个检查站。 虽然从检查点的恢复持续，但数据库不接受连接，即这种情况可以评估为停机。 但正常运行时间计数器不会重置，因为它从一开始就考虑了邮局管理员的启动时间。 因此，此类情况可以跳过。
您还应该监控真空工人的数量。 大家知道PostgreSQL中的autovacuum是什么吗？ 这是 PostgreSQL 中一个有趣的子系统。 关于她的文章很多，报道也很多。 关于真空及其如何工作有很多讨论。 许多人认为这是一种必要的罪恶。 但事实就是这样。 这类似于垃圾收集器，可以清除任何事务不需要的行的过时版本，并为新行释放表和索引中的空间。
为什么需要监控它？ 因为真空有时会造成很大的伤害。 它消耗大量资源，并且客户端请求开始受到影响。
并且应该通过 pg_stat_activity 视图来监控，我将在下一节中讨论。 该视图显示数据库中的当前活动。 通过此活动，我们可以跟踪当前正在工作的吸尘器的数量。 我们可以跟踪 Vacuum 并查看是否超出了限制，那么这就是研究 PostgreSQL 设置并以某种方式优化 Vacuum 操作的原因。
关于 PostgreSQL 的另一件事是 PostgreSQL 非常厌倦长事务。 尤其是那些长时间徘徊且不执行任何操作的交易。 这就是所谓的statididle-in-transaction。 这样的事务会持有锁并阻止真空工作。 结果，桌子膨胀并增大。 使用这些表的查询开始运行速度变慢，因为您需要将所有旧版本的行从内存移至磁盘并移回。 因此，时间、最长事务的持续时间、最长的真空请求也需要监控。 如果我们看到一些进程已经运行了很长时间，对于OLTP负载来说已经超过10-20-30分钟，那么我们需要关注它们并强制终止它们，或者优化应用程序以便它们不会被调用，也不会挂那么久。 对于分析工作负载，10-20-30 分钟是正常的；也有更长的时间。
接下来我们可以选择连接客户端。 当我们已经创建了仪表板并在其上发布了关键可用性指标时，我们还可以在其中添加有关已连接客户端的其他信息。
有关已连接客户端的信息很重要，因为从 PostgreSQL 的角度来看，客户端是不同的。 有好的客户，也有坏的客户。
一个简单的例子。 通过客户我了解该应用程序。 应用程序已连接到数据库并立即开始向数据库发送请求，数据库处理并执行它们，并将结果返回给客户端。 这些都是好的、正确的客户。
在某些情况下，客户端已连接，它保持连接，但不执行任何操作。 它处于空闲状态。
但也有不好的客户。 例如，同一个客户端连接、打开事务、在数据库中执行某些操作，然后进入代码，例如访问外部源或处理接收到的数据。 但他并没有完成交易。 并且事务挂在数据库中并在线上被锁定。 这是一个糟糕的状况。 如果应用程序内部某个地方突然因异常而失败，则事务可以在很长一段时间内保持打开状态。 而这直接影响PostgreSQL的性能。 PostgreSQL 会更慢。 因此，及时追踪此类客户并强制终止其工作非常重要。 并且您需要优化您的应用程序，以免出现此类情况。
其他不良客户正在等待客户。 但他们会因为环境而变坏。 例如，一个简单的空闲事务：它可以打开一个事务，在某些行上锁定，然后在代码中的某个地方它将失败，留下一个挂起的事务。 另一个客户端将请求相同的数据，但他将遇到锁，因为该挂起的事务已经在某些所需的行上持有锁。 第二个事务将等待第一个事务完成或被管理员强制关闭。 因此，挂起的事务可能会累积并填满数据库连接限制。 当限制已满时，应用程序将无法再使用数据库。 这已经是该项目的紧急情况。 因此，需要及时跟踪不良客户并做出响应。
另一个监控的例子。 这里已经有一个不错的仪表板了。 上面有关于连接的信息。 DB 连接 – 8 个。 仅此而已。 我们没有关于哪些客户端处于活动状态、哪些客户端处于闲置状态、什么都不做的信息。 没有有关待处理事务和待处理连接的信息，即，这是一个显示连接数量的数字，仅此而已。 然后自己猜一下。
因此，要将这些信息添加到监控中，您需要访问pg_stat_activity系统视图。 如果您在 PostgreSQL 上花费了大量时间，那么这是一个非常好的视图，应该成为您的朋友，因为它显示了 PostgreSQL 中当前的活动，即其中正在发生的事情。 对于每个进程，都有一个单独的行显示有关该进程的信息：从哪个主机建立连接、在什么用户下、在什么名称下、事务何时启动、当前正在运行什么请求、上次执行什么请求。 因此，我们可以使用 stat 字段评估客户端的状态。 相对而言，我们可以按此字段进行分组，并获取数据库中当前的统计信息以及数据库中具有此统计信息的连接数。 我们可以将已经收到的数字发送到我们的监控并根据它们绘制图表。
评估交易的持续时间也很重要。 我已经说过评估真空的持续时间很重要，但交易也以同样的方式评估。 有 xact_start 和 query_start 字段。 相对而言，它们显示了事务的开始时间和请求的开始时间。 我们采用显示当前时间戳的 now() 函数，并减去事务和请求时间戳。 我们得到交易的持续时间，请求的持续时间。
如果我们看到长交易，我们应该已经完成它们。 对于 OLTP 负载，长事务已经超过 1-2-3 分钟. 对于 OLAP 工作负载，长事务是正常的，但如果它们需要两个多小时才能完成，那么这也表明我们在某个地方存在偏差。
一旦客户连接到数据库，他们就开始使用我们的数据。 他们访问表，访问索引以从表中获取数据。 评估客户如何与这些数据交互非常重要。
为了评估我们的工作量并大致了解哪些表对我们来说“最热门”，这是必要的。 例如，当我们想要将“热”表放置在某种快速 SSD 存储上时，就需要这样做。 例如，一些我们很长时间没有使用的归档表可以移动到某种“冷”归档，移动到SATA驱动器并让它们住在那里，它们将根据需要被访问。
这对于在任何发布和部署后检测异常也很有用。 假设该项目发布了一些新功能。 例如，我们添加了使用数据库的新功能。 如果我们绘制表使用情况图表，我们可以轻松地检测到这些图表上的这些异常情况。 例如，更新突发或删除突发。 它将非常明显。
您还可以检测“浮动”统计数据中的异常情况。 这是什么意思？ PostgreSQL 有一个非常强大且非常好的查询调度程序。 并且开发人员投入了大量的时间来开发它。 他如何工作？ 为了做好计划，PostgreSQL会以一定的时间间隔和一定的频率来统计表中数据的分布情况。 这些是最常见的值：唯一值的数量、表中有关 NULL 的信息、大量信息。
根据这些统计信息，规划器构建多个查询，选择最优的一个，并使用该查询计划来执行查询本身并返回数据。
而且统计数据恰好“浮动”。 表中的质量和数量数据发生了某种变化，但没有进行统计。 而且制定的计划可能不是最佳的。 如果根据收集到的监控结果，根据表格，我们的计划不是最理想的，我们将能够看到这些异常情况。 例如，在某个地方数据发生了质的变化，开始使用顺序遍历表而不是索引，即如果一个查询只需要返回 100 行（限制为 100 行），那么将为该查询执行完整搜索。 而这总是对性能产生非常糟糕的影响。
我们可以在监控中看到这一点。 并且已经查看了这个查询，为其运行解释，收集统计信息，构建一个新的附加索引。 并且已经对这个问题做出了回应。 这就是为什么它很重要。
另一个监控的例子。 我想很多人认识他是因为他很受欢迎。 谁在他们的项目中使用它 ？ 谁将此产品与 Prometheus 结合使用？ 事实上，在这个监控的标准存储库中，有一个用于使用 PostgreSQL 的仪表板 - 普罗米修斯。 但有一个细节不好。
有几个图表。 字节以单位表示，即有 5 个图。 它们是插入数据、更新数据、删除数据、获取数据和返回数据。 测量单位是字节。 但问题是 PostgreSQL 中的统计数据返回元组（行）中的数据。 因此，这些图是多次、数十次低估工作量的好方法，因为元组不是字节，元组是字符串，它有很多字节并且总是可变长度。 也就是说，使用元组以字节为单位计算工作负载是一项不现实的任务或者非常困难。 因此，当您使用仪表板或内置监控时，了解其正常工作并返回正确评估的数据始终很重要。
如何获取这些表的统计信息？ 为此，PostgreSQL 有一系列特定的视图。 主要观点是 。 User_tables - 这意味着代表用户创建的表。 相比之下，PostgreSQL 本身使用一些系统视图。 还有一个汇总表Alltables，其中包括系统表和用户表。 您可以从您最喜欢的任何一个开始。
使用上述字段，您可以估计插入、更新和删除的数量。 我使用的仪表板示例使用这些字段来评估工作负载的特征。 因此，我们也可以在它们的基础上继续发展。 但值得记住的是，这些是元组，而不是字节，所以我们不能只以字节为单位。
基于这些数据，我们可以构建所谓的 TopN 表。 例如，前 5 名、前 10 名。 您可以跟踪那些比其他表回收更多的热表。 例如，插入 5 个“热门”表。 使用这些 TopN 表，我们可以评估我们的工作负载，并可以评估任何发布、更新和部署后的工作负载爆发。
评估表的大小也很重要，因为有时开发人员推出新功能，我们的表开始变得很大，因为他们决定添加额外的数据量，但没有预测这会如何影响数据库的大小。 这样的案例也让我们感到意外。
现在问你一个小问题。 当您注意到数据库服务器上的负载时，会出现什么问题？ 您的下一个问题是什么？
但实际上问题是这样出现的。 负载会引起什么请求？ 也就是说，查看由负载引起的进程并不有趣。 很明显，如果主机有数据库，那么数据库就在那里运行，并且很明显只有数据库会在那里被处理。 如果我们打开 Top，我们将看到 PostgreSQL 中正在执行某些操作的进程列表。 Top 并不清楚他们在做什么。
因此，您需要找到那些导致最高负载的查询，因为调整查询通常比调整 PostgreSQL 或操作系统配置，甚至调整硬件带来更多的利润。 据我估计，这个比例大约是80-85-90%。 而且这个过程完成得更快。 更正请求比更正配置、安排重新启动（尤其是数据库无法重新启动）或添加硬件更快。 在某处重写查询或添加索引以从此查询获得更好的结果会更容易。
因此，有必要监控请求及其充分性。 我们再举一个监控的例子。 这里似乎也有出色的监控。 有关于复制的信息，有关于吞吐量、阻塞、资源利用率的信息。 一切都很好，但没有关于请求的信息。 目前尚不清楚我们的数据库中正在运行哪些查询、它们运行了多长时间以及这些查询中有多少。 我们始终需要在监控中包含这些信息。
要获取此信息，我们可以使用 pg_stat_statements 模块。 基于它，您可以构建各种图表。 例如，您可以获得有关最频繁查询的信息，即有关执行最频繁的查询的信息。 是的，部署后查看它并了解请求是否激增也非常有用。
您可以监控最长的查询，即那些花费最长时间才能完成的查询。 它们在处理器上运行，消耗 I/O。 我们还可以使用字段total_time、mean_time、blk_write_time 和blk_read_time 来评估这一点。
我们可以评估和监控资源使用方面最繁重的请求，即从磁盘读取的请求、使用内存的请求，或者相反，创建某种写入负载的请求。
我们可以评估最慷慨的请求。 这些是返回大量行的查询。 例如，这可能是他们忘记设置限制的某些请求。 它只是返回表的全部内容或跨查询表的查询。
您还可以监视使用临时文件或临时表的查询。
而且我们仍然有后台进程。 后台进程主要是检查点，或者也称为检查点，它们是自动清理和复制。
另一个监控的例子。 左侧有一个“维护”选项卡，进入它并希望看到一些有用的东西。 但这里只是真空操作和统计数据的时间，仅此而已。 这是非常糟糕的信息，因此我们总是需要了解后台进程如何在我们的数据库中工作以及它们的工作是否存在任何问题。
当我们查看检查点时，我们应该记住检查点将脏页从分片内存区域刷新到磁盘，然后创建检查点。 如果 PostgreSQL 在紧急情况下突然终止，这个检查点可以用作恢复位置。
因此，为了将所有“脏”页刷新到磁盘，您需要进行一定量的写入。 通常，在具有大量内存的系统上，这已经很多了。 如果我们在短时间内频繁地创建检查点，那么磁盘性能将会显着下降。 客户端请求将因缺乏资源而受到影响。 他们会争夺资源并缺乏生产力。
因此，通过 pg_stat_bgwriter 使用指定的字段，我们可以监视发生的检查点的数量。 如果我们在一段时间内（10-15-20分钟，半小时）有很多检查点，例如3-4-5，那么这可能已经是一个问题了。 您已经需要查看数据库，查看配置，是什么导致了如此丰富的检查点。 也许正在进行某种大型录音。 我们已经可以评估工作负载，因为我们已经添加了工作负载图表。 我们已经可以调整检查点参数并确保它们不会极大地影响查询性能。
我再次回到 autovacuum，因为正如我所说，它可以轻松地增加磁盘和查询性能，因此估计 autovacuum 的量始终很重要。
数据库中 autovacuum 工作人员的数量是有限的。 默认情况下，有三个，所以如果我们总是有三个工作人员在数据库中工作，这意味着我们的 autovacuum 没有配置，我们需要提高限制，修改 autovacuum 设置并进入配置。
评估我们拥有哪些真空工人非常重要。 要么是由用户启动，要么是 DBA 来手动启动某种真空，这会产生负载。 我们遇到了一些问题。 或者这是拧开交易柜台的真空吸尘器的次数。 对于某些版本的 PostgreSQL 来说，这是非常严重的真空。 他们可以轻松地增加性能，因为他们读取整个表，扫描该表中的所有块。
当然，还有真空的持续时间。 如果我们有运行很长时间的长效真空吸尘器，那么这意味着我们再次需要注意真空吸尘器的配置，并且可能需要重新考虑其设置。 因为当vacuum长时间（3-4小时）在表上工作时，可能会出现一种情况，但在vacuum工作期间，表中又再次积累了大量的死行。 一旦吸尘完成，他就需要再次对这张桌子进行吸尘。 我们遇到了一种情况——无尽的真空。 在这种情况下，真空无法应对其工作，并且表的大小逐渐开始膨胀，尽管其中的有用数据量保持不变。 因此，在长时间的真空期间，我们总是查看配置并尝试优化它，但同时确保客户端请求的性能不会受到影响。
现在几乎没有 PostgreSQL 安装不具备流复制功能。 复制是将数据从主服务器移动到副本的过程。
PostgreSQL 中的复制是通过事务日志完成的。 该向导会生成事务日志。 事务日志通过网络连接传输到副本，然后在副本上再现。 这很简单。
因此，pg_stat_replication 视图用于监视复制延迟。 但对她来说，一切并不简单。 在版本 10 中，视图发生了一些变化。 首先，一些字段已被重命名。 并且添加了一些字段。 在版本 10 中，出现了一些字段，允许您以秒为单位估计复制延迟。 非常舒服。 在版本 10 之前，可以以字节为单位估计复制延迟。 此选项保留在版本 10 中，即您可以选择对您来说更方便的选项 - 以字节为单位估计延迟或以秒为单位估计延迟。 很多人两者都做。
但尽管如此，为了评估复制延迟，您需要知道日志在事务中的位置。 而这些事务日志位置正好在pg_stat_replication视图中。 相对而言，我们可以使用 pg_xlog_location_diff() 函数在事务日志中获取两个点。 计算它们之间的增量并获取复制延迟（以字节为单位）。 非常方便、简单。
在版本 10 中，该函数被重命名为 pg_wal_lsn_diff()。 一般来说，在所有出现“xlog”一词的函数、视图和实用程序中，它都会被值“wal”替换。 这适用于视图和函数。 这是一个创新。
另外，在版本 10 中，添加了专门显示滞后的行。 它们是写入延迟、刷新延迟、重放延迟。 也就是说，监控这些事情很重要。 如果我们发现复制滞后，那么我们需要调查它出现的原因、它来自哪里并解决问题。
几乎一切都符合系统指标。 当任何监控开始时，都会从系统指标开始。 这是处理器、内存、交换、网络和磁盘的处置。 但是，许多参数默认情况下并不存在。
如果回收过程一切正常，那么磁盘回收就会出现问题。 通常，监控开发人员会添加有关吞吐量的信息。 它可以以 iops 或字节为单位。 但他们忘记了磁盘设备的延迟和利用率。 这些是更重要的参数，使我们能够评估磁盘的负载情况以及速度有多慢。 如果延迟很高，则意味着磁盘存在一些问题。 如果利用率很高，则意味着磁盘无法应对。 这些是比吞吐量更好的特性。
此外，这些统计信息也可以从 /proc 文件系统中获得，就像回收处理器一样。 不知道为什么这个信息没有加入到监控中。 但尽管如此，将其纳入监控中还是很重要的。
这同样适用于网络接口。 有关于网络吞吐量（以数据包、字节为单位）的信息，但是没有关于延迟的信息，也没有关于利用率的信息，尽管这也是有用的信息。
任何监控都有缺点。 而且无论你采取什么样的监控，它总是不符合某些标准。 但尽管如此，它们正在开发，正在添加新功能和新事物，所以选择一些东西并完成它。
为了完成任务，您必须始终了解所提供的统计数据的含义以及如何使用它们来解决问题。
以及几个关键点：
- 您应该始终监控可用性并拥有仪表板，以便您可以快速评估数据库的一切是否正常。
- 您始终需要了解哪些客户端正在使用您的数据库，以便清除不良客户端并将其击落。
- 评估这些客户如何处理数据非常重要。 您需要了解自己的工作量。
- 重要的是要在哪些查询的帮助下评估此工作负载的形成方式。 您可以评估查询，可以优化它们，重构它们，为它们构建索引。 这是非常重要的。
- 后台进程可能会对客户端请求产生负面影响，因此监视它们是否使用太多资源非常重要。
- 系统指标允许您制定扩展和增加服务器容量的计划，因此跟踪和评估它们也很重要。
如果您对这个主题感兴趣，那么您可以点击这些链接。
- 这是统计收集器的官方文档。 有所有统计视图的描述和所有字段的描述。 您可以阅读、理解和分析它们。 并基于它们构建您的图表并将其添加到您的监控中。
请求示例：
这是我们的公司存储库，也是我自己的存储库。 它们包含示例查询。 那里没有来自 select* from 系列的查询。 已经有现成的带有连接的查询，使用有趣的函数，允许您将原始数字转换为可读的、方便的值，即这些是字节、时间。 您可以拿起它们，查看它们，分析它们，将它们添加到您的监控中，并基于它们构建您的监控。
问题
问：你说你不会为品牌做广告，但我还是很好奇——你在项目中使用什么样的仪表板？
答：因人而异。 碰巧我们遇到一个客户，他已经有了自己的监控。 我们会向客户建议需要在监控中添加哪些内容。 最糟糕的情况是 Zabbix。 因为它不具备构建TopN图的能力。 我们自己用 ，因为我们正在与这些人就监控问题进行协商。 他们根据我们的技术规范监控 PostgreSQL。 我正在编写自己的宠物项目，它通过 Prometheus 收集数据并将其呈现在 。 我的任务是在 Prometheus 中创建我自己的导出器，然后在 Grafana 中渲染所有内容。
问题：是否有 AWR 报告或...聚合的类似物？ 你知道这样的事情吗？
答：是的，我知道 AWR 是什么，这是一件很酷的事情。 目前有多种自行车大致采用以下型号。 在某个时间间隔，一些基线会写入同一个 PostgreSQL 或单独的存储中。 你可以在互联网上谷歌搜索它们，它们就在那里。 这种东西的开发者之一坐在 sql.ru 论坛的 PostgreSQL 线程中。 你可以在那里抓住他。 是的，有这样的东西，它们可以使用。 再加上其 我也在写一个东西，让你可以做同样的事情。
PS1 如果您使用 postgres_exporter，您使用什么仪表板？ 其中有好几个。 它们已经过时了。 也许社区会创建一个更新的模板？
PS2 删除了 pganalyze，因为它是一种专有的 SaaS 产品，专注于性能监控和自动调整建议。
只有注册用户才能参与调查。 拜托
您认为哪种自托管 postgresql 监控（带仪表板）最好？
-
30,0%Zabbix + 来自 Alexey Lesovsky 或 zabbix 4.4 或 libzbxpgsql + zabbix libzbxpgsql + zabbix3 的补充
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze 是专有 SaaS - 我无法删除它1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 位用户投票。 26 名用户弃权。
来源： habr.com