2026年8月31日，OpenTelemetry Go发布v1.47.0-rc.1，正式将其Logs（日志）API与SDK推入发布候选（Release Candidate）阶段。官方博客明确表示，这标志着该设计进入最终阶段，下一步是提供稳定的v1兼容保证，并呼吁社区广泛测试验证。本文从DevOps与平台工程的视角，解读这一进展对可观测性实践的意义。
三支柱补齐：Go日志支点走向稳定
可观测性领域常以“追踪、指标、日志”三支柱描述观测数据。过去数年，OpenTelemetry在Go生态的Traces与Metrics已相对成熟，而Logs这一支柱长期滞后，需要团队自行拼接或依赖第三方方案。本次Logs API与SDK进入RC，意味着Go开发者有望在官方稳定保证下，用一套统一语义采集日志、追踪与指标，真正享受“一次埋点、多端可观测”的收益，也让不同语言的观测数据在统一面上对齐。
从RC到GA：需要团队做好的准备
RC是正式稳定发布前的最后一级，官方期望社区在真实场景中验证API设计与行为。对平台工程团队而言，这是提前评估、规划迁移的窗口期：在尚未提供v1兼容保证前，接口仍可能有微调，建议在测试环境先行试用，关注官方发布说明与变更记录；待正式GA后再决定生产环境的启用节奏。早尝鲜有助于把潜在迁移成本降到最低。
对可观测性底座与平台工程的意义
OpenTelemetry已成为可观测性的事实上标准，其Go日志支柱的成熟，进一步强化了“可观测性即基础设施”的落地。对连续构建内部开发者平台（IDP）、希望统一监控、告警与故障定位体验的团队，将日志纳入OTel标准采集，可以减少“日志系统 + 指标系统 + 追踪系统”割裂带来的重复成本，让生产问题的定位与告警链路更加连贯。
小结
OpenTelemetry Go日志API与SDK迈入发布候选，是Go可观测性走向三支柱完整、稳定的一次重要推进。对DevOps与平台工程团队，抓住RC阶段的评估窗口，能更好迎接随之而来的稳定发布。