怎样增加网站流量,西安网站制作公司怎么选,vi设计手册范本,网站网格简介#xff1a; 好的产品总是能给予用户最轻松的使用体验#xff0c;并在实际生产中发挥出巨大的业务价值。我们不妨从现在开始#xff0c;就将所有微服务应用通过无侵入的方式接入ARMS#xff0c;构建一体化的全链路监控体系#xff0c;而不是等到真正遇到生产故障的那一…简介 好的产品总是能给予用户最轻松的使用体验并在实际生产中发挥出巨大的业务价值。我们不妨从现在开始就将所有微服务应用通过无侵入的方式接入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就能满足这个要求代表着业界在全链路监控以及应用性能管理领域的最高水平。
应用实时监控服务ARMSApplication 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构建一体化的全链路监控体系而不是等到真正遇到生产故障的那一天为了定位问题而费尽周折。 原文链接 本文为阿里云原创内容未经允许不得转载。
