隨着微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。互聯網應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台服務器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行為、用於分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。
Skywalking是一個可觀測性分析平台和應用性能管理系統。
提供分布式跟蹤、服務網格遙測分析、度量聚合和可視化一體化解決方案。
原理圖
說幾個碰到的坑:
- mysql 支持,github下載下來的包默認沒有驅動,如果你要用mysql來存儲數據,需要把mysql-connector-java-5.1.46.jar 放到oap-libs目錄下
- 數據自動清除,默認刪除90分鍾前的數據
- 使用 端點面板 中 全局最慢端點追蹤 中復制的id 去搜索是搜不到的,必須要加1
- 時區必須保持一致:Ubuntu18.04 設置時區.必須要用
不能使用域名,只能使用IP(碰到連接異常或者agent注冊不上可以試試)
timedatectl set-timezone "Asia/Shanghai"
docker 中設置時區可以用
environment:
- TZ=Asia/Shanghai
主界面
提供全局視圖,主要展示了所有被監控服務的總體信息
具體有:
全局熱圖
提供每分鍾響應時間的統計數據
全局響應百分比
(大於) 過去 10 秒內最慢的 x% 的請求的平均延遲，其中 x 是數字與 100 之差。例如，p99 1.403 表示過去 10 秒內最慢的 1% 請求的平均延遲為 1.403 秒。
(ps:這句話很拗口)
全局概況
全局最大吞吐量
每個服務每分鍾調用次數
全局最慢端點
服務面板
主要提供當前選中服務的基礎信息
全局概況
服務平均響應時間
服務平均吞吐量
該服務每分鍾調用次數
服務平均可用性
通過請求成功與失敗次數來計算(來源:http://blog.itpub.net/31562043/viewspace-2305574/)
全局響應百分比
過去 10 秒內最慢的 x% 的請求的平均延遲，其中 x 是數字與 100 之差。例如，p99 1.403 表示過去 10 秒內最慢的 1% 請求的平均延遲為 1.403 秒。
服務響應百分比
過去 10 秒內最慢的 x% 的請求的平均延遲，其中 x 是數字與 100 之差。例如，p99 1.403 表示過去 10 秒內最慢的 1% 請求的平均延遲為 1.403 秒。
服務最慢端點
該服務下響應最慢的端點
運行中的實例
端點面板
主要提供當前選中端點的基礎信息
全局概況
端點平均響應時間
端點平均吞吐量
該端點每分鍾調用次數
端點平均可用性
通過請求成功與失敗次數來計算(來源:http://blog.itpub.net/31562043/viewspace-2305574/)
全局響應百分比
過去 10 秒內最慢的 x% 的請求的平均延遲，其中 x 是數字與 100 之差。例如，p99 1.403 表示過去 10 秒內最慢的 1% 請求的平均延遲為 1.403 秒。
端點響應百分比
過去 10 秒內最慢的 x% 的請求的平均延遲，其中 x 是數字與 100 之差。例如，p99 1.403 表示過去 10 秒內最慢的 1% 請求的平均延遲為 1.403 秒。
依賴關系圖
最慢端點追蹤
默認顯示該服務下的最慢的十條記錄,可以點擊右側的圖標復制追蹤ID進行查詢詳細信息
全局最慢端點
默認顯示全局的最慢的十條記錄,可以點擊右側的圖標復制追蹤ID進行查詢詳細信息
實例面板
實例信息
該選中實例基礎信息(語言,系統,主機名,流程號,ip)
實例平均吞吐量
該實例每分鍾調用次數
實例平均響應時間
該實例平均響應時間
實例平均可用性
通過請求成功與失敗次數來計算(來源:http://blog.itpub.net/31562043/viewspace-2305574/)
jvm 垃圾回收耗時
新生代,老年代
jvm 堆內存
jvm 非堆內存
jvm cpu
clr cpu
clr 堆內存
clr gc
拓撲圖面板
接口請求的拓撲圖
追蹤面板
左上角可以輸入追蹤ID進行搜索
點擊任意節點進行查詢詳情
