行动策略过于复杂怎么办?试试下面一些解决方法

本文涉及的产品
对象存储 OSS,20GB 3个月
文件存储 NAS,50GB 3个月
对象存储 OSS,内容安全 1000 次 1年
简介: 随着使用SLS告警越来越深入,有些用户的行动策略会配置的特别复杂,有些时候可以让用户通过创建多个行动策略来进行一定的精简,但是在一些场景下,用户是无法创建多个行动策略的。

背景

随着使用SLS告警越来越深入,有些用户的行动策略会配置的特别复杂,有些时候可以让用户通过创建多个行动策略来进行一定的精简,但是在一些场景下,用户是无法创建多个行动策略的。例如用户想要通过SLS来统一管理其各个监控系统的告警,所以采用了SLS的开放告警功能,这种情况下,用户一般一个监控系统就只会创建一个开放告警应用,也就只能对应一个行动策略,所以随着需要动态分派告警的各种情况增多,行动策略就会急剧膨胀,从而出现以下情况:

  • 在控制台无法保存
  • 在前端修改时加载过于卡顿
  • 告警延迟增加

因此,对于上述问题,本文介绍了三种优化的方案。

方案对比

利用告警策略拆分行动策略

使用SDK压缩行动策略内容

使用动态接收人

适用场景

适用于熟悉告警策略,并且告警的标签和标注特征明显的情况

优点:管理清晰、不容易出错

缺点:配置麻烦

适用于对告警SDK使用熟练,并且熟悉告警相关DSL语法的用户

优点:可以极大地精简行动策略

缺点:学习成本高,容易出错

适用有自己的企业用户管理系统,或者无法在行动策略分派的情况

优点:SLS侧配置简洁

缺点:用户需要实现一个提供动态分派通知人能力的webhook服务,并且只支持短信、语音和邮件通知渠道

利用告警策略拆分行动策略

告警策略在配置路由合并策略的时候,是可以按照告警的一些信息采用不同分组合并的,而不同的分组合并又可以选择不同的行动策略,所以手动将每个分组合并的其余配置全部改为和默认告警策略的一致,那么就可以实现拆分行动策略的目的了。(默认告警策略的分组合并中,合并基准选择自定义,告警属性选择告警规则ID和规则所在项目,告警标签选择所有,首次等待选择1秒,变化等待选择15秒,重复等待选择1分钟)

如下图所示,如果使用一个行动策略的话,那么该行动策略中既要考虑标签中appName为app0的情况,还要考虑appName为app1的情况,按照下图所示的方法拆分后,那么行动策略0中只需要考虑appName为app0的情况,行动策略1中只需要考虑appName为app1的情况,这样就完成了对行动策略的拆分。

最后,在创建告警监控规则或者开放告警应用的时候选择上面创建的告警策略即可。

使用SDK压缩行动策略内容

SLS的控制台在配置行动策略的时候,由于需要保存节点的一些UI信息,那么在存储行动策略时的配置内容就会特别大,容易超出资源数据的大小限制,从而导致从控制台上无法保存。如果是通过SDK管理行动策略的话,那么可以省去控制台上那些额外的UI信息,这个行动策略的大小就会变小很多。例如通过以下代码创建一个行动策略。

