探索 Mainframe 的 OpenTelemetry 优先级 - 来自调查回复的见解
用户认为哪些 OpenTelemetry 功能对于增强大型机的可观察性最为重要？今年早些时候，OpenTelemetry on Mainframes 特别兴趣小组 (SIG) 和 Open Mainframe Project 进行了一项调查来回答这个问题。本文博客详细概述了调查结果。
背景和目的
OpenTelemetry 项目旨在通过提供高质量、可移植的遥测数据，从任何源到任何目标，从而实现有效可观察性。该项目目前在GitHub上托管 90 个代码库，涵盖规范和实现。当 OpenTelemetry on Mainframes SIG 成立时，它给自己设定了使命，即为大型机启用最重要的 OpenTelemetry 组件，并专注于三个关键领域：语义约定、编程语言 SDK 和 OpenTelemetry Collector 的增强。考虑到 OpenTelemetry 项目的广泛范围和大型机的复杂架构，很明显，透彻理解用户优先级对于充分利用大型机上的 OpenTelemetry 功能至关重要。随着调查结果的可用，SIG 将优先考虑并实施有针对性的活动，以加速 OpenTelemetry 在大型机平台上的采用。
主要见解
以下是优先处理大型机 SIG 活动的主要见解
- 提升大型机社区内的 OpenTelemetry 专业知识。在 26 名 OpenTelemetry 初学者中，有 21 名拥有十多年的大型机经验，但仍有 11 名表示不了解其功能。
- 优先考虑系统性能指标的语义约定，其次是作业处理、数据库和应用程序。在受访者中，30 人希望 OpenTelemetry 首先关注指标，当被问及指标类别时，约 32 人强调系统指标是主要优先事项。
- 优先考虑 z/OS 的 Java 和 Python SDK，并开发 COBOL SDK。所有想要 Java (25) 和 Python (20) SDK 的受访者也需要 z/OS 的 OpenTelemetry SDK。COBOL SDK 被 26 人请求，其重要性与 Java SDK 相当。
- 评估使用 OpenTelemetry Collector 收集系统性能和平台指标的方法。根据回复，30 名参与者表示有兴趣在部署为代理时让 OpenTelemetry Collector 收集系统性能和平台指标。28 人将大型机运维指定为主要用户，27 人认为以 OpenTelemetry 格式生成的系统性能指标对他们的组织最重要。
贡献方式
我们邀请贡献者和组织加入 OpenTelemetry on Mainframes SIG。承担调查优先事项的责任，并成为 OpenTelemetry 项目的贡献者。例如，参与我们的代码插桩和移植计划
- 支持为 linux/s390x 集成自托管的 GitHub Action Runner，以实现持续集成和交付，以及对 s390x 平台上 OpenTelemetry 组件的自动化验证
- 扩展 SDK 在 zos/s390x 和 linux/s390x 上的社区支持：确保选定的 OpenTelemetry SDK 在 z/OS 和 Linux on s390x 上得到全面支持和维护
- 为 s390x 平台实现 SDK 优化：为性能和兼容性改进做出贡献，释放 OpenTelemetry 在大型机上的全部潜力
- 启用 OpenTelemetry 对 COBOL 的支持：合作开发一个健壮的 COBOL SDK，为遗留应用程序提供现代可观察性功能
方法论
本次调查分为两个部分。第一部分收集了关于受访者角色和背景的信息。第二部分收集了受访者组织在大型机上启用 OpenTelemetry 的优先级。总共有 20 个问题供受访者回答。调查开放两个月，从一月中旬开始，并通过 OpenTelemetry 和 Open Mainframe Projects 的博客以及大型机会议进行推广。调查收到了 45 份回复。所有回复都包含在结果中。仅应用了最少的数据清理。由于只有 45 份回复，样本量太小，无法得出统计上具有代表性的结果。组织不应以此为基础做出决策。尽管如此，该调查提供了关于优先事项的初步见解，大型机 SIG 将利用这些见解来指导其部分活动，如上所述。
全面的回复
问题 1：您在组织中的主要角色是什么？
收到的回复来自各种不同的角色。一半以上的回复（26 个）来自经理、IT 和软件架构师以及系统程序员（包括表明有多个角色的回复）。其中大多数（22 人）在大型机方面拥有超过 10 年的经验。
问题 2：您有多少年处理大型机系统的经验？
大多数受访者（33 人）在处理大型机方面拥有超过 10 年的经验。只有四人声称在 OpenTelemetry 方面拥有专家或高级知识。相反，在拥有不到四年大型机经验的六名受访者中，有四人将自己定位为 OpenTelemetry 专家或高级实践者。总的来说，绝大多数回复表明调查参与者拥有大型机背景。
问题 3：您组织的生产行业是哪个？
绝大多数受访者来自金融服务行业（45 个总回复中的 22 个）。一小部分人来自各种物流行业（共 8 个）。13 名受访者主要从事软件和 IT 相关领域，如软件开发、独立软件供应商 (ISV)、服务提供商、IBM zStack 软件、可观察性和信息技术 (IT)。
问题 4：您使用以下哪些大型机平台？
z/OS 是所有受访者（除一人外，他专注于 IBM Z 上的 Linux）都使用的大型机操作系统。约三分之一的受访者（17 人）使用 IBM Z 上的 Linux。z/VM 作为虚拟化平台被八名受访者使用。一名受访者声称使用所有操作系统，包括 z/VSE 和 zTPF。
问题 5：您使用哪些 z/OS 系统软件？
大多数受访者（38 人）使用交易处理系统 CICS 或 IMS，或两者都使用。39 名调查参与者使用 Db2，31 人使用 VSAM，而相当一部分受访者还使用 ADABAS、IDMS、DVM 或 Datacom 作为数据后端。
问题 6：您对 OpenTelemetry 的熟悉程度如何？
OpenTelemetry 采用的初学者（26 人）是受访者中最大的群体。其中 15 人不熟悉任何 OpenTelemetry 功能或组件。只有三人是专家，而所有拥有中级知识的参与者也声称熟悉 OpenTelemetry Collector。
问题 7：您熟悉 OpenTelemetry 的哪些功能和组件？
大约一半的调查参与者熟悉 OpenTelemetry Metrics (24) 和 OpenTelemetry Collector (22)。在信号类型方面，虽然指标的受访者熟悉度最高，但日志 (20) 和分布式跟踪 (17) 也紧随其后。上下文传播和采样作为与分布式跟踪相关的补充技术，知名度略低。代码插桩（零代码和手动）只有约四分之一的受访者知道。语义约定和 API 规范也是如此。只有少数参与者熟悉 Kubernetes Operator 和 Open Agent Management Protocol，他们将自己定位为对 OpenTelemetry 至少有中级知识，如果不算是高级或专家级别。
问题 8：您是否使用可观察性或性能监控工具？
四分之三的受访者声称使用可观察性或性能监控工具（35 人）。大多数用户可以查看大型机平台（30 人）。在同时为分布式和大型机平台使用工具的受访者（19 人）中，三分之二声称花费 20% 以上的时间进行可观察性和监控活动（13 人），其中五人几乎全职从事这些活动（占其时间的 80% 以上）。
问题 9：您有多少时间用于可观察性或性能监控活动？
约四分之一的受访者（11 人）将 60% 以上的时间用于可观察性或性能监控活动。大多数调查参与者（19 人）的参与度不到 20%，这可能归因于他们的工作职责性质。其中十二人声称熟悉 OpenTelemetry，高于初学者水平。
问题 10：您组织中的可观察性策略的关键特征是什么？
实时分析 (35) 和端到端可见性 (33) 是受访者组织的主要目标，其次是开放标准 (26) 及其支持的能力：上下文和关联 (22)、工具选择灵活性 (19) 和统一数据处理 (19)。一名受访者明确添加了碳账户。
问题 11：在 OpenTelemetry 格式下，您首先需要在大型机上支持哪种信号类型？
在调查参与者中，指标是 OpenTelemetry 在大型机上支持的最重要的信号类型 (30)，其次是日志 (20) 和跟踪 (18)。
问题 12：您组织中谁将是 OpenTelemetry 格式的大型机遥测的主要用户？
受访者认为大型机运维是 OpenTelemetry 格式大型机遥测的主要用户。在优先考虑大型机运维的受访者群体中，80% 的人拥有七年以上的大型机工作经验。值得注意的是，有 22 人拥有十多年的经验，这表明即使是经验丰富的平台用户，也倾向于简化大型机遥测的消耗方法。SRE（21 人）和应用程序开发人员（19 人）构成了第二批受益于 OpenTelemetry 格式大型机遥测的用户群，随后是组织中各个领域的其他角色。
问题 13：您组织中最重要的是要以 OpenTelemetry 格式生成的指标类别是哪个？
对于大多数受访者而言，OpenTelemetry 支持系统性能指标 (32)，结合各种其他工作负载和基础设施相关指标是最重要的。作业和批处理 (27)、数据库 (27) 和应用程序 (27) 指标被调查参与者同等重视，其次是网络 (24)、I/O (21)、存储 (20) 和容量规划 (19) 的基础设施指标。虽然其他指标领域获得的选票较少，但结果凸显了支持这些领域的大量兴趣。例如，多名受访者表示对 DevOps 和 CI/CD 指标以及环境、能源和可持续性指标感兴趣。
问题 14：在您的组织中，以 OpenTelemetry 格式导出大型机遥测的主要用例是什么？
在端到端可见性已被确定为组织可观察性策略的重要目标之后，受访者在列出 OpenTelemetry 支持大型机遥测的用例时对其进行了确认。跨着陆区的端到端可见性 (28) 和改进的事件管理 (28) 被视为主要用例。其他列出的用例对至少四分之一的调查参与者很重要，其中一些用例（如应用程序性能优化 (22) 和主动问题确定与预测分析 (21)）几乎对一半的受访者都很相关。碳核算只有一个投票，因为它是由一名受访者添加的重要用例。
问题 15：对于哪些应用程序部署模型，您最需要使用 OpenTelemetry 进行插桩？
调查参与者希望优先对在线交易处理 (30) 进行 OpenTelemetry 插桩，其次是批处理 (23)、以数据库为中心的应用程序 (19) 和其他应用程序部署模型。分析和人工智能工作负载 (10) 以及云原生、容器化工作负载 (7) 的插桩是部分受访者的关注点，突显了大型机上较新的应用程序部署模型日益增长的使用情况。
问题 16：您组织需要为哪些现有的 OpenTelemetry SDK 提供大型机支持？
Java (25) 和 Python (20) 是在大型机平台上实现 OpenTelemetry SDK 支持的优先级最高的两种编程语言。20% 的受访者希望在大型机平台上提供 C++ SDK。
问题 17：您的组织还需要哪些其他语言的 OpenTelemetry SDK？
COBOL 是大多数受访者 (26) 希望开发 OpenTelemetry SDK 的大型机编程语言。COBOL SDK 主要由拥有七年以上大型机经验的调查参与者请求，但也由五名拥有不到三年经验的受访者请求。超过 40% 的受访者在调查回复中请求 REXX 和 JCL 的 SDK。超过四分之一的调查参与者请求 HLASM 的 OpenTelemetry SDK，20% 请求 PL/1 和 C SDK。三人表示对 Metal C 的 SDK 感兴趣。
问题 18：您的组织需要为哪些大型机操作系统提供 OpenTelemetry SDK 支持？
根据受访者使用的操作系统，他们表达了对相应平台 OpenTelemetry SDK 的兴趣。z/OS 作为 OpenTelemetry SDK 的支持平台对受访者最重要 (35)，其次是 IBM Z 上的 Linux (13)，zTPF 只有一项选择。
问题 19：OpenTelemetry Collector 的哪些功能对贵组织启用大型机遥测的处理和分发最感兴趣？
OpenTelemetry Collector 的数据收集功能对调查参与者最重要。在代理部署中使用 Collector 进行本地数据收集 (20) 和使用接收器从任何系统收集数据 (19) 在回复中得分最高。此外，指标的数据聚合对受访者来说也很重要 (20)。数据处理 (15) 和导出 (16)、跟踪采样 (14) 和网关部署 (14) 对超过 30% 的受访者感兴趣。硬件压缩和加密对九名调查参与者很重要。
问题 20：您设想在大型机上使用 OpenTelemetry Collector 进行系统级遥测收集和处理的用例是什么？
在评估 OpenTelemetry Collector 时，受访者将系统性能和平台指标的收集作为最重要的用例 (30)。系统日志的收集和资源检测的大型机支持被约一半的调查参与者认为是重要的。来自 Kubernetes 和容器运行时的 OTel Collector 数据收集是部分受访者的关注点，他们对此类用例感兴趣。
摘要
调查结果显示，大多数大型机从业者对 OpenTelemetry 是新手，他们优先考虑系统性能指标用于采用。需要 Java、Python 和 COBOL SDK，以及 Collector 支持。这些发现突显了对教育、语义约定以及将 OpenTelemetry 组件移植到大型机平台的有针对性努力的必要性。
加入 OpenTelemetry on Mainframe SIG，为语言 SDK、插桩和社区专业知识做出贡献，这将加速 OpenTelemetry 在大型机上的采用。通过 Slack 频道 #otel-mainframes 或周三上午 10:00 PT 的 SIG 会议与 SIG 成员联系。
本文的一个版本最初发布在 Open Mainframe Project 博客上。