Python 版 APM 服務使用測試

後端開發與雲服務

雲服務這個詞，大概最先是從雲盤開始的，那時候概念也特別簡單，無非就是把一些數據存在別人的服務器上，在」雲存儲」這個名詞火起來以前，QQ 也有提供網站的功能用來存一些小東西（05年06年的樣子，那時候大概只有幾十 M 的空間），其實剛聽到這個概念的時候我就很不理解，光存存東西不至於吹得這麼玄乎吧。畢業後入行，雲服務器才慢慢真真的豐富起來，從最開始的 VPS 變成雲服務器、存儲變成資源服務器、遠程數據庫等等，如今甚至有幫你防 DDOS 的服務（去年和今年貌似 DDOS 變得愈來愈沒有節操了）。確實節省了不少精力，也省錢。

除了雲，最近幾年還有另一個比較火的詞："大數據」。我沒接觸過那麼大的數據，做爲一個半吊子運維，接觸的最大的數據應該就是服務器 log 了。因此大數據的東西之後有機會接觸再說，對我來講更重要的是 — 數據統計。

服務端的各類 log 不只是分析服務器的狀態的重要參數，也是從後臺代碼裏抓 bug 抓異常檢查 SQL 性能等各類工做的參考。log 數據通常都是單調並且重複的居多，要發現它的價值，每每須要大量的分析和統計工做。各類監控服務、分析工具也是層出不窮。不過到今年我才知道有個詞叫 "APM"。

APM (Application Performance Management/Monitoring) 簡單翻譯過來就是"應用性能管理/監控」(也許說監控更準確一些)。大概就是服務器上部署的 awstats、nagios、zabbix 等一堆東西的集合。有服務器的地方就有云，既然這個事情這麼麻煩，那就天然也能夠交給別人來作了。

前幾天找到了一個 Python 的小 web 框架：bottle，只有一個文件，簡潔好用，以爲很不錯，先是用它來作了一個簡單的小應用（APP 下載，公司內部使用），準備這段時間嘗試用它來本身寫一個簡單的博客系統，改造一下本身的博客，因此業務時間花在搞 Python 上的比較多一點。剛好看到了在測 Python 版本的探針，因而部署來測試一下。部署以前先在本地作了一些測試，不過聽雲目前僅支持基於 django 開發的程序（文檔上寫的目標是支持全部以 wsgi 協議部署的 Python Web 服務，包括 flask、tornado 等等，不過這個應該還要等後續開發支持了），因此我就先在本地用 django 測了一下。

聽雲探針(Python版)的使用

探針部署過程十分簡單，在聽雲後臺複製本身帳戶的 license key，生成配置文件，將配置文件地址加載到環境變量中，就能夠啓動程序開始使用了。如下是測試環境部署步驟的介紹。

先用 virtualenv 開闢一個環境並 active 之：

virtualenv tingyun
cd tingyun
source bin/active

聽雲探針在 pypi 的倉庫裏有，因此能夠直接安裝了，同時也安裝 django , 探針支持 MySQL 的 log 記錄，因此我也安裝了 MySQL 的組件並將 django 的數據庫從 sqlite 改爲 MySQL：

# 安裝組件
pip install tingyun django MySQL-python
# 建立一個 django 工程
django-admin startproject www

接着須要修改一下 django 的數據庫選項，進入到 www/www 目錄，打開 settings.py，找到 DATABASE 的字典，註釋掉原有的 sqlite 選項並改成 MySQL：

# 'default': {
#     'ENGINE': 'django.db.backends.sqlite3',
#     'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
# }
'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'django',
    'USER': 'root',
    'PASSWORD': '',
    'HOST': '',
    'PORT': '',
}

在 MySQL 中建立 django 的庫，而後安裝 django 的 admin 後臺須要的數據表（注意回到 manage.py 所在的目錄）：

python manage.py syncdb

接下來設置聽雲的服務，按照聽雲後臺的提示和文檔說明進行就能夠了：

