简介： 好的产品总是能给予用户最轻松的应用体验，并在理论生产中施展出微小的业务价值。咱们无妨从当初开始，就将所有微服务利用通过无侵入的形式接入 ARMS，构建一体化的全链路监控体系，而不是等到真正遇到生产故障的那一天，为了定位问题而费尽周折。
作者：山猎，阿里云解决方案架构师
前言
随着分布式技术的倒退与演进，微服务技术成为了大型分布式 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，构建一体化的全链路监控体系，而不是等到真正遇到生产故障的那一天，为了定位问题而费尽周折。
原文链接
本文为阿里云原创内容，未经容许不得转载。