故障的根源是QA的DB被打掛了，后來經(jīng)確認，是監(jiān)控寶的QA同事在跑一個用戶處理腳本。同時導致被打掛的還有Redis。
這和透視寶的PHPAgent沒有關系啊?
有關系!這是PHPAgent的trace_error和trace_exception選項，打出的日志。這項功能已經(jīng)在測試中，即將正式發(fā)布上線。
最終解決問題方案非常簡單： 關閉nginx，關閉apache，重啟mysql, 重啟redis，重啟apache，重啟nginx。驗證監(jiān)控寶、透視寶和CWOP平臺，恢復。
這個案例的應用場景是：
用戶在生產(chǎn)環(huán)境中會遇到各種因數(shù)據(jù)或流量、代碼等造成的錯誤和異常，而這些錯誤和異常之前并沒有遇到過，因此錯誤和異常并未被關注，此時解決問題需要使用APM產(chǎn)品透視的錯誤和異常發(fā)現(xiàn)功能。
該功能可以自動捕捉因資源、接口、數(shù)據(jù)或其他原因造成的未預知異常，并進行匯報和統(tǒng)計分析，做到精準提示和預警(預測未來)。
云智慧APM產(chǎn)品透視寶的設計初衷：
1. 有效管理企業(yè)應用服務器軟硬件和應用本身的性能問題;
2. 從性能管理的角度補充并充分地了解企業(yè)應用架構(gòu)拓撲;
3. 準確找到并幫助解決企業(yè)應用的性能瓶頸點;
4. 使用性能管理快速解決問題，規(guī)避潛在的應用風險，從而提升應用價值;
要達到以上目標，我們需要做到這樣幾個要點：
1. 要準確理解APM的真正含義。
APM絕不僅僅是簡單的速度監(jiān)測和日志管理。不少APM廠商，看似酷炫的界面，其實只是做了一個非常簡單的日志統(tǒng)計管理。APM包含的內(nèi)容非常深廣，廠商們喜歡把這張圖拋出來忽悠用戶，但是真正做到的APM的，其實并不多。
根據(jù)Gartner的定義，真正的APM要求做到5個范圍：終端用戶體驗，應用架構(gòu)映射，應用事務分析，深度應用診斷，分析與報告。
去年國外一位分析師做過一次分析對比，可以反映去年的情況，今年需要再做一下對比。
2. 從終端用戶體驗出發(fā)，做到數(shù)據(jù)的“端”到“端”
多年前業(yè)內(nèi)就在提End2End，現(xiàn)在業(yè)內(nèi)幾個廠商在繼云智慧提出端到端概念之后，也在這么吆喝。端到端有很多種理解，我們的理解是，從終端用戶出發(fā)，將從request到response整個鏈路中涉及到的數(shù)據(jù)，有效地串接起來，這樣的數(shù)據(jù)才是真正的端到端。
實現(xiàn)方式也比較直接，從請求開始產(chǎn)生一致hash，該hash將伴隨整個請求過程，一步一步向后或旁進行傳遞，并從最末或最旁的響應開始，一步一步向前或旁進行回應。
3. 用戶行為數(shù)據(jù)與性能管理數(shù)據(jù)的有機結(jié)合
用戶行為數(shù)據(jù)是大數(shù)據(jù)中最難令人捉摸的一類數(shù)據(jù)。大多數(shù)情況下人的行為喜好是固定的，或有幾個偏好方向。如色彩喜好，第一視點喜好，甚至有的人會有特定的邊角點擊喜好。不同的位置或色彩的按鈕、鏈接，可能在不同的深度會對應用的性能造成皆然不同的影響。
同樣的一個功能項，由于不同的喜好設定，也可能會造成完全不同的價值體現(xiàn)。透視寶Mobile SDK和Web Rum，都非常友好地記錄用戶的行為喜好，行為鏈路。
4. 使用智能發(fā)現(xiàn)技術，完成應用代碼運行時的拓撲映射。
基于要點2所講的“端”到“端”實現(xiàn)原理，為某一個特定的請求進行“染色”加工，不難在數(shù)據(jù)的最未“端”準確得到一次請求中的請求鏈路。于是我們可以基于此對數(shù)以億萬計的用戶行為，戴上一個“應用”的帽子。
在這個帽子下面，數(shù)據(jù)不再是一個個的孤島，而是有生命的交替轉(zhuǎn)換。我們可以準確地分析出一個應用的架構(gòu)拓撲，有哪些負載均衡，每次請求命中的是哪一個負載點;也可以準確地分析出一個服務集群中，有哪些組成節(jié)點，每一次請求，究竟命中的是哪一個或多個節(jié)點。如這張漂亮的蜘蛛網(wǎng)：
這在維護一個舊有系統(tǒng)或剛剛接手的新系統(tǒng)時，是非常有用的。曾經(jīng)接觸過深圳的一家上市企業(yè)的CTO，他說他們有10余名架構(gòu)師，需要用半年之久，才能準確地畫出他們的應用拓撲。
5.使用智能探針技術，取得深層次性能指標。
這里著重要說就是SmartAgent各個插件的實現(xiàn)原理。如PHPAgent剛剛的一次應用。在與龍珠的合作中，一個特別有意思的需求，即是：統(tǒng)計cache key的命中。不是從cache層面統(tǒng)覽的status，這樣的意義過于局限，而是從應用層面，進行準確分析。如：統(tǒng)計某一個具體key的命中率。從這個層面，性能指標的取得，已經(jīng)被賦予了非常深的意義。
6.深度分析各項大數(shù)據(jù)指標，得出多維度請求應答的散點信息。
大數(shù)據(jù)指標不再多說，我們著重說“多維度”和“散點”，比如請求事務數(shù)據(jù)。一個應用中的事務基本是不可枚舉的，因為有各種參數(shù)的存在;那么在各種參數(shù)存在的前提上，怎么對響應時間進行統(tǒng)計?
各廠商的做法：這段時間內(nèi)請求時間最慢的事務top10，這是相當不負責任的做法。為什么不負責任：我知道這就是我的top10，然后呢?天天說這個top10，周周說，月月說，這并不能反映我的應用健康狀態(tài)。我們需要關注的是，某段時間內(nèi)，請求次數(shù)又多，響應時間又相對較慢的這些事務。
所以我們提出了三個維度的交叉：單位時間內(nèi)，請求次數(shù)，響應時間。
于是我們可以畫出一幅矩陣圖，X軸是時間，左Y軸是請求次數(shù)，右Y軸是平均響應時間。這些事務以向量散落在這個象限內(nèi)，那么我們可以得出，距離XY的左原點，距離最遠的，即是我們所關注的。
經(jīng)過抽象和產(chǎn)品梳理，我們得出了這樣非常有意義的分析結(jié)果：
整個項目對于事務的健康分析狀況，一目了然，同時又可以快速找到關注目標。
透視寶在具體實現(xiàn)中，經(jīng)過了多次實踐和演化 最終幫這些典型客戶解決了這樣非常實際的三個需求：
1. 幫助企業(yè)解決普遍存在的“投訴即反饋”的情況，非常有力的改善了研發(fā)、運維、管理人員被動接受反饋的現(xiàn)狀，避免了業(yè)務下降和直接的用戶丟失。
2. 幫助企業(yè)管理者避免了項目優(yōu)化或重構(gòu)過程中，盲目的性能、體驗優(yōu)化，提供了有效的性能、體驗優(yōu)化建議，和相對應的充分的數(shù)據(jù)佐證。
3. 幫助企業(yè)幾乎無成本地、零修改地進行性能、體驗監(jiān)控。
