我们将了解 Zabbix 如何使用 TimescaleDB 数据库作为后端。 我们将向您展示如何从头开始以及如何从 PostgreSQL 迁移。 我们还将提供两种配置的性能对比测试。
HighLoad++ 西伯利亚 2019。托木斯克大厅。 24 月 16 日 00:XNUMX。 论文和 。 下一次 HighLoad++ 会议将于 6 年 7 月 2020 日至 XNUMX 日在圣彼得堡举行。 详情及门票 .
安德烈·古希钦（Andrey Gushchin，以下简称“AG”）： – 我是一名Zabbix技术支持工程师（以下简称“Zabbix”），一名培训师。 我从事技术支持工作已超过 6 年，对性能有直接的经验。 今天我将讨论 TimescaleDB 与常规 PostgreSQL 10 相比可以提供的性能。此外，还有一些关于它的一般工作原理的介绍部分。
生产力面临的首要挑战：从数据收集到数据清理
首先，每个监控系统都面临某些性能挑战。 第一个生产力挑战是快速收集和处理数据。
一个好的监控系统应该快速、及时地接收所有数据，并根据触发表达式进行处理，即按照某种标准进行处理（不同的系统是不同的），并将其保存到数据库中，以便在系统中使用这些数据。未来。
第二个性能挑战是历史存储。 经常存储在数据库中，并可以快速方便地访问一段时间内收集的这些指标。 最重要的是，这些数据很容易获取，可以在报告、图表、触发器、某些阈值、警报等中使用它。
第三个性能挑战是历史清除，也就是说，当您达到不需要存储 5 年（甚至几个月或两个月）收集的任何详细指标的程度时。 某些网络节点被删除，或者某些主机不再需要这些指标，因为它们已经过时并且不再收集。 所有这些都需要清除，以便您的数据库不会变得太大。 一般来说，清除历史记录通常是对存储的严峻考验 - 它通常会对性能产生非常大的影响。
如何解决缓存问题？
我现在具体讲一下Zabbix。 在Zabbix中，第一次和第二次调用是使用缓存解决的。
数据收集和处理 - 我们使用 RAM 来存储所有这些数据。 现在将更详细地讨论这些数据。
此外，在数据库方面，还有一些主要选择的缓存 - 用于图形和其他内容。
Zabbix 服务器本身的缓存：我们有 ConfigurationCache、ValueCache、HistoryCache、TrendsCache。 这是什么？
ConfigurationCache是主要的缓存，我们在其中存储指标、主机、数据项、触发器； 处理预处理、收集数据、从哪些主机收集、以什么频率收集所需的一切。 所有这些都存储在 ConfigurationCache 中，以免访问数据库并创建不必要的查询。 服务器启动后，我们更新此缓存（创建它）并定期更新（取决于配置设置）。
在 Zabbix 中缓存。 数据采集
这里的图相当大：
该计划中的主要收集者是这些收集者：
这些是装配过程本身，负责不同类型装配的各种“轮询器”。 他们通过 icmp、ipmi 和各种协议收集数据并将其全部传输到预处理。
预处理历史缓存
另外，如果我们有计算数据元素（熟悉Zabbix的都知道），即计算、聚合数据元素，我们直接从ValueCache中取出。 稍后我会告诉你如何填充。 所有这些收集器都使用 ConfigurationCache 来接收其作业，然后将其传递给预处理。
预处理还使用 ConfigurationCache 来获取预处理步骤并以各种方式处理此数据。 从 4.2 版本开始，我们已将其移至代理。 这非常方便，因为预处理本身就是一个相当困难的操作。 而如果你有一个非常大的Zabbix，有大量的数据元素和很高的收集频率，那么这会大大简化工作。
因此，在我们使用预处理以某种方式处理这些数据后，我们将其保存在 HistoryCache 中，以便进一步处理。 数据收集到此结束。 我们继续进行主要流程。
历史同步器的工作
Zabbix 中的主要进程（因为它是整体架构）是历史同步器。 这是专门处理每个数据元素（即每个值）的原子处理的主流程：
- 值来了（它从 HistoryCache 中获取）；
- 检查配置同步器：是否有任何计算触发器 - 计算它们；
如果有 - 创建事件，创建升级以创建警报（如有必要）根据配置； - 记录触发器以供后续处理、聚合； 如果您在过去一小时等时间内进行聚合，则 ValueCache 会记住该值，以免进入历史表； 因此，ValueCache填充了计算触发器、计算元素等所需的必要数据；
- 然后历史同步器将所有数据写入数据库；
- 数据库将它们写入磁盘 - 这是处理过程结束的地方。
数据库。 缓存
在数据库方面，当您想要查看图表或一些事件报告时，有各种缓存。 但在这篇报告中我不会谈论它们。
对于 MySQL，有 Innodb_buffer_pool，以及一堆可以配置的不同缓存。
但这些是主要的：
- 共享缓冲区；
- 有效缓存大小；
- 共享池。
对于所有数据库，我说过都有某些缓存允许您将查询经常需要的数据存储在 RAM 中。 他们有自己的技术。
关于数据库性能
相应地，存在一个竞争环境，即Zabbix服务器收集数据并记录它。 重新启动时，它还会从历史记录中读取数据以填充 ValueCache 等。 在这里，您可以拥有使用 Zabbix API 的脚本和报告，该 API 构建在 Web 界面上。 Zabbix API 进入数据库并接收必要的数据以获取图表、报告或某种事件列表、最近的问题。
Grafana 也是一个非常流行的可视化解决方案，我们的用户也使用它。 能够通过Zabbix API和数据库直接登录。 它还为获取数据带来了一定的竞争：需要对数据库进行更精细、更好的调整，以满足结果和测试的快速交付。
清除历史记录。 Zabbix 有管家
Zabbix 中使用的第三个调用是使用 Housekeeper 清除历史记录。 管家遵循所有设置，即我们的数据元素表示存储多长时间（以天为单位）、存储趋势多长时间以及变化的动态。
我没有谈论 TrendCache，它是我们即时计算的：数据到达后，我们将其聚合一小时（大部分是最后一小时的数字），数量是平均值/最小值，我们每小时将其记录一次变化动态表（“趋势”）。 “管家”使用常规选择来启动和删除数据库中的数据，但这并不总是有效。
怎么理解是无效呢？ 内部流程的性能图可以看到下图：
您的历史记录同步器一直很忙（红色图）。 以及顶部的“红色”图表。 这是一个“管家”，它启动并等待数据库删除它指定的所有行。
让我们看一下 Item ID：您需要删除最后 5 个； 当然是通过索引。 但通常数据集相当大——数据库仍然从磁盘读取它并将其放入缓存中，这对于数据库来说是一个非常昂贵的操作。 根据其大小，这可能会导致某些性能问题。
您可以通过简单的方式禁用 Housekeeper - 我们有一个熟悉的 Web 界面。 在管理常规设置（“管家”设置）中，我们禁用内部历史记录和趋势的内部管理。 因此，管家不再控制这一点：
接下来你可以做什么？ 您将其关闭，您的图表已趋于平稳...在这种情况下可能会出现哪些进一步的问题？ 有什么可以帮忙的？
分区（分段）
通常，这在我列出的每个关系数据库上以不同的方式配置。 MySQL有自己的技术。 但总的来说，PostgreSQL 10 和 MySQL 非常相似。 当然，在如何实现以及如何影响性能方面存在很多内部差异。 但一般来说，创建新分区往往也会导致某些问题。
根据您的设置（一天创建多少数据），他们通常设置最小值 - 这是 1 天/批次，对于“趋势”，变化的动态 - 1 个月/新批次。 如果您的设置非常大，这可能会改变。
让我们立即说说设置的大小：每秒最多 5 个新值（所谓的 nvps）——这将被视为一个小型“设置”。 平均 – 每秒 5 到 25 个值。 以上所有内容都已经是大型且非常大型的安装，需要非常仔细地配置数据库。
对于非常大的安装，1 天可能不是最佳选择。 我个人见过 MySQL 上每天 40 GB 的分区（可能还有更多）。 这是一个非常大量的数据，可能会导致一些问题。 它需要减少。
为什么需要分区？
我想大家都知道，分区提供的是表分区。 通常，这些是磁盘上的单独文件和跨度请求。 如果它是正常分区的一部分，它会更优化地选择一个分区。
对于Zabbix来说，特别是，它是按范围使用的，按范围，即我们使用时间戳（一个常规数字，自纪元开始以来的时间）。 您指定一天的开始/一天的结束，这就是分区。 因此，如果您请求两天前的数据，则可以更快地从数据库中检索所有内容，因为您只需将一个文件加载到缓存中并返回它（而不是一张大表）。
许多数据库还加速插入（插入到一个子表中）。 我现在只是抽象地说，但这也是可能的。 分区通常会有所帮助。
适用于 NoSQL 的 Elasticsearch
最近，在 3.4 中，我们实现了 NoSQL 解决方案。 添加了在 Elasticsearch 中写入的功能。 您可以写某些类型：您选择 - 写数字或一些符号； 我们有字符串文本，您可以将日志写入Elasticsearch...相应地，Web界面也会访问Elasticsearch。 这在某些情况下效果很好，但目前可以使用。
时间刻度数据库。 超级表
对于 4.4.2，我们关注了 TimescaleDB 这样的一件事。 这是什么？ 这是 PostgreSQL 的扩展，也就是说，它有一个原生的 PostgreSQL 接口。 另外，此扩展允许您更有效地处理时间序列数据并具有自动分区。 它看起来像什么：
这是hypertable——Timescale中有这样一个概念。 这是您创建的超表，它包含块。 如果我没记错的话，块是分区，这些是子表。 真的很有效。
TimescaleDB 和 PostgreSQL
正如 TimescaleDB 制造商所保证的那样，他们使用更正确的算法来处理查询，特别是插入，这使得他们能够随着数据集插入大小的增加而获得大致恒定的性能。 也就是说，在 Postgres 的 200 亿行之后，通常的行开始大幅下降，性能几乎为零，而 Timescale 允许您以任意数量的数据尽可能高效地插入插入内容。
如何安装TimescaleDB？ 这很简单！
它在文档中进行了描述 - 您可以从任何包中安装它...这取决于官方 Postgres 包。 可以手动编译。 碰巧我必须为数据库进行编译。
在 Zabbix 上，我们只需激活扩展即可。 我认为那些在 Postgres 中使用 Extention 的人...您只需激活 Extention，为您正在使用的 Zabbix 数据库创建它即可。
还有最后一步...
时间刻度数据库。 历史表迁移
您需要创建一个超级表。 为此有一个特殊的函数——创建超级表。 其中，第一个参数是该数据库中所需的表（您需要为其创建超表）。
创建的字段，chunk_time_interval（这是chunk（需要使用的分区）的时间间隔。86是一天。
Migrate_data 参数：如果插入为 true，则这会将所有当前数据迁移到预先创建的块中。
我自己使用过 migrate_data - 它需要相当长的时间，具体取决于您的数据库有多大。 我有超过 XNUMX TB 的数据 - 创建它花了一个多小时。 在某些情况下，在测试过程中，我删除了文本（history_text）和字符串（history_str）的历史数据，以免传输它们 - 它们对我来说并不真正有趣。
我们在 db_extention 中进行最后一次更新：我们安装 timescaledb，以便数据库，特别是我们的 Zabbix 知道有 db_extention。 他激活它并使用正确的语法和数据库查询，使用 TimescaleDB 所需的“功能”。
服务器配置
我用了两台服务器。 第一个服务器是一个相当小的虚拟机，有 20 个处理器、16 GB RAM。 我在上面配置了 Postgres 10.8：
操作系统是Debian，文件系统是xfs。 我做了最少的设置来使用这个特定的数据库，减去 Zabbix 本身将使用的设置。 在同一台机器上有 Zabbix 服务器、PostgreSQL 和负载代理。
我使用了 50 个使用 LoadableModule 的活动代理来快速生成不同的结果。 他们是生成字符串、数字等的人。 我用大量数据填充了数据库。 最初，每个主机的配置包含 5 个数据元素，并且大约每个数据元素都包含一个触发器 - 以便这是一个真正的设置。 有时您甚至需要使用多个触发器。
我不仅使用 50 个代理（添加更多），而且还使用动态数据元素并将更新间隔减少到 4 秒，从而调节了更新间隔和负载本身。
性能测试。 PostgreSQL：36 个 NVP
第一次启动，我的第一个设置是在这个硬件上的纯 PostreSQL 10 上（每秒 35 个值）。 一般来说，正如您在屏幕上看到的那样，插入数据只需几分之一秒的时间 - 一切都很好而且很快，SSD 驱动器（200 GB）。 唯一的问题是 20GB 很快就被占满了。
未来这样的图表还会有很多。 这是一个标准的 Zabbix 服务器性能仪表板。
第一张图是每秒的值数量（蓝色，左上），在本例中为 35 个值。 这个（顶部中心）是构建进程的加载，这个（右上角）是内部进程的加载：历史同步器和管家，这里（底部中心）已经运行了相当长一段时间。
该图（底部中心）显示 ValueCache 使用情况 - 触发器的 ValueCache 命中次数（每秒数千个值）。 另一个重要的图是第四个图（左下），它显示了我谈到的HistoryCache的使用，它是插入数据库之前的缓冲区。
性能测试。 PostgreSQL：50 个 NVP
接下来，我在同一硬件上将负载增加到每秒 50 个值。 当管家加载时，通过计算在10-2秒内记录了3个值。 事实上，如下截图所示：
“管家”已经开始干扰工作，但总体而言，历史沉降陷阱者的负荷仍处于 60% 的水平（第三张图，右上）。 当 Housekeeper 运行时，HistoryCache 已经开始主动填充（左下角）。 大约有 20 GB，已满 XNUMX%。
性能测试。 PostgreSQL：80 个 NVP
然后我将其增加到每秒 80 个值：
大约有 400 万个数据元素，280 万个触发器。 正如您所看到的，就历史沉降片的负载而言，插入件（共有 30 个）已经相当高了。 然后我增加了各种参数：历史记录器、缓存......在这个硬件上，历史记录器的负载开始增加到最大值，几乎“上架” - 相应地，历史记录器进入了非常高的负载：
一直以来，我监控所有系统参数（处理器的使用方式、RAM），并发现磁盘利用率达到最大 - 我在该硬件、该虚拟机上实现了该磁盘的最大容量。 “Postgres”开始以如此强度相当积极地转储数据，磁盘不再有时间写入、读取......
我使用另一台已经拥有 48 个处理器和 128 GB RAM 的服务器：
我还“调整”了它 - 安装了历史同步器（60 件）并达到了可接受的性能。 事实上，我们并没有“束手无策”，但这可能是生产力的极限，我们已经有必要对此采取一些措施了。
性能测试。 TimescaleDB：80 个 NVP
我的主要任务是使用 TimescaleDB。 每张图都显示出下降：
这些失败恰恰就是数据迁移。 之后，在Zabbix服务器中，历史沉降器的加载配置文件，如您所见，发生了很大变化。 它允许您插入数据的速度提高近 3 倍，并且使用更少的 HistoryCache - 因此，您将按时交付数据。 同样，每秒 80 个值是一个相当高的速率（当然，对于 Yandex 来说不是）。 总的来说，这是一个相当大的设置，只有一台服务器。
PostgreSQL 性能测试：120 万个 NVP
接下来，我将数据元素数量的值增加到 125 万，并收到每秒 XNUMX 个的计算值：
我得到了这些图表：
原则上，这是一个工作设置，它可以工作相当长的时间。 但由于我只有 1,5 TB 的磁盘，几天后就用完了。 最重要的是，同时在 TimescaleDB 上创建了新分区，而这对于性能来说完全没有被注意到，而 MySQL 就不能这样说。
通常，分区是在晚上创建的，因为这通常会阻止插入和使用表，并可能导致服务降级。 在这种情况下，情况并非如此！ 主要任务是测试TimescaleDB的功能。 结果如下图：每秒120万个值。
社区里也有这样的例子：
该人还打开了 TimescaleDB，并且使用 io.weight 的负载下降到了处理器上； 由于包含了 TimescaleDB，内部流程元素的使用也减少了。 而且，这些都是普通的煎饼盘，也就是普通磁盘（不是SSD）上的普通虚拟机！
对于一些受磁盘性能限制的小型设置，在我看来，TimescaleDB 是一个非常好的解决方案。 它将允许您在迁移到更快的数据库硬件之前继续工作。
我邀请大家参加我们的活动：莫斯科会议、里加峰会。 使用我们的渠道 - Telegram、论坛、IRC。 如果您有任何疑问，请来到我们的办公桌，我们可以讨论一切。
观众提问
观众提出的问题（下文中 - A）： - 如果 TimescaleDB 如此易于配置，并且它提供了如此大的性能提升，那么也许这应该用作使用 Postgres 配置 Zabbix 的最佳实践？ 这个解决方案有什么陷阱和缺点吗？或者毕竟，如果我决定自己制作 Zabbix，我可以轻松地使用 Postgres，立即在那里安装 Timescale，使用它而不用考虑任何问题？
股份公司： – 是的，我想说这是一个很好的建议：立即使用 Postgres 和 TimescaleDB 扩展。 正如我已经说过的，尽管这个“功能”是实验性的，但还是有很多好评。 但实际测试表明，这是一个很棒的解决方案（使用 TimescaleDB），而且我认为它会不断发展！ 我们正在监控此扩展的发展情况，并将根据需要进行更改。
即使在开发过程中，我们也依赖于它们众所周知的“功能”之一：可以以稍微不同的方式处理块。 但后来他们在下一个版本中删除了它，我们不得不停止依赖这段代码。 我建议在许多设置中使用此解决方案。 如果您使用 MySQL...对于一般设置，任何解决方案都可以正常工作。
答： – 在社区的最后一张图表中，有一张带有“管家”的图表：
他继续工作。 Housekeeper 使用 TimescaleDB 做什么？
股份公司： – 现在我不能肯定地说 – 我会查看代码并更详细地告诉你。 它使用 TimescaleDB 查询不是为了删除块，而是以某种方式聚合它们。 我还没有准备好回答这个技术问题。 我们将在今天或明天的展台上了解更多信息。
答： – 我有一个类似的问题 – 关于 Timescale 中删除操作的性能。
A（观众回答）： – 当您从表中删除数据时，如果您通过删除来执行此操作，那么您需要遍历该表 - 删除、清理、标记所有内容以供将来清理。 在 Timescale 中，由于您有块，因此可以删除。 粗略地说，你只需告诉大数据中的文件：“删除！”
Timescale 简单地理解这样的块不再存在。 由于它集成到查询规划器中，因此它使用钩子来捕获 select 或其他操作中的条件，并立即了解该块不再存在 - “我不会再去那里了！” （数据不可用）。 就这样！ 也就是说，表扫描被二进制文件删除取代，所以速度很快。
答： – 我们已经谈到了非 SQL 的主题。 据我了解，Zabbix实际上并不需要修改数据，所有这些都是类似于日志的东西。 是否可以使用无法更改数据的专用数据库，但同时可以更快地保存、累积和分发 - 例如 Clickhouse，类似于 Kafka 的东西？...Kafka 也是日志！ 是否有可能以某种方式整合它们？
股份公司： - 可以卸货。 从 3.4 版本开始，我们有一个特定的“功能”：你可以将所有历史文件、事件、其他所有内容写入文件； 然后使用一些处理程序将其发送到任何其他数据库。 事实上，很多人返工后直接写入数据库。 即时历史沉降器将所有这些写入文件，轮换这些文件等等，您可以将其传输到 Clickhouse。 我不能透露具体计划，但也许会继续对 NoSQL 解决方案（例如 Clickhouse）提供进一步支持。
答： – 总的来说，事实证明你可以完全摆脱postgres？
股份公司： – 当然，Zabbix中最困难的部分是历史表，它产生最多的问题和事件。 在这种情况下，如果您不长期存储事件并将历史记录和趋势存储在其他一些快速存储中，那么一般来说，我认为不会有任何问题。
答： – 例如，如果您切换到 Clickhouse，您能估计一下一切运行速度会快多少吗？
股份公司： – 我还没有测试过。 我认为至少可以很简单地实现相同的数字，因为 Clickhouse 有自己的界面，但我不能肯定地说。 最好测试一下。 这一切都取决于配置：您有多少主机，等等。 插入是一回事，但您还需要检索此数据 - Grafana 或其他东西。
答： – 所以我们正在谈论一场平等的战斗，而不是这些快速数据库的巨大优势？
股份公司： – 我认为当我们整合时，会有更准确的测试。
答： – 原来的 RRD 去哪儿了？ 是什么让您转向 SQL 数据库？ 最初，所有指标都是在 RRD 上收集的。
股份公司： – Zabbix 有 RRD，也许是一个非常古老的版本。 SQL 数据库一直存在——这是一种经典的方法。 经典的方法是 MySQL、PostgreSQL（它们已经存在很长时间了）。 我们几乎从未使用过 SQL 和 RRD 数据库的通用接口。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com