拥抱 OpenTelemetry:阿里云 Java Agent 演进实践

简介: 拥抱 OpenTelemetry:阿里云 Java Agent 演进实践

背景

Cloud Native

在 2018 年的 2 月,ARMS Java Agent 的第一个版本正式发布,为用户提供无侵入的的可观测数据采集服务。6 年后的今天,随着软件技术的迅猛发展、业务场景的逐渐丰富、用户规模的快速增长,我们逐渐发现过去的功能以及架构的设计逐渐难以合理、优雅的满足今天的需求,重构越来越多的被提及,但总是缺少一个合理的契机。

适时,OTel 项目异军突起,其社区经过短短四年的发展,活跃度位列 CNCF 第二,逐渐成为可观测领域的开源标准。OTel(OpenTelemetry)是一个位于云原生计算基金会(CNCF)的开放源代码项目,旨在标准化遥测数据的收集、处理和导出的方式。其贡献者由来自不同公司和组织的成员组成,他们共同协作创建和维护用于分布式追踪、指标和日志的 API、SDK 和工具。他们的目标是使可观测性更加易于访问并整合到云原生软件开发中,从而使用户能够更有效地监控、调试和优化他们的应用程序。

这些现象也极大的引起了我们的兴趣, 促使我们对 OTel Java Agent 进行了一次深入的调研。

关于 OTel Java Agent

Cloud Native

首先我们对比了 OTel Java Agent 和 ARMS 现有探针在 Tracing、Metrics、Logs、Profiling 以及其他五个方面的功能差异,如下表所示。可以看到,简单的从功能层面来说,OTel Java Agent 依托社区广大的贡献者,在插件数量上远远领先。此外,基于一些领先的埋点技术,对于各种异步场景支持较好;ARMS 探针则依托广大的商业化用户场景和多年服务集团内外客户的经验,在采样、多协议支持、指标丰富度以及各种三方功能集成方面比较领先。

功能大类

功能子类

ARMS (3.1.4)

OTel Java Agent(1.28.0)

Tracing

插件支持

≈60

≈128

采样能力

头采样、尾采样

头采样

TraceId 透传协议

支持 eagleeye,w3c,zipkin,skywalking,Jaeger,自适应切换,自定义配置

w3c、zipkin、Jaeger

异步透传 手动配置 自动
兼容 OTel SDK

部分支持

全支持

动态新增 Span

支持

不支持

Metrics

RED 指标

支持 支持
线程相关指标 支持 不支持
连接池指标 支持 支持
异常指标 支持 不支持
系统/JVM指标

支持

支持

JMX 指标 不支持 支持
动态新增指标 不支持 不支持

logs

MDC

支持

支持

自动采集

不支持

支持

profiling

支持 Profiling 事件类型数量

5 类CPU 耗时内存样本数内存分配大小应用级墙钟代码热点

不支持

关联 traceId 支持

不支持

event

event 类型数量

简单

不支持

other

应用安全 支持 不支持
Arthas 支持 不支持
微服务治理 支持 不支持
内存 dump 支持 不支持

除了上面列举的功能对比,在对 OTel Java Agent 调研中,我们也发现他有很多领先的设计在解决埋点生效判断、异步、类隔离等问题时十分方便。这里简单介绍一下他的几个比较领先的设计。


muzzle-check 机制
编译时收集我们埋点代码中访问了被增强类的哪些方法、字段。在运行时,如果待增强类没有相应的方法和字段,则不执行增强动作,避免增强代码报错;在平时,可以对待增强类的所有版本执行静态检测,获得支持版本列表。

VirtualField 机制

JVM 的字节码增强机制有一些限制,对于已加载类的增强,只能修改方法体,不能给类新增字段。这个限制对于我们影响较大,因为在 APM 的场景下,往往有较多的场景需要给类增加字段来作一些变量传递。opentelemetry-java-instrumentation 提供了 VirtualField 机制,如下图所示,通过统一的编程接口,可以给类 T 添加一个类型为 F 的字段。

  • 当类 T 当前尚未加载时,此时的实现就是给类 T 增加了类型为 F 的字段。当访问类 T 的 F 字段时和访问普通的类字段一致。
  • 当类 T 已经加载时,此时的实现是有一个全局的 ConCurrentWeakhashMap,map 的 key 类型为 T,value 类型为 F。当访问类 T 的 F 字段时实际在底层为 map 的 get 操作。
