几周的zabbix使用之后几点心得，暂时记在这儿

1. 简单命令监控，直接配置Userparameter参数，以应用来分类conf文件，将不同应用的配置写在不同的conf文件里，并将之放到统一的配置引入目录，每次修改均要重启zabbix-agent；配置文件的修改统一配置方式参考svn（这种方式文件检出会覆盖linux系统文件权限及所有者，每次更新后要修改权限等不太方便）、使用salt在salt-master文件目录入svn并在更新后以salt cp.get_file方式配置到各服务器上（该方式不会覆盖权限及所有者）。
2. 脚本监控，原本以脚本对应parameter的配置方式实施，但感觉这种方式比较繁杂。可以提取parameter共性，利用带参数的Userparameter配置实现one key for all的功能。比如配置：

   Userparameter=script.run[*],/var/lib/zabbix/$1 $2 $3

   前提是配置好$1脚本的可执行权限。该方式注意脚本统一路径，权限等。

3. 经常会遇到从http以json形式取监控数据，这种方式采用中间文件的形式实现。有json的fetch脚本，还有json内容提取脚本，不同监控需求一般需要单独的json fetch脚本，原本从json提取内容也是与之对应的有多个，现在感觉使用统一的json文件属性提取脚本方式比较合理。 中间文件命名程序化，尽量少用固定常量。另外在json fetch脚本记录错误日志。
4. zabbix报警信息格式个性化，正在使用的解决方案是通过给trigger名称加标签（标签使用预定义全局宏），标签区分不同模板（标签会在使用脚本发送信息的时候被过滤）。
5. 上一点提到，既然发送信息使用的是脚本，那么完全可以在发信息脚本层面做信息格式整理的封装。这种方式也是下一步要重构的目标。

zabbix统一脚本监控方式