IncidentRelay 2.0 是一款开源的在线值班管理、告警路由和事件响应系统，现已发布。它可以部署在自托管服务器上。该项目面向寻求云端在线值班管理平台替代方案的 SRE、DevOps 和基础设施团队。代码使用 Python 编写，并以 MIT 许可证发布。
IncidentRelay 可接收来自 Prometheus Alertmanager、Grafana Alerting、Zabbix、Sentry、LibreNMS、RMON、AWS SNS/CloudWatch、Datadog、Uptime Kuma 以及自定义 Webhook 处理程序的事件。事件经过规范化处理后，会关联到服务、团队和轮值，应用路由规则和升级策略，并将通知发送给当前值班处理程序。支持的交付方式包括 Mattermost、Slack、Telegram、Discord、Microsoft Teams、电子邮件、Webhook、浏览器/PWA 推送以及语音通话提供商。
2.0 版本的主要创新之处在于事件编排机制，它在传入集成和告警生命周期之间提供了一个独立的事件处理层。主要变化包括：
- 新增了可视化编排规则编辑器。规则可以全局应用，也可以应用于特定服务，可以分组到嵌套条件组中，并可以按顺序修改优先级、严重级别、标签、命令、路由、分组方法、通知策略和升级等属性。
- 实现了抑制、丢弃和暂停事件处理的操作，使用正则表达式和 JSON Path 提取值，拆分字符串，创建变量和转换值；
- 编排配置分为可编辑的草稿和不可更改的已发布版本。支持配置审核、发布、恢复到先前版本以及添加更改注释；
- 提供禁用模式、影子模式和活动模式。在影子模式下，规则执行结果会被存储以供分析，但不会影响实际路由。传统模式、混合模式和编排兼容模式在过渡期内可用。
- 新增了事件模拟和回放工具。这些工具允许您在不生成实际警报的情况下，对规范化事件或原始集成有效负载测试规则。此外，还提供执行跟踪、解释数据和影子模式指标，以便分析结果。
- 实现了可重用的 Webhook 操作，这些操作在事件处理后异步执行。请求头以加密形式存储，密钥隐藏在 API 和日志中，并且默认情况下禁止访问私有网络。可以配置超时、重试次数以及允许的内部地址列表。
- 新增了与 Uptime Kuma 的集成，该集成可接收关于监控状态的标准 webhook 消息。已实现正常运行和故障状态的规范化、重要性检测、标签处理以及一种新的传入路由类型 uptime_kuma。
- 静默和计划工作窗口已添加 apply_to_existing 和 reactivate_on_end 参数。前者对已打开的警报应用抑制，后者决定抑制期结束后是否恢复处理这些警报。通知、提醒和升级链将被暂停和恢复；
- 对于个人 API 令牌，我们为组、团队、用户、路由、频道、服务、轮换、策略、维护窗口、心跳检查、单点登录 (SSO) 和编排引入了单独的读取和修改权限。为了向后兼容，我们保留了原有的聚合资源：读取、资源：写入和 * 权限。
- 新增了带有筛选和分页功能的审计日志界面。日志记录涉及流程编排、Webhook、静默和计划工作窗口的操作，敏感信息已从显示的数据中移除。
- 网页界面现已采用深色主题，并允许用户自定义语言和设计设置。新增了法语本地化，扩展了编排和维护部分的翻译，并改进了 SSO 组匹配规则的编辑功能。
- 改进的心跳检查：消除了重复创建逾期事件的情况，信号恢复能够正确关闭警报并发送问题已解决的通知，并且时间戳的显示方式已标准化；
- 我们已编写好使用 Helm 部署 Kubernetes 的文档。Helm Chart 中新增了一个专用的 Slack Socket 模式处理程序，该处理程序对于事件的交互式确认和关闭按钮至关重要。
- 我们加强了对外 HTTP 请求、正则表达式和敏感数据的安全性，集中处理了 UTC 和时区，重新设计了轮换计划计算，并扩大了自动化测试覆盖范围。
升级前，建议创建数据库备份。必要的架构更改将使用 IncidentRelay 内置的迁移机制完成。为了逐步实现事件编排，开发人员建议首先使用影子模式和混合模式，验证规则执行跟踪，然后再将编排切换到活动模式。
来源： opennet.ru
