OneUptime 集成指南基于 Workflows 自动化引擎打通 Zabbix、Jira、Slack 等外部工具【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeOneUptime 通过内置的自动化引擎Workflows与团队已有的工具生态Zabbix、Jira、PagerDuty、Slack 等连接无需安装任何独立插件你只需在拖拽画布上把集成拼装起来它便会在事件发生时自动运行。本文围绕 App/FeatureSet/Docs/Content/da/integrations/index.md 阐述集成所依赖的入站Inbound与出站Outbound两大模式并结合仓库源码与配套文档给出秘密管理、认证方案与自托管网络要求等完整实操细节。读完本文你将掌握用 Workflows 连接任何具备 Webhook 或 REST API 的工具的方法即使该工具在官方目录中并没有专属页面。一切集成的根基Workflows 自动化引擎所有集成都构建在Workflows之上。用官方文档的话说Workflows 就是 OneUptime 内置的自动化引擎——把几个块放到画布上、用连线连接起来自动化就会在事故开启、定时触发或外部工具向 OneUptime 推送数据时运行。在 App/FeatureSet/Docs/Content/en/workflows/index.md 中每个 Workflow 由三部分组成触发器Trigger——决定工作流何时运行每个工作流有且只有一个触发器。一个或多个组件Component——工作流执行的动作发消息、发 HTTP 请求、跑一段检查、按条件分支。连接Connections——在画布上从一个块连到下一个块的连线决定执行顺序。从源码结构看OneUptime 的 Workflow 引擎位于 App/FeatureSet/Workflow其中 App/FeatureSet/Workflow/Services/RunWorkflow.ts 与 App/FeatureSet/Workflow/Services/QueueWorkflow.ts 负责工作流的排队与执行App/FeatureSet/Workflow/API/ComponentCode.ts 承载组件逻辑印证了工作流在后台队列中异步运行的设计。你可以把 Workflows 理解为项目的后台助手响应事件、与其他工具对话、在你不干预的情况下保持数据同步。触发器的四种类型在 App/FeatureSet/Docs/Content/en/workflows/triggers.md 中工作流可以从四种触发器中选择这也直接决定了集成的启动方式触发器触发时机典型场景Manual手动点击Run Workflow按钮填入 JSON 载荷轮换密钥发送测试告警这类一键自动化Schedule定时按 cron 表达式周期执行如0 * * * *每小时整点、*/5 * * * *每 5 分钟、0 9 * * 1每周一 9:00夜间清理、每小时同步、每周报告Webhook任何对 OneUptime 生成的唯一 URL 的访问接收外部工具推送的数据CI/CD 回调、其他监控系统的告警、CRM 注册事件OneUptime 事件监控、事故、告警、计划维护、状态页、值班策略、团队等对象的On Create / On Update / On DeleteOneUptime 里发生 X 就执行 Y无需轮询对于 Webhook 触发器请求的头信息、查询参数与请求体都会被传入工作流URL 同时接受GET与POST调用方会立刻收到确认而工作流本身在后台运行。文档明确警告要把这个 URL 当作密码对待——任何拿到它的人都可以启动你的工作流。两大集成模式每一种集成本质上都是把数据沿两个方向之一搬运很多集成两个方向都用到。这是整个集成目录背后的统一抽象理解它之后你可以把 OneUptime 连接到几乎任何工具。入站模式Inbound外部工具把数据送进 OneUptime当外部系统需要在 OneUptime创建或更新某些内容——典型场景是检测到问题时开启事故或告警——使用入站模式。标准三步构建一个以Webhook 触发器开头的工作流OneUptime 会给你一个唯一 URL。在外部工具里配置 webhook/通知动作在事件发生时向该 URL 发送POST。在工作流中读取传入的 payload用Create Incident或 Create Alert组件记录事故。Zabbix / Prometheus / Grafana / Datadog ──► OneUptime Webhook trigger ──► Create Incident技巧对于告警类工具Incoming Request 监控器通常是更好的入站路径。它无需构建工作流就能给你一个 webhook URL按 payload 中的每条告警开一个事故、升级到值班策略并在工具报告恢复时自动解决每条事故。当你需要 OneUptime 原生不提供的逻辑时再使用工作流。完整的实践示例见 Prometheus Alertmanager 集成。关于 Incoming Request 监控器官方文档补充了几个关键事实它提供https://oneuptime.com/heartbeat/YOUR_SECRET_KEY格式的唯一 URL支持GET/POSTHEAD按GET处理路径中的密钥是唯一凭证。OneUptime 会立即返回空的200并在队列中处理请求——注意200并不代表请求被接受密钥错误、监控器被删除或禁用同样返回200。body 需使用Content-Type: application/json才会被解析为可用字段。出站模式OutboundOneUptime 把数据送到外部工具当 OneUptime 里的某些内容需要在另一个工具中呈现——打开一张 Jira 工单、在 PagerDuty 里找人、往 Slack 发帖——使用出站模式。标准三步构建一个以OneUptime 事件触发器开头的工作流——例如Incident → On Create。添加一个API 组件用事故的详细信息调用对方工具的 REST API。把所有 API 密钥存为秘密Secret全局变量确保它们永远不会出现在工作流或其日志中。OneUptime Incident → On Create ──► API component ──► Jira / PagerDuty / ServiceNow / GitHub在 App/FeatureSet/Docs/Content/en/workflows/components.md 中API 组件支持GET、POST、PUT、PATCH、DELETE五种方法可自定义 URL、Headers 与 Body其Success输出在收到 2xx 响应时触发并传递状态码、响应头与响应体Error输出在网络失败或非 2xx 时触发并传递错误信息。事件触发器会把完整记录传给下一个块——例如Incident → On Create触发器把新事故完整传下去下一个块可以直接读取它的标题、描述、严重级别等任意字段。集成目录与方向速查原文档的目录表完整列出官方维护的集成及其数据流方向整理如下工具方向作用Zabbix入站把 Zabbix 问题变成 OneUptime 事故并在恢复时解决它们Jira出站入站每条事故打开一张 Jira 工单状态同步回来PagerDuty出站入站从 OneUptime 事故触发并解决 PagerDuty 事件Opsgenie出站入站创建并关闭 Opsgenie 告警ServiceNow出站入站从 OneUptime 打开 ServiceNow 事故Microsoft Dynamics 365出站入站从 OneUptime 事故打开并解决 Dynamics 365 CasesPrometheus Alertmanager入站把 Alertmanager 通知转换为事故Grafana入站把 Grafana 告警转换为事故Datadog入站把 Datadog 监控告警转换为事故GitHub出站为事故打开一张 GitHub issueGitLab出站为事故打开一张 GitLab issueDiscord出站把事故更新发到 Discord 频道Telegram出站把事故更新发到 Telegram 聊天Slack双向原生 workspace 连接——频道、告警与值班Microsoft Teams双向原生 workspace 连接Slack 与 Microsoft Teams拥有超越工作流的更深层原生连接——自动事故频道、双向操作与值班通知。这两类工具请使用 Slack 与 Microsoft Teams 的 workspace 连接而不是构建工作流。秘密管理API 密钥永远不要写进块里原文档给出的铁律是绝不把 API 密钥或 token 直接粘贴进某个块。正确做法分三步进入Workflows → Global Variables全局变量。创建一个变量——例如JIRA_AUTH——并打开Secret开关。在任何地方用{{global.variables.JIRA_AUTH}}引用它。秘密变量在保存后会从 UI 中隐藏并且会从运行日志中被清除scrubbed。这在 App/FeatureSet/Docs/Content/en/workflows/variables.md 中有更完整的定义每个全局变量包含 Name至少两个字符、无空格、仅限字母数字连字符与下划线、Description可选、Secret开启后从运行日志与步骤追踪中清除、Content长文本字段支持多行值。引用语法为{{global.variables.NAME}}例如把 PagerDuty 密钥存为PAGERDUTY_KEY后任何块都能以{{global.variables.PAGERDUTY_KEY}}使用它。该文档还指出了几个值得注意的坑变量只能创建和删除不能编辑——要在 UI 中改值需要删除后重建或通过 API 更新。变量名区分大小写{{global.variables.MyKey}}与{{global.variables.mykey}}是两个不同的查找。未解析的引用会原样传过去而不是置空——拼错的引用会逐字出现在 Slack 消息、URL 或请求体里运行仍显示Executed只有运行日志中的警告行会点名该引用。花括号内的空格不会被修剪{{ local.variables.NAME }}永远无法解析。此外工作流还支持局部工作流变量{{local.variables.NAME}}与组件输出引用{{local.components.COMPONENT_ID.returnValues.FIELD_ID}}。在编辑器里应尽量使用**取值器picker**插入引用它会插入运行器期望的精确 id并让引用不依赖显示标签。认证速查表六种常见 Authorization 方案大多数出站集成需要在 API 块上设置Authorization请求头。原文档总结了六种常见形式方案Header 值适用工具Bearer tokenBearer {{global.variables.TOKEN}}GitHub 及许多现代 APIBasic authBasic {{global.variables.BASE64_USER_PASS}}Jira Cloud、ServiceNowAPI 密钥 headerGenieKey {{global.variables.OPSGENIE_KEY}}OpsgenieBody 中的 tokenJSON body 中的routing_key字段PagerDuty Events APIPrivate token headerPRIVATE-TOKEN: {{global.variables.GITLAB_TOKEN}}GitLabOAuth 2.0 client credentialsBearer 由前置 API 块获取的 tokenMicrosoft Dynamics 365 (Dataverse)对于 Basic auth你需要把username:password或email:api_token一次性base64 编码然后把结果存为秘密变量。在 macOS/Linux 上printf %s youexample.com:your_api_token | base64Jira 集成文档特别强调了一个细节必须使用printf而不是echo——echo会追加换行符换行符会连同其余内容一起被编码导致 Jira 返回401。此外Atlassian API token 会过期默认有效期一年、无刷新机制过期后需要在JIRA_AUTH中重新编码如果使用带作用域的 token基础 URL 会变为https://api.atlassian.com/ex/jira/cloudId。实战示例把 Zabbix 问题变成 OneUptime 事故Zabbix 集成是入站模式的完整范例数据流为Zabbix trigger fires ──► Webhook media type ──► OneUptime Workflow (Webhook trigger) ──► Create Incident第一部分——构建 OneUptime 工作流先做这一步因为你需要它生成的 webhook URL打开Workflows → Create Workflow命名Zabbix → Incidents进入Builder页。拖入Webhook触发器复制它显示的唯一 URL把它当密码保管把块重命名为Zabbix以便变量可读。拖入Conditions块并连接触发器输出配置左值{{Zabbix.Request Body.status}}、运算符、右值1Zabbix 用1表示问题、0表示恢复。拖入Create Incident块连接到 Conditions 的Yes输出填入标题Zabbix: {{Zabbix.Request Body.name}}、描述Host: {{Zabbix.Request Body.host}}\nSeverity: {{Zabbix.Request Body.severity}}\nZabbix event: {{Zabbix.Request Body.event_id}}。保存暂不开启Enabled。第二部分——配置 Zabbix在Alerts → Media types创建类型为Webhook的媒体类型Name 设为OneUptime把 Zabbix 宏映射为干净的 payloadurl→{ALERT.SENDTO}、event_id→{EVENT.ID}、event_name→{EVENT.NAME}、event_value→{EVENT.VALUE}、event_severity→{EVENT.SEVERITY}、host→{HOST.NAME}等并粘贴一段 JavaScript 脚本把上述参数组装成 JSON 后POST到 OneUptime 工作流 URL。随后为集成创建专用用户在 Media 标签粘贴工作流 URL再创建 Trigger action 把问题事件发往该用户。可选的自动解决路径在 Zabbix 侧配置 Recovery operations恢复时status为0在 OneUptime 工作流中新增一个status 0的 Conditions 分支用Find Incident按描述中保存的event_id找到事故再用Update Incident把它移到已解决状态。实战示例把 OneUptime 事故同步到 JiraJira 集成则演示了出站 入站的双向构建。出站侧用On Create Incident触发器 API Post (JSON)块调用{{global.variables.JIRA_URL}}/rest/api/3/issue请求头为Authorization: Basic {{global.variables.JIRA_AUTH}}请求体按 Jira Cloud v3 API 要求使用Atlassian Document Format文档树而非字符串描述事故内容。Jira 返回的工单 key 在后续块中通过{{local.components.create-issue.returnValues.response-body.key}}读取。入站侧则用Webhook 触发器Update One Incident块接收 Jira 自动化规则Work item transitioned触发器 Send web request动作的回调实现Jira 工单移到 DoneOneUptime 事故跟随解决。该文档还提供了详尽排障表401通常是echo带换行编码所致、429是 Jira 限流可用Delay块隔开连续调用、未解析的{{...}}引用会逐字进入 Jira 工单等。找不到你的工具两大模式覆盖长尾几乎任何工具都能套入上述两种模式之一如果工具在事件发生时能发送 webhook用入站模式——若是告警工具把它的 webhook 指向 Incoming Request 监控器如果需要自定义逻辑则指向 OneUptime Webhook 触发器。如果工具有REST API用出站模式——从API 组件调用它。如果需要在两者之间重塑数据插入一块Custom Code运行一段 JavaScript最后一个值或 async 函数的返回值成为块的输出。这覆盖了长尾工具——Zendesk、AWS CloudWatch经 SNS、New Relic、Splunk、StatusCake 等等。配方是相同的只有 URL 与 payload 不同。自托管部署的网络访问对于自托管安装网络要求已记录在每篇集成设置指南中可按需选择对应指南GitHub 集成SendGrid 入站邮件集成Slack 集成Microsoft Teams 集成Twilio 短信与语音集成推送通知延伸阅读Workflows 概览——自动化引擎的工作方式与关键术语。触发器——Webhook 与 OneUptime 事件触发器的细节。组件——API、Webhook 与数据组件目录。变量——秘密管理与块间数据传递。Incoming Request 监控器——面向告警工具、无需工作流的入站路径。Zabbix、Jira 与 Microsoft Dynamics 365——完整的双方向构建范例。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 集成指南：基于 Workflows 自动化引擎打通 Zabbix、Jira、Slack 等外部工具
OneUptime 集成指南基于 Workflows 自动化引擎打通 Zabbix、Jira、Slack 等外部工具【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeOneUptime 通过内置的自动化引擎Workflows与团队已有的工具生态Zabbix、Jira、PagerDuty、Slack 等连接无需安装任何独立插件你只需在拖拽画布上把集成拼装起来它便会在事件发生时自动运行。本文围绕 App/FeatureSet/Docs/Content/da/integrations/index.md 阐述集成所依赖的入站Inbound与出站Outbound两大模式并结合仓库源码与配套文档给出秘密管理、认证方案与自托管网络要求等完整实操细节。读完本文你将掌握用 Workflows 连接任何具备 Webhook 或 REST API 的工具的方法即使该工具在官方目录中并没有专属页面。一切集成的根基Workflows 自动化引擎所有集成都构建在Workflows之上。用官方文档的话说Workflows 就是 OneUptime 内置的自动化引擎——把几个块放到画布上、用连线连接起来自动化就会在事故开启、定时触发或外部工具向 OneUptime 推送数据时运行。在 App/FeatureSet/Docs/Content/en/workflows/index.md 中每个 Workflow 由三部分组成触发器Trigger——决定工作流何时运行每个工作流有且只有一个触发器。一个或多个组件Component——工作流执行的动作发消息、发 HTTP 请求、跑一段检查、按条件分支。连接Connections——在画布上从一个块连到下一个块的连线决定执行顺序。从源码结构看OneUptime 的 Workflow 引擎位于 App/FeatureSet/Workflow其中 App/FeatureSet/Workflow/Services/RunWorkflow.ts 与 App/FeatureSet/Workflow/Services/QueueWorkflow.ts 负责工作流的排队与执行App/FeatureSet/Workflow/API/ComponentCode.ts 承载组件逻辑印证了工作流在后台队列中异步运行的设计。你可以把 Workflows 理解为项目的后台助手响应事件、与其他工具对话、在你不干预的情况下保持数据同步。触发器的四种类型在 App/FeatureSet/Docs/Content/en/workflows/triggers.md 中工作流可以从四种触发器中选择这也直接决定了集成的启动方式触发器触发时机典型场景Manual手动点击Run Workflow按钮填入 JSON 载荷轮换密钥发送测试告警这类一键自动化Schedule定时按 cron 表达式周期执行如0 * * * *每小时整点、*/5 * * * *每 5 分钟、0 9 * * 1每周一 9:00夜间清理、每小时同步、每周报告Webhook任何对 OneUptime 生成的唯一 URL 的访问接收外部工具推送的数据CI/CD 回调、其他监控系统的告警、CRM 注册事件OneUptime 事件监控、事故、告警、计划维护、状态页、值班策略、团队等对象的On Create / On Update / On DeleteOneUptime 里发生 X 就执行 Y无需轮询对于 Webhook 触发器请求的头信息、查询参数与请求体都会被传入工作流URL 同时接受GET与POST调用方会立刻收到确认而工作流本身在后台运行。文档明确警告要把这个 URL 当作密码对待——任何拿到它的人都可以启动你的工作流。两大集成模式每一种集成本质上都是把数据沿两个方向之一搬运很多集成两个方向都用到。这是整个集成目录背后的统一抽象理解它之后你可以把 OneUptime 连接到几乎任何工具。入站模式Inbound外部工具把数据送进 OneUptime当外部系统需要在 OneUptime创建或更新某些内容——典型场景是检测到问题时开启事故或告警——使用入站模式。标准三步构建一个以Webhook 触发器开头的工作流OneUptime 会给你一个唯一 URL。在外部工具里配置 webhook/通知动作在事件发生时向该 URL 发送POST。在工作流中读取传入的 payload用Create Incident或 Create Alert组件记录事故。Zabbix / Prometheus / Grafana / Datadog ──► OneUptime Webhook trigger ──► Create Incident技巧对于告警类工具Incoming Request 监控器通常是更好的入站路径。它无需构建工作流就能给你一个 webhook URL按 payload 中的每条告警开一个事故、升级到值班策略并在工具报告恢复时自动解决每条事故。当你需要 OneUptime 原生不提供的逻辑时再使用工作流。完整的实践示例见 Prometheus Alertmanager 集成。关于 Incoming Request 监控器官方文档补充了几个关键事实它提供https://oneuptime.com/heartbeat/YOUR_SECRET_KEY格式的唯一 URL支持GET/POSTHEAD按GET处理路径中的密钥是唯一凭证。OneUptime 会立即返回空的200并在队列中处理请求——注意200并不代表请求被接受密钥错误、监控器被删除或禁用同样返回200。body 需使用Content-Type: application/json才会被解析为可用字段。出站模式OutboundOneUptime 把数据送到外部工具当 OneUptime 里的某些内容需要在另一个工具中呈现——打开一张 Jira 工单、在 PagerDuty 里找人、往 Slack 发帖——使用出站模式。标准三步构建一个以OneUptime 事件触发器开头的工作流——例如Incident → On Create。添加一个API 组件用事故的详细信息调用对方工具的 REST API。把所有 API 密钥存为秘密Secret全局变量确保它们永远不会出现在工作流或其日志中。OneUptime Incident → On Create ──► API component ──► Jira / PagerDuty / ServiceNow / GitHub在 App/FeatureSet/Docs/Content/en/workflows/components.md 中API 组件支持GET、POST、PUT、PATCH、DELETE五种方法可自定义 URL、Headers 与 Body其Success输出在收到 2xx 响应时触发并传递状态码、响应头与响应体Error输出在网络失败或非 2xx 时触发并传递错误信息。事件触发器会把完整记录传给下一个块——例如Incident → On Create触发器把新事故完整传下去下一个块可以直接读取它的标题、描述、严重级别等任意字段。集成目录与方向速查原文档的目录表完整列出官方维护的集成及其数据流方向整理如下工具方向作用Zabbix入站把 Zabbix 问题变成 OneUptime 事故并在恢复时解决它们Jira出站入站每条事故打开一张 Jira 工单状态同步回来PagerDuty出站入站从 OneUptime 事故触发并解决 PagerDuty 事件Opsgenie出站入站创建并关闭 Opsgenie 告警ServiceNow出站入站从 OneUptime 打开 ServiceNow 事故Microsoft Dynamics 365出站入站从 OneUptime 事故打开并解决 Dynamics 365 CasesPrometheus Alertmanager入站把 Alertmanager 通知转换为事故Grafana入站把 Grafana 告警转换为事故Datadog入站把 Datadog 监控告警转换为事故GitHub出站为事故打开一张 GitHub issueGitLab出站为事故打开一张 GitLab issueDiscord出站把事故更新发到 Discord 频道Telegram出站把事故更新发到 Telegram 聊天Slack双向原生 workspace 连接——频道、告警与值班Microsoft Teams双向原生 workspace 连接Slack 与 Microsoft Teams拥有超越工作流的更深层原生连接——自动事故频道、双向操作与值班通知。这两类工具请使用 Slack 与 Microsoft Teams 的 workspace 连接而不是构建工作流。秘密管理API 密钥永远不要写进块里原文档给出的铁律是绝不把 API 密钥或 token 直接粘贴进某个块。正确做法分三步进入Workflows → Global Variables全局变量。创建一个变量——例如JIRA_AUTH——并打开Secret开关。在任何地方用{{global.variables.JIRA_AUTH}}引用它。秘密变量在保存后会从 UI 中隐藏并且会从运行日志中被清除scrubbed。这在 App/FeatureSet/Docs/Content/en/workflows/variables.md 中有更完整的定义每个全局变量包含 Name至少两个字符、无空格、仅限字母数字连字符与下划线、Description可选、Secret开启后从运行日志与步骤追踪中清除、Content长文本字段支持多行值。引用语法为{{global.variables.NAME}}例如把 PagerDuty 密钥存为PAGERDUTY_KEY后任何块都能以{{global.variables.PAGERDUTY_KEY}}使用它。该文档还指出了几个值得注意的坑变量只能创建和删除不能编辑——要在 UI 中改值需要删除后重建或通过 API 更新。变量名区分大小写{{global.variables.MyKey}}与{{global.variables.mykey}}是两个不同的查找。未解析的引用会原样传过去而不是置空——拼错的引用会逐字出现在 Slack 消息、URL 或请求体里运行仍显示Executed只有运行日志中的警告行会点名该引用。花括号内的空格不会被修剪{{ local.variables.NAME }}永远无法解析。此外工作流还支持局部工作流变量{{local.variables.NAME}}与组件输出引用{{local.components.COMPONENT_ID.returnValues.FIELD_ID}}。在编辑器里应尽量使用**取值器picker**插入引用它会插入运行器期望的精确 id并让引用不依赖显示标签。认证速查表六种常见 Authorization 方案大多数出站集成需要在 API 块上设置Authorization请求头。原文档总结了六种常见形式方案Header 值适用工具Bearer tokenBearer {{global.variables.TOKEN}}GitHub 及许多现代 APIBasic authBasic {{global.variables.BASE64_USER_PASS}}Jira Cloud、ServiceNowAPI 密钥 headerGenieKey {{global.variables.OPSGENIE_KEY}}OpsgenieBody 中的 tokenJSON body 中的routing_key字段PagerDuty Events APIPrivate token headerPRIVATE-TOKEN: {{global.variables.GITLAB_TOKEN}}GitLabOAuth 2.0 client credentialsBearer 由前置 API 块获取的 tokenMicrosoft Dynamics 365 (Dataverse)对于 Basic auth你需要把username:password或email:api_token一次性base64 编码然后把结果存为秘密变量。在 macOS/Linux 上printf %s youexample.com:your_api_token | base64Jira 集成文档特别强调了一个细节必须使用printf而不是echo——echo会追加换行符换行符会连同其余内容一起被编码导致 Jira 返回401。此外Atlassian API token 会过期默认有效期一年、无刷新机制过期后需要在JIRA_AUTH中重新编码如果使用带作用域的 token基础 URL 会变为https://api.atlassian.com/ex/jira/cloudId。实战示例把 Zabbix 问题变成 OneUptime 事故Zabbix 集成是入站模式的完整范例数据流为Zabbix trigger fires ──► Webhook media type ──► OneUptime Workflow (Webhook trigger) ──► Create Incident第一部分——构建 OneUptime 工作流先做这一步因为你需要它生成的 webhook URL打开Workflows → Create Workflow命名Zabbix → Incidents进入Builder页。拖入Webhook触发器复制它显示的唯一 URL把它当密码保管把块重命名为Zabbix以便变量可读。拖入Conditions块并连接触发器输出配置左值{{Zabbix.Request Body.status}}、运算符、右值1Zabbix 用1表示问题、0表示恢复。拖入Create Incident块连接到 Conditions 的Yes输出填入标题Zabbix: {{Zabbix.Request Body.name}}、描述Host: {{Zabbix.Request Body.host}}\nSeverity: {{Zabbix.Request Body.severity}}\nZabbix event: {{Zabbix.Request Body.event_id}}。保存暂不开启Enabled。第二部分——配置 Zabbix在Alerts → Media types创建类型为Webhook的媒体类型Name 设为OneUptime把 Zabbix 宏映射为干净的 payloadurl→{ALERT.SENDTO}、event_id→{EVENT.ID}、event_name→{EVENT.NAME}、event_value→{EVENT.VALUE}、event_severity→{EVENT.SEVERITY}、host→{HOST.NAME}等并粘贴一段 JavaScript 脚本把上述参数组装成 JSON 后POST到 OneUptime 工作流 URL。随后为集成创建专用用户在 Media 标签粘贴工作流 URL再创建 Trigger action 把问题事件发往该用户。可选的自动解决路径在 Zabbix 侧配置 Recovery operations恢复时status为0在 OneUptime 工作流中新增一个status 0的 Conditions 分支用Find Incident按描述中保存的event_id找到事故再用Update Incident把它移到已解决状态。实战示例把 OneUptime 事故同步到 JiraJira 集成则演示了出站 入站的双向构建。出站侧用On Create Incident触发器 API Post (JSON)块调用{{global.variables.JIRA_URL}}/rest/api/3/issue请求头为Authorization: Basic {{global.variables.JIRA_AUTH}}请求体按 Jira Cloud v3 API 要求使用Atlassian Document Format文档树而非字符串描述事故内容。Jira 返回的工单 key 在后续块中通过{{local.components.create-issue.returnValues.response-body.key}}读取。入站侧则用Webhook 触发器Update One Incident块接收 Jira 自动化规则Work item transitioned触发器 Send web request动作的回调实现Jira 工单移到 DoneOneUptime 事故跟随解决。该文档还提供了详尽排障表401通常是echo带换行编码所致、429是 Jira 限流可用Delay块隔开连续调用、未解析的{{...}}引用会逐字进入 Jira 工单等。找不到你的工具两大模式覆盖长尾几乎任何工具都能套入上述两种模式之一如果工具在事件发生时能发送 webhook用入站模式——若是告警工具把它的 webhook 指向 Incoming Request 监控器如果需要自定义逻辑则指向 OneUptime Webhook 触发器。如果工具有REST API用出站模式——从API 组件调用它。如果需要在两者之间重塑数据插入一块Custom Code运行一段 JavaScript最后一个值或 async 函数的返回值成为块的输出。这覆盖了长尾工具——Zendesk、AWS CloudWatch经 SNS、New Relic、Splunk、StatusCake 等等。配方是相同的只有 URL 与 payload 不同。自托管部署的网络访问对于自托管安装网络要求已记录在每篇集成设置指南中可按需选择对应指南GitHub 集成SendGrid 入站邮件集成Slack 集成Microsoft Teams 集成Twilio 短信与语音集成推送通知延伸阅读Workflows 概览——自动化引擎的工作方式与关键术语。触发器——Webhook 与 OneUptime 事件触发器的细节。组件——API、Webhook 与数据组件目录。变量——秘密管理与块间数据传递。Incoming Request 监控器——面向告警工具、无需工作流的入站路径。Zabbix、Jira 与 Microsoft Dynamics 365——完整的双方向构建范例。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考