Vector 0.31 升级指南废弃内部指标移除、事件 JSON 字节数计量与 S3 端点路径变更【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vectorVector 0.31.0 是一个包含破坏性变更breaking changes的版本核心影响集中在内部指标体系与 AWS S3 兼容端点两处。本篇升级指南基于仓库中的 0.31 Upgrade Guide 展开覆盖被移除的废弃指标清单及其替代方案、component_received_event_bytes_total/component_sent_event_bytes_total统一改用事件估算 JSON 大小的原因与源码实现以及aws_s3source 与 sink 在升级 SDK 后的 endpoint 路径调整。读完本文你可以安全地完成 0.31 升级并对组件级遥测指标的正确使用建立准确认知。破坏性变更总览Vector 的 0.31.0 发布包含两项破坏性变更和一项潜在有影响的行为变更破坏性变更Breaking changes移除多个已废弃的内部指标events_in_total等六个指标component_received_event_bytes_total与component_sent_event_bytes_total统一采用事件的估算 JSON 大小进行计量。潜在有影响变更Potentially impactful changesAWS S3 兼容 API如 Cloudflare R2的 endpoint 路径写法需要调整。这三类变更分别对应监控面板/告警规则、指标语义一致性和第三方 S3 兼容服务配置三个场景下面逐一展开。移除废弃内部指标完整清单与替代方案被移除指标与替代品对照Vector 在多个历史版本中逐步废弃旧的内部指标目标是全面落地 Component Specification组件规范所定义的、每个组件必须输出的基础指标集。0.31.0 中以下指标被正式移除被移除的指标替代指标说明events_in_totalcomponent_received_events_total直接替代events_out_totalcomponent_sent_events_total直接替代processed_bytes_totalcomponent_received_bytes_total或component_sent_bytes_total按组件类型选择见下文processed_events_totalcomponent_received_events_total或component_sent_events_total按组件类型选择见下文processing_errors_totalcomponent_errors_total直接替代events_failed_totalcomponent_errors_total直接替代大部分替换是直接的唯一需要一点判断逻辑的是processed_前缀的两个指标规则是对 sourceprocessed_bytes_total由component_received_bytes_total替代processed_events_total由component_received_events_total替代对 sink则分别由component_sent_bytes_total和component_sent_events_total替代。为什么这样定义组件规范中的指标语义从仓库中的 Component Specification 可以看到这套指标的规范依据。该规范要求所有组件 MUST 发出ComponentEventsReceived事件其属性包含count事件数量与byte_size接收事件所有事件的估算 JSON 字节大小并对应 MUST 递增两个计数器component_received_events_total按count递增其他属性作为指标标签component_received_event_bytes_total按byte_size递增。批量发事件是被允许的规范明确“组件 MAY 按批发出事件以提升性能但结果遥测状态必须等价于逐事件发出”例如一次为 10 个事件发出EventsReceived事件component_received_events_total计数器必须递增 10。这正是升级时面板可以直接用新指标替换旧指标的语义保证。源码中的实现印证新指标的落地实现位于lib/vector-common的注册事件机制中。EventsReceived 事件定义 展示了每个组件收到事件后实际递增的三个指标ComponentReceivedEventsCount直方图统计每批事件数量分布ComponentReceivedEventsTotal计数器即component_received_events_totalComponentReceivedEventBytesTotal计数器即component_received_event_bytes_total。其emit方法将CountByteSize(count, byte_size)解构后分别写入直方图与两个计数器并记录一条 trace 级别的Events received.日志——这与组件规范中“MUST 记录 trace 级别日志且不得限频”的要求一致。指标名枚举与字符串映射定义在 metric_name.rs可以查到ComponentReceivedEventsTotal对应的正是component_received_events_total。迁移建议与一个注意事项如果你基于旧指标构建了 Prometheus/Grafana 面板或告警规则请按上表逐个替换processed_前缀指标需要先确认所在组件是 source 还是 sink再选择received或sent系列。官方文档中有一个重要提醒仍有少量组件在 0.31.0 中继续发出部分被废弃的指标原因是这些指标携带了组件规范不允许的额外标签和信息。这些组件的旧指标将在未来版本中移除因此从 0.31.0 起应视为它们已经不存在不要在任何监控逻辑中依赖它们继续存在。事件字节数指标统一为估算 JSON 大小变更内容在 0.31.0 之前Vector 各组件在计量所发送/接收事件字节数时口径并不一致不同组件可能按实际线上序列化格式比如 Protobuf、自定义 codec或其他方式计量导致跨组件比较没有意义。从 0.31.0 起component_received_event_bytes_total和component_sent_event_bytes_total在所有组件上统一改为输出“事件若被序列化为 JSON 时的估算大小”。这样做的价值在于无论 source 或 sink 对接外部服务时采用何种序列化格式字节数指标都有一个与组件无关、可在整个拓扑中一致比较的口径——例如比较同一 pipeline 中上游与下游的吞吐字节数时不再有口径偏差。源码中的计量方式仓库源码可以直接印证这一口径多处组件代码通过estimated_json_encoded_size_of()计算事件的估算 JSON 字节大小后再上报。例如 内存 enrichment table 的 source 中let json_size events.estimated_json_encoded_size_of(); events_received.emit(CountByteSize(count, json_size));计算结果与事件数量一起封装为CountByteSize交给上文提到的EventsReceived注册事件最终递增component_received_event_bytes_total计数器。组件校验运行器runner/mod.rs对输入/输出事件同样使用该估算 JSON 大小进行计量说明这一口径也贯穿了vector validate的遥测统计。对升级者的实际影响如果此前你的 source/sink 采用非 JSON 序列化格式如 Protobuf 压缩后更小、GELF 结构不同升级后该指标数值会发生变化因为口径从“实际发出的字节”变为“估算 JSON 大小”。涉及数据量统计的告警阈值例如“接收字节数超过某值”建议在升级后观察一段时间必要时按新口径重新标定。如果你需要反映真实网络传输量的指标应关注组件规范中另定义的SinkNetworkBytesSent/SourceNetworkBytesReceived一类网络层事件见 Component Specification 的 Instrumentation 章节而不是依赖事件字节数指标。AWS S3 端点路径变更变更内容aws_s3source 和 sink 对 AWS S3 endpoint 的处理方式发生了变化直接原因是 Vector 升级了其底层使用的 SDK。对 AWS 官方 S3 无影响但对 S3 兼容 API如 Cloudflare R2如果你此前在 endpoint 中写入了 bucket 名可能需要将其去掉。变更示例旧写法endpoint 带 buckethttps://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.com/bucket name新写法endpoint 不含 buckethttps://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.combucket 名本身仍通过 source/sink 各自的bucket配置项指定endpoint 只指向 S3 兼容服务的基础地址。源码背景从源码结构看aws_s3 source 在构建 SDK 客户端时通过region.endpoint()解析出实际使用的端点let endpoint self.region.endpoint();再将该端点传给 AWS SDK 的 client 构建流程。升级 SDK 后端点解析遵循标准 S3 寻址规则endpoint 路径/虚拟主机形式的 bucket 寻址因此 endpoint 中再拼接 bucket 名会被 SDK 二次拼接指向错误地址。测试用例如 mod.rs 中的 RegionOrEndpoint 测试也验证了RegionOrEndpoint对 region 与显式 endpoint 的解析路径。升级检查清单全局搜索配置文件中aws_s3source/sink 的endpoint及region相关配置确认 endpoint 是否包含 bucket 名若使用的是 Cloudflare R2、MinIO 等 S3 兼容服务将 bucket 名从 endpoint 中移除升级后用实际读写验证source 拉取、sink 上传各一次确认 bucket 定位正确。升级小结0.31.0 的升级工作集中在三件事替换六个被移除的内部指标对照上表注意processed_前缀指标需按组件类型选择替代项且不要依赖仍由个别组件残留发出的旧指标、理解事件字节数指标的新口径统一为估算 JSON 大小阈值类告警需复查、修正 S3 兼容服务的 endpoint 写法去掉 endpoint 中的 bucket 名。完成这三步后监控体系即可与 0.31 的组件遥测规范Component Specification对齐后续版本迭代中组件指标的可预期性也会更强。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Vector 0.31 升级指南：废弃内部指标移除、事件 JSON 字节数计量与 S3 端点路径变更
Vector 0.31 升级指南废弃内部指标移除、事件 JSON 字节数计量与 S3 端点路径变更【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vectorVector 0.31.0 是一个包含破坏性变更breaking changes的版本核心影响集中在内部指标体系与 AWS S3 兼容端点两处。本篇升级指南基于仓库中的 0.31 Upgrade Guide 展开覆盖被移除的废弃指标清单及其替代方案、component_received_event_bytes_total/component_sent_event_bytes_total统一改用事件估算 JSON 大小的原因与源码实现以及aws_s3source 与 sink 在升级 SDK 后的 endpoint 路径调整。读完本文你可以安全地完成 0.31 升级并对组件级遥测指标的正确使用建立准确认知。破坏性变更总览Vector 的 0.31.0 发布包含两项破坏性变更和一项潜在有影响的行为变更破坏性变更Breaking changes移除多个已废弃的内部指标events_in_total等六个指标component_received_event_bytes_total与component_sent_event_bytes_total统一采用事件的估算 JSON 大小进行计量。潜在有影响变更Potentially impactful changesAWS S3 兼容 API如 Cloudflare R2的 endpoint 路径写法需要调整。这三类变更分别对应监控面板/告警规则、指标语义一致性和第三方 S3 兼容服务配置三个场景下面逐一展开。移除废弃内部指标完整清单与替代方案被移除指标与替代品对照Vector 在多个历史版本中逐步废弃旧的内部指标目标是全面落地 Component Specification组件规范所定义的、每个组件必须输出的基础指标集。0.31.0 中以下指标被正式移除被移除的指标替代指标说明events_in_totalcomponent_received_events_total直接替代events_out_totalcomponent_sent_events_total直接替代processed_bytes_totalcomponent_received_bytes_total或component_sent_bytes_total按组件类型选择见下文processed_events_totalcomponent_received_events_total或component_sent_events_total按组件类型选择见下文processing_errors_totalcomponent_errors_total直接替代events_failed_totalcomponent_errors_total直接替代大部分替换是直接的唯一需要一点判断逻辑的是processed_前缀的两个指标规则是对 sourceprocessed_bytes_total由component_received_bytes_total替代processed_events_total由component_received_events_total替代对 sink则分别由component_sent_bytes_total和component_sent_events_total替代。为什么这样定义组件规范中的指标语义从仓库中的 Component Specification 可以看到这套指标的规范依据。该规范要求所有组件 MUST 发出ComponentEventsReceived事件其属性包含count事件数量与byte_size接收事件所有事件的估算 JSON 字节大小并对应 MUST 递增两个计数器component_received_events_total按count递增其他属性作为指标标签component_received_event_bytes_total按byte_size递增。批量发事件是被允许的规范明确“组件 MAY 按批发出事件以提升性能但结果遥测状态必须等价于逐事件发出”例如一次为 10 个事件发出EventsReceived事件component_received_events_total计数器必须递增 10。这正是升级时面板可以直接用新指标替换旧指标的语义保证。源码中的实现印证新指标的落地实现位于lib/vector-common的注册事件机制中。EventsReceived 事件定义 展示了每个组件收到事件后实际递增的三个指标ComponentReceivedEventsCount直方图统计每批事件数量分布ComponentReceivedEventsTotal计数器即component_received_events_totalComponentReceivedEventBytesTotal计数器即component_received_event_bytes_total。其emit方法将CountByteSize(count, byte_size)解构后分别写入直方图与两个计数器并记录一条 trace 级别的Events received.日志——这与组件规范中“MUST 记录 trace 级别日志且不得限频”的要求一致。指标名枚举与字符串映射定义在 metric_name.rs可以查到ComponentReceivedEventsTotal对应的正是component_received_events_total。迁移建议与一个注意事项如果你基于旧指标构建了 Prometheus/Grafana 面板或告警规则请按上表逐个替换processed_前缀指标需要先确认所在组件是 source 还是 sink再选择received或sent系列。官方文档中有一个重要提醒仍有少量组件在 0.31.0 中继续发出部分被废弃的指标原因是这些指标携带了组件规范不允许的额外标签和信息。这些组件的旧指标将在未来版本中移除因此从 0.31.0 起应视为它们已经不存在不要在任何监控逻辑中依赖它们继续存在。事件字节数指标统一为估算 JSON 大小变更内容在 0.31.0 之前Vector 各组件在计量所发送/接收事件字节数时口径并不一致不同组件可能按实际线上序列化格式比如 Protobuf、自定义 codec或其他方式计量导致跨组件比较没有意义。从 0.31.0 起component_received_event_bytes_total和component_sent_event_bytes_total在所有组件上统一改为输出“事件若被序列化为 JSON 时的估算大小”。这样做的价值在于无论 source 或 sink 对接外部服务时采用何种序列化格式字节数指标都有一个与组件无关、可在整个拓扑中一致比较的口径——例如比较同一 pipeline 中上游与下游的吞吐字节数时不再有口径偏差。源码中的计量方式仓库源码可以直接印证这一口径多处组件代码通过estimated_json_encoded_size_of()计算事件的估算 JSON 字节大小后再上报。例如 内存 enrichment table 的 source 中let json_size events.estimated_json_encoded_size_of(); events_received.emit(CountByteSize(count, json_size));计算结果与事件数量一起封装为CountByteSize交给上文提到的EventsReceived注册事件最终递增component_received_event_bytes_total计数器。组件校验运行器runner/mod.rs对输入/输出事件同样使用该估算 JSON 大小进行计量说明这一口径也贯穿了vector validate的遥测统计。对升级者的实际影响如果此前你的 source/sink 采用非 JSON 序列化格式如 Protobuf 压缩后更小、GELF 结构不同升级后该指标数值会发生变化因为口径从“实际发出的字节”变为“估算 JSON 大小”。涉及数据量统计的告警阈值例如“接收字节数超过某值”建议在升级后观察一段时间必要时按新口径重新标定。如果你需要反映真实网络传输量的指标应关注组件规范中另定义的SinkNetworkBytesSent/SourceNetworkBytesReceived一类网络层事件见 Component Specification 的 Instrumentation 章节而不是依赖事件字节数指标。AWS S3 端点路径变更变更内容aws_s3source 和 sink 对 AWS S3 endpoint 的处理方式发生了变化直接原因是 Vector 升级了其底层使用的 SDK。对 AWS 官方 S3 无影响但对 S3 兼容 API如 Cloudflare R2如果你此前在 endpoint 中写入了 bucket 名可能需要将其去掉。变更示例旧写法endpoint 带 buckethttps://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.com/bucket name新写法endpoint 不含 buckethttps://xxxxxxxxxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.combucket 名本身仍通过 source/sink 各自的bucket配置项指定endpoint 只指向 S3 兼容服务的基础地址。源码背景从源码结构看aws_s3 source 在构建 SDK 客户端时通过region.endpoint()解析出实际使用的端点let endpoint self.region.endpoint();再将该端点传给 AWS SDK 的 client 构建流程。升级 SDK 后端点解析遵循标准 S3 寻址规则endpoint 路径/虚拟主机形式的 bucket 寻址因此 endpoint 中再拼接 bucket 名会被 SDK 二次拼接指向错误地址。测试用例如 mod.rs 中的 RegionOrEndpoint 测试也验证了RegionOrEndpoint对 region 与显式 endpoint 的解析路径。升级检查清单全局搜索配置文件中aws_s3source/sink 的endpoint及region相关配置确认 endpoint 是否包含 bucket 名若使用的是 Cloudflare R2、MinIO 等 S3 兼容服务将 bucket 名从 endpoint 中移除升级后用实际读写验证source 拉取、sink 上传各一次确认 bucket 定位正确。升级小结0.31.0 的升级工作集中在三件事替换六个被移除的内部指标对照上表注意processed_前缀指标需按组件类型选择替代项且不要依赖仍由个别组件残留发出的旧指标、理解事件字节数指标的新口径统一为估算 JSON 大小阈值类告警需复查、修正 S3 兼容服务的 endpoint 写法去掉 endpoint 中的 bucket 名。完成这三步后监控体系即可与 0.31 的组件遥测规范Component Specification对齐后续版本迭代中组件指标的可预期性也会更强。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
