別慌,這只是一張貼圖前端
除了404,最讓網友們心塞的可能就是這張圖了。java
據相關研究代表:當頁面加載時間從 1 秒到 3 秒,跳出的機會增長了30%左右。1s到5s的機會增長到90%,若是你的網站須要10s的加載,跳出的機會將會超過120%。(這裏的120%不是指來10我的,走12我的,是用戶流失增加率的意思)因此,在這個「用戶體驗爲王」的時代,應用性能監控已經成爲運維管理的重中之重。數據庫
網站卡頓、頁面加載慢是互聯網應用常見的問題之一,這類問題的排查和解決並不容易,會花費運維人員大量的時間和精力。一般緣由有如下三個:bootstrap
» 應用鏈路太長,無從下手。服務器
從前端頁面到後臺網關,從Web應用服務器到後臺數據庫,任何一個環節的問題都有可能致使請求總體卡頓,究竟是前端資源加載過慢?仍是數據庫出了問題?仍是新發布的服務端代碼有性能問題?出現問題的緣由五花八門。架構
採用「微服務」架構的應用,鏈路更加複雜。不一樣組件可能由不一樣的團隊、人員分別維護,加重了問題排查的難度。併發
» 日誌不全或質量欠佳,現場缺失。app
應用日誌無疑是排查線上問題的神器,但出現問題的位置每每沒法預期,發生了問題一般會發現日誌信息不全,由於咱們不可能在每個有可能出現問題的地方打印日誌。運維
「慢」的定義偏主觀,「慢」有時候每每也是偶發現象。真正要捕捉到「慢」的那一行代碼,咱們每每須要記錄每一次調用,不放過每一行代碼,但這樣的作法代價太大。微服務
» 監控不足,出現問題爲時已晚。
業務發展快、迭代速度更快,會致使業務系統頻繁修改接口、增長依賴、代碼質量惡化。若是沒有一個完善的監控體系,可以對應用的每個接口的性能進行全自動的監控,對出現問題的調用進行自動的記錄,等用戶反饋問題再來解決,自己就已經太遲了。
業務實時監控服務 ARMS(Application Real-Time MonitoringService)是一款阿里雲應用性能管理(APM)類的全鏈路監控產品。ARMS提供了針對Java 應用監控和診斷、車聯網實時監控、零售行業實時監控、用戶體驗監控等場景下全方位的監控功能,包括前端監控、應用監控和自定義監控等功能,快速構建實時的業務監控能力。
第一步:安裝Java探針(若是您的應用託管於EDAS,甚至能夠跳過這一步 )
第二步:在應用概覽中發現「慢」可疑線索
進入ARMS應用拓撲圖。在應用概覽中咱們可以明顯地看到今天系統中有「慢SQL」5次。
第三步:瀏覽並發現「慢接口」
點擊接口列表,咱們可以一眼看到這個應用提供的全部接口以及這個接口的調用次數和耗時,固然,這些接口都是ARMS的探針自動在程序中發現的,無需作任何配置。
在這些接口中,「慢」接口會被明顯標註出來。咱們很明顯地發現了可疑的慢接口。
選中左側的調用次數最多的」慢」接口,咱們能夠從右側看到此次調用明顯是「慢」在數據庫的調用上。
第四步:到底「慢在哪一行代碼」? 一鍵定位緣由!
第五步:防患於未然-- 設置告警
固然,您能夠在ARMS的告警設置中對某一個接口或所有接口設置告警,讓頁面接口出現卡頓時第一時刻通知到您的運維團隊。
固然除了網站卡頓、頁面加載慢之外,網站還會出現後臺報錯、頁面加載失敗、內存泄漏等一系列問題。如何利用ARMS快速解決更多網站疑難雜症,請關注咱們的 ARMS 系列文章 - 「網站常見問題1分鐘定位」。