【第177期 June 5, 2012】
 

NonStop專欄

友善列印友善列印轉寄友人轉寄友人

Informatica Ultra Messaging產品監控機制設計

作者/王宜倫

[發表日期：2012/6/5]


前言

Informatica Ultra Messaging(UM)產品(原29West LBM產品)為一高處理容量、低延遲時間的訊息交換軟體產品，應用程式使用此訊息導向中介軟體透過簡單的API，即可處理所有複雜的訊息路由與訊息交換；UM的解決方案可簡化IT基礎架構，消除應用程式間不必要的中繼節點，降低訊息延遲時間，訊息的topic定址，可以不透過常駐程式或伺服器，並可利用網路硬體負責訊息路由、過濾和複製；面對不同的網路和應用環境，可利用參數設定來最佳化傳輸性能。

Informatica UM監看方式說明

UM執行時會自動收集和統計目前執行狀況，但不會主動將此統計數據送出，需透過下列兩種方式將統計數據送出以進行監看。

一、LBM Monitoring API

程式中使用Monitoring API設定要監控的項目與interval，即會將要監控的特定event回傳給程式本身，並將監控的statistics數據送給監控程式(lbmmon)或是SNMP agent，以及再將statistics送給監控軟體整合。

二、Automatic Monitoring

於configuration檔案中設定要監控的項目與interval，即會將要監控的特定event回傳給程式本身，並將監控的statistics數據送給監控程式(lbmmon)或是SNMP agent，以及再將statistics送給監控軟體整合。(本文將以此方式說明)

UM提供兩種方式可讓UM監控與其它監控產品進行整合。

一、SNMP

透過UM SNMP模組，可直接將UM event直接送給監控軟體(例如Prognosis、NNM)進行整合，此為最佳的整合方式，只要監控軟體支援SNMP，即可直接接收UM傳送過來的監控訊息。但目前UM SNMP模組不支援NonStop系統。

二、lbmmon

lbmmon可將監控訊息寫log檔，監控軟體讀取log進行整合，此方式需要另外轉寫程式進行客製化，且改版時若output格式有異動，程式需要重新調整。目前NonStop支援此方式。(本文將以此方式說明)

監看項目說明

此監看機制規劃以協助UM問題解決為方向，主要監看項目包含process運作狀態、資源使用狀況、UM傳輸狀態等功能為主。在production環境的監看的最佳實務(best practice)包含下列兩個監看標的：

一、監看UM程式的Unrecoverable loss與Recoverable loss

監看是否有Unrecoverable loss與Recoverable loss發生可由UM程式是否發生NAKs來判斷。當偵測到UM程式發生NAKs時，再去檢查系統與網路是否有異常狀況。

二、監看UM程式處理訊息速度是否與接收訊息速度取得平衡

監看UM程式的Event Queue長度可判斷程式處理訊息的速度是否大於接收訊息的速度，若source端程式傳送訊息的速度，高於receiver端程式處理速度，receiver端程式Event Queue長度會持續增加，若高於監看門檻值，需要去檢查系統與網路是否有異常狀況。此部分與應用系統架構有關，若設計上為讓訊息暫存在Event Queue中，程式再依序處理，則此Queue長度會很長。

監看規劃說明

一、UM程式提供監看資訊(statistics)

UM程式透過automatic monitoring功能將監看標的資訊送給lbmmon，方式說明如下：

    1.於程式啟動obey file (script)中設定下列環境變數

    # export LBM_MONITOR_INTERVAL=30
    • 此環境變數會讓UM程式每隔30秒送出目前的狀態，線上環境建議的間隔時間為30秒~60秒。

    • 若有UM程式不需要即時監控，只需要知道該UM程式自開始到結束前的執行狀況，可設定一較大的數值，讓程式在結束前將狀態送出，例如：若程式在8:00啟動，於13:40結束所有訊息處理工作，並於13:50結束，可設定INTERVAL為20700，程式會在13:45將處理狀態送出，但要注意程式啟動時間可能之誤差，若太晚啟動可能尚未將處理狀態送出即結束。

    # export LBM_MONITOR_APPID=”ProcessID ”
    • 指定程式名稱，讓Prognosis ADI可辨識該資訊為哪一支UM程式所送出。

    # export LBM_MONITOR_TRANSPORT_OPT=” config=ProcessID-monitor.cfg”
    • 指定UM程式執行monitor所使用的configuration file。範例如下：
      #monitoring topic is /29west/statistics (default)
      #setup monitoring interface
      #monitoring subnet is different than data subnet
      context resolver_multicast_interface 11.1.2.11
      #setup monitoring transport, default is LBTRM
      source transport LBTRM

    2.於UM程式configuration file中設定下列參數(Event Queue only)

    event_queue queue_age_enabled 1
    • 計算訊息在Event Queue中停留的時間。

    event_queue queue_count_enabled 1
    • 計算Event Queue中有多少筆訊息。

    event_queue queue_service_time_enabled 1
    • 計算Event Queue中每個訊息被服務的時間。

二、收集監看資訊(statistics)

lbmmon接收UM程式的資訊後寫log檔，後續可透過其它工具讀取log檔：
    1.啟動lbmmon監看process

    lbmmon --transport-opts="config=lbmmon.cfg"
    • 啟動lbmmon並指定UM程式執行monitor所使用的configuration file。範例如下：

      #monitoring topic is /29west/statistics (default)
      #setup monitoring interface
      #monitoring subnet is different than data subnet
      context resolver_multicast_interface 11.1.2.10
      #setup monitoring transport, default is LBTRM
      #source transport LBTRM