public static <U extends T, V extends F, T, F>
VirtualField<U, V> find(Class<T> type, Class<F>fieldType) {
return RuntimeVirtualFieldSupplier.get().find(type, fieldType);}


异步上下文透传

除了原生的 JDK 线程池,对市面上常见的异步框架 akka、netty event loop 等均做了异步埋点。异步埋点思路整体上包含两个步骤:

  1. 实现了 Runnable 接口的实现类,利用上述的 VirtualField 机制,给实现类增加一个记录 Trace 上下文的字段,同时埋点其 run 方法,run 方法执行时获取增加字段中的 Trace 上下文,并设置到当前线程的 ThreadLocal 中。
  2. 埋点 Exectuor 的 execute 方法,在 execute 方法执行时从 ThreadLocal 获取当前 Trace 上下文,并设置给对应的 Runnable 实现类。


新埋点思路

最大程度利用框架的拓展能力进行埋点,比如利用 Dubbo 的 Filter 机制、grpc 的 Intercepter 机制、实现 lettuce 的 Tracing 接口等等。而不是一味的对框架的方法进行增强。

除了上面提到的这些,opentelemetry-java-instrumentation 还有很多亮点设计,比如类加载器隔离,opentelemetry-java-sdk 兼容,多 JDK 版本兼容等等,这里不再一一赘述,后续会推出系列文章专门介绍 OTel Java Agent 的一些亮点设计和技巧。

调研结论

Cloud Native

当完成 OTel Java Agent 各方面的调研之后,我们会发现他的很多设计都是领先的,一章节提到的那些代码设计和技巧、埋点方式等帮助我们打开了新的思路,可以解决很多困扰许久的问题。OTel Java Agent 的蓬勃发展成为了一个促使我们进行一次大规模重构最合理的契机,再考虑到拥抱开源、拥抱标准的基本原则,于是我们在 2023 年的夏天做了一个重大的决定,在 ARMS Java Agent 的下一个大版本 4.x 版本中,基于 OTel Java Agent 做一次升级重构,将现有 ARMS 3.X 版本探针的商业化能力迁移过来,并做到能 100% 兼容 3.x 探针的功能。

围绕 OTel Java Agent 做了哪些增强

Cloud Native

在接下来将近一年的时间里,围绕 openTelemetry-java-instrumentation,首先,我们对其现有的功能进行了升级重构。包括新插件支持,基础的 Tracing 能力增强,指标类型增加、指标维度增加等等;其次,迁移了很多过往几年沉淀的商业化能力。包括 Arthas 诊断,应用安全、内存 Dump,微服务治理(全链路灰度、无损上下线,限流降级等等);最后,围绕探针构建了完善的稳定性保障措施。升级后的探针整体架构图如下图所示: 下面分别展开说明。

新插件支持
OTel 探针对国内一些被广泛使用的框架、中间件支持较少,比如 druid、xxl-job、hsf、influxdb、mybatis、xxlJob、motan、shenyu 等,我们此次增加了对这些框架的支持,并且部分已经贡献给开源。

Tracing 增强

Tracing 能力是 APM 探针的核心能力,OTel 探针原生的 Tracing 能力在企业内部复杂场景下往往会遇到不少挑战,包括多协议场景下断链、极端场景下 Span 数量爆炸、采样难以命中高价值数据等等。针对这些问题,我们对 OTel 探针做了以下增强来解决:

多协议支持

原理:默认情况下会自动按照 EagleEye、W3C、Skywalking、Zipkin、Jaeger、Skywalking 的顺序识别并恢复上游透传的 Trace 上下文。同样也支持按照用户需求配置优先或者强制使用某种协议。

优点:在客户多语言、内部不同部门使用多套 Tracing 系统、外部流量携带 Trace 上下文、上云迁移等场景下能尽量保证不断链。

调用链压缩

原理:ARMS 探针会将一些同一层级的重复 Span 压缩成一个,比如业务代码在一个 for 循环中,调用数据库应用 10000 次,那么在调用链中会生成 10000 个 Span,而经过调用链压缩后,仅会记录一个 Span,并在这个 Span 中记录重复 Span 的次数、最大耗时、最小耗时、总耗时等信息,效果如下图所示。

