可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载导读本指南讲解如何在 OneUptime 中接入 Grafana把 Grafana 告警规则产生的告警自动转化为 OneUptime 的 Incident事件并纳入 on-call 值班升级与自动恢复闭环。文章基于 OneUptime 官方集成文档展开结合仓库源码深入剖析入站 Webhook → 过滤 → 按字段分组 → 生成/恢复 Incident的底层机制。读完你将掌握两种接入方案Incoming Request 监控器与 Workflow、Grafana Contact point 的完整配置、分组路径的坑点规避以及故障排查方法。集成原理与适用场景OneUptime 的 Grafana 集成属于**入站inbound**模式由 Grafana 一侧的Webhook Contact point向 OneUptime 发送POST请求OneUptime 接收后将告警记录、升级并跟踪为 Incident。Grafana alert rule fires ──► Webhook contact point ──► OneUptime ──► Incident on-callGrafana 的 webhook 负载遵循 Alertmanager 的负载结构——包含status、alerts数组、commonLabels、commonAnnotations以及方便使用的顶层title和message字段。OneUptime 提供两种接收方式选择取决于你的需求方案适用场景Incoming Request 监控器推荐希望告警直接变成 Incident支持 on-call 升级、一条告警对应一个 Incident、并在恢复时自动解析。Workflow Webhook 触发器需要 OneUptime 原生不具备的路由逻辑调用其他系统、重塑负载、条件分支等。前置条件Grafana 9且启用 unified alerting现代 Grafana 的默认行为。Grafana 能通过HTTPS访问你的 OneUptime 实例自托管时使用你自己的域名/主机。一个可以在其中创建监控器或 Workflow的 OneUptime 项目。方案一使用 Incoming Request 监控器推荐该方案把 Grafana 的每条告警映射为独立的 Incident并在告警恢复时自动关闭对应 Incident无需维护任何自定义逻辑。核心配置分四步创建监控器、设置过滤条件、配置按字段分组、写 Incident 标题与描述。第 1 步创建监控器并获取 URL进入Monitores监控器→ Crear monitor创建监控器选择Solicitud entranteIncoming Request。打开监控器点击左侧菜单的Documentation文档复制监控器 URL格式形如https://你的OneUptime/heartbeat/SECRET_KEY密钥位于 URL 路径中是唯一的鉴权凭证。第 2 步设置过滤条件Criteria打开监控器的Criteria条件配置Filter Type过滤类型JavaScript ExpressionValue值{{requestBody.status}} firing这条 JavaScript 表达式判断 webhook 负载顶层的status是否为firing占位符两侧的引号是字符串比较所必需的。若不想用表达式也可改用Request Body/Contains过滤值为status:firing。从源码看这类过滤由 IncomingRequestCriteria.ts 处理RequestBody会被序列化为字符串后执行Contains/NotContains判断而 JavaScript 表达式则由监控器条件求值器见 MonitorCriteriaEvaluator.ts在隔离 VM 中执行命中时产生JavaScript Expression - ... - evaluated to true的判定结果。第 3 步声明 Incident 并开启自动恢复在条件命中时开启When filters match, declare an incident匹配时声明事件并设置标题、**Severity严重级别**与需要呼叫的On-Call Policies值班策略。在Advanced Options高级选项中开启Auto Resolve Incident自动恢复事件。如果不开启恢复通知会被忽略Incident 将永远保持打开。第 4 步按负载字段分组在Settings设置中开启Group incidents and alerts by a payload field按负载字段分组事件与告警并按下表配置字段值Open a separate incident for each…为每个……单独打开一个事件requestBody.alerts[*].fingerprintField that signals recovery标识恢复的字段requestBody.alerts[*].statusValue that means recovered表示已恢复的值resolved这样每个不同的分组值都会成为独立 Incident且当 Grafana 上报其为resolved时各自关闭。Grafana 的 per-alertfingerprint对该告警的标签集唯一因此它是上述分组路径的理想选择。分组机制的源码原理OneUptime 的分组功能由 IncomingRequestIncidentGrouping.ts 实现。其核心逻辑collectFiringMatches会从dataToProcess中解析请求体为 JSON 对象getRequestBodyObject兼容预解析对象与原始 JSON 字符串两种入站路径见 L44-L73按groupByJSONPath提取每个 key把提取值哈希为与指标监控器 per-series Incident 相同的seriesFingerprint去重键对标记为isResolved的 key跳过不创建 IncidentL117-L120而对恢复的 key 通过collectResolvedFingerprints显式关闭——事件驱动模型下只有负载中明确声明为resolved的 key 才会被关闭绝不因key 缺席而误关。配置类型定义见 IncidentGroupingConfig.tsgroupByJSONPath支持点路径、数组索引[0]、[last]以及单个[*]通配符做扇出resolvedWhenJSONPath/resolvedWhenValue即为上表中恢复字段/恢复值的底层实现。第 5 步设置 Incident 标题与描述标题Title{{requestBody.commonLabels.alertname}}描述Description{{requestBody.message}}或{{requestBody.commonAnnotations.summary}}注意{{fingerprint}}变量虽可引用它取自分组路径的最后一段但它是一个哈希值不适合展示给响应人员。commonLabels/commonAnnotations承载跨整个通知共享的字段而requestBody.alerts[0].annotations.summary这类 per-alert 路径始终读取的是负载中第一条告警而非本 Incident 对应的那条因此若希望每个 Incident 携带各自的注释文本务必收紧 Grafana 侧的分组。无法解析的路径会原样打印连花括号一起而不是留空。⚠️ 警告分组路径的三大陷阱静默失败文档明确警告以下三点它们都会静默失败不报错但行为不符合预期不要按通知内恒定不变的标签分组Grafana 默认通知策略按grafana_folder和alertname分组因此同一 webhook 内的所有告警共享 alertname——若按requestBody.alerts[*].labels.alertname分组会把整个负载折叠成一个 Incident。请改用requestBody.alerts[*].fingerprint。分组路径必须以字面量requestBody.开头否则无法解析。一条路径中只有第一个[*]是通配符后续的[*]不生效。第 6 步指向 Grafana Contact point将 Grafana 的 contact point 指向监控器 URL具体见下文配置 Grafana Contact point。方案二使用 Workflow Webhook 触发器当需求超越一条告警变成一个 Incident例如需要调用第三方系统、重塑负载、按severity分支路由时使用 Workflow。第 1 步构建 OneUptime Workflow打开Flujos de trabajoWorkflows→ Crear flujo de trabajo创建 Workflow命名为Grafana → Incidents打开Constructor构建器。添加Webhook触发器并复制其 URL。将块重命名为Grafana。连接一个Condiciones条件块到触发器Izquierda左值{{Grafana.Request Body.status}}Operador操作符Derecha右值firing从Sí是分支添加Crear incidente创建事件块Título标题{{Grafana.Request Body.title}}Descripción描述{{Grafana.Request Body.message}}Severidad严重级别选择一个或先基于{{Grafana.Request Body.commonLabels.severity}}做分支。Guarda保存测试前保持禁用状态。Workflow 触发器的 URL 机制可参考 workflows/triggers.md 文档。第 2 步恢复Resolve逻辑当告警恢复时Grafana 会发送另一条status: resolved的通知。对方案二添加第二条Condiciones分支status resolved查找匹配的 Incident并用Update Incident块将其移动到已解决状态。配置 Grafana Contact point两种方案通用无论使用哪个方案Grafana 侧的配置相同在 Grafana 中进入Alerting → Contact points → Add contact point。Name名称OneUptimeIntegration集成类型Webhook。URL地址粘贴方案一的监控器 URL或方案二 Workflow 的 webhook URL。HTTP Method方法POST。保存 contact point。进入Alerting → Notification policies将你想要路由的告警或默认策略指向OneUptimecontact point。由于 Grafana 负载结构与 Alertmanager 相同Prometheus Alertmanager 集成 文档中的配置细节如send_resolved: true、恢复通知判定等同样适用于本集成。测试集成若构建了 Workflow先启用它。在 Grafana contact point 页面使用Test测试发送一条示例通知或等待真实告警规则触发。检查 OneUptime 的IncidentesIncidents列表若使用方案二还可查看 Workflow 的RegistrosLogs标签页源码层面OneUptime 会在请求入站后先返回一个空的200再执行校验与条件求值。告警恢复时的自动解析告警平静后Grafana 发送status: resolved的通知方案一上面配置的恢复字段与恢复值会自动关闭对应 Incident——前提是Auto Resolve Incident已开启。恢复判断是逐告警进行的若某个负载中一条告警已恢复、另外两条仍在 firing只有已恢复的那条对应的 Incident 会被关闭这得益于[*]在两个路径上同时扇出见 IncomingRequestIncidentGrouping.ts 的实现。方案二需要额外添加status resolved的条件分支通过Update Incident关闭。注意事项旧版告警Grafana 8 及更早发送的是不同的负载结构ruleName、state、evalMatches。若使用旧版告警请改用{{Grafana.Request Body.ruleName}}与{{Grafana.Request Body.state}}并以state alerting做分支。也可以完全绕过 Grafana 的告警让 OneUptime 直接监控同样的指标——参见 Metrics Monitor指标监控器。故障排查Troubleshooting现象原因与解决方法什么都没收到确认 Grafana 能访问该 URL查看 Grafana 服务器日志方案二需确认 Workflow 已Habilitado启用。注意 OneUptime 在验证负载之前就会对每个入站请求返回空200因此 Grafana 日志中的200并不代表负载已被接受。Incident 打开后永不关闭检查条件中的恢复字段与恢复值以及 IncidentAdvanced Options中的Auto Resolve Incident是否开启。该比较区分大小写。负载里有大量告警却只有一个 Incident你按通知内不变的标签分组了。改为按requestBody.alerts[*].fingerprint分组。Incident 文本显示原始{{...}}占位符路径未解析成功未解析的占位符会原样保留而非置空。请引用你的告警版本中真实存在的字段若用方案二可在RegistrosLogs标签页检查触发器输出。延伸阅读Incoming Request 监控器——该监控器类型、条件与 Incident 分组的完整说明。集成总览——入站模式概览。Prometheus Alertmanager 集成——负载结构高度相关含完整的curl测试示例。Metrics Monitor指标监控器——直接在 OneUptime 中监控指标。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime 与 Grafana 集成指南将告警转为可升级、可自动恢复的事故IncidentOneUptime 与 Grafana 集成指南将告警转为可升级、可自动恢复的事故Incident Grafana 负责评估仪表板上的告警规则OneUp可观测性后端运维前端云原生微服务AI Agent在 OneUptime 中集成 Grafana将告警转化为带值守升级与自动恢复的 Incident在 OneUptime 中集成 Grafana将告警转化为带值守升级与自动恢复的 Incident 导读 本文以 OneUptime 官方文档中《Intégr可观测性后端运维前端云原生微服务AI AgentOneUptime 接入 Prometheus Alertmanager把告警通知转化为带告警升级与自动恢复的 Incident 实战指南OneUptime 接入 Prometheus Alertmanager把告警通知转化为带告警升级与自动恢复的 Incident 实战指南 导读 本文介绍如何可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考