IBM i

Dynatrace offers remote monitoring of IBM i hosts via this ActiveGate extension.

The ingested data provides Dynatrace with real-time visibility into host performance through interactive visualization tools, dashboards, unified analysis and events. When combined with OneAgent monitoring, you gain the ability to understand how IBM i interacts with the other components in your stack.

Requirements

Note: For best performance and data collection, these requirements are strict. Always keep your system up to date.

• ActiveGate must be 1.265+
• Dynatrace version 1.265+
• IBM has made significant performance improvements and introduced more accurate metrics in their latest Technology Refresh levels. For this reason, only the following IBM i Releases are supported:
  • IBM i 7.3 Technology Refresh 12+ (must have PTF Group SF99703 Level 28+)
  • IBM i 7.4 Technology Refresh 6+ (must have PTF Group SF99704 Level 20+)
  • IBM i 7.5
• Communication ports between ActiveGate and IBM i Hosts must be open.

• IBM i Access ODBC driver must be installed on ActiveGate. This is a specific driver provided by IBM for DB2 communication with IBM i hosts.

• Connection pooling must be enabled on ODBC driver. On Windows, this is enabled by default.

• Due to sensitive system data, IBM requires a user with SECOFR profile to access performance tables and all its functions. Failure to provide this access will cause issues with missing metrics, missing messages in queues, prohibited access to internal functions and calls made by IBM. You are free to configure other user classes with less privileges but it would not be supported.

  In addition, ensure that the user profile has *JOBCTL special authorization. It also needs *USE authority to the Work with PTF Groups (WRKPTFGRP) command.

Windows ActiveGates (For Linux, continue below)

ODBC driver installation

Follow these instructions if you are using ActiveGates running on Windows:

• Head to IBM's website.
• Click the Downloads for IBM i Access Solutions link.

• Log in with your IBM account and accept the License terms.
• The correct ODBC driver comes only in the "IBM i Access Client Solutions - Windows Application Package for Windows.". Only this package contains the ODBC driver needed. Do not install the "IBM i Access Client". Make sure you download the Windows package.

• Extract file zip archive and follow its instructions to install on the ActiveGate.
• After installation, confirm the IBM i Access driver is installed and Connection Pooling is enabled by running native ODBC Data Sources Windows application. You may increase its timeout to a number no less than 60.

Linux ActiveGates (Advanced setup)

Linux distributions do not come with an ODBC driver manager and this is needed to connect to IBM i. unixODBC is the most accepted, compatible driver manager for Linux and it is also approved by IBM.

• ⚠️ Installation of unixODBC requires advanced Linux knowledge.
• 🛑 You must install unixODBC 2.3.12 or higher. Earlier versions are not supported due to necessary fixes only available on version 2.3.12 and newer.
• Depending on your Linux distribution, this version might be available to your distribution (rpm, debian or others) or you may need to compile it from source code. This is the part where you might need a Linux administrator to make this determination.

Installing unixODBC, installs libraries and commands needed to connect to IBM i. Following this unixODBC, you must now install the IBM i Access ODBC Driver.

ODBC driver installation on Linux

• Head to IBM's website.
• Click the Downloads for IBM i Access Solutions link.

• Log in with your IBM account and accept the License terms.
• The correct ODBC driver comes only in the "IBM i Access Client Solutions -Linux Application Package for Linux.". Only this package contains the ODBC driver needed. Do not install the "IBM i Access Client". Make sure you download the Linux package.

• Extract file zip archive and follow its instructions to install on the ActiveGate.
• After installation, you must now enable Connection Pooling in the IBM i Access ODBC Driver definition in the odbcinst.ini file.
• Locate your odbcinst.ini file, by default it is in /etc/odbcinst.ini or /etc/unixODBC/odbcinst.ini, then add CPTimeout=60 to each driver definition. This setting is needed for the extension to run and provide accurate measurements.

• ⚠️Installing IBM i Access ODBC Driver may install older dependencies, including older versions of unixODBC. Verify that you are still running unixODBC 2.3.12+ afterwards.

Extension configuration

• Log into your Dynatrace console.

• Under Extensions on the left menu, select IBM i.

• Add a monitoring configuration.

This ActiveGate extension, also referred as "Remote", runs in ActiveGate groups.

• Select which ActiveGate group will run this configuration. At least one ActiveGate must be in your group.

  • Log level: Enable DEBUG only when troubleshooting or support instructs you to do so.
  • Add an IBM i Host: Click to configure each connection to individual hosts. All these connections will be run from this ActiveGate group.

Host

• Host or IP address: Hostname or IP of the IBM i Host.
• User name: Due to sensitive system data, table functions and internal stored procedures, a user with SECOFR access to the IBM i Host is required.
• Password: Password to user above.
• Use SSL: Toggle if connecting to host using SSL.

Jobs

