zabbix监控模板修改及调优（不完整版）

sfyhip

• 简介监控一直在不同的层面为我们的运维工作发挥着重要的作用：
  网络层监控，及时发现网络间的访问质量（如我们之前介绍的全国maps网络监控）；
  服务器监控，了解服务器各项性能参数（如常见的zabbix、cacti、nagios、ganglia等）；
  应用性能监控，深入监测具体业务的性能情况（如我们之前提到的APM监控系统）
  其中，服务器监控作为一种传统的监控类型，我们结合不同场景中也用到了多种方案。而在众多方案中，zabbix由于其强大的功能和灵活的自动化特性，尤其得到我们的广泛使用。
  
  为了打造出适合自己的zabbix监控体系，如何去配置和优化是一个比较复杂的课题。下文从监控模板的角度去简单介绍下我们的一些思路，以便抛砖引玉。2. 优化现有模板zabbix自带了各类操作系统的监控模板，一般可以直接拿来用，但如果要求更精细的监控，就要对自带模板进行修改了。
  此外zabbix在网上还有大量的第三方模板可以使用：
  https://zabbix.org/wiki/Zabbix_Templates
  https://share.zabbix.com/
  利用这些第三方模板可以很好地实现官方模板所没有的各类监控：
  更多的系统类型，如各类网络设备/VMware
  硬件状态，如磁盘IO/磁盘健康状态/阵列状态
  各类软件服务，如Nginx/PHP/Memcached/Redis/Hadoop/Elasticsearch
  充分利用第三方模板能避免重复造轮子，但往往第三方模板的监控并不完全符合自己的需求，这时也要自行修改。下面以自带的Template OS Linux为例进行举例。同时为了避免修改原始模板，复制为新模板Template OS Linux Custom进行优化。2.1 优化监控项为了降低zabbix server的压力，通常建议把原有监控项统一修改为客户端主动式（Active）。这里可以用到模板的批量更新功能：
  
  然后是具体监控项的优化。比如自带模板通过LLD（Low-level discovery）实现了所有网卡的流量监控，可以在此基础上增加网卡速率的监控。直接在模板里新增一个监控项原型：
  
  新监控项可以对应配置下触发器，比如这里实现了网卡速率降到1000M以下的报警
  
  注意新增监控的同时需要定义客户端的监控项：
  network_agentd.confUserParameter=net.if.speed
  
• ,sudo /sbin/ethtool $1 |grep Speed|awk ‘{print $$2}’|sed ‘s@Mb/s@@’2.2 优化触发器对于已有触发器，建议结合自己的实际场景修改报警阈值，此外可以根据需求增加新的触发器。zabbix的触发器支持大量功能函数，因此可以灵活设计自己的触发器表达式。比如自带模板已经有系统时间的监控项（Host local time），但并没有对时间出现偏差的故障进行报警。这时我们只需要在模板上增加一个触发器，让被监控机器的系统时间与zabbix server的系统时间偏差超过2分钟时发生报警：
  
  zabbix 3.0起增加了预测性的触发器函数，可以充分利用该特性优化监控。如根据过去1小时的趋势来预测未来1小时是否会触发内存不足的报警：
  
  有时候不同项目的报警阈值要求并不一样，除了分成不同的模板或者单独调整具体主机的触发器，其实还可以结合宏实现报警阈值的动态调整。如默认的可用swap是小于50%才报警，我们改为用宏{$SWAPWARN}定义报警阈值
  
  然后在模板定义一个宏，设置默认值50，那么默认情况下仍然是小于50%才报警。
  
  但如果对于具体某个主机，设置了其他的宏值如10，那么这个主机则会在可用swap小于10%才报警。
  
  触发器还有一个选项是严重性，用于设置该触发器的严重程度，这在需要针对不同阈值设置不同报警程度的场景下就特别有用。此时为了收敛报警可以设置触发器的依赖关系，即低严重性触发器依赖于高严重性触发器。这样，当出现高严重性报警时，相关联的低严重性报警就不会重复触发，从而减少报警消息量。zabbix 3.0之后，触发器原型也支持依赖关系。比如我们可以对警告级别和严重级别的磁盘空间报警触发器设置依赖：
  
  