# YourLicenseKey 是你的聽雲後臺裏顯示的 key
# 聽雲後臺裏將 tingyun.ini 放置在 tmp 目錄，我建議你放在當前工做目錄，省得丟失
# 一些配置參數能夠打開 tingyun.ini 進行修改
tingyun-admin generate-config YourLicenseKey tingyun.ini
#
# 這裏的 TING_YUN_CONFIG_FILE 寫絕對路徑比較保險，如下是我本地的目錄
# 若是是在服務器上，能夠寫入到 .bashrc 或者 .bash_profile 中去，須要重啓服務時不用從新設置
export TING_YUN_CONFIG_FILE=/Users/Scholer/Work/Personal/tingyun/tingyun.ini
#
# 聽雲的服務會讀取當前環境變量的參數 TING_YUN_CONFIG_FILE 來獲取配置文件
# 咱們能夠先檢查一下，若是看到 success 字樣就 OK
tingyun-admin check-config

萬事具有，能夠啓動服務了：

tingyun-admin run-program python www/manage.py runserver

接下來咱們就能夠瀏覽一下頁面，登陸一下後臺等等生成一些訪問記錄來看看效果了（或者能夠比較殘暴一點用測試工具，我用 ab 發了一些的測試請求）。

一切順利的話，過一下子刷新一下聽雲的後臺，就能看到一些數據了。

有一些事情須要注意一下：

1. 聽雲的多個應用是同一個 key，經過應用名稱來區分應用；
2. 不一樣於一些其餘服務、聽雲沒有新建一個 應用的過程，有部署、上報的數據就能看到數據了；
3. 若是使用 uwsgi 的方式不是，須要開啓 enable-threads 和 single-interpreter 的選項。

上報數據觀察

登陸到聽雲的後臺管理面板就能查看到一些監控日誌分析了（圖表是用 highcharts 作的，體驗至關不錯）。

圖中能夠看到一些基本的數據圖表，包括應用的響應時間、Apdex（應用程序性能指數），應用響應耗時和吞吐率等等。

此外面板上也會有硬件的基本信息，包括 CPU 的佔用時間、內存佔用等參數。

各項參數指標的統計最終目的都是爲了分析服務器自己的承載能力和性能。當以上參數出現異常狀況，好比響應時間過長、CPU負載太高或者內存剩餘很少時，就要考慮升級硬件資源或者對程序進行優化了。

Apdex (Application Performance Index) ，應用性能指數。這是一個近幾年成立的聯盟組織，大概是在 2010 年發起的，12 年以後沉寂了兩年，去年又開始活躍了。這個聯盟意在經過一個統一的標準來計算和衡量應用程序的的性能，在它的 官網 中有一些專門的文章來介紹本身。

"Apdex is a way to study measurements of any experience that can be interpreted on a scale ranging from excellent to unacceptable. " （Apdex 用以學習解釋從好到壞的評級標準的相關經驗。）

Apdex 的計算在下面這篇文章用也有介紹：

Apdex = (正常樣本 + 0.5 x 低質樣本 + 0 x 高質樣本) / 樣本總量

咱們能夠這樣把正常樣本理解成正常的時間，低質和高質就分別表示響應的慢和快。顯然計算結果從 1 到 0 就表示從好到壞。

詳細介紹：http://www.apdex.org/index.php/2014/05/apdex-is-not-just-for-application-performance/

以上兩張統計圖分別展現了應用層的處理時間與數據庫調用時間。這兩個參數是對程序和 SQL 語句進行優化的重要參考。這裏應該是計算的平均時間。

在實際的分析過程當中，咱們也一樣須要對於全部耗時過長的處理或者 SQL 慢查詢進行分析和優化。聽雲也提供了對於耗時應用和 SQL 的統計。

在上面的"最耗時的應用過程"中，有一個牆鍾時間比的概念。牆鍾時間（Wall-clock time / wall time）指的是程序從開始執行到結束的過程當中人的時間感知（這個時間是大於 CPU 時間的，由系統提供）。牆鍾時間比就表示當前時間點下某個程序佔總牆鍾時間的百分比。

除了常見關係型數據庫的監控，聽雲也提供了對 memcached、Redis、MongoDB 等非關係型數據庫的監控和統計。

響應率和吞吐率參數參數。吞吐率指的是單位時間內響應的數量。這兩個參數是對網站整體的響應速度和承載能力的評估。

