作者：来自 Elastic Sherry Ger Alexander Wert
在混合企业环境中实现端到端可观测性是一项挑战，在这种环境中，现代云原生应用需要与关键但通常不透明的 IBM 主机系统进行交互。通过使用支持 OTel 输出的 IBM Z Observability Connect 并结合 Elastic Observability，可以提供一种解决方案，将你的主机黑盒转变为部署中一个完全可观测的组件。
引言：
OpenTelemetry 正在成为现代可观测性的标准。作为 Cloud Native Computing Foundation（ CNCF ）中一个高度活跃的项目 —— 仅次于 Kubernetes —— 它已经成为云原生应用的首选监控解决方案。OpenTelemetry 提供了一种统一的方法，用于在 Kubernetes、微服务和基础设施中采集 traces、metrics 和 logs。
然而，对许多企业来说 —— 尤其是在银行、保险、医疗和政府领域 —— 现实比 “云原生” 要复杂得多。尽管大多数组织已经部署了移动应用并采用了微服务架构，但其关键核心处理仍然依赖于 IBM 主机应用。这些 systems 负责处理信用卡刷卡、金融交易、患者记录以及保费计算。
这就带来了一个困境：在混合环境中，现代分布式 systems 已经被很好地观测，而关键的后端却仍然是一个黑盒。
“断裂的 Trace”
我们在客户中经常看到的一个常见挑战是：一个请求从现代移动应用发起，请求进入运行在 Kubernetes 上的微服务，随后调用主机上的服务，而此时，可见性突然中断。
当延迟飙升或事务失败时，Site Reliability Engineers（ SREs ）只能靠猜测：是网络问题？是 API gateway？还是底层的主机应用，比如 CICS？如果没有一个统一的端到端视图，无法把从前端 Node.js 微服务到后端 CICS 服务的所有组件串联起来，那么平均修复时间（ MTTR ）就会变成“平均自证清白时间”，团队只是在证明问题不在自己的微服务上，而不是解决根本原因。
我们需要一个统一的视图，让一个 trace 可以从云原生前端（比如 React ）一路无缝流入主机事务。
IBM Z Observability Connect
随着 Z Observability Connect 的最新发布，IBM 将 OpenTelemetry 原生的自动化埋点能力引入了主机应用。这在现代云原生服务与主机事务之间建立了一座桥梁。
这意味着主机不再是一个特殊案例；它的行为就像服务网格中的任何一个微服务一样。它作为一个 OpenTelemetry 数据生产者，向符合 OpenTelemetry 标准的后端（如 Elastic ）发送 traces、metrics 和 logs。
架构
整体架构非常直接：
- Collector：IBM Z Observability Connect 运行在 z/OS 上。它采集 logs、metrics 或 traces，并将它们转换为 OTLP（ OpenTelemetry Protocol ）格式。
- Processor：Elastic Cloud Managed OTLP Endpoint 作为网关 collector，提供完全托管、可扩展且可靠的原生 OTLP 摄取能力。
- Consumer：Elastic APM 提供 OpenTelemetry 原生的应用性能监控，使你可以快速定位并修复性能问题。
在 Kubernetes 中整合起来
我们在 Kubernetes 集群中部署一个 OpenTelemetry Collector。这个 collector 充当一个专用的网关。它被配置为直接接收来自主机上的 IBM Z Observability Connect 的 OTLP 流量，并通过使用 otlp/elastic exporter 将数据安全地转发到我们的可观测性后端 Elastic APM。
下面是 OpenTelemetry Collector 的配置。请注意 exporters 部分，它负责处理到 Elastic 的认证以及批量传输：
`
1. exporters:
2. # Exporter to print the first 5 logs/metrics and then every 1000th
3. debug:
4. verbosity: detailed
5. sampling_initial: 5
6. sampling_thereafter: 1000
8. # Exporter to send logs and metrics to Elasticsearch Managed OTLP Input
9. otlp/elastic:
10. endpoint: ${env:ELASTIC_OTLP_ENDPOINT}
11. headers:
12. Authorization: ApiKey ${env:ELASTIC_API_KEY}
13. sending_queue:
14. enabled: true
15. sizer: bytes
16. queue_size: 50000000 # 50MB uncompressed
17. block_on_overflow: true
18. batch:
19. flush_timeout: 1s
20. min_size: 1_000_000 # 1MB uncompressed
21. max_size: 4_000_000 # 4MB uncompressed
23. service:
24. extensions: [pprof, zpages, health_check]
25. pipelines:
26. traces:
27. receivers: [otlp]
28. processors: [batch]
29. exporters: [otlp/elastic, debug]
`AI写代码
注意：我们强烈建议使用环境变量来配置 endpoint 和 API key，以保证你的 manifest 安全。
为什么 OTel 规范很重要
Elastic 的托管 OTLP endpoint 和可观测性解决方案是基于原生 OTel 支持构建的，并且严格遵循 OTel 规范和语义约定。当我们把所有组件连接好并且数据开始流动之后，我们注意到 Elastic APM 中有一些 trace 的展示并不正确。
大多数可观测性解决方案都会为 trace 中最重要的 span 派生出所谓的 RED 指标（rate、error 和 duration），也就是每个服务的入站和出站 span。这使得我们无需翻阅所有 tracing 数据，就可以高效地了解服务性能，比如某个服务 endpoint 的延迟或出站请求的错误率。
为了高效计算某个服务入站 span 的这些派生指标，OTel 社区在 OTLP 协议中的 span 实体上引入了 SPAN_FLAGS_CONTEXT_HAS_IS_REMOTE_MASK 和 SPAN_FLAGS_CONTEXT_IS_REMOTE_MASK 标志。这些标志可以明确指示某个 span 是否是入口 span，从而让可观测性后端能够高效地为入口级别的 span 计算指标。
如果这些标志在入口 span 上被错误设置，那么这个 span 就无法被识别为入口 span，相应的指标也就无法正确派生 —— 从而导致体验受损。这正是我们最初在接入来自 IBM 主机的 OTel 数据时遇到的问题。
在一个封闭的专有体系中，这可能会变成死胡同，或者需要花费数月时间排查问题。但由于 OpenTelemetry 是一个开放标准，我们能够快速定位问题，并将发现反馈给 IBM 的工程师，他们也很快就提供了修复方案。
精简可观测性
我们现在已经实现了端到端可视化，从现代移动或 Web 应用一直深入到 IBM 主机。这解锁了巨大的价值：
- 统一服务地图：你可以直观地看到云原生购物车服务与运行在 z/OS 上的后端库存系统之间的依赖关系。
- 单一视图窗口： SREs 不再需要在现代可观测性工具和独立的主机监控工具之间来回切换来查看服务健康状况。
- 运维效率：通过消除 trace 中的“盲点”，你可以减少云端团队与主机团队之间的协调成本，让问题解决更快。
结论
如果你正在运行混合工作负载，现在是时候停止把主机当作黑盒了。借助 IBM Z Observability Connect、 Elastic 托管 OTLP Endpoint 以及 Elastic APM，你的整个技术栈终于可以使用同一种语言进行交流： OpenTelemetry。
