背景

随着应用SLS告警越来越深刻，有些用户的口头策略会配置的特地简单，有些时候能够让用户通过创立多个口头策略来进行肯定的精简，然而在一些场景下，用户是无奈创立多个口头策略的。例如用户想要通过SLS来对立治理其各个监控零碎的告警，所以采纳了SLS的凋谢告警性能，这种状况下，用户个别一个监控零碎就只会创立一个凋谢告警利用，也就只能对应一个口头策略，所以随着须要动静分派告警的各种状况增多，口头策略就会急剧收缩，从而呈现以下状况：

  • 在控制台无奈保留
  • 在前端批改时加载过于卡顿
  • 告警提早减少

因而，对于上述问题，本文介绍了三种优化的计划。

计划比照

利用告警策略拆分口头策略

告警策略在配置路由合并策略的时候，是能够依照告警的一些信息采纳不同分组合并的，而不同的分组合并又能够抉择不同的口头策略，所以手动将每个分组合并的其余配置全副改为和默认告警策略的统一，那么就能够实现拆分口头策略的目标了。（默认告警策略的分组合并中，合并基准抉择自定义，告警属性抉择告警规定ID和规定所在我的项目，告警标签抉择所有，首次期待抉择1秒，变动期待抉择15秒，反复期待抉择1分钟）

如下图所示，如果应用一个口头策略的话，那么该口头策略中既要思考标签中appName为app0的状况，还要思考appName为app1的状况，依照下图所示的办法拆分后，那么口头策略0中只须要思考appName为app0的状况，口头策略1中只须要思考appName为app1的状况，这样就实现了对口头策略的拆分。

最初，在创立告警监控规定或者凋谢告警利用的时候抉择下面创立的告警策略即可。

应用SDK压缩口头策略内容

SLS的控制台在配置口头策略的时候，因为须要保留节点的一些UI信息，那么在存储口头策略时的配置内容就会特地大，容易超出资源数据的大小限度，从而导致从管制台上无奈保留。如果是通过SDK治理口头策略的话，那么能够省去管制台上那些额定的UI信息，这个口头策略的大小就会变小很多。例如通过以下代码创立一个口头策略。

package mainimport ( "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字段）进行动静分派，因而在这种状况下就必须应用动静接管人的形式了。

如下图所示，应用动静接管人后，口头策略就只须要一个口头节点，从而变得简洁。

原文链接

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