拓冰网站定制 
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本文基于 packages/App/FeatureSet/Docs/Content/fr/integrations/jira.md法文版作为原文骨架翻译、整理并深度扩充。以下原文均指该文件。导读本文教你用 OneUptime 内置的 Workflow工作流引擎把 Jira 无缝接入事故响应流程每次 OneUptime 事故被声明时自动在 Jira 创建工单issue事故解决时自动把 Jira 工单过渡到 Done同时 Jira 端的状态变更也能反向同步回 OneUptime——构成一张完整的双向同步网。你不需要安装任何 Jira 专属插件OneUptime 通过内置的 API 组件直接调用 Jira REST APIJira 侧则用自动化规则Automation或原生 Webhook 回调 OneUptime。读完本文你将掌握从凭证存储、事故→工单创建、字段映射、状态回写到 Jira Data Center 适配与常见错误排查的完整闭环。原文地址Jira 集成文档fr 语言包配套阅读集成总览、Workflow 入门、Workflow 组件1. 架构总览两个方向、四段流程OneUptime 的 Workflow 引擎是一个可视化画布让你用触发器 组件块串起自动化逻辑。整个 Jira 集成由两条相对独立的链路组成OneUptime Incident → On Create ──► API Post (POST /rest/api/3/issue) ──► Jira issue Jira issue transitioned ──► Automation rule (Send web request) ──► OneUptime Webhook trigger ──► Update One Incident出站OneUptime → Jira事故创建/更新时触发 Workflow通过 API 组件调用 Jira REST API 创建、评论、过渡工单。入站Jira → OneUptimeJira 自动化规则把工单状态变更以 webhook 形式回调 OneUptime由 Webhook 触发器接收并更新事故状态。从源码看Workflow 引擎的 Webhook 触发器实现在 WebhookTrigger它暴露一个GET /trigger/:secretkey路由把收到的请求头、查询参数和请求体原样透传给工作流后续组件其组件元数据定义在 Webhook.tsTypes 侧明确标注了request-headers、request-params、request-body三个可注入的入参。这正是文档中Jira 回调 → Webhook 触发器 → 更新事故链路的底层支撑。术语提示Atlassian 在 Jira Cloud 中不断调整叫法——project项目在大量界面中被称为space空间issue工单被称为work item。新旧租户词汇不一下文两者都会出现请以你所见界面为准。2. 前置条件在动手之前请确认以下四项都已就绪一个 Jira Cloud 站点形如https://your-domain.atlassian.net以及一个用于建票的项目。记下它的项目密钥project key——例如OPS-1234中的OPS。一个能在该项目中建票的 Jira 账号并为其创建API Token管理入口id.atlassian.com → Security → API tokens。强烈建议使用服务账号service account而非个人账号——因为通过该 token 创建的工单assignee 默认归属 token 持有者。该项目的自动化规则创建权限用于入站方向。一个 OneUptime 项目且你拥有创建 Workflow 和全局变量Global Variables的权限。关于 OneUptime 项目的获取OneUptime 既提供云端托管Cloud也支持自托管self-hosted。自托管场景下所有oneuptime.com的 URL 都要替换成你自己的主机地址。3. 第 1 步把 Jira 凭证安全地存进全局变量Jira Cloud 的 REST API 使用Basic Auth把账号邮箱与 API Token 拼接为email:api_token后整体做 Base64 编码作为Authorization请求头。OneUptime 的 Workflow 引擎没有硬编码凭证的地方最佳实践是使用全局变量 Secret 标记。3.1 一次性生成 Base64 凭证串printf %s youexample.com:your_api_token | base64务必使用printf而不是echoecho会在末尾追加一个换行符换行符会被一并编码进字符串导致 Jira 返回401 Unauthorized——而你在粘贴的字符串里完全看不出原因。这是文档点名的头号坑后续排查章节还会遇到它。3.2 在 OneUptime 中创建两条全局变量变量名类型内容JIRA_AUTHSecret勾选上一步得到的 Base64 字符串JIRA_URL普通不勾选 Secrethttps://your-domain.atlassian.net末尾不要带斜杠操作路径Flux de travail → Variables globales → Créer即 Workflow → Global Variables → Create。之后任何组件都可以直接用Basic {{global.variables.JIRA_AUTH}}作为Authorization请求头而 token 本身永远不会出现在 Workflow 的画布、配置或运行日志中。参见 Variables 文档。3.3 关于 Atlassian API Token 的两个隐藏陷阱这两个问题不会立刻爆发但会在几个月后反咬一口Token 会过期Atlassian API Token 的寿命是 1 天到 1 年默认 1 年且没有自动续期机制。过期后必须手动去同一页面重新生成再重新编码进JIRA_AUTH。请把到期日写进日历——当一个运行了几个月的 Workflow 突然开始返回401十有八九就是这个原因。受限作用域 Token 需要不同的 Base URLToken 页面除了经典的Create API token还提供Create API token with scopes更安全的选项。但这类 token不指向你的站点而是指向https://api.atlassian.com/ex/jira/cloudId——此时JIRA_URL应改为该值下面所有路径保持不变地挂在它后面。你的cloudId可以通过访问https://your-domain.atlassian.net/_edge/tenant_info返回的 JSON 拿到。把受限 token 发往your-domain.atlassian.net会直接失败。3.4 进阶用 OAuth 2.0 服务账号凭证绕开过期问题如果你的组织使用 Atlassian 集中式用户管理还有第三条路OAuth 2.0 服务账号凭证Service account credential。它给你 client id secret 而非静态 tokenWorkflow 在每次执行开始时先用这两个值换取短期访问令牌。结构上与文档中 Microsoft Dynamics 365 集成一致第一个API Post (JSON)块负责拿 token其后所有块改用Bearer token请求头API 基础 URL 为https://api.atlassian.com。这样一年后无需任何人手动更换任何东西。Atlassian 官方页面提供了精确的换取 token 请求体照抄即可。4. 第 2 步为每个事故自动创建 Jira 工单这是整条出站链路的核心。我们要在 OneUptime 里新建一个 Workflow命名为Incidents → Jira。4.1 配置触发器On Create Incident打开Flux de travail → Créer un flux de travailWorkflow → Create Workflow命名后进入画布Constructeur / Builder。点击虚线块添加触发器On Create Incident。在其Select Fields字段中声明你需要发送的列{ _id: true, title: true, description: true, incidentNumber: true, incidentSeverity: { name: true } }保持其Identifier为默认的incident-on-create-1——后续所有组件都通过这个名字引用该触发器的输出。从源码理解 Select FieldsOneUptime 基于数据库模型驱动 Workflow 触发器的字段选择。Incident 模型的字段结构位于 packages/Common/Models/DatabaseModels/触发器只会把你在 Select Fields 里勾选的字段注入返回值因此少勾一个字段后续组件就拿不到对应的引用表现为模板变量原样输出或空值。4.2 添加 API Post (JSON) 组件点击Ajouter un composant添加组件选API Post (JSON)块把触发器的Succès / 成功端口连到新块的入口设置 Identifier 为create-issueURL{{global.variables.JIRA_URL}}/rest/api/3/issueRequest Headers{ Authorization: Basic {{global.variables.JIRA_AUTH}}, Accept: application/json }Request Body{ fields: { project: { key: OPS }, issuetype: { name: Bug }, summary: OneUptime #{{local.components.incident-on-create-1.returnValues.model.incidentNumber}}: {{local.components.incident-on-create-1.returnValues.model.title}}, labels: [oneuptime], description: { type: doc, version: 1, content: [ { type: paragraph, content: [ { type: text, text: {{local.components.incident-on-create-1.returnValues.model.description}} } ] } ] } } }请把OPS换成你的项目密钥、Bug换成该项目真实存在的工单类型。两者也可以改用 ID 传参——{id: 10000}——这是 Atlassian 官方示例的写法当站点里有两个同名工单类型时务必用 ID。ID 可以从下文 4.5 的createmeta接口拿到。4.3 理解 Atlassian Document FormatADF上面的 description 之所以长得这么重是因为Jira Cloud v3 API 要求富文本使用 Atlassian Document FormatADF——它是一棵文档树不是普通字符串。上面这段是合法的 ADF 最小文档一个 paragraph 里包一个 text 节点。同样的规则适用于environment字段以及任何多行文本自定义字段单行文本自定义字段则仍然接受普通字符串。4.4 激活、验证与结果引用在Vue densemble → Modifier le flux de travailOverview → Edit Workflow中把状态切到Activé / 启用。声明一个测试事故打开Exécutions journauxExecutions Logs。create-issue块应返回201响应体包含新工单的id、key、self。两点操作提示源自文档画布上的修改自动保存没有 Save 按钮未启用的 Workflow 完全无法运行——包括手动运行。新工单的 key 可被后续任何组件引用{{local.components.create-issue.returnValues.response-body.key}}4.5 补充常用字段与字段探测在fields对象里几个高频追加项字段写法说明Prioritypriority: { id: 20000 }用你站点的优先级 ID若要做 OneUptime 严重级别→Jira 优先级映射在触发器与 API 块之间插一个If / Else块对{{local.components.incident-on-create-1.returnValues.model.incidentSeverity.name}}分支Assigneeassignee: { id: accountId }Jira Cloud 用 Atlassian accountId 标识人员username/userKey早已被 Cloud API 移除Labelslabels: [oneuptime, sev1]扁平字符串数组不能含空格Componentscomponents: [{ id: 10000 }]组件 ID 数组Custom fieldscustomfield_10034: ...值形态取决于字段类型单选列表用{value: red}多选列表用 ID 数组多行文本用 ADF 文档与其猜不如直接问 Jira。用下面两个 curl 调用探测项目真实要求# 列出某项目的工单类型 curl -u youexample.com:your_api_token \ https://your-domain.atlassian.net/rest/api/3/issue/createmeta/OPS/issuetypes # 列出某工单类型的全部字段哪些必填、customfield_NNNNN 的准确 ID curl -u youexample.com:your_api_token \ https://your-domain.atlassian.net/rest/api/3/issue/createmeta/OPS/issuetypes/10001第二个调用会给出该工单类型接受的全部字段、必填项以及精确的customfield_NNNNN标识。想读取已有工单的字段 ID用?expandnames参数拉取。5. 第 3 步把 OneUptime 事故 ID 存进 Jira双向同步的两个方向都需要某一侧持有另一侧的标识符。文档明确建议把 ID 存在 Jira 侧因为 OneUptime 的customFields列是一个扁平的 JSON blob——Workflow 从里面写入一个值会覆盖该事故的全部自定义字段代价太大。5.1 方案 A推荐自定义字段在 Jira 中新建一个短文本自定义字段命名为OneUptime Incident ID挂到项目的创建界面screen上用 4.5 的createmeta找到它的 ID然后在创建工单的请求体里一并提交customfield_10050: {{local.components.incident-on-create-1.returnValues.model._id}}5.2 方案 B无管理员权限标签没有 Jira 管理员权限时把 ID 塞进 label。label 不能含空格而 OneUptime 的 ID 是 UUID所以oneuptime-id是合法 labellabels: [oneuptime, oneuptime-{{local.components.incident-on-create-1.returnValues.model._id}}]代价入站 Workflow 需要用一个Run Custom JavaScript块从 label 列表里把 ID 抠出来两到三行代码。文档的评价是能拿到自定义字段就用字段更干净。5.3 顺手加一个返回 OneUptime的链接在create-issue之后再接一个API Post (JSON)块指向{{global.variables.JIRA_URL}}/rest/api/3/issue/{{local.components.create-issue.returnValues.response-body.key}}/remotelink请求体{ globalId: systemhttps://oneuptime.comid{{local.components.incident-on-create-1.returnValues.model._id}}, object: { url: https://oneuptime.com/dashboard/{{local.components.incident-on-create-1.returnValues.model.projectId}}/incidents/{{local.components.incident-on-create-1.returnValues.model._id}}, title: OneUptime incident #{{local.components.incident-on-create-1.returnValues.model.incidentNumber}} } }这样 Jira 里所有人都能一键跳回 OneUptime 事故页。注意需要在触发器的Select Fields里追加projectIdglobalId让这个调用可安全重复执行——Jira 会更新已带该 ID 的链接而不是再插一条因为更新会清空所有未提交的字段所以必须始终发送完整的object不能发局部补丁。自托管安装请把https://oneuptime.com/dashboard/...换成你自己的仪表盘地址。6. 第 4 步事故演变时评论并过渡工单这要做成第二个独立 Workflow命名如Incident updates → Jira理由是这个流程失败绝不能阻塞建票流程——两个职责彼此隔离。添加触发器On Update Incident。在Listen on里写{currentIncidentStateId: true}——这样触发器只在状态变化时触发而不是每次修改都触发。Select Fields里写{_id: true, currentIncidentState: {name: true}}。添加If / Else块Input 1为{{local.components.incident-on-update-1.returnValues.model.currentIncidentState.name}}Operator为Input 2为Resolved或你项目里已解决状态的准确名称。参见 États et sévérités des incidents。6.1 从Oui / 是分支找回 Jira 工单用第 3 步存的 ID 去 Jira 查询对应工单。用一个 Identifier 为find-issue的API Post (JSON)块URL{{global.variables.JIRA_URL}}/rest/api/3/search/jqlRequest Body{ jql: project OPS AND labels \oneuptime-{{local.components.incident-on-update-1.returnValues.model._id}}\, maxResults: 1 }如果第 3 步用的是自定义字段而非 labelJQL 子句相应改为cf[10050] ~ ...换成你的字段 ID。工单 ID 从此可用{{local.components.find-issue.returnValues.response-body.issues[0].id}}引用——下面所有端点既接受 key 也接受 id。关于这个端点文档特别强调三点JQL 放进请求体POST不要拼进 URL。查询串里带的值在离开 Workflow 时会被截断而 JQL 通篇都是。查询必须加边界裸写order by key desc会被400拒绝所以要带project 这样的收敛条件。必须用/rest/api/3/search/jql旧端点/rest/api/3/search已废弃并进入生命周期终点不要再用。6.2 留评论单个 API Post 块指向{{global.variables.JIRA_URL}}/rest/api/3/issue/id/commentbody 同样是 ADF 格式和 description 一样{ body: { type: doc, version: 1, content: [ { type: paragraph, content: [{ type: text, text: Resolved in OneUptime. }] } ] } }6.3 过渡工单先查后转两个调用transition 的 ID 因 Jira workflow 而异某些看板上甚至因工单而异所以必须动态查询API Get (JSON)调{{global.variables.JIRA_URL}}/rest/api/3/issue/id/transitions——返回从工单当前状态出发可用的全部 transition每个带id、name和指向目标状态的to对象。API Post (JSON)调同一个 URL 执行 transition{ transition: { id: 31 } }成功的 transition 返回204无响应体。如果不想在运行时读列表可以手动对一张处于正确状态的工单调一次接口、把 ID 硬编码进 Workflow——但要记住它绑定了该 Jira workflow管理员改动 workflow 可能会让硬编码悄悄失效。7. 入站方向从 Jira 回到 OneUptime另一半链路某人在 Jira 把工单拖到 DoneOneUptime 的事故状态要跟着变。7.1 先建好接收 WorkflowCréer un flux de travail命名Jira → OneUptime添加Webhook触发器。打开该 Workflow 的Paramètres / 设置复制clé secrète du webhookwebhook 密钥。你的回调 URL 是https://oneuptime.com/workflow/trigger/webhook secret key自托管安装用自己的主机地址。把这条 URL 当密码对待——任何拿到它的人都能启动这个 Workflow万一泄露在同一页面重新生成密钥即可。从源码看该路由正对应 WebhookTrigger.init() 注册的GET /trigger/:secretkey请求头、参数、body 会原样进入后续组件。在触发器的出口加一个If / Else在任何逻辑之前先校验共享密钥Input 1{{local.components.webhook-1.returnValues.request-headers.x-oneuptime-secret}}OperatorInput 2{{global.variables.JIRA_WEBHOOK_SECRET}}自己编一个值存成 Secret 全局变量从Oui / 是分支加Update One Incident块Query{_id: {{local.components.webhook-1.returnValues.request-body.oneuptimeIncidentId}}}Data (JSON Object)Jira 侧变更在 OneUptime 侧应产生的效果——通常是状态变更。移动事故状态需要目标状态的 ID用Find One Incident State块、查询{name: Resolved}得到{{local.components.incident-state-find-one-1.returnValues.model._id}}把它写进currentIncidentStateId。保持该 Workflow 启用。接下来给 Jira 一个可调用它的东西。7.2 用 Jira 自动化规则发送事件打开 Jira 项目自动化规则新租户在Space settings → Automation旧租户在Project settings → Automation跨项目规则走Settings → System → Global automation需要全局Administer Jira权限。Create rule触发器选Work item transitioned旧租户叫Issue transitioned并设置成进入 Done 状态时触发。务必用 transitioned 触发器不要用 Work item updatedupdate 触发器会刻意排除状态变更。添加Send web request动作Web request URL上面拿到的 OneUptime webhook URLHTTP methodPOSTHeadersContent-Type/application/json以及X-OneUptime-Secret/ 你的共享密钥。用Hide选项隐藏密钥值注意隐藏对该值不可逆且规则被导出或复制时隐藏值会丢失Web request body选Custom format完全自定义载荷{ oneuptimeIncidentId: {{issue.customfield_10050}}, issueKey: {{issue.key}}, summary: {{issue.summary}}, status: {{issue.status.name}} }如果第 3 步用的是 label 而非自定义字段就发送labels: {{issue.labels}}然后在 OneUptime 侧用Run Custom JavaScript块提取 ID。启用规则把一张测试工单拖到 Done两侧验证Jira 的规则审计日志audit log和 OneUptime 的Exécutions journaux。7.3 依赖此机制前必须知道的五个事实出站端口受限Send web request 只能访问端口 80、8080、443、6017、8443、8444、7990、8090、8085、8060、8900、9900。OneUptime Cloud 走 443 没问题自托管部署若监听非常规端口就无法被这种方式调用。没有请求签名该动作不提供 HMAC 选项。Atlassian 文档化的做法就是 HTTPS 上加共享密钥请求头——所以接收 Workflow 里那个If / Else 校验是整套安全性的核心。规则执行会计入配额Jira Cloud 按订阅计划扣减每月成功执行次数——Free 100 次、Standard 1700 次、Premium 1000 × 用户数、Enterprise 无限。繁忙项目的每次 transition 都会消耗配额量大了要掂量。值不会被自动做 URL 编码只有发 form-encoded body 时才有影响上面的 JSON 载荷无此问题。Atlassian 会公布出站 IP 段ip-ranges.atlassian.com如果你的 OneUptime 部署在 IP 白名单后面这些段会变化应订阅其 feed 而不是固化地址。7.4 替代方案Jira 原生 WebhookJira 管理员也可以直接在Settings → System → Advanced → WebHooks注册 webhook选择要投递的事件并可加一条 JQL 过滤涉及的工单。与自动化规则对比载荷是 Jira 的不是你的包含webhookEvent、issue_event_type_name、完整issue对象以及changelog其items数组给出每个被改字段的前后值。状态变更对应field为status的那条记录。要在 Workflow 里解析它通常需要Run Custom JavaScript块。webhook 可以签名但 Workflow 验不了给 webhook 配一个 secret 后Jira 会发送X-Hub-Signature头请求体 HMAC。但签名覆盖的是 Jira 发送的原始字节而 OneUptime 的 Webhook 触发器交给 Workflow 的是已解析成 JSON 的对象——没有字节可哈希。想认证请求就用自动化规则 共享密钥头的方案。URL 必须走 HTTPS 且端口在 Jira 专属列表内与自动化规则的端口列表不同80 不在其中。投递失败最多重试 5 次间隔 515 分钟——所以接收 Workflow 必须容忍同一事件收到两次幂等。另外要注意应用通过/rest/api/3/webhook注册的 webhook 是另一回事——注册后 30 天不刷新就过期管理员在界面上注册的则不过期。8. Jira Data Center 适配自托管 Jira 的工作方式相同只有几处替换。Jira Server 已于 2024 年 2 月结束支持、不再有补丁——自托管请把 Data Center 当作目标版本。CloudData Center/rest/api/3/.../rest/api/2/...—— Data Center 没有 v3description用 ADF 文档description用 wiki markup 纯字符串Authorization: Basic base64(email:api_token)Authorization: Bearer personal access token令牌来自 id.atlassian.com在Profile → Personal access tokens → Create token创建自动化动作Send web request自动化动作Send outgoing web request于是创建工单的块变成对/rest/api/2/issue的POST{ fields: { project: { key: OPS }, issuetype: { name: Bug }, summary: OneUptime #123: Checkout is down, description: Plain text goes straight in here. } }——没有文档树建模更简单。8.1 其余差异清单Personal access tokens自 Jira Core / Jira Software 8.14、Jira Service Management 4.15 起可用。默认 365 天过期到期前 5 天界面会标注Expires soon。Data Center 仍支持用户名密码的 Basic auth但几次失败登录会触发 CAPTCHA把账号彻底挡在 REST API 之外、直到有人在浏览器里人工解锁——这不是发现拼写错误的好方式请优先用 token。自动化已内建自 Jira Data Center 10.0 起内置此前是独立插件 Automation for Jira。其出站请求默认超时 3000 ms可用属性outgoing.webhook.timeout.ms调整。Webhooks在Administration → System → Advanced → WebHooks注册支持 JQL 过滤。务必把过滤器收窄Jira 会在触发事件的执行线程上对每个已注册 webhook 求值 JQL十几个宽泛过滤器会拖慢触发它们的用户操作。Data Center 10.0 起 webhook 投递是异步的没有同步选项——事件可能乱序到达接收 Workflow 要做到幂等。Jira 10 移除了 webhook URL 变量里的$——${issue.id}变成{issue.id}——并把 webhook REST 资源从/rest/webhooks/1.0/webhook移到/rest/jira-webhook/1.0/webhooks。9. 同样的套路搬到 Alert告警上面全部围绕 Incident事故展开因为这是最常见的场景但Alert告警的用法一模一样——只换记录类型其他不动IncidentAlertOn Create Incidentincident-on-create-1On Create Alertalert-on-create-1On Update Incidentincident-on-update-1On Update Alertalert-on-update-1incidentNumber、currentIncidentState、incidentSeverityalertNumber、currentAlertState、alertSeverityFind One Incident StateFind One Alert StateUpdate One IncidentUpdate One Alert注意一个 Workflow 只能有一个触发器所以 Incident 和 Alert 各需一个 Workflow。如果两者要做完全相同的处理把 Jira 那一半建成一个 Workflow再用Execute Workflow组件从两边调用它。10. 排障手册先打开Exécutions journaux里失败的块Jira 返回的 JSON 响应体会精确指出它拒绝了什么API 组件会把响应体保留在response-body里供你检视。症状排查方向401 Unauthorized用printf重新编码email:api_token并更新JIRA_AUTH——echo带出的换行符是最常见原因。确认 token 所属账号在该项目有建票权限。Data Center 上检查是否错发了Basic而不是Bearer400 Bad Request且点名某个字段工单类型在该项目不存在或项目有必填字段未提交。对项目和工单类型跑一遍 4.5 的createmeta调用逐项比对400且抱怨descriptionCloud v3 上 description 必须是 ADF 文档而非字符串。要么发送前文展示的文档结构要么把该块切到/rest/api/2/issue发纯文本404 Not Found检查 Base URL 和 API 版本Cloud 用/rest/api/3/...Data Center 用/rest/api/2/...429 Too Many RequestsJira 限流。响应带Retry-After秒和RateLimit-Reason命中的限制名。同一工单的写入限制很紧约 2 秒内 20 次连续评论 过渡容易单票触发。在调用间加Delay块或把批量工作挪到定时 Workflow过渡调用返回400transition ID 对工单当前状态无效。重新拉该工单的/transitions用响应里的 ID自动化规则显示成功但 OneUptime 没动静先查端口见 7.3 受限列表。再用curl手动向 webhook URL 发一条请求看是否出现在Exécutions journaux你的能到而 Jira 的不到问题在 Jira 侧Workflow 跑了但事故没变Update One Incident块在查询没命中时报告Items Updated: 0这被算作成功而非错误。确认载荷里的 id 确实是 OneUptime 事故 ID且查询的是_id字段{{...}}引用原样出现在 Jira 工单里未解析的引用会被当作纯文本原样传过去而不是清空。运行日志会点名所有未解析的引用——通常是块 Identifier 拼错或变量被改名11. 延伸阅读Vue densemble des intégrations集成总览 —— 出入站模式与认证速查表Microsoft Dynamics 365 集成 —— 同样的双向构造用在 Dynamics 上Workflow 概述 与 创建 Workflow —— 画布、Identifier、激活机制Workflow 组件 —— API 块、If / Else 与 OneUptime 数据组件Workflow 变量 —— Secret 管理以及从上一块读取输出Workflow 配置与安全 —— webhook 安全与出站网络访问ServiceNow 与 PagerDuty —— 同样的出站模式用在其他工具上仓库内实现参考法语原文文档packages/App/FeatureSet/Docs/Content/fr/integrations/jira.mdWebhook 触发器实现packages/Common/Server/Types/Workflow/Components/Webhook.tsWebhook 组件元数据packages/Common/Types/Workflow/Components/Webhook.tsWorkflow 更新/触发 APIpackages/App/FeatureSet/Workflow/API/Workflow.tsWorkflow 组件文档目录packages/App/FeatureSet/Workflow/Docs/ComponentDocumentation/赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime × Jira 双向集成实战用 Workflow 与 REST API 打通事故和 Issue 的双向同步OneUptime × Jira 双向集成实战用 Workflow 与 REST API 打通事故和 Issue 的双向同步 本篇基于 OneUptime 官可观测性后端运维前端云原生微服务AI AgentReact Router v8 到 v9 升级指南Future Flags 与 Future Changes 全解析React Router v8 到 v9 升级指南Future Flags 与 Future Changes 全解析 React Router 借助 Futu可观测性后端运维前端云原生微服务AI AgentOneUptime 与 PagerDuty 集成实战通过 Workflow 将事件双向打通OneUptime 与 PagerDuty 集成实战通过 Workflow 将事件双向打通 本指南讲解如何在 OneUptime 中通过 Workflow 与可观测性后端运维前端云原生微服务AI Agent上一篇告别监控数据泄露Frigate隐私保护全攻略下一篇彻底解决F5-TTS爆音问题从原理到优化的全流程指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime × Jira 双向集成实战：用 Workflow 打通事故工单的完整生命周期
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本文基于 packages/App/FeatureSet/Docs/Content/fr/integrations/jira.md法文版作为原文骨架翻译、整理并深度扩充。以下原文均指该文件。导读本文教你用 OneUptime 内置的 Workflow工作流引擎把 Jira 无缝接入事故响应流程每次 OneUptime 事故被声明时自动在 Jira 创建工单issue事故解决时自动把 Jira 工单过渡到 Done同时 Jira 端的状态变更也能反向同步回 OneUptime——构成一张完整的双向同步网。你不需要安装任何 Jira 专属插件OneUptime 通过内置的 API 组件直接调用 Jira REST APIJira 侧则用自动化规则Automation或原生 Webhook 回调 OneUptime。读完本文你将掌握从凭证存储、事故→工单创建、字段映射、状态回写到 Jira Data Center 适配与常见错误排查的完整闭环。原文地址Jira 集成文档fr 语言包配套阅读集成总览、Workflow 入门、Workflow 组件1. 架构总览两个方向、四段流程OneUptime 的 Workflow 引擎是一个可视化画布让你用触发器 组件块串起自动化逻辑。整个 Jira 集成由两条相对独立的链路组成OneUptime Incident → On Create ──► API Post (POST /rest/api/3/issue) ──► Jira issue Jira issue transitioned ──► Automation rule (Send web request) ──► OneUptime Webhook trigger ──► Update One Incident出站OneUptime → Jira事故创建/更新时触发 Workflow通过 API 组件调用 Jira REST API 创建、评论、过渡工单。入站Jira → OneUptimeJira 自动化规则把工单状态变更以 webhook 形式回调 OneUptime由 Webhook 触发器接收并更新事故状态。从源码看Workflow 引擎的 Webhook 触发器实现在 WebhookTrigger它暴露一个GET /trigger/:secretkey路由把收到的请求头、查询参数和请求体原样透传给工作流后续组件其组件元数据定义在 Webhook.tsTypes 侧明确标注了request-headers、request-params、request-body三个可注入的入参。这正是文档中Jira 回调 → Webhook 触发器 → 更新事故链路的底层支撑。术语提示Atlassian 在 Jira Cloud 中不断调整叫法——project项目在大量界面中被称为space空间issue工单被称为work item。新旧租户词汇不一下文两者都会出现请以你所见界面为准。2. 前置条件在动手之前请确认以下四项都已就绪一个 Jira Cloud 站点形如https://your-domain.atlassian.net以及一个用于建票的项目。记下它的项目密钥project key——例如OPS-1234中的OPS。一个能在该项目中建票的 Jira 账号并为其创建API Token管理入口id.atlassian.com → Security → API tokens。强烈建议使用服务账号service account而非个人账号——因为通过该 token 创建的工单assignee 默认归属 token 持有者。该项目的自动化规则创建权限用于入站方向。一个 OneUptime 项目且你拥有创建 Workflow 和全局变量Global Variables的权限。关于 OneUptime 项目的获取OneUptime 既提供云端托管Cloud也支持自托管self-hosted。自托管场景下所有oneuptime.com的 URL 都要替换成你自己的主机地址。3. 第 1 步把 Jira 凭证安全地存进全局变量Jira Cloud 的 REST API 使用Basic Auth把账号邮箱与 API Token 拼接为email:api_token后整体做 Base64 编码作为Authorization请求头。OneUptime 的 Workflow 引擎没有硬编码凭证的地方最佳实践是使用全局变量 Secret 标记。3.1 一次性生成 Base64 凭证串printf %s youexample.com:your_api_token | base64务必使用printf而不是echoecho会在末尾追加一个换行符换行符会被一并编码进字符串导致 Jira 返回401 Unauthorized——而你在粘贴的字符串里完全看不出原因。这是文档点名的头号坑后续排查章节还会遇到它。3.2 在 OneUptime 中创建两条全局变量变量名类型内容JIRA_AUTHSecret勾选上一步得到的 Base64 字符串JIRA_URL普通不勾选 Secrethttps://your-domain.atlassian.net末尾不要带斜杠操作路径Flux de travail → Variables globales → Créer即 Workflow → Global Variables → Create。之后任何组件都可以直接用Basic {{global.variables.JIRA_AUTH}}作为Authorization请求头而 token 本身永远不会出现在 Workflow 的画布、配置或运行日志中。参见 Variables 文档。3.3 关于 Atlassian API Token 的两个隐藏陷阱这两个问题不会立刻爆发但会在几个月后反咬一口Token 会过期Atlassian API Token 的寿命是 1 天到 1 年默认 1 年且没有自动续期机制。过期后必须手动去同一页面重新生成再重新编码进JIRA_AUTH。请把到期日写进日历——当一个运行了几个月的 Workflow 突然开始返回401十有八九就是这个原因。受限作用域 Token 需要不同的 Base URLToken 页面除了经典的Create API token还提供Create API token with scopes更安全的选项。但这类 token不指向你的站点而是指向https://api.atlassian.com/ex/jira/cloudId——此时JIRA_URL应改为该值下面所有路径保持不变地挂在它后面。你的cloudId可以通过访问https://your-domain.atlassian.net/_edge/tenant_info返回的 JSON 拿到。把受限 token 发往your-domain.atlassian.net会直接失败。3.4 进阶用 OAuth 2.0 服务账号凭证绕开过期问题如果你的组织使用 Atlassian 集中式用户管理还有第三条路OAuth 2.0 服务账号凭证Service account credential。它给你 client id secret 而非静态 tokenWorkflow 在每次执行开始时先用这两个值换取短期访问令牌。结构上与文档中 Microsoft Dynamics 365 集成一致第一个API Post (JSON)块负责拿 token其后所有块改用Bearer token请求头API 基础 URL 为https://api.atlassian.com。这样一年后无需任何人手动更换任何东西。Atlassian 官方页面提供了精确的换取 token 请求体照抄即可。4. 第 2 步为每个事故自动创建 Jira 工单这是整条出站链路的核心。我们要在 OneUptime 里新建一个 Workflow命名为Incidents → Jira。4.1 配置触发器On Create Incident打开Flux de travail → Créer un flux de travailWorkflow → Create Workflow命名后进入画布Constructeur / Builder。点击虚线块添加触发器On Create Incident。在其Select Fields字段中声明你需要发送的列{ _id: true, title: true, description: true, incidentNumber: true, incidentSeverity: { name: true } }保持其Identifier为默认的incident-on-create-1——后续所有组件都通过这个名字引用该触发器的输出。从源码理解 Select FieldsOneUptime 基于数据库模型驱动 Workflow 触发器的字段选择。Incident 模型的字段结构位于 packages/Common/Models/DatabaseModels/触发器只会把你在 Select Fields 里勾选的字段注入返回值因此少勾一个字段后续组件就拿不到对应的引用表现为模板变量原样输出或空值。4.2 添加 API Post (JSON) 组件点击Ajouter un composant添加组件选API Post (JSON)块把触发器的Succès / 成功端口连到新块的入口设置 Identifier 为create-issueURL{{global.variables.JIRA_URL}}/rest/api/3/issueRequest Headers{ Authorization: Basic {{global.variables.JIRA_AUTH}}, Accept: application/json }Request Body{ fields: { project: { key: OPS }, issuetype: { name: Bug }, summary: OneUptime #{{local.components.incident-on-create-1.returnValues.model.incidentNumber}}: {{local.components.incident-on-create-1.returnValues.model.title}}, labels: [oneuptime], description: { type: doc, version: 1, content: [ { type: paragraph, content: [ { type: text, text: {{local.components.incident-on-create-1.returnValues.model.description}} } ] } ] } } }请把OPS换成你的项目密钥、Bug换成该项目真实存在的工单类型。两者也可以改用 ID 传参——{id: 10000}——这是 Atlassian 官方示例的写法当站点里有两个同名工单类型时务必用 ID。ID 可以从下文 4.5 的createmeta接口拿到。4.3 理解 Atlassian Document FormatADF上面的 description 之所以长得这么重是因为Jira Cloud v3 API 要求富文本使用 Atlassian Document FormatADF——它是一棵文档树不是普通字符串。上面这段是合法的 ADF 最小文档一个 paragraph 里包一个 text 节点。同样的规则适用于environment字段以及任何多行文本自定义字段单行文本自定义字段则仍然接受普通字符串。4.4 激活、验证与结果引用在Vue densemble → Modifier le flux de travailOverview → Edit Workflow中把状态切到Activé / 启用。声明一个测试事故打开Exécutions journauxExecutions Logs。create-issue块应返回201响应体包含新工单的id、key、self。两点操作提示源自文档画布上的修改自动保存没有 Save 按钮未启用的 Workflow 完全无法运行——包括手动运行。新工单的 key 可被后续任何组件引用{{local.components.create-issue.returnValues.response-body.key}}4.5 补充常用字段与字段探测在fields对象里几个高频追加项字段写法说明Prioritypriority: { id: 20000 }用你站点的优先级 ID若要做 OneUptime 严重级别→Jira 优先级映射在触发器与 API 块之间插一个If / Else块对{{local.components.incident-on-create-1.returnValues.model.incidentSeverity.name}}分支Assigneeassignee: { id: accountId }Jira Cloud 用 Atlassian accountId 标识人员username/userKey早已被 Cloud API 移除Labelslabels: [oneuptime, sev1]扁平字符串数组不能含空格Componentscomponents: [{ id: 10000 }]组件 ID 数组Custom fieldscustomfield_10034: ...值形态取决于字段类型单选列表用{value: red}多选列表用 ID 数组多行文本用 ADF 文档与其猜不如直接问 Jira。用下面两个 curl 调用探测项目真实要求# 列出某项目的工单类型 curl -u youexample.com:your_api_token \ https://your-domain.atlassian.net/rest/api/3/issue/createmeta/OPS/issuetypes # 列出某工单类型的全部字段哪些必填、customfield_NNNNN 的准确 ID curl -u youexample.com:your_api_token \ https://your-domain.atlassian.net/rest/api/3/issue/createmeta/OPS/issuetypes/10001第二个调用会给出该工单类型接受的全部字段、必填项以及精确的customfield_NNNNN标识。想读取已有工单的字段 ID用?expandnames参数拉取。5. 第 3 步把 OneUptime 事故 ID 存进 Jira双向同步的两个方向都需要某一侧持有另一侧的标识符。文档明确建议把 ID 存在 Jira 侧因为 OneUptime 的customFields列是一个扁平的 JSON blob——Workflow 从里面写入一个值会覆盖该事故的全部自定义字段代价太大。5.1 方案 A推荐自定义字段在 Jira 中新建一个短文本自定义字段命名为OneUptime Incident ID挂到项目的创建界面screen上用 4.5 的createmeta找到它的 ID然后在创建工单的请求体里一并提交customfield_10050: {{local.components.incident-on-create-1.returnValues.model._id}}5.2 方案 B无管理员权限标签没有 Jira 管理员权限时把 ID 塞进 label。label 不能含空格而 OneUptime 的 ID 是 UUID所以oneuptime-id是合法 labellabels: [oneuptime, oneuptime-{{local.components.incident-on-create-1.returnValues.model._id}}]代价入站 Workflow 需要用一个Run Custom JavaScript块从 label 列表里把 ID 抠出来两到三行代码。文档的评价是能拿到自定义字段就用字段更干净。5.3 顺手加一个返回 OneUptime的链接在create-issue之后再接一个API Post (JSON)块指向{{global.variables.JIRA_URL}}/rest/api/3/issue/{{local.components.create-issue.returnValues.response-body.key}}/remotelink请求体{ globalId: systemhttps://oneuptime.comid{{local.components.incident-on-create-1.returnValues.model._id}}, object: { url: https://oneuptime.com/dashboard/{{local.components.incident-on-create-1.returnValues.model.projectId}}/incidents/{{local.components.incident-on-create-1.returnValues.model._id}}, title: OneUptime incident #{{local.components.incident-on-create-1.returnValues.model.incidentNumber}} } }这样 Jira 里所有人都能一键跳回 OneUptime 事故页。注意需要在触发器的Select Fields里追加projectIdglobalId让这个调用可安全重复执行——Jira 会更新已带该 ID 的链接而不是再插一条因为更新会清空所有未提交的字段所以必须始终发送完整的object不能发局部补丁。自托管安装请把https://oneuptime.com/dashboard/...换成你自己的仪表盘地址。6. 第 4 步事故演变时评论并过渡工单这要做成第二个独立 Workflow命名如Incident updates → Jira理由是这个流程失败绝不能阻塞建票流程——两个职责彼此隔离。添加触发器On Update Incident。在Listen on里写{currentIncidentStateId: true}——这样触发器只在状态变化时触发而不是每次修改都触发。Select Fields里写{_id: true, currentIncidentState: {name: true}}。添加If / Else块Input 1为{{local.components.incident-on-update-1.returnValues.model.currentIncidentState.name}}Operator为Input 2为Resolved或你项目里已解决状态的准确名称。参见 États et sévérités des incidents。6.1 从Oui / 是分支找回 Jira 工单用第 3 步存的 ID 去 Jira 查询对应工单。用一个 Identifier 为find-issue的API Post (JSON)块URL{{global.variables.JIRA_URL}}/rest/api/3/search/jqlRequest Body{ jql: project OPS AND labels \oneuptime-{{local.components.incident-on-update-1.returnValues.model._id}}\, maxResults: 1 }如果第 3 步用的是自定义字段而非 labelJQL 子句相应改为cf[10050] ~ ...换成你的字段 ID。工单 ID 从此可用{{local.components.find-issue.returnValues.response-body.issues[0].id}}引用——下面所有端点既接受 key 也接受 id。关于这个端点文档特别强调三点JQL 放进请求体POST不要拼进 URL。查询串里带的值在离开 Workflow 时会被截断而 JQL 通篇都是。查询必须加边界裸写order by key desc会被400拒绝所以要带project 这样的收敛条件。必须用/rest/api/3/search/jql旧端点/rest/api/3/search已废弃并进入生命周期终点不要再用。6.2 留评论单个 API Post 块指向{{global.variables.JIRA_URL}}/rest/api/3/issue/id/commentbody 同样是 ADF 格式和 description 一样{ body: { type: doc, version: 1, content: [ { type: paragraph, content: [{ type: text, text: Resolved in OneUptime. }] } ] } }6.3 过渡工单先查后转两个调用transition 的 ID 因 Jira workflow 而异某些看板上甚至因工单而异所以必须动态查询API Get (JSON)调{{global.variables.JIRA_URL}}/rest/api/3/issue/id/transitions——返回从工单当前状态出发可用的全部 transition每个带id、name和指向目标状态的to对象。API Post (JSON)调同一个 URL 执行 transition{ transition: { id: 31 } }成功的 transition 返回204无响应体。如果不想在运行时读列表可以手动对一张处于正确状态的工单调一次接口、把 ID 硬编码进 Workflow——但要记住它绑定了该 Jira workflow管理员改动 workflow 可能会让硬编码悄悄失效。7. 入站方向从 Jira 回到 OneUptime另一半链路某人在 Jira 把工单拖到 DoneOneUptime 的事故状态要跟着变。7.1 先建好接收 WorkflowCréer un flux de travail命名Jira → OneUptime添加Webhook触发器。打开该 Workflow 的Paramètres / 设置复制clé secrète du webhookwebhook 密钥。你的回调 URL 是https://oneuptime.com/workflow/trigger/webhook secret key自托管安装用自己的主机地址。把这条 URL 当密码对待——任何拿到它的人都能启动这个 Workflow万一泄露在同一页面重新生成密钥即可。从源码看该路由正对应 WebhookTrigger.init() 注册的GET /trigger/:secretkey请求头、参数、body 会原样进入后续组件。在触发器的出口加一个If / Else在任何逻辑之前先校验共享密钥Input 1{{local.components.webhook-1.returnValues.request-headers.x-oneuptime-secret}}OperatorInput 2{{global.variables.JIRA_WEBHOOK_SECRET}}自己编一个值存成 Secret 全局变量从Oui / 是分支加Update One Incident块Query{_id: {{local.components.webhook-1.returnValues.request-body.oneuptimeIncidentId}}}Data (JSON Object)Jira 侧变更在 OneUptime 侧应产生的效果——通常是状态变更。移动事故状态需要目标状态的 ID用Find One Incident State块、查询{name: Resolved}得到{{local.components.incident-state-find-one-1.returnValues.model._id}}把它写进currentIncidentStateId。保持该 Workflow 启用。接下来给 Jira 一个可调用它的东西。7.2 用 Jira 自动化规则发送事件打开 Jira 项目自动化规则新租户在Space settings → Automation旧租户在Project settings → Automation跨项目规则走Settings → System → Global automation需要全局Administer Jira权限。Create rule触发器选Work item transitioned旧租户叫Issue transitioned并设置成进入 Done 状态时触发。务必用 transitioned 触发器不要用 Work item updatedupdate 触发器会刻意排除状态变更。添加Send web request动作Web request URL上面拿到的 OneUptime webhook URLHTTP methodPOSTHeadersContent-Type/application/json以及X-OneUptime-Secret/ 你的共享密钥。用Hide选项隐藏密钥值注意隐藏对该值不可逆且规则被导出或复制时隐藏值会丢失Web request body选Custom format完全自定义载荷{ oneuptimeIncidentId: {{issue.customfield_10050}}, issueKey: {{issue.key}}, summary: {{issue.summary}}, status: {{issue.status.name}} }如果第 3 步用的是 label 而非自定义字段就发送labels: {{issue.labels}}然后在 OneUptime 侧用Run Custom JavaScript块提取 ID。启用规则把一张测试工单拖到 Done两侧验证Jira 的规则审计日志audit log和 OneUptime 的Exécutions journaux。7.3 依赖此机制前必须知道的五个事实出站端口受限Send web request 只能访问端口 80、8080、443、6017、8443、8444、7990、8090、8085、8060、8900、9900。OneUptime Cloud 走 443 没问题自托管部署若监听非常规端口就无法被这种方式调用。没有请求签名该动作不提供 HMAC 选项。Atlassian 文档化的做法就是 HTTPS 上加共享密钥请求头——所以接收 Workflow 里那个If / Else 校验是整套安全性的核心。规则执行会计入配额Jira Cloud 按订阅计划扣减每月成功执行次数——Free 100 次、Standard 1700 次、Premium 1000 × 用户数、Enterprise 无限。繁忙项目的每次 transition 都会消耗配额量大了要掂量。值不会被自动做 URL 编码只有发 form-encoded body 时才有影响上面的 JSON 载荷无此问题。Atlassian 会公布出站 IP 段ip-ranges.atlassian.com如果你的 OneUptime 部署在 IP 白名单后面这些段会变化应订阅其 feed 而不是固化地址。7.4 替代方案Jira 原生 WebhookJira 管理员也可以直接在Settings → System → Advanced → WebHooks注册 webhook选择要投递的事件并可加一条 JQL 过滤涉及的工单。与自动化规则对比载荷是 Jira 的不是你的包含webhookEvent、issue_event_type_name、完整issue对象以及changelog其items数组给出每个被改字段的前后值。状态变更对应field为status的那条记录。要在 Workflow 里解析它通常需要Run Custom JavaScript块。webhook 可以签名但 Workflow 验不了给 webhook 配一个 secret 后Jira 会发送X-Hub-Signature头请求体 HMAC。但签名覆盖的是 Jira 发送的原始字节而 OneUptime 的 Webhook 触发器交给 Workflow 的是已解析成 JSON 的对象——没有字节可哈希。想认证请求就用自动化规则 共享密钥头的方案。URL 必须走 HTTPS 且端口在 Jira 专属列表内与自动化规则的端口列表不同80 不在其中。投递失败最多重试 5 次间隔 515 分钟——所以接收 Workflow 必须容忍同一事件收到两次幂等。另外要注意应用通过/rest/api/3/webhook注册的 webhook 是另一回事——注册后 30 天不刷新就过期管理员在界面上注册的则不过期。8. Jira Data Center 适配自托管 Jira 的工作方式相同只有几处替换。Jira Server 已于 2024 年 2 月结束支持、不再有补丁——自托管请把 Data Center 当作目标版本。CloudData Center/rest/api/3/.../rest/api/2/...—— Data Center 没有 v3description用 ADF 文档description用 wiki markup 纯字符串Authorization: Basic base64(email:api_token)Authorization: Bearer personal access token令牌来自 id.atlassian.com在Profile → Personal access tokens → Create token创建自动化动作Send web request自动化动作Send outgoing web request于是创建工单的块变成对/rest/api/2/issue的POST{ fields: { project: { key: OPS }, issuetype: { name: Bug }, summary: OneUptime #123: Checkout is down, description: Plain text goes straight in here. } }——没有文档树建模更简单。8.1 其余差异清单Personal access tokens自 Jira Core / Jira Software 8.14、Jira Service Management 4.15 起可用。默认 365 天过期到期前 5 天界面会标注Expires soon。Data Center 仍支持用户名密码的 Basic auth但几次失败登录会触发 CAPTCHA把账号彻底挡在 REST API 之外、直到有人在浏览器里人工解锁——这不是发现拼写错误的好方式请优先用 token。自动化已内建自 Jira Data Center 10.0 起内置此前是独立插件 Automation for Jira。其出站请求默认超时 3000 ms可用属性outgoing.webhook.timeout.ms调整。Webhooks在Administration → System → Advanced → WebHooks注册支持 JQL 过滤。务必把过滤器收窄Jira 会在触发事件的执行线程上对每个已注册 webhook 求值 JQL十几个宽泛过滤器会拖慢触发它们的用户操作。Data Center 10.0 起 webhook 投递是异步的没有同步选项——事件可能乱序到达接收 Workflow 要做到幂等。Jira 10 移除了 webhook URL 变量里的$——${issue.id}变成{issue.id}——并把 webhook REST 资源从/rest/webhooks/1.0/webhook移到/rest/jira-webhook/1.0/webhooks。9. 同样的套路搬到 Alert告警上面全部围绕 Incident事故展开因为这是最常见的场景但Alert告警的用法一模一样——只换记录类型其他不动IncidentAlertOn Create Incidentincident-on-create-1On Create Alertalert-on-create-1On Update Incidentincident-on-update-1On Update Alertalert-on-update-1incidentNumber、currentIncidentState、incidentSeverityalertNumber、currentAlertState、alertSeverityFind One Incident StateFind One Alert StateUpdate One IncidentUpdate One Alert注意一个 Workflow 只能有一个触发器所以 Incident 和 Alert 各需一个 Workflow。如果两者要做完全相同的处理把 Jira 那一半建成一个 Workflow再用Execute Workflow组件从两边调用它。10. 排障手册先打开Exécutions journaux里失败的块Jira 返回的 JSON 响应体会精确指出它拒绝了什么API 组件会把响应体保留在response-body里供你检视。症状排查方向401 Unauthorized用printf重新编码email:api_token并更新JIRA_AUTH——echo带出的换行符是最常见原因。确认 token 所属账号在该项目有建票权限。Data Center 上检查是否错发了Basic而不是Bearer400 Bad Request且点名某个字段工单类型在该项目不存在或项目有必填字段未提交。对项目和工单类型跑一遍 4.5 的createmeta调用逐项比对400且抱怨descriptionCloud v3 上 description 必须是 ADF 文档而非字符串。要么发送前文展示的文档结构要么把该块切到/rest/api/2/issue发纯文本404 Not Found检查 Base URL 和 API 版本Cloud 用/rest/api/3/...Data Center 用/rest/api/2/...429 Too Many RequestsJira 限流。响应带Retry-After秒和RateLimit-Reason命中的限制名。同一工单的写入限制很紧约 2 秒内 20 次连续评论 过渡容易单票触发。在调用间加Delay块或把批量工作挪到定时 Workflow过渡调用返回400transition ID 对工单当前状态无效。重新拉该工单的/transitions用响应里的 ID自动化规则显示成功但 OneUptime 没动静先查端口见 7.3 受限列表。再用curl手动向 webhook URL 发一条请求看是否出现在Exécutions journaux你的能到而 Jira 的不到问题在 Jira 侧Workflow 跑了但事故没变Update One Incident块在查询没命中时报告Items Updated: 0这被算作成功而非错误。确认载荷里的 id 确实是 OneUptime 事故 ID且查询的是_id字段{{...}}引用原样出现在 Jira 工单里未解析的引用会被当作纯文本原样传过去而不是清空。运行日志会点名所有未解析的引用——通常是块 Identifier 拼错或变量被改名11. 延伸阅读Vue densemble des intégrations集成总览 —— 出入站模式与认证速查表Microsoft Dynamics 365 集成 —— 同样的双向构造用在 Dynamics 上Workflow 概述 与 创建 Workflow —— 画布、Identifier、激活机制Workflow 组件 —— API 块、If / Else 与 OneUptime 数据组件Workflow 变量 —— Secret 管理以及从上一块读取输出Workflow 配置与安全 —— webhook 安全与出站网络访问ServiceNow 与 PagerDuty —— 同样的出站模式用在其他工具上仓库内实现参考法语原文文档packages/App/FeatureSet/Docs/Content/fr/integrations/jira.mdWebhook 触发器实现packages/Common/Server/Types/Workflow/Components/Webhook.tsWebhook 组件元数据packages/Common/Types/Workflow/Components/Webhook.tsWorkflow 更新/触发 APIpackages/App/FeatureSet/Workflow/API/Workflow.tsWorkflow 组件文档目录packages/App/FeatureSet/Workflow/Docs/ComponentDocumentation/赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime × Jira 双向集成实战用 Workflow 与 REST API 打通事故和 Issue 的双向同步OneUptime × Jira 双向集成实战用 Workflow 与 REST API 打通事故和 Issue 的双向同步 本篇基于 OneUptime 官可观测性后端运维前端云原生微服务AI AgentReact Router v8 到 v9 升级指南Future Flags 与 Future Changes 全解析React Router v8 到 v9 升级指南Future Flags 与 Future Changes 全解析 React Router 借助 Futu可观测性后端运维前端云原生微服务AI AgentOneUptime 与 PagerDuty 集成实战通过 Workflow 将事件双向打通OneUptime 与 PagerDuty 集成实战通过 Workflow 将事件双向打通 本指南讲解如何在 OneUptime 中通过 Workflow 与可观测性后端运维前端云原生微服务AI Agent上一篇告别监控数据泄露Frigate隐私保护全攻略下一篇彻底解决F5-TTS爆音问题从原理到优化的全流程指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考