有一定Zabbix使用經驗的小伙伴可能會發現，接收告警事件時，其中可能包含著大量不同的部件名，同一部件的事件在邏輯上具有很強關聯性，理論上應保持一致的告警/恢復狀態，但Zabbix默認并未對它們進行關聯，直接后果是運維人員只能進行大量重復操作，進而對部件的狀態進行校正。

實際上，雖然Zabbix默認未對相同部件進行關聯，但卻可以通過手動配置實現關聯操作。本文將深入探討Zabbix在處理相同部件觸發器的告警和恢復過程中的強關聯機制。通過這種機制，我們可以確保一旦觸發器狀態發生變化，相關的告警能夠被準確觸發，并且在問題解決后，告警狀態能夠及時恢復，從而避免無效告警的干擾和資源的浪費。

例如，當前監控中有對硬件設備事件采集監控項（數據如下），要對其配置觸發器告警，但是每個事件中包含告警對應的部件名，希望對相同部件的告警實現告警-恢復事件的自動關聯。
數據字段解析：

監控取值中，第4位為告警狀態，"Assertion"表示告警產生，"Deassertion"表示告警恢復。

配置思路：
方法一(建議)：
參考方法二中基礎配置，額外補充事件匹配-標簽

標記中“值“參數支持寫法如下

{{ITEM.VALUE}.regsub(pattern, output)}

{{ITEM.VALUE}.iregsub(pattern, output)}

{{#LLDMACRO}.regsub(pattern, output)}

{{#LLDMACRO}.iregsub(pattern, output)}

圖中示例寫法：

{{ITEM.VALUE}.regsub(“tion”,\s*“\s*(\S+)\s*(”,\1)}

測試數據如下：

測試結果：
從結果中可以看到，部件名稱被正則截取到標記中。

同時，只有DIMM110 是既存在”Assertion”記錄，又存在”Deassertion”記錄的，所以只有DIMM110部件的告警是恢復了的。

優點：

1.配置簡單，僅配置一條即可

2.告警事件不遺漏，多個部件告警信息，則產生多個告警事件

3.可以實現單個部件的告警、恢復記錄的關聯，不會因為其他此部件的恢復記錄，觸發其他部件告警的恢復操作

缺點：

1.配置邏輯較復雜，涉及標記、正則、內置宏等多方面

方法二：
配置單個觸發器，如下圖2

①將告警最新值帶進告警標題中，區分具體告警部件等信息。

②檢測到關鍵字"Assertion"則告警

③檢測到關鍵字"Deassertion"則恢復

④問題事件生成模式：多重：觸發器未恢復的情況下可以多次產生告警；單個：多次規則匹配，如果已經產生的告警為恢復的情況下，不會重新產生新告警。效果如下圖3

優點：

1. 配置簡單，僅配置一條即可

2. 告警事件不遺漏，多個部件告警信息，則產生多個告警事件

缺點：

1.一個部件告警恢復，則其他部件告警一并恢復，如圖4 —— 僅DIMM131部件恢復，其他部件的告警也被恢復了，其實并沒有

方法三：
對每個部件添加一個觸發器（如下圖5）：

DIMM110部件告警觸發器：

觸發表達式：監控值包含DIMM110 且 包含關鍵字 “Assertion”；

恢復表達式：監控值包含DIMM110 且 包含關鍵字 “Deassertion”；

反復操作，添加DIMM111、DIMM120、DIMM121等多個觸發器。

圖5

優點：

1.可以實現單個部件的告警、恢復記錄的關聯，不會因為其他此部件的恢復記錄，觸發其他部件告警的恢復操作

缺點：

1.配置工作量巨大，每個部件都需要定義一個對應觸發器

2.可能會丟失、遺漏告警，因為可能部件關鍵字未加入觸發器中

結論：
上述三種方法可以看出，邏輯上方法二、方法三更加簡單明了，但是皆有不滿足場景需求的情況；方法一則更貼合場景需求，且善用觸發器的標記功能，也更利于監控平臺的維護管理。參考該第一方法，可延伸較多場景，如日志事件告警恢復ID關聯、snmptrap端口up\down數據告警關聯、硬件事件相同部件名告警恢復關聯、遠程登入登出記錄關聯等。

以上就是這一期Zabbix技術分享。大家好，我是樂樂，專注運維技術研究與分享，關注我學習更多Zabbix使用技巧，更多問題也歡迎到樂維社區進行留言。