轻松玩转全链路监控

前言

随着分布式技术的发展与演进，微服务技术成为了大型分布式IT架构的必然选择。从本质上来讲，微服务是一种架构风格，将一个大型的系统拆分为多个拥有独立生命周期的应用，应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建，可以独立部署、独立迭代，也可能根据业务负载独立的水平扩展。微服务思想以及相关的技术为IT架构的发展带来了一系列深刻的变革。

微服务技术让IT系统变得更敏捷、更健壮、更高性能的同时，也给带来了架构复杂度的提升，给应用监控带来了前所未有的挑战。在微服务时代，由于服务的拆分，单个用户请求会经过多个微服务应用，形成复杂的调用链路，使传统的依赖于单机业务日志的监控手段无从下手，这就需要建立全新的监控机制，帮助开发者全面洞察系统运行状态，并在系统遇到异常的时候快速的定位和解决问题。

什么是全链路监控？

在分布式微服务架构中，系统为了接收并处理一个前端用户请求，需要让多个微服务应用协同工作，其中的每一个微服务应用都可以用不同的编程语言构建，由不同的团队开发，并可以通过多个对等的应用实例实现水平扩展，甚至分布在横跨多个数据中心的数千台服务器上。单个用户请求会引发不同应用之间产生一串顺序性的调用关系，链路的概念就此诞生。

图：微服务链路

随着业务规模的增长，不但来自于前端用户的请求频度会增加，链路也变得更长，这也代表着应用之间的调用关系变得越来越复杂。为了提升微服务系统在复杂链路下的健壮性和稳定性，有 3 个关键诉求需要我们去解决：

1、如何梳理整套系统的调用关系，并评判应用上下游依赖的合理性？

2、如何了解每一个应用的性能指标，并对系统容量进行合理的规划？

3、当系统出现故障或异常的时候，如何第一时间发现问题、定位问题、解决问题？

这3个关键诉求的核心挑战，都来源于应用之间复杂的链路。如果有一套成熟易用的机制，对每一条链路的行为进行记录，并进行深入的分析，提取出有价值的参考数据，就能让这些难题迎刃而解，这个重要的机制就是全链路监控。

标准与规范

十年前，Google 成为了分布式系统链路追踪服务的先行者，并通过《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》这篇著名论文阐述了如何在超大规模系统上建设低损耗（low overhead）、应用级透明（application-leveltransparency）、大范围部署（ubiquitous deployment）的链路追踪服务。

图：一个链路完整的数据流转

Dapper 阐述了对分布式系统进行链路追踪的技术细节，包括数据表示、埋点、传递、收集、存储与展示等方面，并提出了跟踪树、Span、Trace、Annotation 等重要概念，为全链路监控提供了理论指导。

图：一个跟踪树里面5个Span的实时关系

在 Dapper 的启发下，业界诞生了很多用于分布式链路追踪的开源组件，为了保持对链路中每一个环节的记录与匹配，不仅需要在应用内部对跟踪信息进行传递，还需要让跟踪信息跨越不同的应用以及不同的分布式组件。这需要制定一套统一的标准，让微服务体系中的所有应用遵循这套标准来实现跟踪信息的描述和传递，这套标准就是 OpenTracing。OpenTracing 抽象出一套与编程语言以及业务逻辑无关的接口，对链路追踪领域各类元素的统一管理，从而实现完整的全链路监控。

本文不会深入介绍 Dapper 和 OpenTracing 的原理以及技术细节。我们只需要知道，优秀的全链路监控组件会尽可能的遵循 OpenTracing 标准，以获得更好的通用性以及扩展性。

可选方案

全链路监控组件如何获得链路相关的信息呢？最简单的方式是让开发者在业务代码中手工埋点，生成符合 OpenTracing 标准的链路信息，并汇入全链路监控组件。但手工埋点的方式要求开发者主动配合，并在业务代码中嵌入大量非业务逻辑。这样的方式是极为脆弱的，开发者稍有疏忽就会导致链路信息丢失，甚至影响到正常的业务逻辑。所以非手工埋点的自动链路信息采集，成为了业界的主流，其中包括两种实现方式：

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

探针方式：探针方式不需要在代码编译前引入 SDK ，而是在应用运行的过程中，通过一个 Agent 动态的拦截底层框架的行为，从而自动注入监控逻辑。像 Java 这样的编程语言可以通过字节码增强技术实现探针方式的链路信息采集。这是一种最开发者最友好的方式，不需要任何代码层面的改动，但并不是每一种编程语言都能提供探针机制，因此 SDK 方式也被很多全链路监控组件采用。

