多元化的告警機制

隨時隨地掌控資訊維運狀態

    主動式的資訊維運系統對於系統異常的檢測是採自動化告警機制,其中最重要的是如何界定何謂"異常狀態"
    IT維運系統對於資訊設備的檢測方式無論是採用主動或被動其資料收集的內容包含
    數據,字串內容,事件觸發等各類型的資料基準點
    而將偵測結果視為告警事件最重要的是符合"告警臨界值"的條件
    "告警事件"與"解除告警事件"都依"告警臨界值"的條件來發佈
    如何定義"告警臨界值"與告警後的處置,要先從建立監控目標的準備事項開始
       *. 需要監控的項目
       *. 定義監控項目的異常臨界點,列舉最常出現的種類
          1.數據類-通常會用大於(>)或小於(<)來定義"告警臨界值"的條件,當取得監控目標值時
             比較其數據符合"告警值"值即發出告警事件
          2.文字類與訊息類-會用字串比對方式與邏輯運算(or,and,not)來確認是否符合警報條件
          3.事件觸發類-收到觸發訊息立即轉送與發佈警報
       *. 檢測警報狀況發出的告警效率,嚴緊度與警報敏感度
       *. 警報發出的管道與通知名單
       *. 警報發出後的緊急處置方案
       *. 建立重要關聯整合點(如:封包測試之佈線追蹤)
       *. 相關資訊建立(如:設備位置,用途,保管人,維護廠商)

嚴緊與靈活的異常檢測機制

    如果告警事件浮爛就會像"放羊小孩",這是目前資訊監控系統中最常出現的狀況,如果沒有
    嚴緊的判斷機制會讓系統管理人員久而不視或關閉此項功能而喪失真正要處理的時機
    所以在很多的資訊維運系統或監控系統不會強調"告警功能"
    當偵測系統要判斷是否為異常事件時必須要有三項以上的條件才可發出警報
    同時必須依每一類型的設備特性與使用重要性分別設定
       *.符合單項功能使用的數據
       *.連續多次的重復檢測
       *.異常後重復檢測的延遲時間,以降低敏感度
       *.加入特別時段不發佈警報通知
       *.許多的列外是必須依資訊設備的每一個細項"監控項目"定義其"告警值"
       *. 有能力拹助其他監控系統處理告警事件

    當自動化的檢測機制啟動後,系統就會開始收集資料並判斷是否超過或符合警報條件
    當然不是每一個個監控項目的警報條件與"告警臨界值"都是一樣
    縱然是相同的資訊設備,相同的監控項目,但仍然必須依資訊設備與監控項目的系統特性或
    使用特性定意"告警臨界值"與告警後的處置
    如:Microsoft Exchange Server 記憶體使用率90%是正常,但在其他主機可能是異常
    告警機制的檢測功能,必須要考慮到非常週詳與細膩,因為每一類型的資訊設備與每一個監控項目都會不同
    每一個監控項目的"告警臨界值"設計至少要符合下列條件
    *.每一個監控細項提供獨立的告警檢測條件
    *.每一個監控細項提供獨立的告警臨界值而內容包含了數據,字串,事件,
       觸發及偵測到符合告警臨界值後可再重複確認的檢測程序
    *.可規範定義再測的延遲時間與重測次數若會因特定時段問題可再加設定時間區間條件
    *.每一個監控細項提供獨立的通報群組
    *.每一個監控細項提供獨立的連動警報後續處理的機制
    如:
       直接對伺服主機下達命令
       直接對特定設備下達命令
       直接控制電源設備

    自動化"告警檢測機制",對於系統負責人或維運人員有極大的幫助,不需花費大量的時間來
    檢查系統狀態,而且使用人工方式又不能將經驗值傳承下去
    一個經過考驗的"告警檢測條件",包含了各種不同的狀態訊息與數據,如果能夠將
    系統負載,數據異常的標準值與經驗建立於"標準規範"內將可傳承
    對於規範異常狀況的告警臨界值通常要從"系統健康檢查"開始,先了解系統營運的狀態後才能精準的修正告警值
    對於"告警臨界值"的設定,盡量不要採用"單一條件"值的設定方式,除非是告警轉送或代理告警通知
    列舉狀況:
      1.如果監控系統採用單一條件值的告警檢測,雖然簡單但告警的次數就會增加很多
         僅依監測系統單一的檢測值
         如: CPU負載上限80%發出警報,但此伺服器CPU負載每5分鐘會有一次持續5秒81%的負載率
              如此告警訊息會每5分鐘發出一次,若每晚10點-12點做備份此時CPU負載到90%,那
              告警訊息會更多
       2.如果監控系統採用多重條件值的告警檢測方法則狀況會完全不同
         如上述狀況
              定義(A)CPU負載上限80%+(B)連續3次超過負載+(C)每次重測間隔5分鐘
              . A+B+C同時成立才發出告警訊息
              . 定義每晚10點-12點不發出告警訊息