吞吐量、響應時間、Apdex和錯誤率的概覽。

聽雲後臺的參數記錄十分全面，從硬件基礎到程序響應到數據庫執行耗時都有完整的分析和記錄。不過遺憾的是在後臺沒有看到 HTTP 狀態碼的記錄，相似 awstats 提供的記錄和統計功能。不過相對於一個須要本身作複雜的配置的開源組件，優點仍是十分明顯的。我也相信隨着時間的推移，服務會愈來愈豐富，這些信息都會被記錄並分析出來。

簡析

部署和數據分析都說了，如今也能夠簡單的來分析下聽雲是如何運做的。我無心去弄清楚探針工做的每個步驟，但卻能夠了解一下大體的流程。

Python 做爲一門膠水語言，已經積澱了豐富的優秀模塊，從來都是被公認爲做爲服務端運維最強力的腳本語言，對於這類問題的處理上，具備自然的優點。聽雲在語言上也作了處理，可以同時支持 Python 2 和 Python 3。

在聽雲的配置文件 tingyun.ini 中，除了有 license_key 之外，還有 app_name、 log_file 、 log_level 等參數配置。其中 action_tracer.log_sql 能夠選擇是否將 SQL 日誌只保存在本地文件中（這應該是出於安全考慮，畢竟把全部的 SQL 日誌都暴漏給服務平臺，有些人可能會有些顧慮。可是考慮到如今服務器通常都是雲服務器，因此這其實問題也並不大，選擇了服務，就應該相信服務），這點聽雲考慮的很周到。

log 文件中記錄了一些 trace 的log，包括程序耗時等。

回到程序自己中去，在啓動探針的時，咱們執行的是 tingyun run-program，最終執行的是聽雲的 package 中 admin 目錄下的 run_program 的函數，check_config、generate_config 也位於 admin 目錄下。整個程序目錄還包括 bootstrap 、hook 和 api 目錄。

root_directory = os.path.dirname(root_directory)
boot_directory = os.path.join(root_directory, 'bootstrap')
python_path = boot_directory

run_program 將 bootstrap 目錄加入系統 path 中。經過 Python 提供的兩個 hook（sitecustomize 和 usercustomize 之中的 sitecustomize，聽雲探針正式被加載到運行環境中：

if config_file is not None:
    # When installed as an egg with buildout, the root directory for
    # packages is not listed in sys.path and scripts instead set it
    # after Python has started up. This will cause importing of
    # 'tingyun' module to fail.

    if root_directory not in sys.path:
        sys.path.insert(0, root_directory)

    import tingyun.agent

    # Finally initialize the agent.
    tingyun.agent.initialize(config_file=config_file)

在 tingyun.api.initial.config 中，initialize 函數被執行，調用 _process_module_builtin 函數，探針開始工做 ：

_load_configuration(config_file=config_file)

if not _detect_done:
    _detect_done = True
    _process_module_builtin()

MySQL、Redis 等監控模塊都位於 hook 目錄下，經過 _process_module_definition_wrapper 函數將進程與監控模塊進行綁定，包括 django 的主要模塊以及經常使用的數據庫等。在覈心模塊執行的時候觸發監控，將數據回傳到 api.tracert 模塊進行處理。

而對於硬件信息的檢測則由 api.platform.system_info 進行。

應用監控數據最終會由 api.tracert.uploader 上傳到聽雲的服務器（host 的設置位於 api.settings 中，host 地址是 redirect.networkbench.com，因此看到你的服務器往這個域名發送請求時，不要以爲奇怪），經過聽雲的處理，咱們就能看到應用程序的各類監控數據了。

對聽雲探針的簡單分析就到這裏，有興趣的讀者能夠進一步深刻研究。其實對於這類雲服務，程序的自己都是透明的，不用有太大的安全顧慮，對於服務提供方而言，更重要的是數據的分析工做。

聽雲自己提供的服務器是很是優秀的，雖然目前還並不是完美。我也期待服務能更加完善，提供更完善的數據分析。另一方面，經過 tingyun-admin run-program 的方式啓動程序，對開發者和服務器管理員來講可能有些侵入感。若是能用模塊加載的方式調用，或許更符合某些開發者的習慣。