同时,为了避免尽可能保留重要信息。会将耗时 top3 和最开始报错的三个 Span 转换为 SpanEvent 保留在压缩后 Span 的 SpanEvent 中。优点:一方面可以避免极端场景下产生大量数据,客户 overhead 过高;另一方面避免 Span 过多场景下,后端查询缓慢、前端渲染卡顿、展示臃肿、客户排查问题难以抓住重点等问题。

缺点:因为仅保留了部分样本,无法看到全部的信息,可能导致丢失用户真正关注的数据。

采样

相比于其他产品单一的采样策略,ARMS 探针提供相对较为丰富的采样策略,且大多不需要用户进行复杂配置,每个采样策略保证特定场景下高价值 Tracing 数据被采样,低价值 Tracing 数据少采样,分别如下所示:

固定比例采样

即现有的默认采样,按照百分比采样链路。

自适应采样

自适应采样会按照 LFU 的策略选取当前调用量 top-1000 的接口,每个接口的采样彼此隔离,可设置两种采样策略,两种策略两种采样分别如下所示。

  • 每秒固定条数(默认):一秒采样 10 条。
  • 自适应比例:默认 10%,会根据该接口上一分钟请求量动态调整,避免大流量接口采样太多无效数据。

另外对于调用量 top-1000 以外的接口,可以认为是一个 other 接口。处理逻辑和前面介绍的 top-1000 中任 1 接口一致。

小流量采样

无需用户配置,自动保证每一个接口每一分钟至少有一个 Span。原理是用一个布隆过滤器存储一分钟内已经被采样过的接口。并每一分钟定期重置该布隆过滤器。这样可以保证无论用户接口有多发散,内存开销都是确定的。

错慢异常采样

无需用户配置,当一次调用满足下面三个条件时,则上报该次调用相关 Span。

  • 接口报错:http 类接口响应码非 2xx、3xx 或者本次调用的 localRootSpan 埋点方法处抛出异常。
  • 接口内部有异常:一次调用的非 LocalRootSpan 的 Span 记录到异常信息。
  • 接口调用耗时长的定义:接口耗时大于过去一段时间该接口的 p99 耗时。

该采样对于问题排查十分重要,但是因为时机问题,无法保证链路完整。比如接口 A 调用接口 B,A 命中错慢采样,并不能保证 B 接口的 Span 一定上报。

自定义采样

即用户自己配置 100% 采样接口、接口前缀、接口后缀等等。满足用户配置要求的调用会一定采样。

总结

上述各个采样策略会在一次调用中都生效,一个 Span 是否上报由上述采样策略综合决定,详细流程如下图所示:



其中不同颜色的采样策略区别在于:

  • 紫色:标准的头采样,只会在链路的 RootSpan 处触发,采样后可以保证后续链路完整。
  • 蓝色:只要当前的采样结果是不采样,可以在链路的任何一个 LocalRootSpan 处触发,采样后可以保证后续链路完整。
  • 绿色:只要当前的采样结果不采样,可以在链路的任何节点触发,采样后无法保证后续链路完整。

以一个常见的链路 A->B->C 为例说明,在不同节点命中不同采样规则时,对应会链路哪些 Span 会上报,哪些 Span 不上报。


Metrics 增强

更丰富的指标

1)线程池监控指标:针对常见 JDK 线程池,Jetty、Undertow 线程池监控,支持核心线程、最大线程、活跃线程、当前线程、历史最大线程、调度任务、完成任务、拒绝任务以及队列大小 9 类指标。便于排查线程池打满类问题。

2)线程监控指标:将当前 JVM 种所有线程归类后,统计不同类别线程的耗时以及处于不同状态线程的数量,并定时抓取线程栈,便于排查线程阻塞,线程耗时高等问题。



3)MQ 消费延迟指标:针对 MQ 类组件,出了常见的 RED 指标,增加消费延迟指标,便于排查消费延迟类问题。



4)数据库响应大小:针对 DB 类操作,增加请求、响应大小指标,便于排查大查询类问题。



5)新增异常类指标:指标主要为异常次数,维度记录了当前接口,便于排错异常类问题。



更多样的维度

1)接口类 RED 指标记录上游接口:方便查看接口到接口的调用拓扑、调用关系,方便接口异常时快速定位上下游。



2)数据库类调用指标。额外记录当前接口、数据库语句维度,方便接口出问题时,快速定位是否 db 的问题。db 出问题时,快速查询影响的接口,具体出问题的 sql 语句。

 