不管是 SDK 方式还是探针方式，非手工埋点形式的链路信息采集都依赖于链路追踪组件对于底层框架的识别。这些底层框架包含的领域非常广，其中包含应用对外提供服务所需要的框架，应用进程内部的通讯框架，应用之间相互访问所需要的框架，应用访问外部系统所需要的框架等等。比如在 Java 体系中，用于提供 HTTP 服务的Tomcat、Jetty，用于进程内部通讯的RxJava，用于微服务应用之间相互调用的Feign，用于访问外部系统的 MyBatis、MySQL JDBC、HTTPClient，都属于这个范畴。对于多种编程语言以及种类繁多的底层框架的适配，是一项浩大的工程，一个全链路监控方案能够适配的底层框架越多，它的能力就越强大。

表格：Java应用需要支持的基本组件和框架

基础链路信息收集上来之后，需要进行统一存储，并对数据进行清洗与聚合，根据应用响应时间、请求数、错误率等指标进行下钻分析，并按应用、接口、链路、事务等多个维度进行展示，这也是一项非常复杂的工作。

因此，全链路监控方案的技术门槛是非常高的，在开源的全链路监控产品中，真正遵循 OpenTracing 标准，又够被广泛认可和使用的产品非常少，其中通过 SDK 方式接入的产品以 Jaeger 为代表，通过探针方式接入的产品以 Skywalking 为代表。

图：Jaeger技术架构

最轻松的方案

开源的全链路监控方案能帮助开发者更深入的理解全链路监控的思想、原理以技术细节，但在在生产环境大规模使用开源方案，还是会给开发者带来很大的挑战：

维护工作复杂：除了客户端的SDK和探针外，一套全链路监控方案在服务端有计算组件、存储组件、展示组件，都需要单独进行维护。以Jaeger为例，仅在数据存储方面需要维护一套独立的Elasticsearch集群，需要投入很大的工作量。

功能简单：对主流底层框架的全面支持，丰富的UI界面，完善的诊断机制和报警机制，这些都是一套优秀的全链路监控方案所必备的特质。开源方案在这些方面很难做到尽善尽美。

缺少高可用保障：开源全链路监控方案并没有完整的高可用机制，当某个组件出现故障，比如服务器宕机的时候，无法自动恢复，需要人工介入进行解决，在这个过程中正常的监控会受到影响。

无法支撑大规模场景：当接入的应用数量达到上千个之后，开源全链路监控方案会暴露出各种性能问题，需要开发者修改源代码进行针对性的优化。

影响正常业务：如果 SDK/探针存在设计上的缺陷，有可能导致应用出现不可预知的故障。这种情况极为罕见，但一旦发生，后果会非常严重，这种情况下一般也只能等待开源社区将问题修复后才能恢复使用。

之所以在生产环境使用开源全链路监控方案存在这么大挑战，是因为这些方案本身缺乏大规模实际业务场景的验证。对于技术实力非常强的互联网企业，会有专门的技术团队负责全链路监控项目，在使用开源产品的过程中如果遇到任何问题，都可以通过自身的技术实力进行修复和弥补。但对于绝大多数使用者而言，这些挑战所带来的都是漫长而痛苦的体验。

有没有一套经历过大规模实际业务场景验证，又简单易用的全链路监控产品呢？在云计算时代这个问题的答案是肯定的，阿里云ARMS就能满足这个要求，代表着业界在全链路监控以及应用性能管理领域的最高水平。

图：ARMS定位问题

应用实时监控服务ARMS（Application Real-Time Monitoring Service）起源于阿里巴巴内部的EagleEye（鹰眼）系统，已经经历了近10年的沉淀和演进。鹰眼系统同时将基础设施层、分布式应用层、业务逻辑层与客户端层进行了全链路跟踪，每天对万亿级别的分布式调用进行分析，对底层的流计算、多维时序指标与事件存储体系等进行了大量优化，同时引入了时序检测、根因分析、业务链路特征等技术，将问题发现与定位由被动转为主动。

在ARMS的理念中，对全链路监控的理解已经超出了一般意义上APM（应用性能管理的范畴），而是把“可观测性”作为产品的最重要使命。可观测性是一切自动化决策的基础，求最终目的是为一个复杂分布式系统所发生的一切给出合理解释。

