追踪

作者｜涯海 全链路追踪的价值链路追踪的价值在于“关联”，终端用户、后端利用、云端组件（数据库、音讯等）独特形成了链路追踪的轨迹拓扑大图。这张拓扑笼罩的范畴越广，链路追踪可能施展的价值就越大。而全链路追踪就是笼罩全副关联 IT 零碎，可能残缺记录用户行为在零碎间调用门路与状态的最佳实际计划。 残缺的全链路追踪能够为业务带来三大外围价值：端到端问题诊断，零碎间依赖梳理，自定义标记透传。 • 端到端问题诊断：VIP 客户下单失败，内测用户申请超时，许多终端用户的体验问题，追根溯源就是因为后端利用或云端组件异样导致的。而全链路追踪是解决端到端问题最无效的伎俩，没有之一。• 零碎间依赖梳理：新业务上线，老业务裁撤，机房搬迁/架构降级，IT 零碎间的依赖关系盘根错节，曾经超出了人工梳理的能力领域，基于全链路追踪的拓扑发现，使得上述场景决策更加麻利、可信。• 自定义标记透传：全链路压测，用户级灰度，订单追溯，流量隔离。基于自定义标记的分级解决&数据关联，曾经衍生出了一个凋敝的全链路生态。然而，一旦产生数据断链、标记失落，也将引发不可预知的逻辑劫难。 全链路追踪的挑战与计划全链路追踪的价值与笼罩的范畴成正比，它的挑战也同样如此。为了最大水平地确保链路完整性，无论是前端利用还是云端组件，无论是 Java 语言还是 Go 语言，无论是私有云还是自建机房，都须要遵循同一套链路标准，并实现数据互联互通。多语言协定栈对立、前/后/云（多）端联动、跨云数据交融是实现全链路追踪的三大挑战，如下图所示： 1、多语言协定栈对立在云原生时代，多语言利用架构越来越广泛，利用不同语言个性，实现最佳的性能和研发体验成为一种趋势。然而，不同语言的成熟度差别，使得全链路追踪无奈做到齐全的能力统一。目前业界的支流做法是，先保障近程调用协定层格局对立，多语言利用外部自行实现调用拦挡与上下文透传，这样能够确保根底的链路数据残缺。 然而，绝大部分线上问题无奈仅通过链路追踪的根底能力就可能无效定位并解决，线上零碎的复杂性决定了一款优良的 Trace 产品必须提供更加全面、无效的数据诊断能力，比方代码级诊断、内存剖析、线程池剖析、无损统计等等。充分利用不同语言提供的诊断接口，最大化的开释多语言产品能力是 Trace 可能一直向前倒退的根底。 透传协定标准化：全链路所有利用须要遵循同一套协定透传规范，保障链路上下文在不同语言利用间可能残缺透传，不会呈现断链或上下文缺失的问题。目前支流的开源透传协定包含 Jaeger、SkyWalking、ZipKin 等。最大化开释多语言产品能力：链路追踪除了最根底的调用链性能外，逐渐衍生出了利用/服务监控，办法栈追踪，性能分析等高阶能力。然而不同语言的成熟度导致产品能力差异较大，比方 Java 探针能够基于 JVMTI 实现很多高阶的边缘侧诊断。优良的全链路追踪计划会最大化的开释每种语言的差异化技术红利，而不是一味的谋求趋同平庸。感兴趣的同学能够阅读文章《开源自建/托管与商业化自研 Trace，如何抉择》。2、前后云（多）端联动目前开源的链路追踪实现次要集中于后端业务应用层，在用户终端和云端组件（如云数据库）侧不足无效的埋点伎俩。次要起因是后两者通常由云服务商或三方厂商提供服务，依赖于厂商对于开源的兼容适配性是否敌对。而业务方很难间接染指开发。 上述情况的间接影响是前端页面响应慢，很难间接定位到后端哪个利用或服务导致的，无奈明确给出确定性的根因。同理，云端组件的异样也难以间接与业务利用异样划等号，特地是多个利用共享同一个数据库实例等场景下，须要更加曲折的伎俩进行验证，排查效率非常低下。 为了解决此类问题，首先须要云服务商更好的反对开源链路规范，增加外围办法埋点，并反对开源协定栈透传与数据回流（如阿里云 ARMS 前端监控反对 Jaeger 协定透传与办法栈追踪）。 其次，因为不同零碎可能因为归属等问题，无奈实现全链路协定栈对立，为了实现多端联动，须要由 Trace 零碎提供异构协定栈的买通计划。 异构协定栈买通为了实现异构协定栈（Jaeger、SkyWalking、Zipkin）的买通，Trace 零碎须要反对两项能力：一是协定栈转换与动静配置，比方前端向下透传了 Jaeger 协定，新接入的上游内部零碎应用的则是 ZipKin B3 协定。在两者之间的 Node.js 利用能够接管 Jaeger 协定并向下透传 ZipKin 协定，保障全链路标记透传完整性。二是服务端数据格式转换，能够将上报的不同数据格式转换成对立格局进行存储，或者在查问侧进行兼容。前者保护老本绝对较小，后者兼容性老本更高，但绝对更灵便。 3、跨云数据交融很多大型企业，出于稳定性或数据安全等因素思考，抉择了多云部署，比方国内零碎部署在阿里云，海内零碎部署在 AWS 云，波及企业外部敏感数据的零碎部署在自建机房等。多云部署曾经成为了一种典型的云上部署架构，然而不同环境的网络隔离，以及基础设施的差异性，也为运维人员带来了微小的挑战。 因为云环境间仅能通过公网通信，为了实现多云部署架构下的链路完整性，能够采纳链路数据跨云上报、跨云查问等形式。无论哪种形式，指标都是实现多云数据对立可见，通过残缺链路数据疾速定位或剖析问题。 跨云上报链路数据跨云上报的实现难度绝对较低，便于保护治理，是目前云厂商采纳的支流做法，比方阿里云 ARMS 就是通过跨云数据上报实现的多云数据交融。 跨云上报的长处是部署成本低，一套服务端便于保护；毛病是跨云传输会占用公网带宽，公网流量费用和稳定性是重要限度条件。跨云上报比拟适宜一主多从架构，绝大部分节点部署在一个云环境内，其余云/自建机房仅占大量业务流量，比方某企业 toC 业务部署在阿x云，企业外部利用部署在自建机房，就比拟适宜跨云上报的形式，如下图所示。 跨云查问跨云查问是指原始链路数据保留在以后云网络内，将一次用户查问别离下发，再将查问后果聚合进行对立解决，缩小公网传输老本。 跨云查问的长处就是跨网传输数据量小，特地是链路数据的理论查问量通常不到原始数据量的万分之一，能够极大地节俭公网带宽。毛病是须要部署多个数据处理终端，不反对分位数、全局 TopN 等简单计算。比拟适宜多主架构，简略的链路拼接、max/min/avg 统计都能够反对。 ...

