ViPR SRM alert parameters missing in email notification

I have the same problem with my 3.7 environment. We recently upgraded to 3.7 after originally deploying 3.6 and we never had the time to fully configure alerting. Now I'm circling back and trying to get that up and running properly and I haven't yet been able to get one alert to populate the data properly from the default e-mail template. I really just noticed how bad it was yesterday and haven't yet opened a case with Support but I plan to today. I'll keep you posted if I find anything out.

Hello,

Emails should be configured through alert consolidation adapter - Email notification. If there is any email component in the default alert component like -> EMC VMAX, VNX etc, few alert properties might not appear properly in email/snmp traps etc.

The best way is to leave the default alert templates as it is, just edit the SNMP address to Primary backend or localhost(default), so that all the templates will forward the alerts and send it to SRM PBE. Those alerts will be formatted correctly and displayed on SRM UI (All Alerts). Through alert consolidation adapter all these alerts can be emailed or sent to SNMP receiver.

If you want to check the properties you can query the events table directly :

1. Login to Primary Backend

2. /opt/APG/bin

   ./mysql-client.sh

   username = root

   database = events

   password = watch4net

3. Based on the email that is posted above, you can use this query : select device,source,severity,sourceip from genericevents_live where device='VNX_1683_RHL';

If this table has data then it should appear in the email/snmp traps. If you are facing any issue you can contact support or post your query here.. I would be happy to help you.

Regards

Gnanendra

Hey Allen,

Please query the events table as stated above. The email which you receive from SRM will pull the properties from genericevents_live table.

I think you added email field directly to default alert templates. For few alerts properties like severity, category etc are not applicable. The best way is to just enable email option for Alert Consolidation Adapter and remove the email option that is added manually for default alert templates.

In future versions there are many enhancements to alerting.

Regards

Gnanendra

Hi Gnan,

Thanks for getting back. I am no expert in linux. Could you assist me what commnad i have to execute after entering the mysql db

thanks

This is the mysql query that Gnan has suggested to run:

mysql> select device,source,severity,sourceip from genericevents_live where device='VNX_1683_RHL';

Another way is try to add the following to alert email to see which and how much information you can get. You may bot get all of them as this looks like a full list to cover different categories:

id,Name,OpenedAt,count,eventstate,Source,parttype,part,eventname,parttypedisplayname,partdisplayname,eventdisplayname,fullmsg,devtype,device,sourceip,sourcedomainname,sourceeventtype,value,active,timestamp,ClosedAt,duration,lastchangedat,isroot,isproblem,acknowledged,eventtype,category,eventtext,severity,impact,certainty,inmaintenance,troubleticketid,owner,systemdefined1,systemdefined2,systemdefined3,systemdefined4,systemdefined5,userdefined1,userdefined2,userdefined3,userdefined4,userdefined5,userdefined6,userdefined7,userdefined8,userdefined9,userdefined10,userdefined11,userdefined12,userdefined13,userdefined14,userdefined15,userdefined16,userdefined17,userdefined18,userdefined19,userdefined20,enterprise,generic

you need to format the message body like this:

ID: PROP.'id'

Name: PROP.'Name'

Opened at: PROP.'OpenedAt'

Count: PROP.'count'

....

One thing that I have seen in our environment that is similar to this had to do with the order in which the variable names are specified in the actual alert definition that is triggering the mail consolidation adapter.  In the ViPR SRM webUI "All Alerts" page, do the appropriate columns get populated with information?  Or, do you see similarly see the columns in the Alert report showing variable names?  If this is the case, then what I have found is that the primary alert definition (the one that sends an SNMP trap to the Primary Backend on port 2041) has somehow gotten things out of order.  I think in our case it was old alert definitions from SRM 3.0 or something.  It took a little work, but I was able to rearrange the order of the variables in that alert definition to get things working properly.

Something to look at anyway.

REID