几周的zabbix使用之后几点心得,暂时记在这儿
- 简单命令监控,直接配置Userparameter参数,以应用来分类conf文件,将不同应用的配置写在不同的conf文件里,并将之放到统一的配置引入目录,每次修改均要重启zabbix-agent;配置文件的修改统一配置方式参考svn(这种方式文件检出会覆盖linux系统文件权限及所有者,每次更新后要修改权限等不太方便)、使用salt在salt-master文件目录入svn并在更新后以salt cp.get_file方式配置到各服务器上(该方式不会覆盖权限及所有者)。
- 脚本监控,原本以脚本对应parameter的配置方式实施,但感觉这种方式比较繁杂。可以提取parameter共性,利用带参数的Userparameter配置实现one key for all的功能。比如配置:
Userparameter=script.run[*],/var/lib/zabbix/$1 $2 $3
前提是配置好$1脚本的可执行权限。该方式注意脚本统一路径,权限等。
- 经常会遇到从http以json形式取监控数据,这种方式采用中间文件的形式实现。有json的fetch脚本,还有json内容提取脚本,不同监控需求一般需要单独的json fetch脚本,原本从json提取内容也是与之对应的有多个,现在感觉使用统一的json文件属性提取脚本方式比较合理。 中间文件命名程序化,尽量少用固定常量。另外在json fetch脚本记录错误日志。
- zabbix报警信息格式个性化,正在使用的解决方案是通过给trigger名称加标签(标签使用预定义全局宏),标签区分不同模板(标签会在使用脚本发送信息的时候被过滤)。
- 上一点提到,既然发送信息使用的是脚本,那么完全可以在发信息脚本层面做信息格式整理的封装。这种方式也是下一步要重构的目标。
时间: 2024-12-28 08:22:11