三、監看資訊(statistics)規劃
    1.Source端process建議的監看statistic

    (1-1) Source statistics
    LBT-RM datagrams in transmission window : 17645
    LBT-RM datagram bytes in transmission window : 25161770
    此兩個指標顯示目前source端的transmission window大小與使用狀況，若要調整transmission window大小時，需要觀察datagrams in transmission window的大小。

    LBT-RM NAK packets received : 0
    LBT-RM NAKs received : 0
    LBT-RM NAKs ignored : 0
    LBT-RM NAKs shed : 0
    LBT-RM NAKs ignored (retransmit delay) : 0

    上述指標顯示該source收到NAKs的情形。預期source端收到的NAKs應該等於receiver端送出的NAKs，若有差異(receiver > source)，則表示有loss的問題，若持續發生，則會造成unrecoverable loss。

    LBT-RM datagrams sent : 35045
    LBT-RM retransmission datagrams sent : 0
    上述兩指標可顯示source端重送多少筆訊息與所佔比例。

    (1-2) Context statistics (Source)

    Topics in source topic map : 1
    Topics in receiver topic map : 1
    Unresolved topics in receiver topic map : 0
    檢查Topic in receiver topic map可了解source端與receiver端是否已完成Topic Resolution。

    2.Receiver端process建議的監看statistic

    (2-1) Receiver statistics
    LBT-RM NAK packets sent : 0
    LBT-RM NAKs sent : 0
    此兩個指標顯示是否有recoverable loss，UM source端收到NAKs後會自動重傳，若有短暫的NAKs發生並不會造成問題，但是會影響latency。

    NCFs received (ignored) : 0
    NCFs received (shed) : 0
    NCFs received (retransmit delay) : 0
    NCFs received (unknown) : 0

    此四個指標表示是否有unrecoverable loss，發生NAKs後，UM source端拒絕重傳，source拒絕重傳原因可能為retransmission window中已無此筆message，或是無法辨識的NAK。Ignored表示unrecoverable loss；shed/retransmit delay表示造成額外的loss，且可能會造成大量的unrecoverable loss；unknow表示source端收到無法辨識的NAK，此也會有unrecoverable loss的問題。

    LBT-RM datagrams unrecoverable (window advance) : 0
    LBT-RM datagrams unrecoverable (NAK generation expiration) : 0
    此兩個指標為unrecoverable loss。Window advance表示receiver端要重傳的packet已不再source端的retransmission window中；NAK generation expiration表示receiver放棄要求source端重送loss的packet。若此兩個指標值持續增加，須注意該receiver可能為”crybaby receivers”或是會造成nak storm問題，要特別注意。

    (2-2) Event Queue statistics
    Data messages currently enqueued : 0
    Total data messages enqueued : 600001
    Data message service mean time : 1us
    Data message service maximum time : 7909us
    上述指標顯示目前event queue的狀況，若處理訊息的速度慢於接收訊息的速度，currently enqueued長度會持續增加，若高於監看門檻值，需要去檢查系統與網路是否有異常狀況。此部分與應用系統架構有關，若設計上為讓訊息暫存在Event Queue中，程式再依序處理，則此Queue長度會很長，最常可達21億或是受限於記憶體大小。

    Event Queue門檻值建議設定方式說明：
    • 依據receiver端process每秒鐘可處理的最大訊息數量設定門檻值：假設receiver端設計每秒鐘處理訊息數量最大為30,000，考量瞬間爆量狀況，可設定監看門檻值為最大處理容量的2倍，設定為60,000。

    • 依據source端retransmission window可存放的訊息數量：source端retransmission window size預設為24MB(最大值)，考量若event queue中的event有loss需要重傳的狀況，假設最壞狀況為讀取event queue中最老的(old)的訊息發現前一筆訊息loss，因此，需要自retransmission window重傳前第60001筆訊息(單筆)；假設每筆訊息長度為200 Bytes，retransmission window中可存放約120,000筆訊息，所以門檻值設為60,000仍在安全範圍內。

    (2-3) Context statistics (Receiver)
    Topics in receiver topic map : 1
    Unresolved topics in receiver topic map : 0
    檢查是否有unresolved topics可了解receiver與source是否已完成Topic Resolution。

    3.告警機制:
    • NAKs統計值為累計的，建議監控告警機制為當連續兩次監控interval所偵測到的NAKs均增加，Prongosis需產生alarm，值班人員再檢查系統或網路狀態是否有異常。

    • -Event Queue指標為當時的值，可設定門檻值，若指標超過門檻值，Prognosis產生alarm，值班人員再檢查系統或網路狀態是否有異常。

結論
  • 針對UM傳輸最重要的監看項目為recoverable loss與unrecoverable loss，可藉由statistics的NAKs與NCF來判斷，其餘statistics可做為系統使用趨勢規劃使用。

  • 較簡單的監控方式為使用Automatic Monitoring方式，程式可完全不需要修改，只須設定configuration file與啟動環境變數。

  • 若已有SNMP監控機制，可透過UM SNMP agent將statistics送給集中監看console，另一簡單的方式為lbmmon，lbmmon可將收到的statistics寫log，可監看此log；或是透過程式處理此log，顯示重要statistics狀況。

  • 使用SNMP或是lbmmon監看方式都可將UM監控與既有單一介面集中監看console整合，無須額外增加監看介面。

參考資料
  • UM參考手冊：29West Ultra Messaging® Concepts

  • UM參考手冊：29West Configuration Guide