我们目前正在运行 Zabbix 3.0 LTS，其 PostgreSQL 数据库版本为 9.5.6，运行在 Ubuntu 16.04 上。我们遇到了一个问题，我们的 Zabbix 数据库不断增长。我们不太确定是什么原因导致了这个问题，但到目前为止，我们已经为 Zabbix 分配了 400GB，而且它已经快要超过这个数字了。我们启用了内部管理功能，并将其设置为保留 30 天的数据。我们的环境也有 550 台主机，Zabbix 中有大约 65,000 个项目，间隔为 60 秒。我们的项目数量非常高，因为我们的环境主要是 Windows。
以下是我们的 Zabbix 环境的一些屏幕截图
这是我们的 Housekeeping 参数的图片
我不确定是什么导致了增长，但它每周都在以大约 40GB 的速度增长，这似乎太疯狂了。如果这不能解决任何问题，我不想继续给它更多的存储空间。有人知道问题是什么吗？或者有人在 PostgreSQL 后端上运行 Zabbix 时遇到过类似的问题吗？我发现唯一可能的解决方案是对数据库进行分区，但在走这条路之前我想先检查一下。
任何想法或反馈都将非常感谢！
编辑
添加我们的 Zabbix 内部进程的图表，显示管家以 100% 的速度运行。管家设置为每小时运行一次，最大删除数量为 40,000。我们最大的表似乎是 History，占用 175GB 和 History_uint，占用 100GB。如果我在 zabbix 服务器日志中搜索“housekeeper”或“housekeeping”，我实际上看不到任何东西，这让我相信它实际上并没有删除任何东西
答案1
在没有看到大表的统计数据的情况下（特别是它们是否被自动清理有效地清理），我的主要建议是限制保留的历史记录量（特别是进入历史记录*表的内容，而不是趋势*表的内容）。
一般来说，Zabbix 通过将历史（详细观察）转化为趋势（汇总观察）来管理收集的数据量；这个想法是，您将历史保留一小段时间，在此期间查看每分钟的精确数据可能很有意义，但对于长期研究，汇总数据就足够了。此外，这意味着历史表（忙于添加数据）也较小，趋势表可以较大，但写入活动较少。
听起来你做的正好相反，不保留趋势数据，而是保留所有历史记录？这是有原因的，还是偶然的？
除此之外，这在稍后会变得相关：分区是一种工具，它不会解决您的眼前问题，但在处理像这样的非常大的数据集时，它会成为您的朋友。也就是说，分区（大多数情况下）需要历史和趋势保留方面的纪律，您必须将所有项目保留相似的时间长度，这样您就可以在它们老化时删除它们相关的分区。回到主要答案...
我所做的就是查看不同的项目并决定如何使用它们，并只在真正需要时保留历史记录，并尽可能长时间保留趋势（如果有的话）。例如，我进行了很多健全性检查，如果出现问题，它们会发出警报，但通常项目返回 0、“OK”或类似的结果。保留这些项目超过几天是毫无意义的。不过，这种针对特定项目的保留与分区不一致，因此您可以自行决定。
更相关的是轮询的内容和频率。我通过积极过滤掉没人关注的内容，将项目数量减少了大约 10 倍。最大的一个是接口 - 一些具有一个物理接口的设备可能具有 6 个或 10 个虚拟接口；当然（有人会说）它们有意义，但有人真的在查看从它们收集的数据吗？子接口、环回接口、（一些）虚拟接口等。网络管理员经常想“我会保留一切以防万一”，但这很少有用 - 深入研究项目数据，看看你在哪里有大量你永远不需要知道的接口。或者最坏的情况是，你可能不得不重新开始监控。从低级发现开始打击他们。
当您在那里时，看看您正在为接口收集什么。同样的想法；人们经常收集 SNMP 显示的所有内容，因为他们可以这样做。假设您正在为每个数据项付费，并问自己如果您按项目付费，是否值得保留它。（从某种意义上说，数据存储方面，您是值得的）。如果您已经做了几年的监控，问问自己是否曾经需要对片段故障进行计数（听起来像一个真实有用的项目的简单示例，对某些人来说可能确实如此）。如果您说出现了 5 个，您会怎么做？如果它不可行，为什么要保留它？如果它是您在实时中被动查看的那种东西，为什么要从历史上保留它？
当你在那里时，问问自己为什么对某些项目进行如此快速的轮询。考虑数据包/字节数问题 - 当然，每 60 秒观看一次实时历史图是很不错的，但它可以付诸行动吗？它是否每 180 秒教你不止一个？每 300 秒？你可能正在非常快速地收集大量这样的数据 - 你会使用它们吗？我曾听网络管理员说过“但我需要对问题做出快速反应”。然后你会发现他们加入了延迟和滞后，以避免误报和抖动。
减少收集的内容和频率，您的历史记录将缩小 10 倍（+/-），而不会显著影响其效用。然后减少您保存详细信息的时间（相对于趋势），它可以再减少 2 倍或 4 倍。
答案很长，很散漫，但基本上是：如果它不可行，就不要保留它。如果你猜错了，你随时可以把它放回去。
最后：确保自动清理工作有效，考虑将内部管理的删除最大值设置为 0（一次删除所有内容），但之后要仔细监控是否有阻塞（在具有足够内存/进程/磁盘速度的大型系统上，这可以显著加快内部管理速度，但如果试图一次执行太多操作，也会有阻塞的风险）。
好吧，最后说一句：如果你决定按照建议做，删除很多项目，那么考虑一下是否可以重新开始处理数据。清理数百 GB 的数据将是一个巨大的挑战。