應用系統在測試或生產運行過程當中，可能常常遇到這樣的場景：mysql
- 「某服務掛了，報錯信息看不出個因此然來，坐等大佬救場」
- 「某個請求響應速度很慢，要查到是哪裏卡殼了須要一層層往下查」
- 「只懂得監控服務器的資源指標，遇到問題時依舊啥也不是」
- 「系統老是時不時抽風下，還能再搶救一下嗎？。。。」
特別是在當下流行的分佈式服務系統中，若是出現性能問題，面對N臺的硬件服務器和10N級的服務（容器），從何處下手自己就已是個難題了。web
那麼，接下來給你們介紹分佈式服務的APM監控工具，Pinpoint。redis
【適合讀者】：開發、測試、運維等。sql
APM, 全稱Application Performance Management，劃重點，與性能有關！數據庫
已經有不少文章專門對比了各類APM工具之間的優劣，好比還有當下流行的skywalking、zipkin等，這裏我就再也不贅述，想了解更多的本身百度。安全
繼續咱們的主題，看看Pinpoint能給咱們帶來什麼？
首先上個整體圖：
服務器
從這個圖咱們能夠獲得這些信息：
1.系統的整體架構組成部分，好比圖中能夠看到應用服務與mysql、redis、第三方服務之間的請求狀況；
2.系統/節點的響應速度狀況，以及成功失敗的請求次數等；
架構
pinpoint的默認跟蹤粒度確實是比較詳細的，能夠看到單次請求在整個服務鏈路各節點上的詳細耗時狀況，好比在這裏，能夠很清楚地看到是哪一個節點哪一個方法消耗了最多的時間。
運維
再來個圖，你們從這個圖能夠看出這個系統當前的性能瓶頸在哪嗎？
分佈式
除了能夠跟蹤服務鏈路耗時狀況，pinpoint還能夠監控JVM、線程池、數據庫鏈接池、句柄等等的使用狀況，來幾個高能大圖。
這裏能看到數據庫鏈接池的最大鏈接數和當前鏈接數，對於判斷數據庫鏈接池數夠不夠用，能起到很好的參考做用，一目瞭然。
Pinpoint除了上述常規用法，還能夠用於跟蹤異常錯誤，好比上面第一張圖，在請求異常失敗的狀況下，pinpoint會以紅色標識，點開也就能夠看到出現異常失敗的節點和方法位置，以及具體的錯誤信息。
一樣地，由於Pinpoint詳細地記錄了請求的鏈路信息，把請求過程當中具體的SQL語句都展現出來了，這樣對於排查問題，甚至監控SQL語句的執行速度，均可以起到很好的幫助做用，很驚喜有沒有！
總結一下，pinpoint能夠給咱們帶來如下好處:
- 掌握系統的總體響應速度狀況，對系統運行狀況內心有底；
- 掌握各節點的響應速度狀況，好比第三方服務接口，redis，mysql等；
- 單次請求的具體服務鏈路耗時狀況，定位性能瓶頸；
- 單次請求的具體服務鏈路請求信息，對於排查問題能提供幫助；
- 監控各服務的JVM、線程池、數據庫鏈接池使用狀況，想象一下，若是分佈式服務系統中有幾十甚至幾百個服務節點，要如何來監控每一個節點的JVM呢？
整體來講，在pinpoint這類APM監控工具逐漸發展成熟的當下，引入這類工具，對咱們平常的開發測試運維工做，是能起到不錯的輔助做用的，尤爲是在分佈式服務系統中，若是沒有這類工具，遇到問題時不免慌手慌腳無從下手。
關因而否要在生產環境上部署這類APM監控工具，這裏說幾點供參考：
- APM監控必定不能夠影響業務系統的運行成敗，換句話說就是即便APM監控掛了，業務系統也應該可以照常運行着。不要由於引入APM監控，而給整套系統引入了一顆不定時炸彈，這樣就得不償失了。在一點上,pinpoint應該是OK的，我試過pinpoint服務端即便掛了，業務系統照樣能跑得好好的；
- APM監控是會消耗服務器的資源的，監控粒度越細，消耗越多。在其餘文章里人作了各類APM監控工具的性能損耗對比，pinpoint相對是損耗較多的，由於它的監控粒度算是比較細的。我也作過測試，開啓pinpoint監控後，性能確實會有8%左右的損耗。可是換個角度來講，目前各類系統的線上環境，CPU等各種資源，常常都是在30%使用率如下運行的，這種狀況下，即便再多個損耗10%也是在能接受範圍內的；
-
開源APM監控工具還要考慮安全問題，像pinpoint、skywalking這類工具目前好像尚未訪問權限之類的控制，要注意不要被亂灌數據，或者被有不良企圖的用戶訪問到各類請求鏈路詳細信息。固然，這類安全問題也是有解決方案的，好比能夠在路由防火牆上指定有權限的ip，或者經過web服務器加上權限驗證再進行轉發等；
若是你們有其餘不一樣意見或見解，歡迎留言討論。