OpenTelemetry con mainframes

Los mainframes siguen ejecutando una gran parte de las cargas de trabajo más críticas del mundo, especialmente en la banca, los seguros, el gobierno, el comercio minorista y las aerolíneas.

A menudo se encuentran en el núcleo de una arquitectura híbrida, con frontends web y móviles, microservicios y plataformas en la nube que dependen de los sistemas de registro del mainframe.

Esta sección explica cómo se integran los mainframes en una estrategia de observabilidad basada en OpenTelemetry y orienta como integrarlos con tus pipelines de telemetría existentes.

Audiencia

Este contenido está dirigido a personas que:

• Trabajan principalmente en entornos distribuidos / nativos de la nube (Kubernetes, VMs, serverless, etc.).
• Necesitan entender qué es un mainframe, por qué es importante y cómo incorporar las cargas de trabajo de mainframe a una estrategia de observabilidad de extremo a extremo.

Suposiciones

No necesitas experiencia previa con mainframes, ni tienes que ser un experto en COBOL o z/OS para beneficiarte de esta sección. Pero debes estar familiarizado con los conceptos de OpenTelemetry, como las trazas, las métricas, los logs, OTLP y el Collector.

Qué entendemos por mainframe

Los mainframes son servidores de datos diseñados para procesar miles de millones de transacciones diarias con los más altos niveles de seguridad y fiabilidad. Para obtener una descripción más detallada, consulta ¿Qué es un mainframe?.

Un ejemplo de mainframe es un sistema IBM Z que alberga:

• Procesamiento de transacciones (por ejemplo, CICS®, IMS™ y subsistemas similares)
• Procesamiento por lotes (trabajos gestionados por JCL, planificadores)
• Sistemas de registro de alto valor (bases de datos y archivos que son la «fuente de verdad»)

Aunque los detalles varían según el proveedor y el producto, la mayoría de los entornos de mainframe comparten características que afectan a la observabilidad:

• Rendimiento muy alto y requisitos estrictos de latencia y disponibilidad
• Aplicaciones y formatos de datos de larga duración
• Restricciones estrictas de seguridad y cumplimiento normativo

Cómo aparecen los mainframes en las arquitecturas de OpenTelemetry

Desde la perspectiva de OpenTelemetry, los mainframes suelen formar parte de un sistema híbrido más amplio:

• Frontends y APIs que se ejecutan en navegadores, aplicaciones móviles o API gateways.
• Microservicios y middleware que se ejecutan en contenedores, VMs o servicios gestionados en la nube.
• Lógica de negocio principal y datos que residen en el mainframe y se acceden mediante MQ, HTTP(S), gRPC, buses de mensajes o protocolos propietarios.

En una arquitectura típica, los flujos de telemetría podrían verse así:

• Los servicios distribuidos emiten trazas, métricas y logs mediante los SDKs de OpenTelemetry y el Collector.
• Los niveles de integración (API gateways, ESBs, puentes MQ, plataformas de streaming de datos) actúan como puntos de intercepción donde puedes correlacionar las solicitudes en la nube con la actividad del mainframe.
• Los componentes que residen en el mainframe emiten eventos, registros SMF, logs, spans de traza o métricas que deben transformarse o exportarse a formatos de OpenTelemetry (a menudo mediante un Collector o gateway que se ejecuta fuera de la plataforma).

El objetivo de esta sección es ayudarte a conectar esos puntos para que puedas ver una imagen única y coherente de los sistemas de mainframe y de los que no lo son.

En qué se diferencian los mainframes

Cuando incorporas OpenTelemetry a un contexto de mainframe, a menudo te encontrarás con:

• Modelos mentales diferentes
  • LPARs, espacios de direcciones y jobs en lugar de hosts, pods y servicios
  • Datasets y archivos VSAM en lugar de buckets de almacenamiento de objetos
• Telemetría y formatos preexistentes
  • Registros de System Management Facilities (SMF)
  • SYSLOG
  • LOGREC
  • Logs de subsistemas
  • Logs de jobs
  • Monitores de rendimiento
  • Estas fuentes a menudo deben analizarse y mapearse a trazas, métricas y logs según los define OpenTelemetry
• Restricciones de acceso y cambio
  • Los mainframes de producción suelen tener un control de cambios estricto y una capacidad limitada para modificar el código de las aplicaciones.
• Expectativas de escala y fiabilidad
  • Las soluciones de telemetría deben seguir el ritmo de tasas de transacciones muy altas sin afectar a los SLAs.
  • Los pipelines de datos deben ser lo bastante robustos y seguros como para cumplir con los requisitos normativos.

Estas características no impiden el uso de OpenTelemetry, pero influyen en dónde y cómo recopilas, transformas y exportas la telemetría.

Cómo puede ayudar OpenTelemetry

OpenTelemetry proporciona bloques de construcción que se pueden aplicar a entornos de mainframe, entre ellos:

• Un modelo de datos independiente de proveedores para trazas, métricas y logs.
• OTLP como protocolo de transporte estándar e interoperable.
• El OpenTelemetry Collector, que puede:
  • Ingerir datos de múltiples protocolos y formatos
  • Transformar y enriquecer datos
  • Exportar los datos transformados a los backends de observabilidad que elijas

En un contexto de mainframe, el Collector a menudo se ejecuta fuera de la plataforma (por ejemplo, en servidores Linux o contenedores) y actúa como puente entre:

• Las fuentes de telemetría específicas del mainframe.
• Tus backends de observabilidad empresariales (plataformas de métricas/logs, backends de trazas, herramientas de APM, SIEMs y data lakes).

Estado actual

Ya existe instrumentación fundamental de OpenTelemetry para entornos de mainframe, y el soporte de la plataforma sigue expandiéndose.

Históricamente, la mayor parte de la instrumentación de mainframe ha sido proporcionada por los proveedores: muchos proveedores de backends de observabilidad ofrecen sus propias extensiones o agentes para empaquetar y enviar la telemetría de mainframe a sus backends.

En respuesta a la demanda de los clientes de telemetría independiente de proveedores, IBM, que suministra el sistema operativo y el software de subsistema para los sistemas de mainframe más utilizados, y muchos proveedores de software independientes (ISV) están añadiendo soporte nativo de OpenTelemetry a sus productos.

Esta transición depende de una terminología y una semántica comunes, que el grupo de trabajo descrito en la siguiente sección está ayudando a definir.

Grupo de trabajo y comunidad

El OpenTelemetry on Mainframes Special Interest Group (SIG) se centra actualmente en:

• Definir terminología y casos de uso comunes
• Identificar carencias en las especificaciones (convenciones semánticas de OpenTelemetry), los SDKs y los componentes del Collector relacionados con los casos de uso de mainframe

El SIG cuenta actualmente con representación de IBM, Broadcom y otros ISV, proveedores de backends de observabilidad y algunos clientes. ¡Únete a nosotros!

Si estás interesado en contribuir, consulta Comunidad y la información sobre los SIG en los repositorios y el sitio web de OpenTelemetry para conocer los horarios de las reuniones, las notas de las reuniones y los canales de comunicación (#otel-mainframes).