Credits: This blog post has been reviewed by @Aditya_Balaji, @GargiBanerjee.
Hello everyone! This is Daya Patil here, continuing our series on business continuity with ABCC. In our previous session, we explored the concept of understanding the inventory of protected items in ABCC through Business Continuity with ABCC: Part 4: optimize security - Microsoft Community Hub. Today, we're going deeper into monitoring journey for John within ABCC.
Tailwind Traders case study
With all configurations and protections set up, John now must monitor the daily status to ensure the desired Recovery Point Objective (RPO) is consistently met. It's crucial for him to receive notifications promptly in case of any failures to achieve this objective, enabling him to take immediate remedial action. His next objectives are:
John remembers using several automation tools in his previous company to create customized views for monitoring tasks. However, this effort came with the challenge of maintaining and updating these views whenever there were changes to automation clients and BCDR (Business Continuity and Disaster Recovery) solutions.
Monitor jobs:
John navigates to Azure Business Continuity Center and notices there is a separate dedicated section with various views to help him with the monitoring. He clicks on the view for jobs. The Jobs view helps him monitor the progress of actions triggered across the solutions. ABCC allows to view jobs across Azure Backup and Azure Site Recovery, with ability to filter, view details of individual jobs and take appropriate action.
Within the jobs view, John can find the action details for each resource using the following information:
Customize the Jobs view
John observes a couple of additional options on the page that enable customization of the view like:
View Job details
John aims to delve deeper into the details of each job, particularly those that haven't completed successfully for specific resources. To do so, he clicks on the operation name or opts for the "More" icon and selects "View Details" from the action menu. This allows him to navigate and explore further details pertaining to a particular job.
In the job detail’s view, John gains access to additional information directly from the provider. This encompasses details like resource ID, activity ID, and sub-task specifics such as name, status, and duration for each.
The built-in help available from the menu within the view assists John in learning more about utilizing the view effectively.
Having access to a comprehensive array of customizable options, detailed insights into job statuses, and extensive provider-specific information within the job view, John experiences a sense of empowerment and satisfaction. Though feeling equipped and informed by the comprehensive visibility for effective task management and monitoring, John seeks to minimize his ABCC progress checks. His goal is to concentrate solely on critical event failures instead of constant monitoring. Additionally, he desires notifications for immediate attention needs, allowing him to stay informed without the need for continual monitoring.
Monitor alerts and configure notifications:
With his objective in mind, John navigates to the Alerts view. Here, he gains insights into alerts triggered for critical events in backup and disaster recovery operations. This view allows him to observe built-in alerts triggered by solutions like Azure Backup or Azure Site Recovery, along with alerts triggered by custom alert rules based on metrics and custom queries.
In the alerts view, John can access information about triggered alerts for resources through the following sections:
To explore the impacted or affected items related to a specific alert, you can choose "View affected resources" from the context menu.
The affected resources view provides comprehensive details for all those resources to which the fired alert applies, including subscription, resource group, location, start time, state, and more.
Customize the Alerts view
John observes similar options on the page that enable customization of the view like:
The "Full" view offers an extensive range of filtering options, whereas the "Basic" view presents a simpler set of filters. Presently, the "Full" view is available exclusively for specific types of data sources, while alerts for other data source types are supported in the "Basic" view.
Perform actions
John finds joy in discovering that all alert-related information is consolidated in one place, offering seamless options to switch between different functionalities. As he delves deeper, he uncovers a range of actions accessible within the view:
At the top of the view, the menu offers actions such as creating and managing alerts.
John, having grasped the functionalities of all actions, now aims to configure the necessary components to receive email notifications in case of critical event failures.
Configure notifications:
To direct alerts to notification channels, you'll need to establish an alert processing rule and an action group. The alert processing rule specifies which alerts should be routed to a specific notification channel, while the action group represents that channel.
All Azure Monitor-supported action groups, including email, webhooks, functions, logic apps, etc., are compatible with backup and disaster recovery alerts as well. Below are the steps outlining how to configure email notifications for your alerts.
John begins with creating an alert processing rule.
In the Rule settings, selects Apply action group and Create action group (or use an existing one). It is the destination to which the notification for an alert should be sent.
For the creation of an action group, in the Basics tab John specifies the name of the action group, the subscription, and the resource group under which it must be created. Under the Notifications tab, for the destination of the notification, he selects as Email/ SMS Message/ Push/ Voice and enters his email ID and other details as necessary.
Upon creating the action group, John is directed back to the alert processing rule creation. The newly created action group is visible on the Rule Settings page. In the Scheduling tab, he opts for "Always" and finalizes the creation of the processing rule.
John's current state is of accomplishment and relief. Successfully configuring the system to alert him about critical event failures has instilled a sense of assurance and readiness. This setup allows him to stay informed without the requirement for continual manual monitoring.
View metrics:
John, within the Azure Business Continuity Center, has the capability to observe built-in metrics specific to business continuity scenarios. Moreover, you can activate alerts based on these metric values. Presently, only metrics related to Azure Backup are supported, such as Backup Health Events and Restore Health Events. To gain further insight learn more about the supported metrics and their definitions.
John clicks on the Metrics tab, and it opens the Azure Monitor metrics explorer. He selects the resource to view metrics for.
John explores the metric to view, “Backup Health events”.
To further see the metric values at lower levels of granularity, John uses filters available on the view. For example, a particular protected item within the vault.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.