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

作者来自 Elastic Anna Maria Modée这份字段指南介绍了我在生产环境中看到过的有效摄取架构、决定你的仪表板是否真正有效的数据质量检查以及让大型机数据可供平台使用的 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它是原生 OpenTelemetryOTel路径并且覆盖范围比下面介绍的架构更广。对于其他情况请继续阅读。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.durationECS 中使用纳秒z/OS 通常以百分之一秒或毫秒报告因此需要在管道阶段进行转换单位不匹配会悄悄破坏 ML 对延迟的异常检测消息 IDevent.code时间戳timestamp在管道中将 z/OS 格式标准化为 ISO 8601LPAR 名称host.name系统 IDSMFIDhost.hostname用户 IDuser.name参考ECS process 字段和 ECS event 字段。使用自定义 ECS 字段进行策略性扩展大型机特定概念没有对应的 ECS 字段作业类别、ASID、SMF 记录类型和子类型、sysplex 名称、WTO 路由代码、CICS 交易 ID。将这些字段扁平化到labels.*中作为无类型字符串会破坏类型信息并使它们实际上无法用于查询和聚合。使用 ECS 文档化的扩展机制定义一个zos.*自定义命名空间。它可以保持你的核心遥测数据符合 ECS 标准同时保留大型机团队在事件响应过程中所需的运营上下文。使用 ecsmappings 保持最新状态在你的索引模板中将ecsmappings作为组件模板包含进去从 Elasticsearch 8.9 开始可用于自定义索引模板从 8.13 开始可用于 Elastic Agent 集成模板。它会自动提供由 Elastic 维护的 ECS 字段定义并随着每个 Elasticsearch 版本更新保持最新状态。对于自定义管道来说这是避免 ECS 对齐随着时间推移发生偏移而无需手动维护的方法。需要注意的一个重要事项ecsmappings提供字段定义但不会在摄取阶段强制执行类型。以字符串形式到达的返回码会被接受并映射为字符串。监控这些差异非常重要可以使用数据质量仪表板识别这些问题。并且由于 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 ProviderCDP二进制 SMF 记录需要在摄取之前进行预处理z/OS SYSLOGIBM Z CDPJES 作业日志IBM Z CDP批量导出是历史分析 / 概念验证PoC工作的替代方案资源访问控制设施RACF审计事件IBM Z CDP符合 ECS 标准的 RACF 数据可以直接与 Elastic SIEM 配合使用RMF 性能数据IBM Z CDP考虑在索引模板中使用时间序列数据流TSDSIMS 统计记录IBM Z CDPOMEGAMON agent 指标CICS、IMS、Db2、z/OS、网络、存储IBM OMEGAMON Data ProviderODP原生输出 JSON无需二进制预处理IMS 交易数据IMS Connect ExtensionRocket SoftwareJSON 输出绕过 SMF 二进制解析需要 Rocket Software 许可CICS 交易追踪IBM Z Observability Connect原生 OTel在从云原生到大型机的端到端可观测性深度分析中详细介绍IBM Z 上的 LinuxzLinux标准 Elastic Agent提供完整集成目录与 z/OS 接入是不同的问题历史分析 / PoC批量导出CSV / FTP不适合作为长期运营解决方案从 z/OS 到 Elastic 的摄取路径流程图。IBM Z CDPz/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 消费并建立索引。一些组织会通过 Kafkarsyslog → 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 AgentElastic 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