目标：在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频繁问题