Profiling 能力支持

和阿里云 Dragonwell 团队合作,底层基于 async-profiler,提供 CP(Continuous Profiling)的能力。阿里云 Java Agent 提供的 CP 支持多种剖析类型,比如 CPU 热点剖析、堆内存热点剖析,墙钟热点剖析等。

特色能力介绍

除了常见的 CPU 热点剖析、内存热点剖析,ARMS 还针对慢调用链诊断场景,提供了代码热点产品能力,其是在开源 Async Profiler 墙钟能力的基础上,通过关联调用链中的 TraceId & SpanId 信息提供了调用链级别的 On & Off-CPU 火焰图,可有效对 Tracing 的监控盲区细节进行还原,帮助用户诊断各类常见的慢调用链问题,详情可参见文档[1]

那么,和客户自己用开源的 Async Profiler 生成火焰图相比有什么优势呢?

首先,支持常态化开启。开源的 Async Profiler 未提供支持常态化开启的数据存储与处理能力,难以在生产环境常态化开启,对于一些线上偶现的问题,难以使用其进行问题排查。

其次,运行环境覆盖面更广。开源的 Async Profiler 一些剖析类型对应用运行环境有一定要求,比如 Alpine Linux 基础镜像为了控制体积而去除了 JDK 调试符号(debug symbols)导致无法使用内存热点剖析功能,但是 ARMS 在其基础上通过针对特定版本的 Alpine Linux 基础镜像对应的 JDK 调试符内容做了预适配,对相关类型的环境,在不安装调试符的情况下,也可以使用内存热点。

最后,更好的稳定性。开源的 Async Profiler 常态化开启过程中可能会容易出现 Crash 问题比如 #694[2]或者多个剖析引擎(CPU 热点、内存热点等)同时启动,一个外部条件不满足引发的单引擎失败会导致整体失败,ARMS 在开源 Async Profiler 基础上做了一些 bugfix 和剖析引擎隔离优化,稳定性更好。

性能优化
在分析 OTel Java Agent 的过程中,我们发现它在创建 Span、记录指标等地方,对于 Attributes 有大量的重复 copy 以及排序操作,这些部分是占用整个探针 CPU 开销的大头,我们对这些操作进行了大量的优化,结果表明在 TPS4000 流量的测试场景下,aliyun-java-agent 探针相较开源版本 OTel Java 探针 CPU 性能表现更好,整体容器 CPU 开销水位大约降低 2%;内存性能表现上,在进行 2h 压测后容器申请的 RSS 内存,aliyun-java-agent 探针相较开源版本 OTel 探针的内存占用降低约 10MB。

问题诊断场景的增强

  • 集成代码级问题诊断利器 Arthas。无需依赖 JDK,一键开启、关闭。常见命令白屏化操作。且支持企业级鉴权、审计能力。避免任意用户随意执行 Arthas 命令。详情见 Arthas 诊断[3]
  • 内存 Dump。一键对指定机器执行内存 Dump,并配套白屏化分析能力。


云产品集成

  • 微服务治理。在同一个 Java Agent 中集成了阿里云 MSE 微服务治理能力,包括全链路灰度、限流降级、无损上下线,系统防护、消息灰度等。
  • 集成云安全中心应用安全 RASP。一键开启后拥有危险组件检测、25+ 种攻击行为[4]的监控,阻断的能力。


探针稳定性建设

由于 Java 探针和用户代码运行在一个进程中,且会对用户代码进行增强修改,Java 探针的稳定性建设尤为重要,多年的公有云用户服务经验告诉我们,对于一款可观测产品而言,我们的底线是不能影响业务行为,比如导致用户进程启动失败,用户进程 crash,用户接口报错,占用大量用户机器资源等等。为了最大程度的避免这类问题,并在出现这类问题时能够及时止血,我们在 OT 的基础上增加了下述能力。

  • 探针 CPU/内存占用上限控制能力:在探针 CPU 开销,内存占用超过指定阈值时,自动降级探针的 Tracing 或者 Metrics 数据采集能力。
  • 探针启动预检能力;因为探针本身有运行的环境要求,为了避免在非预期环境中出现异常行为,探针启动有若干检测项,比如 JVM 类型、JVM 版本、最大堆内存等等,最大程度的避免影响用户业务。
  • 探针功能可动态插拔能力:大部分探针功能,特别是可能影响用户业务的能力,都具备动态控制开关,可以在出现问题时快速关闭。