这是来自Uber的Yuri Shkuro和红帽的Pavol Loffay在几个月前KubeCon + CloudNativeCon北美有关Jaeger和分布式跟踪的介绍。内容包括对当前的Jaeger功能做一个简短的演示，讨论即将到来的一年的路线图，并完成问答。在完成这个介绍之后，应该能更好地了解Jaeger如何适应云原生应用程序的可观察性：腾讯视频幻灯片有关该项目的更多信息，欢迎大家继续观赏他们的“深入了解：Jaeger”的内容：腾讯视频幻灯片KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！

作者：Austin ParkerOpenTracing的最大优势之一是围绕它构建的社区，涵盖各种语言和技术。考虑到这一点，我很高兴今天在OpenTracing博客上发表一篇由Aaron Stannard撰写的客座文章。Aaron Stannard是Petabridge的创始人兼首席执行官，Petabridge是一家帮助.NET公司构建大规模分布式系统的创业公司。他也是Akka.NET项目的联合创始人。你可以在Twitter上找到他，网址是https://twitter.com/Aarononth…在过去的五年里，我一直担任Akka.NET开源项目的维护者和联合创始人之一，该项目是最初在Scala开发，极受欢迎的Akka项目的C#和F#移植。我最初开始这个项目，是因为.NET生态系统缺乏用于构建实时大型应用程序类型的工具和框架，就像那时我在MarkedUp开发的那种类型，MarkedUp是我运行的营销自动化和分析的初创公司。在关闭MarkedUp后，我继续创建了Petabridge，这是一家致力于在.NET中支持和开发Akka.NET，和其他分布式系统技术的开源公司。我很高兴地报告说，现在.NET社区有一个更强大的开源生态系统，并且有更多的工具选择，可用于构建我在2013-14年工作的.NET中的大规模应用程序类型。随着.NET Core的出现，整个.NET生态系统正在发生巨大变化，.NET Core是一种高性能，轻量级和100％跨平台的.NET运行时（runtime）的新实现。这为.NET开发者开辟了一个新的可能性，而这之前根本就没有。使用Akka.NET和Actor模型的大规模.NETAkka和Akka.NET，如果你还没有听说过，是在通用虚拟机（分别是JVM和CLR）之上构建的actor模型的实现。演员（actor）模型是一个可追溯到早期20世纪70年代的旧概念，但近年来它重新焕发活力，因为它提供了一种易于在大型数据中心或公共云环境中分发，可理解的计算模型。你问，“可理解的计算模型”做什么？具体来说，actor模型为需要构建可扩展实时系统的开发者，找到了一个家，例如：多人视频游戏；分析（Analytics）；营销自动化；医疗/医疗物联网；物流、交通和运输；能源；金融；和实时交易处理（ACH、支付处理器等）所有这些应用程序的共同点是，它们履行了对客户和利益相关者的义务，他们必须能够以一致的快速（实时）方式完成工作，而不管系统的总量（可扩展）。为了使这些应用程序满足这两个目标，它们必须是有状态的，这意味着真实的来源来自应用程序内存，而不是外部数据库。为了使有状态应用既具有容错性，和高可用性，它们也必须分散（decentralized），状态不能集中在一个区域，否则系统容易受到单点瓶颈和单点故障限制的影响。这是actor模型允许开发者做的事情：构建高度分散、容错、有状态的应用程序，其中每个工作（actor）单元都是自包含的私有状态，不能直接从外部修改。修改actor的状态的唯一方法，是通过向该actor发送一条消息，该actor最终将处理该消息，从而可能导致更新actor的状态。在.NET中，Akka.NET是构建这些类型应用程序的主要actor模型实现，它被数百家公司使用，包括戴尔、美国银行、波音、S＆P Global、Becton Dickinson、美国能源部，Zynga等等。然而，演员模型为试图大规模采用它的软件团队提出了一些重大挑战，其中最痛苦的一个是大规模诊断和调试编程错误和网络相关问题。这就是OpenTracing和分布式跟踪的登场时间。使用OpenTracing以低成本了解复杂性Akka.NET和大规模分布式演员的问题在于，在任何特定时间，你的系统每秒都可以进行数千万次交互，看起来与此太相似：Akka.NET ActorSystem中的每个actor通常都有一些少量的自包含状态，一些消息处理代码执行其实际工作，以及一些对它经常与之通信的其他actor的引用。演员通过来回传递消息来相互通信。默认情况下，在actor模型中传递的消息100％是异步的，actors一直按照它们被发送的顺序处理消息，但是一个actor可能必须处理来自许多其他actor的消息。Actor可以跨进程和网络边界透明地相互通信，因此，发送到一个进程内的单个actor的消息可能最终传播到多个进程。其中存在的问题是：这种位置透明性，使得演员如此擅长以可扩展的方式分配工作，这可能会使他们在生产中出现问题时进行调试时非常令人沮丧：知道出现问题的地点和时间变成一个非凡问题，尤其是当你有数百万次这样的操作一直在发生时。这是我们发现OpenTracing特别有用的地方。Akka.NET应用程序不作为单线程，单体进程存在，它们是高度并发且通常是分布式的进程。因此.NET中常见的传统跟踪工具，如Intellitrace，通常无法帮助我们回答系统内部“出了什么问题？”。我们需要的是分布式跟踪工具，它们可以从多个进程收集上下文，将它们关联在一起，并从分布式系统的角度讲述完整的故事。我们需要能够回答诸如“akka.tcp://ClusterSys@10.11.22.248:1100/user/actorA/child2收到msg1后，发送给akka.tcp://ClusterSys@10.11.22.249:1100/user/processB/child1的是什么？”，只有在这两个进程上运行的分布式跟踪工具，才能有效地回答这个问题，而这正是我们在Petabridge上使用OpenTracing的原因。OpenTracing实施和优势Petabridge专业支持大规模采用Akka.NET的用户，这意味着我们必须提供各种工具来帮助他们的生活更轻松。这就是为什么我们开始创建Phobos，这是Akka.NET的监控和跟踪解决方案。我们希望通过开发某种分布式跟踪实现，帮助我们的用户解决这个Akka.NET可观察性问题，这些实现可以轻松地包含在他们的应用程序代码。但我们遇到了一个小问题：我们的客户无法接受单一供应商的解决方案作应用程序性能监视，他们肯定不会接受只适用于Akka.NET，而不适用于其他重要的.NET技术，如ASP.NET Core和SignalR。OpenTracing为我们优雅而简单地解决了这个问题：通过瞄准OpenTracing标准，而不是任何单一的销售解决方案，如Zipkin或Jaeger，我们可以为我们的客户打开门口，让他们选择他们想要的任何跟踪解决方案。我们也知道，我们很可能会为.NET用户创建一些兼容OpenTracing的驱动程序，他们希望能够使用我们和其他依赖该标准的产品。因此，我们针对优秀的OpenTracing C#库构建了Phobos的跟踪功能，并设计了Zipkin和Jaeger等工具基于OpenTracing绑定的第一方集成。这大大降低了我们的开发成本，增加了用户享受的选择自由。每次演员发送或接收消息时，我们都会创建一个新的Span，并将跟踪标识符传播到我们在演员之间传递的每条消息中，包括通过网络传递。我们能够构建所有这些，因此它在幕后工作，而不需要太多的手动仪器（instrumentation）。可以肯定的是，OpenTracing允许我们使用Jaeger制作像这样的可理解的图形：在这种情况下，我们正在建模一个“扇出”（“fan out”）调用，其中一个节点通过网络向许多其他节点发出呼叫，使用传统工具难以捕获的东西，因为它涉及多个节点上的大量并发处理和每个人之间的异步沟通。但是使用OpenTracing的标准，我们很容易使用像Jaeger这样的工具来实现这一点，Jaeger在C#中有一个很好的OpenTracing兼容驱动程序。在.NET中创建OpenTracing驱动程序一旦Phobos完全支持OpenTracing，作为我们最终用户的集成点，我们就知道任何拥有内部或第三方跟踪解决方案，但本身不支持OpenTracing的Akka.NET用户最终都可以找到一种方法使用OpenTracing库来将事情联系在一起。但是，我们决定加倍努力，采用一些已经在.NET社区中流行的现有工具，或者通过为这些产品推出第一方OpenTracing驱动程序和适配器来降低进入门槛。我们建造的第一个是Petabridge.Tracing.Zipkin，一个用于Zipkin的高性能OpenTracing兼容驱动程序；我们想在内部使用Zipkin，并希望原生支持像Kafka的传送选项。在许多.NET用户的要求下，我们构建的第二个也是更有趣的是Microsoft Application Insights OpenTracing适配器，用于我们的Akka.NET跟踪产品。对Azure上运行的用户，我们希望能够支持Application Insights作为的跟踪目标，但是没有用于将Application Insights插入OpenTracing的内置解决方案。因此，我们遵循了Microsoft团队编写的标准文档，该文档允许我们在OpenTracing的词典之上映射Application Insights常规，并且能够创建一个开源软件包Petabridge.Tracing.ApplicationInsights，它弥合了这两者之间的差距技术，使Application Insights在大型Akka.NET应用程序中完美可行。我们在发布软件包之后发现，即便是微软本身也在使用OpenTracing和我们的Application Insights驱动程序来内部测试他们自己的一些云应用程序。对于整个.NET生态系统中的每个人来说，这是一件好事：随着OpenTracing继续获得牵引力，它将有助于推动其作为行业标准实践的使用。随着我们继续推动大规模.NET系统的规模和速度的界限，像我们这样的组织将继续投资OpenTracing等技术，以及其有前途的监控对手OpenMetrics，以限制运行这些系统的运营和管理成本。到目前为止，OpenTracing已经为我们的公司和整个Akka.NET项目带来了惊人的表现，我们期待在未来看到更多。-Aaron Stannard，Petabridge首席执行官Akka.NET项目联合创始人2019年KubeCon + CloudNativeCon中国论坛提案征集（CFP）现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集（CFP）现已开放在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux、容器、云技术、网络、微服务等；并获得如何在开源社区中导向和引领的信息。大会日期：提案征集截止日期：太平洋标准时间 2 月 15 日，星期五，晚上 11:59提案征集通知日期：2019 年 4 月 1 日会议日程通告日期：2019 年 4 月 3 日幻灯片提交截止日期：6 月 17 日，星期一会议活动举办日期：2019 年 6 月 24 至 26 日2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦

