zabbix：性能优化

zabbix性能低下的表现如下：

zabbix队列有太多被延迟的item，可以通过administration-queue查看
zabbix绘图中经常出现断图，一些item没有数据
带有nodata()函数的触发器出现flase
前端页面无响应，或者响应慢

解决方案如下：

不要使用默认的模板，使用自己定制的模板
数据库调优
架构优化，如使用分布式，个服务器功能独立
Item 、Trigger调优
变换更好的硬件

一：性能优化的依据

对zabbix server本身进行监控，选择zabbix-server的监控模板Template APP Zabbix Server。
然后看到zabbix-server内部监控情况：
在这里插入图片描述
通过上面的图，我们可以发现监控的指标有剩余的容量、性能这些。通过这些我们可以知道zabbix性能的瓶颈在哪里。例如：如果剩余的容量很小了，我们就可以调大zabbix_server.conf中的缓存参数，直到剩余的容量变大。

二：zabbix配置文件的参数优化

下面就是zabbix_server.conf文件内容

#通过日志可以分析当前服务状态。
LogFile=/tmp/zabbix_server.log	#日志文件路径。
LogFileSize=1	#日志文件最大值(MB),超过则滚动,设为0表示不回滚。
DebugLevel=3	#调试日志级别：
#	0 - Zabbix进程启停基本信息。
#	1 - 严重信息。
#	2 - 错误信息。
#	3 - 警告。
#	4 - 调试模式。
#	5 - 调试模式-加强版。

#数据库配置，若数据库与服务器在同一机器上，使用socket模式可以提高访问速度。
DBSocket=/tmp/mysql.sock

#轮询进程数，通过并发来提高轮询或者捕获的效率，同时用来避免poller busy问题，根据CPU数量与系统负载综合调优。
StartPollers=80	#基本轮询进程数，范围0-1000。
StartIPMIPollers=0	#IPMI轮询进程数，若无智能卡监控，可置为0。
StartPollersUnreachable=1	#不可达主机的轮询进程数，包括IPMI和JAVA。
StartTrappers=1	#捕获模式进程数，若无active模式的客户端，则可减小该进程。
StartPingers=20	#ICMP ping数量，当大量使用ping用于心跳检测时，可适量增加。
StartDiscoverers=1	#自动发现实例数，若关闭此功能则减少该数量。
StartHTTPPollers=7	#HTTP轮询实例数，当使用到内置的WEB监测时，适量增加该值。
StartTimers=1	#定时器实例数。
StartEscalators=20	#扩展实例数。
StartDBSyncers=20 #DB同步器线程数。
StartJavaPollers=5 #JAVA轮询实例，当大量监控JMX时需要增加此项。
StartProxyPollers=1	#代理轮询线程。

#缓存配置
CacheSize=8M	#128K-8G，缓存配置项的大小，用于存储 host， item， trigger 数据。监控项
CacheUpdateFrequency=60	#提交缓存频率。
HistoryCacheSize=16M	#历史缓存大小。
HistoryIndexCacheSize=4M	#历史索引缓存大小。
TrendCacheSize=4M	#趋势缓存大小。
ValueCacheSize=8M	#历史项目值缓存，设为0表示禁用项目值缓存，history value 缓存大小，当缓存超标了，将会每隔 5 分钟往 server 日志里面记录。

#用户配置
AllowRoot=0	#是否允许使用 root 启动， 0:不允许， 1:允许，默认情况下她会使用 zabbix 用户来启动 zabbix 进程。
User=zabbix	#服务使用的用户。

#超时配置
Timeout=4	#端探测超时时间。
TrapperTimeout=300	#捕捉器超时时间。
UnreachablePeriod=45	#不可达时间，超过视为不可达。
UnavailableDelay=60	#不可达期间尝试周期。
UnreachableDelay=15	#不可用期间尝试周期。
HousekeepingFrequency=1	#housekeeping 数据归档周期(h)，housekeep 执行频率，默认每小时回去删除一些过期数据。如果 server 重启，那么 30 分钟之后才执行一次，接下来，每隔一小时在执行一次。。
MaxHousekeeperDelete=5000	#housekeeper表记录,一次删除的数据不能大于 MaxHousekeeperDelete。
SenderFrequency=30	#Zabbix尝试发送未发送数据频率，5-3600s。

就可以根据自己的需要按照上面的内容进行配置。

三：zabbix的架构优化

常用的zabbix架构：（说明：Zabbix最简单的架构，常用于监控主机比较少的情况下。)
在这里插入图片描述
分布式架构：Server-Proxy-Agentd模式
说明：Zabbix分布式架构，常用于监控主机比较多的情况下，使用Zabbix Proxy进行分布式监控，有效的减轻了Zabbix Server端的压力。

四：Items工作模式及Trigger的优化

zabbix中的item默认的工作模式是被动模式，可以通过设置主动模式来提高Server的性能。
Trigger中正则表达式函数last（）、nodata（）的速度是最快的，min（）、max（）、avg（）是最慢的，尽量使用速度快的函数。

五：zabbix的数据库优化

数据库优化的方法有：

对数据库软件本身的优化。采用更高性能的数据库版本
对数据库本身的参数进行调优配置
对zabbix数据库结构进行优化，例如：对history.*、trends.*等表进行分表操作，会很大的提高数据库的性能。

配置数据库本身的参数：

