eG Administration

4. MANAGER SETTINGS - COMMAND EXECUTION The COMMAND EXECUTION section appears when you click on the Command Execution subnode under the Manager Settings node of the SETTINGS tree structure. Like email IDs / mobile numbers, you can associate one/more custom scripts with users to the eG Enterprise system. Whenever alarms are raised/modified/closed for a specific user, the associated custom script will automatically execute, so that the details of the alarms are routed to third-party customer relationship management systems or TT systems, and trouble tickets automatically created (or closed, as the case may be) for the corresponding user. The custom scripts thus provide a mechanism by means of which eG alerts are integrated into CRM/TT systems. These custom scripts can be configured in addition to or instead of email / SMS alerts. Using the COMMAND EXECUTION section, you can configure the details of these scripts as follows: First, to enable the command execution capability, set the Enable Command Execution flag to Yes. By default, this is set to No. To track the status of the script execution and to troubleshoot issues with the same, use the mailexec.log file that is automatically created in the <EG_INSTALL_DIR>\manager\logs directory when the custom scripts execute. You can specify the maximum size up to which this log file can grow, in the Log file maximum size text box. When the file reaches the specified size limit, the details originally logged in the mailexec.log file will be moved to another log file named mailexec.log.1, and the newer information will be logged in the mailexec.log file instead. This log rotation mechanism helps ensure that the log file does not grow beyond control. The default maximum size is 1 MB. You can even indicate the type of information you want to be logged in the mailexec.log file. By default, the log files capture both the errors and the standard output of the specified Command; accordingly, the Log entries for stdout also flag is set to Yes by default. If you want to capture only the errors, set the Log entries for stdout also flag to No. To execute the script for every alert that is generated, set the Separate execution flag to Yes. This means that when the script executes, the details of only a single alert will be included in the script output. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to Yes. 31/08/2011 11:06:51 USER admin COMMAND echo PARAMS -ComponentType &ldqquo;Host system” -ComponentName “esx150” -LayerName “Operating System” -Desc “-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67” -StartTime “Aug 31, 2011 11:05:18” -Priority “Critical&rdquo 31/08/2011 11:06:51 INFO -ComponentType “Host system” -ComponentName “esx150” -LayerName “Operating System” -Desc “-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67” -StartTime “Aug 31, 2011 11:05:18” -Priority “Critical” As you can see, for a single alert, two lines have been logged in the mailexec.log file. The first line displays the USER who will be receiving the alarm intimation, the syntax of the COMMAND that is being executed by the script, and the PARAMS - i.e., the input parameters/arguments - that the command takes while executing. In the sample provided, echo is the COMMAND executed by the script. Therefore, the PARAMS tag in our extract is followed by the input parameters required by the echo command. As you can see, every parameter of the echo command consists of two components: the parameter name and its value at runtime. While the param name begins with a - (hyphen), its runtime value is enclosed within “double quotes”. Take for instance the parameter, -ComponentType “Host system”. Here, -ComponentType is the parameter, and the “Host system’ is its value. The second line logs the output of the COMMAND - in the case of our example, this will be the output of the echo command. The command output typically begins with the tag INFO, and will be followed by the details of the alert being sent. Like its input, the output of the echo command too is a combination of the parameter name and its value at runtime. While the parameter name indicates what type of information is being sent, the actual information itself is contained within “double quotes” and forms the parameter value. The parameters included in the output of the echo command have been discussed in the table below:
   PARAMETER | Description
   ComponentType | The problem component type
   ComponentName | The name of the problem component
   LayerName | The name of the problem layer
   Desc | A brief description of the problem; typically, for the echo command, a problem description includes the following: the site affected; if the alarm does not pertain to any site, only a ‘-’ will appear in the output, as is the case in our sample output; the problem test - this is Processors - Esx in our example; the problem measure - this is Usage in our example; the alarm description - in the case of our sample, this is: Physical CPU usage of ESX server's processor is high; the problem descriptor (if any); in the case of our example, this is Processor 3. For non-descriptor-based tests, a ‘-’ will appear here. the measurement host - this is 192.168.8.67 in the case of our example the last measurement value - this is not available in the case of our sample. This value will appear in the description only if the Show last measure value in alerts flag in the MAIL ALERT PREFERENCES page (Alerts -> Mail Settings -> Alerts) is set to Yes.
   StartTime | The problem date/time
   Priority | The problem severity
