行動策略過於複雜怎麼辦?試試下面一些解決方法

背景

隨着使用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字段）進行動態分派，因此在這種情況下就必須使用動態接收人的方式了。

如下圖所示，使用動態接收人後，行動策略就只需要一個行動節點，從而變得簡潔。

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。