Robot/CONSOLE has important resource and log monitoring features

In addition to message management, Robot/CONSOLE has important resource and log monitoring features that let you monitor jobs, job queues, subsystems, FTP requests, QHST messages, security audit log changes, and more. Based on this monitoring, Robot/CONSOLE can notify you or generate reports. This article explains how to use these special monitoring features.

Resource Monitoring
Robot/CONSOLE can check the status of your critical resources regularly. The RBCRSCMON monitor job runs in the RBTSLEEPER subsystem and automatically checks the status of resources that you set up using the Resource Maintenance panel. When it finds a resource that is NOT in the expected status, it sends a message to a virtual message queue, RBCRSCQ. Using Robot/CONSOLE, you can monitor the following resources:

• Controllers

• Device Descriptions

• Domino Servers

• FTP Servers

• HTTP Servers

• Jobs

• Job Queues

• Line Descriptions

• TCP/IP Servers

• Network Servers

• Objects

• Output Queues

• TCP/IP Ports

• Subsystems

• Servers

• System CPU %

• Network Interfaces

You specify the expected status of the resource and how often Robot/CONSOLE should check. Figure 1 shows an example of how you might set up monitoring for a job queue depth over 10. If the resource monitor job (RBCRSCMON) checks the status and finds more than 10 jobs in the job queue, it sends a message (message ID JBQ0003) to the virtual message queue (RBCRSCQ). You also need a message set to handle the message. Your message set can send a pop-up message, page you using Robot/ALERT, or take some other action by using OPerator Assistance Language (OPAL) code.

Log Monitoring
Robot/CONSOLE provides three types of log monitors: FTP, QHST, and Security Audit Journal.

1. FTP requests. This monitor looks for FTP requests from other systems. A special monitor job (RBCLOGFTP) monitors these events and sends a message to the virtual message queue (RBCLOGFTP). Robot/CONSOLE records the request, who made the request, and when the request was made. Robot/CONSOLE monitors for the following FTP requests: delete file, send file, receive file, rename file, and execute command.

2. System history log (QHST). Turn this monitor on to monitor messages sent to the system history log (QHST). A monitor job (RBCLOGHST) logs QHST messages to a virtual message queue (RBCLOGHST). To avoid message overload, set up a message set and message table to unconditionally suppress frequently occurring informational messages. To determine which messages to include in the message table, run the “Summarize QHST Messages” report (Figure 2). You can run this report from a command line using the following command:

RBTCONLIB/RBCSUMQHST

3. The Security Audit Journal. To monitor security audit journal entries, turn on the Security Audit Log. A monitor job (RBCLOGAUD) converts System i security audit journal entries into message IDs and sends them to a virtual message queue (RBCLOGAUD). You can capture any or all of the following QAUDLVL security audit journal entries: *SECURITY (changes in system values or user profiles), *AUTFAIL (failed sign-on attempts or access to objects), *SERVICE (catches attempts to sidestep security using Service Tools or APIs), and *SYSMGT (changes to system reply list entries, operational assistant functions, and so forth).

You turn log monitors on using the Log Monitoring Setup panel (Figure 3).

Reporting
All log and resource monitoring messages are recorded so you can print history reports quickly for SOX auditors. For example, to print all messages relating to FTP requests, run the Message History List report from the History Reports menu and specify the “Originating Center” as RBCLOGFTP. You can do the same for resource monitor messages (RBCRSCQ), security audit log messages (RBCLOGAUD), and QHST messages (RBCLOGHST).

Contributed by Jenny Dischinger, Technical Consultant

There’s an easy way to monitor Windows services from the System i

How long has the Windows print server been locked up? Why can’t we coordinate our System i backups with shutting down Windows services? Why didn’t we know the e-mail server was down?

If your System i operations team is saddled with the additional chore of monitoring Windows servers and batch processes, they’re not alone. It’s difficult enough to coordinate processes across a network of i5/OS systems, without adding multiple Windows servers. Unfortunately, most System i monitoring tools for Windows services don’t offer much help.

So, today you might have your network team monitoring these systems through freeware or through periodic manual checks. Do your operators wander through the server racks checking for unavailable services? Or, has your development team generously offered to write some code to help manage these issues?

Automate Windows service monitoring
Help/Systems has the simple solution: Robot/CLIENT. Robot/CLIENT can monitor Windows services with a command from the System i. The Monitor NT Service (RCLMONSVC) command (see Figure 1) can check for unavailable services, at regular intervals, from your most reliable server, the System i. When Robot/CLIENT detects a failed service, you can start a scheduled job, use the RCLSTRSVC command to restart it, react with another batch process, or send an e-mail to an operator.

