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

背景

随着使用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信息，这个行动策略的大小就会变小很多。例如通过以下代码创建一个行动策略。

package main
import (
 "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, "")
)
func main() {
 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语法的脚本展开如下：

if alert.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()
if alert.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字段）进行动态分派，因此在这种情况下就必须使用动态接收人的方式了。

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

原文链接

本文为阿里云原创内容，未经允许不得转载。