可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本指南讲解 OneUptime 的 GitHub 出站outbound集成当 OneUptime 中创建一条 Incident 时自动调用 GitHub REST API 在承载受影响服务的仓库中打开一条 GitHub Issue让工程跟进工作直接落在代码仓库里。读完本文你将掌握基于Incident → On Create 触发器 API 组件构建 Workflow 的完整流程、Token 与密钥管理方式、常见错误码排查方法以及该集成在 OneUptime 源码中的底层实现原理。集成模式出站Outbound还是入站InboundOneUptime 的集成统一走Workflows自动化引擎无需安装独立插件直接在拖拽画布上把积木式组件连起来即可。所有集成按数据流动方向分为两类详见 集成总览入站Inbound外部工具把数据推入 OneUptime例如 Zabbix / Prometheus / Grafana 通过 Webhook 触发创建 Incident。出站OutboundOneUptime 把数据发送到外部工具例如创建 Jira 工单、在 PagerDuty 分页、往 Slack 发消息——以及本文的 GitHub Issue。本集成属于典型的出站模式OneUptime 调用 GitHub REST API 的POST /repos/{owner}/{repo}/issues端点用一条带Incident → On Create触发器和一个API 组件的 Workflow 实现OneUptime Incident → On Create ──► API component (POST /repos/{owner}/{repo}/issues) ──► GitHub issue需要说明OneUptime 另有一个更深的GitHub App 原生集成用于连接代码仓库供 AI Agent 与代码相关功能使用可以在 issue 或 pull request 中 它来实施、修改或审查代码参见 从 GitHub 使用 OneUptime 与 GitHub 集成自托管。本页专讲从 Incident 登记 Issue这一场景。前置条件开始之前需要准备三样东西一个 GitHub 仓库用来登记 issue需确认你对其有写入权限。一个能创建 issue 的 Token二选一细粒度 PATfine-grained PAT授予该仓库作用域权限勾选Issues: Read and write经典 PATclassic PAT拥有repo作用域。两者均在 github.com/settings/tokens 创建。一个 OneUptime 项目拥有可创建 Workflow 的权限。触发器与组件的底层原理源码视角在动手配置前先理解这条 Workflow 在 OneUptime 源码中如何被实现有助于后续排错。Incident 模型声明了 Workflow 能力Incident 数据模型通过EnableWorkflow装饰器显式声明了它可以作为 Workflow 触发事件// packages/Common/Models/DatabaseModels/Incident.ts#L111-L116 EnableWorkflow({ create: true, delete: true, update: true, read: true, })create: true意味着当一条 Incident 被创建时会触发注册在该模型上的on-create触发器。从源码结构看这正是Incident → On Create触发器的注册依据。On Create 触发器如何被注册与触发Workflow 组件注册表会遍历所有启用 Workflow 的数据库服务为每个模型动态注册一组触发器与操作组件// packages/Common/Server/Types/Workflow/Components/Index.ts#L81-L91 if (model.enableWorkflowOn.create) { Components[${modelId}-on-create] new OnCreateBaseModel( baseModelService as any, ); ... }其中OnCreateBaseModel就是 Incident 触发器的实现类其构造参数中的on-create字符串即触发类型标识// packages/Common/Server/Types/Workflow/Components/BaseModel/OnCreateBaseModel.ts export default class OnCreateBaseModel TBaseModel extends BaseModel, extends OnTriggerBaseModelTBaseModel { public constructor(modelService: DatabaseServiceTBaseModel) { super(modelService, on-create); } }从OnTriggerBaseModel的实现packages/Common/Server/Types/Workflow/Components/BaseModel/OnTriggerBaseModel.ts可以看到触发执行的真实调用链initTrigger收到事件后先按triggerId projectId isEnabledtrue查询所有已启用的 Workflow再把事件数据交给 Workflow 运行器逐条执行触发器向后续组件输出的核心返回值为model即整条 Incident 的 JSON 表示后续 API 组件即可通过变量引用取用其中的title、description等字段。API 组件出站请求的载体Workflow 中的 API 组件在源码中对应一组按 HTTP 方法拆分的实现类GET / POST / PUT / PATCH / DELETE位于packages/Common/Server/Types/Workflow/Components/API/。以ApiPostPost.ts为例它执行一次POST请求并按结果走两个端口成功端口success2xx 响应返回response-status、response-body、response-headers错误端口error非 2xx 或网络失败返回同样的三个字段外加error消息。// packages/Common/Server/Types/Workflow/Components/API/Utils.ts return { response-status: response.statusCode, response-body: response.jsonData, response-headers: response.headers, error: null, };这正是文档中201 Created表示 issue 创建成功、响应体里能读到number和html_url的源码依据。此外Utils.ts中sanitizeArgs会先对 URL 做 SSRF 防护校验validateWebhookTargetIsSafe再把 headers 统一扁平化为字符串最后才发起请求——从源码注释看这是为了防止 API 组件被当作代理访问云元数据端点等内网地址。第 1 步保存 Token 为全局变量Token 绝不能直接粘贴进 API 组件的 Header 里而应存为全局变量并开启Secret进入Flows/工作流 → 全局变量Global Variables→ 创建命名为GITHUB_TOKEN粘贴 Token打开Is Secret开关。关于全局变量的字段与命名规则参见 Workflow 变量文档变量名至少 2 个字符、不含空格、仅允许字母数字与连字符/下划线Secret开启后值会在运行日志与步骤追踪中被抹除。为什么必须用 Secret 变量源码中有专门的密钥脱敏模块负责这一点运行日志写出前会把所有isSecret变量的明文值替换为[REDACTED]且按最长的密钥优先排序处理避免较短的密钥替换后暴露出较长密钥的剩余部分// packages/App/FeatureSet/Workflow/Utils/SecretRedaction.ts export const WORKFLOW_LOG_REDACTED_VALUE: string [REDACTED]; // getSecretValuesForRedaction 对密钥排序后 // redactSecretsFromString 用单个全局正则一次性替换所有出现位置因此即使请求失败GITHUB_TOKEN的明文也不会出现在 Workflow 日志里。第 2 步构建 Workflow打开工作流 → 创建 Workflow命名例如Incidents → GitHub Issues进入Builder画布添加Incident触发器触发条件设为On Create把它重命名为Incident便于在变量里引用添加一个API组件连接到触发器按下表配置配置项值MethodPOSTURLhttps://api.github.com/repos/tu-org/tu-repo/issues将tu-org/tu-repo换成你的组织与仓库名Headers请求头Authorization: Bearer {{global.variables.GITHUB_TOKEN}} Accept: application/vnd.githubjson X-GitHub-Api-Version: 2022-11-28 User-Agent: OneUptime变量语法说明西班牙语文档写作{{variable.GITHUB_TOKEN}}当前仓库英文文档统一采用{{global.variables.NAME}}形式见 变量文档两者语义一致配置时以你界面中全局变量的实际名称为准。建议开启 Secret 后始终通过变量引用避免密钥出现在画布或日志中。Body请求体{ title: OneUptime incident: {{Incident.title}}, body: {{Incident.description}}\n\nFiled automatically from OneUptime., labels: [incident, oneuptime] }其中{{Incident.title}}与{{Incident.description}}引用的是 Incident 触发器输出的model字段。在画布上更稳妥的做法是使用编辑器内置的组件值选择器插入触发器输出生成形如{{local.components.incident-on-create-1.returnValues.model.title}}的完整引用具体语法见 变量文档 的组件输出一节。保存并启用 Workflow然后创建一条测试 Incident 验证。若 Workflow 运行日志中出现201 Created说明 issue 已创建成功响应体里会包含新 issue 的number与html_url可用于后续回写。进阶技巧GitHub Enterprise Server自建 GitHub把 URL 换成https://tu-host/api/v3/repos/{owner}/{repo}/issues即可其余配置不变。指定负责人 / 里程碑在 Body 中追加assignees: [octocat]或milestone: 3。回链到 Incident读取 API 组件输出的{{CreateIssue.response-body.html_url}}再添加一个Update Incident组件把它写回 Incident 上例如存进某个自定义字段或描述让 Incident 与 GitHub Issue 双向可追溯。从ApiPost的返回值实现看见上文源码response-body就是 GitHub 响应 JSON 的完整对象html_url字段可直接取用。故障排查Troubleshooting按 GitHub REST API 的响应码对症处理401—— Token 错误或已过期。细粒度 PAT 必须显式勾选目标仓库与Issues权限仅授权其他仓库会导致此错误。403/ 触发限流rate limit—— 必须携带User-Agent请求头GitHub 会拒绝无此头的请求同时检查是否触发了 API 限流。文档中的 Headers 示例已包含User-Agent: OneUptime。404——owner/repo路径写错或 Token 无权访问私有仓库。422—— 引用了不存在的标签没关系GitHub 会自动创建被引用的标签但请求体格式错误会报此码——请检查 JSON 是否合法。title为必填字段。另外注意API 组件会把 4xx/5xx 响应导向错误端口而不是成功端口见 Post.ts 中HTTPErrorResponse的分支处理所以排查时除了看状态码还要检查错误分支是否连接了后续处理块如日志组件否则失败可能无声无息。自托管部署的网络要求若你是自托管 OneUptime本集成需要 OneUptime 能够向api.github.com发起出站DNS 解析与 HTTPSTCP 443连接它不需要GitHub 向 OneUptime 发起任何入站回调。对于出站连接、入站回调与私有化部署的完整网络访问说明参见 GitHub 集成自托管。延伸阅读集成总览——出站/入站两种模式、认证速查表与密钥处理规范GitLab 集成——同样的思路对接 GitLabPRIVATE-TOKEN/api/v4/projects/{id}/issuesWorkflow 总览——自动化引擎的整体工作方式Workflow 组件——API 组件的设置项与输出说明Workflow 触发器——Webhook 与 OneUptime 事件触发器详解Workflow 变量——全局变量、Secret 与组件输出引用语法GitHub 集成自托管——GitHub App 原生连接代码仓库管理场景从 GitHub 使用 OneUptime——在 issue / PR 中直接向 GitHub App 下达指令。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime × GitHub 集成用 Workflow 让每个 Incident 自动创建 GitHub IssueOneUptime × GitHub 集成用 Workflow 让每个 Incident 自动创建 GitHub Issue 本文基于 OneUptime 官可观测性后端运维前端云原生微服务AI AgentOneUptime 与 GitHub 集成实战用 Workflow 将 Incident 自动转化为 GitHub IssueOneUptime 与 GitHub 集成实战用 Workflow 将 Incident 自动转化为 GitHub Issue 本篇指南讲解 OneUptim可观测性后端运维前端云原生微服务AI AgentOneUptime × GitLab 集成实战用 Workflow 在 Incident 创建时自动提交 GitLab IssueOneUptime × GitLab 集成实战用 Workflow 在 Incident 创建时自动提交 GitLab Issue 这篇技术指南讲解如何在 O可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
