🥇高性能和本机分区：支持 TimescaleDB 的 Zabbix

Zabbix是一个监控系统。与任何其他系统一样，它面临着所有监控系统的三个主要问题：收集和处理数据、存储历史记录以及清理数据。

接收、处理和记录数据的阶段需要时间。虽然不多，但对于大型系统来说，这可能会导致较大的延迟。存储问题是数据访问问题。它们用于报告、检查和触发器。数据访问的延迟也会影响性能。当数据库增长时，必须删除不相关的数据。删除是一项困难的操作，也会消耗一些资源。

Zabbix中收集和存储过程中的延迟问题通过缓存来解决：几种类型的缓存，数据库中的缓存。为了解决第三个问题，缓存不适合，所以Zabbix使用了TimescaleDB。他会告诉你这件事 安德烈·古欣 - 技术支持工程师 Zabbix SIA。 Andrey 已经支持 Zabbix 超过 6 年，并且在性能方面拥有直接的经验。

TimescaleDB 是如何工作的，与常规 PostgreSQL 相比，它能提供什么性能？ Zabbix对于TimescaleDB数据库扮演什么角色？如何从头开始以及如何从 PostgreSQL 迁移以及哪种配置具有更好的性能？关于这一切都在削减之下。

生产力挑战

每个监控系统都面临着特定的性能挑战。我会讲其中三个：数据收集和处理、存储和历史清除。

快速数据收集和处理。 一个好的监控系统应该快速接收所有数据并根据触发表达式进行处理 - 根据其标准。处理完成后，系统还必须快速将这些数据保存到数据库中以供以后使用。

历史存储。 一个好的监控系统应该将历史记录存储在数据库中并提供对指标的轻松访问。报告、图表、触发器、阈值和计算的警报数据项需要使用历史记录。

清除历史记录。 有时有一天您不需要存储指标。为什么需要 5 年前、一两个月收集的数据：一些节点已被删除，一些主机或指标不再需要，因为它们已经过时且不再收集。一个好的监控系统应该存储历史数据并时常删除，这样数据库就不会增长。

清理陈旧数据是一个极大影响数据库性能的关键问题。

Zabbix 中的缓存

在Zabbix中，第一次和第二次调用是使用缓存解决的。 RAM用于收集和处理数据。用于存储 - 触发器、图表和计算数据元素中的历史记录。在数据库方面，有一些基本选择的缓存，例如图形。

Zabbix 服务器本身的缓存是：

配置缓存；
值缓存；
历史缓存；
趋势缓存。

让我们更详细地考虑它们。

配置缓存

这是我们存储指标、主机、数据项、触发器的主要缓存 - 预处理和数据收集所需的一切。

所有这些都存储在 ConfigurationCache 中，以免在数据库中创建不必要的查询。服务器启动后，我们更新此缓存，创建并定期更新配置。

数据收集

这张图很大，但主要是 采摘者。这些是各种“轮询器”——组装过程。它们负责不同类型的组装：它们通过 SNMP、IPMI 收集数据，并将其全部传输到预处理。

收集器的轮廓为橙色。

Zabbix 已经计算出聚合检查所需的聚合项。如果我们有它们，我们会直接从 ValueCache 获取它们的数据。

预处理历史缓存

所有收集器都使用 ConfigurationCache 来接收作业。然后他们将它们转移到预处理。

预处理使用 ConfigurationCache 来接收预处理步骤。它以各种方式处理这些数据。

使用 PreProcessing 处理数据后，我们将其保存在 HistoryCache 中进行处理。数据收集到此结束，我们继续进行 Zabbix 中的主要流程 - 历史同步器，因为它是一个整体架构。

注意：预处理是一个相当困难的操作。在 v 4.2 中，它已移至代理。如果您有一个非常大的 Zabbix，具有大量数据元素和收集频率，那么这会使工作变得更加容易。

ValueCache、历史和趋势缓存

历史同步器是原子地处理每个数据元素（即每个值）的主进程。

