Neeke 高馳濤，云智慧高級架構師，PHP高級開發組成員之一，是云智慧透視寶產品的核心研發成員，以下是他的分享實錄：

先從一個剛剛發生的真實案例開始這次分享，今天的分享延遲了半個小時，原因是我剛剛在處理透視寶QA環境中的一個宕機故障。

這個故障的表現是：應用500錯誤，無法正常訪問，同時影響透視寶、監控寶和公共的CWOP平臺，造成近兩個小時的測試進度癱瘓。

處理過程：查看nginx日志，發現有upstream不能命中問題，health check模塊頻繁報錯，排查之后發現是一個后端接口從upstream中掉線，然而這個故障并不是導致宕機的根本原因。

從upstream中踢掉該服務后，繼續排查：查看apache日志，發現nginx將請求正常地轉發到了apache服務，apache服務返回500給nginx，nginx轉換500錯誤頁后拋出，正常的500錯誤已經不能正常地響應。

調整nginx拋出正常500后，繼續排查，雖然QA模擬生產環境，但并沒有應有的壓力規模，于是不應出現大流量洪峰，查看nginx和apache狀態頁后，確認，繼續排查；基本上問題定位在應用本身；查看應用本身的log，各種less more grep一通，沒有發現異常日志，這時一般人兒估計要抓狂了。

我用了透視寶的PHPAgent，進行故障排查，定位問題大約花了1分鐘,

故障的根源是QA的DB被打掛了，后來經確認，是監控寶的QA同事在跑一個用戶處理腳本。同時導致被打掛的還有Redis。

這和透視寶的PHPAgent沒有關系啊？

有關系！這是PHPAgent的trace_error和trace_exception選項，打出的日志。這項功能已經在測試中，即將正式發布上線。

最終解決問題方案非常簡單： 關閉nginx，關閉apache，重啟mysql, 重啟redis，重啟apache，重啟nginx。驗證監控寶、透視寶和CWOP平臺，恢復。

這個案例的應用場景是：

用戶在生產環境中會遇到各種因數據或流量、代碼等造成的錯誤和異常，而這些錯誤和異常之前并沒有遇到過，因此錯誤和異常并未被關注，此時解決問題需要使用APM產品透視的錯誤和異常發現功能。

該功能可以自動捕捉因資源、接口、數據或其他原因造成的未預知異常，并進行匯報和統計分析，做到精準提示和預警（預測未來）。

云智慧APM產品透視寶的設計初衷：

要達到以上目標，我們需要做到這樣幾個要點：

1. 要準確理解APM的真正含義。

APM絕不僅僅是簡單的速度監測和日志管理。不少APM廠商，看似酷炫的界面，其實只是做了一個非常簡單的日志統計管理。APM包含的內容非常深廣，廠商們喜歡把這張圖拋出來忽悠用戶，但是真正做到的APM的，其實并不多。

根據Gartner的定義，真正的APM要求做到5個范圍：終端用戶體驗，應用架構映射，應用事務分析，深度應用診斷，分析與報告。

去年國外一位分析師做過一次分析對比，可以反映去年的情況，今年需要再做一下對比。

2. 從終端用戶體驗出發，做到數據的“端”到“端”

多年前業內就在提End2End，現在業內幾個廠商在繼云智慧提出端到端概念之后，也在這么吆喝。端到端有很多種理解，我們的理解是，從終端用戶出發，將從request到response整個鏈路中涉及到的數據，有效地串接起來，這樣的數據才是真正的端到端。

實現方式也比較直接，從請求開始產生一致hash，該hash將伴隨整個請求過程，一步一步向后或旁進行傳遞，并從最末或最旁的響應開始，一步一步向前或旁進行回應。

3. 用戶行為數據與性能管理數據的有機結合

用戶行為數據是大數據中最難令人捉摸的一類數據。大多數情況下人的行為喜好是固定的，或有幾個偏好方向。如色彩喜好，第一視點喜好，甚至有的人會有特定的邊角點擊喜好。不同的位置或色彩的按鈕、鏈接，可能在不同的深度會對應用的性能造成皆然不同的影響。

同樣的一個功能項，由于不同的喜好設定，也可能會造成完全不同的價值體現。透視寶Mobile SDK和Web Rum，都非常友好地記錄用戶的行為喜好，行為鏈路。

4. 使用智能發現技術，完成應用代碼運行時的拓撲映射。

基于要點2所講的“端”到“端”實現原理，為某一個特定的請求進行“染色”加工，不難在數據的最未“端”準確得到一次請求中的請求鏈路。于是我們可以基于此對數以億萬計的用戶行為，戴上一個“應用”的帽子。

在這個帽子下面，數據不再是一個個的孤島，而是有生命的交替轉換。我們可以準確地分析出一個應用的架構拓撲，有哪些負載均衡，每次請求命中的是哪一個負載點；也可以準確地分析出一個服務集群中，有哪些組成節點，每一次請求，究竟命中的是哪一個或多個節點。如這張漂亮的蜘蛛網：

這在維護一個舊有系統或剛剛接手的新系統時，是非常有用的。曾經接觸過深圳的一家上市企業的CTO，他說他們有10余名架構師，需要用半年之久，才能準確地畫出他們的應用拓撲。

5．使用智能探針技術，取得深層次性能指標。

這里著重要說就是SmartAgent各個插件的實現原理。如PHPAgent剛剛的一次應用。在與龍珠的合作中，一個特別有意思的需求，即是：統計cache key的命中。不是從cache層面統覽的status，這樣的意義過于局限，而是從應用層面，進行準確分析。如：統計某一個具體key的命中率。從這個層面，性能指標的取得，已經被賦予了非常深的意義。

6．深度分析各項大數據指標，得出多維度請求應答的散點信息。

大數據指標不再多說，我們著重說“多維度”和“散點”，比如請求事務數據。一個應用中的事務基本是不可枚舉的，因為有各種參數的存在；那么在各種參數存在的前提上，怎么對響應時間進行統計？

各廠商的做法：這段時間內請求時間最慢的事務top10，這是相當不負責任的做法。為什么不負責任：我知道這就是我的top10，然后呢？天天說這個top10，周周說，月月說，這并不能反映我的應用健康狀態。我們需要關注的是，某段時間內，請求次數又多，響應時間又相對較慢的這些事務。

所以我們提出了三個維度的交叉：單位時間內，請求次數，響應時間。

于是我們可以畫出一幅矩陣圖，X軸是時間，左Y軸是請求次數，右Y軸是平均響應時間。這些事務以向量散落在這個象限內，那么我們可以得出，距離XY的左原點，距離最遠的，即是我們所關注的。

經過抽象和產品梳理，我們得出了這樣非常有意義的分析結果：

整個項目對于事務的健康分析狀況，一目了然，同時又可以快速找到關注目標。

透視寶在具體實現中，經過了多次實踐和演化 最終幫這些典型客戶解決了這樣非常實際的三個需求：

1. 幫助企業解決普遍存在的“投訴即反饋”的情況，非常有力的改善了研發、運維、管理人員被動接受反饋的現狀，避免了業務下降和直接的用戶丟失。

2. 幫助企業管理者避免了項目優化或重構過程中，盲目的性能、體驗優化，提供了有效的性能、體驗優化建議，和相對應的充分的數據佐證。

3. 幫助企業幾乎無成本地、零修改地進行性能、體驗監控。