2019年10月7日 星期一

開源網路裝置服務監控系統：LibreNMS (五)



經過前面幾篇的操作，我們已經可以收集非常詳細的裝置資訊、檢測多項服務運作的健康狀態甚至是網域與憑證的效期，也把裝置的事件統一收容進來，既然這麼多的資訊讓我們查詢，接下來就要做出更多進階的應用，將這些數據做為警報發送的材料來源。



發送管道

在 LibreNMS 的警報發送管道裡，支援了非常廣泛的支援，目前可以看到有這些：
  • Alertmanager
  • API
  • Boxcar
  • Canopsis
  • Cisco Spark (aka Webex Teams)
  • Clickatell
  • Discord
  • Elasticsearch
  • Gitlab
  • HipChat
  • IRC
  • JIRA
  • LINE Notify
  • Mail
  • Microsoft Teams
  • Nagios Compatible
  • OpsGenie
  • osTicket
  • PagerDuty
  • Philips Hue
  • PlaySMS
  • Pushbullet
  • Pushover
  • Rocket.chat
  • Slack
  • SMSEagle
  • Syslog
  • Telegram
  • Twilio SMS
  • VictorOps
  • Kayako Classic
  • SMSFeedback


這麼多種方式，我相信至少會有一種以上可以滿足你。其中我個人最喜歡用的是 Telegram，透過 Telegram 來發送即時警報，不用擔心費用而且可以跟常用的通訊軟體區隔，容易分辨。

而在台灣最夯的 LINE Notify 也在支援清單之中，其它許多開發團隊喜歡使用的 Slack 或 Teams 也都在清單之上，若是您要整合自己的 API 服務，只要是走 POST 機制的模式都可以讓 LibreNMS 來呼叫而支援。







警告傳輸

設定警告傳輸的方式，請由頂端功能表的 [Alerts] -> [Alert Transports] 進入，並點選 [Create alert transport] 按鈕進入新增介面。



Telegram 傳輸設定


在 Transport type 欄位可以下拉選擇要使用那一種方式來傳送警報，上圖是選擇 Telegram 後下方出現相對應該輸入的欄位，不同的服務對應的欄位均不相同，請依據畫面上的要求填入即可。







警報規則

當警報建立完成以後，接下來即可準備建立警報規則，請由頂端功能的 [Alerts] -> [Alert Rules] 進入，並點選 [Create new alert rule] 按鈕進入新增介面。



警告規則設定 1


在上圖的範例中，是設定為偵測到裝置有重新啟動即發出警報，因為正常的伺服器運作良好的情況下並不會經常在重開機，若有發生肯定是當機、人為誤作失誤等等原因造成，因此予以警報。

這裡有一個條將 devices.uptime 小於 300 秒的條件設定，用意是指開機後運作時間小於 300 秒也就是 5 分鐘，這與我們 LibreNMS 預設每 5 分鐘輪詢一次狀態是符合的，因此以這個時間做為是否有重開機的檢測完全沒有問題。



警告規則設定 2


前幾篇有提到好幾次，可以把收進來的 Syslog 事件做為警報的判斷來源；上圖就是其中一種範例。

首先利用 syslog.timestamp 大於等於 5 分鐘內的事件記錄取出，再對 syslog.msg 事件的內容以正規表示式做處理，訊息中有「Connection refused」與「I/O error」的記錄就判定為發生該裝置斷線異常 (實際情況要看所使用的系統會產出什麼樣的訊息，不一定會與本範例相同)，從而發出警報提醒管理員需要注意。







警報範本

LibreNMS 對於警報發出的格式提高了很高的彈性，直接建置了範本系統跟我們自己設計，所以不同的使用情境可以依據企業所需要的內容與格式進行調整。

請由頂端功能表的 [Alerts] -> [Alert Templates] 進入，即可新增或修改範本內容。



警報範本設定


上圖是我高度客製化過的警報範本，搭配圖示讓收到訊息的時候可以很快的判斷是什麼類型，內容也以中文與換行搭配讓他整齊一些，以利閱讀。



警報實際範例


上圖就是以該範本實際發出 Telegram 警報的內容，每個單位可以調整為適合自己使用的樣式。

每個警報範本可以各別指派給不同的警告規則，在警報範本的 Attach template to rules 欄位中可以輸入相對應的警報規則名稱。







警報追蹤

在多人維運的團隊裡，當問題發生時收到警報後已處理完成時，若其它成員不知道已完成，則可以造成重工現象；若是處理過後未能完成但有資訊可以提供，也需要在一個平台上註記，以方便追蹤或是接手者可以知道曾經發生過的狀況。

在 LibreNMS 裡提供的警報追蹤的機制，可以透過標記狀態與記錄處理狀況，對每一則還沒有解除的警報留下記錄。

請到頂端功能表 [Alerts] -> [Notifications] 查看這些記錄。



警告追蹤


若對清單上的警告已經有處理或了解，可以按下該筆記錄後方的 ACK 按鈕 (紅色眼睛) 進行認可，並輸入處理的狀況，系統就會將您輸入的記錄存下，同時記下時間點以及認可者的名字。當警報持續未解除而有多次認可者，系統會把每一次都記錄下來，讓處理可以在 Notes 裡看到歷程。







結論

經由 LibreNMS 完整的資訊能力搭配強大的警報系統可以傳送給多種發送管道，而範本系統與規則系統則可以讓我們隨心所欲的制訂警報樣式以及發送警告的條件組合，這些都是幫助管理者提早能夠收到異常資訊的重要機制。

精準的制訂規則，才能讓有用的警報送達，避免次該叫的狂叫，時間久了讓管理者麻木，造成真正的警告來襲時反而沒有做出應該有的應對措施。

LibreNMS 的整合能力與擴充機制夠活，因此我們可以將 LibreNMS 打造成一個中央平台，把其它系統的警告資訊送進來，以及由 LibreNMS 的 Service 發展更多的監測能力，讓 LibreNMS 統一發送警報並進行管理，相信是一個相當不錯的解決方案。







參考資料



發佈：
標籤： , , , , , , , , ,