5 Replies Latest reply: Jun 28, 2012 12:45 PM by Garland Smith RSS

Delaying a parameter from starting immediately

patrick

Hello Folks,

 

It's been a while since I had a deep dive in this, but I am having a problem with a race condition existing between the time a APP Class instantiates as an instance and the time AS_EVENTSPRING sets thresholds.  Here is the issue:

 

1) Start the PatrolAgent (Unix).

2) AS_EVENTSPRING process and applies thresholds to parameters and sets the pconfig variable:

"/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag" = { REPLACE = "1" }

3) Two minutes later, the CPU instance is created with parameters, but they did *NOT EXIST* when step (2) ran.

4) As such, the thresholds to parameters within the CPU instance are not applied.

5) If I set:

"/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag" = { REPLACE = "1" }

to "/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag" = { REPLACE = "2" }

 

of course AS_EVENTSPRING will re-apply the thresholds and they will now take effect.

 

I don't want to micro-manage this stuff for obvious reasons.  So my thought is to see if I cannot delay the RefreshParamSettings parameter to wait, say 3-5 minutes before it processes parameter thresholds.  According to the default poll time, it is 95 seconds every time this parameter runs.  If I remember correctly, the parameter starts *IMMEDIATELY* after the Agent is re-initialized, then runs every 95 seconds thereafter.

 

Anyone else hit this problem and have some fix/workaround for this?

 

Thanks!

  • 1. Re: Delaying a parameter from starting immediately
    Garland Smith

    The logic to create thresholds for parameters is based on state change

    actions when objects get created.

     

    It shouldn't matter when the object is created, the thresholds should be

    created as a result of instance

     

    creation.  The most likely explanation for what you're experiencing is that

    you may have ___tuning___

     

    rules created for some of your metrics.  If you have both PKM for Event

    Management AND ___tuning___

     

    rule for the same parameter, the ___tuning___ rule wins.  Check your pconfig

    for ___tuning___ rules

     

    and compare with your PKM for Event Management rules (pconfig +get | find

    "tuning" or pconfig +get | grep tuning).

     

     

     

    I hope this helps.

     

     

     

    Garland Smith

  • 2. Re: Delaying a parameter from starting immediately
    Jonathan Coop

    How about setting the thresholds using operator overrides, still agent config variable. Jon

     

    Sent from my iPhone

  • 3. Re: Delaying a parameter from starting immediately
    Garland Smith

    The AS_EVENTSPRING thresholds are set based on UpdParState events that are

    generated when a parameter

     

    is created.  An instance created later in the startup process should get its

    thresholds applied upon creation.  My

     

    guess is that you have mixed Operator Override and PKM for Event Management

    rules, in which case the Agent

     

    Tuning rule will take precedence upon startup.  I would check for the

    existence of competing pconfig variables

     

    relating to threshold management.  The best way to overcome this issue is to

    focus on one form of threshold

     

    management and use that methodology exclusively.

     

     

     

    Regards,

     

    Garland Smith

  • 4. Re: Delaying a parameter from starting immediately
    patrick

    My goodness, Garland and Jon.  Your names are familiar; I rememeber working with Garland on a few support cases.  Hope you are well!

     

    Garland, you stated:

    The AS_EVENTSPRING thresholds are set based on UpdParState events that are

    generated when a parameter is created.

     

    I looked in the StdEvents.ctg for that specific event, and I noticed there is no AS*.psl script called.  Did you mean this one?

     

     

    EVENT_RECORD "4" STATE_CHANGE NO_TRAP DO_NOT_STORE "NONE" "Patrol"

    "The agent executes the discovery script of an application

    to detect whether or not it is running.

    This event indicates that the agent has started the discovery

    script of this application"

    "Discovery of application '%s' activated."

    ESCL_ACTION  784393923 "# Escalation Command"

    NOTIFY_PSL_ACTION LOAD "AS_EVSevSTDEVENTS_PS_CALL.psl" <--- This appears to look in the Agent's config file and upon this event being triggered, will call this PSL code that contains the set_ranges() function to set the appropriate parameters, is that correct?

     

    Thanks!

  • 5. Re: Delaying a parameter from starting immediately
    Garland Smith

    Hello Patrick,

     

     

     

    In my previous note, I mentioned that the AS_EVENTSPRING logic is in the

    UpdParState event.  I believe I should

     

    have said that it's in the UpdInstState parameter.   The point is that

    instances come and go dynamically as the KM

     

    functions.  When an instance is created, all of its Parameters are created.

    When this happens, PKM for Event

     

    Management applies the appropriate thresholds.  Were it not for this

    methodology, the results would be completely

     

    chaotic regarding thresholds.

     

     

     

    I hope this helps.

     

     

     

    Garland Smith