Configuring Mail Alert Settings

To access this page, click on the icon available in the Admin tab. Then, select the Alert Settings option from the Mail Settings sub-menu in the Alerts tile. Then click on the Mail/SMS Alert Preferences sub-node from the Settings node in the Mail Alert Settings tree that appears in the left panel.

1. The mail alert settings that are to be included in the MAIL/SMS ALERT CONFIGURATION section in the right panel of this page is as follows:

   • Home page URL in mail messages: If a user has been configured to receive email alerts in the HTML MESSAGE MODE, then alarms sent by mail to that user will carry a hyperlink named Home at the right top corner. The destination of the hyperlink can be configured in this text box. By default, clicking on the Home link will connect you to the eG manager and open the login screen. By providing a specific URL here, you can ensure that monitor users are lead to the specified URL upon clicking the Home hyperlink.

   • Maximum time between email alert checks (secs): By default, the eG Enterprise sends email alerts every 3 minutes (i.e., 180 seconds). In some environments, one/more tests could be run very frequently, say every 1 minute or 30 seconds. If these tests report abnormalities, then the user will receive an email alert of the issue only at the 3rd minute. What's worse, if the issue detected by the test is resolved by the time the email alert is sent out by the eG manager, then the user might not even know that a problem had occurred - critical problems could thus go unnoticed! To avoid this, you can reduce the frequency at which the eG manager sends out email alerts. For this, you need to override the default values (of 180 seconds) displayed against the Maximum time between email alert checks text box.

   • Allow monitor users to edit their mail IDs: By default, this flag is set to Yes which indicates that a user possessing Monitor user role will be allowed to edit his/her mail id from the USER PROFILE page. If you do not want that particular user to edit his/her mail id, then set this flag to No.

   • Alert if an agent is not running: If you wish to receive alerts when an agent has stopped running, then set this flag to Yes. By default, this flag is set to No.

   • Show last measure value in mail alerts: By default, the last measurement value of a measure will not be included when email alerts are sent to the administrator. If you wish to be alerted of the actual measurement value that was received in the last measurement period in the email alerts, set this flag to Yes. If this flag is set to Yes, you will not be allowed to uncheck the Test and Descriptor check boxes against the Mail preferences field of the MAIL/SMS ALERT PREFERENCES section.

   • Show last measure value in SMS alerts: By default, the last measurement value of a measure will not be included when SMS alerts are sent to the administrator. If you wish to be alerted of the actual measurement value that was received in the last measurement period in the SMS alerts, set this flag to Yes. If this flag is set to Yes, you will not be allowed to uncheck the Test and Descriptor check boxes against the SMS preferences field of the MAIL/SMS ALERT PREFERENCES section.

   • Stop escalation for acknowledged alerts: An acknowledgement is an indication that the corresponding alert is being investigated; the purpose of alarm escalation is also similar - i.e., to have someone look into/investigate an alert that has been pending for a long time. Escalating an acknowledged alert would not only be redundant, but will also result in an enterprise unnecessarily throwing more administrative resources on problems that are already being attended to. This is why, by default, eG Enterprise does not escalate acknowledged alerts. Accordingly, this flag is set to Yes by default. In some environments however, managers may want to be alerted if a user who volunteered to resolve a problem (by acknowledging it) is unable to solve it within a stipulated time. In such environments, it may be useful to escalate acknowledged alerts. For this, you may want to set this flag to No.

   Note:

   If administrators choose to escalate acknowledged alarms, they can additionally configure the eG manager to send the acknowledgment description as part of the email/escalation alert. This way, help desk managers can understand that the problem is being looked into, know who is looking into it, and demand status updates from that specific executive. If you wish to include the acknowledgment description in the email and escalation alarm mails, then set the AckDetailsWithEmailAlerts flag in the [MISC_ARGS] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory) to Yes. By default, turning this flag on will ensure that the descriptions related to the Top 3 acknowledgments based on the acknowledgement time are included in the email/escalation mails. This default number can however be overridden. For this, set the value of your choice against the NoOfAcknowledgementsInMail flag in the [MISC_ARGS] section of the eg_services.ini file. If both the Stop escalation for acknowledged alerts and AckDetailsWithEmailAlerts flags are set to Yes, then the Stop escalation for acknowledged alerts flag setting takes precedence and the alarm escalation stops for an acknowledged alarm.

