Contact us
Does your mainframe need OpenTelemetry?
A clear read on what OpenTelemetry actually does on the mainframe and a framework to decide if you need it now, later, or not at all.
There is a lot of talk in the mainframe world about OpenTelemetry (OTel). While it is easy to read about it, few can answer the core question of what problem it is trying to solve for them. OpenTelemetry is an open standard for the transport of operational data about applications (opentelemetry.io) that is maintained by the Cloud Native Computing Foundation. This ebook attempts to describe what OpenTelemetry does, why the mainframe is a special case, and how one can read the blurb from your vendor. We will then develop a simple framework that can be used to make a decision about OpenTelemetry with your team. Note that this is written for people who run mainframes and not for people who sell pipelines. We consider “not yet” to be a valid answer.
✓ Independent — no product tour, no competitor named, no pitch
✓ Written for people who run mainframes, not people who sell pipelines
Get the free ebook
What will you learn?
- What OpenTelemetry is in plain terms, and the three things it is not.
- Why the mainframe is a special case: SMF (System Management Facility) data, no software development kit for COBOL or PL/I, and the cost of collecting on-platform.
- How to read “we support OpenTelemetry” on a vendor datasheet: the five questions that separate a shipped product from a press release.
- Where OpenTelemetry genuinely helps on the mainframe, and where it quietly runs up your bill.
- The principle that saves the most money: enrich your data before you send it.
- A six-question framework to decide whether you need OpenTelemetry now, later, or not at all.
Who is it for?
- Systems engineers running one too many collectors on the same mainframe.
- Infrastructure leaders deciding what to standardize on, and how to defend the platform.
- CTOs weighing observability across a hybrid estate.
Why this guide is different?
It is independent: no product tour, no competitor named, no pitch. Zetaly builds software that puts mainframe data to work, so we know the plumbing, but this guide exists to help you make a clear decision, including the decision not to adopt.
Questions people ask before downloading
Is OpenTelemetry replacing mainframe monitoring tools?
No. OpenTelemetry (OTel) is a standard for transporting operational data, not a monitoring product. It has no storage, dashboards, or alerting. Mainframe monitors, analytics platforms, and OTel pipelines solve different problems; the real question is which combination fits your organization.
Can COBOL applications emit OpenTelemetry data?
Not natively. No stable OpenTelemetry software development kit exists for COBOL or PL/I. On the mainframe, OpenTelemetry data comes from the infrastructure: the operating system, subsystems such as CICS, IMS, MQ and Db2, or data platforms that translate SMF records. The applications themselves cannot participate directly.
Does collecting mainframe telemetry increase the IBM bill?
It can. Software running on the mainframe consumes capacity that IBM meters, and heavy on-platform processing shows up in billing. When you evaluate any telemetry approach, ask where the processing runs and what its measured on-mainframe footprint is. The difference between architectures is large
Do I need OpenTelemetry to modernize mainframe observability?
No. The underlying need, to collect once, enrich the data, and make it usable beyond the mainframe team, can be met today without OpenTelemetry, and OpenTelemetry alone does not meet it: it transports data but does not keep or interpret it. Adopt the standard when your organization runs OpenTelemetry infrastructure with named consumers.
Get the ebook before your next TFP conversation
35 pages. Independent. Whether you’re moving to TFP or already there.