*.如上述狀況若採用多重條件值的告警檢測方法則不會發出告警訊息

    對於"告警臨界值"的設定,盡量依系統使用的特性與環境調整告警條件
    有時候不是系統的負載率高就表示有系統問題或是系統異常
    例如:
       兩台伺服主機(A,B),A台CPU負載率為95%,B台CPU負載率為12%是那一台主機有問題?
       可能大部份的答案是 "A台" ,因為A台CPU負載率高達95%
       但如果"A台"是從安裝後使用都很正常從未出現過當機現象或過慢的狀況,
       而"B台"平常CPU負載率為68%而現在下降為12%,那又是如何?
       如果"B台"是因為某些服務停止而讓CPU負載率從68%下降為12%,那是那一台伺服主機有問題?

規劃週詳的通報群組

    當"告警事件"發生後要依據預定的"通報名單"通知系統負責人或維運人員與維護廠商或各專業技術工程師
    "解除告警事件"同樣是依"告警事件"預定的"通報名單"與管道來通知
    所以對於"通報名單"的設定,要有能力應付不同的"設備群組"與"負責群組"甚至"特定群組"
    包含了系統負責人或維運人員與維護廠商,資訊中心主管,所以每一個通報群組必須要可建立
    30筆以上的名單,來設定不同警報發佈的對象
    在每一個監控項目所提供的告警檢測條件下指定"通報群組"並依群組內容
    採用不同的通報管道來發佈告警訊息與連動串聯控制命令
    在每一個"通報群組名單"可細分至單一監控項目
    如:
       同一伺服器的CPU負載率與硬碟使用率可為不同通報群組
       同一伺服器的C:硬碟使用率與D:硬碟使用率可為不同通報群組
       同一伺服器的的任何監控項目可為同一通報群組名單
    每一次的告警訊息發佈時會依最細項的監控項目開始選擇"通報群組名單"
    除了"必要名單"外,將不會重複發佈告警訊息
    通報群組名單的優先順序
    依: "監控項目"(如:CPU負載率) ->伺服主機通報群組 -> "整體共用名單"
    通報群組名單的類別約可分為
      *.依每一監控項目
      *.依設備主體(如:伺服主機,交換器Switch)
      *.依不同群組
      *.監控主機之系統與設備
      *.系統開機
      *.定時簡訊測試
      *.整體共用名單
      *.必要名單
      *.依特定檢測類別設備(如"SNMP Trap,Watchdog主控系統)

多元化通報管道與訊息介接整合

    通報群組中的名單可同時經由多種不同的管道傳遞示警訊息,依實際需求建立告警時發佈的方式,
    並可隨時更改名單內容
    對於多重管道的告警訊息發佈也有可能會同步使用到控制類型的功能
    例如: 執行"緊急關機"或"一鍵關機"就適合使用"音效廣播"與"警報燈具"
    告警訊息發佈的管道:
      *.即時資訊戰情中心的監控畫面展示
      *.簡訊(SMS)發佈
      *.郵件(Mail)發佈
      *.LINE訊息發佈
      *.Telegram訊息發佈
      *.轉送 SNMP Trap
      *.傳真(Fax)
      *.音效廣播
      *.數位控制(DO)如:警報燈,警報器,電源開關
      *.網路開機
      *.標記閘道(簡訊命令用)
      *.訊息客屬介接整合

    訊息介接整合
    當使用單位己經有建立企業資訊入口系統(EIP)時,亦可依需要提供告警訊息整合於
    企業資訊入口系統(EIP)的推播系統或即時通訊系統 如: Line
    如果有其他維運管理平台系統,同樣可經由雙方認可之資料協定提供告警資訊內容

告警連帶串聯控制命令

    當"告警事件"發生後除了依據預定的"通報名單"通知維運人員與維護廠商或系統負責人外
    可將"告警事件"視為一項觸發動作,連結警報後續處理的控制機制,"命令閘道"
    每一個的警報控制流程可串聯控制多個"命令閘道"
    每一個"命令閘道"可同時對256台以上的伺服器下達各類型命令 如:系統指令,IPMI命令,CLI命令
    *.直接對伺服主機下達命令
    *.直接對特定設備下達命令
    *.直接控制電源設備
    *.控制一鍵執行

回到首頁