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

    Delaying a parameter from starting immediately

    Patrick NameToUpdate

      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 NameToUpdate

                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