If the Separate execution flag is set to No on the other hand, the script will be executed only once for all alerts raised simultaneously. Given below is an extract from the mailexec.log file, when the Separate execution flag is set to No. 30/08/2011 12:13:27 USER admin COMMAND echo PARAMS -ComponentType “Microsoft SQL” -ComponentName “sql100:1433” -LayerName “MS SQL Service” -Desc “-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77” -StartTime “Aug 30, 2011 12:10:26” -Priority “Critical” # -ComponentType “Windows” -ComponentName “win77” -LayerName “Windows Service” -Desc “-|WindowsServices|Availability|Service not up|eGAgentMon|win77” -StartTime “Aug 30, 2011 12:10:41” -Priority “Critical” # -ComponentType “Host system” -ComponentName “esx150” -LayerName “Operating System” -Desc “-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67” -StartTime “Aug 30, 2011 12:11:18” -Priority “Critical” # -ComponentType “Host system” -ComponentName “vdi136” -LayerName “Network” -Desc “-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67” -StartTime “Aug 30, 2011 12:11:23” -Priority “Critical” 30/08/2011 12:13:27 INFO -ComponentType “Microsoft SQL” -ComponentName “sql100:1433” -LayerName “MS SQL Service” -Desc “-|MsSqlNet|Availability|SQL Server unavailable|master|192.168.8.77” -StartTime “Aug 30, 2011 12:10:26” -Priority “Critical” # -ComponentType “Windows” -ComponentName “win77” -LayerName “Windows Service” -Desc “-|WindowsServices|Availability|Service not up|eGAgentMon|win77” -StartTime “Aug 30, 2011 12:10:41” -Priority “Critical” # -ComponentType “Host system” -ComponentName “esx150” -LayerName “Operating System” -Desc “-|Processors - Esx|Usage|Physical CPU usage of ESX server's processor is high|Processor 3|192.168.8.67” -StartTime “Aug 30, 2011 12:11:18” -Priority “Critical” # -ComponentType “Host system” -ComponentName “vdi136” -LayerName “Network” -Desc “-|Network - Esx|Availability|Network interface of the ESX server is down|vmnic1|192.168.8.67” -StartTime “Aug 30, 2011 12:11:23” -Priority “Critical” In this case again, only two lines will be logged in the mailexec.log. The first line will display the USER name, COMMAND syntax, and the command PARAMS (with their corresponding values). Since multiple alerts will be clubbed in the command output, the first line will include the PARAMS for all alerts. ‘#’ (hash) will be used to separate the parameter-value pairs of one alert from the other. The second line, which begins with the tag INFO, will display the combined output of all email alerts generated simultaneously - each alert in the output will also be separated by the hash (#) symbol. Note: The Separate execution flag setting will take effect only if a user is configured to receive New alarm intimations alone - i.e., if the Type of notification is set to New for a user in the ADD USER page. For users who are configured to receive the Complete List of alarms, details of multiple alarms will always be clubbed in a single script execution, regardless of this flag setting. Specify the maximum permissible length of the command in the Command length text box. The command line here includes the command syntax, its input arguments (if any), and the value of each argument. By default, the command line can have a maximum of 4000 characters. You can alter this default setting by specifying a length of your choice in the Command length text box. If the Separate execution flag is set to Yes, then, if the Command length is violated, the command will be truncated at the end of the parameter value that is closest to the configured Command length. If the Separate execution flag is set to No, then, upon a Command length violation, the command will be truncated at the end of the complete alert specification that is closest to the configured length. Specify a comma-sepatrated list of scripts that will be executed by the eG manager whenever an alert is generated to the user, in the Allowed script types text box. By default, the script types supported by eG are: .exe, .com, .bat, .wav, .wsf, .vbs, .prn, .sh, .perl Note: This capability is supported in a redundant eG manager configuration. In case of the redundant manager configuration, if the primary manager is up and running, it will perform script execution. If the primary manager is down for any reason, the secondary manager will perform script execution. Finally, click the Update button.