John Alvord, IBM Corporation

jalvord@us.ibm.com

Follow on twitter

Introduction

Twice a year installations need to change the clocks on many systems. Identifying which systems did not have their time changed is often of great interest. This document shows you how to create a situation which will alert when an agent is running with a system time that is very different from the hub TEMS system time. Based on those events you can undertake recovery actions. This can also be useful to identify cases where a time protocol is in use but has been badly configured and is not working as expected. I had one case where the system involved had a broken hardware timer.

This is an model situation and not suitable for production use. For example if an agent is in another timezone , it would be normal for the system time to be different. During a DST transition, you might get many alerts that could be ignored. If each agent was in the same timezone as it the TEMS it reports to no extra alerts would be seen.  

One important aspect of *TIME tests is that the two items tested must be in different attribute groups. If you have both sides in the same attribute group, the situation fires or does not fire somewhat randomly. That is a undocumented part of ITM and the Situation Audit project warns about it.        

Step by Step Situation Development

For the attribute to test, select a single row attribute group specific to the operating environment. Here are good choices for Linux/Unix/Windows:

Linux: Linux Machine Information

Unix: Machine Information

Windows: Computer Information

The example situation here is for Linux.

The test situation will be named IBM_time_test. Start with a situation on the target system and select Attribute Group Linux Machine Information and attribute Timestamp.

Next click OK and start to develop the situation

Click on column function area [left third]. The following dialog box pops up

Click on Cancel

Click on column function area and select “Compare Time to a time + or – delta”

In the selection chose Local_Time.Timestamp.

Set the delta time and select OK. I will leave the settings at + one hour for this example situation formula.

Apply  and test the situation.

You will need one situation for agent ahead of the TEMS time nd another situation for agent behind TEMS time

The formula advanced display shows

(  TIME(#LNXMACHIN.TIMESTAMP) > ‘#’Local_Time.Timestamp’ + 1H’)

This compares the Agent side Linux Machine Information Timestamp with the TEMS side Local_Time. For example if you wanted to alert when the agent was 30 minutes ahead of the  TEMS, you would do

(  TIME(#LNXMACHIN.TIMESTAMP) > ‘#’Local_Time.Timestamp’ + 30M’)

Suppose Agent is at 1:35 PM and TEMS is at 1PM.  Left side Agent is 1:35pm, right side TEMS is at 1pm, TEMS timestamp + 30 minutes is at 1:30pm. Test is 1:35pm more than 1:30PM – which is true and so situation event fires.

If you wanted to alert when the agent was 30 minutes behind the TEMS.

(  TIME(#LNXMACHIN.TIMESTAMP) <  ‘#’Local_Time.Timestamp’ – 30M’)

Suppose Agent at 12:55 PM and TEMS at 1:30PM.  Left side Agent is 12:55PM, right side TEMS is at 1:30pm, TEMS timestamp – 30 minutes is at 1:00pm. Test is 12:55 pm less than 1:00PM – which is true and so situation event fires.

Note that if the TEMS and the agents involved are in different time zones, the formula would need to adjust.

Summary

This shows how to create a report about current agents and the DST status. I decided not to include the model situation because of simplicity.

Sitworld: Table of Contents

History

The original post used the same attributes on both sides of the formula and that was corrected on 15 April 2016.

Photo Note: Rascal in Repose, Big Sur 2006.