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