Re: Agent Situation Persistence

John Alvord <jalvord-r/[email protected]>
Newsgroups gmane.comp.sysutils.tivoli.general
Message-ID <OF43D60211.185E1FDD-ON88257AD3.007C9701-88257AD3.007E01A6__15056.9047233605$1355439426$gmane$org@us.ibm.com>
I know this was resolved - in some way - but wanted to comment.

Activity on an Agent is largely single threaded. That means that if a 
historical data export is under way and the sampling interval expires - 
the situation evaluation just waits until the historical data export 
completes. If you are running prior to ITM 622 FP7 and there is a BIG 
short term history file, you might we waiting for hours.

Another good example involves APAR IV28538 

PERFORMANCE PROBLEM IN COLLECTING PROCESS INFORMATION
http://www.ibm.com/support/docview.wss?uid=swg1IV28538 

In the initial case we saw, there were 5 process attribute situations. 
Each of them took 8+ minutes to finish the evaluation. A situation that 
should have fired immediately ["should" in some theoretical sense] was 
instead evaluated for the first time about 40 minutes after the agent 
started. The APAR workaround is available at ITM 622 FP6 and the default 
will be changed in the upcoming ITM 623 FP3.

My point is - that if you are absolutely dependent on a rapid alert to a 
condition you need to do some extra work. Maybe run it on its own agent. 
Maybe run it as a private situation with the output sent to Omnibus via 
its own EIF - or even via a SNMP trap. Most times such extreme setups are 
unneeded, but if you have the need - think outside the box.

*Note: the node status update or Heartbeat runs on an independent thread.

**Note: In my Agent survey project 

ITM Example Perl/SOAP  - Agent Survey
http://www.ibm.com/support/docview.wss?uid=swg21572396 

I  discovered this issue by doing a realtime request for current time from 
the agent. If it didn't respond promptly, I could mark it up as a problem. 
It was a total surprise at the time/

Regards, 

  



John Alvord - Ph: 1-720-396-2788    Cell: none 
Customer Support - Tivoli Software - jalvord-r/[email protected]
Advisory Engineer - Tivoli Monitoring - ITM infrastructure
Follow us on Twitter! @Tivolisupport and Facebook
Personalize your support needs with the IBM Support Portal
Use Service Request to get assistance!
For emails regarding a PMR, copy [email protected]
For secure browser uploads: https://www.ecurep.ibm.com/app/upload
For Customer Support guidance: IBM Software Support Handbook









From:   Gregory Mendes <[email protected]>
To:     <[email protected]>, 
Date:   12/11/2012 04:07 PM
Subject:        [TME10] Agent Situation Persistence
Sent by:        [email protected]



Question:  When you have your situation persistence set at "1", is there 
something else in the agent's settings that can cause the agent not to 
respond to "Christmas Lights/fluttering" effects where the situation 
doesn't respond any more based on the sampling interval, etc?
 
I ran a while loop for a test and my agent "sampling interval" was forced 
to 10 seconds.  My loop started and stopped a process and was programmed 
to sleep for 12 seconds in between, outside of my "sampling interval". The 
situation never triggered the alert.  Is there a failsafe mechanism built 
into the agent and if so, what is it called?
 
Regards,

Gregory R. Mendes
770-317-8593
_______________________________________________
TME10 mailing list
[email protected]
Unsubscribe:[email protected]

_______________________________________________
TME10 mailing list
[email protected]
Unsubscribe:[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.