Change in the Self-Monitoring Topology Workspace.

Body

Change in the Self-Monitoring Topology Workspace

The issue reported was with an agent that linked to one of two RTEMS, a very common configuration.

Previously the agent was reported as online on whichever of the RTEMS it was connected to, however now it also reports offline if it has connected to the other RTEMS previously.  

At the start the agent connects to RTEMS_A and is shown in the Self-Monitoring Topology workspace as online at RTEMS_A.
Then for some reason  (not an issue for this blog) the agent connects to RTEMS_B, so then is shown as online at RTEMS_B .

However the agent will also have another entry, showing as offline at RTEMS_A, where as before the change (previous versions) this was not seen.

This is due to a change at 6.3 FP06 (Apar IV69246).

This APAR addresses  the problem of last heartbeat times for agents connected to a RTEMS being incorrect in the  Self-Monitoring Topology view.

IV69426 changed  the SQL statement that retrieves the last heartbeat time, to request the data from the RTEMS instead of HUB TEMS, given that the  agent is connected to an RTEMS, not the HUB TEMS.

This means all of the other attributes are now being retrieved from RTEMS as well,  including the online/offline agent status.

Prior to this APAR change, the query was directed only to the HUB TEMS, not the respective RTEMS.

Because the data table being queried is memory resident, when an Agent first connects to RTEMS_A and later switches connection to RTEMS_B,
RTEMS_A still hold a record in memory of Agent, though now in offline status, while the new ThruNode, RTEMS_B, has a record in memory for the Agent with status of online.

The issue was further complicated as the agent was stopped, so showing as offline at both RTEMS.

A "clear offline entry" was then done, when the “KFWITM024 1 navigator update pending” was seen, the refresh was done.

The results are the agent is no longer seen in the topology view but can still be seen as offline in the Self-Monitoring Topology workspace for the RTEMS it was offline with at an earlier time.

So taking the above example, since the agent was last conencted to RTEMS_B, the agent was not shown with RTEMS_B.
However it is still shown as offline on the RTEMS_A, again this is due to the memory resident on RTEMS_A.
If RTEMS_A is recycled then the entry in the Self-Monitoring Topology workspace is cleared and the agent is no longer shown.

This is due to the "clear offline entry" and pressing the "pending updates" button has nothing to do with the topology view,
the pending updates is for the TEP navigator tree only.

When an agent is removed or added to the TEMS node list, and the internal tree kept by the TEPS is updated.

The internal tree kept by the TEPS is not what the topology is based off.

So the Managed System Status workspace view and the Self-Monitoring Topology view are based upon completely separate
queries, against completely different data tables.  You may therefore see slightly different values in each.

The true view of TEMS and agents status is shown by the Managed System Status workspace view, and is the one to check against.

Subscribe and follow us for all the latest information directly on your social feeds: