Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring an Event Policy to Pass Arguments to an Event Script

When an event policy invokes an event script, the policy can pass arguments to the script. The following sections outline how to configure the arguments in the event policy and use the arguments within the event script:

Configuring Event Script Arguments in an Event Policy

You configure the arguments that an event policy passes to an event script within the then clause of the policy under the event-script filename arguments hierarchy. You can configure any number of arguments for each invoked event script.

You include arguments to the script as name/value pairs. The argument values can include variables that contain information about the triggering event or other received events. The event script can then reference this information during execution. You can use variables of the following forms:

  • {$$.attribute-name}—The double dollar sign ($$) notation represents the event that is triggering a policy. When combined with an attribute name, the variable resolves to the value of the attribute associated with the triggering event. For example, {$$.interface-name} resolves to the interface name associated with the triggering event.

  • {$event.attribute-name}—The single dollar sign with the event name ($event) notation represents the most recent event that matches event. When combined with an attribute name, the variable resolves to the value of the attribute associated with that event. For example, {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} resolves to the interface name associated with the most recent COSD_CHAS_SCHED_MAP_INVALID event cached by the eventd process.

For a given event, you can view a list of event attributes that you can reference by issuing the help syslog event command.

For example, in the following command output, text in angle brackets (< >) shows attributes of the COSD_CHASSIS_SCHEDULER_MAP_INVALID event:

Another way to view a list of event attributes is to issue the set attributes-match event? configuration mode command at the [edit event-options policy policy-name] hierarchy level.

For example, in the following command output, the event.attribute list shows that error-message and interface-name are attributes of the cosd_chassis_scheduler_map_invalid event:

In this set command, there is no space between the event name and the question mark (?).

To view a list of all event attributes that you can reference, issue the set attributes-match ? configuration mode command at the [edit event-options policy policy-name] hierarchy level.

Using Arguments in an Event Script

When an event policy invokes an event script, the event script can reference any of the arguments that are passed in by the policy. The names of the arguments in the event script must match the names of the arguments configured for that event script under the [edit event-options policy policy-name then event-scripts filename arguments] hierarchy in the configuration.

To use the arguments within a SLAX or XSLT event script, you must include a parameter declaration for each argument. The event script assigns the value for each script argument to the corresponding parameter of the same name, which can then be referenced throughout the script.

XSLT Syntax

SLAX Syntax

To use the arguments within a Python event script, you can use any valid means in the Python language. The following example uses the Python argparse module to process the script arguments. A parser.add_argument statement must be included for each argument passed to the script.

Python Syntax