Jaeger gRPC Remote Storage 接入指南协议解析、配置实战与合规性认证【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger本指南围绕 Jaeger 的 gRPC Remote Storage API 展开讲解如何让 Jaeger 通过标准的 gRPC 接口对接任何自研或第三方存储后端涵盖三大核心服务协议、jaeger_storage扩展的完整配置示例以及如何运行官方集成测试为自己的存储后端完成合规性认证。读完本文你将掌握从协议设计、客户端配置到端到端验证的完整链路可以直接照此为自己的存储实现接入 Jaeger。为什么需要 Remote StorageJaeger 本身原生支持 Cassandra、Elasticsearch/OpenSearch、Badger、ClickHouse 等存储见 internal/storage/v2 下的各存储实现但真实生产环境中常常存在 Jaeger 尚未原生适配的存储系统例如自研的列式数据库、云厂商托管的 trace 服务或已有的统一可观测性存储。gRPC Remote Storage 正是为解决这类问题而设计Jaeger 通过一套固定的 gRPC 协议与外部存储通信外部只需实现协议中约定的服务接口即可被 Jaeger 当作一等存储后端使用。它由 Jaeger 客户端实现internal/storage/v2/grpc与对应的远程存储服务端组成两端解耦存储内部实现细节完全对 Jaeger 隐藏。协议总览远程存储必须实现的三大 gRPC 服务一个远程存储后端需要实现三类 gRPC 服务分别覆盖读、写与依赖图服务职责数据流方向TraceReader让 Jaeger 从存储中读取 trace按 trace ID 取 trace、按条件搜索 trace、列出服务名与操作名、获取 trace 摘要与搜索能力查询端 → 存储DependencyReader从存储加载服务依赖图Service Dependency Graph查询端 → 存储TraceService允许将 trace 数据推送到存储中基于 OTLP 导出协议如有需要可运行在独立端口采集端 → 存储在 Jaeger 源码中这三类服务的角色划分清晰可见读取侧TraceReader与DependencyReader使用 Jaeger 自定义的 storage/v2 协议客户端见 tracereader.go、depreader.go生成的 Go 代码位于 internal/proto-gen/storage/v2写入侧TraceWriter直接复用 OpenTelemetry 的 OTLP gRPC 导出协议ptraceotlp.GRPCClient见 tracewriter.go 中对Export调用的封装。这意味着远程存储的写入端可以天然复用 OTLP 生态。从服务端视角看handler.go 中的Register方法把四个接口TraceReader、DependencyReader、Capabilities与 OTLPTraceService一次性注册到同一个 gRPC Server并同步向 gRPC Health 服务上报各服务的SERVING状态——健康检查是接入 Jaeger 时后端应一并实现的基础能力。配置实战以官方示例为模板接入自定义后端官方在 cmd/jaeger/config-remote-storage.yaml 提供了完整可运行的远程存储配置示例这是接入自定义后端最直接的起点。核心片段如下extensions: jaeger_storage: backends: some-storage: grpc: endpoint: ${env:REMOTE_STORAGE_ENDPOINT:-localhost:17271} tls: insecure: true writer: endpoint: ${env:REMOTE_STORAGE_WRITER_ENDPOINT:-0.0.0.0:4316} tls: insecure: true jaeger_query: storage: traces: some-storage ui: config_file: ./cmd/jaeger/config-ui.json receivers: otlp: protocols: grpc: http: processors: batch: exporters: jaeger_storage_exporter: trace_storage: some-storage要点解读jaeger_storage扩展声明名为some-storage的后端其类型为grpc。endpoint指向远程存储的读取地址TraceReader/DependencyReader 服务支持${env:VAR:-default}形式的占位符默认localhost:17271writer子配置用于覆盖写入端点示例中写端点被设置为0.0.0.0:4316一个与读取端口不同的独立端口即 TraceService/OTLP 服务的监听地址并同样显式声明tls.insecure: truejaeger_query扩展将查询链路的traces存储指向some-storageUI 配置沿用 cmd/jaeger/config-ui.json采集链路通过otlpreceiver 接收数据经batchprocessor 后由jaeger_storage_exporter写入some-storage。注意示例中TraceService被配置运行在独立端口0.0.0.0:4316该端口通过配置文件中的writer.endpoint显式覆盖而非沿用读取端口。深入理解客户端配置参数grpc后端的配置结构体定义在 internal/storage/v2/grpc/config.go其参数说明如下配置项类型说明endpointstring读取端点TraceReader/DependencyReader继承自 collector 的configgrpc.ClientConfigtlsobjectTLS 客户端配置自建环境通常设insecure: truewriter.endpointstring可选写入端点覆盖项不配置时读写共用主端点writer.tlsobject写入连接的 TLS 配置max_recv_msg_size_mibint客户端可接收的最大消息大小MiB默认 4 MiBgRPC 默认值当存储返回的大 trace 响应超过 4 MiB 时应调大timeoutduration请求超时默认5s见DefaultConfig()multi_tenancyobject多租户配置启用后客户端会附加租户拦截器header_forwardingarray需要从查询端透传到存储的请求头列表两个值得注意的实现细节balancer 大小写兼容Config.Unmarshal会将BalancerName统一转为小写以保留 grpc-go 历史上对 balancer 名称大小写不敏感的查找行为config.gomax_recv_msg_size_mib校验Factory初始化时校验其取值必须位于[0, math.MaxInt/(1024*1024)]超过该范围直接报错factory.go。源码剖析双连接设计与递归 trace 防护阅读 factory.go 可以发现一个精巧的设计Factory 维护两条独立的 gRPC 连接readerConn *grpc.ClientConn // 用于从远程存储读取可开启 instrumentation writerConn *grpc.ClientConn // 用于向远程存储写入不应开启 instrumentation选择writer端点cfg.Writer.Endpoint为空时写连接退化为复用主端点factory.go。之所以要拆成两条连接是因为防止递归生成 trace写入链路的连接使用noop.NewTracerProvider()创建无操作 tracerfactory.go避免 Jaeger 在向存储写入数据时又把自己产生的 trace 送回存储形成循环而读取链路不涉及该风险可以放心开启 instrumentation。此外Factory 在初始化连接时统一装配了以下拦截器链factory.goBearer Token一元与流式客户端拦截器支持携带令牌访问受保护的存储多租户当multi_tenancy.enabled为真时追加租户注入拦截器Header 转发当配置了header_forwarding时把查询端 HTTP/gRPC 服务端拦截器捕获的请求头透传到出站 metadata消息大小max_recv_msg_size_mib 0时附加grpc.MaxCallRecvMsgSize调用选项。Factory 对外暴露的三个创建方法CreateTraceReader()、CreateTraceWriter()、CreateDependencyReader()分别构造出对应客户端Close()会同时关闭两条连接并聚合错误。读取端流式返回与能力协商TraceReadertracereader.go实现了 Jaeger 存储 API 的全部读取接口GetTraces/FindTraces通过 gRPC服务端流逐批返回结果调用方按iter.Seq2迭代消费GetServices/GetOperations服务名与操作名列举FindTraceIDs/FindTraceSummariestrace ID 搜索与摘要支持SearchDepth深度参数SearchCapabilities向后端询问搜索能力并缓存结果atomic.Pointer缓存。协议约定能力在连接生命周期内稳定若后端未实现Capabilities服务而返回UNIMPLEMENTED则客户端按最弱能力处理保证旧版后端继续可用。查询参数编码方面toProtoQueryParameters会把过滤表达式树转换为线上协议并对SearchDepth做 int32 溢出校验tracereader.go属性值则递归转换为AnyValue字符串、布尔、整数、浮点、字节、数组、KV 列表均可表达。服务端Handler 的完整实现形态若你的后端希望直接复用 Jaeger 的协议实现例如基于 Jaeger 内存存储快速搭建远程存储服务可参考Handlerhandler.go。它同时实现了TraceReaderServer、DependencyReaderServer、CapabilitiesServer与 OTLPGRPCServer四个接口内部持有tracestore.Reader、tracestore.Writer与depstore.Reader将线上请求翻译为 Jaeger 内部存储接口后转交底层实现。查询处理中还内置了filter 兼容策略对应 RFC 0005 §7 的设计解码后先FinalizeFilter补全过滤器拒绝 filter 与旧式查询字段同时携带的请求返回InvalidArgument并根据后端声明的能力决定投递 filter 还是退化为旧式谓词字段handler.go。合规性认证运行官方集成测试验证你的后端README 明确指出要验证远程存储后端能否与 Jaeger 正确协同工作运行 Jaeger 项目提供的集成测试即可。这也是官方建议的合规认证Certifying compliance流程。第一步克隆 Jaeger 仓库git clone https://github.com/jaegertracing/jaeger.git cd jaeger第二步运行 gRPC 存储集成测试STORAGEgrpc \ CUSTOM_STORAGEtrue \ REMOTE_STORAGE_ENDPOINT${MY_REMOTE_STORAGE_ENDPOINT} \ REMOTE_STORAGE_WRITER_ENDPOINT${MY_REMOTE_STORAGE_WRITER_ENDPOINT} \ PURGER_ENDPOINT${MY_PURGER_ENDPOINT} \ make jaeger-v2-storage-integration-test四个环境变量的含义环境变量含义REMOTE_STORAGE_ENDPOINT远程存储读取端点TraceReader / DependencyReader测试会以此启动查询链路REMOTE_STORAGE_WRITER_ENDPOINT远程存储写入端点OTLP TraceServicePURGER_ENDPOINT清理端点每次测试运行前测试框架会调用该POST HTTP 端点清空存储后端确保测试从干净状态开始CUSTOM_STORAGEtrue标记使用外部自定义存储而非 Jaeger 内置存储该 make 目标定义于 scripts/makefiles/IntegrationTests.mk。测试入口为 internal/storage/integration/grpc_test.go 中的TestGRPCRemoteStorage它通过SkipUnlessEnv(t, StorageGRPC)判断是否启用构建GRPCStorageIntegrationTestSuite后调用RunAll(t)跑完全部存储行为用例写入、读取、搜索、依赖图等。架构全景一次测试的完整数据流README 用 Mermaid 图给出了集成测试的架构直观展示了测试、Jaeger 收集器与自定义存储三方的关系flowchart LR Test -- |writeSpan| SpanWriter Test -- |http:$PURGER_ENDPOINT| Purger SpanWriter -- |0.0.0.0:4317| OTLP_Receiver1 OTLP_Receiver1 -- GRPCStorage GRPCStorage -- |grpc:$REMOTE_STORAGE_WRITER_ENDPOINT| TraceService Test -- |readSpan| SpanReader SpanReader -- |0.0.0.0:16685| QueryExtension QueryExtension -- GRPCStorage GRPCStorage -- |grpc:$REMOTE_STORAGE_ENDPOINT| TraceReader GRPCStorage -- |grpc:$REMOTE_STORAGE_ENDPOINT| DependencyReader subgraph Integration Test Executable Test SpanWriter SpanReader end subgraph Jaeger Collector OTLP_Receiver1[OTLP Receiver] QueryExtension[Query Extension] GRPCStorage[gRPC Storage] end subgraph Custom Storage Backend TraceService TraceReader DependencyReader Purger[HTTP/Purger] end数据流解读写入路径测试的SpanWriter通过 OTLP0.0.0.0:4317把 trace 推给 Jaeger 收集器的 OTLP Receiver → 进入gRPC Storage客户端 → 经grpc:$REMOTE_STORAGE_WRITER_ENDPOINT写入自定义存储的TraceService读取路径测试的SpanReader通过查询扩展0.0.0.0:16685发起查询 →QueryExtension→gRPC Storage客户端 → 经grpc:$REMOTE_STORAGE_ENDPOINT调用自定义存储的TraceReader与DependencyReader清理路径每次用例前测试直接以http:$PURGER_ENDPOINT调用自定义存储暴露的 HTTP Purger保证状态干净。仓库内的参考实现若想先观察一个标准答案仓库内自带了一个基于内存存储的远程存储服务实现可直接对照学习internal/storage/integration/remote_memory_storage.go集成测试中启动的进程内远程存储服务器用内存memory.Factory作为底层存储监听在ports.RemoteStorageGRPC端口cmd/remote-storage独立可运行的 remote-storage 服务程序其 app/server.go 使用Handler.Register把读取、写入、依赖与能力四个服务注册到 gRPC Server配置示例见 cmd/remote-storage/config.yaml 与 cmd/remote-storage/config-badger.yaml服务端能力协商的 proto 转换逻辑见 capabilities.go负责SearchCapabilities/FilterCapabilities在内部类型与线上 proto 之间的双向转换。接入清单与注意事项把以上内容落成一份可执行的接入清单实现三个服务TraceReader读取、DependencyReader依赖图、TraceServiceOTLP 写入建议同时实现 Capabilities 服务以支持能力协商并注册 gRPC Health 服务暴露 HTTP Purger提供 POST 端点用于清空数据这是官方集成测试的前置要求按需拆分端口写入OTLP可与读取共用端口也可像官方示例那样通过writer.endpoint拆到独立端口如4316配置 TLS 与消息大小自建环境可设tls.insecure: true若存储会返回超过 4 MiB 的大响应记得调大max_recv_msg_size_mib运行官方集成测试认证设置STORAGEgrpc、CUSTOM_STORAGEtrue及三个端点变量后执行make jaeger-v2-storage-integration-test注意向后兼容未实现 Capabilities 服务时客户端会按最弱能力工作旧字段查询未实现FindTraceSummaries时客户端会回退为加载全量 trace 后在本地聚合新功能属于增量增强而非破坏性变更。按照上述流程接入并通过集成测试后你的存储后端即可与 Jaeger 的查询、采集与依赖分析全链路无缝协作。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jaeger gRPC Remote Storage 接入指南：协议解析、配置实战与合规性认证
Jaeger gRPC Remote Storage 接入指南协议解析、配置实战与合规性认证【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger本指南围绕 Jaeger 的 gRPC Remote Storage API 展开讲解如何让 Jaeger 通过标准的 gRPC 接口对接任何自研或第三方存储后端涵盖三大核心服务协议、jaeger_storage扩展的完整配置示例以及如何运行官方集成测试为自己的存储后端完成合规性认证。读完本文你将掌握从协议设计、客户端配置到端到端验证的完整链路可以直接照此为自己的存储实现接入 Jaeger。为什么需要 Remote StorageJaeger 本身原生支持 Cassandra、Elasticsearch/OpenSearch、Badger、ClickHouse 等存储见 internal/storage/v2 下的各存储实现但真实生产环境中常常存在 Jaeger 尚未原生适配的存储系统例如自研的列式数据库、云厂商托管的 trace 服务或已有的统一可观测性存储。gRPC Remote Storage 正是为解决这类问题而设计Jaeger 通过一套固定的 gRPC 协议与外部存储通信外部只需实现协议中约定的服务接口即可被 Jaeger 当作一等存储后端使用。它由 Jaeger 客户端实现internal/storage/v2/grpc与对应的远程存储服务端组成两端解耦存储内部实现细节完全对 Jaeger 隐藏。协议总览远程存储必须实现的三大 gRPC 服务一个远程存储后端需要实现三类 gRPC 服务分别覆盖读、写与依赖图服务职责数据流方向TraceReader让 Jaeger 从存储中读取 trace按 trace ID 取 trace、按条件搜索 trace、列出服务名与操作名、获取 trace 摘要与搜索能力查询端 → 存储DependencyReader从存储加载服务依赖图Service Dependency Graph查询端 → 存储TraceService允许将 trace 数据推送到存储中基于 OTLP 导出协议如有需要可运行在独立端口采集端 → 存储在 Jaeger 源码中这三类服务的角色划分清晰可见读取侧TraceReader与DependencyReader使用 Jaeger 自定义的 storage/v2 协议客户端见 tracereader.go、depreader.go生成的 Go 代码位于 internal/proto-gen/storage/v2写入侧TraceWriter直接复用 OpenTelemetry 的 OTLP gRPC 导出协议ptraceotlp.GRPCClient见 tracewriter.go 中对Export调用的封装。这意味着远程存储的写入端可以天然复用 OTLP 生态。从服务端视角看handler.go 中的Register方法把四个接口TraceReader、DependencyReader、Capabilities与 OTLPTraceService一次性注册到同一个 gRPC Server并同步向 gRPC Health 服务上报各服务的SERVING状态——健康检查是接入 Jaeger 时后端应一并实现的基础能力。配置实战以官方示例为模板接入自定义后端官方在 cmd/jaeger/config-remote-storage.yaml 提供了完整可运行的远程存储配置示例这是接入自定义后端最直接的起点。核心片段如下extensions: jaeger_storage: backends: some-storage: grpc: endpoint: ${env:REMOTE_STORAGE_ENDPOINT:-localhost:17271} tls: insecure: true writer: endpoint: ${env:REMOTE_STORAGE_WRITER_ENDPOINT:-0.0.0.0:4316} tls: insecure: true jaeger_query: storage: traces: some-storage ui: config_file: ./cmd/jaeger/config-ui.json receivers: otlp: protocols: grpc: http: processors: batch: exporters: jaeger_storage_exporter: trace_storage: some-storage要点解读jaeger_storage扩展声明名为some-storage的后端其类型为grpc。endpoint指向远程存储的读取地址TraceReader/DependencyReader 服务支持${env:VAR:-default}形式的占位符默认localhost:17271writer子配置用于覆盖写入端点示例中写端点被设置为0.0.0.0:4316一个与读取端口不同的独立端口即 TraceService/OTLP 服务的监听地址并同样显式声明tls.insecure: truejaeger_query扩展将查询链路的traces存储指向some-storageUI 配置沿用 cmd/jaeger/config-ui.json采集链路通过otlpreceiver 接收数据经batchprocessor 后由jaeger_storage_exporter写入some-storage。注意示例中TraceService被配置运行在独立端口0.0.0.0:4316该端口通过配置文件中的writer.endpoint显式覆盖而非沿用读取端口。深入理解客户端配置参数grpc后端的配置结构体定义在 internal/storage/v2/grpc/config.go其参数说明如下配置项类型说明endpointstring读取端点TraceReader/DependencyReader继承自 collector 的configgrpc.ClientConfigtlsobjectTLS 客户端配置自建环境通常设insecure: truewriter.endpointstring可选写入端点覆盖项不配置时读写共用主端点writer.tlsobject写入连接的 TLS 配置max_recv_msg_size_mibint客户端可接收的最大消息大小MiB默认 4 MiBgRPC 默认值当存储返回的大 trace 响应超过 4 MiB 时应调大timeoutduration请求超时默认5s见DefaultConfig()multi_tenancyobject多租户配置启用后客户端会附加租户拦截器header_forwardingarray需要从查询端透传到存储的请求头列表两个值得注意的实现细节balancer 大小写兼容Config.Unmarshal会将BalancerName统一转为小写以保留 grpc-go 历史上对 balancer 名称大小写不敏感的查找行为config.gomax_recv_msg_size_mib校验Factory初始化时校验其取值必须位于[0, math.MaxInt/(1024*1024)]超过该范围直接报错factory.go。源码剖析双连接设计与递归 trace 防护阅读 factory.go 可以发现一个精巧的设计Factory 维护两条独立的 gRPC 连接readerConn *grpc.ClientConn // 用于从远程存储读取可开启 instrumentation writerConn *grpc.ClientConn // 用于向远程存储写入不应开启 instrumentation选择writer端点cfg.Writer.Endpoint为空时写连接退化为复用主端点factory.go。之所以要拆成两条连接是因为防止递归生成 trace写入链路的连接使用noop.NewTracerProvider()创建无操作 tracerfactory.go避免 Jaeger 在向存储写入数据时又把自己产生的 trace 送回存储形成循环而读取链路不涉及该风险可以放心开启 instrumentation。此外Factory 在初始化连接时统一装配了以下拦截器链factory.goBearer Token一元与流式客户端拦截器支持携带令牌访问受保护的存储多租户当multi_tenancy.enabled为真时追加租户注入拦截器Header 转发当配置了header_forwarding时把查询端 HTTP/gRPC 服务端拦截器捕获的请求头透传到出站 metadata消息大小max_recv_msg_size_mib 0时附加grpc.MaxCallRecvMsgSize调用选项。Factory 对外暴露的三个创建方法CreateTraceReader()、CreateTraceWriter()、CreateDependencyReader()分别构造出对应客户端Close()会同时关闭两条连接并聚合错误。读取端流式返回与能力协商TraceReadertracereader.go实现了 Jaeger 存储 API 的全部读取接口GetTraces/FindTraces通过 gRPC服务端流逐批返回结果调用方按iter.Seq2迭代消费GetServices/GetOperations服务名与操作名列举FindTraceIDs/FindTraceSummariestrace ID 搜索与摘要支持SearchDepth深度参数SearchCapabilities向后端询问搜索能力并缓存结果atomic.Pointer缓存。协议约定能力在连接生命周期内稳定若后端未实现Capabilities服务而返回UNIMPLEMENTED则客户端按最弱能力处理保证旧版后端继续可用。查询参数编码方面toProtoQueryParameters会把过滤表达式树转换为线上协议并对SearchDepth做 int32 溢出校验tracereader.go属性值则递归转换为AnyValue字符串、布尔、整数、浮点、字节、数组、KV 列表均可表达。服务端Handler 的完整实现形态若你的后端希望直接复用 Jaeger 的协议实现例如基于 Jaeger 内存存储快速搭建远程存储服务可参考Handlerhandler.go。它同时实现了TraceReaderServer、DependencyReaderServer、CapabilitiesServer与 OTLPGRPCServer四个接口内部持有tracestore.Reader、tracestore.Writer与depstore.Reader将线上请求翻译为 Jaeger 内部存储接口后转交底层实现。查询处理中还内置了filter 兼容策略对应 RFC 0005 §7 的设计解码后先FinalizeFilter补全过滤器拒绝 filter 与旧式查询字段同时携带的请求返回InvalidArgument并根据后端声明的能力决定投递 filter 还是退化为旧式谓词字段handler.go。合规性认证运行官方集成测试验证你的后端README 明确指出要验证远程存储后端能否与 Jaeger 正确协同工作运行 Jaeger 项目提供的集成测试即可。这也是官方建议的合规认证Certifying compliance流程。第一步克隆 Jaeger 仓库git clone https://github.com/jaegertracing/jaeger.git cd jaeger第二步运行 gRPC 存储集成测试STORAGEgrpc \ CUSTOM_STORAGEtrue \ REMOTE_STORAGE_ENDPOINT${MY_REMOTE_STORAGE_ENDPOINT} \ REMOTE_STORAGE_WRITER_ENDPOINT${MY_REMOTE_STORAGE_WRITER_ENDPOINT} \ PURGER_ENDPOINT${MY_PURGER_ENDPOINT} \ make jaeger-v2-storage-integration-test四个环境变量的含义环境变量含义REMOTE_STORAGE_ENDPOINT远程存储读取端点TraceReader / DependencyReader测试会以此启动查询链路REMOTE_STORAGE_WRITER_ENDPOINT远程存储写入端点OTLP TraceServicePURGER_ENDPOINT清理端点每次测试运行前测试框架会调用该POST HTTP 端点清空存储后端确保测试从干净状态开始CUSTOM_STORAGEtrue标记使用外部自定义存储而非 Jaeger 内置存储该 make 目标定义于 scripts/makefiles/IntegrationTests.mk。测试入口为 internal/storage/integration/grpc_test.go 中的TestGRPCRemoteStorage它通过SkipUnlessEnv(t, StorageGRPC)判断是否启用构建GRPCStorageIntegrationTestSuite后调用RunAll(t)跑完全部存储行为用例写入、读取、搜索、依赖图等。架构全景一次测试的完整数据流README 用 Mermaid 图给出了集成测试的架构直观展示了测试、Jaeger 收集器与自定义存储三方的关系flowchart LR Test -- |writeSpan| SpanWriter Test -- |http:$PURGER_ENDPOINT| Purger SpanWriter -- |0.0.0.0:4317| OTLP_Receiver1 OTLP_Receiver1 -- GRPCStorage GRPCStorage -- |grpc:$REMOTE_STORAGE_WRITER_ENDPOINT| TraceService Test -- |readSpan| SpanReader SpanReader -- |0.0.0.0:16685| QueryExtension QueryExtension -- GRPCStorage GRPCStorage -- |grpc:$REMOTE_STORAGE_ENDPOINT| TraceReader GRPCStorage -- |grpc:$REMOTE_STORAGE_ENDPOINT| DependencyReader subgraph Integration Test Executable Test SpanWriter SpanReader end subgraph Jaeger Collector OTLP_Receiver1[OTLP Receiver] QueryExtension[Query Extension] GRPCStorage[gRPC Storage] end subgraph Custom Storage Backend TraceService TraceReader DependencyReader Purger[HTTP/Purger] end数据流解读写入路径测试的SpanWriter通过 OTLP0.0.0.0:4317把 trace 推给 Jaeger 收集器的 OTLP Receiver → 进入gRPC Storage客户端 → 经grpc:$REMOTE_STORAGE_WRITER_ENDPOINT写入自定义存储的TraceService读取路径测试的SpanReader通过查询扩展0.0.0.0:16685发起查询 →QueryExtension→gRPC Storage客户端 → 经grpc:$REMOTE_STORAGE_ENDPOINT调用自定义存储的TraceReader与DependencyReader清理路径每次用例前测试直接以http:$PURGER_ENDPOINT调用自定义存储暴露的 HTTP Purger保证状态干净。仓库内的参考实现若想先观察一个标准答案仓库内自带了一个基于内存存储的远程存储服务实现可直接对照学习internal/storage/integration/remote_memory_storage.go集成测试中启动的进程内远程存储服务器用内存memory.Factory作为底层存储监听在ports.RemoteStorageGRPC端口cmd/remote-storage独立可运行的 remote-storage 服务程序其 app/server.go 使用Handler.Register把读取、写入、依赖与能力四个服务注册到 gRPC Server配置示例见 cmd/remote-storage/config.yaml 与 cmd/remote-storage/config-badger.yaml服务端能力协商的 proto 转换逻辑见 capabilities.go负责SearchCapabilities/FilterCapabilities在内部类型与线上 proto 之间的双向转换。接入清单与注意事项把以上内容落成一份可执行的接入清单实现三个服务TraceReader读取、DependencyReader依赖图、TraceServiceOTLP 写入建议同时实现 Capabilities 服务以支持能力协商并注册 gRPC Health 服务暴露 HTTP Purger提供 POST 端点用于清空数据这是官方集成测试的前置要求按需拆分端口写入OTLP可与读取共用端口也可像官方示例那样通过writer.endpoint拆到独立端口如4316配置 TLS 与消息大小自建环境可设tls.insecure: true若存储会返回超过 4 MiB 的大响应记得调大max_recv_msg_size_mib运行官方集成测试认证设置STORAGEgrpc、CUSTOM_STORAGEtrue及三个端点变量后执行make jaeger-v2-storage-integration-test注意向后兼容未实现 Capabilities 服务时客户端会按最弱能力工作旧字段查询未实现FindTraceSummaries时客户端会回退为加载全量 trace 后在本地聚合新功能属于增量增强而非破坏性变更。按照上述流程接入并通过集成测试后你的存储后端即可与 Jaeger 的查询、采集与依赖分析全链路无缝协作。【免费下载链接】jaegerCNCF Jaeger, a Distributed Tracing Platform项目地址: https://gitcode.com/GitHub_Trending/ja/jaeger创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考