vONE alerts for M365 backup jobs

[sandsturm]

Hi

We use vONE to forward events from our environment to our internal event and alerting system (something similiar to ServiceNow). We forward events of our VBR environment since many years and every backupjob creates a unique event ID. We use this event ID as unique identifier when forwarding the events to our event and alerting system.
Events are forwarded via powershell script: every vONE alarm has configured "Run script" as Notification.

I configured this event forwarding as well for the alerts from the Veeam M365 backup environment and noticed that the alarms of different M365 backupjobs have the same Alarm- or Event-ID. Maybe there is a good reason for this behavior? But I would expect that alerts are handled in the same manner, doesn't matter if the alarms are thrown from a VBR server or a VBM365 server. But that is not the case currently.
If there is no good reason for this behavior, my question: Do you think, you can change this behavior to have a unique alarm-ID per backup job as well for the M365 backupjobs in a future release of vONE?

thx,
sandsturm

[jorgedlcruz]

Hello,
Let me double check this internally first, as I am not aware of this behavior, I would expect to work similarly to the VBR ones, as the alarm is based on the same (Job state). Will come back with some answers.

Thank you!

[jorgedlcruz]

Hello,
I have been digging internally, and I have a mix of news, let's start with how the alarms works:

• Every Alarm has an Alarm ID that is the same across types. For example Backup Jobs, no matter the job name, will always have the same ID as seeing here, look (I let the SQL query in case you want to take a look, be careful):
  
  For VB365 for example as well, you get the idea:
  
  But for every Job type, like Backup Copy, or Replication, etc. A different triggered Alarm Id will be across every job type. The IDs sometimes are different, different that mine, if you have a second VBR, then that Alarm Id for Backup Job for example is different and unique for that VBR, but the same across job types for that VBr if that makes sense.

That said, I started digging further, and I can say that in Veeam ONE v11a, a new parameter was introduced that complement the other 7:

• %1 – Alarm name
• %2 – Affected object name
• %3 – Alarm summary
• %4 – Time
• %5 – Alarm status
• %6 – Previous alarm status
• %7 – Alarm ID
• %8 – Source ID

There is some good information about it here:

• https://helpcenter.veeam.com/docs/one/m ... ml?ver=120

Let's say you want to improve the script you have, by adding the Source Job Name, which I guess it will reduce headhache, by adding that %8 t your script, you will be able to collect this:


And look, I added to my script and into the alarm the %8, which sends stuff to a Syslog using PowerShell (old as now we support it natively):


In the case that you have some of those different IDs for Jobs that are the same type, on same VBR, will be happy to see them.

Hope it helps.

[sandsturm]

Hello Jorge

Thanks a lot for your fantastic explanation! I wasn't aware of the additional parameter %8 till now, thanks for the hint. I modified my alerting script and it works now like a charm.
I noticed that not all "Backup" alarms do have such a subAlarm (%). This parameter is empty for the alarm "Unusual Job duration" for example but there were others as well. If I do not have unique IDs for an alarm, I'm not able to "map" the"resolved" alarm to the according alarm. Whenever an alarm is autoresolved (for any reason), our eventsystem gets the "resolved" message and clears the alarm there as well but this is only possible if all alarms are really unique. Do you think it's possible that all alarms will get a subAlarm in the future?

thanks a lot for your help and regards,
sandsturm

[jorgedlcruz]

Hello,
Yes, that is an interesting feedback, will take a look and discuss internally.

We do something like this for ServiceNow integration as you can see in the DB a bit. Meaning we trigger alarms as usual, but then the other ticket system gives us an unique alarm id, in this case snow alarm id, anf we map that to our alarm, so we can resolve it later, etc.

Will see if it is possible to display the unique alarm id, as another variable, maybe %9.

Thank you so much for the ideas.