ITM Nuggets: SPUFI Use Case 2: Retrieve LIVE information on which situations are started, stopped, deleted, etc CLI
MarkLeftwich 270000DTK4 Visits (13578)
The goal is to be able to pull information on which situations are started and stopped in your environment, from across the entire monitoring
infrastructure, straight from the HUB TEMS itself. There are many reasons why you would use this method, here are a few:
Generally the less load on the HUB the better. You may wish to consider moving agents connected to the HUB to RTEMS to help reduce load and
remove the HUB from distribution of some situations.
You can use this method in combination with use case one in the blog series to check which situations have started and then which situations have events
raised, acknowledged, closed, etc (this can be completed all with one SQL statement)
Today we will be using the KDSTSNS tool with some SQL to query the situation status table on the HUB TEMS, specifically the ISITSTSH table.
As in the first blog of the series explained how to query the TEMS, the below information explains how to interpret the output of the SQL, so you can utilise the information for you own means. I will start by breaking down what each column means in the table we are querying and they go through a
basic example of how the TEMS processes the start/stop records. This will give you the basics to go away and try it for yourself!
Each of the rows in the below table represents is a column in the ISITSTSH table on the TEMS and its meaning. You will need to query this table
on the TEMS using SQL provided to retrieve the required data.
Now you know how to read the data, you need to understand the processing of the TEMS. Any action performed with a situation will insert a corresponding row to the TEMS ISITSTSH table.
1) You start a situation on the HUB TEMS. A "S" record appears in the DELTASTAT column to show the situation has started.
2) You then stop a situation on the HUB TEMS. A "P" record appears in the DELTASTAT column to show the situation has stopped.
3) You then notice an "X" record appears in the DELTASTAT column. This shows there has been an error with this situation (maybe it
4) You then decide to delete that situation as it had an issue whilst you investigate the cause. A "D" record appears in the DELTASTAT
column to show the situation has been deleted.
From the output below, you can see an example of each of the above Deltastat types:
WHERE DELTASTAT = 'S' OR DELTASTAT = 'P';
You now have the methodology and the SQL to get the data you need. You could perform health check, test events, etc. You could also open up the resulting file in a spreadsheet editor. A quick text to columns and you can filter away on a single TEMS, situation, DELTASTAT type to really refine masses of information down to concise quality checks.
Hope this has been of use to you. If you have any questions or you would like me to build a test case to find a specific piece of information, please post below and I will respond to you.