OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南以 OneUptime 官方集成文档App/FeatureSet/Docs/Content/en/integrations/zabbix.md为核心完整讲解如何将 Zabbix 的告警问题自动转化为 OneUptime 事件。Zabbix 负责服务器与网络监控OneUptime 负责事件响应、值班On-Call与状态页——打通两者后每一个 Zabbix 问题都会自动变成一条 OneUptime 事件从而触发正确的人员通知并保持状态页的真实可信。读完本文你将能够独立完成Zabbix 侧 Webhook 媒体类型 OneUptime 侧 Workflow的整套配置并掌握事件自动解除、严重级别映射与常见故障排错方法。集成架构总览这是一条单向inbound集成数据只从 Zabbix 流向 OneUptime不需要安装任何插件或额外服务。整个链路由两侧组成Zabbix 侧一个基于 Webhook 的媒体类型Media type负责把触发器事件打包成 JSON 载荷OneUptime 侧一个以Webhook 为触发器trigger的Workflow负责接收载荷、判断状态并创建事件。数据流可以概括为Zabbix trigger fires ──► Webhook media type ──► OneUptime Workflow (Webhook trigger) ──► Create Incident工作流程分解Zabbix 中的某个触发器trigger切换到PROBLEM问题状态Zabbix 中配置的action通知名为OneUptime的媒体类型发送事件媒体类型中的脚本将一个精简 JSON 载荷 POST 到 OneUptime Workflow 的 Webhook 地址Workflow 读取载荷并创建事件可选地当 Zabbix 恢复recovery时自动解除resolve该事件。从 OneUptime 侧看Webhook 触发器的接收机制定义在 App/FeatureSet/Workflow/Docs/ComponentDocumentation/Webhook.md 中该触发器为每个工作流生成一个唯一 URLURL 形如{{serverUrl}}workflow/trigger/{{webhookSecretKey}}其中webhookSecretKey是该工作流专属的密钥可在工作流设置页中重置。该 URL 同时接受GET与POST请求的头部、查询参数与请求体都会被传入下游组件。前置条件一个你可管理 Zabbix 服务器本指南针对Zabbix 6.0 LTS / 7.0 LTS编写Webhook 媒体类型在 5.0 及以上版本中行为一致Zabbix 服务器能够通过HTTPS访问你的 OneUptime 实例一个你可以在其中创建工作流的 OneUptime 项目。第一部分 —— 构建 OneUptime Workflow务必先完成这一部分因为后续 Zabbix 配置需要用到它生成的 Webhook 地址。打开Workflows → Create Workflow命名为Zabbix → Incidents进入Builder画布标签页。将Webhook触发器拖到画布上点击它并复制其显示的独特 URL。请妥善保管——任何持有该 URL 的人都能触发工作流。将块重命名为Zabbix这样后续变量引用会更具可读性例如{{Zabbix.Request Body.status}}。拖入一个Conditions条件块将触发器的输出连接到它并按如下配置Left value左值{{Zabbix.Request Body.status}}Operator操作符Right value右值1Zabbix 对问题发送1对恢复发送0拖入一个Create Incident创建事件块连接到 Conditions 块的Yes输出并填写TitleZabbix: {{Zabbix.Request Body.name}}DescriptionHost: {{Zabbix.Request Body.host}}\nSeverity: {{Zabbix.Request Body.severity}}\nZabbix event: {{Zabbix.Request Body.event_id}}Severity选择你期望的 OneUptime 事件严重级别后续可用更多 Conditions 分支映射 Zabbix 严重级别来细化。保存。暂时保持Enabled为关闭状态——测试通过后再开启。提示将 Zabbix 的event_id写入事件描述或事件标签中可以让你在需要自动解除时再次定位到该事件。详见下文自动解除可选一节。Workflow 概念速览Workflow 是 OneUptime 中无需编写代码即可实现的自动化能力详见 App/FeatureSet/Docs/Content/en/workflows/index.md。每个工作流由三部分组成触发器Trigger——决定工作流何时运行每个工作流有且仅有一个触发器组件Component——工作流执行的具体动作发消息、调 API、做判断、分支等连接Connections——画布上块之间的连线决定执行顺序。Webhook 触发器属于四种触发器之一其余为 Manual 手动、Schedule 定时、OneUptime event 事件触发其输出包含Request Headers、Request Query Params与Request Body三部分正好对应本集成中读取 Zabbix 载荷所需的数据结构。第二部分 —— 配置 Zabbix步骤 1创建 OneUptime 媒体类型在 Zabbix 中进入Alerts → Media types旧版本为Administration → Media types。点击Create media type将Type设为Webhook。Name填OneUptime。添加以下Parameters每项点击Add。这些参数将 Zabbix 宏macros 映射为干净整洁的载荷名称值url{ALERT.SENDTO}event_id{EVENT.ID}event_name{EVENT.NAME}event_value{EVENT.VALUE}event_severity{EVENT.SEVERITY}host{HOST.NAME}event_date{EVENT.DATE}event_time{EVENT.TIME}其中{ALERT.SENDTO}会被替换为用户媒体配置中Send to字段的值——也就是第一步中复制的 Webhook 地址。将以下脚本粘贴到Script字段中var params JSON.parse(value); var request new HttpRequest(); request.addHeader(Content-Type: application/json); var payload { source: zabbix, event_id: params.event_id, name: params.event_name, host: params.host, severity: params.event_severity, // 1 problem, 0 recovered. OneUptime reads this in a Conditions block. status: params.event_value, date: params.event_date, time: params.event_time, }; var response request.post(params.url, JSON.stringify(payload)); if (request.getStatus() 200 || request.getStatus() 300) { throw ( OneUptime responded with HTTP request.getStatus() : response ); } return OK;脚本要点说明value是 Zabbix Webhook 媒体类型运行时注入的 JSON 字符串包含上一步定义的全部参数构造的payload中status字段直接取自{EVENT.VALUE}1表示问题、0表示恢复OneUptime 侧正是通过 Conditions 块读取该字段分流非 2xx 响应会通过throw抛出错误便于在 Zabbix 侧直接看到失败原因。点击Message templates标签页为Problem与Problem recovery各添加一个模板正文可以为空——载荷已在脚本中构造。这是 Zabbix 在这些事件类型上启用该媒体类型的必要条件。点击Add保存媒体类型。步骤 2创建承载 Webhook 的用户Zabbix 的通知是发送给用户的。创建一个专用用户让集成易于查找和停用。进入Users → Users → Create user命名为OneUptime Webhook为其分配可以接收通知的角色例如User role并加入一个用户组。在Media标签页点击AddTypeOneUptimeSend to粘贴第一步中复制的工作流 Webhook 地址。When active/ 严重级别保持默认或按需限制为你关心的严重级别。点击Add然后Update保存。步骤 3通过 action 将问题发送到 OneUptime进入Alerts → Actions → Trigger actions → Create action。NameNotify OneUptime。Conditions可选按需收窄范围——例如Trigger severity Warning。留空则发送所有事件。在Operations标签页添加一个操作通过OneUptime媒体类型发送给User: OneUptime Webhook。若希望后续在恢复时自动解除事件同时用相同的用户/媒体类型填写Recovery operations。点击Add保存并确保该 action 处于Enabled状态。第三部分 —— 测试集成回到 OneUptime 工作流将Enabled打开。在 Zabbix 中触发一个测试问题——例如临时降低某个触发器的阈值或使用一个会翻转为问题状态的测试监控项。打开工作流的Logs日志标签页。你应该看到一次带有 Zabbix 载荷的运行记录、Conditions 块走了Yes分支以及事件被创建的过程。在 OneUptime 中检查Incidents——你的 Zabbix 问题现在就是一条事件了。如果什么都没有到达参见下方的故障排查章节。关于日志与运行记录Workflow 的每次执行Run都会被保存包含时间戳与每个块的输出参见 App/FeatureSet/Docs/Content/en/workflows/index.md 与 Runs Logs。当排错事件创建了但字段为空或工作流从未运行时运行日志是最直接的证据来源——它可以显示触发器的原始输出、每个条件的判定路径以及组件执行结果。自动解除可选上述核心工作流只负责打开事件。若希望在 Zabbix 恢复时自动关闭事件请按以下步骤操作确保你的 Zabbix action 配置了Recovery operations见上文步骤 3以便恢复事件也被发送。恢复时status的值为0。在工作流中新增第二个Conditions分支左值{{Zabbix.Request Body.status}}操作符右值0。从其Yes输出连接一个Find Incident块查找之前创建的未关闭事件——基于你存储在描述或标签中的 Zabbixevent_id进行匹配。将其连接到Update Incident块把事件移动到你的已解决resolved状态。由于解除逻辑取决于你在项目中如何建模事件状态请始终将创建路径作为可靠核心待确认事件流正常后再叠加解除路径。相关 OneUptime 数据组件Find/Update Incident的详细说明见 Components → OneUptime data components。数据组件的查询语义OneUptime 数据组件如 Find One Incident、Update One Incident的字段基于记录自身的列名column names——即 API 使用的名字而非仪表盘表单上的标签。ID 列为_id。Query 决定组件操作哪些记录键为列名、值为匹配目标例如{ monitorType: Website, isEnabled: true }查询始终限定在工作流所属的项目范围内无需在查询中手动添加项目条件来源App/FeatureSet/Docs/Content/en/workflows/components.md。映射 Zabbix 严重级别可选Zabbix 严重级别Not classified、Information、Warning、Average、High、Disaster会以{{Zabbix.Request Body.severity}}的形式到达。要将其映射到 OneUptime 事件严重级别请在Create Incident之前添加Conditions分支——例如将Disaster与High路由到Critical严重事件其余路由到Major主要事件。每个分支各构建一个Create Incident块。故障排查工作流从未运行。确认工作流的Enabled开关已打开从 Zabbix 服务器验证其能访问该地址curl -i -X POST workflow-url -d {} -H Content-Type: application/json应能收到快速确认响应在 Zabbix 中检查Reports → Action log查看投递错误。Zabbix 报告脚本错误。打开媒体类型使用Test发送样例载荷Zabbix 会显示脚本输出或抛出的错误脚本中的throw会暴露 OneUptime 返回的非 2xx 响应——检查工作流地址是否完全正确。事件已创建但字段为空。打开工作流的Logs标签页并检查触发器输出。确认Request Body下的字段名与你引用的名字一致name、host、severity、status、event_id缺失的字段会解析为空字符串而非报错——参见 Variables → Gotchas。所有事件触发两次。很可能问题操作与升级步骤escalation step同时发送到同一媒体。检查 action 的Operations步骤。变量引用注意事项在 Workflow 中引用变量时详见 App/FeatureSet/Docs/Content/en/workflows/variables.md有几个容易踩坑的细节使用选择器pickers在编辑器中用组件值选择器插入引用而非手打——它能插入运行器期望的准确组件 ID 与返回值 ID变量名区分大小写{{global.variables.MyKey}}与{{global.variables.mykey}}是不同的无法解析的引用会原样保留引用不存在的内容不是错误也不会得到空字符串花括号会被原样传递运行日志会给出警告行花括号内的空格不会被裁剪{{ local.variables.NAME }}与{{local.variables.NAME}}是不同的查找永远不会解析。安全注意事项将工作流 Webhook 地址视为密码。一旦泄露删除该触发器并新建一个以轮换地址限制 Zabbix action 的条件只转发值得产生一条事件的那些严重级别如果你自托管 OneUptime 且位于防火墙之后请允许 Zabbix 服务器的出口 IP 通过 HTTPS 访问它。进一步阅读Integrations Overview —— 输入/输出集成模式Webhook trigger —— 接收地址的工作方式Components —— Conditions、Create Incident 等组件Variables —— 在后续块中读取 Zabbix 载荷。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 与 Zabbix 集成实战：通过 Webhook 媒体类型与 Workflow 自动创建与解除事件
OneUptime 与 Zabbix 集成实战通过 Webhook 媒体类型与 Workflow 自动创建与解除事件【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南以 OneUptime 官方集成文档App/FeatureSet/Docs/Content/en/integrations/zabbix.md为核心完整讲解如何将 Zabbix 的告警问题自动转化为 OneUptime 事件。Zabbix 负责服务器与网络监控OneUptime 负责事件响应、值班On-Call与状态页——打通两者后每一个 Zabbix 问题都会自动变成一条 OneUptime 事件从而触发正确的人员通知并保持状态页的真实可信。读完本文你将能够独立完成Zabbix 侧 Webhook 媒体类型 OneUptime 侧 Workflow的整套配置并掌握事件自动解除、严重级别映射与常见故障排错方法。集成架构总览这是一条单向inbound集成数据只从 Zabbix 流向 OneUptime不需要安装任何插件或额外服务。整个链路由两侧组成Zabbix 侧一个基于 Webhook 的媒体类型Media type负责把触发器事件打包成 JSON 载荷OneUptime 侧一个以Webhook 为触发器trigger的Workflow负责接收载荷、判断状态并创建事件。数据流可以概括为Zabbix trigger fires ──► Webhook media type ──► OneUptime Workflow (Webhook trigger) ──► Create Incident工作流程分解Zabbix 中的某个触发器trigger切换到PROBLEM问题状态Zabbix 中配置的action通知名为OneUptime的媒体类型发送事件媒体类型中的脚本将一个精简 JSON 载荷 POST 到 OneUptime Workflow 的 Webhook 地址Workflow 读取载荷并创建事件可选地当 Zabbix 恢复recovery时自动解除resolve该事件。从 OneUptime 侧看Webhook 触发器的接收机制定义在 App/FeatureSet/Workflow/Docs/ComponentDocumentation/Webhook.md 中该触发器为每个工作流生成一个唯一 URLURL 形如{{serverUrl}}workflow/trigger/{{webhookSecretKey}}其中webhookSecretKey是该工作流专属的密钥可在工作流设置页中重置。该 URL 同时接受GET与POST请求的头部、查询参数与请求体都会被传入下游组件。前置条件一个你可管理 Zabbix 服务器本指南针对Zabbix 6.0 LTS / 7.0 LTS编写Webhook 媒体类型在 5.0 及以上版本中行为一致Zabbix 服务器能够通过HTTPS访问你的 OneUptime 实例一个你可以在其中创建工作流的 OneUptime 项目。第一部分 —— 构建 OneUptime Workflow务必先完成这一部分因为后续 Zabbix 配置需要用到它生成的 Webhook 地址。打开Workflows → Create Workflow命名为Zabbix → Incidents进入Builder画布标签页。将Webhook触发器拖到画布上点击它并复制其显示的独特 URL。请妥善保管——任何持有该 URL 的人都能触发工作流。将块重命名为Zabbix这样后续变量引用会更具可读性例如{{Zabbix.Request Body.status}}。拖入一个Conditions条件块将触发器的输出连接到它并按如下配置Left value左值{{Zabbix.Request Body.status}}Operator操作符Right value右值1Zabbix 对问题发送1对恢复发送0拖入一个Create Incident创建事件块连接到 Conditions 块的Yes输出并填写TitleZabbix: {{Zabbix.Request Body.name}}DescriptionHost: {{Zabbix.Request Body.host}}\nSeverity: {{Zabbix.Request Body.severity}}\nZabbix event: {{Zabbix.Request Body.event_id}}Severity选择你期望的 OneUptime 事件严重级别后续可用更多 Conditions 分支映射 Zabbix 严重级别来细化。保存。暂时保持Enabled为关闭状态——测试通过后再开启。提示将 Zabbix 的event_id写入事件描述或事件标签中可以让你在需要自动解除时再次定位到该事件。详见下文自动解除可选一节。Workflow 概念速览Workflow 是 OneUptime 中无需编写代码即可实现的自动化能力详见 App/FeatureSet/Docs/Content/en/workflows/index.md。每个工作流由三部分组成触发器Trigger——决定工作流何时运行每个工作流有且仅有一个触发器组件Component——工作流执行的具体动作发消息、调 API、做判断、分支等连接Connections——画布上块之间的连线决定执行顺序。Webhook 触发器属于四种触发器之一其余为 Manual 手动、Schedule 定时、OneUptime event 事件触发其输出包含Request Headers、Request Query Params与Request Body三部分正好对应本集成中读取 Zabbix 载荷所需的数据结构。第二部分 —— 配置 Zabbix步骤 1创建 OneUptime 媒体类型在 Zabbix 中进入Alerts → Media types旧版本为Administration → Media types。点击Create media type将Type设为Webhook。Name填OneUptime。添加以下Parameters每项点击Add。这些参数将 Zabbix 宏macros 映射为干净整洁的载荷名称值url{ALERT.SENDTO}event_id{EVENT.ID}event_name{EVENT.NAME}event_value{EVENT.VALUE}event_severity{EVENT.SEVERITY}host{HOST.NAME}event_date{EVENT.DATE}event_time{EVENT.TIME}其中{ALERT.SENDTO}会被替换为用户媒体配置中Send to字段的值——也就是第一步中复制的 Webhook 地址。将以下脚本粘贴到Script字段中var params JSON.parse(value); var request new HttpRequest(); request.addHeader(Content-Type: application/json); var payload { source: zabbix, event_id: params.event_id, name: params.event_name, host: params.host, severity: params.event_severity, // 1 problem, 0 recovered. OneUptime reads this in a Conditions block. status: params.event_value, date: params.event_date, time: params.event_time, }; var response request.post(params.url, JSON.stringify(payload)); if (request.getStatus() 200 || request.getStatus() 300) { throw ( OneUptime responded with HTTP request.getStatus() : response ); } return OK;脚本要点说明value是 Zabbix Webhook 媒体类型运行时注入的 JSON 字符串包含上一步定义的全部参数构造的payload中status字段直接取自{EVENT.VALUE}1表示问题、0表示恢复OneUptime 侧正是通过 Conditions 块读取该字段分流非 2xx 响应会通过throw抛出错误便于在 Zabbix 侧直接看到失败原因。点击Message templates标签页为Problem与Problem recovery各添加一个模板正文可以为空——载荷已在脚本中构造。这是 Zabbix 在这些事件类型上启用该媒体类型的必要条件。点击Add保存媒体类型。步骤 2创建承载 Webhook 的用户Zabbix 的通知是发送给用户的。创建一个专用用户让集成易于查找和停用。进入Users → Users → Create user命名为OneUptime Webhook为其分配可以接收通知的角色例如User role并加入一个用户组。在Media标签页点击AddTypeOneUptimeSend to粘贴第一步中复制的工作流 Webhook 地址。When active/ 严重级别保持默认或按需限制为你关心的严重级别。点击Add然后Update保存。步骤 3通过 action 将问题发送到 OneUptime进入Alerts → Actions → Trigger actions → Create action。NameNotify OneUptime。Conditions可选按需收窄范围——例如Trigger severity Warning。留空则发送所有事件。在Operations标签页添加一个操作通过OneUptime媒体类型发送给User: OneUptime Webhook。若希望后续在恢复时自动解除事件同时用相同的用户/媒体类型填写Recovery operations。点击Add保存并确保该 action 处于Enabled状态。第三部分 —— 测试集成回到 OneUptime 工作流将Enabled打开。在 Zabbix 中触发一个测试问题——例如临时降低某个触发器的阈值或使用一个会翻转为问题状态的测试监控项。打开工作流的Logs日志标签页。你应该看到一次带有 Zabbix 载荷的运行记录、Conditions 块走了Yes分支以及事件被创建的过程。在 OneUptime 中检查Incidents——你的 Zabbix 问题现在就是一条事件了。如果什么都没有到达参见下方的故障排查章节。关于日志与运行记录Workflow 的每次执行Run都会被保存包含时间戳与每个块的输出参见 App/FeatureSet/Docs/Content/en/workflows/index.md 与 Runs Logs。当排错事件创建了但字段为空或工作流从未运行时运行日志是最直接的证据来源——它可以显示触发器的原始输出、每个条件的判定路径以及组件执行结果。自动解除可选上述核心工作流只负责打开事件。若希望在 Zabbix 恢复时自动关闭事件请按以下步骤操作确保你的 Zabbix action 配置了Recovery operations见上文步骤 3以便恢复事件也被发送。恢复时status的值为0。在工作流中新增第二个Conditions分支左值{{Zabbix.Request Body.status}}操作符右值0。从其Yes输出连接一个Find Incident块查找之前创建的未关闭事件——基于你存储在描述或标签中的 Zabbixevent_id进行匹配。将其连接到Update Incident块把事件移动到你的已解决resolved状态。由于解除逻辑取决于你在项目中如何建模事件状态请始终将创建路径作为可靠核心待确认事件流正常后再叠加解除路径。相关 OneUptime 数据组件Find/Update Incident的详细说明见 Components → OneUptime data components。数据组件的查询语义OneUptime 数据组件如 Find One Incident、Update One Incident的字段基于记录自身的列名column names——即 API 使用的名字而非仪表盘表单上的标签。ID 列为_id。Query 决定组件操作哪些记录键为列名、值为匹配目标例如{ monitorType: Website, isEnabled: true }查询始终限定在工作流所属的项目范围内无需在查询中手动添加项目条件来源App/FeatureSet/Docs/Content/en/workflows/components.md。映射 Zabbix 严重级别可选Zabbix 严重级别Not classified、Information、Warning、Average、High、Disaster会以{{Zabbix.Request Body.severity}}的形式到达。要将其映射到 OneUptime 事件严重级别请在Create Incident之前添加Conditions分支——例如将Disaster与High路由到Critical严重事件其余路由到Major主要事件。每个分支各构建一个Create Incident块。故障排查工作流从未运行。确认工作流的Enabled开关已打开从 Zabbix 服务器验证其能访问该地址curl -i -X POST workflow-url -d {} -H Content-Type: application/json应能收到快速确认响应在 Zabbix 中检查Reports → Action log查看投递错误。Zabbix 报告脚本错误。打开媒体类型使用Test发送样例载荷Zabbix 会显示脚本输出或抛出的错误脚本中的throw会暴露 OneUptime 返回的非 2xx 响应——检查工作流地址是否完全正确。事件已创建但字段为空。打开工作流的Logs标签页并检查触发器输出。确认Request Body下的字段名与你引用的名字一致name、host、severity、status、event_id缺失的字段会解析为空字符串而非报错——参见 Variables → Gotchas。所有事件触发两次。很可能问题操作与升级步骤escalation step同时发送到同一媒体。检查 action 的Operations步骤。变量引用注意事项在 Workflow 中引用变量时详见 App/FeatureSet/Docs/Content/en/workflows/variables.md有几个容易踩坑的细节使用选择器pickers在编辑器中用组件值选择器插入引用而非手打——它能插入运行器期望的准确组件 ID 与返回值 ID变量名区分大小写{{global.variables.MyKey}}与{{global.variables.mykey}}是不同的无法解析的引用会原样保留引用不存在的内容不是错误也不会得到空字符串花括号会被原样传递运行日志会给出警告行花括号内的空格不会被裁剪{{ local.variables.NAME }}与{{local.variables.NAME}}是不同的查找永远不会解析。安全注意事项将工作流 Webhook 地址视为密码。一旦泄露删除该触发器并新建一个以轮换地址限制 Zabbix action 的条件只转发值得产生一条事件的那些严重级别如果你自托管 OneUptime 且位于防火墙之后请允许 Zabbix 服务器的出口 IP 通过 HTTPS 访问它。进一步阅读Integrations Overview —— 输入/输出集成模式Webhook trigger —— 接收地址的工作方式Components —— Conditions、Create Incident 等组件Variables —— 在后续块中读取 Zabbix 载荷。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考