历史同步器从 HistoryCache 中获取值并检查配置是否存在计算触发器。如果它们存在，它就会进行计算。

历史记录同步器创建事件、升级以根据配置和记录创建警报（如果需要）。如果有后续处理的触发器，那么它会将这个值存储在ValueCache中，以免访问历史表。这就是 ValueCache 填充计算触发器和计算元素所需的数据的方式。

历史同步器将所有数据写入数据库，然后写入磁盘。处理过程到此结束。

缓存在数据库中

当您想要查看事件的图表或报告时，数据库端有各种缓存：

Innodb_buffer_pool 在 MySQL 方面；
shared_buffers 在 PostgreSQL 方面；
effective_cache_size 在 Oracle 方面；
shared_pool 在 DB2 端。

还有许多其他缓存，但这些是所有数据库的主要缓存。它们允许您将查询经常需要的数据存储在 RAM 中。他们有自己的技术。

数据库性能至关重要

Zabbix服务器不断收集数据并写入。重新启动时，它还会从历史记录中读取数据以填充 ValueCache。使用脚本和报告 扎比克斯API，它构建在 Web 界面上。 Zabbix API 访问数据库并检索图表、报告、事件列表和最新问题所需的数据。

为了可视化 - 格拉法纳。这是我们用户中流行的解决方案。它可以直接通过Zabbix API发送请求并发送到数据库，并为接收数据创建一定的竞争。因此，需要对数据库进行更精细、更好的调整，以匹配结果和测试的快速交付。

管家

Zabbix中的第三个性能挑战是使用Housekeeper清除历史记录。它遵循所有设置 - 数据元素指示存储动态变化（趋势）的时间（以天为单位）。

我们即时计算 TrendsCache。当数据到达时，我们将其聚合一小时并将其记录在表格中以了解趋势变化的动态。

Housekeeper 使用通常的“选择”启动数据库并删除信息。这并不总是有效，从内部流程的性能图表可以看出。

红色图显示历史记录同步器一直处于繁忙状态。顶部的橙色图是不断运行的 Housekeeper。他等待数据库删除他指定的所有行。

什么时候应该禁用管家？例如，有一个“Item ID”，需要在一定时间内删除最后5行。当然，这是通过索引发生的。但通常数据集非常大，数据库仍然从磁盘读取并放入缓存。对于数据库来说，这始终是一项非常昂贵的操作，并且根据数据库的大小，可能会导致性能问题。

管家很容易被禁用。在Web界面中，有一个针对管家的“常规管理”设置。我们禁用内部趋势历史记录的内部管理，它不再管理它。

Housekeeper 被关闭，图表趋于平稳 - 在这种情况下可能存在哪些问题以及什么可以帮助解决第三个性能挑战？

分区——分区或分区

通常，在我列出的每个关系数据库上以不同的方式配置分区。每个都有自己的技术，但总体上是相似的。创建新分区通常会导致某些问题。

通常，分区的配置取决于“设置”——一天内创建的数据量。一般来说，分区会在一天内发出，这是最少的。对于新批次的趋势 - 1 个月。

如果“设置”非常大，这些值可能会发生变化。如果小型“设置”高达 5 nvps（每秒新值），中型“设置”为 000 到 5，那么大型“设置”则超过 000 nvps。这些是大型和超大型安装，需要仔细配置数据库。

对于非常大的安装，一天的时间可能不是最佳的。我见过每天 40 GB 或更多的 MySQL 分区。这是一个非常大量的数据，可能会导致问题，需要减少。

分区能带来什么？

分区表。通常这些是磁盘上的单独文件。查询计划会更优化地选择一个分区。通常分区是按范围使用的——对于 Zabbix 来说也是如此。我们在那里使用“时间戳”——自时代开始以来的时间。这些对于我们来说都是普通的数字。您可以设置一天的开始和结束 - 这是一个分区。

快速移除 - DELETE。选择一个文件/子表，而不是选择要删除的行。

