Specifies the event identifier to which the event writer rule applies. You can use a UNIX regular expression. A period and an asterisk (.*) matches any event name. For example, you can specify [Aa].* to match any event that starts with uppercase or lowercase “a.”
If the event_ ID parameter is simple text (not a regular expression), it must exactly match the generic event’s event ID. Partial matching does not count. If the event_ID is a regular expression, the length of the regular expression match is used to determine how well the event writer rule’s event_ID matches the generic event’s event ID.
Specifies the name of the object, which is typically a device or host associated with the event. A period and an asterisk (*) is the default and indicates that the source object is ignored in selecting the rule.
If an incoming event matches several rules when source types and event IDs are evaluated, devices are compared. Rules that match the device of the incoming event take precedence over rules that have asterisk (*) specified for device.
If you have defined rules for assigning device names, this parameter can be useful. For example, if you name devices located in the United States USxx, you can specify US.* in this parameter to execute a particular writer action for events from devices in the United States.
Identifies a user associated with the event. Use this parameter to execute a particular action for events from a specific user. Many events do not have specific users associated with them. This parameter cannot contain a UNIX regular expression. You must supply an exact user ID or an asterisk. An asterisk (*) is the default and indicates that the user is ignored in selecting the rule.
If an incoming event matches several rules when source types, event IDs, and devices are evaluated, user IDs are compared. Those rules that match the user ID associated with the event take precedence over rules that have asterisk (*) specified for user_ID.
Automatically displays the major type of source directing events to the event writer. This parameter is required. Its value is determined by the event source. For events from CA NSM on Windows, the value must be “tng.” For events from CA NSM on UNIX, the value must be “uni.”
Automatically displays the minor type of source directing events to the event writer. For events from CA NSM, this parameter contains the event type. Use an asterisk (*) to accept all events.
Specifies the action that occurs when the event writer receives this type of event using one of the following values:
Write a new request for each event.
Update an existing request or requests (if they exist), or create a request if no requests are found. By default, records are located by matching on the log_agent and affected_resource attributes. The user can override the defaults by specifying a list of any request attributes.
Like CR_UPDATE, except a request is never created when no matching requests are found.
Execute the command specified in the command parameter.
Note: If CA SDM cannot access a request or change order, it attempts the update again after a fixed interval.
Specifies the name of a request template to use to create a request. This parameter is not required and is ignored if the action is not CR_CREATE.
Note: The request template must be created before the rule is defined.
Specifies the command to execute if the action parameter value is COMMAND. Substitution arguments, as the following table shows, can be incorporated into the command. The arguments are replaced by their real-time values when the command is executed:
The device name or node identifier
The user name or ID
The event date
The event time
The source event string that triggered the event
The associated event data
A measure of importance for the event
The source application ID
The agent name or further delineation of the event
The daemon-supplied string resulting from rules
The daemon identifier that assigned the handle
The status of the handle (valid values are create, update, or terminate)
Specifies whether logging occurs, using one of the following values:
No logging, other than normal error logging, occurs. NONE is the default value.
Logging occurs in the CA SDM log (stdlog.0) in its internal generic event format.
Logging occurs in the UNIX syslog, which can be forwarded to the Unicenter Console. The event is assigned a message ID (CAPD ....13) to allow event processing from the Unicenter Console.
Logging occurs in the CA SDM log (stdlog.0) and the UNIX syslog.
A 30-character user-defined tag that identifies a specific request associated with an event_id (tng event message) or all messages like an event_id (for example, a wildcarded event_id). event_token is a request attribute and is stored in every request generated by the CA NSM interface. If no event_token is specified in the writer rule, the string “tng_generated” is used. This lets the user update all requests that match the event_token attribute. For example, two different messages for the same asset can update unique requests.
Each CR_UPDATE writer rule specifies the unique message parts and a unique event_token. The event_token is used to find and update the matching request. By default, an activity log containing the message is added to the matching request. In another example, the user can update the status attribute (for example, set status=CL (closed)) in an existing request by specifying the same event_token in the CR_UPDATE writer rule that was used when the request was created using a CR_CREATE writer rule.
For example, the first writer rule below causes the writer process (tngwriter) to create a call request with an event_token equal to ‘SystemCritical whenever it receives a NSM event identified by the string ‘Event1’. The second writer rule causes the writer process to update the status value to ‘CL’ for all call requests with an event_token equal to ‘SystemCritical’ whenever it receives a NSM event identified by the string ‘Event2’.
Event1:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE:::SystemCritical::: Event2:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE:::SystemCritical:::%SEARCH=EVENT_TOKEN;%STATUS=CL
Contains the following types of information:
Request attribute values are specified using the following syntax: %ATTRIBUTE=value, where ATTRIBUTE is an attribute name identified in text_api.cfg that maps to a CA SDM Majic call request attribute. This file is located in $NX_ROOT/site (UNIX) or installation‑directory\site (Windows).
Note: If you use multiple keyword/value pairs, separate each one with a semicolon (“;”).
For example, the writer rule below causes the writer process (tngwriter) to create a call request with assignee equal to ‘mccda04’ and customer equal to ‘nsm’ whenever it receives a CA NSM event identified by the string ‘Event4’.
Event4:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::%ASSIGNEE=mccda04;CUSTOMER=nsm
The syntax for the list of attributes to match is specified as follows:
%SEARCH=attribute1[, attribute2…], where SEARCH is a fixed keyword and attribute1, attribute2, and so on are ATTRIBUTE names specified in the text_api.cfg.
The default search list of attributes is "asset_name" (DEVICE or UUID) and LOG_AGENT. The SEARCH keyword adds attributes (to match on) to the default search list. The SEARCH_EXPLICIT keyword completely overrides the default search list. Only the list of attributes following the SEARCH_EXPLICIT keyword are used to search for a call request.
For example, the writer rule below causes the writer process (tngwriter) to update the status value to ‘CL’ for all call requests with assignee equal to ‘mccda04’ whenever it receives a CA NSM event identified by the string ‘Event2’.
Event2:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE:::SystemCritical:::%SEARCH=ASSIGNEE;%STATUS=CL;%ASSIGNEE=mccda04
An attribute in the list of attribute values is used to search on if the attribute is in the SEARCH or SEARCH_EXPLICIT list. If it is not in the search list it is used to set or update the attribute's value in the call request. It cannot be used for both in the same writer rule.
Note: For more information about text_api.cfg and how CA SDM uses it, see the Administration Guide.
You can use the following special parameter names anywhere in the user_parms string:
Message text associated with this CA NSM message.
AHD.DLL Parm field on CA NSM Message Action Screen.
CA NSM universally unique identifier.
Device (for example, host name) that generated the CA NSM message.
The major type of source directing events to the event writer. For events from CA NSM on Windows, the value is “tng.” For events from CA NSM on UNIX, the value is “uni.”
The minor type of source directing events to the event writer.
Device (for example, host name) that generated the CA NSM message.
The IP address of the host that generated the CA NSM message.
The user name on the host that generated the CA NSM message.
An integer representing how long since 1970 the CA NSM message was generated.
The Date and Time of the CA NSM message (for example, Tue Jul 4 10:23:37 2000).
The severity of the CA NSM message.
Tag data associated with the CA NSM message.
For example, the writer rule below causes the writer process (tngwriter) to create a call request with customer equal to the username value (&username) of the event message whenever the writer receives a NSM event identified by the string ‘Event2’.
Event2:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::%CUSTOMER=&username
Using event_token and user_parms, you can set initial values or update values of all attributes of the request and specify which fields to match when locating records to update. The only restriction is that the description attribute is never updated in an existing call request record. If a record update and the description field are specified, an activity log containing the text of the description is added to the existing record.
You can also specifiy data (<parms...>) to the AHD_Call on the CA NSM message action record that can be used to replace the &Parm parameter specified in your user_parms parameter in your writer rule. In order for the data specified on the AHD_Call to be processed in this way the data (<parms...>) must be preceded with a '%' character and the &Parm 'special parameter' must be included somewhere in the user_parms field of the writer rule.
The following is an CA NSM message action and a writer rule that work together to cause the writer process to create requests with assignee set to ‘mccda04’ whenever it receives a NSM event identified by the string ‘Event3’.
Ahd.dll AHD_Call %ASSIGNEE=mccda04
Event3:::.*:::*:::tng:::*:::CR_CREATE:::::::::NONE::::::&Parm
CA SDM customers upgrading from AHD4.5 and earlier may already be using the <parms...> field. For example, you may be using this data to match on Writer rules. You can continue this practice without change. If you want to use both 'old' and 'new' parameters then you must concatenate a '%' character to your 'old' <parms..> data and then follow with 'new' data.
Example:
ahd.dll AHD_Call old data
ahd.dll AHD_Call %new user_parms
ahd.dll AHD_Call old data%new user_parms
Data before the first '%' character is concatenated to the CA NSM event message which is placed into the Call Request description field. This is how CA SDM has worked in the past. Data after the first '%' character is used to replace the &Parm parameter wherever it is specified in your user_parms parameter in your writer rule.
|
Copyright © 2013 CA.
All rights reserved.
|
|