分布式监控系统Zabbix3.2给异常添加邮件报警

简介:   在前一篇 分布式监控系统Zabbix3.2跳坑指南 中已安装好服务端和客户端,此处客户端是被监控的服务器,可能有上百台服务器。监控的目的一个是可以查看历史状态,可以对比零晨和工作区间数据的对比,以便后期进行优化指导。

  在前一篇 分布式监控系统Zabbix3.2跳坑指南 中已安装好服务端和客户端,此处客户端是被监控的服务器,可能有上百台服务器。监控的目的一个是可以查看历史状态,可以对比零晨和工作区间数据的对比,以便后期进行优化指导。还有一个是报警,总不能等到服务器出现异常了才去从头查是什么问题吧。所以这篇主要介绍报警中最基础的一个 配置邮件预警。

  通常zabbix提供了 e-mail、sms、jabber、微信等预警方式,sms等前期需要资金投入那就先否决吧,谁叫老板不给钱。

安装邮件发送工具mailx

  这里我选择的是mailx,所以的关闭其他的邮件发送工具

service sendmail stop #关闭
chkconfig sendmail off #禁止开机启动
service postfix stop
chkconfig postfix off

 执行安装mailx的命令:

yum install mailx

配置Zabbix服务端外部邮箱

打开文件vi /etc/mail.rc 如果mail.rc文件没有,就手动创建 内容如下:

set sendcharsets=iso-8859-1,utf-8
set from=123456789@163.com
set smtp=smtp.163.com:25
set smtp-auth-user=123456789@163.com #认证用户,一般与from保持一致
set smtp-auth-password=xxx #认证密码,如何开通授权可自行google

 

测试邮件是否可以发出

echo "zabbix test mail" |mail -s "zabbix" yyy@163.com
#这时候,邮箱yyy@163.com会收到来自123456789@163.com的测试邮件

编写发送邮件脚本

进入下面路径:/usr/local/zabbix/alertscripts 创建sendmail.sh文件,内容如下
echo "$3" | mail -s "$2" "$1"


  上面的这个三个参数是接收从web页面中传递过来的,$1:收件人邮箱地址;$2:邮件标题;$3:邮件内容
  为什么我们会在这个路径下面创建这个脚本呢,这是在我们的zabbix_server.conf文件中配置的
  AlertScriptsPath=/usr/local/zabbix/alertscripts
  所以你不想将这个脚本放在这个目录下面,需要修改服务端的配置文件中的AlertScriptsPath的值。

配置web页面

  创建媒体类型

  点击创建媒体类型

 

 

  添加以下3个参数,分别对应sendmail.sh脚本需要的3个参数:收件人地址、主题、详细内容
{ALERT.SENDTO}
{ALERT.SUBJECT}
{ALERT.MESSAGE}
  如果在3.0中不添加这三个参数会报错,因为在3.0以后zabbix允许自定义参数了,所以不会默认传递参数,在2.0的时候会默认传递三个参数,所以在3.0如果不写这三个参数会报错。

给用户添加报警媒介

在这以Admin用户为例 管理—》用户—》点击Admin

 

点击Admin

 

添加接收人

添加动作


填写动作选项 

此处添加以一般严重 状态的信息都报警。

除了自己填写一个名称以外,其余的都默认就好了。当然也可以修改成中文:参考如下

默认接收人:
故障{TRIGGER.STATUS},服务器:{HOSTNAME1}发生:{TRIGGER.NAME}故障!
默认信息:
告警主机:{HOSTNAME1}
告警时间:{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}
恢复时间:{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}
#这里注意了,很多教程都是复制故障通知消息,这里时间需要设置为EVENT.RECOVERY.DATE 才会发送正确的故障恢复时间,否则会发送故障发生时的时间。
告警时间:{EVENT.DATE}{EVENT.TIME}
告警等级:{TRIGGER.SEVERITY}
告警信息: {TRIGGER.NAME}
告警项目:{TRIGGER.KEY1}
问题详情:{ITEM.NAME}:{ITEM.VALUE}
当前状态:{TRIGGER.STATUS}:{ITEM.VALUE1}
事件ID:{EVENT.ID}
已启用:打钩