正是因为经历了大规模生产环境的长期验证，才使 ARMS 能够在易用性、功能性、稳定性方面做到极致，以开源领域最活跃的全链路监控项目 Skywalking 为例，我们可以从多个维度对两个产品进行对比：

接入来，我们就通过阿里云ARMS，开启轻松玩转全链路监控之旅。

应用接入

ARMS采用无代码侵入探针接入方式，对于应用接入只需要非常简单的几个步骤，以Java应用为例：

1、开通ARMS服务：登录阿里云控制台后，打开ARMS产品主页，按照提示开通“应用实时监控服务试用版”，开通服务后会获得15天的免费产品试用。

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

3、修改应用的启动命令：通过-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

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

修改完应用启动命令后，对应用进行重启，就能够成功接入ARMS。如果在1分钟后，ARMS控制台的应用列表能够看到新的应用，就代表接入成功。

当然，对于Tomcat等通过操作系统脚本启动的应用，不能直接修改应用启动命令来挂载ARMS探针，这个时候只要对启动脚本进行修改即可，以Tomcat为例，我们在setenv.sh中加入如下配置：

JAVA_OPTS="$JAVA_OPTS-javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar-Darms.licenseKey={LicenseKey} -Darms.appName={AppName}"

更多的 Jetty 等更多通过 Web 容器启动的应用可以参考ARMS的帮助文档。

对于部署在阿里云EDAS或者容器服务Kubernetes的应用，接入工作会更加的简单，ARMS已经和这些产品进行了集成，使用者都不需要下载ARMS的探针到应用所在的节点，可以直接在控制台进行一键式的批量操作。

特别重要的一点是，ARMS支持混合云模式，所以并不要求接入的应用一定要部署在阿里云，不管应用部署在线下IDC还是其他的云，都可以统一接入ARMS。当然，需要确保在混合云模式下，应用与ARMS服务端之间的网络是畅通的。

核心实践一：了解你的系统

应用接入后，可以通过ARMS获得哪些重要的信息，从而帮助使用者更好的了解整个系统呢？我们可以从这几个方面入手：

应用列表和全局拓扑

在应用列表视图，我们能看到每一个应用的健康度以及最近10分钟对外服务的响应情况。如果应用的状态列亮红灯，代表此应用运行不健康，我们可以继续点击红灯查看ARMS此应用生成的诊断报告，以进一步分析应用不健康的原因。

图：应用列表视图

点击应用列表右上角的全局拓扑按钮，能够通过可视化界面观察所有接入ARMS应用的拓扑结构，这个界面清晰的展示了所有应用的上下游组件以及相应的调用关系，能够帮助使用者从全局角度深入理解整个微服务系统。

图：全局拓扑结构

理想的微服务应用只有不同层级之间的单向依赖，这种依赖的原则是高层应用依赖于低层应用。同层应用之间的相互依赖，或者低层应用依赖于高层应用都是违背这个原则的。假设我们在全局拓扑视图里面，找到了环状依赖关系，说明微服务应用之间的依赖关系不清晰，可以考虑对应用的层次结构进行重构。

应用总览

从应用列表进入应用总览页，首先呈现给使用者的是概览分析视图，在这个视图中，我们能够查询应用在指定时间的关键指标。右上角的时间段是一个非常重要的选项，使用者可以根据需要来修改此应用关键指标的采集时间范围（默认15分钟）。在ARMS的很多视图里面，都提供了这个选项，来帮助使用者查看指定时间范围的监控信息。

图：应用关键指标

应用在选定时间内的总请求量、平均响应时间、错误数、实时实例数、FullGC 次数、慢 SQL 次数、异常次数和慢调用次数，以及这些指标和上一天的环比、上周的同比升降幅度等信息，都能够在这个视图体现。我们可以重点关注应用应用提供服务和应用依赖服务栏展示的指标曲线，如果在某个时间点发生了突变，可以进行针对性的排查。比如在某一个时间点，一个应用对外服务接口的请求量突然变低，极有可能是其中的一个节点发生了故障，需要特别关注。对于在ARMS展示出来的任何一条以时间维度为横座标的指标曲线，都可以继续选择其中的时间段进行下钻分析，这也是一个非常便捷的功能。

图：在指标曲线上选择时间段进行下钻分析

