作者：山猎，阿里云办理方案架构师
序言随着分布式技能的发展与演进，微做事技能成为了大型分布式IT架构的一定选择。从实质上来讲，微做事是一种架构风格，将一个大型的系统拆分为多个拥有独立生命周期的运用，运用之间采取轻量级的通信机制进行通信。这些运用都是环绕详细业务进行构建，可以独立支配、独立迭代，也可能根据业务负载独立的水平扩展。微做事思想以及干系的技能为IT架构的发展带来了一系列深刻的变革。微做事技能让IT系统变得更敏捷、更健壮、更高性能的同时，也给带来了架构繁芜度的提升，给运用监控带来了前所未有的寻衅。在微做事时期，由于做事的拆分，单个用户要求会经由多个微做事运用，形成繁芜的调用链路，使传统的依赖于单机业务日志的监控手段无从下手，这就须要建立全新的监控机制，帮助开拓者全面洞察系统运行状态，并在系统碰着非常的时候快速的定位和解决问题。
在分布衰落做事架构中，系统为了吸收并处理一个前端用户要求，须要让多个微做事运用协同事情，个中的每一个微做事运用都可以用不同的编程措辞构建，由不同的团队开拓，并可以通过多个对等的运用实例实现水平扩展，乃至分布在横跨多个数据中央的数千台做事器上。单个用户要求会引发不同运用之间产生一串顺序性的调用关系，链路的观点就此出身。
随着业务规模的增长，不但来自于前端用户的要求频度会增加，链路也变得更长，这也代表着运用之间的调用关系变得越来越繁芜。为了提升微做事系统在繁芜链路下的健壮性和稳定性，有3个关键诉求须要我们去办理：1 . 如何梳理整套系统的调用关系，并评判运用高下游依赖的合理性？2 . 如何理解每一个运用的性能指标，并对系统容量进行合理的方案？3 . 当系统涌现故障或非常的时候，如何第一韶光创造问题、定位问题、办理问题？这3个关键诉求的核心寻衅，都来源于运用之间繁芜的链路。如果有一套成熟易用的机制，对每一条链路的行为进行记录，并进行深入的剖析，提取出有代价的参考数据，就能让这些难题迎刃而解，这个主要的机制便是全链路监控。
标准与规范十年前，Google成为了分布式系统链路追踪做事的先行者，并通过《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》这篇著名论文阐述了如何在超大规模系统上培植低损耗（low overhead）、运用级透明（application-level transparency）、大范围支配（ubiquitous deployment）的链路追踪做事。
Dapper阐述了对分布式系统进行链路追踪的技能细节，包括数据表示、埋点、通报、网络、存储与展示等方面，并提出了跟踪树、Span、Trace、Annotation等主要观点，为全链路监控供应了理论辅导。
在Dapper的启示下，业界出身了很多用于分布式链路追踪的开源组件，为了保持对链路中每一个环节的记录与匹配，不仅须要在运用内部对跟踪信息进行通报，还须要让跟踪信息超过不同的运用以及不同的分布式组件。这须要制订一套统一的标准，让微做事体系中的所有运用遵照这套标准来实现跟踪信息的描述和通报，这套标准便是OpenTracing。OpenTracing抽象出一套与编程措辞以及业务逻辑无关的接口，对链路追踪领域各种元素的统一管理，从而实现完全的全链路监控。本文不会深入先容Dapper和OpenTracing的事理以及技能细节。我们只须要知道，精良的全链路监控组件会尽可能的遵照OpenTracing标准，以得到更好的通用性以及扩展性。
可选方案全链路监控组件如何得到链路干系的信息呢？最大略的办法是让开发者在业务代码中手工埋点，天生符合OpenTracing标准的链路信息，并汇入全链路监控组件。但手工埋点的办法哀求开拓者主动合营，并在业务代码中嵌入大量非业务逻辑。这样的办法是极为薄弱的，开拓者稍有轻忽就会导致链路信息丢失，乃至影响到正常的业务逻辑。以是非手工埋点的自动链路信息采集，成为了业界的主流，个中包括两种实现办法：1 . SDK办法: 通过引入链路追踪SDK自动天生链路数据，并自动上报。对付底层框架没有公开API的情形，监控逻辑的注入会比较繁芜，有可能须要开拓者针对详细的底层框架预先做好适配事情。2 . 探针办法: 探针办法不须要在代码编译前引入SDK，而是在运用运行的过程中，通过一个Agent动态的拦截底层框架的行为，从而自动注入监控逻辑。像Java这样的编程措辞可以通过字节码增强技能实现探针办法的链路信息采集。这是一种最开拓者最友好的办法，不须要任何代码层面的改动，但并不是每一种编程措辞都能供应探针机制，因此SDK办法也被很多全链路监控组件采取。
不管是SDK办法还是探针办法，非手工埋点形式的链路信息采集都依赖于链路追踪组件对付底层框架的识别。这些底层框架包含的领域非常广，个中包含运用对外供应做事所须要的框架，运用进程内部的通讯框架，运用之间相互访问所须要的框架，运用访问外部系统所须要的框架等等。比如在Java体系中，用于供应HTTP做事的Tomcat、Jetty，用于进程内部通讯的RxJava，用于微做事运用之间相互调用的Feign，用于访问外部系统的MyBatis、MySQL JDBC、HTTPClient，都属于这个范畴。对付多种编程措辞以及种类繁多的底层框架的适配，是一项浩大的工程，一个全链路监控方案能够适配的底层框架越多，它的能力就越强大。
根本链路信息网络上来之后，须要进行统一存储，并对数据进行洗濯与聚合，根据运用相应韶光、要求数、缺点率等指标进行下钻剖析，并按运用、接口、链路、事务等多个维度进行展示，这也是一项非常繁芜的事情。因此，全链路监控方案的技能门槛是非常高的，在开源的全链路监控产品中，真正遵照OpenTracing标准，又够被广泛认可和利用的产品非常少，个中通过SDK办法接入的产品以Jaeger为代表，通过探针办法接入的产品以Skywalking为代表。
最轻松的方案
开源的全链路监控方案能帮助开拓者更深入的理解全链路监控的思想、事理以技能细节，但在在生产环境大规模利用开源方案，还是会给开拓者带来很大的寻衅：1 . 掩护事情繁芜：除了客户真个SDK和探针外，一套全链路监控方案在做事端有打算组件、存储组件、展示组件，都须要单独进行掩护。以Jaeger为例，仅在数据存储方面须要掩护一套独立的Elasticsearch集群，须要投入很大的事情量。2 . 功能大略：对主流底层框架的全面支持，丰富的UI界面，完善的诊断机制和报警机制，这些都是一套精良的全链路监控方案所必备的特质。开源方案在这些方面很难做到尽善尽美。3 . 短缺高可用保障：开源全链路监控方案并没有完全的高可用机制，当某个组件涌现故障，比如做事器宕机的时候，无法自动规复，须要人工参与进行办理，在这个过程中正常的监控会受到影响。4 . 无法支撑大规模场景：当接入的运用数量达到上千个之后，开源全链路监控方案会暴露出各种性能问题，须要开拓者修正源代码进行针对性的优化。5 . 影响正常业务：如果SDK/探针存在设计上的毛病，有可能导致运用涌现不可预知的故障。这种情形极为罕见，但一旦发生，后果会非常严重，这种情形下一样平常也只能等待开源社区将问题修复后才能规复利用。之以是在生产环境利用开源全链路监控方案存在这么大寻衅，是由于这些方案本身缺少大规模实际业务场景的验证。对付技能实力非常强的互联网企业，会有专门的技能团队卖力全链路监控项目，在利用开源产品的过程中如果碰着任何问题，都可以通过自身的技能实力进行修复和填补。但对付绝大多数利用者而言，这些寻衅所带来的都是漫长而痛楚的体验。有没有一套经历过大规模实际业务场景验证，又大略易用的全链路监控产品呢？在云打算时期这个问题的答案是肯定的，阿里云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剖析工具。同样，在以韶光为横坐的曲线图处，可以连续选中一个韶光段进行下钻剖析。
如果一个运用的多个对等实例中，某一个涌现了故障，我们就能够非常迅速的创造这个实例在运用情形视图中呈现出来的状态信息和其他实例存在非常大的差异，这样有助于我们迅速找到故障实例，并进行相应的处理。
接口调用 & 外部调用当一个运用对外供应多个做事接口的时候，如何从剖析每一个接口的做事质量，以及每一个接口对应的链路详细情形呢？这个时候接口调用视图就能发挥主要的浸染。从这个运用所有供应的接口中，我们可以选中须要剖析的单个接口，与这个接口干系的链路信息就能够从多个维度展示出来，个中包括接口的要求数、相应韶光、缺点数、返回状态码，以及在接口所对应的链路中，运用访问外部数据库（包括关系型数据库，以及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条报警：1、数据库非常报警模板：数据库相应韶光长或数据库调用出错场景的报警2、非常调用报警模板：存在超时调用或缺点调用场景的报警3、主机监控报警模板：CPU 水位过高或磁盘空间不敷场景的报警4、进程非常报警模板：进程存活场景的报警5、GC非常报警模板：有过多的 FullGC、FullGC 耗时长或 YoungGC 耗时长场景的报警这5条默认的报警模板很有用，代表着ARMS对付最通用的一些报警场景的抽象，我们保留这几个模板，只在细节方面做出少许调度，用最少的配置提升风险预知的能力。
构建多措辞全链路监控体系除了Java措辞外，ARMS还供应了PHP探针，PHP运用接入ARMS后，能够拥有和Java运用同样的全链路监控体验。除了Java和PHP之外 ，ARMS还对主流的编程措辞供应了支持，我们可以选择开源的探针/SDK接入ARMS。受益于统一的全链路监控模型，如果一个微做事体系中存在多种措辞之间的相互调用，只要把对应的运用都接入ARMS，就能够超过多措辞对调用链路进行统一的管理和剖析。
当然，开源探针/SDK在功能方面和ARMS探针还存在不小的差距，ARMS针对更多措辞的探针正在陆续发布中，希望能够尽快覆盖所有的主流编程措辞。目前阶段，我们可以参考以下表格，选择最得当的接入办法。
总结
受限定于篇幅的缘故原由，本文只能先容全链路监控最核心的一些实践，作为全链路监控以及运用性能管理领域的标杆产品，ARMS还有更多的功能特性等待着我们去挖掘，我们可以对照帮助文档逐步学习。好的产品总是能给予用户最轻松的利用体验，并在实际生产中发挥出巨大的业务代价。我们不妨从现在开始，就将所有微做事运用通过无侵入的办法接入ARMS，构建一体化的全链路监控体系，而不是等到真正碰着生产故障的那一天，为了定位问题而费尽周折。
