Summary
Is your Dynatrace z/OS monitoring not working as expected? Before opening a support ticket, it’s often helpful to perform an initial investigation yourself—but reading mainframe logs can feel overwhelming if you’re not sure where to start.
Don’t worry—I’ve got you covered. 😉
In this two‑part blog series, I’ll walk you through common z/OS monitoring issues I’ve encountered and explain how to troubleshoot them effectively.
In Part 1, we’ll cover the basics:
- Which logs you need
- How to download and extract them
- How to identify the right log files
- What critical information to check first
- Summary
- Downloading the Dynatrace z/OS Support Archive
- Verifying Dynatrace z/OS Component Versions
- What to Look for in Dynatrace z/OS Logs
- Final Thoughts
Downloading the Dynatrace z/OS Support Archive
The first step in any z/OS troubleshooting process is collecting logs. Whether the issue is related to zRemote, zLocal, or zDC, having full visibility is essential.
To download the Dynatrace z/OS OneAgent diagnostics logs, follow the instructions here:
👉 How to download the z/OS OneAgent diagnostics logs
👉 How to download the z/OS OneAgent diagnostics logs
How to Find the Logs Relevant to Your Issue
One of the biggest challenges is volume. Depending on your environment, the support archive can contain a large number of logs across multiple components.
Step 1: Identify Related zRemote and zLocal Logs
Search within the extracted archive for the keyword:
zRemoteAgent TimeStamp=YYYY-MM-DDThen look for a log entry similar to this:
YYYY-MM-DD HH:MM:SS UTC �00000000] info �native] Log info data�zLocalAgent logfile=/location/zlocal.log, zRremoteAgent logfile=location/zremote.log, zRemoteAgentName=oneagentname, zRemoteAgent TimeStamp=YYYY-MM-DD HH:MM:SS]This entry tells you the location of the zlocal agent logs and its accompanying zremote logs.
Why This Matters
In many environments, you’ll have multiple zRemotes, zDCs, and zLocals. Mapping the relationships between them helps you avoid mixing unrelated logs and saves a lot of investigation time.
Verifying Dynatrace z/OS Component Versions
Once you’ve identified the correct logs, the next critical step is checking version compatibility between your Dynatrace mainframe components.
zDC Version
In the zLocal log, search for:
ZDC Version=
This tells you which zDC version is installed on the mainframe.
zLocal Version
In the same log, search for:
The most recently installed zLocal version:
Example:
The most recently installed zLocal version: 7.2.29.1008
zRemote Version
You can find the zRemote version in:
- The UI, Deployment Status> ActiveGate , or
- The zRemote log file, by searching for the version string directly
Why Version Checks Are So Important
Many z/OS monitoring issues are resolved by upgrading components. The zDC, zLocal, and zRemote are interconnected, so version compatibility among these three components is critical.
Best practice:
- zDC, zLocal, and zRemote should be on the same version, or
- At most, within three versions of each other
⚠️ If zDC is on a higher version than zRemote, compatibility issues can occur.
What to Look for in Dynatrace z/OS Logs
Once versions are verified, the logs contain a wealth of diagnostic data.
Key Information in zRemote Logs
In the zRemote logs, you’ll typically find:
-
zRemote resource details
ZRemote number of cpus=n, total memory=nGB -
Build platform
Build platform .............. Linux x86 64-bit -
Tenant ID information
-
Process group IDs
-
Server or collector IP addresses
-
Available physical memory
Physical memory limit: 99.99% available (nnnn of nnnn MB taken) -
Active Sensors
ZDTP020I Active Sensors: MQ DB2 SOAP CTG DB2Fetch DLI HTTP ZCON
What You’ll Find in zLocal and zDC Logs
The zLocal and zDC logs provide deeper mainframe‑specific insights, including:
- z/OS version
- LPAR details
- ZDCSYSIN configuration values
- SMO information
- Number of transactions processed
These details are often critical when diagnosing performance, connectivity, or data‑collection issues.
Final Thoughts
Before starting any deep investigation, these are the baseline checks I always perform:
- Correct logs identified
- Component versions verified
- Resource and configuration details reviewed
Having this information upfront dramatically shortens troubleshooting time and leads to faster resolution.
👉 Next up (Part 2):
We’ll cover common Dynatrace z/OS monitoring problems and how to troubleshoot them step by step:
Troubleshooting your z/OS monitoring: Common Issues
We’ll cover common Dynatrace z/OS monitoring problems and how to troubleshoot them step by step:
Troubleshooting your z/OS monitoring: Common Issues
Related Reading
📖 Troubleshooting your z/OS monitoring: Common Issues
📖 zRemote hardware requirements
