前言
壓力測試和監控分不開，監控能夠記錄壓測過程中狀態，方便問題跟蹤、定位。本篇我們將討論對壓測客戶端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,"tsung_controller@10.10.10.10"} 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,"tsung_controller@10.10.10.10"} 1 4164.0 0.0 45938 4164 24914.798543689314 412
stats: {sentpackets,"tsung_controller@10.10.10.10"} 1 4182.0 0.0 39888 4182 22939.191747572815 412
stats: {cpu,"tsung_controller@10.10.10.10"} 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種方式進行監控目標服務器資源占用情況：
大致交互功能，粗略使用一張圖表示：
?
- 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\_controller@10.10.10.10
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 tsung_controller@10.10.10.10
- 若是hostname形式，可以這樣：
sh connect_tsung.sh tsung_controller@tsung_master_hostname
- 成功進入之后，輸入
nodes(). 可以獲得完整tsung client節點列表
- 啟動tsung時生成日志所在目錄，可以看到類似日志文件：
- tsung client端產生日志單獨存放，格式為
節點名稱.log
- eg: tsung15@10.10.10.113.log，那么節點名稱為tsung15@10.10.10.113
- 可以直接連接：
sh connect_tsung.sh tsung15@10.10.10.ll3
如何診斷/監控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構建的、或類似商業產品，一般會有提供專門數據收集服務器，但對于開源的應用而言，需要兼顧通用需求，也是能夠理解的。