在拓扑图页签上，可以通过拓扑图更加直观地看到应用的上下游组件以及与它们的调用关系。相比全局拓扑图，单应用拓扑图能够展示更多细节信息，帮助使用者分析应用的上下游调用情况，从而更快速地找出性能瓶颈。

图：应用拓扑

应用详情

在应用详情视图中，能够基于应用整体的维度以及应用内单实例的维度查看更多详细的信息，包括JVM信息、主机信息、SQL调用分析、异常和错误分析等等。

主机监控功能用于监控CPU、内存、Disk（磁盘）、Load（负载）、网络流量和网络数据包的各项指标。当我们遇到硬件或网络故障的时候，这些基础资源的指标数据将非常有价值。当应用部署在 Kubernetes 的时候，Pod 监控和主机监控能够分别从pod和宿主机维度分别对指标数据进行展示。

JVM监控功能通过可视化页面展示应用的GC情况、内存详情、线程详情，完全可以代替JStat、JStack 等 JDK 自带的 JVM 分析工具。同样，在以时间为横坐的曲线图处，可以继续选中一个时间段进行下钻分析。

图：应用情况 – JVM监控

如果一个应用的多个对等实例中，某一个出现了故障，我们就能够非常迅速的发现这个实例在应用情况视图中呈现出来的状态信息和其他实例存在非常大的区别，这样有助于我们迅速找到故障实例，并进行相应的处理。

接口调用 & 外部调用

当一个应用对外提供多个服务接口的时候，如何从分析每一个接口的服务质量，以及每一个接口对应的链路详细情况呢？这个时候接口调用视图就能发挥重要的作用。从这个应用所有提供的接口中，我们可以选中需要分析的单个接口，与这个接口相关的链路信息就能够从多个维度展示出来，其中包括接口的请求数、响应时间、错误数、返回状态码，以及在接口所对应的链路中，应用访问外部数据库（包括关系型数据库，以及Redis等非关系型数据库）的情况。如果访问这个接口的上游应用也接入了ARMS，还能从链路上游页签查看每一个上游应用访问这个接口的请求数、响应时间和错误数。同样，如果这个接口对应的链路在离开这个应用后，还会继续访问接入了ARMS的下游应用，我们也能从链路下游页签查看到针对每一个下游应用的请求情况。

图：接口调用

我们需要记住，接口调用基于单个应用接口的维度，对链路信息进行提取并展示。当一个应用的某个接口存在问题的时候，我们能迅速通过这个功能定位这个有问题的接口。

在外部调用视图中，会把下游应用每一个实例以IP 端口的形式进行呈现，我们可以通过这个视图快速定位下游应用是否有某个实例存在故障。

核心实践二：快速定位故障源和性能瓶颈

通过核心实践一介绍的功能，相信大家已经可以对整个微服务系统形成全面而深入的了解。接下来，我们需要在系统遇到故障或系统问题的时候，通过ARMS来迅速定位故障源和性能瓶颈。

我们以某个业务功能出现卡顿现象为例，来说明如何通过ARMS一步一步的进行排查。这种情况发生的时候，往往来自于前端用户的反馈，直观的表现是前端用户在进行操作的时候，返回时间比较长，或者收到系统异常相关的提示。

核查应用的整体健康状态

首先，我们从自身对于整个系统架构以及业务架构的了解，能够知道当问题发生的时候，前端用户的请求在经过安全系统、负载均衡组件以网关后，最先发往哪一个微服务应用。站在微服务链路的角度，这个应用负责接收并处理最终用户的请求，是链路的发起点，可以简称为入口应用。

通过全局拓扑和应用拓扑视图，我们能够知道这个应用依赖于哪一些下游应用，这样就确定了与这次问题有可能发生关联的应用名单。

回到应用列表视图，我们能查看到这些应用的整理健康状态，最先应该关注的是应用的状态列，如果亮红灯，说明系统已经诊断到某个应用存在明显的健康问题，这个时候我们可以点击红灯图标，让ARMS生成一份应用诊断报告。通过应用诊断报告，能很快的知道这个应用在哪一个时间点发生了故障。比如ARMS判断故障是由应用的某一个实例导致的情况下，会把可疑实例在报告中报出，让使用者点击实例链接就能进入单实例的详情页面，从错误率、硬件资源、JVM等维度对故障进行排查。

图：诊断报告

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

分析应用统计信息

