gydtep

微服务技术让IT系统变得更敏捷、更健壮、更高性能的同时，也给带来了架构复杂度的提升，给应用监控带来了前所未有的挑战。

gydtep

1 . SDK方式: 通过引入链路追踪SDK自动生成链路数据，并自动上报。对于底层框架没有公开API的情况，监控逻辑的注入会比较复杂，有可能需要开发者针对具体的底层框架预先做好适配工作。

gydtep

2 . 下载探针（Agent）：在公网环境以及VPC内，都提供了探针的下载链接，可以直接参考ARMS台的提示进行操作。

gydtep

修改应用的启动命令：通过-javaagent挂载探针，并配置对应的license Key以及应用名。比如我们启动SpringBoot应用为例，启动命令为
java -javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar -Darms.licenseKey={LicenseKey} -Darms.appName={AppName} -jar demoApp.jar

gydtep

其中，-javaagent后面的路径是探针文件所在的路径，arms.licenseKey可以从ARMS的控制台获得，appName代表应用的名字。在微服务应用中，一个应用可以拥有多个对等的应用实例，这些对等的应用实例接入ARMS的时候，使用同样的应用名，这样ARMS可以把这个应用的多个实例放到一个分组中进行统一管理。

gydtep

比如在某一个时间点，一个应用对外服务接口的请求量突然变低，极有可能是其中的一个节点发生了故障，需要特别关注。对于在ARMS展示出来的任何一条以时间维度为横座标的指标曲线，都可以继续选择其中的时间段进行下钻分析，这也是一个非常便捷的功能。

gydtep

通过应用诊断报告，能很快的知道这个应用在哪一个时间点发生了故障。比如ARMS判断故障是由应用的某一个实例导致的情况下，会把可疑实例在报告中报出，让使用者点击实例链接就能进入单实例的详情页面，从错误率、硬件资源、JVM等维度对故障进行排查。

gydtep

回到应用列表视图，我们能查看到这些应用的整理健康状态，最先应该关注的是应用的状态列，如果亮红灯，说明系统已经诊断到某个应用存在明显的健康问题，这个时候我们可以点击红灯图标，让ARMS生成一份应用诊断报告。

gydtep

如果在应用列表视图，并没有发现亮红灯的应用，我们可以从健康度百分比、请求数、错误数、异常数、最近10分钟响应时间等数据中，快速判断一下有没有比较明显的与实际情况存在出入的应用。比如在最近10分钟内，有一个应用从某一个时间点开始，响应时间明显变长，我们就可以把这类应用列入需要进一步进行分析的名单。

gydtep

JVM监控可以直观展示指定时间段内的多项内存指标，虽然图表能体现出内存使用量过大的情况，但无法显示具体信息，因此如果需要进一步排查问题产生的原因，可以创建内存快照，通过详细的日志查看内存占用的详细信息，方便排查内存泄漏和内存浪费等内存问题。