显着加快数据检索速度 SELECT - 使用一个或多个分区，而不是整个表。如果您访问两天前的数据，则可以更快地从数据库中检索该数据，因为您只需将一个文件加载到缓存中并返回它，而不是一张大表。

通常许多数据库也会加速 INSERT — 插入到子表中。

时标数据库

对于 v 4.2，我们将注意力转向了 TimescaleDB。这是带有本机接口的 PostgreSQL 扩展。该扩展可以有效地处理时间序列数据，而不会失去关系数据库的优点。 TimescaleDB 还会自动分区。

TimescaleDB有一个概念 超稳定 您创建的（超表）。它包含块 - 分区。块是自动管理的超表片段，不会影响其他片段。每个块都有自己的时间范围。

TimescaleDB 与 PostgreSQL

TimescaleDB 的工作效率非常高。该扩展的制造商声称他们使用了更正确的查询处理算法，特别是inserts 。随着数据集插入大小的增长，算法保持恒定的性能。

在 200 亿行之后，PostgreSQL 通常开始显着下降，性能下降至 0。TimescaleDB 允许您高效地插入任意数量的数据的“插入”。

安装

对于任何软件包来说，安装 TimescaleDB 都相当容易。在文件资料一切都有详细描述 - 这取决于官方 PostgreSQL 包。 TimescaleDB 也可以手动构建和编译。

对于 Zabbix 数据库，我们只需激活扩展即可：

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

你激活 extension 并为 Zabbix 数据库创建它。最后一步是创建一个超级表。

将历史表迁移到 TimescaleDB

有一个专门的函数可以实现这个功能 create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

该函数有三个参数。第一的 - 数据库中的表，您需要为其创建一个超表。第二 - 场，根据您需要创建 chunk_time_interval — 要使用的分区块的间隔。就我而言，间隔是一天 - 86。

第三个参数 - migrate_data。如果你设置 true，然后所有当前数据都会转移到预先创建的块中。我自己用过 migrate_data。我有大约 1 TB，花了一个多小时。甚至在某些情况下，在测试过程中，我删除了不需要存储的字符类型的历史数据，以免传输它们。

最后一步 - UPDATE：在 db_extension 放 timescaledb以便数据库了解此扩展名的存在。 Zabbix 激活它并正确使用数据库的语法和查询 - 这些功能是 TimescaleDB 所必需的。

硬件配置

我用了两台服务器。第一的 - 虚拟机。它非常小：20 个 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz 处理器、16 GB RAM 和 200 GB SSD。

我在其上安装了 PostgreSQL 10.8、Debian 10.8-1.pgdg90+1 操作系统和 xfs 文件系统。我对所有内容进行了最低程度的配置以使用这个特定的数据库，减去 Zabbix 本身将使用的数据库。

在同一台机器上有一个 Zabbix 服务器、PostgreSQL 和 负载代理。我有 50 个正在使用的活跃代理 LoadableModule非常快速地生成不同的结果：数字、字符串。我用大量数据填充了数据库。

最初的配置包含 5 个元素 每个主机的数据。几乎每个元素都包含一个触发器，使其类似于真实的安装。在某些情况下，有不止一个触发因素。对于一个网络节点有 3-000 个触发器.

数据项更新间隔 - 4-7秒。我不仅使用 50 个代理，还添加了更多代理来调节负载本身。此外，使用数据元素，我动态调整负载并将更新间隔减少到 4 秒。

PostgreSQL。 35 次 nvps

我在这个硬件上的第一次运行是在纯 PostgreSQL 上——每秒 35 个值。正如您所看到的，插入数据只需几分之一秒的时间 - 一切都很好而且很快。唯一的问题是 200 GB SSD 磁盘很快就会被填满。

这是一个标准的 Zabbix 服务器性能仪表板。

第一个蓝色图是每秒的值数量。右侧第二张图是构建过程的加载。第三个是加载内部构建进程：历史同步器和 Housekeeper，它们已经在这里运行了相当长的一段时间。

