(upbeat music)
- Hi, everyone.
I'm Aditya Balaji, and I'm a product manager
in the Azure BCDR team.
In this video, I'll show you
some of the new monitoring functionality available
for your backups in Azure.
So firstly, why is observability important?
Well, many organizations
are going through a rapid digital transformation
and are seeing a sharp growth in their IT footprint,
which includes their cloud assets as well.
And as these organizations scale,
there are many more stakeholders involved
in developing, maintaining,
and supporting various business-critical applications.
Within such a landscape,
it becomes crucial for them
to have robust and scalable processes
to monitor for issues in every part of their IT estate
and take timely corrective action
to minimize the impact due to failures and outages.
And given that BCDR is the last line of defense
for most organizations,
having robust monitoring systems for BCDR
becomes all the more important.
Today, Azure Backup,
which is a secure and native backup solution in Azure
provides a range of monitoring capabilities
to cater to different requirements.
What you see on this slide is a typical journey
of an organization adopting backup.
They first need to assess their estate
to determine which items need to be protected
then learn about the solutions available.
Once they choose to adopt a solution,
they'll need to create a plan based on their recoverability
and long term retention requirements
and then go ahead and configure backup
as per the defined plan.
The responsibility doesn't end with setting up backup.
They need to set up systems
to ensure that any issues in their backups
are serviced to the required stakeholders in a timely manner
so that immediate corrective action can be taken.
For example, some resource might have a configuration issue
that is leading to failed backups
affecting the recovery point objective for that resource.
In other cases, it's possible that someone
has accidentally turned off backup for a resource,
which could be a compliance violation.
Being able to tackle such issues
is what falls under the monitor compliance
and operate steps of this journey.
And finally, there is also the report and audit part
where users need to be able
to generate audit evidence reports on a periodic basis
that backups have been taken reliably
since backup is an important part
of most compliance standards.
In the rest of this video,
we'll focus on the monitoring part of this journey.
So this is a quick rundown of the different solutions
that Azure Backup offers for monitoring today.
And these are covered in detail in the public documentation.
We have Backup Center,
which provides a single pane of glass
for monitoring protected and unprotected resources
along with the recent backup jobs.
There are a few built-in metrics
which Azure Backup supports via Azure Monitor,
which helps users get an idea of the overall backup help.
We also integrate with Azure monitoring alerting platform
for servicing default alerts,
which is what will be the focus of this session.
We have integration with Azure Monitor logs
for historical analysis.
And finally, organizations can also audit
various user-triggered operations on vaults
using standard activity logs.
Let's double-click into row three now, which is alerting.
Let's look at some of the common scenarios
for which BCDR operators require to be alerted on.
They require security alerts,
for example, if someone accidentally
or maliciously deletes backup data
or turns off some security setting.
They require alerts whenever there is an issue
in the backup or DR Health, for example,
an alert for every backup failure or more generically
whenever the recoverability goals are not met
in a certain period.
Some organizations also require informational alerts
when all the backups for the day were successful.
And similarly, there are other scenarios
around not being able to get alerted if backups don't start
on schedule and other such scenarios.
Now, let's look at what customers want to do
with these alerts.
Some of the most requested alert management capabilities
have been being able to configure alerts at scale,
monitoring alerts across subscriptions and workloads,
and being able to filter and scope down as needed,
routing alerts to various notification channels of choice
be it things like email, ITSM, Webhooks, Slack, and so on.
They also want to be able to get more details
about a particular alert
to be able to diagnose and troubleshoot better.
There is also the aspect of long term retention of alerts
for audit purposes.
They want flexibility
to want to choose which scenarios
to get alerted or notified for.
And finally,
for scenarios where there is a maintenance window
where they know backups are going to fail,
they want to also be able to have the option
to suppress notifications during a certain period of time
so that the noise can be reduced.
So before we had Azure Monitor-based alerts,
Azure Backup provided an alerting solution
which is now referred to as classic alerts.
Customers could view alerts for some default scenarios
like backup failures
and it allowed our customers
to configure email notifications for these alerts.
And while this solution worked well
for the scenarios it was built for,
there were difficulties in catering
to customers end-to-end alerting requirements.
As you can see on this slide,
there were challenges
around needing to use different workarounds
for routing these alerts to other notification channels,
not enough flexibility in choosing who gets which alert,
and for customers using Azure Monitor
for other Azure services,
they now needed to learn a separate paradigm
just for monitoring backup and DR alerts
For these reasons and more,
Azure Backup has been on a journey
to integrate natively with Azure Monitor
to meet organizations' alert management requirements
and provide more standardized alerting experiences.
There are many different ways
in which Azure Backup integrates with Azure Monitor
for alerting today
as each channel caters better
to specific categories of requirements.
We have something called Built-in Azure Monitor alerts
wherein our service, which is Azure Backup,
generates alerts by default
for certain critical scenarios
that all customers need to be alerted to
irrespective of whether they have configured alerts or not.
Security alerts fall under this category.
We also have something called metric alerts
wherein Azure backup surfaces a few metrics
out of the box to customers.
Each metric is indicative
of a certain aspect of BCDR health,
such as success of backup jobs, success of restore jobs,
and so on.
Users can choose to write alerts
on whichever metrics and thresholds they're interested in.
And then for scenarios which are very specific
to a certain user's requirement
and not available out of the box via the other two channels,
users can always send all diagnostic data
for their recovery services vault to Azure Monitor logs
and write custom alert rule queries on these logs
based on their requirements.
Irrespective of the source of an alert,
organizations should still be able
to have a consistent alert management experience
across these different alerts
whenever they visit the Azure Monitor Dashboard
or Backup Center.
They should also be able to route these alerts
to any notification channel of their choice
by creating an alert processing rule.
So let's dive into the demo now.
So now that backup alerts are surfaced by Azure Monitor,
I can go to the Azure Monitor portal
and see all of the backup alerts as well.
So what I can do here is I can filter
for Monitor service Azure Backup
to see all the built-in Azure Monitor alerts
that have been fired by the Azure Backup service.
I can click on any alert, view more details about the alert,
such as the affected resource,
the category of the alert,
the description, the recommended action,
and things like that.
I can also change the state to acknowledged or closed
based on the scenario,
and I can also check the history of the alert.
So, for example,
if this alert triggered a notification channel,
I can see whether the notification was triggered
and things like that.
So this is the experience of viewing the alert
from the Azure Monitor dashboard.
What is possible in addition to this
is that if a user comes via Backup Center,
they will be able to see the Azure Monitor alerts
via Backup Center as well.
And the benefit of of having these alerts
in Backup Center as well
is that it allows users
to have more filtering capabilities
beyond the standard filters available
for all Azure resources.
So what happens is that when I come to Backup Center,
I can see an a tile in the overview,
which shows the list of active Azure Monitor alerts.
It could either be the built-in alerts
or any custom alerts that users might have written
on that metrics.
So we see two categories of alerts here.
One is the datasource alerts and one is the global alerts.
Datasource alerts are alerts
where there is an association to a particular data source.
So, for example, if backup has failed for a VM
or if backup data has been deleted
for a particular database,
those things come under datasource alerts.
But there are also global alerts
which don't have an association to a particular data source,
for example, if someone disables soft delete feature
for the entire world.
And so each of these
have different sets of filtering capabilities and properties
and hence show up differently over here.
I can click on any of these numbers
to view more details about each of these alerts.
And what you can see here is that,
in addition to the standard filters
like Subscription and Resource Group,
which were there in the Azure Monitor dashboard,
if I'm a backup user
who's managing a subset of workload backup,
I can also filter for more advanced properties
like the type of the data source being backed up,
the category of alert,
whether it's a security alert or a job failure alert
and things like that.
And I can go as far as the last 30 days.
And then, similarly, clicking on the alert
leads me to more detailed information about the alert,
and here I can take the required action.
So this was the experience from the Azure portal.
But in most cases,
large organizations who are backing up
and monitoring a large estate
may not want to come to the portal every single day
to view their alerts.
They might already have established processes
in terms of ticketing systems or a distribution list
to be able to route these alerts
to the notification channel
that is being used by their organization all up.
So what you can do to create notifications
for these alerts to a channel of choice
is create an alert processing rule.
So in very simple terms,
an alert processing rule helps users define
which alerts should be sent to which notification channel.
So I click on Alert processing rule
and go ahead and create the rule.
So a rule can apply for multiple resources
within a subscription.
For the purposes of this demo,
I'll do it for a single recovery services vault
within that subscription.
So if I search for my required role,
I enter that as the scope,
and I can also provide additional filters if needed.
For example, if there are certain error codes
for which I don't want to receive alerts,
I can do all of that filtering over here.
Next is the rule settings.
And here, since I want to send it to a notification channel,
I will apply an action group.
And let's say the organization here
has a system where there are two applications,
Contoso WebApp1 and Contoso WebApp2,
each of them having infrastructure and database components
and are being monitored by different sets of users.
And depending on which part of the application
that has been a failure or an incident,
they want the right Teams channel to be notified.
So what I have here
is I've defined a logic app,
which basically is meant to take information on each alert,
look at the properties of the alert
to see which part of which application has been affected,
and then based on that, based on the properties,
it decides which Teams channel to route it to.
So for example, if there has been an issue
in the VM part of Contoso WebApp1,
it'll be sent to a particular Teams channel
for the WebApp1.
Similarly, if there has been an issue
in a VM in Contoso WebApp2,
it'll be sent to the Infra channel
under Contoso WebApp2 Teams channel.
And so this is a logic app that has been defined already
in the interest of time.
And what I'll do here
is that I will hook this alert processing rule
to this logic app so that whenever an alert is fired,
it gets sent to this logic app,
and the Logic app can do the required pre-processing
so that the alert is routed to the right channel.
And this is another benefit of having these alerts serviced
by Azure Monitor now,
because it enables you to use standard components
like logic apps and action groups
and things like that to be able to do more with your alerts.
So I'll select an action group
which has, again, being pre-created.
So this action group is the one attached
to the logic app that I just showed, and I'll add this here.
We want this to be run Always,
so I'll go with the default settings.
And this is where I basically select
where this rule should be created,
because the alert processing rule is also an Azure resource.
And I will need to add a few tags,
because there is an internal subscription policy here
which requires tags to be created.
And once I go ahead and create it,
notifications are enabled
for this recovery services vault to the logic app
which in turn sends the alert to a Team's channel.
So what I'll do now is I will go ahead
and simulate a security alert for one of the WebApps.
So what I'll do is I'll go to this particular vault
and I'll search for ContosoWebAppVM1
and tell it backup data just to simulate the security alert.
So I click on Stop backup,
and I select Delete backup data.
So once the backup data is deleted,
you should be able to see an alert over here.
And since you also now have the alert processing rule,
what you should see is a notification coming
to the required channel.
So since we had deleted backup
for the VM under this WebApp,
the notification showed up under this channel
with all the required properties
like now the affected resource,
the recommended action,
the severity, and things like that.
So this was a quick demonstration
of how you can use Azure Monitor based alerts
to route these to different notification channels of choice.
It's not limited to email and Teams
but also any other ticketing systems,
be it ServiceNow, ICM and things like that
are all very integratable with these alerts now
that they are serviced with Azure Monitor.
So now, the last part which is worth talking about
is that what if I was a user
who was using classic alerts up until now
and let's say my team primarily focuses on backup
and I haven't used alerting
for too many other Azure services.
I want to be able to have a seamless experience
even when I do make the move to Azure Monitor.
For that, what Azure Backup also provides now
is a more easy way for customers
to migrate to Azure Monitor based alerts
from classic alerts with just a few clicks.
So what users can see
is that when you go to Backup Center,
you'll see a message here
which shows the number of vaults
which are still using classic alerts
and now a recommendation
to start using Azure Monitor alerts
to leverage its various benefits.
And clicking here,
I can actually see two distinct actions.
The first one is
to basically create an alert processing rule,
which we just saw.
And what users can do using this experience
is instead of having to go manually
to the alert processing rule creation page
and enter all of those details from scratch,
what they can do here
is that they will find a template-based experience
to create the alert processing rule
for all vaults within the subscription.
So the only things they will need to enter
is the subscription resource group region
in which the alert processing rule should be created
and the email ID to which they want notifications
to be sent to.
And once they enter this,
they can go ahead and actually create this.
And what happens is that every vault
within the particular subscription
that they have selected
now gets configured for notifications
to the email address of their choice.
And once they do this,
all the prerequisites
for them to start using Azure Monitor based alerts
and get a similar experience
as what they were having using classic alerts,
all of those prerequisites are completed now.
In addition, the one other thing which we recommend
is that they can also opt out.
Once they have migrated to Azure Monitor alerts,
they can also opt out of classic alerts
so that they don't get duplicate alerts
from two different solutions.
So what they can do here
is they can click on the second action,
which is the Manage alerts,
and here they will see a list of all vaults
which are still using classic alerts.
So they can choose to select multiple vaults within a page,
update the monitoring settings by going here,
And when they select Use only Azure Monitor alerts,
essentially they're consenting to receive backup alerts
only via the new Azure Monitor solution
so that they don't receive duplicate alerts
from the classic alert solution.
So in this way, users who have been using classic alerts
and want to quickly make the switch to Azure Monitor alerts
without needing to learn too many concepts
can make use of this template-based experience
to achieve the same.
(gentle music)
So this concludes the demo
of built-in Azure Monitor alerts for Azure Backup.
Thank you all for listening,
and if you have any questions,
please feel free to write
to AskAzureBackupTeam@microsoft.com.
Thank you.