Coroot × OpenTelemetry Java Agent零代码改造实现 Java 应用分布式追踪接入指南【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot本文以 Coroot 官方文档《OpenTelemetry for Java》为核心讲解如何用 OpenTelemetry Java Agent 以零代码改造的方式将 Spring Boot 应用的追踪数据含异常、数据库调用、跨服务 HTTP 调用与自定义 Span 属性/事件接入 Coroot。读完本文你将掌握完整的 Agent 挂载与环境变量配置方法、TraceContext 传播机制的原理并能结合 Coroot 源码理解 trace 数据从接收、批量落盘到 ClickHouse 的完整链路。为什么用 OpenTelemetry 为 Java 应用接入 CorootCoroot 的分布式追踪功能见 tracing/overview.md支持请求耗时分布 HeatMap、错误归因、属性对比与慢请求 FlameGraph 分析而这些能力的前提是应用能产生符合标准的 trace 数据。OpenTelemetry 是厂商中立的开源可观测性框架为 Java 等主流语言提供了 SDK 与工具链Coroot 官方将其定位为推荐的遥测数据采集标准并将 ClickHouse 作为 trace 数据的存储底座——低延迟查询、高效压缩与 SQL 分析能力正是其选择依据。对 Java 生态而言最大的价值在于 OpenTelemetry 提供了Java Agent字节码自动注入探针它能在 JVM 启动阶段自动探测并插桩主流应用服务器、HTTP 客户端与框架应用本身无需修改一行代码即可完成埋点。准备一个示例 Spring Boot 应用以下是一个最简单的 Spring Boot Web 应用提供一个按路径变量返回问候语的 GET 接口SpringBootApplication RestController public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } GetMapping(/hello/{name}) public String hello(PathVariable(value name) String name) { return String.format(Hello, %s!, name); } }OpenTelemetry 探针会为入站 HTTP 请求生成详细的 Server Span完整覆盖该请求从到达服务端到响应返回客户端的整个生命周期包括耗时、状态码、HTTP 方法、路径等属性。零代码改造挂载 OpenTelemetry Java Agent1. 下载 Agent从 OpenTelemetry Java Instrumentation 的官方 Release 页面下载最新版本的opentelemetry-javaagent.jar等价于执行wget该 release 地址下的 latest 产物。2. 通过环境变量配置并启动export \ OTEL_SERVICE_NAMEspring-demo \ OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://coroot.coroot:8080/v1/traces \ OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf \ OTEL_LOGS_EXPORTERnone \ OTEL_METRICS_EXPORTERnone \ java -javaagent:./opentelemetry-javaagent.jar -jar build/libs/demo-0.0.1-SNAPSHOT.jar各环境变量的作用与取值说明环境变量示例值说明OTEL_SERVICE_NAMEspring-demo服务名写入 Span 的service.name资源属性。在 Coroot 中它直接决定 trace 归属的应用/服务OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://coroot.coroot:8080/v1/tracestrace 上报地址。Coroot 的/v1/traces路由在 main.go 中注册coroot.coroot:8080是 Coroot 官方部署文档中的示例地址需替换为你环境中应用可访问的 Coroot 地址OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf采用 OTLP over HTTP protobuf 编码。Coroot 服务端仅接受application/x-protobuf见下文源码解析故必须用http/protobuf而非grpcOTEL_LOGS_EXPORTERnone本例不向 Coroot 上报日志Coroot 的日志入口为/v1/logsOTEL_METRICS_EXPORTERnone指标在 Coroot 体系中由 Prometheus 生态提供此处显式关闭补充一点多项目多租户场景下还需通过OTEL_EXPORTER_OTLP_HEADERSx-api-key你的API Key携带项目 API Key——Coroot 前端的 OpenTelemetry 集成向导OpenTelemetryIntegration.vue生成的配置模板即包含该字段API Key 可在项目设置页管理。3. 源码视角Coroot 如何接收这批 traceOTEL_EXPORTER_OTLP_TRACES_ENDPOINT指向的/v1/traces由 collector/traces.go 中的Traces处理器实现其关键行为与上表配置一一对应项目识别从X-API-Key请求头解析所属项目getProjectcollector/collector.go。若未携带 Key且实例中只有一个项目或存在名为default的项目会自动归入默认项目多项目且无 Key 时返回 404project not found协议校验Content-Type必须为application/x-protobuf否则直接返回 400这就是必须配置http/protobuf的原因解析入库将请求体反序列化为ExportTraceServiceRequest交给按项目隔离的TracesBatch累积。Coroot 同时支持 gRPC 通道collector/grpc.go 注册了 OTLP gRPC 的TraceServiceServer与LogsServiceServer对应grpc/端口下的标准 OTLP gRPC 端点便于已经部署 OpenTelemetry Collector 的用户直接转发。批量写入 ClickHouseTracesBatchcollector/traces.go维护一组列式缓冲区TraceId、SpanId、ParentSpanId、SpanName、SpanKind、ServiceName、SpanAttributes、Duration、StatusCode、事件与 Link 等单批上限batchLimit 10000行或超时batchTimeout 5s触发落盘collector/collector.go。落盘时通过 ch-go 将数据直接INSERT进otel_traces表collector/traces.go表结构迁移由 collector/migration.go 的migrateProject在启动时按项目自动完成。查询侧HeatMap、Span 列表、属性对比等则基于otel_traces、otel_traces_histogram、otel_traces_trace_id_ts等表实现见 clickhouse/traces.go。异常场景错误 Span 如何定位故障原因当接口抛出异常时只需让代码抛出ResponseStatusException即可探针会自动捕获GetMapping(/hello/{name}) public String hello(PathVariable(value name) String name) { throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR, Failure injection: HTTP-500); }结果 trace 中会出现两个标记为错误的 Span。错误详情通常记录在嵌套最深的失败 Span内——本例中即DemoApplication.hello这个 Span其StatusMessage中带有Failure injection: HTTP-500的原始信息无需翻日志即可定位该请求失败的直接原因。对应到存储层TracesBatch中专门有StatusCodeLowCardinality与StatusMessage两列承接 OTel Span 的 Statuscollector/traces.goCoroot 前端的错误归因与自动异常分析正是基于这些字段展开的。数据库调用Agent 自动捕获无需额外埋点在应用中注入一个 JPAUserRepository并增加一次按 ID 查库的逻辑SpringBootApplication RestController public class DemoApplication { Autowired private UserRepository userRepository; public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { OptionalUser user userRepository.findById(id); if (user.isEmpty()) { throw new ResponseStatusException(HttpStatus.NOT_FOUND, User not found); } return String.format(Hello, %s!, user.get().getName()); } }不需要任何额外 instrumentationOTel Java Agent 自动为每一条数据库调用生成 Client Span且数据库中查询的 SQL 语句会作为 Span 属性如db.statement被记录。下图 trace 中HTTP 请求下的 DB 调用清晰可见DB Span 的属性面板可以看到数据库系统、库名与具体 SQL 语句这为慢请求定位到具体 SQL 提供了直接证据。HTTP 调用与 TraceContext 跨服务传播若应用改为调用下游user服务获取用户信息GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { RestTemplate tpl new RestTemplate(); tpl.getMessageConverters().add(new MappingJackson2HttpMessageConverter()); User user tpl.getForObject(String.format(http://127.0.0.1:8082/user/%d, id), User.class); return String.format(Hello %s!, user.getName()); }结果 trace 中会包含下游user服务上报的 Span——两端都用 OpenTelemetry 插桩后整条调用链自动串成一条。跨服务的串联依靠 W3C TraceContext 头Agent 在客户端自动注入Traceparent下游服务读取该头继续同一 TraceID。发出到 user 服务的实际请求如下GET /user/1 HTTP/1.1 Host: 127.0.0.1 Connection: keep-alive User-agent: Java/17.0.1 Accept: application/json Traceparent: 00-d12946898a11d917a2fb6bd1ab054e0e-d55429431be788ff-01Traceparent格式为Version-TraceID-ParentSpanID-TraceFlags本例中d12946898a11d917a2fb6bd1ab054e0e是 TraceIDd55429431be788ff是发起调用的父 Span IDParentSpanId01表示采样标志位。下游服务据此将自身 Span 挂到同一 Trace 下Coroot 侧依靠ParentSpanId列还原调用树。进阶向 Span 添加自定义属性与事件自动探针覆盖了骨架而业务上下文如订单号、租户 ID需要手动补充。为此需向项目引入 OpenTelemetry SDK 依赖示例版本 1.26.0Gradledependencies { implementation io.opentelemetry:opentelemetry-sdk:1.26.0 }Mavenproject dependencyManagement dependencies dependency groupIdio.opentelemetry/groupId artifactIdopentelemetry-bom/artifactId version1.26.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdio.opentelemetry/groupId artifactIdopentelemetry-sdk/artifactId /dependency /dependencies /project然后获取当前 Span设置自定义属性或添加事件GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { Span span Span.current(); // set an attribute span.setAttribute(user.id, id); // add an event span.addEvent(the user profile has been loaded from the database); ... return String.format(Hello %s!, user.getName()); }这些内容会随该 Span 一起上报到 Coroot属性进入SpanAttributes映射列事件进入Events.Timestamp/Events.Name/Events.Attributes三个数组列collector/traces.go在 Span 详情中可直接查看。更关键的是自定义属性会被 Coroot 的属性对比与自动异常分析功能消费——例如某个特性开关打开时才出现的异常Coroot 能自动对比出选中区间请求与正常请求在自定义属性上的差异这类能力对任何自定义属性均生效无需额外配置。已部署 OpenTelemetry Collector 的场景如果应用或 Collector 已在向其他后端发送 trace不必改动应用只需在 Collector 中追加一个指向 Coroot 的 OTLP HTTP exporter该配置模板同样由 OpenTelemetryIntegration.vue 提供receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: exporters: otlphttp/coroot: endpoint: http://coroot-url encoding: proto headers: x-api-key: 你的API Key service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/coroot]Coroot 侧无需任何额外配置trace 表由迁移逻辑自动创建collector/migration.go数据以 1 万行/5 秒的批量窗口持续写入。小结零代码改造-javaagent:./opentelemetry-javaagent.jar一个启动参数即可完成 HTTP Server/Client、数据库调用等全部自动插桩异常信息也会自动进入 Span 状态配置三要素OTEL_SERVICE_NAME定服务、OTEL_EXPORTER_OTLP_TRACES_ENDPOINTcoroot/v1/traces定地址、OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf定协议Coroot 服务端强制application/x-protobuf多租户下加x-api-key头跨服务串联由 W3CTraceparent头Version-TraceID-ParentSpanID-TraceFlags自动完成业务上下文通过引入opentelemetry-sdk依赖后用Span.current()手动补属性与事件并可被 Coroot 的属性对比、错误归因等自动化分析直接利用存储链路OTLP 请求 →/v1/tracesHTTP 处理器或 gRPC 通道→ 每项目独立的TracesBatch10000 行/5 秒批量→ ClickHouseotel_traces表为上层 HeatMap、错误分析、延迟 FlameGraph 提供数据基础。参考文档OpenTelemetry for Java、Tracing Overview、ebpf-based-tracing无需 SDK 的 eBPF 替代方案适合不便改启动参数的场景。【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Coroot × OpenTelemetry Java Agent：零代码改造实现 Java 应用分布式追踪接入指南
Coroot × OpenTelemetry Java Agent零代码改造实现 Java 应用分布式追踪接入指南【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot本文以 Coroot 官方文档《OpenTelemetry for Java》为核心讲解如何用 OpenTelemetry Java Agent 以零代码改造的方式将 Spring Boot 应用的追踪数据含异常、数据库调用、跨服务 HTTP 调用与自定义 Span 属性/事件接入 Coroot。读完本文你将掌握完整的 Agent 挂载与环境变量配置方法、TraceContext 传播机制的原理并能结合 Coroot 源码理解 trace 数据从接收、批量落盘到 ClickHouse 的完整链路。为什么用 OpenTelemetry 为 Java 应用接入 CorootCoroot 的分布式追踪功能见 tracing/overview.md支持请求耗时分布 HeatMap、错误归因、属性对比与慢请求 FlameGraph 分析而这些能力的前提是应用能产生符合标准的 trace 数据。OpenTelemetry 是厂商中立的开源可观测性框架为 Java 等主流语言提供了 SDK 与工具链Coroot 官方将其定位为推荐的遥测数据采集标准并将 ClickHouse 作为 trace 数据的存储底座——低延迟查询、高效压缩与 SQL 分析能力正是其选择依据。对 Java 生态而言最大的价值在于 OpenTelemetry 提供了Java Agent字节码自动注入探针它能在 JVM 启动阶段自动探测并插桩主流应用服务器、HTTP 客户端与框架应用本身无需修改一行代码即可完成埋点。准备一个示例 Spring Boot 应用以下是一个最简单的 Spring Boot Web 应用提供一个按路径变量返回问候语的 GET 接口SpringBootApplication RestController public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } GetMapping(/hello/{name}) public String hello(PathVariable(value name) String name) { return String.format(Hello, %s!, name); } }OpenTelemetry 探针会为入站 HTTP 请求生成详细的 Server Span完整覆盖该请求从到达服务端到响应返回客户端的整个生命周期包括耗时、状态码、HTTP 方法、路径等属性。零代码改造挂载 OpenTelemetry Java Agent1. 下载 Agent从 OpenTelemetry Java Instrumentation 的官方 Release 页面下载最新版本的opentelemetry-javaagent.jar等价于执行wget该 release 地址下的 latest 产物。2. 通过环境变量配置并启动export \ OTEL_SERVICE_NAMEspring-demo \ OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://coroot.coroot:8080/v1/traces \ OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf \ OTEL_LOGS_EXPORTERnone \ OTEL_METRICS_EXPORTERnone \ java -javaagent:./opentelemetry-javaagent.jar -jar build/libs/demo-0.0.1-SNAPSHOT.jar各环境变量的作用与取值说明环境变量示例值说明OTEL_SERVICE_NAMEspring-demo服务名写入 Span 的service.name资源属性。在 Coroot 中它直接决定 trace 归属的应用/服务OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://coroot.coroot:8080/v1/tracestrace 上报地址。Coroot 的/v1/traces路由在 main.go 中注册coroot.coroot:8080是 Coroot 官方部署文档中的示例地址需替换为你环境中应用可访问的 Coroot 地址OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf采用 OTLP over HTTP protobuf 编码。Coroot 服务端仅接受application/x-protobuf见下文源码解析故必须用http/protobuf而非grpcOTEL_LOGS_EXPORTERnone本例不向 Coroot 上报日志Coroot 的日志入口为/v1/logsOTEL_METRICS_EXPORTERnone指标在 Coroot 体系中由 Prometheus 生态提供此处显式关闭补充一点多项目多租户场景下还需通过OTEL_EXPORTER_OTLP_HEADERSx-api-key你的API Key携带项目 API Key——Coroot 前端的 OpenTelemetry 集成向导OpenTelemetryIntegration.vue生成的配置模板即包含该字段API Key 可在项目设置页管理。3. 源码视角Coroot 如何接收这批 traceOTEL_EXPORTER_OTLP_TRACES_ENDPOINT指向的/v1/traces由 collector/traces.go 中的Traces处理器实现其关键行为与上表配置一一对应项目识别从X-API-Key请求头解析所属项目getProjectcollector/collector.go。若未携带 Key且实例中只有一个项目或存在名为default的项目会自动归入默认项目多项目且无 Key 时返回 404project not found协议校验Content-Type必须为application/x-protobuf否则直接返回 400这就是必须配置http/protobuf的原因解析入库将请求体反序列化为ExportTraceServiceRequest交给按项目隔离的TracesBatch累积。Coroot 同时支持 gRPC 通道collector/grpc.go 注册了 OTLP gRPC 的TraceServiceServer与LogsServiceServer对应grpc/端口下的标准 OTLP gRPC 端点便于已经部署 OpenTelemetry Collector 的用户直接转发。批量写入 ClickHouseTracesBatchcollector/traces.go维护一组列式缓冲区TraceId、SpanId、ParentSpanId、SpanName、SpanKind、ServiceName、SpanAttributes、Duration、StatusCode、事件与 Link 等单批上限batchLimit 10000行或超时batchTimeout 5s触发落盘collector/collector.go。落盘时通过 ch-go 将数据直接INSERT进otel_traces表collector/traces.go表结构迁移由 collector/migration.go 的migrateProject在启动时按项目自动完成。查询侧HeatMap、Span 列表、属性对比等则基于otel_traces、otel_traces_histogram、otel_traces_trace_id_ts等表实现见 clickhouse/traces.go。异常场景错误 Span 如何定位故障原因当接口抛出异常时只需让代码抛出ResponseStatusException即可探针会自动捕获GetMapping(/hello/{name}) public String hello(PathVariable(value name) String name) { throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR, Failure injection: HTTP-500); }结果 trace 中会出现两个标记为错误的 Span。错误详情通常记录在嵌套最深的失败 Span内——本例中即DemoApplication.hello这个 Span其StatusMessage中带有Failure injection: HTTP-500的原始信息无需翻日志即可定位该请求失败的直接原因。对应到存储层TracesBatch中专门有StatusCodeLowCardinality与StatusMessage两列承接 OTel Span 的 Statuscollector/traces.goCoroot 前端的错误归因与自动异常分析正是基于这些字段展开的。数据库调用Agent 自动捕获无需额外埋点在应用中注入一个 JPAUserRepository并增加一次按 ID 查库的逻辑SpringBootApplication RestController public class DemoApplication { Autowired private UserRepository userRepository; public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { OptionalUser user userRepository.findById(id); if (user.isEmpty()) { throw new ResponseStatusException(HttpStatus.NOT_FOUND, User not found); } return String.format(Hello, %s!, user.get().getName()); } }不需要任何额外 instrumentationOTel Java Agent 自动为每一条数据库调用生成 Client Span且数据库中查询的 SQL 语句会作为 Span 属性如db.statement被记录。下图 trace 中HTTP 请求下的 DB 调用清晰可见DB Span 的属性面板可以看到数据库系统、库名与具体 SQL 语句这为慢请求定位到具体 SQL 提供了直接证据。HTTP 调用与 TraceContext 跨服务传播若应用改为调用下游user服务获取用户信息GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { RestTemplate tpl new RestTemplate(); tpl.getMessageConverters().add(new MappingJackson2HttpMessageConverter()); User user tpl.getForObject(String.format(http://127.0.0.1:8082/user/%d, id), User.class); return String.format(Hello %s!, user.getName()); }结果 trace 中会包含下游user服务上报的 Span——两端都用 OpenTelemetry 插桩后整条调用链自动串成一条。跨服务的串联依靠 W3C TraceContext 头Agent 在客户端自动注入Traceparent下游服务读取该头继续同一 TraceID。发出到 user 服务的实际请求如下GET /user/1 HTTP/1.1 Host: 127.0.0.1 Connection: keep-alive User-agent: Java/17.0.1 Accept: application/json Traceparent: 00-d12946898a11d917a2fb6bd1ab054e0e-d55429431be788ff-01Traceparent格式为Version-TraceID-ParentSpanID-TraceFlags本例中d12946898a11d917a2fb6bd1ab054e0e是 TraceIDd55429431be788ff是发起调用的父 Span IDParentSpanId01表示采样标志位。下游服务据此将自身 Span 挂到同一 Trace 下Coroot 侧依靠ParentSpanId列还原调用树。进阶向 Span 添加自定义属性与事件自动探针覆盖了骨架而业务上下文如订单号、租户 ID需要手动补充。为此需向项目引入 OpenTelemetry SDK 依赖示例版本 1.26.0Gradledependencies { implementation io.opentelemetry:opentelemetry-sdk:1.26.0 }Mavenproject dependencyManagement dependencies dependency groupIdio.opentelemetry/groupId artifactIdopentelemetry-bom/artifactId version1.26.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdio.opentelemetry/groupId artifactIdopentelemetry-sdk/artifactId /dependency /dependencies /project然后获取当前 Span设置自定义属性或添加事件GetMapping(/hello/{id}) public String hello(PathVariable(value id) Integer id) { Span span Span.current(); // set an attribute span.setAttribute(user.id, id); // add an event span.addEvent(the user profile has been loaded from the database); ... return String.format(Hello %s!, user.getName()); }这些内容会随该 Span 一起上报到 Coroot属性进入SpanAttributes映射列事件进入Events.Timestamp/Events.Name/Events.Attributes三个数组列collector/traces.go在 Span 详情中可直接查看。更关键的是自定义属性会被 Coroot 的属性对比与自动异常分析功能消费——例如某个特性开关打开时才出现的异常Coroot 能自动对比出选中区间请求与正常请求在自定义属性上的差异这类能力对任何自定义属性均生效无需额外配置。已部署 OpenTelemetry Collector 的场景如果应用或 Collector 已在向其他后端发送 trace不必改动应用只需在 Collector 中追加一个指向 Coroot 的 OTLP HTTP exporter该配置模板同样由 OpenTelemetryIntegration.vue 提供receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: batch: exporters: otlphttp/coroot: endpoint: http://coroot-url encoding: proto headers: x-api-key: 你的API Key service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlphttp/coroot]Coroot 侧无需任何额外配置trace 表由迁移逻辑自动创建collector/migration.go数据以 1 万行/5 秒的批量窗口持续写入。小结零代码改造-javaagent:./opentelemetry-javaagent.jar一个启动参数即可完成 HTTP Server/Client、数据库调用等全部自动插桩异常信息也会自动进入 Span 状态配置三要素OTEL_SERVICE_NAME定服务、OTEL_EXPORTER_OTLP_TRACES_ENDPOINTcoroot/v1/traces定地址、OTEL_EXPORTER_OTLP_TRACES_PROTOCOLhttp/protobuf定协议Coroot 服务端强制application/x-protobuf多租户下加x-api-key头跨服务串联由 W3CTraceparent头Version-TraceID-ParentSpanID-TraceFlags自动完成业务上下文通过引入opentelemetry-sdk依赖后用Span.current()手动补属性与事件并可被 Coroot 的属性对比、错误归因等自动化分析直接利用存储链路OTLP 请求 →/v1/tracesHTTP 处理器或 gRPC 通道→ 每项目独立的TracesBatch10000 行/5 秒批量→ ClickHouseotel_traces表为上层 HeatMap、错误分析、延迟 FlameGraph 提供数据基础。参考文档OpenTelemetry for Java、Tracing Overview、ebpf-based-tracing无需 SDK 的 eBPF 替代方案适合不便改启动参数的场景。【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考