通过前一个步骤，找到的可疑应用名单后，我们逐个点击应用名，进行应用总览视图，分析应用的关键指标。ARMS会收集和展示选定时间内应用的总请求量、平均响应时间、错误数、实时实例数、FullGC次数、慢SQL次数、异常次数和慢调用次数，以及这些指标和上一天的环比、上周的同比升降幅度。我们主要关注这一些信息的环比以及同比升降情况，还可以修改右面右上角的时间段，来调整统计时间范围。

这些展示的数据中，如果我们发现有明显的可疑现象，可以点击数字上的链接，进入更详细的分析视图。例如：我们发现某个应用今天的错误数相比昨天存在400%的涨幅，但总请求量变化不大，就可以判断出这个应用非常值得怀疑。接下来，我们可以直接进入错误分析视图，来观察具体哪一个时间段的哪一些接口存在问题。

图：错误分析视图

在应用总览展示的数据中，最应该值得关注的是慢SQL数据。ARMS会记录应用访问数据库的情况，当发现应用存在大量慢SQL的时候，就可以直接给出判断：该应用在访问数据库的环节存在问题。我们可以从慢SQL分析视图找到到底是哪一条SQL存在问题，从而针对性的进行优化。对于慢SQL的定义，可以通过应用的自定义配置进行修改（默认执行时间超过500ms会标记为慢SQL）

通过调用链锁定问题应用

如果通过前两个步骤还没有找到问题的根源，就需要借助ARMS的核心能力—全链路排查了。

我们先进入入口应用的接口调用视图，结束实际业场景，我们能够快速找到哪一个接口存在响应时间过长的情况。接下来，我们进入接口快照视图，在这个视图中，ARMS记录了每一次具体接口调用的情况，包括耗时、状态、以及对应的TraceId。按照耗时从大到小的顺序，对列表进行排序，就能够找到指定时间内耗时最长的调用。

图：接口快照视图

接下来就需要重点分析接口调用耗时过长的问题了。我们知道，接口调用耗时是应用自身的处理速度，加上下游所有环节处理速度，以及所有网络时延的总和。当应用存在下游依赖的时候，整个调用链路的任何一个环节耗时过高，都会影响到接口的整体耗时。在这种情况下，我们需要利用TraceId提取出调用链路上的所有环节，进行统一的排查。点击TraceId所代表的链接，呈现出来的调用链路视图，就能帮助我们快速锁定真正存在性能瓶颈的应用。

图：调用链路视图

在调用链路视图中，可以查看到整个调用链路中，所经历的每一个应用的调用类型、服务名、IP地址，以及耗时。通过右侧的时间轴，能一步定位到哪一个应用存在性能瓶颈。

锁定有问题的代码

找到有问题的应用后，接下来可以通过对方法栈的剖析，排查出真正存在问题的代码片段。点击放大镜图标，弹出的窗口中展示了这个应用为了处理接口请求所经过的方法列表。同样，通过右侧的时间轴能够迅速定位哪一个方法执行的速度与预期不符。至此，我们已经能够确定慢调用的源头，从而有效的进行下一步的代码优化工作。

图：方法栈视图

线程分析 & 内存快照

找到有问题的代码片断之后，慢调用的根本原因是什么呢？ARMS能够对应用的线程以及内存快照做进一步的分析，为使用者优化代码提供思路。

线程分析功能提供线程粒度的CPU耗时和每类线程数量的统计，并且每5分钟记录一次线程的方法栈并聚合，可真实还原代码执行过程。如果我们发现导致慢调用的关键应用存在CPU占用率高的问题，可以通过线程分析功能找到消耗CPU最多的线程。选中某一异常线程后，能够通过右侧的CPU耗时和线程数曲线图分析CPU耗时与线程数变化。此外，还可以单击异常线程的方法栈，查看指定时间内的此线程的方法执行情况，例如查看处于BLOCKED状态的线程对应的方法，从而优化指定代码段，以便降低CPU使用率。

图：线程分析视图

JVM监控可以直观展示指定时间段内的多项内存指标，虽然图表能体现出内存使用量过大的情况，但无法显示具体信息，因此如果需要进一步排查问题产生的原因，可以创建内存快照，通过详细的日志查看内存占用的详细信息，方便排查内存泄漏和内存浪费等内存问题。点击JVM监控页面的创建内存快照按钮，可以让ARMS在线为应用生成内存快照，并通过控制台在线对内存快照进行分析，从而避免将大体积快照文件回传到开发者的本地环境进行分析。如果我们发现在慢调用比较严重的时间点，GC频繁或者出现了耗时长的FullGC，对于内存快照的分析是必不可少的工作。