2. The administrator can customize the subject of the alarm mails by specifying an appropriate subject in the MAIL/SMS ALERT PREFERENCES section in the right panel of this page.

   • In this section, the administrator will first have to indicate whether he/she needs to provide a simple, brief subject, or a more descriptive subject. To provide a short and crisp subject, select the Concise option against Mail subject format. In which case, the administrator has to specify the mail subject in the Mail subject text box.

     By default, the Concise mail subject will include the alarm priority - accordingly, the Priority check box will be selected by default in the Contents of mail subject section. If you want to exclude the priority from the mail subject, simply deselect the Priority check box.

   • To provide an elaborate subject, which should include the names and/or types of components to which the alarms pertain, select the Descriptive option. In this case, administrators will be allowed to “build” the entire mail subject, by first specifying how the subject should begin in the Start of mail subject text box. Then, he/she should choose the Contents of mail subject by selecting the desired check boxes. A typical mail subject can include one/more of the following:

     • Name: The name of the problem component
     • Component Type: The name of the problem component-type
     • Layer: The name of the problem layer
     • Test: The test that reported the problem measure(s)
     • Description: The problem descriptor (if any), and a brief description of the problem
     • Priority: The problem severity (Critical/Major/Minor)
     • Last measure value: The last value reported by the problem measure; this check box will appear only if the Show last measure value in alerts option in the MAIL ALERT CONFIGURATION section is set to Yes.

     For instance, assume that all the check boxes in the Contents of mail subject section are selected. Now, say that the DiskSpace test mapped to the Operating System layer of a component named Event50 has detected a Critical space crunch in the C drive of that component. The corresponding email alert will therefore carry the following subject:

     Critical,Event50,Host system,Operating System,DiskSpace,Capacity is low{C},98

     From the above example, it is clear that a typical email alert will be of the following format:

     <Severity>, <Component Name>, <Component Type>, <Layer>, <Test>, Alarm description {Descriptor}, Last measure value

   • The maximum number of problem components to feature in the mail subject should also be indicated in the Maximum components in mail subject text box.

     Note:

     The Descriptive mail subject discussed above will take effect only if the following conditions are fulfilled:

     • The user profile must be configured to receive email alerts for New alarms.
     • The Send separate mails for each alert flag should be set to Yes.

     In this case, note that the Maximum components in mail subject setting becomes irrelevant. On the other hand, if the mail subject is set to Descriptive, the user profile is configured to receive alerts for the Complete list of alarms, and the Send separate mails for each alert flag is set to No, then the subject of the resulting email alert will indicate only the <ComponentName> <ComponentType>. In this case however, the Maximum components in mail subject setting gains significance.

     Similarly, if the mail subject is set to Descriptive, the user profile is configured to receive alerts for the New list of alarms, and the Send separate mails for each alert flag is set to No, the resulting email alert will not display the variables chosen from the Contents of mail subject section; instead, a mail subject of the format, <ComponentName> <ComponentType>, will accompany each mail alert generated. Here again, the Maximum components in mail subject setting gains significance.

   • Besides the mail subject, the contents of an email alert can also be customized by selecting the relevant check boxes from the Mail preferences field. The Last measure value check box will appear in this section only if the Show last measure value in alerts flag in the MAIL ALERT CONFIGURATION section is set to Yes.

     Note:

     If you select the Description check box in the Mail preferences field, the Test and Last measure value (if available) check boxes will get selected automatically. Similarly, deselecting any one of the Description, Test, or Measure check boxes will automatically disable the other two options. This indicates that if an alarm description is contained in an email alert, the details of the problem test, and the last measure value (if the Last measure value check box appears in the Mail preferences field) will appear.

   • If multiple alarms are generated simultaneously, then the eG Enterprise, by default, sends a single email alert comprising of all the alarm information. Accordingly, the Send separate mails for each alert flag is set to No by default. To ensure that a separate email is sent for every alarm, select the Yes option.

     Note:

     The “separate email/SMS alert” flag setting will take effect only if a user is configured to receive email/SMS alerts for the New alarms. For users who are configured to receive the Complete List of alarms, details of multiple alarms will continue to be clubbed in a single email/SMS regardless of the flag setting.

     Note:

     • If the eG agent detects an issue in a test Descriptor, then the email alert will also include the descriptor name. If another descriptor of the same test suffers a performance setback later, then users who are configured to receive only New alarms, will receive a single email containing the information pertaining to both the alarms. Moreover, the start Date and time for both the problems, as indicated by the alert, will be that of the first alarm.
     • Similarly, when the alarm priority changes - say, from Critical to Major - the email alert for the Major alarm will carry the Date and time of the original Critical alarm.

   • In some environments, the mail servers used for processing email alerts might not be adequately configured to support certain data types/fonts used in the email content. In such cases, alarm information included in the body of the mail could appear distorted / misaligned. To avoid this, the eG manager can be configured to send alerts as attachments, so that users can open the alarm information and view it using any program that they choose.

     To achieve this, set the Send alert as attachment flag to Yes. By default, this flag is set to No. Note that both HTML and text alerts can be sent as attachments.

   • The eG Enterprise can also be configured to send email alerts/SMS when a problem gets fixed. This can be done by setting the Send mails/SMS when alarms are cleared flag to Yes.

   • Besides the above-mentioned information, the email alerts sent by the eG Enterprise can also be configured to include the detailed diagnosis of the problem measures. For instance, an email alert indicating excessive CPU utilization on a host can also be configured to list the top 10 CPU-consuming processes on that host. This way, administrators can easily perform further diagnosis without having to login to the monitor interface; the required information will be available in the email itself.

     To ensure that the detailed diagnosis information accompanies the alarm details, set the Include detailed diagnosis(DD) in mail alerts flag to Yes.

     Note:

     Once this flag is switched on, then users who are configured to receive the New list of alarms will begin receiving email alerts with DD. However, in the case of users who have been configured to receive the Complete list of alarms, the eG manager will only send email alerts without DD.

   • You can also make sure that configuration changes are also intimated to administrators via email alerts. For this, set the Include configuration changes in mail alerts flag to Yes.

   • Similarly, for alarm information transmitted via SMS, an administrator can provide a subject of his/her choice in the SMS subject text box. By default, the contents of the SMS will include the alarm priority. The user can customize the other details to be displayed in the mobile phone's console by selecting the relevant check boxes in the SMS preferences field. By default, the Component Name, Component Type, Description, Services, Test, and Measure are selected. If the Measurement Host should also be displayed, then the administrator must select the Measurement Host check box.

   • If multiple alarms are generated simultaneously, then the eG Enterprise, by default, sends separate SMS alerts for every alarm. Accordingly, the Send separate SMS for each alert flag is set to Yes by default. To ensure that a single SMS alert comprises of information pertaining to all the simultaneous alarms, set this flag to No.

     Note:

     The “separate email/SMS alert” flag setting will take effect only if a user is configured to receive email/SMS alerts for the New alarms. For users who are configured to receive the Complete List of alarms, details of multiple alarms will continue to be clubbed in a single email/SMS regardless of the flag setting.

     Note:

     • The SMS subject and SMS settings fields will appear only if the eG license enables the SMS alerting capability. If the LICENSE INFORMATION screen displays a No against SMS Alerts, then the SMS subject and settings cannot be configured.
     • To stop receiving email alerts, the administrator can remove the eG Administrator mail ID from the MAIL SERVER SETTINGS page. For that, he/she would have to remove the SMTP mail host first, and then the eG Administrator mail ID, and finally, click the Update button.

