一、前言
这里用的是zabbix6.0LTS版本，这里记录自定义配置报警，因为邮件报警基本已经很少有人使用了，大部分是，短信、飞书、钉钉等等工具，所有需要定制化报警
二、定义脚本存放路径
cd /usr/local/zabbix/etc
[root@node1 etc]# vim zabbix_server.conf
#增加报警脚本的存放路径
AlertScriptsPath=/usr/local/zabbix/share/zabbix/alertscripts
三、创建报警媒介
点击"管理" --> “报警媒介类型”–>“创建媒体类型”
1处: 自定义报警媒介名称
2处: 报警媒介的类型，我们是自定义报警，所有选择"脚本"类型，一切报警的处理逻辑都在脚本中处理
3处: 脚本名称，此处的脚本名称就是调用放在 "AlertScriptsPath"参数路径中的脚本文件
4处: 此处有3个参数，这3个参数的写法是固定的，顺序也是固定的，不要调整它们的顺序
{ALERT.SENDTO} 的含义: 报警信息接收人
{ALERT.SUBJECT}的含义: 报警主题
{ALERT.MESSAGE}的含义：报警的具体消息
1.编写测试脚本
cd /usr/local/zabbix/share/zabbix/alertscripts
[root@node1 alertscripts]# touch log
[root@node1 alertscripts]# chmod 777 log
[root@node1 alertscripts]# cat main.sh
#!/bin/bash
url=$(dirname $(readlink -f $0))
echo "{ALERT.SENDTO} = $1" >> $url/log
echo "{ALERT.SUBJECT} = $2" >> $url/log
echo "{ALERT.MESSAGE} = $3" >> $url/log
2.发送消息给测试脚本
找到要测试的报警媒介，点击右侧的测试
填写测试内容
测试成功结果如下：
在服务器端查看是否有日志生成，
[root@node1 alertscripts]# cat log
{ALERT.SENDTO} = 12345678910
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = 这是一个测试报警消息
总结：
根据结论得出，在报警媒介定义的3个脚本参数 分别通过位置参数传递给了脚本
3.验证脚本参数顺序
调整参数顺序
再次发送相同的测试内容
日志内容如下：
[root@node1 alertscripts]# cat log
{ALERT.SENDTO} = 故障报警
{ALERT.SUBJECT} = 这是一个测试报警信息
{ALERT.MESSAGE} = 12345678910
4.结果
根据日志内容能够说明两点：
1.说明{ALERT.SENDTO}这三个参数的编写顺序是直接对应$1、$2、$3的顺序
2.说明
"收件人" 的值 赋值给 {ALERT.SENDTO} 变量
"主题" 的值 赋值给 {ALERT.SUBJECT} 变量
"消息" 的值 赋值给 {ALERT.MESSAGE} 变量
这个赋值的动作，不会随着脚本参数的顺序的变化而变化，
四、创建接收用户
1.简单用户接收
如果接收报警的人只限于运维部门几个人，可以直接在zabbix的Admin账号中配置多个接收人报警接收人。
注意：虽然这里是一个Admin 账户，但是里边的有3个报警信息接收人，此时Admin账号除了是一个zabbix系统的 “登录用户” 的身份，又是一个 “报警接收人组” 的身份
1.1 添加接收人1
1.2 添加接收人2
1.3 添加接收人3
添加完成后如下图，然后点击更新：
2.多用户接收
如果公司中有很多项目，不同的运维人员负责不同的项目，那就常见不同的zabbix用户，在不同的zabbix用户中增加不同的报警用户接收人，这样就可以根据不同的项目发送给不同的报警接收人
五、创建触发器
选择创建触发器
添加表达式如下图
添加完成后，搜索刚才添加的触发器
1.查看监控项值
[root@node1 ~]# /usr/local/zabbix/bin/zabbix_get -s "127.0.0.1" -p 10050 -k 'system.users.num'
1
多开启几个终端，现在登录用户数量变成了3个，我们的触发器规定的是大于2个就报警
[root@node1 ~]# /usr/local/zabbix/bin/zabbix_get -s "127.0.0.1" -p 10050 -k 'system.users.num'
3
2.查看触发器异常
此时的 “值” 从正常变成了"问题"
在"监测" --> “问题” 中也能快速的看到异常的触发器
关闭终端后，用户数量正常后，报警恢复之后如下图
六.创建动作
目前触发器触发之后，只会显示有问题，不会通知用户，这时候就需要触发器触发之后，有相关的动作，讲警告信息通知给用户，此时就用到了动作
1.添加报警主机
这里只是用于测试，生产中可以根据主机群组来定义
2.添加报警级别
如下图：
这里的含义为，此报警动作是在zabbix server主机 有报警级别大于等于严重的情况下会触发此动作
3.设置"操作"
注意：这里的主体和消息对应的就是 上述中的 {ALERT.SUBJECT} {ALERT.MESSAGE}参数。
这里的操作主要就是将 收件人信息、主题、 消息 已参数的形式发送给前边定义的"main.sh"脚本.
消息内容如下
故障：{TRIGGER.STATUS}，服务器：{HOSTNAME1}发生:{TRIGGER.NAME}故障！
告警主机：{HOSTNAME1}，IP地址：{HOST.CONN}
告警时间：{EVENT.DATE}{EVENT.TIME}
告警等级：{TRIGGER.SEVERITY}
告警信息：{TRIGGER.NAME}
告警项目：{TRIGGER.KEY1}
问题详情：{ITEM.NAME}:{ITEM.VALUE}
当前状态：{TRIGGER.STATUS}:{ITEM.VALUE1}
事件ID：{EVENT.ID}
恢复：{TRIGGER.STATUS}，服务器：{HOSTNAME1}已经恢复！:{TRIGGER.NAME}
告警主机：{HOSTNAME1} ，IP地址：{HOST.CONN}
告警时间：{EVENT.DATE}{EVENT.TIME}
告警等级：{TRIGGER.SEVERITY}
告警信息：{TRIGGER.NAME}
告警项目：{TRIGGER.KEY1}
问题详情：{ITEM.NAME}:{ITEM.VALUE}
当前状态：{TRIGGER.STATUS}:{ITEM.VALUE1}
事件ID：{EVENT.ID}
完成如下图：
3.验证动作是否生效
在server端查看记录日志
[root@node1 alertscripts]# tail -f log
{ALERT.SENDTO} = 13811111111
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = IP地址：127.0.0.1
告警时间：2023.04.0921:43:01
告警信息：用户登录数量报警
告警项目：system.users.num
问题详情：Number of logged in users:3
{ALERT.SENDTO} = 13822222222
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = IP地址：127.0.0.1
告警时间：2023.04.0921:43:01
告警信息：用户登录数量报警
告警项目：system.users.num
问题详情：Number of logged in users:3
{ALERT.SENDTO} = 13833333333
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = IP地址：127.0.0.1
告警时间：2023.04.0921:43:01
告警信息：用户登录数量报警
告警项目：system.users.num
问题详情：Number of logged in users:3
因为报警接收人1、2、3都接收"严重"报警，触发器的报警级别是"严重"，所有在脚本中收到了3个人的报警信息
4.调整触发器报警和动作级别
现在将"用户登录数量报警"的触发器的报警级别调整为"一般严重"
将动作级别也调整为"一般严重"
服务器日志如下： 只有用户1 和3 收到了报警信息，2没有收到
{ALERT.SENDTO} = 13811111111
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = IP地址：127.0.0.1
告警时间：2023.04.0922:00:01
告警信息：用户登录数量报警
告警项目：system.users.num
问题详情：Number of logged in users:3
{ALERT.SENDTO} = 13833333333
{ALERT.SUBJECT} = 故障报警
{ALERT.MESSAGE} = IP地址：127.0.0.1
告警时间：2023.04.0922:00:01
告警信息：用户登录数量报警
告警项目：system.users.num
问题详情：Number of logged in users:3
生产中一般不会设置不同的人接收不同级别的的报警信息，这里只是做了验证。
七、自定义模板
linux自带的模板比较全面，当然 个人感觉模板中的很多监控项我们用不到，所以可以自定义模板，然后自定义其中的监控项，是模板中的监控项少并且简洁。
八、克隆模板
zabbix6.0LTS 监控linux模板中 有两个模板
#被动模式模板
Linux by Zabbix agent
#被动模式模板
Linux by Zabbix agent active
这里克隆主动模式的模板，这里为什么要克隆而不是一个一个写监控项目呢？是因为模板中有"自动发现规则"，克隆后就不用手动写自动发现规则了
1.搜素模板
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-euhVAEsq-1681372282021)(E:\文档\工作文件\条线相关文件\SC1000\医疗zabbix文档\配置文档\zabbix配置文档.assets\image-20230412094723511.png)]
2.克隆模板
在克隆的时候选择完全克隆，因为完全克隆的时候，删除改动新模板，不会影像原来的模板
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lplKwgRz-1681372282023)(E:\文档\工作文件\条线相关文件\SC1000\医疗zabbix文档\配置文档\zabbix配置文档.assets\image-20230412094827591.png)]
3.修改新模板
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nqIYlrfa-1681372282023)(E:\文档\工作文件\条线相关文件\SC1000\医疗zabbix文档\配置文档\zabbix配置文档.assets\image-20230412095132192.png)]
4.查看克隆后的新模板
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8XWqAySf-1681372282024)(E:\文档\工作文件\条线相关文件\SC1000\医疗zabbix文档\配置文档\zabbix配置文档.assets\image-20230412095405679.png)]
九、自定义监控项目
注意：
对于常规的监控项可以保留，比如cpu、内存监控，还有自定义发现规则中的分区监控。其它的可以根据需要进行删除和保留
1.检测zabbix agent
agent.ping
在键值选项中，zabbix主动模式中，有一个监控项叫做agent.ping,检测zabbix—agent的状态，
"ZBX"图标变成绿色就是靠的这个监控项目。停止这个监控项目，图标变成灰色
"ZBX"图标变成红色是agent客户端down了。
agent.ping 客户端可达性检查。返回 nothing - 不可达；1 - 可达
注意：这个监控项要使用 被动模式。主动模式无效
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-atGTZI53-1681372282024)(E:\文档\工作文件\条线相关文件\SC1000\医疗zabbix文档\配置文档\zabbix配置文档.assets\image-20230413090851534.png)]
2.检测端口是否处于监听
net.tcp.listen[端口号]