innodb_buffer_pool_size - 如果你有一个专属的 MySQL 服务器，尽可能设置的越高越好（上限是整个可用内存的 75% 左右），否则，你将同服务器上的其他进程平衡它。但是如果它仅仅是 zabbix 服务器，我依然建议设置的比较高，接近总的内存的 75%。
innodb_buffer_pool_instances - 在 MySQL 5.5, 设置它为 4，在 MySQL 5.6 – 设置它为 8 或者甚至是 16。
innodb_flush_log_at_trx_commit = 0 - 这是折中的显著改善写入吞吐量的方案，特别是你没有一个非易失性高速缓存的磁盘子系统。基本上你引发的是在 MySQL 或是服务器 crash 时的 1s 的写损失。很多网站的实际运行它（很多网站依然运行在 MyISAM 上），我十分确定这不是一个 Zabbix 设置问题。
innodb_flush_method = O_DIRECT - 如果你是运行在 Linux，设置它。
innodb_log_file_size - 你想要这些事务日志（默认是有两份）保持 1 - 2 小时有价值的写入数据。为了做决定，你可能需要看下你的 MySQL 服务器的 Zabbix graphs，但是你也可以从 mysql 命令行运行以下的命令：
```
  mysql> pager grep seq; show engine innodb statusG select     sleep(3600); show engine innodb statusG PAGER set to     'grep seq'
  Log sequence number 8373513970951
```
…
Log sequence number 8373683996767

这两个数字的不同的之处就是 InnoDB 在上一个小时写入的字节数。因此在以上的服务器，我将设置 innodb_log_file_size=128M 并且以 256M 日志大小空间结束以允许我存储超过 1 个小时有价值的写入数据到事务日志中（See this on changing the log file size if you run MySQL 5.5 or earlier）

innodb_read_io_threads, innodb_write_io_threads - 不要深思这些，它们不像看起来那么重要，特别是如果你使用异步 IO（你可以通过在 mysql cli 运行 “show global variables like ‘innodb_use_native_aio’” 来检查）。在 MySQL 5.5 和 5.6 你通常想使用异步 IO（AIO），因此检查 mysql log 来明白为什么。如果没有，那就是说，如果你没有使用 AIO 并且不准备使用，仅仅设置这些值为 8 即可。
innodb_old_blocks_time = 1000 - 这个可以帮助你防止由于偶尔的 scans 造成的 buffer pool 污染。这个目前在 MySQL 5.6 中是默认的（在 5.5，需要明确设置）。
innodb_io_capacity - 设置这个是为了你的磁盘 IO 子系统能处理更多的写 iops。对于 SSDs，这个应该最少为几千（2000 可能是一个好的开始），然而对于一些旋转磁盘值稍微有点低 - 500-800，依赖于磁盘数量。对于今天的大多数系统，默认的 200 明确是太低的。
sync_binlog=0 - 这是默认设置，但以防万一它是大于 0，关闭它，除非你运行的不是 Zabbix。不同步 binary logs 的代价是万一 master 宕机，副本没有同步，但是如果由于 binary log 同步，你不断触及 IO 瓶颈，仅仅因为你想避免每五年一次同步到备机的麻烦，当 master 宕机了，你应该重新考虑这个选项。
query_cache_size=0, query_cache_type=0 - 这是禁止查询缓存。大部分时间你不需要查询缓存。并且如果你没有通过这些设置在内核中禁止它，查询（尤其是小的）可能会受到影响，由于查询缓存的互斥竞争。
sort_buffer_size, join_buffer_size, read_rnd_buffer_size - 如果你配置了这些变量，取消这些改变（仅仅移除它们或是注释它们）。我发现在大多数客户端服务器，这是失调的前三名变量。然而在大部分情况下，不改变它们是最好的。仅仅让它们保留默认值。
tmpdir - 有时候指定 tmpdir 为 /dev/shm 是一个好注意，以至于 on-disk temporary 表实际是写入内存中，但是在 MySQL 5.5 有一个重要的警告：如果你这样做了，它禁用了 AIO acorss the board，因为 tmpfs 不支持 AIO。因此我将监控在当前 tmpdir（/tmp）的活跃性，并且如果我发现它有问题的时候，切换到 /dev/shm。

zabbix数据库进行分表操作：
MySQL 5.5为写入工作负载留下了巨大的瓶颈 - 每个索引都有锁定锁定，因此当时只有一个线程可以插入索引条目，这可能是一个重要的瓶颈。我们通过其中一列的散列分区表获得了2x +更好的性能，我希望随着更多内核的增益可以更高。

具体操作脚本github链接：https://github.com/itnihao/zabbix-book/blob/master/03-chapter/partitiontables.sh

六：其他优化手段

服务器硬件
想通过几个简单的配置让服务器提高成倍的性能，想法很好，但是基本不太现实。简单的说，你需要搭配更好的CPU、更大的内存，更快的硬盘：条件允许的花，可以考虑购买SSD，它比更大的cpu和更大的内存带来的效果更好，或者考虑使用SAS 15K硬盘，组raid等等，总之一句话，配置优化不动的情况，增加硬件投入，别绞尽脑汁搜索：zabbix如何优化之类的文章，你在浪费时间。

操作系统
使用最新的操作系统，优化、定制化操作系统内核。应该会有些作用，但是肯定不大。

参考博客链接如下：
http://www.talkwithtrend.com/Article/242299
https://sre.ink/zabbix-turn-conf/#respond
https://segmentfault.com/a/1190000001638101