阿里云 Java Agent 4.0 探针带来了哪些好处

Cloud Native

从功能层面上来说,这次升级,完全吸纳了 OTel 的优秀设计,对我们现有的很多功能做了升级或者增强。

  • 遵循 JDBC 规范的数据库埋点从 JDBC 接口层面埋点,理论上支持所有遵循 JDBC 规范的数据库埋点(3.x 探针仅支持固定的 9 种)。
  • 异步埋点无需用户配置,不会断链。
  • vertx、webflux、lettuce、Rabbitmq、kafka、RocketMq、ONS 等插件相比老版本,因为埋点的位置优化,指标统计更准确,支持版本范围更广。
  • 支持容器场景的系统指标采集。
  • 线程池监控支持用户自定义线程池的监控。

从工程质量上来看来说,这次升级重构是对 3.x 代码的一次取其精华、去其糟粕的过程、是重新树立更合理科学的开发规范的过程,通过这次升级重构:4.0 探针的内存占用下降了 20%、线程数降低了 60%,探针包大小降低了 30%。

最后,从长远发展来看,我们制定了每三个月合并一次开源最新稳定代码的计划,可以快速的享受到社区快速迭代的红利。

我们为社区做了什么

Cloud Native

在基于 OTel Java Agent 二次开发的过程中,我们也积极的反哺开源,在过去 6 个月中,我们累计向社区贡献并合并各类 PR 40+,其中包含新增在国内广泛使用的 XXL-JOB、InfluxDB、MyBatis 等插件,参与社区日常 PR Review 100+,steverao[5]和 123liuziming[6]两位同事成为社区 member,其中 steverao 受邀作为该项目的 Triager 并且负责该社区的日常维护、代码 CR,且个人贡献长期位列社区前四名,贡献度积分位列社区 Top 20,亚太地区第一。

image.png

此外,我们也积极参与社区相关各类会议活动,今年 6 月,受社区邀请,在北美举行的 2024 OpenTelemetry Community Day 活动中,我们同事望陶和铖朴,为社区带来了《GraalVM 静态编译下 OTel Java Agent 的自动增强方案与实现》[7]主题分享,对相关问题的原创性解决方案得到了社区开发者的广泛关注。今年 8 月,在中国香港举行的 KubeCon China 2024 大会上,望陶和铖朴与社区其他开发者一起,在社区 Governance Committee 团队的支持下,代表社区在大会上做了《社区最新进展以及阿里云拥抱 OTel 社区实践》相关分享。

此外,为了促进亚太地区与社区的交流,在团队相关同学向社区提议,在与社区 Governance Committee Member 成员沟通后,OTel 社区也在多个领域,设立了亚太地区友好的周会交流时间。其中包含 Java: SDK + Instrumentation、Semantic Conventions: LLM、Contributor Experience 和 Developer Experience,相关时间可以参考社区周会安排[8],相关会议中有社区最资深的开发者一起参与,欢迎有兴趣的朋友加入。

目前,我们也正在将由阿里云开源的 Go Instrumentation[9]贡献到 OTel 社区,相关内容正在与社区相关 Governance Committee 和 Technical Committee 团队讨论中 #1961[10]

写在最后

Cloud Native

我们用了接近一年的时间完成了基于 OTel Java Agent 的升级重构,并于今年 5 月份发布了 4.x 探针的第一个版本 4.1.0,经过接近半年时间的验证、回归、优化,目前最新的稳定版本 4.1.12[11]已经正式发布,欢迎大家了解使用。

接下来的时间,一方面我们将持续的 Follow OTel Java Agent 的发版节奏,定期合并开源稳定代码,保障用户可以持续的享受社区最新的 feature;另一方面,我们也将重点打造阿里云 Java Agent 相比 OTel Java Agent 的差异化能力,补齐其不足与短板,帮助用户获得更全面、更透彻的应用可观测体验。

对 ARMS 有任何疑问,可搜索钉钉群号:31123480 加入 ARMS 沟通交流群。

相关链接:

[1] 文档https://help.aliyun.com/zh/arms/application-monitoring/user-guide/enable-continuous-profiling

[2] #694https://github.com/async-profiler/async-profiler/issues/694

[3] Arthas 诊断

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/arthas-diagnosis

[4] 25+ 种攻击行为https://help.aliyun.com/zh/arms/application-security/attacks-and-solutions

