Vector 0.18 升级指南batch.max_size、request.in_flight_limit 等五项破坏性变更详解【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vectorVector 0.18.0 是一次包含五项**破坏性变更breaking changes**的版本升级涉及 sink 批量配置、源/汇并发配置、内置 HTTP 指标标签、metric_to_log转换的聚合摘要字段以及 Datadog metrics sink 的两个废弃配置项。本文基于仓库中随版本发布的官方升级文档 2021-11-18-0-18-0-upgrade-guide.md 展开结合当前仓库的源码与测试逐条说明变更背景、迁移方法和底层实现依据帮助你在升级 0.18 时快速、无歧义地调整现有配置。0.18.0 破坏性变更总览官方文档将本次发布中的全部破坏性变更归纳为以下五项序号变更影响组件迁移动作1batch.max_size不再有效所有支持批量batching的 sink改用batch.max_bytes或batch.max_events2request.in_flight_limit不再有效source 与 sink改名为request.concurrency3http_client_responses_total的status标签只保留数字状态码内置遥测指标调整下游按状态码分组/过滤的规则4metric_to_log聚合摘要aggregated summaries字段改名metric_to_log转换下游消费方将upper_limit改为q5移除 Datadog metrics sink 的废弃字段host、namespaceDatadog metrics sink改用endpoint与default_namespace下面逐条展开。一、batch.max_size从 sink 中移除变更背景0.18.0 正式移除了支持批量处理的 sink 上的batch.max_size参数。在早期版本中这个字段允许以通用的方式设置批量上限但它的实际含义由 sink 自行解释——有时表示字节数有时表示事件数。随着 sink 数量不断增加越来越多 sink 同时支持按字节 按事件双维度限制批量继续使用一个语义模糊的max_size会迫使用户去翻文档才能弄清该 sink 到底如何解释它。迁移方法如果当前配置中设置了batch.max_size需要替换为两个语义明确的字段之一想限制批量的字节大小→ 使用batch.max_bytes想限制批量的事件数量→ 使用batch.max_events。迁移示例以通用 sink 配置为示意sinks: my_sink: type: your_sink inputs: [my_source] # 旧0.18 之前含义随 sink 不同而不同 # batch: # max_size: 1000 # 新0.18 起语义明确 batch: max_events: 1000 # 按事件数限制 # max_bytes: 1000000 # 或按字节数限制按需二选一或同时使用源码层面的佐证从源码结构看批量上限最终统一由批量器batcher的限流器limiter来处理lib/vector-stream/src/batcher/config.rs 中定义了BatchConfigTtrait 与BatchConfigPartsL, D结构其中batch_limiter: L负责是否还能再塞一个元素进批量item_fits_in_batch/is_batch_full的判断timeout则控制单个批量的最长等待时间计时从批量收到第一个元素开始。也就是说按事件与按字节的限制在实现上对应不同的 limiter 类型配置层用max_events/max_bytes显式区分正是要与这一实现模型对齐。二、request.in_flight_limit从 source 与 sink 中移除变更背景与batch.max_size类似Vector 早已提供request.concurrency用于调整 source 与 sink 的并发度即同一时刻最多多少个请求在飞行中。request.concurrency是官方文档中统一引用的推荐字段而request.in_flight_limit只是它的历史别名。迁移方法从源码结构看request.concurrency与request.in_flight_limit在内部被同等对待因此迁移成本极低只需把配置中所有request.in_flight_limit直接改名为request.concurrency即可取值含义不变sinks: my_sink: type: your_sink inputs: [my_source] # 旧写法 # request: # in_flight_limit: 10 # 新写法内部处理完全一致 request: concurrency: 10三、http_client_responses_total的 status 标签只保留数字状态码变更背景内置指标http_client_responses_total带有status标签用于标识响应的 HTTP 状态码。此前该标签会带上规范化原因短语canonical reason例如把200 OK整体作为标签值这是一个实现上的疏漏oversight本意只应包含数字状态码。0.18 起status标签只包含数字码如200不再带OK这样的原因短语。迁移方法与影响面这一变更不影响 Vector 的数据管道本身但会影响下游指标系统的查询任何按status200 OK过滤或分组的 PromQL 表达式都需要改成status200。官方指出只保留数字码后分组聚合更容易——例如可以把所有2xx级别的状态码归到一类这在带原因短语时是无法用简单前缀匹配做到的。源码层面的佐证当前仓库的 HTTP 客户端内部事件实现印证了这一约定src/internal_events/http_client.rs 中通过let status self.response.status_u16();取响应状态码并以status %status的格式记录到事件字段——即只输出 u16 数字状态码不含任何原因文本。四、metric_to_log转换中聚合摘要字段改名upper_limit→q变更背景metric_to_log转换会把 metric 事件渲染为 log 事件其中聚合摘要aggregated summaries的渲染字段在 0.18 中做了调整原来用于存放分位数quantile的字段upper_limit被改为q。q是 quantile 的常用缩写更能表达该字段的真实含义。为什么改名是合理的upper_limit是 Vector 早期 metrics 支持的遗留命名它适用于聚合直方图aggregated histograms的桶边界桶上界但对聚合摘要来说上界的语义是错的——摘要里存的根本不是桶边界而是分位数值。源码层面的佐证与后续演进在当前仓库的 src/transforms/metric_to_log.rs 中可以看到这两类聚合结构的 schema 定义差异聚合直方图aggregated_histogrambuckets数组中每个桶仍保留upper_limitfloat与countinteger这与文档所述upper_limit适用于聚合直方图一致聚合摘要aggregated_summaryquantiles数组中每个元素为quantilefloat与valuefloat——注意这是当前0.18 之后持续演进代码中的形态同文件的测试断言如 src/transforms/metric_to_log.rs 中的aggregated_summary.quantiles[0].quantile、aggregated_summary.quantiles[0].value路径也印证了该渲染结构。可以推断0.18 中摘要字段不再借用upper_limit的设计在后续版本中进一步演化为更具描述性的quantile命名。如果你是从 0.17 或更早版本升级按本文档将摘要字段从upper_limit改为q若同时升级到了更新的版本还需以目标版本metric_to_log文档中的实际字段名为准直方图的upper_limit始终未变注意不要误改。五、移除 Datadog metrics sink 的废弃字段host与namespace变更背景Vector 持续清理配置与文档中的冗余cruft0.18 移除了 Datadog Metrics sink 中的两个已废弃配置字段host→ 由endpoint取代namespace→ 由default_namespace取代。迁移方法只需在配置中把旧字段替换为新字段即可sinks: dd_metrics: type: datadog_metrics inputs: [my_source] # 旧已废弃0.18 起不可用 # host: datadoghq.com # namespace: my.app # 新 endpoint: https://api.datadoghq.com # 完整的上报端点 default_namespace: my.app # 指标默认命名空间 api: key: ${DATADOG_API_KEY}当前仓库中 Datadog metrics sink 的配置定义见 src/sinks/datadog/metrics/config.rs其中仅保留endpoint与default_namespace等现行字段不再存在host/namespace与本文档描述一致。升级操作清单与验证建议将以上五步汇总为可执行的检查清单全局搜索配置中的max_size位于batch:段下按语义替换为batch.max_bytes字节或batch.max_events事件数全局搜索in_flight_limit统一改名concurrency所在的request:段无需其他改动检查所有依赖http_client_responses_total的仪表盘、告警规则把status标签值从200 OK形式改为纯数字形式并可用数字码做前缀级聚合如2xx检查消费metric_to_log输出尤其aggregated_summary相关字段的下游将upper_limit改为qaggregated_histogram.buckets[].upper_limit保持不变Datadog metrics sinkhost→endpointnamespace→default_namespace。完成配置改写后建议用 Vector 自带的配置校验能力做静态检查实现入口见 src/validate.rs确保字段名拼写与所在组件的可选配置项匹配后再滚动升级。适用前提与限制说明本文所有结论以 0.18.0 升级文档website/content/en/highlights/2021-11-18-0-18-0-upgrade-guide.md为准其中metric_to_log部分关于q字段的描述对应 0.18 当时形态当前仓库代码显示该命名后续又演进为quantile见上文第四节跨多个小版本升级时请以目标版本文档为准。源码佐证部分batcher trait、HTTP 事件、Datadog 配置反映的是当前仓库 HEAD 的实现用于印证 0.18 变更方向不代表 0.18 时代的逐行代码。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vector 0.18 升级指南：batch.max_size、request.in_flight_limit 等五项破坏性变更详解
Vector 0.18 升级指南batch.max_size、request.in_flight_limit 等五项破坏性变更详解【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vectorVector 0.18.0 是一次包含五项**破坏性变更breaking changes**的版本升级涉及 sink 批量配置、源/汇并发配置、内置 HTTP 指标标签、metric_to_log转换的聚合摘要字段以及 Datadog metrics sink 的两个废弃配置项。本文基于仓库中随版本发布的官方升级文档 2021-11-18-0-18-0-upgrade-guide.md 展开结合当前仓库的源码与测试逐条说明变更背景、迁移方法和底层实现依据帮助你在升级 0.18 时快速、无歧义地调整现有配置。0.18.0 破坏性变更总览官方文档将本次发布中的全部破坏性变更归纳为以下五项序号变更影响组件迁移动作1batch.max_size不再有效所有支持批量batching的 sink改用batch.max_bytes或batch.max_events2request.in_flight_limit不再有效source 与 sink改名为request.concurrency3http_client_responses_total的status标签只保留数字状态码内置遥测指标调整下游按状态码分组/过滤的规则4metric_to_log聚合摘要aggregated summaries字段改名metric_to_log转换下游消费方将upper_limit改为q5移除 Datadog metrics sink 的废弃字段host、namespaceDatadog metrics sink改用endpoint与default_namespace下面逐条展开。一、batch.max_size从 sink 中移除变更背景0.18.0 正式移除了支持批量处理的 sink 上的batch.max_size参数。在早期版本中这个字段允许以通用的方式设置批量上限但它的实际含义由 sink 自行解释——有时表示字节数有时表示事件数。随着 sink 数量不断增加越来越多 sink 同时支持按字节 按事件双维度限制批量继续使用一个语义模糊的max_size会迫使用户去翻文档才能弄清该 sink 到底如何解释它。迁移方法如果当前配置中设置了batch.max_size需要替换为两个语义明确的字段之一想限制批量的字节大小→ 使用batch.max_bytes想限制批量的事件数量→ 使用batch.max_events。迁移示例以通用 sink 配置为示意sinks: my_sink: type: your_sink inputs: [my_source] # 旧0.18 之前含义随 sink 不同而不同 # batch: # max_size: 1000 # 新0.18 起语义明确 batch: max_events: 1000 # 按事件数限制 # max_bytes: 1000000 # 或按字节数限制按需二选一或同时使用源码层面的佐证从源码结构看批量上限最终统一由批量器batcher的限流器limiter来处理lib/vector-stream/src/batcher/config.rs 中定义了BatchConfigTtrait 与BatchConfigPartsL, D结构其中batch_limiter: L负责是否还能再塞一个元素进批量item_fits_in_batch/is_batch_full的判断timeout则控制单个批量的最长等待时间计时从批量收到第一个元素开始。也就是说按事件与按字节的限制在实现上对应不同的 limiter 类型配置层用max_events/max_bytes显式区分正是要与这一实现模型对齐。二、request.in_flight_limit从 source 与 sink 中移除变更背景与batch.max_size类似Vector 早已提供request.concurrency用于调整 source 与 sink 的并发度即同一时刻最多多少个请求在飞行中。request.concurrency是官方文档中统一引用的推荐字段而request.in_flight_limit只是它的历史别名。迁移方法从源码结构看request.concurrency与request.in_flight_limit在内部被同等对待因此迁移成本极低只需把配置中所有request.in_flight_limit直接改名为request.concurrency即可取值含义不变sinks: my_sink: type: your_sink inputs: [my_source] # 旧写法 # request: # in_flight_limit: 10 # 新写法内部处理完全一致 request: concurrency: 10三、http_client_responses_total的 status 标签只保留数字状态码变更背景内置指标http_client_responses_total带有status标签用于标识响应的 HTTP 状态码。此前该标签会带上规范化原因短语canonical reason例如把200 OK整体作为标签值这是一个实现上的疏漏oversight本意只应包含数字状态码。0.18 起status标签只包含数字码如200不再带OK这样的原因短语。迁移方法与影响面这一变更不影响 Vector 的数据管道本身但会影响下游指标系统的查询任何按status200 OK过滤或分组的 PromQL 表达式都需要改成status200。官方指出只保留数字码后分组聚合更容易——例如可以把所有2xx级别的状态码归到一类这在带原因短语时是无法用简单前缀匹配做到的。源码层面的佐证当前仓库的 HTTP 客户端内部事件实现印证了这一约定src/internal_events/http_client.rs 中通过let status self.response.status_u16();取响应状态码并以status %status的格式记录到事件字段——即只输出 u16 数字状态码不含任何原因文本。四、metric_to_log转换中聚合摘要字段改名upper_limit→q变更背景metric_to_log转换会把 metric 事件渲染为 log 事件其中聚合摘要aggregated summaries的渲染字段在 0.18 中做了调整原来用于存放分位数quantile的字段upper_limit被改为q。q是 quantile 的常用缩写更能表达该字段的真实含义。为什么改名是合理的upper_limit是 Vector 早期 metrics 支持的遗留命名它适用于聚合直方图aggregated histograms的桶边界桶上界但对聚合摘要来说上界的语义是错的——摘要里存的根本不是桶边界而是分位数值。源码层面的佐证与后续演进在当前仓库的 src/transforms/metric_to_log.rs 中可以看到这两类聚合结构的 schema 定义差异聚合直方图aggregated_histogrambuckets数组中每个桶仍保留upper_limitfloat与countinteger这与文档所述upper_limit适用于聚合直方图一致聚合摘要aggregated_summaryquantiles数组中每个元素为quantilefloat与valuefloat——注意这是当前0.18 之后持续演进代码中的形态同文件的测试断言如 src/transforms/metric_to_log.rs 中的aggregated_summary.quantiles[0].quantile、aggregated_summary.quantiles[0].value路径也印证了该渲染结构。可以推断0.18 中摘要字段不再借用upper_limit的设计在后续版本中进一步演化为更具描述性的quantile命名。如果你是从 0.17 或更早版本升级按本文档将摘要字段从upper_limit改为q若同时升级到了更新的版本还需以目标版本metric_to_log文档中的实际字段名为准直方图的upper_limit始终未变注意不要误改。五、移除 Datadog metrics sink 的废弃字段host与namespace变更背景Vector 持续清理配置与文档中的冗余cruft0.18 移除了 Datadog Metrics sink 中的两个已废弃配置字段host→ 由endpoint取代namespace→ 由default_namespace取代。迁移方法只需在配置中把旧字段替换为新字段即可sinks: dd_metrics: type: datadog_metrics inputs: [my_source] # 旧已废弃0.18 起不可用 # host: datadoghq.com # namespace: my.app # 新 endpoint: https://api.datadoghq.com # 完整的上报端点 default_namespace: my.app # 指标默认命名空间 api: key: ${DATADOG_API_KEY}当前仓库中 Datadog metrics sink 的配置定义见 src/sinks/datadog/metrics/config.rs其中仅保留endpoint与default_namespace等现行字段不再存在host/namespace与本文档描述一致。升级操作清单与验证建议将以上五步汇总为可执行的检查清单全局搜索配置中的max_size位于batch:段下按语义替换为batch.max_bytes字节或batch.max_events事件数全局搜索in_flight_limit统一改名concurrency所在的request:段无需其他改动检查所有依赖http_client_responses_total的仪表盘、告警规则把status标签值从200 OK形式改为纯数字形式并可用数字码做前缀级聚合如2xx检查消费metric_to_log输出尤其aggregated_summary相关字段的下游将upper_limit改为qaggregated_histogram.buckets[].upper_limit保持不变Datadog metrics sinkhost→endpointnamespace→default_namespace。完成配置改写后建议用 Vector 自带的配置校验能力做静态检查实现入口见 src/validate.rs确保字段名拼写与所在组件的可选配置项匹配后再滚动升级。适用前提与限制说明本文所有结论以 0.18.0 升级文档website/content/en/highlights/2021-11-18-0-18-0-upgrade-guide.md为准其中metric_to_log部分关于q字段的描述对应 0.18 当时形态当前仓库代码显示该命名后续又演进为quantile见上文第四节跨多个小版本升级时请以目标版本文档为准。源码佐证部分batcher trait、HTTP 事件、Datadog 配置反映的是当前仓库 HEAD 的实现用于印证 0.18 变更方向不代表 0.18 时代的逐行代码。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考