Vector vector 组件 v2 发布从裸 TCP 到 gRPC 的 Vector-to-Vector 通信迁移指南【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector本篇技术指南围绕 Vector 官方发布说明《Version 2 of the Vector source/sink released》展开讲解vectorsource/sink 组件 v2 版本的通信协议升级从 v1 的裸 TCP 传输切换为 gRPC over HTTP背后的动机、配置切换方式、被移除的 v1 专属参数、source 与 sink 必须同步升级的原因以及完整的零停机升级操作步骤。读完后你将能够在自己的 Vector 拓扑中安全地把 Vector 自转发链路切换到 v2 协议并理解其 gRPC 服务定义、健康检查与压缩协商等源码级实现细节。v1 为什么必须被替代v1 的vectorsource/sink 基于裸 TCP 实现。官方在 0.16.0 版本中发布了 v2 主版本明确列出了 v1 存在并促使这次重写的四个问题vectorsink 在 Kubernetes 中配合动态 IP 地址无法工作对应 issue #2070v1 使用长连接直连对端 socket当对端 Pod 重建、IP 漂移后旧连接无法自动失效重连sink 侧因此失效v1 不支持在vectorsource 和 sink 中启用 HTTP对应 issue #5124裸 TCP 协议无法被标准的 HTTP 代理、负载均衡器或 TLS 终结层介入source 与 sink 无法基于 gRPC 通信对应 issue #6646v1 没有 RPC 语义无法携带请求/响应状态码也就无法做基于状态码的重试与路由决策v1 缺少面向 Vector 间通信的正式编解码规范对应 PR #6032RFC 5843没有结构化的事件序列化协议事件元数据与指标类型在传输中无法保真。v2 的解法是彻底更换通信协议以 gRPC over HTTP 作为传输层事件体改为 Protobuf 编解码。这一替换同时解决了上述全部问题——HTTP/2 连接可被代理与负载均衡器处理gRPC 状态码支撑重试逻辑Protobuf 提供稳定的线格式。如何启用 v2启用方式极其简单在[sources.vector]与[sinks.vector]中各自显式声明version 2[sinks.vector] type vector version 2 [sources.vector] type vector version 2版本策略的演进与现状官方公告给出了明确的三阶段迁移时间线这是理解版本字段行为的关键前提阶段行为0.16.0发布 v2但仍默认 v1可任选其一并显式声明version0.20.0要求运维人员显式声明version同时继续支持 v10.22.0完全移除 v1默认且仅有 v2不再要求显式设置版本对照当前仓库源码可以验证这一时间线已经走完。在 vector source 配置定义 中版本标记类型只保留了 v2 一个变体/// Marker type for version two of the configuration for the vector source. #[configurable_component] #[derive(Clone, Debug)] enum VectorConfigVersion { /// Marker value for version two. #[serde(rename 2)] V2, }vector sink 的配置文件 中version字段同样只接受2且源码注释明确写道该选项已弃用并已从旧文档中移除未来会以破坏性变更的方式彻底移除/// Version of the configuration. // NOTE: this option is deprecated and has already been removed from the old docs. // At some point in the future we will remove it entirely as a breaking change. #[configurable(metadata(docs::hidden))] version: Optionsuper::VectorConfigVersion,也就是说在当前代码库对应的版本中version 2属于兼容性残留写法保留它不会报错但配置语义上 v1 已不复存在新配置实际上不再需要显式写version。v2 的协议本体gRPC 服务与 Protobuf 消息v2 的通信契约完全由 proto/vector/vector.proto 定义内容非常精炼syntax proto3; package vector; import event.proto; message PushEventsRequest { repeated event.EventWrapper events 1; } message PushEventsResponse {} enum ServingStatus { SERVING 0; NOT_SERVING 1; } message HealthCheckRequest {} message HealthCheckResponse { ServingStatus status 1; } service Vector { rpc PushEvents(PushEventsRequest) returns (PushEventsResponse) {} rpc HealthCheck(HealthCheckRequest) returns (HealthCheckResponse); }两个 RPC 各司其职PushEventssink 将一批事件repeated EventWrapper编码后 POST 到下游 source 的/vector.Vector/PushEvents端点sink 测试中对请求路径与application/grpcContent-Type 的断言 可直接印证这一线上行为。EventWrapper来自event.proto是 Vector 原生的事件表示因此日志、指标、trace 都能在同一通道中保真转发这正是结构化编解码要解决的问题HealthChecksource 侧上报SERVING/NOT_SERVING状态sink 在构建阶段与健康检查时调用它来确认下游是否可接收事件。source 端gRPC 服务端如何组装source 的build流程 展示了 v2 服务端的完整组装过程用proto::Server::new(Service { ... })构建自定义的Vector服务实现其中Service的push_events方法把PushEventsRequest反序列化为Event按日志命名空间策略注入source_type等标准源元数据再交给下游 pipeline消息上限受全局解压大小限制约束max_decoding_message_size避免在未认证监听端口上因单条超大消息触发无界内存分配同时挂载一个标准 gRPC 健康服务tonic_health的health_reporter并将vector.Vector服务注册为Serving状态最后通过RoutesBuilder把两个服务合并到同一个 gRPC 路由树。这里有一个值得注意的细节source 同时实现了自定义HealthCheckRPC与标准 gRPC 健康检查协议两套端点。sink 侧的健康检查实现 注释明确说明两者行为一致均返回 serving 状态而不做深度健康校验source 保留双协议纯粹是为了兼容不同客户端。source 单元测试中的custom_health_check_works与standard_grpc_health_check_works分别验证了这两条路径都可用。sink 端批处理、编码与压缩sink 的数据主循环 描述了事件从接收到上线的完整链路先做嵌套深度防护event_exceeds_max_nesting_cost检查每个事件的嵌套成本是否超出 Protobuf 编码预算超出的事件会被标记为Rejected并丢弃防止深层嵌套对象在接收端解码时溢出按batch配置RealtimeEventBasedDefaultBatchSettings对事件做实时批处理累积EventWrapper与字节数统计将整批封装为proto_vector::PushEventsRequest计算编码长度并连同EventFinalizers用于端到端确认一起交给 Tower 服务栈发起 gRPC 调用。压缩由 compression.rs 中的VectorCompression枚举控制取值none默认、gzip、zstd底层映射为 tonic 的CompressionEncoding并作用于 gRPC 消息层体现在grpc-encoding请求头中。压缩级别不可配置这是底层 tonic 库的限制。source 端则由DecompressionAndMetricsLayer统一处理解压协商sink 与 source 的压缩测试deliver_message_gzip、receive_zstd_compressed_message等覆盖了三种算法的互操作。v1 遗留参数的移除切换到 v2 后两个与 TCP 长连接强绑定的参数不再合法配置中出现会导致校验失败组件移除的 v1 参数原用途vectorsourcekeepalive、receive_buffer_bytesTCP 层保活与接收缓冲区大小vectorsinkkeepalive、send_buffer_bytesTCP 层保活与发送缓冲区大小这些参数只服务于裸 TCP 连接管理在 gRPC/HTTP2 传输下由协议栈本身接管。需要说明的是v2 并非完全没有 keepalive 概念而是换了模型——source 端保留了一个 gRPC 意义的keepalive默认地址为0.0.0.0:6000keepalive使用GrpcKeepaliveConfig例如可配置max_connection_age_secs强制周期性关闭连接测试max_connection_age_closes_idle_connection验证了连接到期后确实被服务端关闭sink 端新增了 HTTP/2 空闲保活VectorKeepaliveConfiginterval_secs默认 60 秒、timeout_secs默认 20 秒。其目的不是维持连接而是在请求发出之前探测并剔除已死的连接下游崩溃、重启或网络分区导致确保重试永远落在存活连接上。默认值 60 秒是对齐 gRPC 官方对too_many_pings策略的建议下限。升级纪律source 与 sink 必须成对升级官方公告中最重要的运维约束是source 和 sink 必须同时升级到 v2或者都不升级绝不允许只升一端。原因是 v1 与 v2 是完全不同的线协议一个裸 TCP 流一个 HTTP/2 gRPC一端升级后对端仍按旧协议解释字节流结果是直接的数据丢失。从当前仓库的测试结构可以侧面印证这一约束source 侧的互操作测试receive_message 等是用真实构造的 v2 sink作为对端来发送事件的不存在任何 v1 互通测试——因为 v1 代码已经不存在了。零停机升级操作手册官方给出的零停机迁移方案采用新旧组件并存、先加后切再删的三步法。以下按公告原文的 diff 逐步说明。第一步在 source 上新增 v2 实例与 v1 并存[sources.vector] address 0.0.0.0:9000 type vector version 1 [sources.vector] address 0.0.0.0:5000 type vector version 2此时下游 Vector 同时监听两个端口9000 上的 v1 继续接收存量上游流量5000 上的 v2 等待新流量。注意示例中 v1 也显式写上了version 1——这在 0.20.0 要求显式声明版本的背景下是必须的。第二步切换 sink 指向 v2 source[sinks.vector] - address 127.0.1.2:9000 address 127.0.1.2:5000 type vector version 2部署后上游 Vector 的事件开始经 gRPC 通道进入下游。此步是整个流程中唯一改变数据流向的部署切换是原子的一个 sink 配置整体生效不存在半开状态。第三步移除 source 上的 v1 实例- [sources.vector] - address 0.0.0.0:9000 - type vector - version 1 - [sources.vector] address 0.0.0.0:5000 type vector version 2至此该 Vector-to-Vector 链路完全运行在 v2 协议上。如果拓扑中存在多个级联的 Vector 实例每一跳每一对 source/sink都需要独立走完这三步。当前实现中的进一步佐证除了上述公告内容当前仓库中还能看到 v2 传输在发布后持续演进的若干实现事实可作为深入阅读入口多端点路由sink 的 RoutingConfig 支持routing.endpointsstrategyload_balance/failover/failover_primary配合VectorGrpcRetryLogic按 gRPC 状态码判定可重试性NotFound、InvalidArgument、PermissionDenied、DataLoss等不可重试见 config.rs。这是 gRPC 状态码语义的直接红利——v1 的 TCP 流上根本无法做这种判定端到端确认source 的push_events在acknowledgements开启时会等待本批事件的最终投递状态失败时映射为 gRPCinternal/data_loss错误码handle_batch_statussink 侧据此驱动重试或丢弃决策嵌套预算与线格式的一致性sink 测试 专门验证了恰好处于嵌套预算边界的事件能够完整走完PushEventsRequest的编码/解码往返确保防嵌套溢出的闸门与真实线格式不脱节。小结Vector source/sink v2 的核心价值不在于换了个端口而在于把 Vector-to-Vector 通信从私有 TCP 流升级为有正式 Protobuf 契约、有状态码语义、可被 HTTP 基础设施介入的 gRPC 协议从而一次性解决了 Kubernetes 动态 IP、代理/TLS 支持、RPC 通信与结构化编解码四类 v1 局限。对存量拓扑而言记住三条纪律即可新旧版本按version字段显式声明并遵循 0.16 → 0.20 → 0.22 的默认值演进source 与 sink 必须成对切换零停机迁移遵循先加 v2 source、再切 sink、后删 v1 source的三步部署。在当前仓库对应的版本中v1 已被彻底移除version 2字段仅作兼容保留新的 Vector 自转发链路可以默认工作在 gRPC 之上。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考