谈几个遇到的问题：
1.首先，为了了解zabbix的性能情况，增加了zabbix相关的metric监控
（具体见：http://1662935.blog.51cto.com/1652935/1345664）
2.监控添加问题，开发了添加监控的前端页面，使用zabbix api的方式来一键添加监控，完成链接模板，分配分组的操作。其中主机到模板的链接通过主机名的方式进行匹配，缺乏可维护性，因为现在cmdb不可用，和同事讨论下来，准备自己在数据库里面维护一套信息（host--process,process--template），每天动态更新。
3.在一个proxy添加了200台机器后，开始遇到了断图的问题
比如下面这个：
通过分析zabbix server 数据库中history的数据，发现有数据丢失的情况，interval 为60s，1小时应该有60条数据，但是在数据库中只有十几条，进而分析proxy 数据库中的items表，delay设置是没有问题的，排除config sync的问题，分析agent端的日志，发现在agent端就存在数据获取不完整的问题（agent使用了passive的模式），也就是说proxy busy造成了获取数据不完整，调整StartPollers后解决，这个值默认是5，在passive agent的模式下，远远不够用，建议改成hosts*1.5的值。
4.unreachable 问题
1）接入机器后，出现大批的host unreachable的报警（agent.ping item）,但是主机是可以通的，通过部署网络监测脚本，排除agent---proxy---master 3者间的网络连通问题。通过增大 StartPollersUnreachable和UnreachablePeriod解决。
2）报警问题，zabbix在ok--->unknown状态时不会产生报警，因此unreachable的报警不能发现host item获取值的问题，可通过增加host update percent监控实现（具体见：http://1662935.blog.51cto.com/1652935/1345789）。
5.集群整体update percent很低
通过breakdown到host，发现部分host update percent导致（几台机器agent有问题，值状态为unknown）修复后，整体的update percent升高到98%左右。
6.proxy服务器load问题
一个proxy接入350台左右的集群，nvps200左右，但是load比较高，因为agent是passive的模式，数据获取都是proxy负责的，因此如果item比较多，proxy的压力就会比较大。考虑转换agent的模式为active，将压力分散到agent端，proxy只负责数据sync和config sync，调整后，proxy压力减小了很多，具体见下图（没数据的地方是item没有调整为active导致）
同时解决了queue过多的问题，调整后，基本没有超过5分钟的delay了。
7.housekeeper的问题
master端和proxy端都存在这个问题（proxy不能disable housekeeper）,master端可以通过disable 并partition db解决，因为需要停机维护，暂时还没做调整。
通过上面的调整，zabbix基本没什么压力了（单proxy 350台），扩展性也不错，后面需要做benchmark test,看看能跑到多少nvps.
小结：做zabbix的性能调优之前，要做好zabbix性能的监控，调整中要考虑把压力分散，master分散至proxy,proxy分散至agent。
对zabbix的工作机制和各种process的作用要了解，对zabbix的数据库表结构也要有比较好的理解。
本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/1346372，如需转载请自行联系原作者