Configuring Email Alerts in Data Services Manager version 9.1

I was recently asked to assist with some troubleshooting of the Email Alerting mechanism in Data Services Manager (DSM). The first thing to note is that there are different types of alerts that can be raised and emailed in DSM. The first type are Global Alerts, and these are emailed to the DSM Admin. The second type are Database Alerts, and these are emailed to all of the DSM Users (permissions) who are part of the DSM Namespace where the database is provisioned. Those of you familiar with Data Services Manager will know DSM Users are granted permission to provision a database by associating the data service in question with a Namespace through a Data Service Policy. The net result is that all DSM Users in that Namespace get a notification if there is an alert raised on the database.

Before looking at the email alerts, it is vitally important to ensure that your SMTP configuration is working correctly. When configuring SMTP in Data Services Manager, an attempt is made to send a test email to the DSM Admin account that is currently logged in to DSM and performing the SMTP configuration. If that DSM login is an LDAP/AD user, DSM attempts to fetch the email address from that LDAP/AD user object using attributes such as mail or rfc822mailbox.If that email address is not configured, the DSM Admin will not receive the test email, and won’t receive future Global Alert emails either. So ensure this is working first. If you have configured it correctly, as in the example shown here:

You should receive a notification similar to the following:

Let’s look at some of those alerts, and their corresponding emails now.

Global Alerts

The full list of Global Alerts can be found in the official Data Services Manager documentation. One Global Alert is root password expiry on the DSM appliance. I reproduced that issue to generate the alert and resulting email to the DSM Admin. In fact any user with the role DSM Admin will get the global alert email.

Here is the alert:

And here is the resulting email sent to the DSM Admin(s):

Let’s now look at the Database Alerts.

Database Alerts

As mentioned, Database Alerts go to all DSM Users who have permissions in the namespace where the database is created. One caveat is that the Database Alerts are not going to DSM Admins. This is a caveat that we will address in a future release. It is currently listed as a known issue in the Release Notes.

With that in mind, let’s look at a typical Database Alert. In this example, I remove access to the backup endpoint (S3 bucket) which meant that the Write Ahead Log (WAL) files for the Postgres database in question could not be written. This causes a Database Alert, Wal file health, as shown here:

And this is the email sent to the DSM Users with Permissions in that Namespace:

Additional Alert Email Recipients

There may be other users who are not part of the DSM Users who might need to receive Database Alerts as well. This can be done manually in the DSM UI by navigating to the database in question, selecting the Monitor tab, selecting Notifications and then Editing the Alert Email Notification section and adding a comma-separated list of email addresses. The email that is sent to DSM Users when an database alert occurs, as shown above, will also be sent to these users. Here is an example of where to add the additional emails:

In the Notifications section shown above, you will see the Auto Subscribed Namespace reference. This is how DSM Users which have their permissions associated with a namespace are discovered, and so have the Database Alerts sent to their respective emails. But for VCF Automation, those Supervisor namespace where the databases are provisioned do not have any DSM Users associated. Thus, Database Alerts from databases provisioned in VCF Automation are not sent to any users automatically, not even the VCFA organization users who have been assigned to the Project where the namespaces are created. Thus, to have users receive VCFA provisioned database alerts via email notifications, add those users to the Additional Alert Email Recipients section shown above. Unfortunately, there is no public API to automate this task at the time of writing, so the process is manual for now. The DSM team are working to address both of these limitations.

Summary

I hope this has gone some way towards explaining the different alert types, and how they are sent to email addresses of the different personas within DSM. The important part in all of this is ensuring that the DSM Admins and DSM Users have their emails configured correctly, especially if the users are LDAP or Active Directory users – make sure that the test email is working before looking for any other emails! And if you are a VCF Automation user, database alerts email notifications can be configured via the DSM UI, adding the recipients email address to the appropriate databases.