Skip Navigation Links首頁 > 產品與服務 > 技術分享

技術分享

Informatica Ultra Messaging產品監控機制設計

作者/王宜倫
前言

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

 

回上一頁