背景
伴隨租房業務的不斷髮展，租房各個子業務系統的集群數量也迎來了一波增長，提供的API接口數量和服務數量也有了井噴式增長，但在業務層自動化監控方面我們卻缺失統一的工具平臺，隨之而來我們開發同學會經常碰到這些問題：
1. 有哪些的接口訪問超時/特別慢，往往關注的時候就是服務出現瓶頸的時候。
2. 線上top uri每日的訪問量是多少，沒有可視化的工具，只能去單機通過awk命令統計。
3. 不知道接口的平均耗時是多少，也就沒有優化服務的動力。
但當時我們面對類似問題通常採用下面的方法解決：
1. 採用公司的人工埋點系統Wmonitor手動在代碼裡埋點，優點是能實現部分可視化和預警，缺點是埋點流程複雜每個接口都需要申請埋點值並在接口中手動埋點，管理複雜效率低下，對開發同學的開發意識要求很高。
2. 通過nginx日誌查詢訪問詳細情況如 uri，訪問狀態，耗時等信息，優點是能得到訪問量和訪問時長等數據，缺點是每次都需要人工手動查詢，缺乏無可視化平臺和預警，如某一臺機器故障/性能故障則完全無感知 。
由於公司內部已有基於Java Web框架的API監控系統，鑑於這套系統已成熟，PHP側可以複用其數據存儲、數據視圖和報警部分，然後自己實現數據採集和上報即可實現PHP可用的API監控系統。那我們的核心重點就是解決在PHP-FPM多進程模型下，如何靈活、高效、穩定的實現數據的採集和上報。
WF manager 是JAVA WEB層API監控系統
設計理念
1. 靈活定製
面對不同的業務集群，作為服務方需要兼顧靈活和標準， 首先通過從眾多的接口訪問信息中抽出來標準化的數據信息集，如集群名稱，接口uri，http Code，訪問量，訪問時長，超時量，失敗量等具體的數據，標準化的數據保證了傳輸的順暢，為後續的分析，統計，展示奠定基礎。其次提供靈活的可配置方案，兼容不同集群，不同採集間隔和自動化uri採集模型，去實現業務的靈活變通。
<code>wrm.enable=1
wrm.tick=60
wrm.timeout=2000
wrm.collector_register_url=https://****.**.com/****/****
wrm.collector_port=****
wrm.cluster=***_***_***
wrm.total_url_num=500
wrm.enable_sync_uri=1
wrm.sync_uri_url=****.**.com/****/****/<code>
2. 低成本接入
利用PHP的底層特性以擴展形式在PHP進程啟動的時候加載，避免開發同學因接入監控服務而需要做出額外的開發，實現無感知的數據採集。
PHP編譯執行主要流程
3. 資源利用率高
合理選型數據結構和接入方式，依託於PHP-FPM主進程的監控進程，避免對系統額外的cpu和內存資源佔用，保證線程安全調用。
系統架構
1. 首先啟動PHP Zend引擎後，在註冊動態擴展的過程中通過調用MINIT鉤子，fork出來監聽進程，從而在每次request開始/結束時 執行業務邏輯。
2. 監聽根據系統配置，初始化全局變量如上報時長，內存大小，上報地址等信息，以及通過mmap開闢共享內存空間和pthread去實現線程安全上報。
3. 每次request在請求時會初始化php_request_startup，並依次遍歷調用擴展中調用Rinit，在這個過程中收集到uri，http code，訪問時長等信息存儲如對應的結構體。
4. 監聽進程根據配置tick收集指定間隔時間的數據後，通過切換數據hash的內存塊指針，平滑變更hashtable的角色屬性，啟動上報線程，開始壓縮數據並異步上報至數據中心服務側。
PHP Restful API系統流程圖
功能設計&實踐
1. 進程啟動
PHP引擎啟動過程中通過php_module_startup遍歷php_extension_list中在php.ini註冊的動態擴展，並依次調用對應的Minit鉤子函數，在這個過程中我們在Minit中fork出來上報進程，根據配置的url個數初始化共享內存，並依據bkrdhash算法實現uri的hash存儲，同時一個hash做輸出，一個hash做存儲，並通過指針動態切換.該進程同時會監聽主進程。
2. 日誌收集
在Rinit的鉤子中，依賴於sapi_getenv和SG去獲取本次請求的參數，如header和Server信息,根據uri路由，收集後存儲於trace實體中，在此鉤子中不做其他操作，保證最小粒度干擾線上的資源開銷，在Rshutdown鉤子中，統計響應狀態，耗時等日誌信息，並存儲到對應的hash中。
<code>typedef struct wrm_trace_analyze {
int mutex; // 互斥量
struct timeval total_duration;
int success_times;
int failed_times;
int timeout_times;
int server_port;
char server_addr[32];
char uri[256];
} wrm_trace_analyze;/<code>3. 數據上報
依託於配置中的上報週期，上報線程會將數據存儲的hash指針做切換，從這一刻起，另外一個空hash結構體開始接受新數據做存儲，同時原輸出hash開始壓縮並上報數據中心服務側，上報完成後等待下個週期的切換，如此循環往復。
PHP Restful API監控效果圖
關鍵問題
1. 如何避免對上報服務端的流量衝擊，合理利用資源
鑑於每次的http請求都會產生一條日誌數據，如果每次都進行上報則對服務端是個很大的流量衝擊，針對這種情況我們通過合理設計本地存儲結構，實現時間週期內的日誌數據彙總存儲，壓縮&定期上報彙總數據。
2. 如何設計一個有效的數據採集數據結構
數據實現hash存儲，key值採用bkrdhash算法，以質數作為種子，每個字符串的ascii加和，保證每個字符串都參與到運算中，同時hash中只存儲有效的日誌數據，如http code 200/500次數，時間等信息，以10000個uri舉例，只額外佔用不到10M內存，並在數據udp上報到服務側之前通過gz壓縮,保證資源的合理優化。
3. 如何去解決hash數據集的併發性寫入
我們採用的futex內核級同步鎖.在眾多php-fpm在同一時間點寫入同一個hash的，如果採用自旋鎖+等待，在線程較多的時候其他上下文的切換的資源開銷不低，但是通過futex內核級鎖，在通過雙向鏈表的隊列維護競爭的線程，在佔用鎖資源的線程釋放資源後，會按順序從隊列中喚起等待的線程寫入。
4. 如何在保證對數據採集和上報流程隔離，實現線程安全的全流程監控
我們採用的方案是通過監聽進程的存儲層開闢一個共享內存區域，分別為分為存儲區A和上報區B,在監控服務收集的過程中所有數據沉澱在A上，等待上報週期時間點一到則會將數據寫入的指針指向B，此時B角色切換為存儲區，A角色變更為上報區，線程將A上的數據進行上報，上報成功後clean掉數據，等待下一次的角色變更，如此循環往復，實現線程安全的異步上報流程。
5. 如何低成本部署和兼容
我們以php擴展為獨立載體，不依賴任何框架，支持公司內部物理機和私有云等集群環境。業務集群需要監控服務則可將此.so文件加載到項目extension/下目錄或者 php配置級的extension下，同時在項目中的extension.conf配置採集參數即可方便使用，也因此實現項目級的日誌採集能力。
此擴展語法同時支持PHP7.0.0以上的版本集群環境。
PHP Restful API系統架構圖
總結成果
Restful的自動化日誌監控服務，在租房業務線集群以擴展的形式已成功部署至生產環境，各業務線負責人可以方便的通過公司的提供的可視化工具平臺（WF manager）直觀看到所屬的接口訪問詳情，從而節省各個業務線手動開發，標準不一的開發代價和維護成本。
目前租房業務線累計已有幾十個集群先後通過此擴展接入wfmanager系統，覆蓋百餘臺PHP服務器，每分鐘採集日誌超上百萬次，覆蓋90%的租房業務線上流量，為服務的平穩運行提供有力保障。
通過可視化的線上接口實時訪問數據，對應服務的負責人實現了對所屬服務的主動關注/被動報警能力，為服務質量和穩定性提供了有力的支持，具體體現在以下兩個方面：
1. 在工程效率方面，過往線上出現接口訪問超時現象到問題解決的時間跨度週期往往超過1天，通過此擴展接入日誌採集能力後，實現了線上的訪問實時監控預警，從問題出現到解決的時間跨度也降低為分鐘級別，如 一些APP端的詳情頁在優化之前接口加載時長達到300ms以上，接入日誌監控擴展後清晰看到線上的真實耗時，對應同學收到預警後，經過幾輪實時技術優化對比，已成功將耗時降低為100ms以下。
2. 在數據分析維度，過往分析日誌從單機awk統計到現在集群整體視角，粒度甚至細分至單機uri的級別，直觀監測到實時訪問數據，實現了同比，環比的流量波動分析，精準掌握產品的線上的訪問流量,為保證服務可用性的增擴容以及優化提供有力決策支持。
陳藝天 / 58房產租房技術部 / 先後負責PHP技術棧的wscf重構，wfmanager擴展，php微服務孵化等；
胡坤 / 58房產租房技術部 / 先後負責租房業務wfmanager擴展項目，房源直播及保障服務在線化能力等；
閱讀更多 58技術 的文章