3. You can also configure eG Enterprise to communicate alerts via WhatsApp. For that, do the following:

• In the WHATSAPP ALERT CONFIGURATION section in the right panel, move the Enable whatsapp alerts slider to the right to enable whatsapp alerting.
• Next, choose a Gateway. eG Enterprise is capable of using one of the following gateway APIs to send out WhatsApp alerts:
• Chat API: Chat API is designed to create chat bots and integrate WhatsApp with business systems
• WhatsMate: WhatsMate provides API service for WhatsApp messaging.
• If Chat API is chosen as the Gateway, then do the following before you proceed with the configuration:
• Make sure you create a sender account for eG Enterprise in Chat API using WhatsApp Web.
• Once eG Enterprise is registered as a sender, an authorization token will be granted to it. Make a note of this authorization token.
• Once the aforesaid pre-requisites are fulfilled, proceed with the configuration as depicted above. This requires you to provide the following information:
• Against Gateway URL, specify the Chat API URL to which eG Enterprise should connect, in order to send eG alerts.
• Specify the authorization Token that you were provided at the time of registering eG Enterprise with Chat API.
• On the other hand, if you want to use WhatsMate for generating WhatsApp alerts, select WhatsMate as the Gateway. Before proceeding any further, make sure you do the following:
• Subscribe to a WhatsMate Premium plan.
• Upon successfully subscribing to that plan, you will receive an email from WhatsMate containing a personalized Client ID and Client Secret. Make a note of these.
• Next specify the following:
• Gateway URL: Specify the URL to the WhatsMate REST API to which eG alerts are to be sent.
• Client ID and Client Secret: Specify the Client ID and Client Secret that would have been sent to you by email after you subscribe to the Premium plan.
• Instance ID: Specify your gateway's instance ID. This ID will be given to you once you subscribe to WhatsMate.

After configuring all the sections, click the Update button in this page to register the changes.

Customizations:

1. 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.
   • Also, 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.
   • 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.

2. Besides intimating users of problems with components and their subsequent return to normalcy, the 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, set the UnknownStateMail parameter in the [UNKNOWN_STATUS_REPORTING] of the eg_services.ini file (in the {EG_INSTALL_DIR}\manager\config directory) to Yes. The default is No. Similarly, specify Yes against the UnknownStateSMS parameter to be able to receive SMS alerts when the state of a component changes to Unknown. The eG system can also be configured to send out unknown state alerts even if the state of a test descriptor changes to Unknown, by setting the UnknownStateInfoMail parameter to Yes. To receive SMS alerts to that effect, set UnknownStateInfoSMS to Yes. You can even 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 eG system will email/SMS 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. Once the changes are done, save the eg_services.ini file.