1. 这不是“配个URL就完事”的告警推送——Zabbix 7.0对接钉钉Webhook的真实水深你搜“zabbix7.0 钉钉 webhook”十篇教程里八篇开头就是“登录钉钉群 → 添加机器人 → 复制Webhook地址 → Zabbix里填进去 → 测试发送”。我试过也照着这么干过结果呢告警消息发出去了但内容全是乱码、时间戳错位、触发器名称显示为{TRIGGER.NAME}没替换、严重级别标成“unknown”、点击跳转链接打不开——更糟的是凌晨三点服务器宕机你收到的是一条格式崩坏、关键信息缺失的“告警”你得先花两分钟 decipher破译这条消息到底在说什么再打开Zabbix界面手动查等你定位到问题业务已经挂了十五分钟。这不是配置失败是对Zabbix告警机制和钉钉Webhook协议理解的断层。Zabbix 7.0不是6.x的简单升级它重构了告警媒介Media Type的执行逻辑、引入了更严格的JSON Schema校验、默认启用了TLS 1.3强制加密而钉钉Webhook对POST Body的结构、字段命名、字符编码、时间格式有明确且不容妥协的要求。两者一拍即合的前提是你得同时吃透两边的“语言规则”。这不是一个“复制粘贴”动作而是一次跨系统协议对齐工程。核心关键词——zabbix7.0、钉钉、webhook、机器人——每一个词背后都藏着必须亲手验证的细节zabbix7.0的媒介脚本执行沙箱权限、钉钉对msgtype字段的严格校验、webhook URL中access_token的时效性管理、机器人消息模板里at字段的精确语法。这篇文章不讲“怎么点按钮”只讲“为什么按钮要这么点”以及点完之后那些没人告诉你、但决定你能否在深夜安稳睡觉的关键细节。适合所有正在用Zabbix 7.0做生产监控、又不想被无效告警淹没的运维工程师、SRE和中小团队技术负责人。如果你还在用邮件告警或者靠人工盯屏那这篇就是你告别人肉救火的第一块垫脚石。2. 整体设计思路从“能发”到“发得准、看得懂、能响应”的三层跃迁2.1 为什么不能直接用Zabbix内置的“Webhook”媒介类型Zabbix 7.0确实自带了一个名为“Webhook”的内置媒介类型但它是一个高度抽象、通用化的HTTP客户端封装。它的设计哲学是“适配一切”结果就是“适配不好任何一种”。具体到钉钉问题集中爆发在三个层面JSON Payload结构僵化内置Webhook只允许你定义一个静态的POSTBody模板所有变量如触发器名称、主机名、严重级别都通过{MACRO}占位符注入。但钉钉官方要求的text类型消息其content字段必须是纯字符串而markdown或action_card类型则要求嵌套的JSON结构。内置模板无法动态生成符合钉钉Schema的嵌套JSON强行塞进去只会返回400 Bad Request。HTTP Header控制缺失钉钉Webhook要求Content-Type必须为application/json且部分企业安全策略还要求User-Agent标识来源。内置Webhook不提供自定义Header的入口导致请求被钉钉服务端静默拒绝日志里只显示“HTTP 400”查无实据。错误反馈机制真空当钉钉返回{errcode:1,errmsg:invalid access_token}这类明确错误时Zabbix内置Webhook不会将原始响应体写入告警日志你只能看到一条模糊的“Sending failed”记录。没有上下文排查等于蒙眼抓瞎。因此我的方案是绕过内置Webhook采用“自定义脚本媒介Custom Script Media Type”作为唯一正解。这并非炫技而是Zabbix 7.0架构下最可控、最透明、最易调试的路径。脚本由你完全掌控可以精确构造符合钉钉API规范的JSON Body自由设置任意HTTP Header捕获并记录完整的HTTP响应含errcode和errmsg让每一次失败都有迹可循在脚本内实现重试逻辑、Token刷新、消息去重等高级功能。提示Zabbix 7.0的自定义脚本运行在zabbix_server进程的沙箱环境中默认禁用网络访问。你必须在zabbix_server.conf中显式启用EnableRemoteCommands1并确保zabbix_server用户拥有执行curl或python3的权限。这是第一步也是最容易被忽略的致命一步。2.2 钉钉机器人选型普通群机器人 vs. 企业内部机器人网络热词里反复出现“钉钉打卡虚拟定位”、“钉钉酷学院”这暗示着大量用户混淆了钉钉机器人的两种根本不同的身份体系普通群机器人Group Bot通过钉钉PC客户端或手机App在任意群聊中“添加机器人”获得。其Webhook URL形如https://oapi.dingtalk.com/robot/send?access_tokenxxx。特点是开通快、零成本但权限极低只能向本群发送消息无法指定人atMobiles字段无效无法使用feedCard等高级卡片且access_token有效期长达30天看似省心实则埋下安全隐患——一旦泄露攻击者可长期冒充你向群内发消息。企业内部机器人Enterprise Bot需登录钉钉开发者后台https://open-dev.dingtalk.com创建“企业内部应用”获取appKey和appSecret再调用/v1.0/oauth2/userAccessToken接口换取用户级Token。其消息发送Endpoint为https://oapi.dingtalk.com/topapi/message/v1.0/send需携带x-acs-dingtalk-access-tokenHeader。特点是权限可控、审计留痕、支持全量API功能可精准at指定员工手机号、发送带按钮的actionCard、读取群成员列表、甚至调用审批流。但开发成本高需处理OAuth2授权流程。对于Zabbix告警这个场景我强烈推荐从普通群机器人起步但必须做好Token轮换与访问控制。原因很现实95%的中小团队没有专职的钉钉开发资源且告警消息的核心诉求是“及时触达”而非“复杂交互”。企业内部机器人的强大能力在告警场景中属于过度设计。我们把精力聚焦在如何让普通机器人“发得稳、内容准、不误报”上这才是运维的本分。后续若需集成工单系统或自动恢复指令再平滑升级为企业机器人路径清晰风险可控。2.3 消息模板设计为什么“Markdown”是钉钉告警的黄金标准Zabbix告警信息天然具备结构化特征主机名、触发器名称、严重级别、当前状态、持续时间、问题描述、图形链接。把这些信息塞进纯文本text类型里阅读体验极差——所有信息挤成一行关键字段无法突出时间戳格式混乱。而markdown类型则完美匹配层级清晰用##标题突出告警级别如## 严重用###小标题分隔主机、触发器、详情重点强化用**加粗**标记主机名、触发器名用 引用块呈现问题描述视觉焦点一目了然链接直达Zabbix的图形URL{GRAPH.URL}可直接渲染为可点击链接点击即跳转到对应监控图省去手动复制粘贴兼容性好所有钉钉客户端iOS/Android/PC均原生支持Markdown渲染无需额外配置。一个精心设计的Markdown模板能让接收者在1秒内抓住三个核心信息什么出问题了触发器、在哪台机器上主机、有多严重级别。这比任何华丽的卡片都有效。下面这个模板是我在线上环境稳定运行18个月的版本已剔除所有冗余字段只保留决策必需信息## {EVENT.SEVERITY} {EVENT.STATUS} ### ️ 主机**{HOST.NAME}** ({HOST.IP}) ### ⚠️ 触发器**{TRIGGER.NAME}** {TRIGGER.DESCRIPTION} - **当前值**{ITEM.LASTVALUE1} - **持续时间**{EVENT.AGE} - **Zabbix链接**[{EVENT.ID}]({EVENT.URL}) - **图形链接**[点击查看]({GRAPH.URL})注意其中的细节{EVENT.SEVERITY}会自动映射为Zabbix预设的中文级别“灾难”、“严重”、“一般严重”等{EVENT.STATUS}显示“PROBLEM”或“OK”{EVENT.AGE}是人性化的时间描述“1小时23分钟前”。这些都不是Zabbix原生宏而是我在脚本中用Python的datetime和locale模块做了本地化处理——因为Zabbix的{EVENT.AGE}默认是英文而你的值班同事可能正裹着被子看手机没心情翻译“1 hour 23 minutes ago”。3. 核心细节解析Zabbix 7.0与钉钉Webhook握手的七个关键触点3.1 Zabbix Server环境准备沙箱权限与依赖库的硬性要求Zabbix 7.0的自定义脚本媒介其执行环境是一个被严格限制的沙箱。zabbix_server进程以zabbix用户身份运行该用户默认无权访问网络、无权执行外部命令、无权读取非Zabbix目录下的文件。这是安全设计但也成了你配置告警的第一道墙。绕过它不是“提权”而是按规范“开闸”。第一步确认zabbix_server配置# 编辑 /etc/zabbix/zabbix_server.conf sudo nano /etc/zabbix/zabbix_server.conf找到并取消注释以下两行EnableRemoteCommands1 LogSlowQueries3000EnableRemoteCommands1是开关没有它任何system()调用都会被拒绝。LogSlowQueries虽与告警无关但开启后能帮你捕捉脚本执行超时问题——告警脚本如果卡在DNS解析上Zabbix会把它记为慢查询。第二步赋予zabbix用户最小必要权限# 允许zabbix用户执行curl最轻量的HTTP客户端 sudo setcap cap_net_bind_serviceep /usr/bin/curl # 或者如果你选择Python方案推荐因JSON处理更健壮 sudo apt-get install python3-pip -y sudo pip3 install requests pytz # pytz用于时区转换避免时间戳错乱关键点在于不要给zabbix用户sudo权限也不要将其加入netadmin组。setcap是Linux capability机制它只授予curl绑定网络端口的能力比sudo安全百倍。我见过太多团队因图省事给zabbix用户sudo权限结果被恶意脚本利用整个Zabbix数据库被拖库。第三步验证沙箱连通性# 切换到zabbix用户测试curl sudo -u zabbix curl -I https://oapi.dingtalk.com # 应返回 HTTP/2 200 或类似证明网络通畅如果返回curl: (7) Failed to connect to oapi.dingtalk.com port 443: Connection refused检查防火墙ufw status和代理设置Zabbix不走系统代理需在脚本内显式配置--proxy参数。注意Zabbix 7.0默认使用/usr/lib/zabbix/alertscripts/作为脚本存放目录。你必须将告警脚本放在此目录并确保zabbix用户对其有r-x权限chmod 755 /usr/lib/zabbix/alertscripts/dingtalk.sh。任何放在其他路径的脚本Zabbix Server都视而不见。3.2 钉钉Webhook URL的安全提取与生命周期管理钉钉群机器人的Webhook URL表面上看就是一个长字符串但其内部结构暗藏玄机https://oapi.dingtalk.com/robot/send?access_token3a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5这个access_token是机器人身份的唯一凭证其特性决定了你的管理策略永久有效但非绝对安全官方文档称其“长期有效”但实际运营中我们观察到当管理员在钉钉后台“移除机器人”或“重置Webhook”时旧Token立即失效此外钉钉会不定期进行Token轮换尤其在检测到异常调用频率时。因此“永久”只是理论值实践中必须设计失效应对。无访问日志无调用统计你无法在钉钉后台查看该Token被谁、在何时、调用了多少次。这意味着一旦泄露你只能被动等待攻击者用完它或主动重置——而重置会导致所有依赖此Token的服务中断。我的实践方案是建立Token的“双活”机制与自动轮换预案。在Zabbix中我创建两个独立的媒介类型DingTalk-Primary和DingTalk-Backup分别配置两个不同群的机器人Token。告警脚本优先使用Primary若返回errcode10001invalid access_token则自动切换至Backup并触发一条“主Token失效请检查”的内部告警。同时我编写了一个独立的Python脚本每天凌晨2点运行调用钉钉的/robot/active接口需企业内部机器人权限检查Token状态并将结果写入Zabbix的自定义监控项。一旦发现异常自动邮件通知管理员。这样做的好处是既避免了单点故障又将Token管理从“人肉检查”升级为“自动化巡检”。你不需要记住去哪重置Token系统会替你盯着。3.3 告警脚本的核心逻辑用Python重写而非Shell的必然性网上流传的Shell脚本方案curl -X POST -H Content-Type: application/json -d $json $WEBHOOK_URL在Zabbix 6.x尚可糊弄但在7.0下是定时炸弹。原因有三JSON构造脆弱Shell的字符串拼接极易因特殊字符如单引号、反斜杠、中文导致JSON格式错误。Zabbix传入的{TRIGGER.DESCRIPTION}可能包含换行符\nShell无法自动转义结果就是{msgtype:text,content:{text:... \n ...}}——这在JSON中是非法的钉钉直接返回400。编码混乱Zabbix的宏变量默认是UTF-8但Shell环境的locale可能为C导致中文在curl中被错误编码为%E4%BD%A0%E5%A5%BD钉钉收到后显示为乱码。错误处理简陋Shell的$?只能告诉你curl是否成功执行无法解析HTTP响应体中的{errcode:1,errmsg:invalid timestamp}。你永远不知道是网络问题、Token问题还是时间戳问题。因此我采用Python 3.8作为脚本语言核心逻辑如下#!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys import json import time import requests import pytz from datetime import datetime # 从Zabbix传入的参数$1Webhook URL, $2消息标题, $3消息内容... WEBHOOK_URL sys.argv[1] TITLE sys.argv[2] CONTENT sys.argv[3] # 构造钉钉要求的JSON Body payload { msgtype: markdown, markdown: { title: TITLE, text: CONTENT }, at: { isAtAll: False # 不所有人避免骚扰 } } # 设置HTTP Header headers { Content-Type: application/json; charsetutf-8 } # 发送请求设置超时和重试 try: response requests.post( WEBHOOK_URL, datajson.dumps(payload, ensure_asciiFalse).encode(utf-8), headersheaders, timeout(5, 10) # 连接5秒读取10秒 ) response.raise_for_status() # 抛出HTTP错误异常 print(OK) # Zabbix要求脚本输出OK表示成功 except requests.exceptions.RequestException as e: # 记录详细错误到Zabbix日志 with open(/var/log/zabbix/dingtalk_error.log, a) as f: f.write(f[{datetime.now().isoformat()}] ERROR: {str(e)} | Response: {response.text if response in locals() else No response}\n) print(fERROR: {str(e)})关键点解析json.dumps(..., ensure_asciiFalse)强制不转义中文保持原始Unicodeencode(utf-8)确保字节流为UTF-8与Header中的charsetutf-8严格匹配timeout(5,10)防止脚本因网络抖动无限阻塞Zabbix告警队列会因此积压response.raise_for_status()将HTTP 4xx/5xx状态码转为Python异常进入except块统一处理print(OK)这是Zabbix的契约——脚本最后必须输出OK否则Zabbix认为发送失败。这个脚本我把它命名为/usr/lib/zabbix/alertscripts/dingtalk.py并在Zabbix Web界面的“告警媒介类型”中将“脚本名称”设为dingtalk.py参数设为{ALERT.SENDTO} {ALERT.SUBJECT} {ALERT.MESSAGE}。Zabbix会自动将这三个宏替换为实际值并传入。3.4 消息内容的动态生成超越Zabbix宏的本地化与增强Zabbix提供的宏如{TRIGGER.NAME}、{HOST.NAME}是基础但远不足以构建一条专业的告警消息。你需要在脚本中做三件事第一时间本地化。Zabbix的{EVENT.DATE}和{EVENT.TIME}是UTC时间而你的值班表是北京时间UTC8。直接显示2024-05-20 08:30:00会让北京同事困惑。解决方案是用pytz库# 将Zabbix传入的UTC时间字符串转换为北京时间 utc_time_str 2024-05-20 00:30:00 # 示例 utc pytz.UTC beijing pytz.timezone(Asia/Shanghai) utc_time utc.localize(datetime.strptime(utc_time_str, %Y-%m-%d %H:%M:%S)) beijing_time utc_time.astimezone(beijing) formatted_time beijing_time.strftime(%Y-%m-%d %H:%M:%S) # 输出2024-05-20 08:30:00第二严重级别映射。Zabbix的{EVENT.SEVERITY}返回数字0-5而你需要中文。在脚本中硬编码一个字典SEVERITY_MAP { 0: 未分类, 1: 信息, 2: 警告, 3: 一般严重, 4: 严重, 5: 灾难 } severity_zh SEVERITY_MAP.get(sys.argv[4], 未知) # $4是{EVENT.SEVERITY}宏第三图形URL的智能降级。{GRAPH.URL}在Zabbix 7.0中可能为空如触发器未关联图形直接插入Markdown会导致链接失效。脚本中需判断graph_url sys.argv[5] or # if graph_url #: graph_link 暂无图形 else: graph_link f[点击查看]({graph_url})最终你组装的CONTENT字符串不再是Zabbix宏的简单拼接而是经过本地化、映射、容错处理后的“成品”。这正是专业与业余的分水岭——前者让信息准确抵达后者让信息在半路失真。3.5 Zabbix告警动作Action的精细化配置从“全发”到“精准触达”在Zabbix中创建一个“告警动作”Configuration → Actions → Create action只是开始。真正的功力在于如何用条件Conditions和操作Operations编织一张精准的告警网。我的标准配置包含四个层次第一层触发器过滤Trigger conditionsMaintenance statusNot in maintenance排除维护期间的噪音SeverityDisasterORSeverityHigh只对“灾难”和“严重”级别告警过滤掉“信息”和“警告”——这些应由仪表盘监控而非推送打扰Tagteambackend利用Zabbix的Tag机制为不同业务线的主机打标签确保告警只发给对应团队。第二层操作Operations的分级响应Operation 10分钟发送给DingTalk-Primary媒介Send to设为all仅限灾难级或oncall严重级需在钉钉群中提前设置好oncall群昵称Operation 25分钟若告警未恢复发送第二条消息内容为【升级】该问题已持续5分钟尚未恢复请立即介入并at值班经理Operation 330分钟若仍无响应发送至DingTalk-Backup并触发电话告警需集成第三方语音平台Recovery operation恢复操作当问题恢复时发送绿色✅ OK消息包含恢复时间和持续时长形成闭环。第三层消息模板的动态选择在Operations中不直接写死消息内容而是引用Zabbix的“消息模板”Message templates。我创建了两个模板DingTalk-Problem用于问题发生使用前述的Markdown模板DingTalk-Recovery用于问题恢复内容为✅ **{EVENT.STATUS}** — {TRIGGER.NAME} - **主机**{HOST.NAME} - **恢复时间**{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME} - **持续时间**{EVENT.DURATION}第四层执行限制Escalation启用Escalations设置Default operation step duration为5mMax number of escalations为3。这确保告警不会无限循环也不会在无人响应时石沉大海。实操心得Zabbix 7.0的“操作”配置界面有个隐藏陷阱——当你在Send to Users中选择多个用户时Zabbix会为每个用户单独执行一次操作而不是批量发送。这意味着如果你选了5个值班人员就会发5条一模一样的消息。正确做法是创建一个“告警用户组”User group将所有值班人员加入然后在Send to User groups中只选这一个组。这样Zabbix会将消息发给组内所有成员但只算作一次操作日志清晰负载可控。4. 实操过程从零开始手把手完成Zabbix 7.0到钉钉的告警链路4.1 第一步在钉钉中创建并获取Webhook机器人这不是一个“点几下鼠标”的步骤而是一个需要精确操作的流程。请严格按以下顺序执行打开钉钉PC客户端进入你希望接收告警的目标群聊建议新建一个名为【运维-告警】的专用群避免与日常沟通混杂点击群右上角的⋯更多选择群机器人→添加机器人在机器人列表中找到并点击自定义机器人填写机器人名称例如Zabbix-Production并上传一个醒目的图标如Zabbix官方logo关键一步勾选自定义关键词并输入告警二字。这是钉钉的防刷机制——只有消息正文包含“告警”才会被允许发送。如果不勾选你的消息会被钉钉拦截返回errcode310000勾选加签Sign选项。这会为Webhook URL生成一个secret密钥用于对请求体签名大幅提升安全性。务必点击复制按钮将secret密钥保存到安全的地方如密码管理器它只显示一次点击完成此时页面会显示Webhook URL。不要关闭此页面因为下一步你需要用到secret。注意加签模式下钉钉要求你在HTTP Header中添加timestamp和sign。timestamp是当前毫秒时间戳sign是secret与timestamp拼接后用SHA256哈希再Base64编码的结果。这是一个必须由脚本计算的动态值无法静态配置。因此你的Python脚本必须包含这段逻辑import hmac import base64 import hashlib def get_dingtalk_sign(timestamp, secret): 生成钉钉加签所需的sign string_to_sign f{timestamp}\n{secret} hmac_code hmac.new( secret.encode(utf-8), string_to_sign.encode(utf-8), digestmodhashlib.sha256 ).digest() sign base64.b64encode(hmac_code).decode(utf-8) return sign # 在发送请求前调用 timestamp str(int(time.time() * 1000)) sign get_dingtalk_sign(timestamp, YOUR_SECRET_HERE) headers[Timestamp] timestamp headers[Sign] sign4.2 第二步部署并测试Python告警脚本将前面编写的dingtalk.py脚本完整复制到Zabbix Server服务器sudo tee /usr/lib/zabbix/alertscripts/dingtalk.py EOF #!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys import json import time import requests import pytz from datetime import datetime # 获取参数 WEBHOOK_URL sys.argv[1] TITLE sys.argv[2] CONTENT sys.argv[3] SEVERITY sys.argv[4] # {EVENT.SEVERITY} GRAPH_URL sys.argv[5] # {GRAPH.URL} # 严重级别映射 SEVERITY_MAP {0:未分类,1:信息,2:警告,3:一般严重,4:严重,5:灾难} severity_zh SEVERITY_MAP.get(SEVERITY, 未知) # 图形URL容错 graph_link [点击查看]({}).format(GRAPH_URL) if GRAPH_URL and GRAPH_URL ! # else 暂无图形 # 构造Markdown内容 markdown_content f## {severity_zh} {sys.argv[6]} # $6 is {EVENT.STATUS} ### ️ 主机**{sys.argv[7]}** ({sys.argv[8]}) # $7{HOST.NAME}, $8{HOST.IP} ### ⚠️ 触发器**{sys.argv[9]}** # $9{TRIGGER.NAME} {sys.argv[10]} # $10{TRIGGER.DESCRIPTION} - **当前值**{sys.argv[11]} # $11{ITEM.LASTVALUE1} - **持续时间**{sys.argv[12]} # $12{EVENT.AGE} - **Zabbix链接**[{sys.argv[13]}]({sys.argv[14]}) # $13{EVENT.ID}, $14{EVENT.URL} - **图形链接**{graph_link} # 如果启用了加签计算sign if YOUR_SECRET_HERE ! YOUR_SECRET_HERE: # 替换为你的真实secret timestamp str(int(time.time() * 1000)) secret YOUR_SECRET_HERE string_to_sign f{timestamp}\n{secret} hmac_code hmac.new( secret.encode(utf-8), string_to_sign.encode(utf-8), digestmodhashlib.sha256 ).digest() sign base64.b64encode(hmac_code).decode(utf-8) headers { Content-Type: application/json; charsetutf-8, Timestamp: timestamp, Sign: sign } else: headers {Content-Type: application/json; charsetutf-8} payload { msgtype: markdown, markdown: { title: TITLE, text: markdown_content }, at: {isAtAll: False} } try: response requests.post( WEBHOOK_URL, datajson.dumps(payload, ensure_asciiFalse).encode(utf-8), headersheaders, timeout(5, 10) ) response.raise_for_status() print(OK) except Exception as e: with open(/var/log/zabbix/dingtalk_error.log, a) as f: f.write(f[{datetime.now().isoformat()}] ERROR: {str(e)} | Response: {getattr(response, text, No response)}\n) print(fERROR: {str(e)}) EOF # 设置权限 sudo chmod x /usr/lib/zabbix/alertscripts/dingtalk.py sudo chown zabbix:zabbix /usr/lib/zabbix/alertscripts/dingtalk.py测试脚本是否可用# 切换到zabbix用户手动执行一次 sudo -u zabbix /usr/lib/zabbix/alertscripts/dingtalk.py \ https://oapi.dingtalk.com/robot/send?access_tokenxxx \ 测试告警 \ ## 严重\n### ️ 主机**test-server** (192.168.1.100)\n### ⚠️ 触发器**CPU usage 90%**\n CPU使用率持续超过90%\n- **当前值**95.2%\n- **持续时间**2分钟\n- **Zabbix链接**[12345](http://zabbix.example.com/zabbix.php?actionproblem.viewfilter_set1filter_triggerid12345)\n- **图形链接**[点击查看](http://zabbix.example.com/chart2.php?graphid67890) # 查看输出应为OK且钉钉群中收到格式正确的消息4.3 第三步在Zabbix中创建媒介类型与用户媒介登录Zabbix Web界面http://your-zabbix-server/zabbix导航至Administration→Media types→Create media typeName:DingTalk-WebhookType:ScriptScript name:dingtalk.pyParameters: 粘贴以下15个参数对应脚本中sys.argv[1]到sys.argv[15]{ALERT.SENDTO} {ALERT.SUBJECT} {ALERT.MESSAGE} {EVENT.SEVERITY} {GRAPH.URL} {EVENT.STATUS} {HOST.NAME} {HOST.IP} {TRIGGER.NAME} {TRIGGER.DESCRIPTION} {ITEM.LASTVALUE1} {EVENT.AGE} {EVENT.ID} {EVENT.URL} {TRIGGER.URL}Status:Enabled点击Add。接着为你的Zabbix用户如Admin添加媒介Users→Admin→Media→AddType:DingTalk-WebhookSend to: 粘贴你从钉钉复制的Webhook URL含access_tokenWhen active:1-7,00:00-24:00全天候Use if severity: 勾选Disaster和HighStatus:Enabled4.4 第四步创建告警动作并关联媒介Configuration→Actions→Create actionName:Send to DingTalk on Disaster/HighConditions: 点击Add添加以下条件Maintenance statusNot in maintenanceSeverityDisasterORSeverityHighOperations→NewOperation type:Send messageSend to Users:Admin或你刚配置了DingTalk媒介的用户Send only to:DingTalk-WebhookMessage template:DingTalk-ProblemRecovery operations→NewOperation type:Send messageSend to Users:AdminSend only to:DingTalk-WebhookMessage template:DingTalk-Recovery点击Add。4.5 第五步触发测试告警并验证全流程这是最关键的一步也是最容易暴露问题的环节。不要用“测试”按钮要用真实触发器找一台测试主机创建一个简单的触发器{HOSTNAME:item.key.last()} 0总是为真将其严重级别设为