“分享升级5.0常见的问题和最佳解决方案，方便大家能够在自己的环境中顺利升级Zabbix。”
——Arturs Lontons，
高级技术支持工程师，Zabbix SIA
本文整理自Arturs 在2020Zabbix中国峰会的演讲，更多演讲视频可关注官方Bilibili账号主页（ID：Zabbix中国）。
01 - 升级准备
首先，在升级之前需要做一些准备，所以我想跟先大家讲一下升级的一些新要求、备份和可能的停机等相关内容。我将分别说明新版本对php和数据库后端的要求更新、备份Zabbix实例以及如何预估需要的停机时间，这些点对于更新而言非常重要，你肯定想要确定大概有多长的时间监控系统不能运行。首先我们来看一下新版本的基本要求更新，正如你所看到的，我们已经对php支持的最低版本进行了更新，之前是5.4，而现在则是7.2。我们不再支持embedTLS，因为它已经被弃用，安全性是我们最为注重的一个方面，而支持不受支持的加密库（特别是不推荐使用的加密库）的潜在风险和潜在成本太大。我们在较新的平台比如RHEL8上添加了对LIBSSH的支持。MySQL也从5.0.3版升级到5.5.62至8.0.x。Oracle支持的版本也有更改，还有PostgreSQL，如果你使用的是Timescale，那么这正是我们的新功能之一，目前我们支持Timescale 1.0或更高版本。我们没有找到关于IBM DB2的可行用例，我们确实有尽力的找，所以在新版本中，IBM DB2支持已被取消，因为这是一个非常小众的数据库后端，尽管我们在测试实验室中使用这一数据库后端，但似乎没有其他人在使用。因此，我们决定放弃这项的维护，让开发团队集中于更有意义的任务。现在我们知道了新的最低要求，让我们在考虑到这些要求的情况下开始做准备吧。
02 - 对所有的OS更新进行检测
首先，我们需要对所有的OS更新进行检测，如果我们有一些占存非常大的OS正在等待更新，那么我们就需要决定是否对它们执行更新，我们需要做一些规划：我们需要做这件事吗？会导致多久的停机时间？我们需要这样做吗？如果确实需要对它们进行更新的话，那么什么时候最为合适？如果我们决定更新，那么就让我们来执行。在完成OS更新之后，需要记住的是，在进行下一步之前，我们需要在环境中运行几天的时间，以便于对任何新出现的潜在问题进行详细的盘查，因此，这里我们的基本思路是，一次只更新一部分，首先执行OS更新，然后扫描问题，然后检查数据库后端，必要时执行数据库后端更新，然后查找和排除可能发生的任何问题、错误和性能故障，这样我们可以根除这些潜在的问题，然后一旦所有这些都完成了，我们就已经准备好了基础架构，准备好了运行环境，然后我们就可以继续进行Zabbix本身的升级了。否则，如果我们同时进行所有的更新，那么在出现问题时，我们就真的很难找出问题的根源。就无法确定问题是不是来自Zabbix？还是来自OS？还是来自数据库？因为我们在很短的时间里做了太多改动，这就是为什么需要一步一步来更新的原因。
03 - 为备份工作做好准备
接下来，为备份工作做好准备，这是在将Zabbix升级到5.0之前需要进行的一项大型工作。首先，确认下Zabbix监控实例中是否使用到了任何自定义解决方案。如果是，请备份，当然还要进行测试。这个非常重要。如果这些是专门为现有的旧版本定制的解决方案，那么就需要在新版本上首先进行测试，然后才能将其用于生产环境中。例如你采用的可能是某个社区开发的模板，它使用自定义脚本或一些前端修改、数据库修改，虽然不是必然，但是在升级的过程中这些自定义很可能会导致一些问题。例如，如果你正在使用分区，要从版本等于或早于3.0的版本升级到5.0，则在继续升级之前必须关闭这些分区。不过，对于较新的版本而言并不是一个问题，因为历史表在升级过程中不会受到干扰。但是对于旧版本，我们需要在升级时禁用该分区，然后重新创建。就像我说的，自定义模块和补丁，你是否有在使用？如果是，那么就需要首先对其兼容性进行测试，然后进行备份。另外一件事情，非常非常简单，也非常基础，但是大家总是忘记。我们的软件包也可以在底层操作系统上运行。系统策略会允许下载这些软件包吗？网络团队允许你下载吗？安全团队允许下载吗？如果不允许，那么我能否从源代码编译Zabbix或Zabbix软件包将取决于这些前提条件，不同的情况下需要以不同的方式进行升级。如果你可以直接安装新的软件包，那就可以继续。如果不可以，那么必须选择其他的办法，例如从源代码编译。这些都准备完成之后，就可以考虑对基础架构进行备份。除此之外，我们还需要执行数据库、后端、前端文件和备份，就像我说的那样，不要忘记对你的自定义设置、自定义脚本（例如自定义配置文件、模块等）进行备份。而且不仅要备份自定义配置文件，还要对常规配置文件进行备份，如果有些内容损坏了，只要有备份，我们可以完整的恢复过来。在屏幕上是一些关于如何备份Zabbix配置的示例。可以看到，我们正在执行外部脚本、Zabbix config目录、Apache配置目录（用于使用Apache）、我们的Web前端本身和doc目录（可以包含基础架构和其他一些内容）的副本。
然后，我们就需要执行非常重要的一步，那就是对环境配置进行备份。用户需要明白的是，备份配置的重要性在很多时候都要大于历史记录的备份。因为如果我们丢失了所有的配置文件，那么我们就会遇到非常非常棘手的麻烦。历史数据通常会自己备份，可能是通过分区进行备份，或者如果可以做到，我们可以单独备份历史数据，但配置可能是我们多年以来一直都在做的、修改和调整的。因此，我们肯定不想丢失配置。所以在这里我们有MySQL dump命令可用，这一命令会忽略我们的历史和趋势表。并能够将其余内容转储到存档之中，然后你就可以对其进行备份。
04 - 如何估计停机时间
那么我们如何估计停机时间呢？这非常重要，你的管理层会经常问你，这需要多长时间？一个小时？一天？还是更长时间？所以我们可以做一个非常粗略的估计，通过执行查询，在这里查询table_schema表，其中有几个参数可以给我们提供数据库的大小。这可以为我们提供一个粗略的估计，几GB？几百GB？还是超过1TB？通过这一信息，我们就可以估计出这个过程需要多长时间，是几个小时，还是几天还是更长。然后，在更细粒度的级别上，我们还可以查看数据库表。这里有一个select语句，可以显示前20个表。在此基础上，了解不同版本之间的变化，通过查看“版本说明”，我们可以确定哪些表将进行升级。正如我们所看到的，我现在的屏幕上有一个配置表，非常简单明了。可以看出，alerts是最上面的配置表，items甚至不是真正的配置表，只是包含alerts，但我选择了除事件历史趋势之外的所有内容，所以alerts也会显示出来，但这个表占用存储空间也很小，只有1.64GB。items配置表大小为1.46GB，triggers配置表的大小也仅仅为0.4GB，真的很小。另一方面，在同一实例上，让我们来看一下历史事件和趋势，你可以看到历史表的大小为220GB，所以history表比alerts表大100多倍，events是156，trends是126，这是一个很小的示例。小型到中型实例，对于较大的实例，这些表就是变得很大（非常大）。因此，查看这些表的大小可以帮助我们估计停机时间，特别是从旧版本升级时，例如历史表和事件表要升级。我们如何清理其中的一些呢？例如，对于事件，我们需要查看housekeeping设置，我经常看到客户、社区成员、我的朋友，甚至是同事会使用非常长的数据存储期，例如，存储触发数据的数据存储期为一年，存储内部数据的数据存储期一年。而大多数时候并不需要如此长的储存期，那么我们需要怎么做呢？我们可以将事件存储期设置为一天，然后从命令行手动执行housekeeper进程，你的屏幕上会显示该命令，你可以看到所有旧事件正在被删除，表正在清理，完成此操作后备份的速度会快得多。也许我们在这里删除了好几GB的数据。升级时的停机时间时也会减少很多。
还有另一种方式，有时我们会这样做，但对于一般的客户或社区成员，或朋友们，如果你不知道自己在做什么，我不建议这样做。这里有一个循环，可以手动清理事件表，如果housekeeper不够用，或者有一些限制，我们可以使用我现在屏幕上的这个循环，50次迭代，在每次迭代中删除大约100000个项。根据你所需的性能，你可以增加或减少该限制。所以，就像我说的，这是一种变通办法，如果housekeeper不够用，比如在非常大的情况下。但是要小心，你要知道你在做什么。我们在支持团队中，在出现问题之前，我们可以互相咨询，我们不会破坏一个实例。但在实际环境中，你必须小心，当然理想情况下，首先要在测试环境中执行此操作。另外一种情况下，如果连这个for loop循环都不够用，我会怎么做呢？我将源为0的事件触发，复制到新表中。因此，新的事件表仅包含源为0的事件，这里的问题是你必须删除并重新创建所有约束，引用其他表上的事件。由于只是复制并重命名时间表，因此创建新的表事件（如Events），然后给它重命名，不能满足引用的要求，约束仍然停留在包含所有旧事件的旧表上。所以我们需要在新表上重新创建约束，这里有一些示例查询，我是如何重新创建它们的一些示例语句。请注意，事件表没有任何更改，如果你是从4.0升级到5.0，那么根本不需要担心这一点。还有一个相当普遍的做法，就是创建临时历史表。本质上是创建空的历史表，对这些空表执行升级，它们的pattern会稍有改变。然后重新插入旧数据。这样，你可以尽快启动并运行Zabbix实例。空表上的升级将比满表上的升级快得多，特别是因为pattern有一点变化。同样，如果你要从4.0升级到5.0，表结构不会改变，因此你不必担心这一点，你的历史表将完全不受影响。
接下来，让我们来看看这些逐步升级的示例。这里有两个用例，首先是配置有Zabbix 3.0 server的CentOS 7，前端以及三个proxies，其中一个proxies使用的是Amazon Linux AMI OS，这可能会出现比较大的问题，正如我们看到的那样，Zabbix server所使用的是MariaDB10.2作为后台数据库，而proxy使用MariaDB5.5和SQLite的组合。所以，我们这里该怎么做？首先需要创建临时历史表，安装更新包，清理存储库缓存，执行升级，并对命令进行检查，完成，希望成功。我们可以看到这一提示，是的，从数据包的角度来看，这是一个相当简单的实例，我们可以在线下载软件包，再安装，我们不需要从源代码编译任何东西，一切都非常简单和顺利。然后安装Zabbix 5.0存储库和CentOS SCL repo，这是基于我们使用的CentOS 7的操作系统的要求。让我提醒你，在这一用例下，我们是在CentOS 7上执行运行，并从3.0升级到5.0。这就是为什么我们需要SCL repo，添加，然后安装，启用，除此之外，我们还需要在我们的Zabbix用户配置中启用前端存储库。然后，使用Apache配置重新安装前端，我们需要专门重新安装它，因为这里我们在使用一些新的软件包，所以我们需要删除旧的前端并安装新的前端。安装Zabbix web，MySQL，这就是MySQL前端，支持你MySQL查询的前端，MySQL数据库后端，我们正在从SCL存储库中安装Apache配置。然后，更改默认的php配置，内存限制是你可能希望在较大实例上更改的内容。你可以根据实例所在的位置更改日期和时区，在我的情况下，是“Europe/Riga”。然后我导入回旧的历史数据，所以我使用带有空历史表的临时表进行了升级，我是从3.0升级的。然后，我将数据从旧的表导回到新的表中，好的一点是，这步可以在服务器运行的同时完成，这个非常好！因为它还在收集新的数据，而整个数据都很重要。所以在这种情况下没有发生停机。在升级过程中有短暂的停机时间，但数据导入阶段没有停机时间。
05 - 继续升级proxy
然后继续升级proxies，在这里，我们使用两种不同的方法。其中第一个非常顺利，升级proxies，添加存储库，yum clean all, 升级proxies，使用MariaDB，一切都很顺利。proxies启动一切都很好，很简单。我们甚至有一些使用SQLite3的proxy，这个可能就没有那么简单，因为我们必须删除单个文件，虽然这有点耗时，但仍然不算复杂。我们删除SQLite的数据库文件，重新启动proxies，一切都正常。然后我们使用另一种方法，发生了什么，这种单一用例为什么如此独特可以被分成两部分。如果有Proxy会怎么样,在本例中运行的是Amazon Linux AMI，使用CentOS 6软件包，在这种情况下，我们没有事先检查是否有适用于CentOS 6的软件包。在CentOS 6上没有5.0的server或proxy软件包可用，那么我们此时能做什么？这里我们需要停下来，喝杯咖啡或茶或别的什么，然后我们决定如何继续，我们是否需要从源代码编译proxy？在这种情况下，我们将来升级时，比如升级到5.2或6.0时，我们将需要重新编译这个proxy，从头开始，取决于你是否能接受这个，或者你的管理员或者其他执行人员是否同意。也许更好的做法是为整个环境做好未来的准备，并创建一个新的虚拟机，使用最新的操作系统。我们现在和将来都可以从包中安装proxy，所以这实际上就是我们所做的。在实际环境中，这是一个真实的用例。这里，我们决定启用一个带有CentOS 8的新虚拟机，并安装软件包中的所有内容，实际上速度相当快。我认为这比录制整个编译过程、将来校对、提供客户的文档都要快得多。客户熟悉从软件包开始的升级，从软件包开始安装，所以这是最好的解决方案。你得做个决定。
接下来，安装agent，要么是C agent，要么是GO agent，记住新的版本中已经有GO agent了，还提供很多新的插件可以使用，真的很不错。再次由你来决定，是否要执行升级，然后你需要在C agent 和GO agent 之间做出选择，但是由于它们可以后端可兼容，因此如果你非常疲惫，也可以推迟决定这个选择，比如目前你已经升级了三个proxies，其中一个运行在不受支持的操作系统上，你可以稍后、明天、一个月后确认，视情况而定，或者如果你现在需要新功能，那么你现在就可以执行此操作。
06 - 升级之后要做的事
检查错误消息和日志
好的，我们已经进行了升级，确实有点费力。现在让我们来谈谈升级后要做的一些事情。我们可以充分利用5.0的潜力，升级之后，我们就可以利用一些优化的点，我们得到了视觉上更让人舒服的UI，我们拥有了新的功能集，但我们也需要应用这些优势，不是吗？我们需要验证我们的实例完整性，升级后一切都在运行，并使用最新和最好的功能和要求，我们需要检查其性能，也许还需要对其进行进一步的优化，现在我们有了执行此操作的工具，还可以启用一些新功能。
当然，升级之后，你要做的第一件事就是在当天，或者当天晚上检查错误消息和日志。如果你在升级过程中遇到一些错误消息，你需要及时修复这些问题，特别是如果你自定义了一些数据库表，或者添加了一些额外的索引，或者执行了类似的操作，则需要对这些充分进行删除。将数据库恢复到其原始状态，然后继续进行升级。然后，你需要注意到的另一件事是，你将收到一条错误消息或更多关于排序规则的警告。因此你可以参考这个ZBX-17357，它将包含更改数据库排序规则和列排序规则的查询，然后你可以执行并修复这些问题。但是，需要说明的是，对你来说这不一定是一个关键的问题，也许这个问题在你这里已经存在了好几年。但需要记住的是，在我们所有的培训中，在我们与客户和所有论坛沟通中，在与你们的面对面交流中，我们一直强调排序规则是一个十分重要的环节。它确保你的实体和元素对大小写敏感。Zabbix支持大小写敏感元素。例如，你有一个全小写的主机abc和全大写的主机ABC，Zabbix应该能够区分这两个主机，这就是正确排序规则真正的意义所在。
使用补丁进行升级Float64
接下来，我们还启用了Float64支持，目前是通过自定义补丁实现。可以通过链接获得。只需打开它，如果你需要Float64值更高的未来校样，请使用补丁进行升级。你可以继续使用Float64的值，如果你不需要，现在你想稍后升级，就像我说的，你现在很累，你可以后面再做。
查看前端
好，接下来我们来看一下我们的前端。如果我们有错误的排序规则或错误的字符集，我们的前端也会给我们一条警告消息。所以我们需要修复。这里我再次提供了ZBX-17357链接和ZBXNEXT-5691链接，是和排序规则、Float64有关的告警信息。因此，你不仅可以在日志文件中看到，还可以在系统信息部分的前端中看到它。
对脚本和自定义媒体类型的集成执行测试
接下来，对你的脚本和自定义媒体类型的集成执行测试。如果它们正常工作，并且你可以获得预期的数据，那么很好，我们可以继续。注意小的测试按钮，可以直接点击来测试的，对吧。接下来，确保你基于脚本的监控项在正常接收数据。现在这里也有测试按钮，你也可以使用，来测试你是否获得了正确的值。如果没问题的话，很好，我们就可以继续了。如果有问题，修复脚本，然后继续。当然，在升级之后，请验证性能和配置，确认在升级了proxies之后队列没有大幅的增加。因为proxies需要升级到与后端相同的主要版本。然后我们可以继续了。
确认Zabbix server和proxy的性能图表
接下来，确认一下Zabbix server和proxy的性能图表，如果有任何大的变动，我们需要找出问题所在。还要看看Zabbix server或proxy的日志文件中比较慢的查询队列，如果有比较慢的队列，我们需要找出这些性能问题来自哪里。是不是数据库出现了问题？还是Zabbix server性能出现问题？我们需要找出是什么原因造成的，并修复。
优化数据采集逻辑
接下来，我们可以通过使用新功能、新预处理规则来优化数据采集逻辑。例如，节流对于优化非常有用，既然你已经升级到5.0，那么就可以使用这些新功能，使用节流，丢弃不必要的数据。我们还可以使用预处理的数据验证规则来验证和获取数据，并检查它是否遵守我们的数据收集规则。修改现有监控项以使用新功能而不是DSN。也许你现在想要使用ODBC连接字符串，因为它在新版本里是完全受支持的。仔细检查你的API脚本，我们做了一些更新，进行了改进，例如，SNMP接口类型现在需要details属性，这可能会破坏你的遗留主机创建的脚本。你需要遵守这条规则，所以你需要稍微更改一下API脚本，添加以前可能缺少details属性，因为这个之前不是必需的。
从脚本切换到WEBHOOKS，这是4.2中增加的一个很大的功能，用WEBHOOK来集成，而不是使用你自己编写的脚本，你可能花了几个小时来编写，现在还要花时间维护，必须维护。切换到官方支持的WEBHOOK吧，我们现在提供WEBHOOK，可以用于集成，我们会维护，我们会更新、改进。这会让你的工作轻松很多。既然你已经升级到5.0，你完全可以使用这个。使用升级了的安全功能，数据库和后端之间的加密通信，前端和数据库之间的加密通信，你还可以对其进一步加密，屏蔽宏，是的，如果你现在将密码存储在宏中，你现在可以屏蔽。所以没有人能够看到你输入的内容。迁移到开箱即用的单点登录支持，不需要在web部件、web组件上使用，你可以在Zabbix中本地使用这个功能了。
我的演讲接近尾声，通过演讲带着大家过一下升级时准备阶段、升级阶段和升级后阶段需要做的工作。希望我的演讲给了你们一些启示和帮助，祝大家顺利升级到5.0，谢谢！
