|
Filter Mail/SMS Alerts - Mail Alert Settings
By default, a user receives email/SMS alerts for all issues pertaining to all components assigned to him/her. In some circumstances, the user may not want to receive all of these alarms. For instance, in a large, multi-tier infrastructure, a user may be monitoring all the applications and network devices involved in supporting a business service. However, the user may have primary responsibility only for some of the components supporting the business service (e.g., a network administrator's primary responsibility is to monitor the network devices). In such cases, while the user may want to view the status of all the components of the business service, he/she may want to receive email or SMS alerts pertaining to specific components of the infrastructure alone (e.g., network devices).
To enable such selective alerting, eG Enterprise provides administrators with the option to configure the eG manager to not send out email/SMS alerts related to specific layers/components/component-types/tests for specific users.
By default, the ability to filter mail/SMS alerts is disabled. To enable it, follow the menu sequence: Admin -> Alerts -> Mail Settings -> Alert Settings menu sequence. Expand the Settings node in the Mail Alert Settings tree-structure that appears in the left panel. Next, select the Filter Mail/SMS Alerts sub-node within the Settings node. FILTER MAIL/SMS ALERTS section will then appear in the right panel. In this section, set the Allow mail/SMS filter configuration flag to Yes. This will allow Admin users to configure email/SMS filters for user profiles. To allow non-admin users to alter the email/SMS settings defined by the Admin user, set the Allow limited admins and monitor users to update flag to Yes. Then, click the Update button in this page to register the changes.
Note:
Like email activity, the eG manager can also be optionally configured to maintain logs of the alarms generated by it. In some environments, this could serve as a tool for effective ‘postmortem’ analysis of problem situations - i.e., administrators can use the logs to be informed of problems that might have occurred during a period of their non-availability. Auditing of alarms reveal when an alarm was generated, the nature of the problem reported by the alarm, what were the problems clubbed together, and which problem is the source of a set of related problems. In some other environments, alarm logging could be a ‘must have’; such environments may host applications that read the alarm information stored in the logs for converting them into email/SMS alerts.
To enable alarm logging, do the following:
Edit the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory. In the [MISC_ARGS] section of the file, set the NEED_ALARMLOG parameter to true, to enable alarm logging. To indicate what type of alarm information needs to be stored in the logs, use the ALARMLOG_FORMAT parameter. By default, the alarm priority, the problem layer, the alarm ID, the problem description, the problem component name, the component type, and the last measurement time are logged in the log file. Accordingly, the default ALARM_LOG format is: PRIORITY:LAYER:PROBLEM_DESC:ALARM_ID:COMP_NAME:COMP_TYPE:MSMT_TIME Indicate the separator that separates alarm details against the ALARMLOG_SEPRT parameter. Specify how frequently (in milliseconds) the alarm log configurations need to be refreshed against the ALARM_LOG_REFRESH_INTERVAL parameter. If this parameter is set to 0 or is left blank, then, by default, the alarm log configurations will be refreshed every 30 minutes - i.e., 1800000 milliseconds. To ensure that a single log file is not overloaded with problem details or does not grow enormously in size, you can trigger the creation of additional log files as soon as the size of a log file exceeds a pre-configured limit. This ceiling can be set using the ALARM_LOG_MAX_SIZE parameter. Besides, to ensure that a single log file is not overloaded with problem details or does not grow enormously in size, you can trigger the creation of additional log files as soon as the size of a log file exceeds a pre-configured limit. This ceiling can be set using the ALARM_LOG_MAX_SIZE parameter. Once this limit is reached, the eG manager creates a new log file, copies the old data to it, and starts logging the latest information to the older log file. In environments where too many alarms are generated, this can result in a large number of log files, which might in turn consume too much space on the eG manager host. In such a case, you can conserve space on the eG manager host by specifying the maximum number of log files that can be created using the ALARM_LOG_MAX_FILES configuration. If such a limit is configured, then the eG manager will continue creating new log files only till such time that the said file limit is reached. Beyond this point, no additional log files will be created; instead, the eG manager will overwrite the currently open log file with the newer problem information. Finally, save the eg_services.ini file to register the changes.
Besides intimating users of problems with components and their subsequent return to normalcy, eG Enterprise can also be configured to send out emails / SMS when the state of a component becomes UNKNOWN. To configure unknown state mails/SMS, do the following:
Edit the eg_services.ini file in the <EG_INSTALL_DIR>\manager\config directory to set the values of the parameters in the [UNKNOWN_STATUS_REPORTING] section, as shown below:
UnknownStateMail=No
UnknownStateSMS=No
UnknownStateInfoMail=
UnknownStateInfoSMS=
UnknownStateMailList=
UnknownStateSMSList=
DefaultUnknownStatePeriod=
To get unknown state mails, set the UnknownStateMail parameter to Yes, whereas, the default is No. Similarly, specify Yes against UnknownStateSMS parameter to be able to receive SMS alerts when the state of a component changes to UNKNOWN. To configure unknown state mail alerts even if the state of a test descriptor changes to UNKNOWN, set the UnknownStateInfoMail parameter to Yes. To receive SMS alerts to that effect, set UnknownStateInfoSMS to Yes. Specify the users who should receive the email/SMS alerts by providing a comma-separated list of mail ids and mobile numbers (as the case may be) against the UnknownStateMailList and UnknownStateSMSList parameters, respectively. The email/SMS will be sent to the configured users only when a component remains in the UNKNOWN state for the duration specified in the DefaultUnknownStatePeriod parameter. This duration can also be set specific to a test, by inserting the test name as a parameter in the [UNKNOWN_STATUS_REPORTING] section and providing a value against it, as shown below:
OraTableSpacesTest=60
The DefaultUnknownStatePeriod will automatically apply to all those tests which do not have a specific unknown state period or which have been misspelt in the [UNKNOWN_STATUS_REPORTING] section.
|