一笔交易，三个字段名称：使用 ECS 修复大型机数据

这份字段指南介绍了我在生产环境中看到过的有效摄取架构、决定你的仪表板是否真正有效的数据质量检查，以及让大型机数据可供平台使用的 ECS 映射。

大型机团队希望拥有其他可观测性团队已经具备的能力：异常检测、针对批处理窗口的机器学习（ML），以及在真正出现问题时触发的告警。大多数团队已经拥有实现这些功能所需的数据。他们缺少的是平台能够识别为统一、互联且具有运营意义的数据。

一位客户这样向我描述：一笔交易在经过大型机的过程中会流经三个产品，而每个产品对同一个字段使用不同的名称（系统名称、程序名称、用户）。将数据导入 Elastic 并不是难点；难点在于让数据能够跨产品进行关联，使 Elastic 的仪表板和 ML 作业能够识别这些数据实际上是同一类数据，这也是大多数项目未能达到预期的地方。

如果正确完成，Elastic 将成为大型机环境一直缺少的速度层：跨运营、交易和安全数据的近实时视图，同时权威记录系统保持完全不变。

这是我与大型机客户一起使用的接入流程，它基于大型金融机构中正在生产环境运行的架构构建。它涵盖了实际有效的摄取模式、Elastic 通用模式（ECS）对齐如何让数据可用，以及数据质量是否能够保持稳定还是会悄无声息地失败。

在编写管道之前验证你的大型机源数据

我在大型机摄取项目中看到的最昂贵的失败，往往是那些没有明显失败迹象的情况。管道正常运行，数据成功写入，仪表板正常呈现，但几周后，某人发现来自某个逻辑分区（LPAR）的半数事件从未被解析，或者某个隐蔽的类型变化一直在悄悄破坏某个字段。

两个问题经常出现：

LPAR 和时间窗口之间的格式不一致：日志格式会因 LPAR、批处理窗口和在线窗口，以及不同交接班时间而变化。在开发 LPAR 中可以正常解析的格式，可能无法匹配生产环境在高峰批处理期间生成的格式。这是我遇到的部分解析失败中最常见的原因。
将示例配置当作生产配置使用：导致 "它一夜之间坏了" 事件的常见原因是：上游采集器配置基于供应商提供的示例结构，然后从未替换为经过设计的生产配置。当供应商推送更新时，命名和类型发生变化（字段重命名、类型变化），下游管道开始在处理过程中拒绝记录。将示例配置仅仅视为示例，并将其替换为经过设计的生产配置，避免配置在你不知情的情况下发生变化。

在开始任何管道开发之前，与大型机团队一起检查每个数据源 24--48 小时的原始样本。这项检查应该被视为持续性的要求，而不是一次性事件，因为导致格式漂移的情况（供应商更新、配置更改、新消息类型）会在项目上线后持续发生。

首先需要了解的一点 ：对于大型机环境，Elastic 集成目录中的选项较少。IBM MQ 集成是最完整的选择（包括队列管理器错误日志和性能指标，与 ECS 对齐，并提供开箱即用的仪表板），不过指标数据流需要使用容器化 MQ 分发版本，而不是原生 z/OS MQ。如果你的架构包含客户信息控制系统（CICS）工作负载，或者你需要端到端分布式追踪，请在构建自定义管道之前评估 IBM Z Observability Connect：它是原生 OpenTelemetry（OTel）路径，并且覆盖范围比下面介绍的架构更广。对于其他情况，请继续阅读。

ECS 对齐：从 Elastic 中的数据到 Elastic 可以使用的数据

在选择摄取策略之前，值得先了解为什么在实践中 ECS 对齐应该优先考虑，即使管道稍后才构建。这是决定其他所有工作是否能够产生价值的关键决策。

大型机团队的核心任务：追踪一次完整交易，从 REST 调用进入 z/OS Connect，经过信息管理系统（IMS）应用程序，再返回的整个过程。该流程会涉及三个产品，每个产品都会针对相同概念（系统名称、程序名称、用户、交易 ID）使用自己的字段名称生成遥测数据。如果没有标准化，关联该交易就意味着需要编写查询，明确联合每个概念对应的三个不同字段名称。当任何产品更改其架构时，这种方式编写成本高，并且容易出错。

ECS 解决了这个问题。它定义了一套一致的目标架构（host.name 、process.name 、user.name 、event.code），所有数据源都可以映射到这些字段中。一旦 z/OS Connect、IMS Connect 和 IMS 数据都针对相同逻辑概念写入相同的 ECS 字段，那么跨产品的交易追踪就可以通过一个查询完成。

这件事重要的另一个原因是，Elastic 的开箱即用（OOTB）仪表板、告警规则、异常检测和 ML 作业都是基于 ECS 字段路径构建的。从 JES 日志中由 Logstash 提取出的 job_name 字段对它们来说是不可见的。而携带相同值的 process.name 字段会立即被识别并处理。ECS 对齐使平台内置能力能够识别你的数据。

跳过这一步是摄取项目无法达到预期的最常见原因，尽管数据实际上已经存在。

将适合的字段映射到核心 ECS

下面的映射表是根据我在客户环境中看到的有效实践整理出的起点。你的源数据中的字段名称会有所不同，但 ECS 目标字段保持稳定：

z/OS 概念	ECS 字段	说明
作业名称	`process.name`
返回码	`process.exit_code`	确保使用整数类型；十六进制字符串是常见的映射错误
程序名称	`process.executable`
已用时间	`event.duration`	ECS 中使用纳秒；z/OS 通常以百分之一秒或毫秒报告，因此需要在管道阶段进行转换；单位不匹配会悄悄破坏 ML 对延迟的异常检测
消息 ID	`event.code`
时间戳	`@timestamp`	在管道中将 z/OS 格式标准化为 ISO 8601
LPAR 名称	`host.name`
系统 ID（SMFID）	`host.hostname`
用户 ID	`user.name`

参考：ECS process 字段和 ECS event 字段。

使用自定义 ECS 字段进行策略性扩展

大型机特定概念没有对应的 ECS 字段：作业类别、ASID、SMF 记录类型和子类型、sysplex 名称、WTO 路由代码、CICS 交易 ID。将这些字段扁平化到 labels.* 中作为无类型字符串，会破坏类型信息，并使它们实际上无法用于查询和聚合。

使用 ECS 文档化的扩展机制定义一个 zos.* 自定义命名空间。它可以保持你的核心遥测数据符合 ECS 标准，同时保留大型机团队在事件响应过程中所需的运营上下文。

使用 ecs@mappings 保持最新状态

在你的索引模板中将 ecs@mappings 作为组件模板包含进去（从 Elasticsearch 8.9 开始可用于自定义索引模板，从 8.13 开始可用于 Elastic Agent 集成模板）。它会自动提供由 Elastic 维护的 ECS 字段定义，并随着每个 Elasticsearch 版本更新保持最新状态。对于自定义管道来说，这是避免 ECS 对齐随着时间推移发生偏移而无需手动维护的方法。

需要注意的一个重要事项：ecs@mappings 提供字段定义，但不会在摄取阶段强制执行类型。以字符串形式到达的返回码会被接受，并映射为字符串。监控这些差异非常重要，可以使用数据质量仪表板识别这些问题。并且由于 Elastic 已将 ECS 捐赠给 OpenTelemetry，你在这里定义的 zos.* 映射会继续作为 OTel 语义约定和 ECS 逐渐融合过程中的有效映射。无论数据通过 Logstash 还是 OpenTelemetry 协议（OTLP）到达，对齐工作都是相同的。

为数据源选择正确的架构

我接触的大多数环境都会运行不止一种摄取架构，而不同的数据源具有不同的延迟、吞吐量和许可特性。单一架构很少能够覆盖所有需求。下面的表格将常见的 z/OS 数据源映射到适合它们的架构。

当大型机和 Elastic 集群之间存在网络弹性需求时，通常会添加 Kafka。如果你的环境中还没有 Kafka，需要权衡运行 Kafka 的运维开销与它带来的弹性收益。从 IBM MQ 9.4.3 开始，Kafka Connect 可以原生运行在 z/OS UNIX System Services 中，用于 MQ connector 使用场景，从而减少对平台外 Kafka Connect 集群的需求。

当使用 Kafka 时，本文指南中的摄取路径推荐使用 Logstash 作为下游消费者。Confluent Elasticsearch sink connector 是另一种选择；自托管的 v1 connector 支持 Elasticsearch 7.x 和 8.x，但已弃用，并将在 2027 年 4 月结束生命周期（EOL）；而 v2 connector 仅适用于 Confluent Cloud，因此不适合本地部署和隔离网络环境。

参考架构：Kafka 作为中间件。

数据源	采集器	说明
SMF 类型 30 作业计费	IBM Z Common Data Provider（CDP）	二进制 SMF 记录需要在摄取之前进行预处理
z/OS SYSLOG	IBM Z CDP
JES 作业日志	IBM Z CDP	批量导出是历史分析 / 概念验证（PoC）工作的替代方案
资源访问控制设施（RACF）审计事件	IBM Z CDP	符合 ECS 标准的 RACF 数据可以直接与 Elastic SIEM 配合使用
RMF 性能数据	IBM Z CDP	考虑在索引模板中使用时间序列数据流（TSDS）
IMS 统计记录	IBM Z CDP
OMEGAMON agent 指标（CICS、IMS、Db2、z/OS、网络、存储）	IBM OMEGAMON Data Provider（ODP）	原生输出 JSON；无需二进制预处理
IMS 交易数据	IMS Connect Extension（Rocket Software）	JSON 输出绕过 SMF 二进制解析；需要 Rocket Software 许可
CICS 交易追踪	IBM Z Observability Connect	原生 OTel；在从云原生到大型机的端到端可观测性深度分析中详细介绍
IBM Z 上的 Linux（zLinux）	标准 Elastic Agent	提供完整集成目录；与 z/OS 接入是不同的问题
历史分析 / PoC	批量导出（CSV / FTP）	不适合作为长期运营解决方案

从 z/OS 到 Elastic 的摄取路径流程图。

IBM Z CDP：z/OS 运营数据的主力方案

IBM Z CDP 是 z/OS 运营数据中部署最广泛的第一阶段采集器。它从 SMF 数据集中近实时读取数据，并将数据转发到平台外部，负责处理真正困难的部分：在不影响性能关键路径的情况下将数据从 z/OS 中取出。在我接触的环境中，它是 SMF 类型 30 作业计费、IMS 统计记录和 z/OS SYSLOG 的标准路径。

CDP 将数据转发到 Logstash，由 Logstash 负责解析、字段提取和路由到 Elasticsearch。Kafka 是一个可选的中间件消息队列：

CDP →（Kafka →）Logstash → Elasticsearch

权衡因素：CDP 是单独授权的 IBM 产品，二进制 SMF 记录需要在 Logstash 解析之前进行预处理，并且该架构不适用于亚分钟级延迟需求。

除了 CDP 之外，还需要注意 IBM ODP，它为你环境中的 OMEGAMON 监控组件提供的性能和可用性指标扮演相同的采集角色，包括 CICS、IMS、Db2、z/OS、网络和存储。不同于 CDP 的二进制 SMF 输出，ODP 原生转换为 JSON，因此无需预处理步骤。ODP 由两个组件组成：OMEGAMON Data Broker（运行在 z/OS 上的 Zowe 跨内存服务器插件，用于从 OMEGAMON 监控 agent 收集属性，并将它们转发到 Data Connect）；以及 OMEGAMON Data Connect（运行在 z/OS 上或 z/OS 外部的 Java 应用程序，从 Data Broker 接收数据，并将数据转发到包括 Elasticsearch 在内的目标位置；目标设置在这里进行配置）。如果 OMEGAMON 已经存在于你的监控栈中，ODP 是将这些遥测数据导入 Elastic 的自然路径。

参考架构：Logstash 到 Elasticsearch。

IMS Connect Extension：适用于可以绕过 CDP 的 IMS 工作负载

Rocket Software 的 IMS Connect Extension 会直接将 IMS 交易活动记录为 JSON，完全绕过 SMF 层。事件发布到 Kafka，然后由 Logstash 消费并建立索引。一些组织会通过 Kafka（rsyslog → Kafka → Logstash）统一所有日志流，作为可选的弹性模式。

IMS Connect Extension →（Kafka →）Logstash → Elasticsearch

