zabbix使用OceanBase作为数据存储的实践和感想

在最初决定探索OB时，对ob都不是很了解，所以决定从监控系统来入手做一些研究，积累经验。监控系统的数据量也比较可观，zabbix server端使用c++编写，前端使用PHP，与我们的业务语言高度一致，是一快很好的试验田。

1. 痛点和尝试ob的原因

zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。公司在最初使用zabbix时，选用mysql来存储数据，随着业务量增加，要监控的设备和指标也越来越多，有如下一些痛点：

1. 数据量在保留半年的情况下依然很大

   使用zabbix的众所周知，zabbix有两张大表history_uint和history，用来存放监控数据。现在的数据增量history_uint约每天33G，history表每天的数据增量约每天50G。

   

   

2. MySQL将来可能存在的数据读写瓶颈。

3. 分区表不易维护，zabbix有几张存监控数据的大表使用了按时间维度来分区的分区表，便于数据清理，查询。

   

4. 我们在使用OB替换mysql上做了一些探索。

相较于MySQL，OB在数据压缩、数据写入上都有很大的优势：

1. OB可以把数据压缩至MySQL的1/5~1/4，在相同规格的机器上，这样可以存放时间更久的监控数据；

   一些线上数据迁移到OB后的大小和压缩率：

   表名	数据行数	迁移前大小(mb)	迁移到OB表大小(mb)	OB压缩率
   tb01	798728403	519445	117162	4.43
   tb02	1080966456	252357	59213	4.26
   tb03	161642614	247981	43918	5.65
   tb04	238384756	137625	33536	4.1
   tb05	104799544	48013	9329	5.15
   tb06	17811054	55933	3257	17.17
   tb07	10779978	8717	3025	2.88
   tb08	28050594	4905	1876	2.61
   tb09	15121626	3125	443	7.06
   tb10	4004670	789	356	2.22
   tb11	1254191	3273	205	15.95
   1b12	909331	521	146	3.57
   平均压缩率		1282684	272466	4.71

   使用oms把zabbix库的数据迁移到OB中，压缩率：

   

2. 在数据写入上边，ob的写入性能是MySQL的三倍以上；

3. OB的online ddl特性使得在分区表的维护上非常平滑，不需要特定维护窗口停监控系统去做分区表的维护。

4. 为正式业务上OB积累经验。

2. 方案制定和环境准备

2.1 方案制定

我们计划先使用4台虚拟机来进行兼容性测试和基础功能验证，机器规划如下：

-- 由于是本人申请的，所以机器名使用了本人的名字命名 -_-!

软件版本选择：

上线思路：

1. 兼容性测试：测试存储与服务的兼容性，功能是否正常。
2. OB集群和相关组件准备：部署ocp、oms，使用ocp快速部署集群。
3. 历史数据迁移：使用oms迁移表结构和全量数据到ob中，同时选择上增量数据同步。
4. 打开维护窗口，服务更换数据库连接地址到OB集群上。
5. 清理同步链路释放服务器资源。

2.2 环境准备

OB、OCP、OMS的部署按照官方文档部署即可，测试环境也并未做太多规范化的配置，在导入表结构后，使用即可，要注意default collation为utf8mb4_bin。

环境准备的过程遇到了一些问题，由于我司的MySQL版本使用的是8.0，在编译好zabbix-server后，发现连接OB时总是连接失败，更换为mysql 5.7版本的环境后编译可以连接上数据库，可能原因是8.0的密码加密方式与5.7不同，这倒也不是什么大问题。

另外还有提示数据库版本的问题，因为obproxy对外显示默认版本是MySQL 5.6.25 ，zabbix会有错误提示版本不支持，所以，需要修改obproxy的mysql_version参数到支持的版本，我们改成了8.0.20。（这个小功能不错，可以根据需求调整到任意版本）

3. 功能测试和遇到的一些问题

测试主要有几个方面：

1. 服务运行状态：检查zabbix-server、UI服务是否能正常启动，长时间运行后的状态检查。

2. 基础功能检查：包括增加监控项、数据采集，数据读取，接口健康检查，报警事件触发等。

3. zabbix版本升级，agent升级等。

4. 数据迁移前后的一致性验证（oms自带数据一致性校验功能，所以只进行了抽样检查）

在zabbix 6.0版本测试过程中，各种功能正常，但是在测试升级过程中遇到了一些问题，主要有如下几个方面：

1. 触发器问题：ob不支持触发器，所有触发器都建在changelog表。（zabbix版本从6.0 升级到6.2）
2. ob不支持把text修改为varchar，在4.0版本之后支持，问题暂时搁置。（zabbix版本从6.0 升级到6.2）
3. changelog表的问题，从代码上看是升级时要写数据，使用触发器，需要再验证。（zabbix版本从6.0 升级到6.2）
4. zabbix添加机器后，重启zabbix server 才能连通的问题，可能与程序有关，同一个程序，在使用mysql时，没有问题。（zabbix 6.2使用过程中的问题，比较致命，重点处理）

后来经过查看zabbix源码和测试，发现以上的问题的根本原因3.1.x版本的OB不支持触发器：zabbix在6.0（LTSC）版本的表结构中，没有使用到触发器，而在6.2版本中，在一些表上边建立了向changelog表插入数据的触发器。

部分触发器截图：

如果可以手动写“外挂”来实现触发器的功能是否可行呢，我们也做了一些测试，在源表数据有变化的时候，把对应的数据插入changelog表后，zabbix对应的功能恢复正常。至于有没有其他隐患，测试时暂未发现。怎样实现源表的变更订阅呢，我们是设想是通过OMS订阅表的变化写入到kafka，然后消费kafka的数据写到changelog里。

在当初测试时，OB还是3.1.4版本，现在OB的4.0版本已经出来了，触发器功能也开放出来了，如果有时间，后面也会有4.0与zabbix的兼容性测试，从经验来看问题不大。

4. 一些感想

3.x版本是OB的一个大版本，在去年六一开源至今也有一年半的时间了。记得OB在开源的时候，我就尝试部署过，过程复杂，成功率低。后来随着OBD出来后，部署非常的方便，屡试不爽。再随着商业产品工具的开放（OCP、OMS、ODC等），OB的开源产品体系也越来越完善，越来越好用。开源社区也越来越壮大，越来越活跃，一些社区用户的使用经验对我们也很有启发。希望OB在将来在开源社区能持续发力，做好知识体系、文档建设，与用户共创一个强大的社区。

5. 附录：

一些线上数据迁移到OB后的大小和压缩率：

可以看到不同的表的压缩效率有很大的差异，压缩率与表结构有关，与承载的业务有关。