视频地址弄好了,我下面怎么做?(视频地址怎么弄的出来)
747
2022-05-29
“分享升级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,谢谢!
“分享升级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,谢谢!
Zabbix 运维
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。