|
Trouble Ticket Integration - Mail/SNMP
This page appears when you click the Mail / SNMP option under the Trouble Ticket Integration node of the MANAGER SETTINGS tree that appears when you follow the menu sequence: Admin -> Settings -> Manager. By default, this page is categorized into a Mail section and a SNMP section. To integrate the eG Manager with a TT System via a TT Mail Interface, follow the steps below:
If you wish to integrate the eG Manager with a TT System via a TT Mail Interface, set the Enable mail alerts flag in the Mail section to Yes. By default, this flag is set to No. Then, specify the Subject of the email alerts that the eG manager will send to the TT system in the right panel of the Mail/SNMP sub-node. To ensure that the mail subject reflects the problem component name, problem component type, the problem priority, etc., variables can be used in the Subject definition, in the following format: $alarmid#$user#$cname#$ctype#$layer#$prior#$pdesc. The variable $alarmid in the Subject ensures that the subject of the TT mail contains the alarm id. Similarly, the $user, $cname, $ctype variables represent the user with whom the alarm is associated, the name of the problem component, and the problem component type, respectively. Likewise, the $layer, $prior, and $pdesc variables denote the problem layer, the alarm priority, and the alarm description, respectively. The ‘#’ is the separator, but it can be changed. You can rearrange the order of the variables, and even omit a few variables if need be; but, the variable names and the ‘$’ symbol preceding the name should not be changed. A sample subject has been provided below:
192.168.10.12_14678945321#john#printer:NULL#Host_system#NETWORK#Critical#Network connection down
This mail subject has been described below:
192.168.10.12_14678945321 is the alarm id that eG's trouble ticketing engine automatically generates every time a new alarm is processed by it; typically, this will be of the format: <ManagerIP>_<a long value> john is the user with whom the problem component is associated. printer:NULL is the hostname of the problem component Host_system is the component type NETWORK is the layer name Critical is the alarm priority Network connection down is the alarm description
Note
Note that a mail Subject specification characterized by variables discussed above will work only if the SeparateMails flag in the [TTMAIL] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory) is switched on. By default, this flag is set to No, indicating that a single TT mail will comprise of details pertaining to all the alarms that were raised by the eG Enterprise system during that point in time. In such a case, the variables in the Subject cannot be substituted by the corresponding problem information; in this case therefore, by default, eGTTMail will appear as the subject of the TT mail. However, if every problem event in the environment should generate a separate TT mail, then set the SeparateMails flag to Yes. In such a case, the variables in the Subject will be substituted by the corresponding details from the problem information.
Then, specify the Mail output format. This represents the format in which alarm content needs to be emailed. The default format is as follows:
<eG_Alarm>\n<Priority>$prior</Priority>\n<AlarmId>$alarmid</AlarmId>\n<User>$user</User>\n<ComponentName>$cname</ComponentName>\n<ComponentType>$ctype</ComponentType>\n<Layer>$layer</Layer>\n<Problem>$pdesc</Problem>\n<Service(s)>$Service</Service(s)>\n<DD>$DD</DD>\n</eG_Alarm>
As stated earlier, a single TT mail can comprise of details pertaining to numerous alarms. Every such alarm definition within a TT mail will typically begin with the tag <eG_Alarm> and end with the tag </eG_Alarm>. This essentially indicates that the details contained within these tags pertain to a single alarm. These tags can be changed if so required. For example, you can specify <Alarm_info> and </Alarm_Info> instead of <eG_Alarm> and </eG_Alarm>. The variables $prior, $alarmid, $user, $cname, $ctype, $layer, $pdesc, $service and $dd, during run-time, will display the alarm priority, alarm id, the user associated with the problem component, the problem component’s name, the problem component type, the problem layer, the problem description, the service affected by the problem, and the detailed diagnosis of the problem (if any), respectively. In a TT mail, the value of each of the defined variables will be enclosed within the opening and closing tags defined in the Mail output format. For example, take the case of the specification <Priority>$prior</Priority>. In the TT mail for a critical alarm, this specification will appear as <Priority> critical </Priority>. These tags serve as qualifiers for the enclosed values. In other words, they indicate what value is displayed within. These tags can also be modified, if need be. However, the dollared variable names cannot be changed. ‘/n’ acts as a separator for the values. A sample TT mail output has been provided below:
<eG_Alarm>
<Priority>Normal</Priority>
<AlarmId>2</AlarmId>
<User>john</User>
<ComponentName>king:7001</ComponentName>
<ComponentType>WebLogic_server</ComponentType>
<Layer>WL_SERVICE</Layer>
<Problem>Many invocations{DD}</Problem>
</eG_Alarm>
If the problem component is associated with multiple users, then the $user variable, if used in the Mail output format, will display a comma-separated user list. Typically, these users will be the ones responsible for resolving the issues with the corresponding component. However, some users will be authorized by the eG Enterprise system to oversee the performance of all the components in the environment (for eg., the default users of the eG Enterprise system - admin and supermonitor). In most cases, the responsibilities of such users will be more ‘supervisory’ in nature, and not administrative - i.e. might not involve troubleshooting and problem redressal. Therefore, by default, the eG Enterprise system will hide the ID of this user from the user list displayed in the TT mail output. To ensure that the user list displays such a user ID too, set the Include user details in mail flag to Yes. By default, this parameter will be set to No.
Typically, every new alert generated by the eG Enterprise system will be associated with a unique alarm ID. By default, when every new alarm is processed by eG's trouble ticketing engine, a different alarm ID is generated by the engine, which will be of the format: <ManagerIP>:<a long value>. Instead of this TT engine-generated alarm ID, if you want the original, manager-generated alarm ID to be associated with the alarm and be part of the TT mail output, set the Use unique ID flag to No. By default, this flag is set to Yes.
If need be, you can make sure that the TT mails indicate the alarm priority using numbers instead of priority names such as critical, major, minor, or normal. For this purpose, you will have to set the Priority as numeric flag to Yes. By default, this flag is set to No, indicating that the priority of an alarm is indicated using the priority name by default. If this flag is set to Yes instead, then the default priority name-number mappings defined in the [TTMAIL] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config folder) will automatically apply. These default mappings are as follows:
Critical=1
Major=2
Minor=3
According to these mappings, if the Priority as numeric flag is set to Yes, then, in every TT mail sent subsequently, critical priority will be represented by number 1, major priority by number 2, and minor priority by number 3. If required, you can even change the numbers that should represent the alarm priorities. For instance, your priority name-number mapping can be as follows:
Critical=10
Major=11
Minor=12
Also, by setting the Apply priority for all TT mails flag to Yes or No, you can indicate whether the AllowedAlarms setting applies only to each new alarm ID that is raised by the eG manager or to modified alarms as well. As already stated, if an existing alarm has been modified, the eG manager retains the earlier assigned alarm ID for this alarm. The following are considered alarm modifications:
A change in the alarm priority: This could be a switch to a higher or lower priority. A change in the alarm description: For example, originally, a usage-related alarm may have been raised on disk ‘D’ of a server. Later, disk ‘C’ of the same server might have experienced a space crunch, causing another alarm to be raised. In this case, the description of the original alarm will change to indicate that both disks C and D are experiencing a problem, but the alarm ID will not change. Changes in alarm description may also happen if additional tests being run for the same layer indicate a problem. A change may involve either an addition to the description (as in the example above) or a removal of one or more descriptors (e.g., the space usage of disk ‘C’ in the example / above returning to a normal condition). A change in the list of impacted services.
If the Apply priority for all TT mails flag is set to Yes, then the eG manager will send an email alert into the TT system even if one of the above modifications occur on an existing alarm, as long as the priority of the modified alarm belongs to the list of priorities configured against Alarm preferences in the Common Settings page. On the other hand, if the Apply priority for all TT mails flag is set to No, then the eG manager will send email alerts only for every new alarm ID. In this case, the manager will ignore all subsequent changes to the priority of the alarm.
Finally, click the the Update button to save the changes
Note:
You can even configure the specific tests for which TT mails are to be sent using the TestsList parameter in the [TTMAIL] section. By default, this parameter is set to All, indicating that the eG manager, by default, sends out TT mails for alarms related to all tests. To restrict TT mail transmission to specific tests, provide a comma-separated list of tests against TestsList. While providing test names here, make sure you provide the <internaltestnames> and not the display names. For instance, say, you want TT mails to be sent only when the eG manager raises alarms for the Processes test and the System Details test. To achieve this, your TestsList specification should be as follows:
TestsList=ProcessTest,SystemTest
In the specification above, the internal name for Processes test is ProcessTest, and the same for SystemDetals test is SystemTest. To determine the internal name of a test, do the following:
Open the eg_lang*.ini file (from the <EG_INSTALL_DIR>\manager\config directory), where * is the language code that represents the language preference that you have set using the USER PROFILE page. In this file, the component types, measure names, test names, layer names, measure descriptions, and a wide range of other display information are expressed in a particular language, and are mapped to their eG equivalents. Now, search the eg_lang*.ini file for the test name of interest to you. For example, to know the internal name of the SystemDetails test, search the language file for the text, SystemDetails. Since the eG equivalent of the SystemDetails test is SystemTest, you will find a specification to that effect in the [TEST_NAME_MAPPING] section of that file. For our example, the specification would be as follows:
SystemTest=SystemDetails
In the SNMP section, if you wish to enable TT Integration over SNMP traps, then set the Enable TT Integration over SNMP trap flag to Yes. Upon clicking the Update button, the ‘trouble tickets as traps’ capability will be automatically enabled for all the SNMP managers that have been pre-defined in the eG Enterprise system.
Once the capability is enabled, then, for ech alert generated by the eG manager, an SNMP trap carrying the following information will be sent to all the third-party SNMP management systems registered with the eG Enterprise system:
- TT ID - unique identifier of the trouble ticket; TTID will be generated based on the settings defined for the third-party SNMP management system;
- Component name - The name of the problem component
- Component type - The problem component type (as it appears in the Current Alarms window of the eG monitoring console)
- Layer - The problematic layer
- Problem Time - the date/time when the problem started (as in the eG alarm window). The format to be used for date and time will be taken from the default setting of the eG Enterprise suite.
- Problem description - A brief description of the problem
Note:
Once an SNMP manager is configured, the eG manager will start sending SNMP traps to that manager, even if the Enable TT integration over SNMP traps flag is set to No. Such SNMP traps will be governed by the Alarm types and SNMP Trap Settings configured using the SNMP MANAGER CONFIGURATION page (Admin ->Alerts -> SNMP Traps -> Receivers and Settings). Moreover, such traps will not carry the TTID.
On the other hand, as soon as the Enable TT integration over SNMP traps flag is switched on, the eG manager will start sending SNMP traps with TTID to the same SNMP manager, alongside the SNMP traps without the TTID. The traps with TTID will be governed by the Alarm preferences and other settings configured in the Common Settings section of the Trouble Ticket Integration. Also, such traps will not be affected by the Alarm types and SNMP Trap Settings configured using the SNMP MANAGER CONFIGURATION page.
If you select a set of Alarm types to be sent as SNMP traps using the SNMP MANAGER CONFIGURATION page (see Figure 3.1), and also set Alarm preferences for TT integration in the Common Settings section, then, once the Enable TT integration over SNMP traps flag is set to Yes, the eG manager will send separate traps for the alarm priorities chosen from both pages. For instance, say that the Critical and Major check boxes are chosen from the Alarm types section of the SNMP MANAGER CONFIGRUATION page while adding an SNMP manager and only the Critical check box is selected from the Alarm preferences section. In this case, the eG manager will send two traps for every Critical alarm – one with TTID and one without TTID – and one trap for every Major alarm. The Critical alarm with the TTID will be sent from eG's trouble ticketing engine to match with the Alarm preferences setting for TT integration, and the Critical alarm without the TTID will be sent from eG's SNMP trap engine to match with the Alarm types setting.
|