第四张图显示了 HistoryCache 的使用情况。这是插入数据库之前的一种缓冲区。绿色的第五张图显示了 ValueCache 的使用情况，即触发器命中了多少 ValueCache - 这是每秒数千个值。

PostgreSQL。 50 次 nvps

然后我在相同的硬件上将负载增加到每秒 50 个值。

从Housekeeper加载时，插入10万个值需要2-3秒。

管家已经开始干涉工作了。

第三张图显示，总体而言，捕获器和历史同步器的负载仍为 60%。在第四张图中，HistoryCache 在 Housekeeper 操作期间已经开始相当活跃地填充。已满 20%，约为 0,5 GB。

PostgreSQL。 80 次 nvps

然后我将负载增加到每秒 80 个值。这大约有 400 万个数据元素和 280 万个触发器。

三十个历史同步器的加载成本已经相当高了。

我还增加了各种参数：历史同步器、缓存。

在我的硬件上，历史同步器的负载增加到最大。 HistoryCache 很快就填满了数据——用于处理的数据已经累积在缓冲区中。

这段时间我观察了处理器、RAM和其他系统参数的使用情况，发现磁盘利用率达到了最大。

我已经实现了使用 最大磁盘容量 在此硬件和该虚拟机上。在这样的强度下，PostgreSQL开始相当积极地刷新数据，磁盘不再有时间写入和读取。

第二台服务器

我选择了另一台服务器，它已经有 48 个处理器和 128 GB RAM。我对其进行了调整 - 将其设置为 60 个历史记录同步器，并获得了可接受的性能。

事实上，这已经是生产力的极限了，需要做一些事情。

时间刻度数据库。 80 次 nvps

我的主要任务是测试 TimescaleDB 针对 Zabbix 负载的功能。每秒 80 万个值很多，收集指标的频率（当然 Yandex 除外）和相当大的“设置”。

每张图中都有一个下降——这正是数据迁移。 Zabbix 服务器出现故障后，历史同步器的加载配置文件发生了很大变化 - 下降了 XNUMX 次。

TimescaleDB 允许您将数据插入速度提高近 3 倍，并且使用更少的 HistoryCache。

因此，您将及时收到数据。

时间刻度数据库。 120 次 nvps

然后我将数据元素的数量增加到500万个，主要任务是测试TimescaleDB的能力——我收到每秒125万个值的计算值。

这是一个可以长期有效的有效“设置”。但由于我的磁盘只有 1,5 TB，所以几天之内就填满了。

最重要的是，同时创建了新的 TimescaleDB 分区。

这对于性能来说是完全察觉不到的。例如，当在 MySQL 中创建分区时，一切都不同了。这通常发生在晚上，因为它会阻止一般插入、处理表并可能导致服务降级。 TimescaleDB 的情况并非如此。

作为示例，我将展示社区中许多图表的一张图表。图中，TimescaleDB 已启用，因此处理器上使用 io.weight 的负载下降了。内部流程元素的使用也减少了。而且，这是普通煎饼盘上的普通虚拟机，而不是SSD。

发现

TimescaleDB 是小型“设置”的良好解决方案，这会影响磁盘性能。它将允许您继续良好地工作，直到数据库尽快迁移到硬件。

TimescaleDB 易于配置，可提高性能，与 Zabbix 配合良好， 与 PostgreSQL 相比有优势.

如果您使用 PostgreSQL 并且不打算更改它，我建议 将 PostgreSQL 与 TimescaleDB 扩展结合使用 Zabbix。该解决方案在中等“设置”下也能有效工作。

当我们说“高性能”时，我们的意思是高负荷++。您很快就能了解使服务能够为数百万用户提供服务的技术和实践。列表报告 7 月 8 日和 XNUMX 日我们已经编译好了，但是这里聚会还可以提出更多建议。

订阅我们的通讯 и 电报，其中我们揭示了即将举行的会议的特点，并了解如何充分利用它。

来源： habr.com

高性能和本机分区：支持 TimescaleDB 的 Zabbix