宣布OpenTelemetry的社区演示
简而言之
OpenTelemetry社区拿到了一个非常好的现有演示（感谢Google！）并且正在使其变得更好。除了Swift之外，每个GA SDK都将有所代表，演示支持将扩展到度量和日志，并且每个信号都将记录规范化的情景，并进行故障注入等等！
如果你想跳过细节，那么请克隆我们的仓库，然后从命令行运行 docker compose up1。还有一些技术要求，请务必查阅。
第一次构建演示可能需要15-20分钟，因此我们鼓励您在此期间做一些伸展运动并喝点水。
您的命令行输出应该如下所示：
- 一旦映像构建完成，您可以通过以下方式访问Web商店：http://localhost:8080
- 以及Jaeger UI：http://localhost:8080/jaeger/ui
恭喜！现在您可以尽情购物并提交遥测数据了。真正的胜利。
公共服务的成功
有一些普遍的问题推动着我们联合演示努力的驱动力。
随着OpenTelemetry的发展，用户和企业越来越需要关于如何将他们的服务接入新范式或演示应用程序的最佳实践指南，以便他们可以自己尝试新工具。然而，社区工作组和供应商缺乏一个既复杂又统一的平台来展示他们的技术。向世界打招呼只会让我们走得更远。
多个供应商编写了自己的演示应用程序，但他们完全负责其开发和持续支持。现有的演示应用程序都以自己的方式存在一些功能不完整的问题，缺少语言支持，对后端选择有限制，并且过分依赖于仪表化库。
项目目标
- 为开发人员提供一个强大的示例应用程序，用于学习OpenTelemetry仪表化。
- 为可观察性供应商提供一个单一的、得到良好支持的演示平台，供他们进一步定制或直接使用。
- 为OpenTelemetry社区提供一个展示OTel API、SDK和工具的特性和能力的活生生的作品。
- 为OpenTelemetry的维护者和工作组提供一个平台，以在真实世界的场景中演示新特性/概念。
目前的状态
作为一个起点，我们选择了流行的GCP微服务演示的一个分支。我们的首批特性增强是通过将项目合并到单个docker compose文件中、更新文档以及用Ruby示例替换一个现有服务来简化本地部署。除此之外，来自GCP演示的现有功能集保持不变：
- 10个应用微服务，支持6种语言（C#、Go、Java、Node.js、Python和Ruby）
- 在发布日期的最后两周内添加了Ruby支持
- 设计用于在本地使用Docker
- 使用Redis缓存
- 使用仪表化库进行的自动仪表化，支持gRPC、Redis和HTTP库的追踪
- 由OpenTelemetry collector转发的Jaeger分布式跟踪的可视化
- 始终开启采样（提交100%的遥测数据）以及合成负载生成
当前架构
自带后端（Bring Your Own Backend）
Jaeger很棒（真的），但如果您想尝试使用您选择的APM供应商进行操作呢？只需通过更改收集器配置文件使用他们的收集器导出器，或者使用供应商的我们的演示版本，您可以将数据发送到首选后端。
Lightstep在他们刚发布的博客中介绍了如何开始发送数据以支持他们从我们的演示版本分叉出来的体验。
未来的状态
即将推出的新功能
我们计划或正在进行许多令人激动的改进，将这个应用程序变成OpenTelemetry全部功能的典型示例。以下是一个几乎详尽的即将推出的功能列表，但我们不仅仅限于此处列出的项目。
- 各语言的示例，如C++、Erlang/elixir、PHP和Rust。
- 扩展对所有GA SDK的Metric和Log的支持。
- 用于消费度量的可视化组件。
- 实施多种仪表化技术。
- 使用辅助程序的自动仪表化。
- 手动仪表化所有信号。
- 服务水平目标（SLO）的定义和跟踪。
- 根据需要引入其他仪表化库。
- 展示添加Baggage和其他自定义标签的能力。
- 继续在其他云原生技术上构建，比如：
- Kubernetes
- gRPC
- OpenFeature
- OpenSLO
- 等等
- 改进的OpenTelemetry Collector网关的摄入、转换和导出能力。
- 基于概率的采样。
- 功能标志服务，用于演示故障注入等各种场景以及如何从依赖于功能标志的服务中发出遥测数据。
未来架构
未来的发展
我们仍然处于旅程的开始阶段，但项目背后有着强大的势头。如果您有兴趣进行贡献，我们非常欢迎您的支持。在我们的GitHub仓库中有参与的相关链接，您可以从那里跟踪我们的整体进展情况。
有趣的链接
-
docker-composeis deprecated. For details, see Migrate to Compose V2. ↩︎