packagemainimport (
"fmt"sls"github.com/aliyun/aliyun-log-go-sdk")
var (
// 日志服务的服务入口。创建资源必须是河源区域。endpoint="cn-heyuan.log.aliyuncs.com"// 阿里云访问密钥AccessKey。更多信息,请参见访问密钥。阿里云账号AccessKey拥有所有API的访问权限,风险很高。强烈建议您创建并使用RAM用户进行API访问或日常运维。accessKeyId=""accessKeySecret=""// 创建日志服务Client。client=sls.CreateNormalInterface(endpoint, accessKeyId, accessKeySecret, "")
)
funcmain() {
actionPolicy :=&sls.ResourceActionPolicy{
ActionPolicyId:              "test-action-policy",
ActionPolicyName:            "Test Action Policy",
PrimaryPolicyScript:         "if alert.labels.appName == \"app0\":\n    fire(type=\"sms\", users=[\"user1\"], groups=[], oncall_groups=[], receiver_type=\"static\", external_url=\"\", external_headers={}, template_id=\"sls.builtin.cn\", check_quota=\"true\", period=\"any\")\n    stop()\nif alert.labels.appName == \"app1\":\n    fire(type=\"email\", users=[\"user2\"], groups=[], oncall_groups=[], receiver_type=\"static\", external_url=\"\", external_headers={}, template_id=\"sls.builtin.cn\", check_quota=\"true\", period=\"any\")\n    stop()\nfire(type=\"webhook_integration\", integration_type=\"dingtalk\", webhook_id=\"user3\", template_id=\"sls.builtin.cn\", period=\"any\")",
SecondaryPolicyScript:       "",
EscalationStartTimeout:      "10m",
EscalationInprogressEnabled: false,
EscalationInprogressTimeout: "30m",
EscalationEnabled:           true,
EscalationTimeout:           "1h",
 }
record :=&sls.ResourceRecord{
Id:    actionPolicy.ActionPolicyId,
Tag:   actionPolicy.ActionPolicyName,
Value: sls.JsonMarshal(actionPolicy),
 }
err :=client.CreateResourceRecord("sls.alert.action_policy", record)
fmt.Println("[create action policy]", err)
}

第一列行动策略对应的DSL语法的脚本展开如下:

ifalert.labels.appName=="app0":
fire(type="sms", users=["user1"], groups=[], oncall_groups=[], receiver_type="static", external_url="", external_headers={}, template_id="sls.builtin.cn", check_quota="true", period="any")
stop()
ifalert.labels.appName=="app1":
fire(type="email", users=["user2"], groups=[], oncall_groups=[], receiver_type="static", external_url="", external_headers={}, template_id="sls.builtin.cn", check_quota="true", period="any")
stop()
fire(type="webhook_integration", integration_type="dingtalk", webhook_id="user3", template_id="sls.builtin.cn", period="any")

创建好了以后,在控制台上点击编辑创建好的行动策略如下图所示。通过SDK创建的行动策略没有UI信息,但是依然可以正常运行。

上述的行动策略对应的有UI信息的行动策略如下图所示。

使用动态接收人

SLS提供了动态接收人功能,可以通过Webhook服务设置告警通知的动态接收人。该Webhook服务办不仅可以按照SLS的用户模型返回需要通知告警的联系人方式,还可以进行告警的动态分派,实现与行动策略相同的能力,不仅如此,由于行动策略无法支持按照特殊内容(例如告警的fire_results字段)进行动态分派,因此在这种情况下就必须使用动态接收人的方式了。

如下图所示,使用动态接收人后,行动策略就只需要一个行动节点,从而变得简洁。

参考文档

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
2天前
|
Android开发 开发者 Windows
这是我设计的一种不关机,然后改造操作系统的软件设计思路2.0版本
本文介绍了在不重启系统的情况下实现操作系统改造的两种方案。第一种方案通过SLFM Recovery模式,在独立于操作系统的最高权限环境下完成系统更新与改造,并支持断电恢复与失败回滚。第二种方案采用多分区机制,通过SLFM套件在独立分区中完成系统改造,适用于可中断与不可中断服务场景,确保系统更新过程的安全与稳定。
210 132
|
9天前
|
人工智能 算法 测试技术
轻量高效,8B 性能强劲书生科学多模态模型Intern-S1-mini开源
继 7 月 26 日开源『书生』科学多模态大模型 Intern-S1 之后,上海人工智能实验室(上海AI实验室)在8月23日推出了轻量化版本 Intern-S1-mini。
342 51
|
19天前
|
人工智能 JavaScript 前端开发
实战使用 Qwen3-coder 低代码开发 HTML 个人网站
阿里巴巴开源的Qwen3-coder模型,凭借强大性能和低代码能力,助力用户快速搭建个人网站。本文详解环境配置、提示词设计与部署流程,适合编程新手快速上手,掌握AI辅助开发技能。
1309 8