这对于 IMS 交易性能数据和应用程序级事件流非常有效。JSON 输出消除了二进制解析问题。Kafka 提供了解耦、重放以及下游维护期间的缓冲能力。

权衡因素：IMS Connect Extension 许可、Kafka 基础设施运维，以及仅覆盖 IMS 特定场景，无法帮助处理 z/OS SYSLOG 或其他 SMF 类型。

在决定采用这种模式之前，我总会验证的一点是 Kafka topic 命名。银行和受监管环境通常有严格的 topic 命名策略，而 IMS Connect Extension 默认自行创建 topic 的行为可能会与这些策略冲突。在确定架构之后才发现这个问题，成本会更高。

批量导出：用于历史分析和 PoC

从 IMS Problem Investigator 或类似工具导出到 CSV，传输到平台外，然后通过 Logstash 或 Elastic Agent 文件输入进行摄取。这种方式没有实时能力，也不需要新的 z/OS 软件。

批量导出 → CSV/FTP → Logstash/Elastic Agent → Elasticsearch

这种方式非常适合历史分析、初始 PoC 工作，以及在投入实时管道之前展示价值。我们也会使用这种方式，在生产架构建立之前确定 ECS 映射。它不适合作为长期运营可观测性解决方案。

IBM Z 上的 Linux：独立且更简单的路径

这条路径经常被忽略。IBM Z 上的 Linux 工作负载可以运行标准 Elastic Agent（Elastic Agent 不运行在原生 z/OS 上），无需 z/OS 特定工具，无需自定义管道，并且可以使用完整的 Elastic 集成目录。

如果你的环境中有 IBM Z 上的 Linux 工作负载，请将它们视为独立的（并且明显更简单的）接入路径。

对于所有选项，请查看使用 Elastic Agent 的参考架构。

吞吐量和隔离网络：每个大型机团队都会问的两个问题

吞吐量影响：对于每秒运行数千笔交易的大型机团队来说，任何接触 z/OS 性能关键路径的方案都是不可接受的。上面的四种架构都采用平台外采集方式：CDP、ODP、Kafka/Logstash、批量导出或标准 Linux agent。这是适合该环境的正确设计，而不是一种变通方案。

隔离网络环境：我接触的大多数大型机环境在某种程度上都受到网络限制。Elastic 的隔离网络参考架构是一条有文档支持的部署路径。

构建管道，不要从零开始

对于 CDP 和 IMS Connect Extension 架构，日志数据进入 Elastic 时会保留其源数据有限的结构。大型机日志格式具有安装环境特定性，最多只能算部分结构化；没有开箱即用的解析器能够覆盖它们，而从零编写管道一直是任何接入项目中耗时最多的部分。人工智能改变了这一点。对于无法调用托管模型的大型机环境（大多数环境都是如此），下面两个工具都支持使用自托管本地大型语言模型（LLM），因此即使在隔离网络和受限网络环境中，也可以使用这些能力。查看本地 LLM 概览了解支持的选项。

Streams：适用于已经进入 Elastic 的数据（从 9.2 开始可用）。

在 Kibana 中打开某个流的 Processing 选项卡，然后点击 Suggest pipeline 。几秒钟内，你就可以看到一个完整且经过验证的管道（Grok 或 Dissect 模式、日期标准化、类型转换、字段清理），并可以实时预览实际文档如何通过该管道进行解析。在你确认之前，任何内容都不会写入该流。在底层，生成过程分两个阶段运行：首先，确定性指纹识别会对日志格式进行分组，并选择最佳解析方式；其次，一个推理 agent 会不断迭代，添加标准化和清理步骤，在交给你之前根据严格阈值进行验证。最终结果是一个可以进一步优化的可用管道，而不是一个需要重新编写的起点。技术细节请参考 Streams 如何在几秒内生成日志管道。

