Coroot 与 PagerDuty 集成指南基于 Events API V2 的告警、SLO 事件与值班通知实战【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot本指南以 Coroot 项目中的官方集成文档 docs/docs/alerting/pagerduty.md 为主体完整讲解如何在 PagerDuty 账号中创建Events API V2集成、在 Coroot 的Project Settings → Integrations中完成配置并通过源码级分析说明通知的触发、负载内容、去重与重试机制。读完本文你将掌握从 PagerDuty 服务目录创建集成、到 Coroot 侧粘贴 Integration Key、再到发送测试告警验证全链路可用的完整流程并理解 Coroot 在触发trigger与解决resolve事件时的底层实现。一、集成原理概览Coroot 如何向 PagerDuty 发送事件Coroot 的通知体系抽象为统一的NotificationClient接口定义于 notifications/notifications.go包含三个方法SendIncident发送 SLO 事件Incident通知SendAlert发送告警规则Alerting Rule触发的告警通知SendDeployment发送部署通知PagerDuty 集成不支持该能力。PagerDuty 集成对应的实现类是Pagerduty见 notifications/pagerduty.go它只保存一个integrationKey字段即你在 PagerDuty 控制台创建的Events API V2集成密钥。Coroot 底层使用 PagerDuty 官方 Go SDKgithub.com/PagerDuty/go-pagerduty调用ManageEventWithContext发送事件。从源码结构看PagerDuty 通知在 Coroot 中覆盖两类场景IncidentsSLO 事件当应用违反 SLO、或 SLO 事件的状态发生变更WARNING / CRITICAL / 恢复时触发Alerts告警规则当自定义告警规则如 PromQL 表达式告警触发或恢复时发送。而部署通知对 PagerDuty 明确返回not supported见 notifications/pagerduty.go因此前端表单中Deployments选项对 PagerDuty 集成是置灰不可选的。二、在 PagerDuty 账号中创建 Events API V2 集成配置的第一步是在 PagerDuty 侧创建集成。按照 docs/docs/alerting/pagerduty.md 的步骤执行登录 PagerDuty导航到Services → Service Directory选择目标服务target service或点击 New Service创建一个新服务进入该服务的Integrations选项卡点击 Add another integration添加集成在集成类型列表中选择Events API V2Events API v2 是 PagerDuty 当前的推荐事件协议支持自动去重、事件分组与状态变更如有需要修改Integration Name例如命名为Coroot便于在多集成中区分来源复制页面展示的Integration Key32 位十六进制格式后续粘贴到 Coroot 中。完成上述操作后PagerDuty 侧已具备接收 Coroot 事件的入口Integration Key 是两者之间的唯一认证凭据。三、在 Coroot 中配置 PagerDuty 集成3.1 配置入口与表单字段在 Coroot Web 界面中进入Project Settings → Integrations创建一条Pagerduty类型的集成将上一步复制的Integration Key粘贴到表单中。Coroot 前端的 PagerDuty 集成表单实现在 front/src/components/IntegrationFormPagerduty.vue核心字段如下字段说明可选值 / 约束Integration KeyPagerDuty Events API V2 集成密钥必填不能为空前端使用$validators.notEmpty校验Incidents是否接收 SLO 事件通知复选框默认勾选与否取决于集成配置Deployments部署通知始终禁用PagerDuty 不支持部署通知Alerts是否接收告警规则通知复选框对应的后端数据结构为IntegrationPagerduty见 db/integrations.gotype IntegrationPagerduty struct { IntegrationKey string json:integration_key yaml:integrationKey Incidents bool json:incidents yaml:incidents Alerts *bool json:alerts,omitempty yaml:alerts,omitempty }其中Alerts是指针类型兼容旧版本配置中未显式声明 alerts 开关的情况Validate()方法要求IntegrationKey非空否则校验失败并返回invalid pagerduty configuration: integration key is required。配置完成后的界面示意如下3.2 前置条件Base URL在 db/integrations.go 的NotificationIntegrations.Validate()中所有通知类集成都要求配置Base URL即 Coroot 自身的对外访问地址。该地址用于构造事件负载中的ClientURL链接使 PagerDuty 中显示的每条事件都能直接跳回 Coroot 的对应告警/事件页面事件详情跳转{baseUrl}/p/{projectId}/incidents?incident{incidentKey}见 notifications/notifications.go告警详情跳转{baseUrl}/p/{projectId}/alerts?alert{alertId}见 notifications/alerts.go。因此请确保项目设置中已正确填写 Coroot 的对外 Base URL否则集成校验无法通过。四、发送测试告警验证集成配置完成后建议立即发送一条测试通知以验证整条链路。在 Coroot 集成配置页面点击发送测试按钮即可测试通知的后端实现位于 api/forms/forms.go 的SendTestNotification。当表单携带test.incident字段且项目中已配置 PagerDuty 集成时Coroot 会实例化NewPagerduty(integrations.Pagerduty.IntegrationKey)并调用SendIncident发送一条测试事件对应 API 入口在 api/api.go。测试事件同样会走真实的 PagerDuty Events API V2 通道因此能可靠验证Integration Key 是否有效Coroot 到 PagerDuty 的网络连通性PagerDuty 服务是否成功接收并创建对应事件/告警。若测试通过PagerDuty 中应能看到来自Coroot的测试事件随后可进入下一步验证真实告警的触发与恢复。五、PagerDuty 通知的实际发送与消息内容源码级5.1 事件协议trigger 与 resolveCoroot 发送的是 PagerDuty Events API V2 的trigger/resolve两类动作核心实现在 notifications/pagerduty.go 与 notifications/pagerduty.go当通知状态为model.OK事件已恢复时发送resolve事件并携带与触发时相同的DedupKey用于关闭 PagerDuty 中对应的打开事件否则发送trigger事件事件负载中包含Client固定为Coroot、ClientURL跳回 Coroot 详情页、Payload等字段。5.2 DedupKey自动去重与状态关联Coroot 利用 PagerDuty 的去重键DedupKey将同一条 Coroot 事件的多次状态变更关联为 PagerDuty 中的同一事件Incident 事件的去重键格式为{projectId}:{incidentKey}:{severity}Alert 告警的去重键格式为{projectId}:{alertId}:{severity}。以 SLO 事件为例见 notifications/incidents.goCoroot 会跟踪同一事件在 WARNING 与 CRITICAL 两个严重级别下的打开状态事件升级为WARNINGtrigger一条 WARNING 事件事件升级为CRITICAL先resolve已打开的 WARNING 事件再trigger一条 CRITICAL 事件事件恢复同时resolve所有仍处于打开状态的 WARNING / CRITICAL 事件。告警Alert的通知逻辑与之类似见 notifications/alerts.gotrigger时记录打开的去重键resolve时携带该键关闭 PagerDuty 事件从而保证 PagerDuty 不会出现告警已恢复但事件仍打开的脏状态。5.3 事件负载内容IncidentSLO 事件的V2Payload结构见 notifications/pagerduty.go字段内容Summary[CRITICAL] my-app is not meeting its SLOs形式严重级别为大写Source固定为CorootSeverity事件严重级别critical / warning取自事件状态字符串Timestamp事件时间戳Details明细字典包含各检查报告格式报告名 / 检查项 → 消息、Root CauseAI 根因摘要与Remediations修复建议最长截断 2000 字符其中Root Cause与Remediations来自 Coroot 的 AI 根因分析RCA结果只有当事件附带 RCA 且状态为 OK 时才填充见 notifications/notifications.go。Alert告警规则的V2Payload结构见 notifications/pagerduty.go字段内容Summary[CRITICAL] app-name: 告警摘要形式应用名缺失时回退为规则名Source固定为CorootSeverity告警严重级别Details明细字典包含Project项目名、Alerting rule规则名以及规则自定义的详情键值对值得注意的是告警明细在入队前会经过filterAlertDetails过滤剔除PromQL与PromQLChart两类内部详情见 notifications/alerts.go避免把冗长的查询语句直接推送到 PagerDuty。5.4 发送失败的重试机制Coroot 的通知发送采用入队 定时重试模型见 notifications/notifications.go单次发送超时时间为30 秒sendTimeout未发送成功的通知由后台定时器每隔1 分钟retryInterval重试仅重试最近1 小时retryWindow内的未发送通知超过窗口即放弃。在 notifications/incidents.go 的发送循环中同一目标集成首次发送失败后会标记为失败并跳过本批次其余通知避免对 PagerDuty API 造成突增请求。六、通知范围控制结合应用类别Application Category管理PagerDuty 通知并非全局强制发送而是与应用类别Application Category的通知设置联动。相关逻辑位于 db/application_categories.go当你启用某个集成的 Incidents / Alerts 开关时Coroot 会自动为各应用类别同步开启对应的 PagerDuty 通知通道关闭集成或取消勾选后各类别中的对应通道也会被同步清理。实际入队时见 notifications/incidents.goIncident 通知只会在notificationSettings.Pagerduty.Enabled true时入队。也就是说你可以在Project Settings → Application Categories中按应用类别精细控制哪些应用的事件/告警要推送到 PagerDuty实现分级通知策略。七、常见问题与排查建议Deployments 选项不可选PagerDuty 集成不支持部署通知源码中SendDeployment返回not supported这是预期行为与 Slack / Teams / Webhook 集成的能力差异有关。集成保存失败提示 integration key is requiredIntegration Key 未填写或粘贴不完整请回到 PagerDuty 服务目录的 Integrations 页重新复制 Events API V2 密钥。测试告警发送失败优先检查 Base URL 是否已正确配置通知类集成的前置校验项以及 Coroot 到 PagerDuty 的网络连通性PagerDuty API 返回的错误会在服务端日志中记录为failed to send to pagerduty: ...。事件已恢复但 PagerDuty 仍显示打开检查 Coroot 事件触发与恢复是否经过了同一条集成同一 Integration Key。去重键由projectId incident/alert 标识 severity构成更换集成密钥后旧事件将无法被自动关闭。通过以上步骤你可以将 Coroot 的 SLO 事件与告警规则通知稳定地接入 PagerDuty 值班体系让 AI 根因分析结果、检查报告与恢复状态自动流转到值班工作流中实现检测 → 通知 → 分析 → 解决的闭环。【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Coroot 与 PagerDuty 集成指南：基于 Events API V2 的告警、SLO 事件与值班通知实战
Coroot 与 PagerDuty 集成指南基于 Events API V2 的告警、SLO 事件与值班通知实战【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot本指南以 Coroot 项目中的官方集成文档 docs/docs/alerting/pagerduty.md 为主体完整讲解如何在 PagerDuty 账号中创建Events API V2集成、在 Coroot 的Project Settings → Integrations中完成配置并通过源码级分析说明通知的触发、负载内容、去重与重试机制。读完本文你将掌握从 PagerDuty 服务目录创建集成、到 Coroot 侧粘贴 Integration Key、再到发送测试告警验证全链路可用的完整流程并理解 Coroot 在触发trigger与解决resolve事件时的底层实现。一、集成原理概览Coroot 如何向 PagerDuty 发送事件Coroot 的通知体系抽象为统一的NotificationClient接口定义于 notifications/notifications.go包含三个方法SendIncident发送 SLO 事件Incident通知SendAlert发送告警规则Alerting Rule触发的告警通知SendDeployment发送部署通知PagerDuty 集成不支持该能力。PagerDuty 集成对应的实现类是Pagerduty见 notifications/pagerduty.go它只保存一个integrationKey字段即你在 PagerDuty 控制台创建的Events API V2集成密钥。Coroot 底层使用 PagerDuty 官方 Go SDKgithub.com/PagerDuty/go-pagerduty调用ManageEventWithContext发送事件。从源码结构看PagerDuty 通知在 Coroot 中覆盖两类场景IncidentsSLO 事件当应用违反 SLO、或 SLO 事件的状态发生变更WARNING / CRITICAL / 恢复时触发Alerts告警规则当自定义告警规则如 PromQL 表达式告警触发或恢复时发送。而部署通知对 PagerDuty 明确返回not supported见 notifications/pagerduty.go因此前端表单中Deployments选项对 PagerDuty 集成是置灰不可选的。二、在 PagerDuty 账号中创建 Events API V2 集成配置的第一步是在 PagerDuty 侧创建集成。按照 docs/docs/alerting/pagerduty.md 的步骤执行登录 PagerDuty导航到Services → Service Directory选择目标服务target service或点击 New Service创建一个新服务进入该服务的Integrations选项卡点击 Add another integration添加集成在集成类型列表中选择Events API V2Events API v2 是 PagerDuty 当前的推荐事件协议支持自动去重、事件分组与状态变更如有需要修改Integration Name例如命名为Coroot便于在多集成中区分来源复制页面展示的Integration Key32 位十六进制格式后续粘贴到 Coroot 中。完成上述操作后PagerDuty 侧已具备接收 Coroot 事件的入口Integration Key 是两者之间的唯一认证凭据。三、在 Coroot 中配置 PagerDuty 集成3.1 配置入口与表单字段在 Coroot Web 界面中进入Project Settings → Integrations创建一条Pagerduty类型的集成将上一步复制的Integration Key粘贴到表单中。Coroot 前端的 PagerDuty 集成表单实现在 front/src/components/IntegrationFormPagerduty.vue核心字段如下字段说明可选值 / 约束Integration KeyPagerDuty Events API V2 集成密钥必填不能为空前端使用$validators.notEmpty校验Incidents是否接收 SLO 事件通知复选框默认勾选与否取决于集成配置Deployments部署通知始终禁用PagerDuty 不支持部署通知Alerts是否接收告警规则通知复选框对应的后端数据结构为IntegrationPagerduty见 db/integrations.gotype IntegrationPagerduty struct { IntegrationKey string json:integration_key yaml:integrationKey Incidents bool json:incidents yaml:incidents Alerts *bool json:alerts,omitempty yaml:alerts,omitempty }其中Alerts是指针类型兼容旧版本配置中未显式声明 alerts 开关的情况Validate()方法要求IntegrationKey非空否则校验失败并返回invalid pagerduty configuration: integration key is required。配置完成后的界面示意如下3.2 前置条件Base URL在 db/integrations.go 的NotificationIntegrations.Validate()中所有通知类集成都要求配置Base URL即 Coroot 自身的对外访问地址。该地址用于构造事件负载中的ClientURL链接使 PagerDuty 中显示的每条事件都能直接跳回 Coroot 的对应告警/事件页面事件详情跳转{baseUrl}/p/{projectId}/incidents?incident{incidentKey}见 notifications/notifications.go告警详情跳转{baseUrl}/p/{projectId}/alerts?alert{alertId}见 notifications/alerts.go。因此请确保项目设置中已正确填写 Coroot 的对外 Base URL否则集成校验无法通过。四、发送测试告警验证集成配置完成后建议立即发送一条测试通知以验证整条链路。在 Coroot 集成配置页面点击发送测试按钮即可测试通知的后端实现位于 api/forms/forms.go 的SendTestNotification。当表单携带test.incident字段且项目中已配置 PagerDuty 集成时Coroot 会实例化NewPagerduty(integrations.Pagerduty.IntegrationKey)并调用SendIncident发送一条测试事件对应 API 入口在 api/api.go。测试事件同样会走真实的 PagerDuty Events API V2 通道因此能可靠验证Integration Key 是否有效Coroot 到 PagerDuty 的网络连通性PagerDuty 服务是否成功接收并创建对应事件/告警。若测试通过PagerDuty 中应能看到来自Coroot的测试事件随后可进入下一步验证真实告警的触发与恢复。五、PagerDuty 通知的实际发送与消息内容源码级5.1 事件协议trigger 与 resolveCoroot 发送的是 PagerDuty Events API V2 的trigger/resolve两类动作核心实现在 notifications/pagerduty.go 与 notifications/pagerduty.go当通知状态为model.OK事件已恢复时发送resolve事件并携带与触发时相同的DedupKey用于关闭 PagerDuty 中对应的打开事件否则发送trigger事件事件负载中包含Client固定为Coroot、ClientURL跳回 Coroot 详情页、Payload等字段。5.2 DedupKey自动去重与状态关联Coroot 利用 PagerDuty 的去重键DedupKey将同一条 Coroot 事件的多次状态变更关联为 PagerDuty 中的同一事件Incident 事件的去重键格式为{projectId}:{incidentKey}:{severity}Alert 告警的去重键格式为{projectId}:{alertId}:{severity}。以 SLO 事件为例见 notifications/incidents.goCoroot 会跟踪同一事件在 WARNING 与 CRITICAL 两个严重级别下的打开状态事件升级为WARNINGtrigger一条 WARNING 事件事件升级为CRITICAL先resolve已打开的 WARNING 事件再trigger一条 CRITICAL 事件事件恢复同时resolve所有仍处于打开状态的 WARNING / CRITICAL 事件。告警Alert的通知逻辑与之类似见 notifications/alerts.gotrigger时记录打开的去重键resolve时携带该键关闭 PagerDuty 事件从而保证 PagerDuty 不会出现告警已恢复但事件仍打开的脏状态。5.3 事件负载内容IncidentSLO 事件的V2Payload结构见 notifications/pagerduty.go字段内容Summary[CRITICAL] my-app is not meeting its SLOs形式严重级别为大写Source固定为CorootSeverity事件严重级别critical / warning取自事件状态字符串Timestamp事件时间戳Details明细字典包含各检查报告格式报告名 / 检查项 → 消息、Root CauseAI 根因摘要与Remediations修复建议最长截断 2000 字符其中Root Cause与Remediations来自 Coroot 的 AI 根因分析RCA结果只有当事件附带 RCA 且状态为 OK 时才填充见 notifications/notifications.go。Alert告警规则的V2Payload结构见 notifications/pagerduty.go字段内容Summary[CRITICAL] app-name: 告警摘要形式应用名缺失时回退为规则名Source固定为CorootSeverity告警严重级别Details明细字典包含Project项目名、Alerting rule规则名以及规则自定义的详情键值对值得注意的是告警明细在入队前会经过filterAlertDetails过滤剔除PromQL与PromQLChart两类内部详情见 notifications/alerts.go避免把冗长的查询语句直接推送到 PagerDuty。5.4 发送失败的重试机制Coroot 的通知发送采用入队 定时重试模型见 notifications/notifications.go单次发送超时时间为30 秒sendTimeout未发送成功的通知由后台定时器每隔1 分钟retryInterval重试仅重试最近1 小时retryWindow内的未发送通知超过窗口即放弃。在 notifications/incidents.go 的发送循环中同一目标集成首次发送失败后会标记为失败并跳过本批次其余通知避免对 PagerDuty API 造成突增请求。六、通知范围控制结合应用类别Application Category管理PagerDuty 通知并非全局强制发送而是与应用类别Application Category的通知设置联动。相关逻辑位于 db/application_categories.go当你启用某个集成的 Incidents / Alerts 开关时Coroot 会自动为各应用类别同步开启对应的 PagerDuty 通知通道关闭集成或取消勾选后各类别中的对应通道也会被同步清理。实际入队时见 notifications/incidents.goIncident 通知只会在notificationSettings.Pagerduty.Enabled true时入队。也就是说你可以在Project Settings → Application Categories中按应用类别精细控制哪些应用的事件/告警要推送到 PagerDuty实现分级通知策略。七、常见问题与排查建议Deployments 选项不可选PagerDuty 集成不支持部署通知源码中SendDeployment返回not supported这是预期行为与 Slack / Teams / Webhook 集成的能力差异有关。集成保存失败提示 integration key is requiredIntegration Key 未填写或粘贴不完整请回到 PagerDuty 服务目录的 Integrations 页重新复制 Events API V2 密钥。测试告警发送失败优先检查 Base URL 是否已正确配置通知类集成的前置校验项以及 Coroot 到 PagerDuty 的网络连通性PagerDuty API 返回的错误会在服务端日志中记录为failed to send to pagerduty: ...。事件已恢复但 PagerDuty 仍显示打开检查 Coroot 事件触发与恢复是否经过了同一条集成同一 Integration Key。去重键由projectId incident/alert 标识 severity构成更换集成密钥后旧事件将无法被自动关闭。通过以上步骤你可以将 Coroot 的 SLO 事件与告警规则通知稳定地接入 PagerDuty 值班体系让 AI 根因分析结果、检查报告与恢复状态自动流转到值班工作流中实现检测 → 通知 → 分析 → 解决的闭环。【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考