# OpenTelemetry with Mainframes > Use OpenTelemetry to gain insights into mainframe workloads alongside your cloud and distributed systems. --- LLMS index: [llms.txt](/llms.txt) --- Mainframes continue to run a large share of the world’s most critical workloads—especially in banking, insurance, government, retail, and airlines. They often sit at the **core of a hybrid architecture**, with web and mobile frontends, microservices, and cloud platforms all depending on mainframe systems of record. This section explains how mainframes fit into an OpenTelemetry-based observability strategy and points to guidance on integrating them with your existing telemetry pipelines. ## Audience This content is aimed at people who: - Work primarily in **distributed / cloud native** environments (Kubernetes, VMs, serverless, etc.). - Need to understand **what a mainframe is**, why it matters, and how to bring mainframe workloads into an end-to-end observability story. ## Assumptions You do _not_ need prior mainframe experience, and you do not need to be a COBOL or z/OS expert to benefit from this section. But you should be familiar with [OpenTelemetry concepts](/docs/concepts/) such as traces, metrics, logs, OTLP, and the Collector. ## What we mean by mainframe Mainframes are data servers that are designed to process billions of transactions daily with the highest levels of security and reliability. For a more detailed overview, see [What is a mainframe?](https://www.ibm.com/think/topics/mainframe). An example of a mainframe is an IBM Z system that hosts: - Transaction processing (e.g., CICS®, IMS™ and similar subsystems) - Batch processing (JCL-driven jobs, schedulers) - High-value systems of record (databases and files that are the “source of truth”) While the details vary by vendor and product, most mainframe environments share characteristics that affect observability: - Very high throughput and strict latency/availability requirements - Long-lived applications and data formats - Strong security and compliance constraints ## How mainframes show up in OpenTelemetry architectures From an OpenTelemetry perspective, mainframes are usually part of a **larger, hybrid system**: - **Frontends and APIs** run in browsers, mobile apps, or API gateways. - **Microservices and middleware** run in containers, VMs, or managed cloud services. - **Core business logic and data** live on the mainframe and are accessed via MQ, HTTP(S), gRPC, message buses, or proprietary protocols. In a typical architecture, telemetry flows might look like: - Distributed services emit **traces, metrics, and logs** via OpenTelemetry SDKs and the Collector. - Integration tiers (API gateways, ESBs, MQ bridges, data streaming platforms) act as **interception points** where you can correlate cloud requests with mainframe activity. - Mainframe-resident components emit **events, [SMF records](https://www.ibm.com/docs/en/zos/3.2.0?topic=smf-introduction), logs, trace spans, or metrics** that must be transformed or exported into OpenTelemetry formats (often via a Collector or gateway running off-platform). The goal of this section is to help you **connect those dots** so you can see a single, coherent picture across mainframe and non-mainframe systems. ## What’s different about mainframes When you bring OpenTelemetry into a mainframe context, you will often encounter: - **Different mental models** - LPARs, address spaces and jobs instead of hosts, pods and services - Datasets and VSAM files instead of object storage buckets - **Pre-existing telemetry and formats** - System Management Facilities (SMF) records - SYSLOG - LOGREC - subsystem logs - job logs - performance monitors - These sources often need to be parsed and mapped into traces, metrics, and logs as defined by OpenTelemetry - **Access and change constraints** - Production mainframes often have strict change control and limited ability to modify application code. - **Scale and reliability expectations** - Telemetry solutions must keep up with **very high transaction rates** without impacting SLAs. - Data pipelines must be robust and secure enough to meet regulatory requirements. These characteristics don’t prevent the use of OpenTelemetry, but they influence **where and how** you collect, transform, and export telemetry. ## How OpenTelemetry can help OpenTelemetry provides building blocks that can be applied to mainframe environments, including: - **Vendor-neutral data model** for traces, metrics, and logs. - **OTLP** as a standard, interoperable transport protocol. - The **OpenTelemetry Collector**, which can: - Ingest data from multiple protocols and formats - Transform and enrich data - Export transformed data to your chosen observability backends In a mainframe context, the Collector often runs **off-platform** (for example, on Linux servers or containers) and acts as a **bridge** between: - Mainframe-specific telemetry sources, and - Your enterprise observability backends (metrics/logs platforms, tracing backends, APM tools, SIEMs, and data lakes). ## Current status Foundational OpenTelemetry instrumentation is available for mainframe environments, and platform support continues to expand. Historically, most mainframe instrumentation has been vendor supplied: many observability backend vendors provide their own extensions or agents to package and ship mainframe telemetry to their backends. In response to customer demand for vendor-neutral telemetry, IBM, which supplies the operating system and subsystem software for the most widely used mainframe systems, and many independent mainframe software vendors (ISVs) are adding native OpenTelemetry support to their products. This transition depends on common terminology and semantics, which the working group described in the next section is helping to define. ## Working group and community The **OpenTelemetry on Mainframes Special Interest Group (SIG)** is currently focused on: - Defining common terminology and use cases - Identifying gaps in specifications (OpenTelemetry Semantic Conventions), SDKs, and Collector components related to mainframe use cases The SIG currently has representation from IBM, Broadcom and other ISVs, observability backend vendors, and some customers. Join us! If you are interested in contributing, see the [Community](/community/) and [SIG information](https://github.com/open-telemetry/community#special-interest-groups) in the OpenTelemetry repositories and website for [meeting times](https://groups.google.com/a/opentelemetry.io/g/calendar-mainframe), [meeting minutes](https://docs.google.com/document/d/14p-bpofozTL4n3jy6HZH_TKjoOXvog18G1HBRqq6liE), and communication channels ([#otel-mainframes](https://cloud-native.slack.com/archives/C05PXDFTCPJ)).