[5] steverao

https://github.com/steverao

[6] 123liuziming

https://github.com/123liuziming

[7] 《GraalVM 静态编译下 OTel Java Agent 的自动增强方案与实现》https://otelcommunitydayna24.sched.com/event/1d0AC/implement-auto-instrumentation-under-graalvm-static-compilation-on-otel-java-agent-zihao-rao-huxing-zhang-alibaba

[8] 社区周会安排

https://github.com/open-telemetry/community?tab=readme-ov-file#special-interest-groups

[9] Go Instrumentation

https://github.com/alibaba/opentelemetry-go-auto-instrumentation

[10] #1961

https://github.com/open-telemetry/community/issues/1961

[11] 4.1.12

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/versions-of-arms-agent-for-java

目录
打赏
0
0
0
0
1051
分享
相关文章
|
2月前
|
现代 Java IO 高性能实践从原理到落地的高效实现路径与实战指南
本文深入解析现代Java高性能IO实践,涵盖异步非阻塞IO、操作系统优化、大文件处理、响应式网络编程与数据库访问,结合Netty、Reactor等技术落地高并发应用,助力构建高效可扩展的IO系统。
61 0
Java List 集合结合 Java 17 新特性与现代开发实践的深度解析及实战指南 Java List 集合
本文深入解析Java 17中List集合的现代用法,结合函数式编程、Stream API、密封类、模式匹配等新特性,通过实操案例讲解数据处理、并行计算、响应式编程等场景下的高级应用,帮助开发者提升集合操作效率与代码质量。
120 1
|
2月前
|
Java 17 及以上版本核心特性在现代开发实践中的深度应用与高效实践方法 Java 开发实践
本项目以“学生成绩管理系统”为例,深入实践Java 17+核心特性与现代开发技术。采用Spring Boot 3.1、WebFlux、R2DBC等构建响应式应用,结合Record类、模式匹配、Stream优化等新特性提升代码质量。涵盖容器化部署(Docker)、自动化测试、性能优化及安全加固,全面展示Java最新技术在实际项目中的应用,助力开发者掌握现代化Java开发方法。
105 1
深度理解 Java 内存模型:从并发基石到实践应用
本文深入解析 Java 内存模型(JMM),涵盖其在并发编程中的核心作用与实践应用。内容包括 JMM 解决的可见性、原子性和有序性问题,线程与内存的交互机制,volatile、synchronized 和 happens-before 等关键机制的使用,以及在单例模式、线程通信等场景中的实战案例。同时,还介绍了常见并发 Bug 的排查与解决方案,帮助开发者写出高效、线程安全的 Java 程序。
133 0
Java 大视界 -- Java 大数据在智慧文旅旅游线路规划与游客流量均衡调控中的应用实践(196)
本实践案例深入探讨了Java大数据技术在智慧文旅中的创新应用,聚焦旅游线路规划与游客流量调控难题。通过整合多源数据、构建用户画像、开发个性化推荐算法及流量预测模型,实现了旅游线路的精准推荐与流量的科学调控。在某旅游城市的落地实践中,游客满意度显著提升,景区流量分布更加均衡,充分展现了Java大数据技术在推动文旅产业智能化升级中的核心价值与广阔前景。
Java 大视界 —— 基于 Java 的大数据隐私保护在金融客户信息管理中的实践与挑战(178)
本文探讨了基于 Java 的大数据隐私保护技术在金融客户信息管理中的应用与挑战。随着金融行业数字化转型加速,客户信息的安全性愈发重要。文章详细分析了数据加密、脱敏、访问控制、区块链及联邦学习等关键技术,并结合实际案例展示了其在金融机构中的应用效果,为金融科技从业者提供了宝贵的实践经验与技术参考。
Java 大视界 —— Java 大数据在智慧交通停车场智能管理与车位预测中的应用实践(174)
本文围绕 Java 大数据在智慧交通停车场智能管理与车位预测中的应用展开,深入剖析行业痛点,系统阐述大数据技术的应用架构,结合大型体育中心停车场案例,展示系统实施过程与显著成效,提供极具实操价值的技术方案。
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
630 41
分布式链路监控系统问题之系统拆分后链路追踪技术的问题如何解决
分布式链路监控系统问题之系统拆分后链路追踪技术的问题如何解决
136 0
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
1463 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问