Robot/CLIENT also has commands that let you start and end Windows services. These commands can release Windows services that have locked an i5/OS file, preventing a successful backup. All you need to do is start your backups with the command that ends Windows services (see Figure 2). When the backup completes, just restart the service using the start services command. Backups are just one example of when you might want to end a Windows service.

Let Robot/CLIENT go to work for you
As many of our customers have learned, Robot/CLIENT provides the tools necessary to maintain control of your network monitoring. It monitors and manages Windows services automatically, so you don’t have to worry about them. Let us help you automate Windows integration with the System i. Call for your Robot/CLIENT 30-day free trial. You won’t be disappointed.

Contributed by Tom Huntington, Vice President of Technical Services

When you need to expand your sphere of resource monitoring, consider Robot/TRAPPER

Robot/TRAPPER adds another facet to the many ways the Robot products allow you to monitor resources. Robot/TRAPPER allows you to use the reliability of the System i to monitor any device with an IP address. This can include such varied equipment as automated teller machines (ATMs), Windows servers, hubs, environmental monitors, and more!

Check resources at predefined intervals
Robot/TRAPPER allows you to proactively ping (check the status of) any device that has an IP address at predefined intervals to ensure availability. It keeps track of the pulse of your network.

The Maintain Devices panel displays a device’s description, IP address, ping priority, and status. You can search the list of devices by device description or IP address.

You can use this panel to add, delete, and modify device records. When you select a device on the Maintain Devices panel, you can modify its description, message queue, library, or ping interval. You also can use the Maintain Devices panel to check the status of devices, place devices on hold so they are not pinged, and ping devices on demand.

If the device doesn’t respond to a ping, Robot/TRAPPER uses Robot/CONSOLE to notify you. You should assign your critical resources the highest ping priority so they are pinged more frequently than less important resources. When a critical device becomes unavailable, you have the full power of Robot/CONSOLE at your disposal to respond to the problem. Your Robot/CONSOLE message set might:

* Run OPAL code to attempt a recovery when a ping fails.

* Notify you immediately so that you can begin to monitor the situation and take corrective action. (If you want to notified by pager or e-mail message, you need Robot/ALERT.)

* Use the interface to Robot/ALERT to escalate the problem through a chain of people, or notify a whole group at the same time.

Listen for messages
Robot/TRAPPER also has the ability to receive SNMP traps (event notifications) from these devices. Devices can be added manually or Robot/TRAPPER can add them dynamically as traps are received.

Robot/TRAPPER running on the System i works with Robot/CONSOLE to let you know when your network devices have security breaches, completion messages, or application errors. This is accomplished by using a Management Information Base (MIB). The MIB tells Robot/CONSOLE what a message from a specific device means.

If you’ve defined a message set for that message, Robot/CONSOLE takes the action you have specified. Robot/TRAPPER ships with a number of common MIB source files that can be compiled to translate events from network devices. If the MIB you need is not supplied, you can usually download it from the equipment vendor’s Web site and compile it.

If you are doing (or would like to do) System i-based enterprise management, you should consider Robot/TRAPPER.

Interface to enterprise monitors
If you are not doing System i-based enterprise management, Robot/TRAPPER also acts as an interface for Robot/NETWORK and Robot/CONSOLE that allows two-way communications with an enterprise monitor such as Netcool or Remedy. Help/Systems supplies MIBs that you can compile on the enterprise monitor to enable it to translate the SNMP trap events sent by the System i.

When an SNMP trap (message) is sent to the enterprise monitor by a Robot product, the operations staff at the enterprise monitor console can review the event and reply to it directly. Robot/TRAPPER picks up the reply and directs it to its source, so the reply is applied to the correct System i message.

Every day, your network of devices grows bigger and becomes more complex. The job of network monitoring has also grown considerably—whether your monitoring efforts center on the System i or on a large enterprise. In fact, your network may have grown so complex that it’s scary. Robot/TRAPPER can help take the fear and confusion out of the equation. But, you’ll only know if you give it a try. Help/Systems invites you try it for 30 days for free!

Contributed by Terri Preston, Technical Consultant

By evaluating your goals, the choice may become clearer

