运维开发网

通过修改源码突破zabbix单server监控数量

运维开发网 https://www.qedev.com 2021-04-07 20:54 出处:51CTO 作者:AIOPS_DBA
最近业务的快速增长,zabbix监控的VPS(Required server performance, new values per second)早已超过六位数,这也许是达到他的单server最大吞吐量。而zabbix server的CPU负载、内存使用率、网络IO、磁盘IO、MySQL的QPS等关键性能指标都不高(主要是server服务器的配置较高:64c/128G内存/SSD硬盘),这也许是

最近业务的快速增长,zabbix监控的VPS(Required server performance, new values per second)早已超过六位数,这也许是达到他的单server最大吞吐量。而zabbix server的CPU负载、内存使用率、网络IO、磁盘IO、MySQL的QPS等关键性能指标都不高(主要是server服务器的配置较高:64c/128G内存/SSD硬盘),这也许是达到他的单server最大吞吐量。架构为单server、单MySQL数据库、多代理的模式,出现几个代理数据队列延迟,报警异常的情况,此时只能清空代理节点的数据来临时解决。

通过观察zabbix server自身的性能指标,发现有几个指标在出现队列延迟时特别高:Zabbix busy history syncer processes达到100%,非常繁忙,(用于同步代理数据到server端,进而刷数据进数据库),Zabbix history write cache free、Zabbix value cache free基本为0,而查看zabbix server的配置文件看到已经设置为最大值。因为服务器的负载比较低,而zabbix server的负载比较低,显而易见服务器资源没有得到很好的利用。如果能通过源码修改这几个参数的上限,也许就可以给zabbix server的拆分争取到一定的时间。通过搜索这几个配置参数,在源码src/zabbix_server/server.c(server的配置参数最大值和最小值都在这里)找到了这几个参数的最大值,调整最大值,重新编译,启动,通过几天的观察,之前的现象消失,MySQL的QPS也上升不少(近30%)。

另外还有一个参数,当监控项和主机数量增多时,压力也比较大,Zabbix busy configuration syncer processes, in %(用于server同步监控源数据到代理)这个指标在源码中设置为1个进程,通过测试,这个值不能进行修改,否则多个线程同时查询数据库库,同样的SQL执行多次,效率反而更低,建议官方优化这个进程的同步流程,一次查出,多进程同步源数据,从而提升同步配置源数据性能。

建议官方适当放大这几个缓存值设置的最大值,这样能合理的利用服务器资源,提升zabbix server的最大吞吐量。同时建议官方出一个多server统一管理的UI,方便运维。作为运维,这种单server的架构比较省事,但是业务增长到一定数量的时候必须进行server拆分,统一管理监控数据等二次开发,确保监控服务的稳定运行。根据经验,通过数据库、硬件、server配置参数的优化,单server监控的VPS不建议超过5万,否则对运维的考验特别大。

另外服务器不好,监控业务量不大的,就不需要用这个方法修改了,没有意义。

src/zabbix_server/server.c 

StartDBSyncers-->100-->1000

CacheSize-->8--->64   #单位是G

HistoryCacheSize-->2-->64 #单位是G

HistoryIndexCacheSize-->2-->64 #单位是G

TrendCacheSize-->2-->64 #单位是G

通过修改源码突破zabbix单server监控数量

0

精彩评论

暂无评论...
验证码 换一张
取 消