otel-upgrade

OpenTelemetry 升级

根据仓库中可用的证据，找出支持的最高稳定目标版本，并提供简洁且针对具体情况的升级建议。除非用户要求实施，否则评估升级时不要更改项目文件。

选择工作流

请求或仓库证据	阅读
软件包清单、锁定文件、API、SDK、插桩库、导出器、插件或依赖约束	依赖升级
Collector 二进制文件、镜像、图表、Operators、配置、功能门、组件、OCB 清单、构建或运行时行为	Collector 升级
涉及独立版本或第三方模块的自定义 Collector	先阅读 Collector 工作流，再阅读依赖工作流，了解相关模块约束。

只阅读适用的参考文档。若升级涉及两方面，则两者都要阅读。

通用说明

1. 在选择工作流或假设生态系统之前，先检查仓库和运行时证据。
2. 确定确切的当前版本和候选版本。分别记录封装器、发行版、构件和内嵌依赖，不要把某一个版本当作其他版本的证明。
3. 查询权威注册表和上游带标签的主要来源，获取当前稳定版本。记录查询日期。将候选发布版、Beta/Alpha 软件包、每夜构建构件和未打标签的源码视为预发布版本；除非该软件包系列有意使用预发布标识发布，否则不要默认用不同系列的稳定软件包替换项目现有的实验性软件包系列。如果没有满足既定要求的稳定版本，则单独评估预发布版本并明确标注。
4. 区分“最新可用”稳定版本与“经过验证且兼容的最高版本”候选项。若无法运行相关检查，不要称候选项已通过验证。
5. 在临时副本、工作树或同等隔离环境中验证，以保护用户的工作树。先从最新稳定候选版本开始。如果失败，诊断原因，并在有用时测试选定的较低版本；不要假设兼容性会随版本单调变化。
6. 将上游变更与此仓库的实际用法和可用的下游约定关联起来。对于无法访问的使用方、环境和确切版本覆盖范围，应标记为未经验证。
7. 仅在有适用的专用技能时使用。否则，使用上游主要来源和仓库证据，并报告由此产生的验证缺口。

依赖解析、编译、配置验收和测试通过，分别只能证明不同且有限的内容。准确说明每项结果所能证明的内容。

报告

报告应简洁，并针对仓库的具体情况。

## Recommendation

Recommend upgrading `<subject>` from `<current>` to `<target>`, remaining on `<current>`, or deferring the upgrade. Explain the evidence, effort, and risk.

## Relevant Findings

- `<Material finding>` — explain its effect on this repository and any required action.

## Proposed Upgrade Path

Give the smallest coordinated sequence of dependency, artifact, code, configuration, and rollout changes.

## Validation

State the exact candidates, artifacts, configurations, platforms, and checks covered, their results, and what those results demonstrate.

## Remaining Risk

Mention only material behavior, environments, integrations, consumers, or artifacts that could not be verified. Omit this section when no material unverified areas were identified.

对于重要的上游声明，请链接到权威的发行说明、文档或源码。如果最新可用版本并非经过验证且兼容的最高版本，请列出两者并说明阻碍因素。