一、當系統某一模塊的部分功能訪問很慢，怎樣檢測？
1.檢查線上10臺機器各硬件負載指標均正常（硬件）
2.查詢線上10臺會員系統日誌，出現大量請求Timeout（網絡）
3.檢查3臺MySQL數據庫，訪問非常慢，並且連接已佔滿（應用內部）
4.進一步查明，大量連接都在執行一個會員註冊的SQL語句，找到問題（應用外圍的節點組件）
二、若以上步驟都用人工去完成，需要消耗多長時間？
優化：
1.採用Zabbix對線上機器各性能指標進行集中監控
2.使用ELK對線上日誌集中存儲查詢
3.使用Anemometer集中監控SQL語句
以上三個功能合起來就是我們的APM系統
三、若這個SQL並不是慢查詢，且這時的流量並不大
那麼只能查看代碼，這個時間可能比前面四個步驟花的時間還要長，一般是耗時較長的代碼段
四、APM簡介
APM全稱是APPlocation Performance Management（應用性能管理），APM致力於監控和管理應用軟件的性能和可用性。通過檢測和診斷複雜應用程序的性能問題，來保證軟件應用程序的良好運行
五、APM發展的三個階段
1.以網絡爲中心，網速即運行速度，APM主要指基礎組件的性能監控
2.以IT不見、組件爲中心，監控圍繞着部件、組件健康狀態，基礎設施可用性，伴隨IT基礎建構組件發佈
3.以IT應用核心和業務交易爲中心，IT架構高度複雜性，專注IT應用，面向用戶，提供應用生命週期管理
六、各互聯網公司APM解決方案
1.google：dapper
2.京東：hydra(開源)
3.小米：open-falcon(開源) 等
七、現有監控系統解決方案對比（Zabbix和open-falcon）
主要功能：CUP負荷、內存使用、磁盤使用、網絡狀況、端口監視、日誌監視
不同點：
1.
| Zabbix | open-falcon | |
| 用戶羣 | 85%互聯網企業 | 美團、滴滴、愛奇藝等 |
| 優點 |
1.安裝部署簡單 2.多數據集採集靈活集成 3.用戶羣體大，使用時間長 |
1.數據採集免配置 2.吞吐量高，支持單週期億次數據採集，告警判斷 3.中文文檔齊全 4.水平擴容多IDC支持 5.支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調用 |
| 缺點 |
1.易用性不高、而且很多定製化監控實現起來很麻煩 2.應對超大流量有點力不從心 |
1.部署複雜，單個組件太零散 |