共计 3240 个字符，预计需要花费 9 分钟才能阅读完成。
背景
随着应用 SLS 告警越来越深刻，有些用户的口头策略会配置的特地简单，有些时候能够让用户通过创立多个口头策略来进行肯定的精简，然而在一些场景下，用户是无奈创立多个口头策略的。例如用户想要通过 SLS 来对立治理其各个监控零碎的告警，所以采纳了 SLS 的凋谢告警性能，这种状况下，用户个别一个监控零碎就只会创立一个凋谢告警利用，也就只能对应一个口头策略，所以随着须要动静分派告警的各种状况增多，口头策略就会急剧收缩，从而呈现以下状况：
- 在控制台无奈保留
- 在前端批改时加载过于卡顿
- 告警提早减少
因而，对于上述问题，本文介绍了三种优化的计划。
计划比照
利用告警策略拆分口头策略
告警策略在配置路由合并策略的时候，是能够依照告警的一些信息采纳不同分组合并的，而不同的分组合并又能够抉择不同的口头策略，所以手动将每个分组合并的其余配置全副改为和默认告警策略的统一，那么就能够实现拆分口头策略的目标了。（默认告警策略的分组合并中，合并基准抉择自定义，告警属性抉择告警规定 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 字段）进行动静分派，因而在这种状况下就必须应用动静接管人的形式了。
如下图所示，应用动静接管人后，口头策略就只须要一个口头节点，从而变得简洁。
原文链接
本文为阿里云原创内容，未经容许不得转载。