Automatic Import：适用于从头开始构建新的自定义集成（从 8.18/9.0 开始可用）。 Automatic Import 采用不同路径。你上传示例数据，它会生成一个完整、可部署的 Elastic Agent 集成包（摄取管道、ECS 字段映射、事件分类以及相关 .* 字段填充），你可以在安装前进行审核和批准。Streams 的 Suggest Pipeline 是为已经进入流的数据构建结构，而 Automatic Import 则从零开始构建整个采集路径。支持的输入格式包括 JSON、NDJSON、CSV 和 syslog，这直接覆盖了 z/OS SYSLOG。支持的采集方式包括 Kafka、File Stream、TCP 和 HTTP Endpoint，因此非常适合已经通过 Kafka 路由数据，或通过 TCP 接收 ODP 输出的环境。对于采用 Elastic Agent 的大型机团队来说，这消除了过去需要数周完成的自定义集成工作。

这两个工具还有一个不太明显但很重要的优势：持续性。编写自定义 GROK 模式的工程师最终可能会转到其他团队。一个能够根据示例数据重新生成管道或集成的工具，可以提供运营弹性。

从范围来看，Streams 处理文本数据。二进制 SMF 记录需要先在上游转换为文本或 JSON（通过 CDP 或 IBM 提供的工具），然后这两个工具才能处理它们。该转换发生在 Elastic 参与之前。

从第一天开始配置死信队列

大型机团队了解来自 MQ 的_死信队列模式_：当消息无法传递或处理时，它会进入保留队列，而不是被静默丢弃。Elasticsearch 对摄取管道也有相同概念，称为failure store。从第一天开始配置它，而不是等到第一次生产事故之后。

格式漂移是一个持续出现的失败模式：供应商更新、将示例配置当作生产配置、新消息类型在批处理窗口中出现。failure store 可以让你在仪表板对你产生误导之前发现这些问题。当日志行以意外格式到达，并且管道无法解析时，failure store 会保存原始文档以及失败原因相关的元数据。你可以查询它、根据增长速度设置告警，并使用捕获的文档修复管道。

如果没有它，解析失败要么会进入默认处理方式（使用原始 message 字段建立索引，而预期查询字段缺失），要么会被完全丢弃。无论哪种情况，你都不知道问题正在发生。

根据团队处理格式漂移所需的时间设置保留周期，通常为几天到几周。结合文档数量或增长速度告警，使队列本身成为早期预警机制，而不是需要某个人记得检查的东西。

在构建基础能力之前验证大型机数据质量

不要基于未经验证的数据构建仪表板或告警规则。数据质量仪表板可以告诉你 ECS 对齐是真实有效的，还是只是理想状态。

对于大型机数据，隐式类型不匹配非常常见：十六进制形式的返回码被映射为 keyword，已用时间被存储为字符串，时间戳无法转换为 @timestamp。这些问题在摄取阶段都不会失败，但都会悄悄破坏查询和告警条件。

使用真实生产数据运行检查，而不是合成样本。由于 z/OS 日志会在不同批处理窗口和消息类型之间变化，边界情况只有在真实环境中才会出现。准备进行多次迭代：发现不匹配，修复管道，然后再次运行。对于新的大型机数据流，两到三轮迭代是正常的。

源数据质量验证、failure store 和数据质量仪表板是同一个循环中的三个环节。它们共同让你确信仪表板反映的是大型机中真实发生的情况，而不是你希望管道生成的结果。

开始大型机数据接入

大型机是一个一等公民的可观测性目标，而实现这一目标的路径比几年前更加明确。托管集成覆盖 IBM MQ。CDP 和基于 Kafka 的架构已经拥有成熟的部署模式。Streams 和 Automatic Import 解决了自定义管道从空白开始的问题，包括通过本地 LLM 支持受限环境。IBM Z Observability Connect 则适用于可以采用 OTel 路径的场景。

推荐的操作顺序：

验证源数据。
在存在开箱即用集成的地方优先使用它们。
尽早对齐 ECS。
根据数据源选择架构。
生成管道，而不是从零编写。
从第一天开始配置 failure store。
在构建任何上层能力之前进行验证。

如果你的组织正在处理这些工作，并希望交流经验，或者正在遇到特定阻碍，请联系你的 Elastic 账户团队。对于 OTel 原生路径，请继续阅读从云原生到大型机的端到端可观测性深度文章。要在你自己的环境中尝试这些基础组件，请开始免费 Elastic Cloud 试用。

原文：How Streams Generates a Log Pipeline in Seconds --- Elastic Observability Labs