懒人开发者指南：观察自己的代码
内容提要
开发者使用OpenTelemetry为应用添加可观测性虽增加工作量，但能减少调试时间、加速开发、改善代码质量并理解分布式系统。建议从零代码插桩开始，辅以手动插桩，并利用AI辅助。文章还介绍了OpenTelemetry Collector配置及OTel Desktop Viewer、otel-tui、OTel Front三种开源可视化工具，帮助开发者本地查看遥测数据。
延伸解读
零代码插桩的适用边界
文章指出，零代码插桩目前仅支持Java、.NET、Python、JavaScript、PHP和Go等语言，而Rust、Elixir等语言缺乏支持，需要手动插桩。这意味着开发者需先确认所用语言是否具备零代码能力，否则需从零开始手动插桩，增加上手难度。零代码插桩虽能快速起步，但无法覆盖业务关键逻辑，仍需手动补充。
AI辅助插桩的实践要点
文章强调，AI辅助插桩需遵循具体、挑战、迭代的原则。具体指提供角色、目标、输入输出等上下文；挑战指要求AI解释决策，甚至用不同模型作为“法官”来审查；迭代指不断调整提示词和代码。作者认为，AI能加速探索和减少摩擦，但需正确使用，否则可能产生低质量代码。
本地可视化工具的选择考量
文章对比了三款开源工具：OTel Desktop Viewer仅支持traces，otel-tui支持traces、logs、metrics且具备服务拓扑图，OTel Front支持traces、logs、metrics但仪表盘不可点击。开发者应根据需求选择，并注意这些工具存在配置复杂、依赖第三方维护、与最新OpenTelemetry特性不完全同步等挑战。
开发者自建Collector的价值
文章认为，即使平台团队提供自助工具，开发者仍应了解OpenTelemetry Collector的工作原理和配置方法，因为它是生态系统的关键组件。掌握Collector的接收器、处理器、导出器和管道等概念，有助于开发者独立调试和排查问题，避免完全依赖平台团队。
Q&A
为什么开发者应该关注可观测性？
可观测性可以帮助开发者减少调试时间、加速开发和部署、改善代码质量、理解分布式系统，以及理解AI生成的代码。
OpenTelemetry 插桩有哪些常见痛点？
常见痛点包括：依赖特定SDK社区的努力、某些语言缺少自动插桩导致手动插桩困难、插桩选项过多且项目不够成熟、公共API稳定性问题以及升级依赖痛苦等。
如何开始使用 OpenTelemetry 插桩？
建议从零代码插桩开始，然后补充手动插桩来填补空白，并实践可观测性驱动开发（ODD），即边写代码边插桩。
应该对哪些内容进行插桩？
应该对有意义的工作单元添加span，如入站请求、出站调用和关键业务操作；在日志中记录错误、验证失败、重试和回退路径以及安全事件；捕获延迟指标；对自研框架和库进行插桩。
如何使用 AI 辅助 OpenTelemetry 插桩？
使用AI辅助插桩时，要提供具体上下文（如角色、目标、输入、输出），挑战AI的决策（如用LLM-as-judge），并迭代优化。
OpenTelemetry Collector 的主要组件有哪些？
Collector 由接收器（Receivers）、处理器（Processors）、导出器（Exporters）和管道（Pipelines）组成，还有连接器（Connectors）用于连接管道。
有哪些本地可视化 OpenTelemetry 数据的开源工具？
有三种开源工具：OTel Desktop Viewer（仅支持traces，Web UI）、otel-tui（支持traces、logs、metrics，文本界面）、OTel Front（支持traces、logs、metrics，Web UI）。
使用这些可视化工具时遇到了哪些挑战？
挑战包括：设置和使用难度较大、依赖第三方维护、与最新OpenTelemetry API/SDK的兼容性可能不佳。
