前言
壓力測試和監控分不開，監控能夠記錄壓測過程中狀態，方便問題跟蹤、定位。本篇我們將討論對壓測客戶端tsung client的監控，以及對被壓測服務器的資源佔用監控等。同時，也涉及到Tsung運行時的實時診斷方式，這也是對Tsung一些運行時狀態的主動監控。
壓測客戶端的監控
壓測端（指的是tsung client）會收集每一個具體模擬終端用戶（即ts_client模塊）行爲數據，發送給主節點（tsung_controller），供後面統計分析使用。

- ts_client模塊調用ts_mon，而ts_mon又直接調用ts_mon_cache，有些繞，不直觀（邏輯層面可忽略掉ts_mon）
- count爲計數器，sum表示各項累加值，sample和sample_counter計算一次統計項的平均值&標準差
- tsung.dump文件一般不會創建&寫入，除非你在tsung.xml文件中指定需要dump屬性爲true，壓測數據量大時這個會影響性能
-
match.log僅僅針對HTTP請求，默認不會寫入，除非在HTTP壓測指定
<http url="/" method="GET" version="1.1"/> <match do=’log’ when=’match’ name=’http_match_200ok’>200OK</match> -
從節點tsung client所記錄日誌、需要dump的請求-響應數據，都會交由tsung_controller處理
-
ts_mon_cache，接收到數據統計內存計算，每500毫秒週期分發給後續模塊，起到緩衝作用
-
ts_stats_mon模塊接收數據進行內存計算，結果寫入由ts_mon觸發
-
ts_mon負責統計數據最每10秒定時寫入各項統計數據到tsung.log文件，非實時，可避免磁盤IO開銷過大問題
tsung/src/tsung_controller/tsung_controller.app.in對應{dumpstats_interval, 10000}- 可以在運行時修改
-
tsung.log文件彙集了客戶端連接、請求、完整會話、頁面以及每一項的sum操作統計的完整記錄，後續perl腳本報表分析基於此
-
ts_mon模塊處理tsung.log的最核心模塊，全局唯一進程，標識爲
{global, ts_mon}
比如某次單機50萬用戶壓測tsung.log日誌片段：
# stats: dump at 1467620663
stats: users 7215 7215
stats: {freemem,"os_mon@yhg162"} 1 11212.35546875 0.0 11406.32421875 11212.35546875 11346.37109375 2
stats: {load,"[email protected]"} 1 0.0 0.0 0.01171875 0.0 0.01171875 2 17,1 Top
stats: {load,"os_mon@yhg162"} 1 2.3203125 0.0 3.96875 0.9609375 2.7558736313868613 411
stats: {recvpackets,"os_mon@yhg162"} 1 5874.0 0.0 604484 5874 319260.6024390246 410
stats: {sentpackets,"os_mon@yhg162"} 1 8134.0 0.0 593421 8134 293347.0707317074 410
stats: {cpu,"os_mon@yhg162"} 1 7.806645016237821 0.0 76.07377357701476 7.806645016237821 48.0447587419309 411
stats: {recvpackets,"[email protected]"} 1 4164.0 0.0 45938 4164 24914.798543689314 412
stats: {sentpackets,"[email protected]"} 1 4182.0 0.0 39888 4182 22939.191747572815 412
stats: {cpu,"[email protected]"} 1 0.575191730576859 0.0 6.217097016796189 0.575191730576859 2.436491628709831 413
stats: session 137 2435928.551725737 197.4558174045777 2456320.3908691406 2435462.9838867188 2436053.875557659 499863
stats: users_count 0 500000
stats: finish_users_count 137 500000
stats: connect 0 0 0 1004.4912109375 0.278076171875 1.480528250488281 500000
stats: page 139 12.500138756182556 1.1243565417115737 2684.760009765625 0.43115234375 16.094989098940804 30499861
stats: request 139 12.500138756182556 1.1243565417115737 2684.760009765625 0.43115234375 16.094989098940804 30499861
stats: size_rcv 3336 3386044720
stats: size_sent 26132 6544251843
stats: connected -139 0
stats: error_connect_timeout 0 11
tsung.log日誌文件可由tsung_stats.pl腳本提取、分析、整理成報表展示，其報表的一個摘要截圖：

異常行爲的收集
當模擬終端遇到網絡連接超時、地址不可達等異常事件時，最終也會發給主節點的ts_mon模塊，保存到tsung.log文件中。
這種異常記錄，關鍵詞前綴爲 **error_**：
- 比如ts_client模塊遇到連接超時會彙報
error_connect_timeout錯誤 - 系統的可用端口不夠用時（創建與壓測服務器連接數超出可用段限制）上報
error_connect_eaddrinuse錯誤
Errors報表好比客戶端出現問題晴雨表，再加上tsung輸出log日誌文件，很清楚的呈現壓測過程中出現的問題彙集，方便問題快速定位。

被壓測服務器的監控
當前tsung提供了3種方式進行監控目標服務器資源佔用情況：
- erlang
- snmp
- Munin
大致交互功能，粗略使用一張圖表示：

