RE: Agent Situation Persistence

Gregory Mendes <[email protected]>
Newsgroups gmane.comp.sysutils.tivoli.general
Message-ID <BAY148-W5545C5C27710604E095F64F74E0__33787.0758878582$1355441641$gmane$org@phx.gbl>
Hey John, As always, I appreciate your valuable information.   Regards,



Gregory R. Mendes
770-317-8593

 To: [email protected]
Subject: Re: [TME10] Agent Situation Persistence
From: jalvord-r/[email protected]
Date: Thu, 13 Dec 2012 14:56:22 -0800

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]

_______________________________________________
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.