zabbix调优

yao000

　　网上搜了半天zabbix调优，最后结果都是一样的复制粘贴，主要都是1.8的，在这个2.0的时代，很让人难受。
　　在13年年末，zabbix推出了性能提升一倍的2.2版本。本屌将线上zabbix数据库的备份导出在测试环境升级到2.2，在升级数据库这个环节，耗时近一周，因此本屌现在线上用的还是2.0

　　zabbix2.0哥们是去年7月份开始正式使用的，在这小半年的时间里，history和history_uint两张表加起来存了50亿条数据，这不得不让我对zabbix的性能表示五体投地的佩服。

　　说道调优，就得说说现在运行的状态：哥们部署的这套环境目前监控着1000多台机器，3w个活跃的监控项，每秒采集800个数据（这个值最高到过900+），用了三台服务器（一台server，一对mysql主从库）目前运行良好。

　　在这我仅将本屌这微不足道的经验陈列下，喷子们请见谅，恕小弟无知，谢谢。

　　

　　我认为优化zabbix其实就是优化这几部分：架构、模板、server配置、数据库、用新版本
　　架构：用分布式。
　　虽然本屌还没正式在线上用proxy，但我还是心仪已久，没啥经验，只是感觉和大牛们都这么认为，所以我也潜意识的这么想，分布式应该比cs性能强。
　　模板：一定要自定义监控项，尽量减少没用的以及设置合理的监控周期。
　　监控项我想说，第一点用不到或者功能重复的一定要去掉，最好是自己定制自己的模板，在定制过程中，削减监控项的个数是一点，第二点是一定要根据自己的实际情况，配置监控周期，我这点就没做好，现在都是30s采集一次，其实对于很多监控项而言，这么频繁没必要；第三点就是收集数据以及展示数据的方法，我就一个想法（能用zabbix自带的就别用自定义的）其他的官方总结的很到位，我就引用下：
因素
慢快数据库大小特别大适应内存大小触发器表达式复杂程度
min(),max(),avg()last(),nodata()数据收集方法
Polling(SNMP,No Proxy,被动式Agent)Trapping(主动式Agent)存储数据类型
文本，字符串
数字　　服务器端配置：就像其他帖子说的，优化进程数，角色分离等等。
　　我的前端是tengine+php，这里的优化工作我认为不是主要的，webserver用在zabbix上，基本没有瓶颈，可以在网上搜搜，做些简单的优化就行了。
　　重头戏在zabbixserver的配置上，默认的，server起的进程非常少，而且事实证明，数据级到了亿这个级别的时候，hoursekeeper的作用可以忽略不急了，所以我炒了他。我贴下我的配置吧：

LogFile=/tmp/zabbix_server_2.0.log
PidFile=/tmp/zabbix_server_2.0.pid
DBHost=*******
DBName=*******
DBUser=******
DBPassword=******
DBPort=3306
ListenPort=10051
SNMPTrapperFile=/tmp/zabbix_traps_2.0.tmp
StartPollers=256
StartProxyPollers=4
StartDBSyncers=8
StartHTTPPollers=8
StartPingers=8
StartTrappers=64
StartPollersUnreachable=64
StartDiscoverers=32
HistoryCacheSize=128M
CacheSize=1024M
TrendCacheSize=32M
#MaxHousekeeperDelete=10000
DisableHousekeeping=1
UnreachableDelay=60
UnavailableDelay=60
UnreachablePeriod=60
TrapperTimeout=300
Timeout=10　　这是一台8g内存的机器的配置，server对内存和cpu的要求还是挺高的，这个之前没有规划好，建议用16g以上的机器。
　　数据库：我只用过mysql，所以这我就说mysql。
数据库：
　　    mysql配置调优可以参考http://shanks.blog.运维网.com/3899909/1307636
　　

　　我要说的重点是mysql的分区表，多了不说，直接上操作：
　　在create分区表时，需要对所有数据都做好分区，否则会报错，也就是说你要保证这条create的时候，该表内所有数据都能找到各自的分区。建分区的时候，实际上就是把数据导出再导入，因此这期间，该表是只读的。

　　在2.0中，history、history_str、history_uint、trends、trends_uint、events这几张表大家应该比较熟悉，大量的历史数据都存在这几张表中，我们现在就对这几张表做分区：
　　1、分别create
　　以history为例：
CREATE TABLE `history` (`itemid` bigint(20) unsigned NOT NULL,`clock` int(11) NOT NULL DEFAULT '0',`value` double(16,4) NOT NULL DEFAULT '0.0000',`ns` int(11) NOT NULL DEFAULT '0',KEY `history_1` (`itemid`,`clock`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by range (clock) (partition p201307 values less than (unix_timestamp("2013-07-01 00:00:00")),partition p201308 values less than (unix_timestamp("2013-08-01 00:00:00")));　　1.1 alter已有的表
alter table history_uint partition by RANGE (clock) (partition p201306 values less than (unix_timestamp("2013-07-01")),partition p201307 values less than (unix_timestamp("2013-08-01")),partition p201308 values less than (unix_timestamp("2013-09-01")));　　2、发现分区已经超时了，需要添加
　　以history为例：
alter table history add partition (partition p201309 values less than (unix_timestamp("2013-10-01 00:00:00")));　　这么做之后，你会发现当你查看近一个月的数据的时候，数据出来的比较快，同时有可能之前的图像断点问题也解决了。然后写脚本定期的去删除分区，同样可以做到删除垃圾数据的效果。