- tsung_controller主節點會被強制啓用監控
- SNMP方式，客戶端作爲代理主動註冊並連接開放SNMP的服務器，SNMP安裝針對新手來說比較複雜
- Munin採用C/S模式，自身要作爲客戶端連接被壓測服務器上能夠安裝Munin Server
- erlang方式，本身代理形式監控服務器資源佔用，滿足條件很簡單：
- 需要能夠自動登錄連接
- 並且安裝有Erlang運行時環境，tsung_controller方便啓動監控節點
- 採用遠程加載方式業務代碼，省去被監控端部署的麻煩
- 現實情況下，我一般採用一個腳本搞定自動部署監控部署客戶端，自動打包可移植的Erlang，簡單綠色，部署方便
- 提供監控採樣數據包括 CPU/Memory/Load/Socket Sent&Recv
- 所有監控數據都會被髮送給ts_mon模塊，並定時寫入到tsung.log文件中
看一個最終報表部分呈現吧：

tsung對服務器監控採樣手機數據不是很豐富，因爲它面向的更爲通用的監控需求。
更深層次、更細粒度資源監控，就需要自行採集、自行分析了，一般在商業產品在這方面會有更明確需求。
日誌收集
和前面講到的終端行爲數據採集和服務器端資源監控行爲類似，tsung運行過程中所產生日誌被存儲到主節點。
tsung使用error_logger記錄日誌，主節點tsung_controller啓動之後，會併發啓動tsung client從節點，換句話來說tsung client從節點是由主節點tsung_controller創建，這個特性決定了tsung client從節點使用error_logger記錄的日誌都會被重定向到主節點tsung_controller所在服務器上，這個是由Erlang自身獨特機制決定。
因此，你在主節點log目錄下能夠看到具體的日誌輸出文件，也就水到渠成了。因爲Erlang天生分佈式基因，從節點error_logger日誌輸出透明重定向到主節點，不費吹灰之力。這在其他語言看來，確實完全不可能輕易實現的。
基於error_logger包裝日誌記錄，需要一個步驟：
- 設置輸出到文件系統中
error_logger:tty(false) - 設定輸出的文件目錄
error_logger:logfile({open, LogFile}) - 包裝日誌輸出接口
?DEBUG/?DEBUGF/?LOG/?LOGF/ - 最終調用包裝的error_logger接口
debug(From, Message, Args, Level) ->
Debug_level = ?config(debug_level),
if
Level =< Debug_level ->
error_logger:info_msg("~20s:(~p:~p) "++ Message,
[From, Level, self()] ++ Args);
true ->
nodebug
end.
和大部分日誌框架設定的日誌等級一致，emergency > critical > error > warning > notice (default) > info > debug，從左到右，依次遞減。
需要注意事項，error_logger語義爲記錄錯誤日誌，只適用於真正的異常情況，並不期望過多的消息量的處理。
若當一般業務調試類型日誌量過多時，不但耗費了大量內存，網絡/磁盤寫入速度跟不上生產速度時，會導致進程堵塞，嚴重會拖累整個應用僵死，因此需要在tsung.xml文件中設置至少info級別，至少默認的notice就很合適。
Tsung運行時診斷/監控
Tsung在運行時，我們可以remote shell方式連接登錄進去。
爲了連接方便，我寫了一個腳本 connect_tsung.sh，只需要傳入tsung節點名稱即可：
# !/bin/bash
## 訪問遠程Tsung節點 sh connect\_tsung.sh tsung\[email protected]
HOST=`ifconfig | grep "inet " | grep -v "127.0.0.1" | head -1 | awk '{print $2}' | cut -d / -f 1`
if [ -z $HOST ]; then
HOST = "127.0.0.1"
fi
erl -name tmp\_$RANDOM@$HOST -setcookie tsung -remsh $1
需要安裝有Erlang運行時環境支持
當然，要向運行腳本，你得知道Tsung所有節點名稱。
如何獲得tsung節點名稱
其實有兩種方式獲得Tsung節點名稱：
- 直接連接tsung_controller節點獲得
- 若是IP形式，
sh connect_tsung.sh [email protected] - 若是hostname形式，可以這樣：
sh connect_tsung.sh tsung_controller@tsung_master_hostname - 成功進入之後，輸入
nodes().可以獲得完整tsung client節點列表
- 若是IP形式，
- 啓動tsung時生成日誌所在目錄，可以看到類似日誌文件：
- tsung client端產生日誌單獨存放，格式爲
節點名稱.log - eg: [email protected]，那麼節點名稱爲[email protected]
- 可以直接連接：
sh connect_tsung.sh [email protected]
- tsung client端產生日誌單獨存放，格式爲
如何診斷/監控Tsung運行時
其實，這裏僅僅針對使用Erlang並且對Tsung感興趣的同學，你都能夠進來了，那麼如何進行查看、調試運行時tsung系統運行情況，那麼就很簡單了。推薦使用 recon 庫，包括內存佔用，函數運行堆棧，CPU資源分配等，一目瞭然。
若問，tsung啓動時如何添加recon依賴，也不復雜：
- 每一個運行tsung的服務器拷貝已經編譯完成的recon項目到指定目錄
-
tsung_controller主節點啓動時，指定recon依賴庫位置
tsung -X /Your_Save_Path/recon/ebin/ ...
說一個用例，修改監控數據每10秒寫入tsung.log文件時間間隔值，10秒修改爲5秒：
application:set_env(tsung_controller, dumpstats_interval, 5000).
執行之後，會立刻生效。
小結
總結了Tsung主從監控，以及服務器端監控部分，以及運行時監控等。提供的被壓測服務器監控功能很粗，僅收集CPU、內存、負載、接收數據等類型峯值，具有一般參考意義。但基於Tsung構建的、或類似商業產品，一般會有提供專門數據收集服務器，但對於開源的應用而言，需要兼顧通用需求，也是能夠理解的。
