2026/9/12 16:11:18
FEATURED · 精选文章 
Jaegerjaeger_storage_exporter实战指南将 OTel Collector 管道无缝写入 Jaeger 原生存储【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaegerjaeger_storage_exporter是 Jaeger v2基于 OpenTelemetry Collector 架构内置的一个 traces 导出器组件它把 Collector 管道中的 span 数据写入 Jaeger 原生存储后端。本文以 cmd/jaeger/internal/exporters/storageexporter/README.md 为骨架结合该组件的 config.go、exporter.go、factory.go 以及配套测试与真实配置系统讲解其设计原理、配置方法与源码实现。读完本文你将掌握如何配置该导出器、如何为其启用重试与批量队列、如何在 all-in-one 部署中接线内存存储以及它在多 exporter 场景下的行为细节。一、组件定位与设计原理1.1 它是做什么的从 README 的第一句话即可确认其定位该模块实现exporter.Traces将 span 写入 Jaeger 原生spanstore.SpanWriter而写入器来源于 jaeger_storage 扩展。其核心价值在于把内存存储memory storage接入导出器管道这正是 all-in-one 部署模式的基石同时其设计决定了它可以对接任何 Jaeger V1 存储实现Cassandra、Elasticsearch/OpenSearch、ClickHouse、Badger 等只要这些后端通过jaeger_storage扩展暴露为命名存储即可。从源码结构看导出器实际依赖的是 v2 存储抽象层的tracestore.Writer接口exporter.go而jaeger_storage扩展通过TraceStorageFactory(name)按名字返回tracestore.Factory两者通过命名约定解耦。这意味着“导出器”与“存储实现”之间不直接耦合新增后端无需改动导出器代码。1.2 在 all-in-one 中的典型位置在 Jaeger v2 的官方 all-in-one 配置 cmd/jaeger/internal/all-in-one.yaml 中traces 管道这样接线service: pipelines: traces: receivers: [otlp, jaeger, zipkin] processors: [batch] exporters: [jaeger_storage_exporter] extensions: jaeger_storage: backends: some_storage: memory: max_traces: 100000 exporters: jaeger_storage_exporter: trace_storage: some_storage可见其工作流为otlp / jaeger / zipkin接收器 →batch处理器 →jaeger_storage_exporter→ 由jaeger_storage扩展创建的命名存储。jaeger_query扩展则从同一存储读取数据供 UI 查询因此一个 all-in-one 进程内即可完成“采集 — 写入 — 查询”闭环。二、基本配置trace_storage与存储后端2.1 最小可运行配置README 给出的基本配置是exporters: jaeger_storage_exporter: trace_storage: memstore extensions: jaeger_storage: memory: memstore: max_traces: 100000其中exporters.jaeger_storage_exporter.trace_storage必填项指定要写入的存储后端名字该名字必须与extensions.jaeger_storage中声明的后端名一致extensions.jaeger_storage.memory.name.max_traces内存存储的容量上限最大 trace 条数。all-in-one 配置中默认max_traces: 100000。注意 README 示例中jaeger_storage扩展的写法memory直接作为顶层键是旧式写法而当前仓库的 all-in-one 配置已演进为backends嵌套形式两种形式在 YAML 上对应同一份存储配置结构实际以你所使用版本支持的 schema 为准。2.2trace_storage的必填校验从 config.go 可以看到Config结构与校验逻辑type Config struct { TraceStorage string mapstructure:trace_storage valid:required QueueConfig configoptional.Optional[exporterhelper.QueueBatchConfig] mapstructure:queue valid:optional RetryConfig configretry.BackOffConfig mapstructure:retry_on_failure } func (cfg *Config) Validate() error { _, err : govalidator.ValidateStruct(cfg) return err }关键点trace_storage带有valid:required标签通过govalidator强制必填若留空启动时校验会直接失败。测试 factory_test.go 中的TestConfig_Validate明确覆盖了这一行为missing trace storage场景断言报错若trace_storage指定的名字在jaeger_storage扩展中未声明导出器start阶段会返回cannot find storage factory错误见 exporter_test.go 的TestExporterStartBadNameError。三、重试配置retry_on_failure3.1 默认值该导出器支持为导出失败配置可调的重试行为默认关闭重试。默认配置项如下与 README 完全一致配置项默认值说明enabledfalse默认禁用重试initial_interval5s首次重试前的等待间隔randomization_factor0.5退避间隔的随机化因子防惊群multiplier1.5每次重试间隔的乘法递增系数max_interval30s重试间隔上限max_elapsed_time5m总重试时间上限超过即放弃这些默认值来自 factory.gofunc createDefaultConfig() component.Config { cfg : configretry.NewDefaultBackOffConfig() cfg.Enabled false return Config{ RetryConfig: cfg, } }createDefaultConfig先取 OpenTelemetry Collector 的标准configretry.NewDefaultBackOffConfig()即上表默认值随后显式将Enabled置为false保证默认不重试。这与仓库 factory_test.go 中Retry should be disabled by default的断言相互印证。3.2 启用并自定义重试exporters: jaeger_storage_exporter: trace_storage: memstore retry_on_failure: enabled: true # 显式开启重试 initial_interval: 10s max_interval: 1m max_elapsed_time: 10m说明只需设置enabled: true即可启用未覆盖的项沿用默认值重试的接入点位于 factory.go 的exporterhelper.WithRetry(cfg.RetryConfig)测试 factory_test.go 演示了自定义initial_interval10s、randomization_factor0.7、multiplier2.0、max_interval60s、max_elapsed_time10m的完整配置形态。3.3 重试与幂等写入值得注意的一个实现细节当后端存储声明了同步批量写入tracestore.SyncBulkWriteConfig且启用字节上限时若 exporter 的queue.batch.max_size配置不当写入方会把超大批次拆分为多个_bulk子请求。拆分后的子请求如果失败整个批次会被重试——由于 span 携带确定性_id幂等 upsert重发不会产生重复数据只是效率略低。这一逻辑在 exporter.go 的warnMisalignedSyncBatchSizing中实现仅在字节计数的批量配置与存储字节上限不对齐时输出告警而不会阻断启动对应测试 exporter_test.go 的TestExporterStartWarnsButSucceedsOnMisalignedSyncBatch。四、队列与批量配置queue4.1 配置示例exporters: jaeger_storage_exporter: trace_storage: memstore queue: enabled: true num_consumers: 10 queue_size: 1000queue段复用 OpenTelemetry Collector 的exporterhelper.QueueBatchConfig结构见 config.go常用的子项包括enabled是否启用发送队列num_consumers并行消费队列的消费者数量示例为 10queue_size队列缓冲的批次数示例为 1000batch.max_size/batch.sizer单批次大小上限与计量方式按条数items或按字节bytes。4.2 与批量大小的配合当batch.sizer: bytes且存储为同步字节上限写入模式时应保证batch.max_size不超过存储的bulk_processing.max_bytes以便一个批次对应一次批量写请求。若max_size为 0无界或大于存储上限启动时日志会出现类似警告exporter.goqueue.batch.max_size is not aligned with the storages bulk_processing.max_bytes; ...告警仅提示效率问题不影响正确性若你不需要字节级批量控制保持默认按条数计数即可跳过该检查。该分支逻辑由 exporter_test.go 的TestWarnMisalignedSyncBatchSizing表驱动测试完整覆盖含“非同步工厂跳过、异步工厂跳过、零上限跳过、无队列跳过、无 batch 跳过、条数批量跳过、字节批量在限内不告警、超限/无界告警”共 8 种场景。五、源码实现纵深导出器如何工作5.1 工厂与生命周期factory.go 定义组件类型jaeger_storage_exporter并通过exporter.NewFactory注册var componentType component.MustNewType(jaeger_storage_exporter) func NewFactory() exporter.Factory { return exporter.NewFactory( componentType, createDefaultConfig, exporter.WithTraces(createTracesExporter, component.StabilityLevelDevelopment), ) }createTracesExporter组装导出器时做了几件重要的事exporterhelper.WithCapabilities(consumer.Capabilities{MutatesData: false})声明不修改数据exporterhelper.WithTimeout(exporterhelper.TimeoutConfig{Timeout: 0})显式禁用超时避免长尾写入被超时打断WithRetry(cfg.RetryConfig)/WithQueue(cfg.QueueConfig)接入重试与队列WithStart(ex.start)/WithShutdown(ex.close)注册启动与关闭钩子。5.2 启动时获取存储工厂exporter.go 的start方法在启动阶段完成存储接线func (exp *storageExporter) start(_ context.Context, host component.Host) error { f, err : jaegerstorage.GetTraceStoreFactory(exp.config.TraceStorage, host) if err ! nil { return fmt.Errorf(cannot find storage factory: %w, err) } exp.warnMisalignedSyncBatchSizing(f) if exp.traceWriter, err f.CreateTraceWriter(); err ! nil { return fmt.Errorf(cannot create trace writer: %w, err) } return nil }调用链为GetTraceStoreFactory(name, host)→ 从 Host 的扩展列表中定位jaeger_storage扩展extension.go 的findExtension→ 调用TraceStorageFactory(name)按名字惰性创建/缓存工厂 →CreateTraceWriter()得到写入器。若name未声明或扩展缺失分别返回storage ... not declared ...与cannot find extension ... (make sure its defined earlier in the config)错误——后者提示了扩展在配置中必须位于引用它的组件之前这一约束。5.3 数据面写入前先消毒pushTraces是真正的数据入口exporter.gofunc (exp *storageExporter) pushTraces(ctx context.Context, td ptrace.Traces) error { return exp.traceWriter.WriteTraces(ctx, exp.sanitizer(td)) }每次写入前都会经过sanitizer.Sanitize来自 internal/jptrace/sanitizer它负责补齐/修正不规范的 span 数据典型行为包括为空的服务名填充missing-service-name、空 span 名、负持续时间、非法 UTF-8 等。端到端测试 exporter_test.go 验证了写入后从存储读回的资源属性中确实带上了service.name missing-service-name。5.4 关闭钩子与只读数据close方法为空实现注释明确说明“span writer is not closable”——存储的生命周期由jaeger_storage扩展统一管理其Shutdown会关闭所有已创建的工厂见 extension.go测试 exporter_test.go 的TestExporterWithReadOnlyTraces专门验证了当存在多个 exporter 时 trace 数据被标记为只读MarkReadOnly的情况下本导出器不会 panic 且写入正常——这得益于MutatesData: false的声明与消毒器的只读安全实现。六、端到端验证测试如何证明它可用仓库自带的集成级单元测试exporter_test.go走完了完整闭环创建真实的内存存储扩展jaeger_storagememory.Configuration{MaxTraces: 10000}→ 用NewFactory()创建导出器 →Start→ 构造一个带特定traceID/spanID的 span →ConsumeTraces写入 → 再通过CreateTraceReader().GetTraces读回并断言 spanID 与消毒后的服务名。这说明该导出器不依赖任何外部服务即可独立验证内存存储即可“写入即可读回”证明它与jaeger_storage扩展的接线是完整可用的消毒器在真实写入路径上生效。如果你想在本地复现只需运行go test ./cmd/jaeger/internal/exporters/storageexporter/...。七、实践要点小结必填项trace_storage必须指定且与extensions.jaeger_storage中声明的后端名一致否则启动校验或start阶段报错重试默认关闭如需开启动态退避重试显式设置retry_on_failure.enabled: true并按需覆盖间隔、倍率与总时长队列可调queue支持并发消费者数、队列深度与批次大小字节计数的批量大小应与存储的bulk_processing.max_bytes对齐避免不必要的拆分与重写声明不改数据组件标记为MutatesData: false可安全用于多 exporter 并存的管道只读 trace 也不会导致 panic消毒在前所有写入数据先经sanitizer.Sanitize规范化空服务名、负时长等脏数据在落库前被修正生命周期归属导出器自身不持有存储资源关闭时不做额外清理存储由jaeger_storage扩展统一管理。jaeger_storage_exporter虽小却是 Jaeger v2 “采集即存储”架构中承上启下的关键一环它让任意 OTel Collector 管道能以统一方式写入 Jaeger 原生存储也让 all-in-one 模式得以用内存后端零依赖启动。理解它的配置面与实现细节是排查写入失败、调优批量效率、规划自托管 Jaeger 部署的基础。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jaeger `jaeger_storage_exporter` 实战指南：将 OTel Collector 管道无缝写入 Jaeger 原生存储
Jaegerjaeger_storage_exporter实战指南将 OTel Collector 管道无缝写入 Jaeger 原生存储【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaegerjaeger_storage_exporter是 Jaeger v2基于 OpenTelemetry Collector 架构内置的一个 traces 导出器组件它把 Collector 管道中的 span 数据写入 Jaeger 原生存储后端。本文以 cmd/jaeger/internal/exporters/storageexporter/README.md 为骨架结合该组件的 config.go、exporter.go、factory.go 以及配套测试与真实配置系统讲解其设计原理、配置方法与源码实现。读完本文你将掌握如何配置该导出器、如何为其启用重试与批量队列、如何在 all-in-one 部署中接线内存存储以及它在多 exporter 场景下的行为细节。一、组件定位与设计原理1.1 它是做什么的从 README 的第一句话即可确认其定位该模块实现exporter.Traces将 span 写入 Jaeger 原生spanstore.SpanWriter而写入器来源于 jaeger_storage 扩展。其核心价值在于把内存存储memory storage接入导出器管道这正是 all-in-one 部署模式的基石同时其设计决定了它可以对接任何 Jaeger V1 存储实现Cassandra、Elasticsearch/OpenSearch、ClickHouse、Badger 等只要这些后端通过jaeger_storage扩展暴露为命名存储即可。从源码结构看导出器实际依赖的是 v2 存储抽象层的tracestore.Writer接口exporter.go而jaeger_storage扩展通过TraceStorageFactory(name)按名字返回tracestore.Factory两者通过命名约定解耦。这意味着“导出器”与“存储实现”之间不直接耦合新增后端无需改动导出器代码。1.2 在 all-in-one 中的典型位置在 Jaeger v2 的官方 all-in-one 配置 cmd/jaeger/internal/all-in-one.yaml 中traces 管道这样接线service: pipelines: traces: receivers: [otlp, jaeger, zipkin] processors: [batch] exporters: [jaeger_storage_exporter] extensions: jaeger_storage: backends: some_storage: memory: max_traces: 100000 exporters: jaeger_storage_exporter: trace_storage: some_storage可见其工作流为otlp / jaeger / zipkin接收器 →batch处理器 →jaeger_storage_exporter→ 由jaeger_storage扩展创建的命名存储。jaeger_query扩展则从同一存储读取数据供 UI 查询因此一个 all-in-one 进程内即可完成“采集 — 写入 — 查询”闭环。二、基本配置trace_storage与存储后端2.1 最小可运行配置README 给出的基本配置是exporters: jaeger_storage_exporter: trace_storage: memstore extensions: jaeger_storage: memory: memstore: max_traces: 100000其中exporters.jaeger_storage_exporter.trace_storage必填项指定要写入的存储后端名字该名字必须与extensions.jaeger_storage中声明的后端名一致extensions.jaeger_storage.memory.name.max_traces内存存储的容量上限最大 trace 条数。all-in-one 配置中默认max_traces: 100000。注意 README 示例中jaeger_storage扩展的写法memory直接作为顶层键是旧式写法而当前仓库的 all-in-one 配置已演进为backends嵌套形式两种形式在 YAML 上对应同一份存储配置结构实际以你所使用版本支持的 schema 为准。2.2trace_storage的必填校验从 config.go 可以看到Config结构与校验逻辑type Config struct { TraceStorage string mapstructure:trace_storage valid:required QueueConfig configoptional.Optional[exporterhelper.QueueBatchConfig] mapstructure:queue valid:optional RetryConfig configretry.BackOffConfig mapstructure:retry_on_failure } func (cfg *Config) Validate() error { _, err : govalidator.ValidateStruct(cfg) return err }关键点trace_storage带有valid:required标签通过govalidator强制必填若留空启动时校验会直接失败。测试 factory_test.go 中的TestConfig_Validate明确覆盖了这一行为missing trace storage场景断言报错若trace_storage指定的名字在jaeger_storage扩展中未声明导出器start阶段会返回cannot find storage factory错误见 exporter_test.go 的TestExporterStartBadNameError。三、重试配置retry_on_failure3.1 默认值该导出器支持为导出失败配置可调的重试行为默认关闭重试。默认配置项如下与 README 完全一致配置项默认值说明enabledfalse默认禁用重试initial_interval5s首次重试前的等待间隔randomization_factor0.5退避间隔的随机化因子防惊群multiplier1.5每次重试间隔的乘法递增系数max_interval30s重试间隔上限max_elapsed_time5m总重试时间上限超过即放弃这些默认值来自 factory.gofunc createDefaultConfig() component.Config { cfg : configretry.NewDefaultBackOffConfig() cfg.Enabled false return Config{ RetryConfig: cfg, } }createDefaultConfig先取 OpenTelemetry Collector 的标准configretry.NewDefaultBackOffConfig()即上表默认值随后显式将Enabled置为false保证默认不重试。这与仓库 factory_test.go 中Retry should be disabled by default的断言相互印证。3.2 启用并自定义重试exporters: jaeger_storage_exporter: trace_storage: memstore retry_on_failure: enabled: true # 显式开启重试 initial_interval: 10s max_interval: 1m max_elapsed_time: 10m说明只需设置enabled: true即可启用未覆盖的项沿用默认值重试的接入点位于 factory.go 的exporterhelper.WithRetry(cfg.RetryConfig)测试 factory_test.go 演示了自定义initial_interval10s、randomization_factor0.7、multiplier2.0、max_interval60s、max_elapsed_time10m的完整配置形态。3.3 重试与幂等写入值得注意的一个实现细节当后端存储声明了同步批量写入tracestore.SyncBulkWriteConfig且启用字节上限时若 exporter 的queue.batch.max_size配置不当写入方会把超大批次拆分为多个_bulk子请求。拆分后的子请求如果失败整个批次会被重试——由于 span 携带确定性_id幂等 upsert重发不会产生重复数据只是效率略低。这一逻辑在 exporter.go 的warnMisalignedSyncBatchSizing中实现仅在字节计数的批量配置与存储字节上限不对齐时输出告警而不会阻断启动对应测试 exporter_test.go 的TestExporterStartWarnsButSucceedsOnMisalignedSyncBatch。四、队列与批量配置queue4.1 配置示例exporters: jaeger_storage_exporter: trace_storage: memstore queue: enabled: true num_consumers: 10 queue_size: 1000queue段复用 OpenTelemetry Collector 的exporterhelper.QueueBatchConfig结构见 config.go常用的子项包括enabled是否启用发送队列num_consumers并行消费队列的消费者数量示例为 10queue_size队列缓冲的批次数示例为 1000batch.max_size/batch.sizer单批次大小上限与计量方式按条数items或按字节bytes。4.2 与批量大小的配合当batch.sizer: bytes且存储为同步字节上限写入模式时应保证batch.max_size不超过存储的bulk_processing.max_bytes以便一个批次对应一次批量写请求。若max_size为 0无界或大于存储上限启动时日志会出现类似警告exporter.goqueue.batch.max_size is not aligned with the storages bulk_processing.max_bytes; ...告警仅提示效率问题不影响正确性若你不需要字节级批量控制保持默认按条数计数即可跳过该检查。该分支逻辑由 exporter_test.go 的TestWarnMisalignedSyncBatchSizing表驱动测试完整覆盖含“非同步工厂跳过、异步工厂跳过、零上限跳过、无队列跳过、无 batch 跳过、条数批量跳过、字节批量在限内不告警、超限/无界告警”共 8 种场景。五、源码实现纵深导出器如何工作5.1 工厂与生命周期factory.go 定义组件类型jaeger_storage_exporter并通过exporter.NewFactory注册var componentType component.MustNewType(jaeger_storage_exporter) func NewFactory() exporter.Factory { return exporter.NewFactory( componentType, createDefaultConfig, exporter.WithTraces(createTracesExporter, component.StabilityLevelDevelopment), ) }createTracesExporter组装导出器时做了几件重要的事exporterhelper.WithCapabilities(consumer.Capabilities{MutatesData: false})声明不修改数据exporterhelper.WithTimeout(exporterhelper.TimeoutConfig{Timeout: 0})显式禁用超时避免长尾写入被超时打断WithRetry(cfg.RetryConfig)/WithQueue(cfg.QueueConfig)接入重试与队列WithStart(ex.start)/WithShutdown(ex.close)注册启动与关闭钩子。5.2 启动时获取存储工厂exporter.go 的start方法在启动阶段完成存储接线func (exp *storageExporter) start(_ context.Context, host component.Host) error { f, err : jaegerstorage.GetTraceStoreFactory(exp.config.TraceStorage, host) if err ! nil { return fmt.Errorf(cannot find storage factory: %w, err) } exp.warnMisalignedSyncBatchSizing(f) if exp.traceWriter, err f.CreateTraceWriter(); err ! nil { return fmt.Errorf(cannot create trace writer: %w, err) } return nil }调用链为GetTraceStoreFactory(name, host)→ 从 Host 的扩展列表中定位jaeger_storage扩展extension.go 的findExtension→ 调用TraceStorageFactory(name)按名字惰性创建/缓存工厂 →CreateTraceWriter()得到写入器。若name未声明或扩展缺失分别返回storage ... not declared ...与cannot find extension ... (make sure its defined earlier in the config)错误——后者提示了扩展在配置中必须位于引用它的组件之前这一约束。5.3 数据面写入前先消毒pushTraces是真正的数据入口exporter.gofunc (exp *storageExporter) pushTraces(ctx context.Context, td ptrace.Traces) error { return exp.traceWriter.WriteTraces(ctx, exp.sanitizer(td)) }每次写入前都会经过sanitizer.Sanitize来自 internal/jptrace/sanitizer它负责补齐/修正不规范的 span 数据典型行为包括为空的服务名填充missing-service-name、空 span 名、负持续时间、非法 UTF-8 等。端到端测试 exporter_test.go 验证了写入后从存储读回的资源属性中确实带上了service.name missing-service-name。5.4 关闭钩子与只读数据close方法为空实现注释明确说明“span writer is not closable”——存储的生命周期由jaeger_storage扩展统一管理其Shutdown会关闭所有已创建的工厂见 extension.go测试 exporter_test.go 的TestExporterWithReadOnlyTraces专门验证了当存在多个 exporter 时 trace 数据被标记为只读MarkReadOnly的情况下本导出器不会 panic 且写入正常——这得益于MutatesData: false的声明与消毒器的只读安全实现。六、端到端验证测试如何证明它可用仓库自带的集成级单元测试exporter_test.go走完了完整闭环创建真实的内存存储扩展jaeger_storagememory.Configuration{MaxTraces: 10000}→ 用NewFactory()创建导出器 →Start→ 构造一个带特定traceID/spanID的 span →ConsumeTraces写入 → 再通过CreateTraceReader().GetTraces读回并断言 spanID 与消毒后的服务名。这说明该导出器不依赖任何外部服务即可独立验证内存存储即可“写入即可读回”证明它与jaeger_storage扩展的接线是完整可用的消毒器在真实写入路径上生效。如果你想在本地复现只需运行go test ./cmd/jaeger/internal/exporters/storageexporter/...。七、实践要点小结必填项trace_storage必须指定且与extensions.jaeger_storage中声明的后端名一致否则启动校验或start阶段报错重试默认关闭如需开启动态退避重试显式设置retry_on_failure.enabled: true并按需覆盖间隔、倍率与总时长队列可调queue支持并发消费者数、队列深度与批次大小字节计数的批量大小应与存储的bulk_processing.max_bytes对齐避免不必要的拆分与重写声明不改数据组件标记为MutatesData: false可安全用于多 exporter 并存的管道只读 trace 也不会导致 panic消毒在前所有写入数据先经sanitizer.Sanitize规范化空服务名、负时长等脏数据在落库前被修正生命周期归属导出器自身不持有存储资源关闭时不做额外清理存储由jaeger_storage扩展统一管理。jaeger_storage_exporter虽小却是 Jaeger v2 “采集即存储”架构中承上启下的关键一环它让任意 OTel Collector 管道能以统一方式写入 Jaeger 原生存储也让 all-in-one 模式得以用内存后端零依赖启动。理解它的配置面与实现细节是排查写入失败、调优批量效率、规划自托管 Jaeger 部署的基础。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
)
