在 Flashduty On-call
您可通过以下两种方式获取集成推送地址,任选其一即可。
使用专属集成
- 进入 Flashduty 控制台,选择 协作空间,打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成,点击 新增一个集成
- 选择 GitLab,点击 保存
- 打开生成的集成卡片,复制 推送地址
使用共享集成
- 进入 Flashduty 控制台,选择 集成中心 → 告警事件
- 选择 GitLab,填写集成名称
- 配置默认路由并选择协作空间;创建后可在 路由 中增加更多规则
- 点击 保存,复制生成的 推送地址
在 GitLab 中配置
GitLab.com、GitLab 自托管版和 GitLab Dedicated 都支持 Webhook。项目 Webhook 所有版本都有,需要项目的 Maintainer 或 Owner 角色;群组 Webhook 需要 Premium 或 Ultimate 版本和群组的 Owner 角色,会推送群组及其子群组下所有项目的事件。
1
添加 Webhook
- 在 GitLab 中打开需要接入的项目(或群组),在左侧导航选择 Settings → Webhooks
- 点击 Add new webhook
- 将 Flashduty 集成的完整推送地址粘贴到 URL,地址中需包含
integration_key - Signing token 和 Secret token 可以不填,Flashduty 通过地址中的
integration_key认证 - 不要填写 Custom webhook template,Flashduty 按 GitLab 默认的请求体解析
2
选择推送的事件
在 Trigger 中勾选以下事件,其余事件不需要勾选,勾选了 Flashduty 也会直接返回成功、不创建告警:
Vulnerability events 需要 GitLab 17.11 或更高版本(17.7 到 17.10 需要管理员开启
vulnerabilities_as_webhook_events 功能开关),项目中产生漏洞记录需要 GitLab Ultimate。3
保存并验证
- 保持 Enable SSL verification 勾选,点击 Add webhook
- 在 Webhook 列表中点击 Test,选择 Pipeline events。GitLab 会把项目最近一条流水线的真实数据推送过来:如果这条流水线失败,Flashduty 会为它所在的分支创建一条告警;如果成功,不会产生新告警
- 让一个分支的流水线失败(例如提交一个会失败的测试),确认 Flashduty 收到活动告警;修复后在同一分支重新运行成功,确认原告警恢复
Alert Key
Flashduty 按业务对象生成 Alert Key,同一对象的触发和恢复事件使用同一个 Alert Key:
Alert Key 由对象类型和上表字段共同计算,分支和同名标签、分支和同名环境不会互相合并。项目改名或迁移路径不影响 Alert Key。缺少上表字段的失败或成功事件会被拒绝。
状态和告警等级
告警不会自动恢复的情况
以下对象之后不会再有成功事件,告警不会自动恢复:
- 流水线失败后分支被删除或合并,或失败的是标签流水线
- 失败的是临时环境(例如 Review App 的
review/*环境),之后环境被停止 - 同一分支上一条较早的流水线在较新的成功流水线之后才结束并失败
标签
流水线变量(
variables)和用户邮箱不会写入标签。
排查问题
- Webhook 显示 Temporarily disabled 或 Disabled:GitLab 在连续 4 次推送失败后会临时停用 Webhook,连续 40 次失败后永久停用。确认推送地址完整且包含
integration_key,然后点击 Test 发送一次测试请求重新启用 - 部署被驳回后收到告警:受保护环境的部署被驳回时,GitLab 先推送
rejected,丢弃部署作业后再推送同一部署的failed,Flashduty 会按部署失败创建告警,可手动关闭或等下一次成功部署恢复 - 合并请求流水线合并到了分支告警:合并请求流水线的
ref是源分支名,和该分支的普通流水线使用同一个 Alert Key - 没有收到漏洞事件:确认 GitLab 版本和 Ultimate 订阅满足要求,并且项目已开启安全扫描
- 在 Webhook 的 Recent events 中查看推送记录:在 Webhook 编辑页的 Recent events 中可以查看每次推送的请求体和 Flashduty 返回的响应