随着业务规模的增长，不但来自于前端用户的请求频度会增加，链路也变得更长，这也代表着应用之间的调用关系变得越来越复杂。为了提升微服务系统在复杂链路下的健壮性和稳定性，有3个关键诉求需要我们去解决：
1 . 如何梳理整套系统的调用关系，并评判应用上下游依赖的合理性？
2 . 如何了解每一个应用的性能指标，并对系统容量进行合理的规划？
比如在Java体系中，用于提供HTTP服务的Tomcat、Jetty，用于进程内部通讯的RxJava，用于微服务应用之间相互调用的Feign，用于访问外部系统的MyBatis、MySQL JDBC、HTTPClient，都属于这个范畴。对于多种编程语言以及种类繁多的底层框架的适配，是一项浩大的工程，一个全链路监控方案能够适配的底层框架越多，它的能力就越强大。
JAVA_OPTS="$JAVA_OPTS -javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar -Darms.licenseKey={LicenseKey} -Darms.appName={AppName}"
主机监控功能用于监控CPU、内存、Disk（磁盘）、Load（负载）、网络流量和网络数据包的各项指标。当我们遇到硬件或网络故障的时候，这些基础资源的指标数据将非常有价值。当应用部署在Kubernetes的时候，Pod监控和主机监控能够分别从pod和宿主机维度分别对指标数据进行展示。
这些展示的数据中，如果我们发现有明显的可疑现象，可以点击数字上的链接，进入更详细的分析视图。例如：我们发现某个应用今天的错误数相比昨天存在400%的涨幅，但总请求量变化不大，就可以判断出这个应用非常值得怀疑。接下来，我们可以直接进入错误分析视图，来观察具体哪一个时间段的哪一些接口存在问题。
在应用总览展示的数据中，最应该值得关注的是慢SQL数据。ARMS会记录应用访问数据库的情况，当发现应用存在大量慢SQL的时候，就可以直接给出判断：该应用在访问数据库的环节存在问题。我们可以从慢SQL分析视图找到到底是哪一条SQL存在问题，从而针对性的进行优化。对于慢SQL的定义，可以通过应用的自定义配置进行修改（默认执行时间超过500ms会标记为慢SQL）
通过调用链锁定问题应用
如果通过前两个步骤还没有找到问题的根源，就需要借助ARMS的核心能力—全链路排查了。
在应用总览展示的数据中，最应该值得关注的是慢SQL数据。ARMS会记录应用访问数据库的情况，当发现应用存在大量慢SQL的时候，就可以直接给出判断：该应用在访问数据库的环节存在问题。我们可以从慢SQL分析视图找到到底是哪一条SQL存在问题，从而针对性的进行优化。对于慢SQL的定义，可以通过应用的自定义配置进行修改（默认执行时间超过500ms会标记为慢SQL）
早些时候，大家对“数据驱动”的理解是“报表驱动”。2016年、2017年的时候，一家处于C轮、D轮的深圳公司，该公司有1000多份报表，每张有10个Sheet，每个表格有20多个指标，大家可以算下一共有多少个指标，他们内部的数据团队都不知道哪些指标有用、哪些没有用。为了督促大家去看这些报表，公司还监控了邮箱。