If you have both Robot/SCHEDULE and Robot/CONSOLE, you have two Help/Systems products that can help you with resource monitoring. Robot/SCHEDULE checks local resources and their current status by using OPAL. Robot/CONSOLE lets you set up an automated process to monitor resources such as lines, subsystems, controllers, and more without writing OPAL. When you use Robot/CONSOLE resource monitoring, it notifies you whenever resources are not available (not in the expected state) and when their status changes again. It also provides a detailed history of all the status checks.

As you implement resource monitoring, you will find that some resources can be monitored by either Robot/SCHEDULE or Robot/CONSOLE. If you have both, how do you decide which is the better candidate to monitor what?

How does Robot/SCHEDULE excel?
Robot/SCHEDULE was the first of the Robot products to offer resource monitoring. The primary purpose of Robot/SCHEDULE’s resource monitoring is to check that resources are available when a job needs them to run successfully. Robot/SCHEDULE resource monitoring lets you:

* Create a job and use OPAL to check on the resource status.

* Schedule the job to run every so often (an EVERY type job that also can use time ranges).

* Schedule the job only when you need to check the status of the resource.

* Run the job on demand via the DO or DS override options.

* Put the job on hold easily.

* Send a pager, e-mail, or text message (via Robot/ALERT) each time the resource is still in the unexpected state when checked.

* Run a job based on resource status.

What does Robot/CONSOLE do differently?
Resource monitoring was so popular in Robot/SCHEDULE that when Robot/CONSOLE 4.0 was designed, Help/Systems decided to provide an even more robust systems management capability. Robot/CONSOLE lets you:

* Check a resource at intervals (ranging from 5 to 180 minutes) without scheduling a job.

* Set up resource checking easily; OPAL is not required.

* Check a resource more than once before reporting an unavailable status (check from one to 999 times).

* Track resource status history. This can help you identify “problem” resources.

* Include a summary of availability in the Robot/CONSOLE Good Morning Report.

* Schedule the RBCCHKRSC command as a Robot/SCHEDULE job and run it at a pre-determined time (on a schedule).

* Stop monitoring by changing the monitoring priority to zero.

* Reduce message overload. Robot/CONSOLE generates one message after the specified number of checks show the resource is not in its expected status. No further messages are sent until the resource’s status changes.

* Customize message text sent to a pager, by e-mail, or other notify options within a message set. (Note: Pager or e-mail notification requires Robot/ALERT.)

* Schedule the RBCCHKRSC command as a Robot/SCHEDULE job with the Force Message parameter set to *YES. Each time the job runs and the resource is not in the expected status a message, Robot/CONSOLE sends a message. For example:

RBCCHKRSC RESOURCE(QBATCH) TYPE(SBS) LIBRARY(QGPL) FRCMSG(*YES)

* Monitor a larger selection of resources.

Making the call
Both Robot/SCHEDULE and Robot/CONSOLE offer significant resource monitoring capabilities. When you are trying to decide which one to use, think about these points:

* If you are monitoring a resource primarily to make sure a job runs correctly and it can be monitored by Robot/SCHEDULE, it’s best to use Robot/SCHEDULE. Keeping all the information in Robot/SCHEDULE makes it easier to see job dependencies.

* If you need to monitor a resource that can’t be monitored by Robot/SCHEDULE, you must use Robot/CONSOLE.

* If you need to monitor a resource most of the time (not relative to any particular job) and it’s a resource that can be monitored by either product, use the product with which you are more familiar.

Setting up resource monitoring in Robot/CONSOLE
Setting up resource monitoring in Robot/CONSOLE involves two parts. First, you tell Robot/CONSOLE the resource to monitor. Then, you set up a message set to handle the message. The sample panels shown check the QBATCH subsystem every five minutes to make sure it is active.

Setting up resource monitoring in Robot/SCHEDULE
Robot/SCHEDULE can do the same thing. To set up monitoring in Robot/SCHEDULE, you would create two jobs—an EVERY-type job that runs every five minutes to check the subsystem and a reactive job with OPAL that reacts to the EVERY job. You need two jobs because OPAL can’t be attached to an EVERY-type job.

Conclusion
The Robot products are designed to be flexible and let you solve problems more than one way. If you have both Robot/SCHEDULE and Robot/CONSOLE, you have several ways to monitor resources to make sure jobs run smoothly and to improve data center management.

If you need to monitor resources beyond those that can be monitored by Robot/SCHEDULE or Robot/CONSOLE, take a look at Robot/TRAPPER.

Contributed by Heath Kath, Technical Training Consultant