内存快照创建后，点击分析结果，就能够进入内存快照在线分析页，这个页面集成了MAT(Eclipse Memory Analyzer)内存分析工具的所有功能，具体的用法和实践可以参考MAT手册。

图：内存分析报告

核心实践三：提前预知风险

构建一个健壮稳定的微服务体系，不能总是等着有问题和故障暴露出来之后，再进行排查和优化，只有建立一个可以提前预知风险机制，才能帮助我们尽可能的避免问题发生。报警机制是实现风险提前预知的核心，ARMS可以制定针对特定监控对象的报警规则，当规则被触发时，会通过预先指定的报警方式向报警联系人分组发送报警信息，以提醒用户采取必要的问题解决措施。

创建联系人

报警规则被触发时会向指定的联系人分组发送通知，而在创建联系人分组之前必须先创建联系人。所以在创建报警规则前，我们需要预先确定报警的接收者，配置好联系人和联系人分组。

我可以在报警管理 > 联系人管理页面创建联系人，指定联系人用于接收通知的手机号码和邮箱地址，也可以提供用于自动发送报警通知的钉钉机器人地址。

创建报警

在ARMS控制台可以制定针对特定监控对象的报警，当报警规则被触发时，系统会以指定的报警方式向报警联系人分组发送报警信息，以提醒用户采取必要的问题解决措施。

报警覆盖了JVM监控、异常接口监控、调用类型统计、主机监控、数据库指标等多种类型，每一种类型都预定义了一系列的可选规则，允许使用者在一个报警中添加一条或多条规则。每一条规则都包含一条时间参数，代表报警基于最近多少分钟之内的统计结果，而多条规则之间可以是“与“或者”或“的关系。

以数据库指标这种类型为例，我们可以定义一条这样的规则：”最近60分钟之内，如果应用的多个实例在访问数据库的时候，平均响应时间大于2000毫秒，便触发系统报警”.

图：数据库指标报警规则示例

为新上线的应用自动创建报警

我们还可以定义多条报警模板，批量创建报警，提高配置报警规则的效率，具体的操作和创建报警类似。

ARMS已经为我们默认定义了5条报警模板，以方便我们使用，在默认情况下，每一个新接入ARMS的应用都会被自动追加如下5条报警：

Ø 数据库异常报警模板：数据库响应时间长或数据库调用出错场景的报警

Ø 异常调用报警模板：存在超时调用或错误调用场景的报警

Ø 主机监控报警模板：CPU 水位过高或磁盘空间不足场景的报警

Ø 进程异常报警模板：进程存活场景的报警

Ø GC异常报警模板：有过多的 FullGC、FullGC 耗时长或 YoungGC 耗时长场景的报警

这5条默认的报警模板很有用，代表着ARMS对于最通用的一些报警场景的抽象，我们保留这几个模板，只在细节方面做出少许调整，用最少的配置提升风险预知的能力。

构建多语言全链路监控体系

除了Java语言外，ARMS还提供了PHP探针，PHP应用接入ARMS后，能够拥有和Java应用同样的全链路监控体验。除了Java和PHP之外 ，ARMS还对主流的编程语言提供了支持，我们可以选择开源的探针/SDK接入ARMS。受益于统一的全链路监控模型，如果一个微服务体系中存在多种语言之间的相互调用，只要把对应的应用都接入ARMS，就能够跨越多语言对调用链路进行统一的管理和分析。

图：ARMS支持的编程语言

当然，开源探针/SDK在功能方面和ARMS探针还存在不小的差距，ARMS针对更多语言的探针正在陆续发布中，希望能够尽快覆盖所有的主流编程语言。目前阶段，我们可以参考以下表格，选择最合适的接入方式。

表格：各种主流语言的接入方式

总结

受限制于篇幅的原因，本文只能介绍全链路监控最核心的一些实践，作为全链路监控以及应用性能管理领域的标杆产品，ARMS还有更多的功能特性等待着我们去挖掘，我们可以对照帮助文档逐步学习。好的产品总是能给予用户最轻松的使用体验，并在实际生产中发挥出巨大的业务价值。我们不妨从现在开始，就将所有微服务应用通过无侵入的方式接入ARMS，构建一体化的全链路监控体系，而不是等到真正遇到生产故障的那一天，为了定位问题而费尽周折。