指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载导读本文以 Zabbix 官方仓库中的 ServiceNow 集成模板为核心完整讲解如何借助 Zabbix 的 Webhook 媒体类型能力将 Zabbix 中的告警事件自动同步为 ServiceNow 平台上的 incident事件工单。阅读并实践本文后你将掌握ServiceNow 端服务用户与角色的创建、media_servicenow.yaml模板的导入与参数填充、Zabbix 用户与媒体配置、事件严重级别到 ServiceNow urgency 的映射以及恢复recovery与更新update操作对既有工单的联动逻辑最终形成一套可直接复用的监控告警闭环。概述Webhook 如何打通 Zabbix 与 ServiceNow本指南对应的官方集成模板位于仓库 templates/media/servicenow由两个核心文件组成README.md官方配置指南即本文主体内容的来源media_servicenow.yaml可直接导入 Zabbix 前端的 Webhook 媒体类型定义。集成的本质是Zabbix 的 Webhook 媒体类型内部执行一段 JavaScript 脚本把动作action中定义的通知内容拼装成 JSON 请求通过 ServiceNow 的POST /api/now/table/incidentREST API 创建 incident当问题恢复或问题被更新时脚本改为对.../incident/{sys_id}发送PUT请求从而更新既有工单。这种一个 webhook 同时覆盖创建与更新的设计正是该模板的核心价值。在 Zabbix 源码层面Webhook 媒体类型有明确的类型定义include/zbxdbhigh.h中的MEDIA_TYPE_WEBHOOK 4include/zbxdbhigh.h#L265通知的发送由 alerter 进程执行在 alerter.c 的alerter_process_webhook()中通过 Zabbix 内嵌的 JS 引擎zbx_es_*系列函数加载并执行 webhook 脚本最终将脚本返回的 JSON包含__zbx_servicenow_sys_id等标签回传给事件作为后续恢复/更新操作的依据。适用范围与限制官方文档明确了两点前提Zabbix 版本要求8.0 及以上模板zabbix_export.version同样标记为8.0恢复与更新操作、以及 ServiceNow 自定义字段custom fields仅对触发器trigger产生的事件有效。对应地模板脚本中只有在event_source为触发器事件时才执行工单恢复/更新的PUT逻辑。前置条件在开始配置前需要准备一台可访问的Zabbix 8.0 服务器Webhook 媒体类型依赖内嵌 JS 引擎与 alerter 进程需确认编译时已启用相应组件一个ServiceNow 实例instance并拥有管理权限用于创建工单的ServiceNow 服务账号及其密码Zabbix 服务器与 ServiceNow 实例之间的网络连通性HTTPS 出站。Webhook 参数详解导入媒体类型后可在媒体类型 - ServiceNow - 参数中查看和修改参数。模板脚本会读取全部参数以servicenow_开头的参数被提取为连接与工单核心配置以u_开头的参数被识别为 ServiceNow 自定义字段custom field其余预定义参数用于事件解析。可配置参数参数名默认值说明servicenow_password\PLACE PASSWORD HERE\ServiceNow 服务用户的密码。servicenow_url\PLACE URL HERE\ServiceNow 实例的完整 URL如https://\INSTANCE.service-now.com/脚本会自动拼接api/now/table/incident作为工单 REST 接口。servicenow_user\PLACE USERNAME HERE\ServiceNow 服务账号的用户名。tls_verify{$HTTP.TLS.VERIFY:ServiceNow}HTTP 请求的 TLS 证书校验策略none关闭校验peer校验证书链与有效期full进行完整校验同时校验主机名任何其他值都会被当作full。可通过定义上下文为ServiceNow的全局宏即{$HTTP.TLS.VERIFY:ServiceNow}针对该媒体类型单独覆盖。urgency_for_average2事件严重级别为 Average 时映射的 ServiceNow urgency 值。urgency_for_disaster1事件严重级别为 Disaster 时映射的 ServiceNow urgency 值。urgency_for_high2事件严重级别为 High 时映射的 ServiceNow urgency 值。urgency_for_information3事件严重级别为 Information 时映射的 ServiceNow urgency 值。urgency_for_not_classified3事件严重级别为 Not classified 时映射的 ServiceNow urgency 值。urgency_for_warning3事件严重级别为 Warning 时映射的 ServiceNow urgency 值。从 media_servicenow.yaml 中的脚本逻辑可以看到urgency_for_*与严重级别的对应关系是通过severities数组not_classified/information/warning/average/high/disaster与EVENT.NSEVERITY数值0–5联动的脚本读取params[urgency_for_ severity_name]写入工单的urgency字段。也就是说你可以按需调整每个严重级别对应的 urgency例如把 Disaster 调成1最高紧急度而 Information 保持3。HTTP 代理支持每个 webhook 都支持 HTTP 代理。如需使用在媒体类型参数中新增一个名为http_proxy的参数值填写代理 URL 即可。脚本中对应逻辑为ServiceNow.setProxy(params.HTTPProxy)。内部参数以下参数为脚本预定义宏不建议修改它们承载事件上下文参数名值说明alert_message{ALERT.MESSAGE}动作配置中Default message默认消息的值。alert_subject{ALERT.SUBJECT}动作配置中Default subject默认主题的值。event_nseverity{EVENT.NSEVERITY}事件严重级别的数值0 – Not classified1 – Information2 – Warning3 – Average4 – High5 – Disaster。event_recovery_value{EVENT.RECOVERY.VALUE}恢复事件的数值。event_source{EVENT.SOURCE}事件来源数值0 – Trigger1 – Discovery2 – Autoregistration3 – Internal4 – Service。event_update_status{EVENT.UPDATE.STATUS}问题更新状态数值0 – Webhook 因问题/恢复事件被调用1 – 更新操作。event_value{EVENT.VALUE}触发动作的事件数值1 表示问题发生0 表示恢复。servicenow_sys_id{EVENT.TAGS.__zbx_servicenow_sys_id}已创建工单的 ServiceNow sys_id由脚本写入事件标签供恢复/更新时定位工单。这些参数与脚本中的输入校验一一对应。例如脚本会校验event_source必须在 0–3 范围内event_value在来源为 Trigger/Internal 时必须是 0 或 1event_update_status在 Trigger 来源下必须是 0 或 1当event_source不是 0非触发器且event_recovery_value为 0 时会直接抛出恢复操作仅支持触发器事件的错误——这正是官方文档recovery/update 仅支持 trigger 事件的底层实现。ServiceNow 端设置在开始 Zabbix 配置前需要先准备好 ServiceNow 侧的工作创建服务用户登录 ServiceNow 管理后台创建一个专门用于创建 incident 的系统用户不要使用个人账号授予角色给该用户分配两个角色rest_api_explorer允许通过 REST API 进行资源浏览与调用sn_incident_write允许创建/写入 incident 记录。该用户将作为 Zabbix webhook 调用 ServiceNow API 时的 Basic Auth 凭证来源脚本中以Authorization: Basic base64(user:password)头携带因此务必妥善保管其密码。Zabbix 端配置步骤第 1 步设置全局宏推荐建议先定义全局宏{$ZABBIX.URL}其值为 Zabbix 前端的 URL。该宏可在后续用于向 ServiceNow 自定义字段填充事件详情 / 图表的跳转链接。在 Zabbix 前端的Administration - General - Macros全局宏页面中配置第 2 步导入媒体类型在Administration - Media types管理 - 媒体类型中点击Import导入 media_servicenow.yaml。导入成功后即可看到名为ServiceNow的媒体类型类型为 Webhook模板中以type: WEBHOOK声明默认状态为DISABLED。第 3 步填充占位符参数打开ServiceNow媒体类型将PLACEHOLDERS替换为实际值以下三个参数必填servicenow_user前面创建的 ServiceNow 用户登录名servicenow_password该用户的密码servicenow_urlServiceNow 实例完整 URLhttps://\INSTANCE.service-now.com/。自定义字段导出若需要把信息写入 ServiceNow 的自定义字段可新增一个参数参数名使用自定义字段的 ID形如u_field_name参数值使用 Zabbix 宏。脚本会遍历所有以u_开头的参数将其逐项写入 incident 数据中见ServiceNow.setFields()。注意事项来自官方文档ServiceNow 实例时区必须与 Zabbix 服务器时区一致对Date/time 类型字段参数值需用空格分隔日期与时间例如{EVENT.DATE} {EVENT.TIME}对纯日期字段参数值仅允许包含返回日期的宏如{EVENT.DATE}、{EVENT.RECOVERY.DATE}脚本会自动把 Zabbix 的yyyy.MM.dd格式转换为 ServiceNow API 兼容的yyyy-MM-dd格式对应setFields中的正则^\d{4}\.\d{2}\.\d{2}$与replace(/\./g, -)如果不想让信息在 description 字段与自定义字段中重复可在Message templates消息模板页签中修改Problem、Problem recovery和Problem update三类消息模板。第 4 步创建 Zabbix 用户并配置媒体在 Zabbix 中创建一个用户Administration - Users为该用户添加Media媒体类型选择ServiceNow注意虽然 ServiceNow webhook 不使用Send to发送到字段但该字段不能留空否则无法通过前端校验——随意输入任意字符即可确保该用户对所有需要把告警转换为 ServiceNow 工单的主机都有访问权限否则这些主机的告警不会触发通知。第 5 步创建动作Action在Alerts - Actions - Trigger actions中创建动作绑定上述用户/媒体并设置操作operation使用 ServiceNow 媒体类型发送通知。动作中的默认主题与消息会分别映射到{ALERT.SUBJECT}和{ALERT.MESSAGE}进而写入工单的short_description简短描述、description描述与comments备注字段。消息模板工单内容的标准化导入的媒体类型自带一整套消息模板定义于 media_servicenow.yaml 的message_templates覆盖多类事件来源与操作模式TRIGGERS / PROBLEM主题Problem: {EVENT.NAME}正文包含问题开始时间、问题名、主机名、严重级别、操作数据、原始问题 ID 与触发器 URLTRIGGERS / RECOVERY主题Resolved in {EVENT.DURATION}: {EVENT.NAME}包含恢复耗时、恢复时间等TRIGGERS / UPDATE主题Updated problem in {EVENT.AGE}: {EVENT.NAME}包含更新人、更新动作、当前状态与确认状态DISCOVERY / PROBLEM网络发现事件模板包含设备 IP/DNS/状态/运行时长与服务信息AUTOREGISTRATION / PROBLEM自动注册事件模板INTERNAL / PROBLEM、RECOVERY内部事件模板SERVICE / PROBLEM、RECOVERY、UPDATE服务Service事件模板包含服务名、严重级别、根因描述等。这些模板决定了工单正文的信息结构你可以按团队规范自由增删宏。工单生命周期创建、恢复与更新的底层逻辑从 media_servicenow.yaml 的脚本可见完整的工单生命周期处理问题发生时POST 创建工单默认method post脚本把short_description、description、comments、urgency及自定义字段组装为 JSONPOST 到servicenow_url api/now/table/incident写入回传标签创建成功后脚本把返回结果写入事件标签__zbx_servicenow_sys_id工单 sys_id、__zbx_servicenow_link工单直达链接、__zbx_servicenow_number工单编号并以JSON.stringify(result)返回问题恢复或更新时PUT 更新工单当event_source 0触发器事件且event_value 0恢复或event_update_status 1更新时脚本将process_tags置为false、方法改为put、删除description与urgency并拼接servicenow_sys_id定位到既有工单后发送 PUT 请求事件菜单联动模板还启用了process_tags与show_event_menuevent_menu_url指向{EVENT.TAGS.__zbx_servicenow_link}event_menu_name显示为ServiceNow: {EVENT.TAGS.__zbx_servicenow_number}——即在 Zabbix 问题详情中可以直接看到并跳转到对应的 ServiceNow 工单。请求与错误处理脚本通过HttpRequest对象发起请求携带Content-Type: application/json与 Basic Auth 头若配置了http_proxy则通过代理发送。响应状态码不在 200–299 范围内或响应缺少result.sys_id时脚本会抛出带状态码与错误信息的异常并记录到 debug 日志Zabbix.log(4, ...)记录请求/响应详情Zabbix.log(3, ...)记录错误摘要。排障时可在媒体类型测试界面或Administration - Audit log中查看日志。TLS 校验细节CTlsConfig将tls_verify归一化后映射为两个底层选项SSLVerifyPeerpeer/full时启用与SSLVerifyHost仅full时启用并且当校验开启时checkURL()会强制要求 URL 为https://否则直接报错提示改用 HTTPS 或把{$HTTP.TLS.VERIFY}设为none——这能有效防止凭证在明文 HTTP 下泄露。告警执行链路与源码印证了解 webhook 在 Zabbix 内部的执行路径有助于定位为什么没收到工单这类问题动作触发src/zabbix_server/escalator/escalator.c在升级escalation流程中处理 webhook 通知从数据库取出 webhook 参数、对脚本与参数执行宏替换substitute_message_macros再通过zbx_webhook_params_pack_json把参数打包为 JSON 传入脚本执行escalator.c#L1508-L1540脚本执行alerter 进程的alerter_process_webhook()alerter.c#L475-L510反序列化 webhook 数据、初始化内嵌 JS 引擎zbx_es_init_env、设置超时与调试模式后调用zbx_es_execute运行脚本并把脚本输出/错误回传媒体类型注册webhook 作为媒体类型的一种在include/zbxdbhigh.h中以MEDIA_TYPE_WEBHOOK 4参与数据库存取include/zbxdbhigh.h#L265。因此一条告警从问题产生到ServiceNow 出现工单完整路径为事件 → 动作/升级escalator→ alerter 进程 → 内嵌 JS 引擎执行 webhook 脚本 → HTTP 调用 ServiceNow REST API → 写入事件标签回传 sys_id。常见问题与排障建议媒体类型导入后无法发送确认已把三个必填占位符user/password/url替换为真实值脚本对缺失的url/user/password会抛出Required ServiceNow param is not set: ...。TLS 校验报错若 URL 为http://而tls_verify未设为none脚本会拒绝请求——优先改用 HTTPS 实例地址。恢复/更新不生效确认事件来源为触发器trigger事件非触发器事件的恢复操作会被脚本直接拒绝。工单内容缺失自定义字段检查参数名是否以u_开头、字段 ID 是否正确、纯日期字段是否只包含日期类宏。时区与日期格式问题ServiceNow 实例与 Zabbix 服务器时区必须一致日期时间字段要用{EVENT.DATE} {EVENT.TIME}这种空格分隔格式。查看详细日志将媒体类型测试时的 debug 日志打开脚本以Zabbix.log(4, ...)输出请求与响应并结合 alerter 进程日志确认脚本执行结果。小结通过本指南你可以在 Zabbix 8.0 上完成 ServiceNow 的端到端集成导入官方 media_servicenow.yaml 媒体类型、配置三要素与 severity→urgency 映射、创建带媒体授权的用户与动作即可实现告警自动建单、恢复自动更新、问题详情一键跳转工单的完整闭环。结合本文给出的源码链路escalator → alerter → 内嵌 JS 引擎 → ServiceNow REST API当集成出现异常时你也可以从 Zabbix 内部执行路径出发快速定位问题。若在使用过程中遇到媒体类型本身的缺陷可到 Zabbix 官方支持站点support.zabbix.com提交 issue或在 Zabbix 官方论坛中讨论该媒体类型的设计与改进建议。赞分享指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载相关推荐Zabbix 8.0 与 Event-Driven Ansible 集成实战Webhook 媒体类型接入指南Zabbix 8.0 与 Event Driven Ansible 集成实战Webhook 媒体类型接入指南 本文基于 Zabbix 官方模板仓库中的 tem指标监控可观测性告警运维Zabbix 与 GitHub 集成指南使用 Webhook 媒体类型自动创建 IssueZabbix 与 GitHub 集成指南使用 Webhook 媒体类型自动创建 Issue 导读 本文讲解如何在 Zabbix 8.0 及以上版本中通过自带指标监控可观测性告警运维OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件 本篇技术指南以 OneUptime 官方可观测性后端运维前端云原生微服务AI Agent上一篇如何用3个核心问题理解Pixelle-VideoAI短视频生成的革命性突破下一篇You-Dont-Need-jQuery用原生 JavaScript 替代 jQuery 的完整实战指南西班牙语版导读创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/7 9:46:54 · 阅读 1.2k Zabbix 8.0 集成 ServiceNow Webhook 实战指南：从媒体类型导入到工单自动创建
指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载导读本文以 Zabbix 官方仓库中的 ServiceNow 集成模板为核心完整讲解如何借助 Zabbix 的 Webhook 媒体类型能力将 Zabbix 中的告警事件自动同步为 ServiceNow 平台上的 incident事件工单。阅读并实践本文后你将掌握ServiceNow 端服务用户与角色的创建、media_servicenow.yaml模板的导入与参数填充、Zabbix 用户与媒体配置、事件严重级别到 ServiceNow urgency 的映射以及恢复recovery与更新update操作对既有工单的联动逻辑最终形成一套可直接复用的监控告警闭环。概述Webhook 如何打通 Zabbix 与 ServiceNow本指南对应的官方集成模板位于仓库 templates/media/servicenow由两个核心文件组成README.md官方配置指南即本文主体内容的来源media_servicenow.yaml可直接导入 Zabbix 前端的 Webhook 媒体类型定义。集成的本质是Zabbix 的 Webhook 媒体类型内部执行一段 JavaScript 脚本把动作action中定义的通知内容拼装成 JSON 请求通过 ServiceNow 的POST /api/now/table/incidentREST API 创建 incident当问题恢复或问题被更新时脚本改为对.../incident/{sys_id}发送PUT请求从而更新既有工单。这种一个 webhook 同时覆盖创建与更新的设计正是该模板的核心价值。在 Zabbix 源码层面Webhook 媒体类型有明确的类型定义include/zbxdbhigh.h中的MEDIA_TYPE_WEBHOOK 4include/zbxdbhigh.h#L265通知的发送由 alerter 进程执行在 alerter.c 的alerter_process_webhook()中通过 Zabbix 内嵌的 JS 引擎zbx_es_*系列函数加载并执行 webhook 脚本最终将脚本返回的 JSON包含__zbx_servicenow_sys_id等标签回传给事件作为后续恢复/更新操作的依据。适用范围与限制官方文档明确了两点前提Zabbix 版本要求8.0 及以上模板zabbix_export.version同样标记为8.0恢复与更新操作、以及 ServiceNow 自定义字段custom fields仅对触发器trigger产生的事件有效。对应地模板脚本中只有在event_source为触发器事件时才执行工单恢复/更新的PUT逻辑。前置条件在开始配置前需要准备一台可访问的Zabbix 8.0 服务器Webhook 媒体类型依赖内嵌 JS 引擎与 alerter 进程需确认编译时已启用相应组件一个ServiceNow 实例instance并拥有管理权限用于创建工单的ServiceNow 服务账号及其密码Zabbix 服务器与 ServiceNow 实例之间的网络连通性HTTPS 出站。Webhook 参数详解导入媒体类型后可在媒体类型 - ServiceNow - 参数中查看和修改参数。模板脚本会读取全部参数以servicenow_开头的参数被提取为连接与工单核心配置以u_开头的参数被识别为 ServiceNow 自定义字段custom field其余预定义参数用于事件解析。可配置参数参数名默认值说明servicenow_password\PLACE PASSWORD HERE\ServiceNow 服务用户的密码。servicenow_url\PLACE URL HERE\ServiceNow 实例的完整 URL如https://\INSTANCE.service-now.com/脚本会自动拼接api/now/table/incident作为工单 REST 接口。servicenow_user\PLACE USERNAME HERE\ServiceNow 服务账号的用户名。tls_verify{$HTTP.TLS.VERIFY:ServiceNow}HTTP 请求的 TLS 证书校验策略none关闭校验peer校验证书链与有效期full进行完整校验同时校验主机名任何其他值都会被当作full。可通过定义上下文为ServiceNow的全局宏即{$HTTP.TLS.VERIFY:ServiceNow}针对该媒体类型单独覆盖。urgency_for_average2事件严重级别为 Average 时映射的 ServiceNow urgency 值。urgency_for_disaster1事件严重级别为 Disaster 时映射的 ServiceNow urgency 值。urgency_for_high2事件严重级别为 High 时映射的 ServiceNow urgency 值。urgency_for_information3事件严重级别为 Information 时映射的 ServiceNow urgency 值。urgency_for_not_classified3事件严重级别为 Not classified 时映射的 ServiceNow urgency 值。urgency_for_warning3事件严重级别为 Warning 时映射的 ServiceNow urgency 值。从 media_servicenow.yaml 中的脚本逻辑可以看到urgency_for_*与严重级别的对应关系是通过severities数组not_classified/information/warning/average/high/disaster与EVENT.NSEVERITY数值0–5联动的脚本读取params[urgency_for_ severity_name]写入工单的urgency字段。也就是说你可以按需调整每个严重级别对应的 urgency例如把 Disaster 调成1最高紧急度而 Information 保持3。HTTP 代理支持每个 webhook 都支持 HTTP 代理。如需使用在媒体类型参数中新增一个名为http_proxy的参数值填写代理 URL 即可。脚本中对应逻辑为ServiceNow.setProxy(params.HTTPProxy)。内部参数以下参数为脚本预定义宏不建议修改它们承载事件上下文参数名值说明alert_message{ALERT.MESSAGE}动作配置中Default message默认消息的值。alert_subject{ALERT.SUBJECT}动作配置中Default subject默认主题的值。event_nseverity{EVENT.NSEVERITY}事件严重级别的数值0 – Not classified1 – Information2 – Warning3 – Average4 – High5 – Disaster。event_recovery_value{EVENT.RECOVERY.VALUE}恢复事件的数值。event_source{EVENT.SOURCE}事件来源数值0 – Trigger1 – Discovery2 – Autoregistration3 – Internal4 – Service。event_update_status{EVENT.UPDATE.STATUS}问题更新状态数值0 – Webhook 因问题/恢复事件被调用1 – 更新操作。event_value{EVENT.VALUE}触发动作的事件数值1 表示问题发生0 表示恢复。servicenow_sys_id{EVENT.TAGS.__zbx_servicenow_sys_id}已创建工单的 ServiceNow sys_id由脚本写入事件标签供恢复/更新时定位工单。这些参数与脚本中的输入校验一一对应。例如脚本会校验event_source必须在 0–3 范围内event_value在来源为 Trigger/Internal 时必须是 0 或 1event_update_status在 Trigger 来源下必须是 0 或 1当event_source不是 0非触发器且event_recovery_value为 0 时会直接抛出恢复操作仅支持触发器事件的错误——这正是官方文档recovery/update 仅支持 trigger 事件的底层实现。ServiceNow 端设置在开始 Zabbix 配置前需要先准备好 ServiceNow 侧的工作创建服务用户登录 ServiceNow 管理后台创建一个专门用于创建 incident 的系统用户不要使用个人账号授予角色给该用户分配两个角色rest_api_explorer允许通过 REST API 进行资源浏览与调用sn_incident_write允许创建/写入 incident 记录。该用户将作为 Zabbix webhook 调用 ServiceNow API 时的 Basic Auth 凭证来源脚本中以Authorization: Basic base64(user:password)头携带因此务必妥善保管其密码。Zabbix 端配置步骤第 1 步设置全局宏推荐建议先定义全局宏{$ZABBIX.URL}其值为 Zabbix 前端的 URL。该宏可在后续用于向 ServiceNow 自定义字段填充事件详情 / 图表的跳转链接。在 Zabbix 前端的Administration - General - Macros全局宏页面中配置第 2 步导入媒体类型在Administration - Media types管理 - 媒体类型中点击Import导入 media_servicenow.yaml。导入成功后即可看到名为ServiceNow的媒体类型类型为 Webhook模板中以type: WEBHOOK声明默认状态为DISABLED。第 3 步填充占位符参数打开ServiceNow媒体类型将PLACEHOLDERS替换为实际值以下三个参数必填servicenow_user前面创建的 ServiceNow 用户登录名servicenow_password该用户的密码servicenow_urlServiceNow 实例完整 URLhttps://\INSTANCE.service-now.com/。自定义字段导出若需要把信息写入 ServiceNow 的自定义字段可新增一个参数参数名使用自定义字段的 ID形如u_field_name参数值使用 Zabbix 宏。脚本会遍历所有以u_开头的参数将其逐项写入 incident 数据中见ServiceNow.setFields()。注意事项来自官方文档ServiceNow 实例时区必须与 Zabbix 服务器时区一致对Date/time 类型字段参数值需用空格分隔日期与时间例如{EVENT.DATE} {EVENT.TIME}对纯日期字段参数值仅允许包含返回日期的宏如{EVENT.DATE}、{EVENT.RECOVERY.DATE}脚本会自动把 Zabbix 的yyyy.MM.dd格式转换为 ServiceNow API 兼容的yyyy-MM-dd格式对应setFields中的正则^\d{4}\.\d{2}\.\d{2}$与replace(/\./g, -)如果不想让信息在 description 字段与自定义字段中重复可在Message templates消息模板页签中修改Problem、Problem recovery和Problem update三类消息模板。第 4 步创建 Zabbix 用户并配置媒体在 Zabbix 中创建一个用户Administration - Users为该用户添加Media媒体类型选择ServiceNow注意虽然 ServiceNow webhook 不使用Send to发送到字段但该字段不能留空否则无法通过前端校验——随意输入任意字符即可确保该用户对所有需要把告警转换为 ServiceNow 工单的主机都有访问权限否则这些主机的告警不会触发通知。第 5 步创建动作Action在Alerts - Actions - Trigger actions中创建动作绑定上述用户/媒体并设置操作operation使用 ServiceNow 媒体类型发送通知。动作中的默认主题与消息会分别映射到{ALERT.SUBJECT}和{ALERT.MESSAGE}进而写入工单的short_description简短描述、description描述与comments备注字段。消息模板工单内容的标准化导入的媒体类型自带一整套消息模板定义于 media_servicenow.yaml 的message_templates覆盖多类事件来源与操作模式TRIGGERS / PROBLEM主题Problem: {EVENT.NAME}正文包含问题开始时间、问题名、主机名、严重级别、操作数据、原始问题 ID 与触发器 URLTRIGGERS / RECOVERY主题Resolved in {EVENT.DURATION}: {EVENT.NAME}包含恢复耗时、恢复时间等TRIGGERS / UPDATE主题Updated problem in {EVENT.AGE}: {EVENT.NAME}包含更新人、更新动作、当前状态与确认状态DISCOVERY / PROBLEM网络发现事件模板包含设备 IP/DNS/状态/运行时长与服务信息AUTOREGISTRATION / PROBLEM自动注册事件模板INTERNAL / PROBLEM、RECOVERY内部事件模板SERVICE / PROBLEM、RECOVERY、UPDATE服务Service事件模板包含服务名、严重级别、根因描述等。这些模板决定了工单正文的信息结构你可以按团队规范自由增删宏。工单生命周期创建、恢复与更新的底层逻辑从 media_servicenow.yaml 的脚本可见完整的工单生命周期处理问题发生时POST 创建工单默认method post脚本把short_description、description、comments、urgency及自定义字段组装为 JSONPOST 到servicenow_url api/now/table/incident写入回传标签创建成功后脚本把返回结果写入事件标签__zbx_servicenow_sys_id工单 sys_id、__zbx_servicenow_link工单直达链接、__zbx_servicenow_number工单编号并以JSON.stringify(result)返回问题恢复或更新时PUT 更新工单当event_source 0触发器事件且event_value 0恢复或event_update_status 1更新时脚本将process_tags置为false、方法改为put、删除description与urgency并拼接servicenow_sys_id定位到既有工单后发送 PUT 请求事件菜单联动模板还启用了process_tags与show_event_menuevent_menu_url指向{EVENT.TAGS.__zbx_servicenow_link}event_menu_name显示为ServiceNow: {EVENT.TAGS.__zbx_servicenow_number}——即在 Zabbix 问题详情中可以直接看到并跳转到对应的 ServiceNow 工单。请求与错误处理脚本通过HttpRequest对象发起请求携带Content-Type: application/json与 Basic Auth 头若配置了http_proxy则通过代理发送。响应状态码不在 200–299 范围内或响应缺少result.sys_id时脚本会抛出带状态码与错误信息的异常并记录到 debug 日志Zabbix.log(4, ...)记录请求/响应详情Zabbix.log(3, ...)记录错误摘要。排障时可在媒体类型测试界面或Administration - Audit log中查看日志。TLS 校验细节CTlsConfig将tls_verify归一化后映射为两个底层选项SSLVerifyPeerpeer/full时启用与SSLVerifyHost仅full时启用并且当校验开启时checkURL()会强制要求 URL 为https://否则直接报错提示改用 HTTPS 或把{$HTTP.TLS.VERIFY}设为none——这能有效防止凭证在明文 HTTP 下泄露。告警执行链路与源码印证了解 webhook 在 Zabbix 内部的执行路径有助于定位为什么没收到工单这类问题动作触发src/zabbix_server/escalator/escalator.c在升级escalation流程中处理 webhook 通知从数据库取出 webhook 参数、对脚本与参数执行宏替换substitute_message_macros再通过zbx_webhook_params_pack_json把参数打包为 JSON 传入脚本执行escalator.c#L1508-L1540脚本执行alerter 进程的alerter_process_webhook()alerter.c#L475-L510反序列化 webhook 数据、初始化内嵌 JS 引擎zbx_es_init_env、设置超时与调试模式后调用zbx_es_execute运行脚本并把脚本输出/错误回传媒体类型注册webhook 作为媒体类型的一种在include/zbxdbhigh.h中以MEDIA_TYPE_WEBHOOK 4参与数据库存取include/zbxdbhigh.h#L265。因此一条告警从问题产生到ServiceNow 出现工单完整路径为事件 → 动作/升级escalator→ alerter 进程 → 内嵌 JS 引擎执行 webhook 脚本 → HTTP 调用 ServiceNow REST API → 写入事件标签回传 sys_id。常见问题与排障建议媒体类型导入后无法发送确认已把三个必填占位符user/password/url替换为真实值脚本对缺失的url/user/password会抛出Required ServiceNow param is not set: ...。TLS 校验报错若 URL 为http://而tls_verify未设为none脚本会拒绝请求——优先改用 HTTPS 实例地址。恢复/更新不生效确认事件来源为触发器trigger事件非触发器事件的恢复操作会被脚本直接拒绝。工单内容缺失自定义字段检查参数名是否以u_开头、字段 ID 是否正确、纯日期字段是否只包含日期类宏。时区与日期格式问题ServiceNow 实例与 Zabbix 服务器时区必须一致日期时间字段要用{EVENT.DATE} {EVENT.TIME}这种空格分隔格式。查看详细日志将媒体类型测试时的 debug 日志打开脚本以Zabbix.log(4, ...)输出请求与响应并结合 alerter 进程日志确认脚本执行结果。小结通过本指南你可以在 Zabbix 8.0 上完成 ServiceNow 的端到端集成导入官方 media_servicenow.yaml 媒体类型、配置三要素与 severity→urgency 映射、创建带媒体授权的用户与动作即可实现告警自动建单、恢复自动更新、问题详情一键跳转工单的完整闭环。结合本文给出的源码链路escalator → alerter → 内嵌 JS 引擎 → ServiceNow REST API当集成出现异常时你也可以从 Zabbix 内部执行路径出发快速定位问题。若在使用过程中遇到媒体类型本身的缺陷可到 Zabbix 官方支持站点support.zabbix.com提交 issue或在 Zabbix 官方论坛中讨论该媒体类型的设计与改进建议。赞分享指标监控可观测性告警运维【免费下载链接】zabbixReal-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.项目地址https://gitcode.com/gh_mirrors/zabbix2/zabbix点击查看免费下载相关推荐Zabbix 8.0 与 Event-Driven Ansible 集成实战Webhook 媒体类型接入指南Zabbix 8.0 与 Event Driven Ansible 集成实战Webhook 媒体类型接入指南 本文基于 Zabbix 官方模板仓库中的 tem指标监控可观测性告警运维Zabbix 与 GitHub 集成指南使用 Webhook 媒体类型自动创建 IssueZabbix 与 GitHub 集成指南使用 Webhook 媒体类型自动创建 Issue 导读 本文讲解如何在 Zabbix 8.0 及以上版本中通过自带指标监控可观测性告警运维OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件 本篇技术指南以 OneUptime 官方可观测性后端运维前端云原生微服务AI Agent上一篇如何用3个核心问题理解Pixelle-VideoAI短视频生成的革命性突破下一篇You-Dont-Need-jQuery用原生 JavaScript 替代 jQuery 的完整实战指南西班牙语版导读创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考