目標：在ecs中啟動一個java應用，且攜帶arms監控

原理：在java應用啟動時，同時啟動一個agent探針，時刻監控java應用變化（如：接口調用、CPU、線程池狀態等）

1.arms接入中心添加java應用

若是容器集群環境，則選擇容器服務環境

手動安裝方式，是手動把 agent的jar包放到 ecs服務器，然后運行個人的spring boot服務時，加上一些參數，將agent也啟動運行

會一直等待2步驟的java應用集成agent成功

2.linux的java應用集成agent

2.1?linux下載添加agent

監控的是ecs中的java應用，因此要將agent下載到ecs中

添加unzip指令集，并解壓縮

2.2 啟動java應用、agent探針

java -javaagent:/home/admin/AliyunJavaAgent/aliyun-java-agent.jar -Darms.licenseKey=dnnlqal****** -Darms.appName=my-service -jar arms-0.0.1-SNAPSHOT.jar

?/home/admin? 是agent在ecs中的實際路徑

最后的? -jar *.jar & 是啟動的自己的java服務jar包

啟動

3.集成的效果

3.1 接口調用

3.2 JVM監控

3.3 線程池監控

限制：僅支持部分框架

3.4 持續性能刨析

作用：分析內存占用、接口cpu耗時函數

4. 利用arms解決線上問題

分析“性能剖析”的火焰圖

4.1 解決內存占用異常問題

線程池組：先看下各個線程池組的內存占比，找到業務中的線程池（本圖的內存占用 arms的agent占用最多，但是我們不用分析，因此不選。。現實場景，自己的業務占用的內存占絕大多數）

可以一個個的線程池組分析、也可以先多選幾個一塊分析

現實模式：使用表格+火焰的形式。

從下往上找，自己業務的最寬的方法，就是導致占用內存較多的原因。

org.draymond.arms.ArmsThreadTest.extracted(String)

?在代碼中找到對應的位置，然后分析原因

4.2 解決接口慢問題

trace?+ 火焰圖

1.通過trace先定位哪個接口慢

找到一個慢的traceId

詳情里面有各個span的耗時（因為我只開了一個服務，也沒有手動添加span，所以沒有其他span了）

不足：該接口內部的邏輯，不確定哪個地方是卡點

但是使用 “代碼整體執行時間火焰圖” 輔助分析

從trace中找到慢的 服務 與 慢方法

搜索自己業務的路徑

arms/byte/id

調用關系：

org.draymond.arms.ArmsController.bytesTest(Integer)

org.draymond.arms.ArmsService.bytesTest(Integer)

org.draymond.arms.ArmsService.sleepNumberTime(Integer)

入口：.ArmsController.bytesTest 花費??7.15 m， 占比49%

最耗時方法：ArmsService.sleepNumberTime

定位：最根本的是?sleepNumberTime 的sleep占用了大量時間。

4.3 解決CPU不穩定問題

方式：利用CPU火焰圖，對比CPU穩定、不穩定 時的CPU占用情況，找到引起CPU飆升的業務，分析，解決

4.4 解決GC頻繁問題