填写条件选项

 

解释:

默认的步骤是1-1,也即是从1开始到1结束。一旦故障发生,就是执行sendEmail.sh脚本发生报警邮件给Admin用户和zabbix administrator组。

假如故障持续了1个小时,它也只发送一次。如果改成1-0,0是表示不限制.无限发送 间隔就是默认持续时间60秒。那么一个小时,就会发送60封邮件。
到这我们的邮件报警配置就完成了,这是只要我们设置的触发器触发,就会自动给我发送报警邮件。

测试邮件报警

我将zabbix自带的模板中的对可用内存的监控中的触发器的临界值改为大于0,进入模板列表

点击修改,改成可用内存小于2g就报警,这样就容易触发。

保存以后 将收到一份报警邮件 内容如下:

在此就配好了邮件发送。

补坑注意:

  在邮件发送时,按上面的sendmail.sh中的写可能会出现zabbix邮件内容为附件和zabbix图中出现中文乱码问题。

下面是参考园友的解决方法:

安装zabbix之后,设置邮件脚本报警的时候,发送的报警内容变成了tcmime.1278.1278.1724.bin或ATT00001.bin。

安装dos2unix:
yum -y install mailx dos2unix //安装mailx工具和dos2unix转换工具

以下是脚本内容
打开 /usr/local/zabbix/alertscripts/sendmail.sh
替换内容

#!/bin/bash

export LANG=zh_CN.UTF-8

file=/tmp/zabbix_mail.txt
echo "$3" > $file
dos2unix -k $file
/bin/mailx -s "$2" $1 < $file

 

目录
相关文章
|
8月前
|
Kubernetes 大数据 调度
Airflow vs Argo Workflows:分布式任务调度系统的“华山论剑”
本文对比了Apache Airflow与Argo Workflows两大分布式任务调度系统。两者均支持复杂的DAG任务编排、社区支持及任务调度功能,且具备优秀的用户界面。Airflow以Python为核心语言,适合数据科学家使用,拥有丰富的Operator库和云服务集成能力;而Argo Workflows基于Kubernetes设计,支持YAML和Python双语定义工作流,具备轻量化、高性能并发调度的优势,并通过Kubernetes的RBAC机制实现多用户隔离。在大数据和AI场景中,Airflow擅长结合云厂商服务,Argo则更适配Kubernetes生态下的深度集成。
1026 34
|
4月前
|
存储 算法 安全
“卧槽,系统又崩了!”——别慌,这也许是你看过最通俗易懂的分布式入门
本文深入解析分布式系统核心机制:数据分片与冗余副本实现扩展与高可用,租约、多数派及Gossip协议保障一致性与容错。探讨节点故障、网络延迟等挑战,揭示CFT/BFT容错原理,剖析规模与性能关系,为构建可靠分布式系统提供理论支撑。
274 2
|
4月前
|
机器学习/深度学习 算法 安全
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
176 3
|
6月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
262 1
分布式新闻数据采集系统的同步效率优化实战
|
12月前
|
存储 运维 安全
盘古分布式存储系统的稳定性实践
本文介绍了阿里云飞天盘古分布式存储系统的稳定性实践。盘古作为阿里云的核心组件,支撑了阿里巴巴集团的众多业务,确保数据高可靠性、系统高可用性和安全生产运维是其关键目标。文章详细探讨了数据不丢不错、系统高可用性的实现方法,以及通过故障演练、自动化发布和健康检查等手段保障生产安全。总结指出,稳定性是一项系统工程,需要持续迭代演进,盘古经过十年以上的线上锤炼,积累了丰富的实践经验。
975 7
|
存储 分布式计算 Hadoop
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
403 7
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
728 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
运维 监控 BI
zabbix强大的报警系统
zabbix强大的报警系统
448 8
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
738 4
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
479 0

推荐镜像

更多