• 改造模板支持自动发现zabbix模板支持自动发现，这大大方便了同类监控的批量添加，非常便于运维自动化。相比之下，尽管cacit的模板可以通过参数实现多个同类监控，但如果要实现批量添加就复杂不少。但并不是所有zabbix模板都支持自动发现，这时该怎么办呢，其实我们可以手动改造模板。比如常用的Percona Monitoring Plugins，它很全面地实现了MySQL监控，比官方自带的强大得多。但默认模板只能监控单一的3306实例。如果线上实例不是3306端口，或者有多个实例就无法监控了。下面介绍如何将它改造为LLD（Low-level discovery）的自动发现模板。3.1 定义自动发现规则所有自动发现的模板都至少要定义一个自动发现规则，这里定义一个每小时更新的规则，用于发现需要监控的所有MySQL端口
  
  
• 定义自动发现中具体的宏。宏可以定义多个，但这里只需要一个即MySQL端口 定义匹配宏用的正则表达式规则，也可以不配置。这里类似33*的值都被认为是合法端口值 3.2 修改模板XML将模板导出为XML，将普通监控改为自动发现的格式：首先修改监控项为监控项原型
  
  ……
  
  替换为下面格式
  
  
  
  ……
  
  
  
  修改图形为图形原型
  
  ……
  
  替换为下面格式
  
  
  
  ……
  
  
  
  修改触发器为触发器原型
  
  替换为下面格式
  
  
  
  
  
  修改应用类型为应用类型原型（zabbix 3.0起支持）
  
  Percona MySQL
  
  替换为下面格式
  
  
  Percona MySQL {#MYSQLPORT}
  
  修改完毕后，导入到zabbix覆盖原来的模板。3.3 配置agent的自动发现配置自动发现的key，需要结合自己实际来编写脚本实现端口发现的逻辑。我们是读取统一管理后台的接口，并格式化成zabbix需要的json。
  mysql_discovery_agentd.confUserParameter=MySQL.port.discovery,/bin/bash /var/lib/zabbix/percona/scripts/zbx_discovery_mysql.sh port_discovery脚本执行效果如下{
  “data”:[
  {
  “{#MYSQLPORT}”:”3306″
  },
  {
  “{#MYSQLPORT}”:”3307″
  }]
  }修改Percona Monitoring Plugins的zabbix配置文件，使得能接收端口参数，实现自动发现。userparameter_percona_mysql.confUserParameter=MySQL.Alive[],/usr/bin/mysqladmin -uzabbix -pzabbix -h127.0.0.1 -P$1 ping 2>&1|grep alive |wc -l
  UserParameter=MySQL.Sort-scan[],/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh kt $1
  UserParameter=MySQL.slave-stopped[],/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh jh $1
  UserParameter=MySQL.Com-replace
  
• ,/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh jz $1
  ……这里我们去掉了Total number of mysqld processes的监控项，增加一个用ping来检测具体MySQL实例是否存活的监控项。 该监控项原型还关联了一个自定义的值映射，增加监控值的可读性 修改Percona Monitoring Plugins的相应脚本，以便支持不同端口。而ss_get_mysql_stats.php原本就支持端口参数，所以不需要修改。/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh……
  ITEM=$1
  HOST=127.0.0.1
  PORT=$2
  DIR=dirname $0
  CMD=”/usr/bin/php -q $DIR/ss_get_mysql_stats.php –host $HOST –port $PORT –items gg”
  if [ “$PORT” = “3306” ];then
  CACHEFILE=”/tmp/$HOST-mysql_cacti_stats.txt”
  else
  CACHEFILE=”/tmp/$HOST-mysql_cacti_stats.txt:$PORT”
  fi
  ……最新数据的效果如下图: 4. 模板的自动关联当把模板都定制好之后，就可以进一步定义动作，实现新主机的自动注册并关联模板、主机组。 在模板自动关联的基础上，通过自研运维后台与zabbix API接口相结合，我们很好地实现了服务器上架并添加监控、下架并撤销监控的自动化运维工作。 但也需要强调一下，没有最好的监控系统，只有最合适自己的监控系统。怎么结合开源工具和自研工具，更好地实现运维自动化需求才是我们的核心目标。