• Get Top active jobs: Toggle to collect Top N CPU consuming jobs. (Max 500). This requires the least amount of configuration as it automatically collects most taxing jobs by CPU. Disabling this toggle allows you to manually configure which jobs by certain filters.
  • Send log event on status of all jobs: Toggle this button to configure rules that will trigger a log event for any job on the system that matches a status. Resulting log event will include the job number as well.
• Add job filter: If Top active jobs is disabled, you can manually configure rules that match certain jobs, by user and by subsystem too.
  • Send log event on status of this job: Toggle this button to configure rules that will trigger a log event if this job is in that status. Resulting log event will include the job number as well.

Job queues

• Add job queue filter: Configure a rule for job queues matching a name and/or library they are in.

Subsystems

• Add subsystem filter: Configure a rule for subsystems matching a name and/or library they are in.

Message queues to monitor

• Add Message Queue filter: A default message queue is configured, QSYSOPR. Most system messages are in this queue. However, you may add more rules for other message queues. Only messages in these queues that have a minimum severity will be counted. Optionally you may see individual messages by triggering log events for those messages that match a criteria.
  • Minimum severity: Messages have a severity level from 0 to 99. Using this filter will eliminate noise and messages that are not critical.
  • Send log events on message: Toggle this button to trigger log events on messages that match severity and Message IDs and/or Message types.
    • Message IDs: Enter a comma-separated list of important Message IDs. You may leave this blank to match any message ID.
    • Filter on message types: Toggle which Message types to filter on. Leave this blank to filter on any of them.

History log messages to collect

• Define rule: Most messages, even the ones from message queues, go into the History Log. You may filter what messages you are interested in. Multiple rules will collect different type of messages. Only messages that have a minimum severity and matching criteria will be counted. All messages found will be automatically sent as Dynatrace log events.
  • Minimum severity: Messages have a severity level from 0 to 99. Using this filter will eliminate noise and messages that are not critical.
    • Message IDs: Enter a comma-separated list of important Message IDs. You may leave this blank to match any message ID.
    • Filter on message types: Toggle which Message types to filter on. Leave this blank to filter on any of them.

Output queues

• Add Output queue filter: Configure rules to collect output queues and information about their spooled files.

Network monitoring

• Local addresses: Enter a comma-separated list of IP addresses or CIDR addresses and their port numbers. This is useful to see traffic incoming traffic statistics to certain ports.
• Remote addresses: Enter a comma-separated list of IP addresses or CIDR addresses and their port numbers. This is useful to see traffic outgoing traffic statistics to certain ports.

Advanced parameters

• Polling frequency: By default, data is collected every 1 minute but you may configure frequency here. 1 minute data provides most accurate data.
• Connection timeout: Time in seconds before it gives up trying to connect to IBM i Host. This should be fairly quick and should not be beyond 30 seconds.
• Query timeout: Time in seconds before running a query timesout.
• Important job statuses: A list of common job statuses. This list will keep the possible combination of job statuses to a minimum to avoid consuming too many DDUs. Any status not in this list will be placed in an "Other" status bucket. Log events triggered from job statuses will not be impacted by this list and will always match its true status.

• Lastly, select which feature sets (metric groups) you would like this configuration to collect. Selecting too few will not give you the proper visibility and you may miss out on important performance data causing gaps or empty screens.

• Windows and Linux ActiveGates
• Supported releases:
  • IBM i 7.3 Technology Refresh 12+ (must have PTF Group SF99703 Level 28+)
  • IBM i 7.4 Technology Refresh 6+ (must have PTF Group SF99704 Level 20+)
  • IBM i 7.5

For Linux ActiveGates:

• unixODBC 2.3.12 and higher

Q: What is the DDU Consumption of this extension?

A: The formula for DDU consumption of the extension is:

  (15 + (11 * Memory pools) +  (7 * Jobs) +
  (9 * ASPs) +  (12 * Disk unit) + (5 * Job queues) + 
  ((3 * Output queues) * (3 * Spooled files)) + 
  (1 * Subsystems) + (1 * Network interfaces) + 
  (7 * Network connections) + (1 * Message queues) + 1 History Log ) * 525.6 DDUs/year, per Host

The following example assumes you collect all feature sets (metric groups) every minute.

Example, monitoring 1 Host with 4 Memory pools, 5 Subsystems, 1 ASP with 20 Disk units, 10 Job queues, 200 Jobs, 1 Message queue, 3 Interfaces, 5 Network connections, 3 Output queues and each one with 5 spooled files produces the following:

(15 + (11 * 4) + (7 * 200) + (9 * 10) + (12 * 20) + (10 * 5) + ((3 * 3) * (3 * 5)) + (1 *5) + (1 * 3) + (7 * 5) * (1 *1) +1) * 525.6 DDUs/year = 1,061,185 (1M) DDUs/year

DDU cost above does not include any possible Log events or Custom events triggered by the extension. For more information on this, please visit the DDU log event cost and DDU custom event cost pages.

Included dashboards:

System view

Memory pool

Job view

ASP and Disks

Job queue properties

Message queue

Output queue and spooled files

Network