概述生产环境中的服务可能会出现各种问题，但总不能让服务下线来专门排查错误，这时候最好有一些手段来获取程序运行时信息，比如 接口方法参数/返回值、外部调用情况 以及 函数执行时间等信息以便定位问题。传统的日志记录方式的确可以，但有时非常麻烦，甚至可能需要重启服务，因此代价太大，这时可以借助一个牛批的工具：BTrace ！BTrace 可用于动态跟踪正在运行的 Java程序，其原理是通过动态地检测目标应用程序的类并注入跟踪代码 ( “字节码跟踪” )，因此可以直接用于监控和追踪线上问题而无需修改业务代码并重启应用程序。BTrace 的使用方式是用户自己编写符合 BTrace使用语法的脚本，并结合btrace命令，来获取应用的一切调用信息，就像下面这样：<btrace>/bin/btrace <PID> <trace_script>其中 <PID>为被监控 Java应用的 进程ID<trace_script> 为 根据需要监控的信息 而自行编写的 Java脚本本文就来实操一波 BTrace工具的使用，实验环境如下：OS：CentOS 7.4 64bitBTrace版本：1.3.11.3被追踪的 Java应用：Spring Boot 2.1.1 应用，这里使用我的文章《Spring Boot应用缓存实践之：Ehcache加持》一文中的 Spring Boot工程BTrace 安装部署下载 二进制文件并解压这里我解压到目录：/home/btrace配置系统环境变量vim /etc/profileBTRACE_HOME=/home/btraceexport BTRACE_HOMEexport PATH=$PATH:$BTRACE_HOME/bin验证 BTrace安装情况btrace –version编译 BTrace源码克隆源码git clone git@github.com:btraceio/btrace.git编译源码./gradlew build构建完成的生成物路径位于：build/libs目录下我们取出构建生成的 jar包供下文使用。利用btrace追踪 Spring Boot应用例析首先我们得构造一个 Spring Boot的模拟业务 用于下文被追踪和分析，这里我就使用文章 《Spring Boot应用缓存实践之：Ehcache加持》中的实验工程。我们在此工程里再添加一个 scripts包，用于放置 btrace 脚本文件：由于 btrace脚本中需要用到 btrace相关的组件和函数库，因此我们还需要在工程的 pom.xml中引入 btrace的依赖，所使用的 jar包就是上文编译生成的 btrace-1.3.11.3.jar <dependency> <groupId>com.sun.btrace</groupId> <artifactId>btrace</artifactId> <version>1.3.11.3</version> </dependency>Talk is cheap ，Show you the code ！接下来就用四五个实验来说明一切吧：0x01 监控方法耗时情况btrace 脚本：@BTracepublic class BtraceTest2 { @OnMethod(clazz = “cn.codesheep.springbt_brace.controller.UserController”, method = “getUsersByName”, location = @Location(Kind.RETURN)) public static void getFuncRunTime( @ProbeMethodName String pmn, @Duration long duration) { println( “接口 " + pmn + strcat(“的执行时间(ms)为: “, str(duration / 1000000)) ); //单位是纳秒，要转为毫秒 }}接下来开始运行 btrace脚本来拦截方法的参数，首先我们用 jps命令取到需要被监控的 Spring Boot应用的进程 Id为 27887，然后执行：/home/btrace/bin/btrace 27887 BtraceTest2.java这里我总共对 /getusersbyname接口发出了 12次 POST请求，情况如下：接下来我们再看看利用btrace脚本监控到的 /getuserbyname接口的执行时间：这样一对比很明显，从数据库取数据还是需要 花费十几毫秒的，但从缓存读取数据 几乎没有耗时，这就是为什么要让缓存加持于应用的原因！！！0x02 拦截方法的 参数/返回值btrace 脚本： @OnMethod( clazz = “cn.codesheep.springbt_brace.controller.UserController”, method = “getUsersByName”, location = @Location(Kind.ENTRY) ) public static void getFuncEntry(@ProbeClassName String pcn, @ProbeMethodName String pmn, User user ) { println(“类名: " + pcn); println(“方法名: " + pmn); // 先打印入参实体整体信息 BTraceUtils.print(“入参实体为: “); BTraceUtils.printFields(user); // 再打印入参实体每个属性的信息 Field oneFiled = BTraceUtils.field(“cn.codesheep.springbt_brace.entity.User”, “userName”); println(“userName字段为: " + BTraceUtils.get(oneFiled, user)); oneFiled = BTraceUtils.field(“cn.codesheep.springbt_brace.entity.User”, “userAge”); println(“userAge字段为: " + BTraceUtils.get(oneFiled, user)); }接下来开始运行 btrace脚本来拦截方法的参数，首先我们用 jps命令取到需要被监控的java应用的进程 Id为 27887，然后执行：/home/btrace/bin/btrace -cp springbt_brace/target/classes 27887 BtraceTest4.java此时正常带参数 {“userName”:“codesheep.cn”} 去请求业务接口：POST /getusersbyname，会得到如下输出：很明显请求参数已经被 btrace给拦截到了同理，如果想拦截方法的返回值，可以使用如下 btrace脚本： @OnMethod( clazz = “cn.codesheep.springbt_brace.controller.UserController”, method = “getUsersByName”, location = @Location(Kind.RETURN) //函数返回的时候执行，如果不填，则在函数开始的时候执行 ) public static void getFuncReturn( @Return List<User> users ) { println(“返回值为: “); println(str(users)); }运行 btrace命令后，继续请求想要被监控的业务接口，则可以得到类似如下的输出：0x03 监控代码是否到达了某类的某一行btrace 脚本如下：@BTracepublic class BtraceTest3 { @OnMethod( clazz=“cn.codesheep.springbt_brace.service.UserService”, method=“getUsersByName”, location=@Location(value= Kind.LINE, line=28) // 比如拦截第28行, 28行是从数据库取数据操作 ) public static void lineTest( @ProbeClassName String pcn, @ProbeMethodName String pmn, int line ) { BTraceUtils.println(“ClassName: " + pcn); BTraceUtils.println(“MethodName: " + pmn); BTraceUtils.println(“执行到的line行数: " + line); }}执行 btrace追踪命令/home/btrace/bin/btrace 28927 BtraceTest3.java接着用 POSTMAN工具连续发出了对 /getuserbyname接口的 十几次POST请求，由于只有第一次请求没有缓存时才会从数据库读，因此也才会执行到 UserService类的第 28行 ！0x04 监控指定函数中所有外部调用的耗时情况btrace脚本如下：@BTracepublic class BtraceTest5 { @OnMethod (clazz = “cn.codesheep.springbt_brace.service.UserService”,method = “getUsersByName”, location=@Location(value= Kind.CALL, clazz=”/./”, method=”/./”, where = Where.AFTER) ) public static void printMethodRunTime(@Self Object self,@TargetInstance Object instance,@TargetMethodOrField String method, @Duration long duration) { if( duration > 5000000 ){ //如果外部调用耗时大于 5ms 则打印出来 println( “self: " + self ); println( “instance: " + instance ); println( method + “,cost:” + duration/1000000 + " ms” ); } }}执行监控命令：/home/btrace/bin/btrace 28927 BtraceTest5.java然后再对接口 /getuserbyname发出POST请求，观察监控结果如下：我们发现最耗时的外部调用来源于 MyBatis调用。0x05 其他追踪与监控除了上面四种典型的追踪场景之外，其他的 btrace追踪与监控场景还比如 查看谁调用了System.gc()，调用栈如何，则可以使用如下 btrace脚本进行监控@BTracepublic class BtraceTest { @OnMethod(clazz = “java.lang.System”, method = “gc”) public static void onSystemGC() { println(“entered System.gc()”); jstack(); }}很明显，因为btrace 内置了一系列诸如 jstack等十分有用的监控命令。当然最后需要说明的是 btrace内置了很多语法和命令，可以应对很多线上 Java应用监控场景，大家可以去研究一下官方文档后记由于能力有限，若有错误或者不当之处，还请大家批评指正，一起学习交流！My Personal Blog：CodeSheep 程序羊程序羊的 2018年终总（gen）结（feng） ...

OpenTracing Registry（https://opentracing.io/registry/）已经登记了129个仪器插件和跟踪器。来检查一下，看看你的项目是否可以在可观察性方面获得快速启动！