EEM: How to "Create" a named counter in an applet?

[6502]

I am trying to figure out how to create a "named" counter in EEM.  My goal is to:

1 - Create a "watchdog timer" event applet that updates the subsystem "798 type 1" event every time it expires

2 - Create a "none" event applet that is run from the CLI,  which instantiates a named counter & sets it to a a value passed in via the applet parameters.

3 - Create an "application" event applet that is triggered by the subsystem 798 type 1 event watchdog that decrements the named counter by 1, and takes an action when the value reaches zero.

When I try to do this, I keep getting a "%HA_EM-3-FMPD_UNKNOWN_ENV: fh_parse_var: could not find environment variable:" messge in the log, referring to the named counter.

The only counter examples I see in the command reference refer to "well-known" counter names.  I could maybe use one of these, but they're not "well-known" to me.   I'd rather create one that has a name relevant to my applets.

Below are some scripts I wrote as a test:

event manager applet day-timer
!set to 60 seconds for testing
event timer watchdog name day-timer time 60 maxrun 86400
action 0010.000 publish-event sub-system 798 type 1 arg1 "BONG"

event manager applet day-timer-expiry
event tag 1.0 application sub-system 798 type 1
action 0100.000 syslog msg "$_application_data1 : $day_counter"
action 0110.000 counter name "day_counter" op inc value 1

event manager applet initialize-day-counter
event none
action 0100.000 counter name "day_counter" op set value 0

[6502 · Accepted solution]

Well it looks like I ran into CSCsm70738 .  I needed an eem policy with an event that's actually watching the counter in order for the counter to become "instantiated".  Apparently until there's something watching the counter eem doesn't actually initialize the counter variable.  The EEM Command Reference pages for "Action Counter" and "Event Counter" should be updated to reflect this fact.

In terms of debugging, I was wondering what the timer wasn't showing up in "show event manager statistics server":

After I created the policy watching the counter:

[M02@rt37 · Accepted solution]

Hello @6502 

Considering the information about the counter instantiation :

- Watchdog Timer Event Applet

event manager applet day-timer
event timer watchdog name day-timer time 60 maxrun 86400
action 0010.000 publish-event sub-system 798 type 1 arg1 "BONG"

- Application Event Applet

event manager applet day-timer-expiry
event tag 1.0 timer watchdog name day-timer time 60
action 0100.000 syslog msg "$_subsystem_type : $_subsystem_status : $day_counter"
action 0110.000 counter name "day_counter" op dec value 1

- Initialize Day Counter Event Applet

event manager applet initialize-day-counter
event counter name "day_counter" entry valued
action 0100.000 counter name "day_counter" op set value <initial_value>

----

In the `initialize-day-counter` applet, I added an `event counter` entry to ensure that the counter is instantiated properly. This should address the requirement for something to watch the counter for it to be initialized.

Replace `<initial_value>` with the desired starting value for your counter.

[6502 · Accepted solution]

Actually, I need to be able to run the "initialize" policy manually, so I ended up using tags to create a "two-event" policy:

action 00090.020 cli command "event manager applet $counter_name-initialize"
action 00090.025 cli command "event tag 1.0 none"
action 00090.030 cli command "action 00005.000 comment Create a dummy timer event to listen on $counter_name to work around CSCsm70738"
action 00090.035 cli command "event tag 2.0 counter name $counter_name entry-val -2147483648 entry-op lt exit-val 2147483647 exit-op gt"

...

action 00090.105 cli command "trigger"
action 00090.110 cli command "correlate event 1.0 or event 2.0"

The 2.0 counter event fulfills the requirement that something has to be "listening" on the counter before you can use it.  The entry & exit conditions are such that they will never happen, so in effect that event will never trigger this policy.

[MHM Cisco World]

So it solved or not?

What point you stop ?

Thanks 

MHM

[6502]

To close out this thread for now, It appears that the stats of  CSCsm70738 is "terminated".  If anyone from Cisco is watching this thread, I would strongly suggest that you re-open this bug and try to solve it in a way that makes sense.  IMHO, the premise of a non-causal system where you have to pend on a counter event before the event exists is not at all intuitive in this context.  Even creating the policy that you want to actually pend on the counter event first, before creating the counter, doesn't make sense either. Since you must specify entry & exit conditions for that counter policy, how can you do that when the counter your pending on is "indeterminate" until you actually pend on it??