Skip to content

Commit 7034963

Browse files
committed
updates
1 parent 7aa9d55 commit 7034963

File tree

2 files changed

+20
-16
lines changed

2 files changed

+20
-16
lines changed

articles/azure-monitor/includes/logs-availability-zones.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,8 @@ ms.date: 08/28/2024
88

99
Each Azure region that supports availability zones has a set of datacenters equipped with independent power, cooling, and networking infrastructure.
1010

11-
Azure Monitor Logs availability zones are [zone-redundant](../../reliability/availability-zones-overview.md#zonal-and-zone-redundant-services), which means that Microsoft manages spreading service requests and replicating data across different zones in supported regions. If one zone is affected by an incident, Microsoft manages failover to a different availability zone in the region automatically. You don't need to take any action because switching between zones is seamless.
11+
Azure Monitor Logs availability zones are [redundant](../../reliability/availability-zones-overview.md#zonal-and-zone-redundant-services), which means that Microsoft spreads service requests and replicates data across different zones in supported regions. If an incident affects one zone, Microsoft uses a different availability zone in the region instead, automatically. You don't need to take any action because switching between zones is seamless.
1212

13-
In most regions, Azure Monitor Logs availability zones support **data resilience**, which means your stored data is protected against zonal failures, but service operations might be impacted by regional incidents. A subset of the availability zones that support data resilience currently also support **service resilience**, which means that Azure Monitor Logs service operations - for example, log ingestion, queries, and alerts - can continue in the event of a zone failure.
13+
In most regions, Azure Monitor Logs availability zones support **data resilience**, which means your stored data is protected against zonal failures, but service operations might still be impacted by regional incidents. A subset of the availability zones that support data resilience also support **service resilience**, which means that Azure Monitor Logs service operations - for example, log ingestion, queries, and alerts - can continue in the event of a zone failure.
14+
15+
Availability zones protect against infrastructure-related incidents, such as storage failures. They don’t protect against application-level issues, such as faulty code deployments or certificate failures, which impact the entire region.

articles/azure-monitor/includes/waf-logs-reliability.md

Lines changed: 16 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -25,45 +25,47 @@ This video provides an overview of reliability and resilience options available
2525

2626
You can [continuously export data sent to specific tables in your Log Analytics workspace](../logs/logs-data-export.md) to Azure storage accounts.
2727

28-
The destination storage account you export data to must be in the same region as your Log Analytics workspace, but you can replicate the storage account to another region, so your ingested logs remain safe and available even if the workspace region is down.
28+
The storage account you export data to must be in the same region as your Log Analytics workspace. To protect and have access to your ingested logs, even if the workspace region is down, use a geo-redundant storage account, as explained in [Configuration recommendations](#configuration-recommendations).
2929

3030
The export mechanism doesn’t provide protection from incidents impacting the ingestion pipeline or the export process itself.
3131

3232
> [!NOTE]
33-
> You can access data in a storage account from Azure Monitor Logs using the [externaldata operator](/kusto/query/externaldata-operator?view=azure-monitor). However, the exported data is stored in five-minute blobs and analyzing data spanning multiple blobs can be cumbersome. Therefore, exporting data to a storage account is a good data backup mechanism, but having the backed up data in a storage account is not ideal if you need in for analysis in Azure Monitor Logs. You can query a large volumes of blob data using [Azure Data Explorer](/azure/data-explorer/query-exported-azure-monitor-data), [Azure Data Factory](/azure/data-factory/introduction#connect-and-collect), or any other storage access tool.
33+
> You can access data in a storage account from Azure Monitor Logs using the [externaldata operator](/kusto/query/externaldata-operator?view=azure-monitor). However, the exported data is stored in five-minute blobs and analyzing data spanning multiple blobs can be cumbersome. Therefore, exporting data to a storage account is a good data backup mechanism, but having the backed up data in a storage account is not ideal if you need it for analysis in Azure Monitor Logs. You can query large volumes of blob data using [Azure Data Explorer](/azure/data-explorer/query-exported-azure-monitor-data), [Azure Data Factory](/azure/data-factory/introduction#connect-and-collect), or any other storage access tool.
3434
35-
#### Protection against regional failure using workspace replication (preview)
35+
#### Cross-regional data protection and service resilience using workspace replication (preview)
3636

3737
Workspace replication (preview) is the most extensive resilience solution as it replicates the Log Analytics workspace and incoming logs to another region.
3838

39-
Workspace replication protects both your logs and the service operations, and allows you to continue monitoring your systems in the event of region-wide incidents, regardless of whether they stem from the infrastructure or the application layer.
39+
Workspace replication protects both your logs and the service operations, and allows you to continue monitoring your systems in the event of infrastructure or application-related region-wide incidents.
40+
41+
In contrast with availability zones, which Microsoft manages end-to-end, you need to monitor your primary workspace's health and decide when to switch over to the workspace in the secondary region and back.
4042

4143

4244
### Design checklist
4345

4446
> [!div class="checklist"]
4547
> - To ensure service and data resilience to region-wide incidents, enable workspace replication.
46-
> - To ensure in-region protection against datacenter failure, create your workspace in a region that supports data resilience.
47-
> - For cross-regional backup of data in specific tables, use the continuous export feature to send data to a zone-redundant storage account.
48+
> - To ensure in-region protection against datacenter failure, create your workspace in a region that supports availability zones.
49+
> - For cross-regional backup of data in specific tables, use the continuous export feature to send data to a geo-replicated storage account.
4850
> - Monitor the health of your Log Analytics workspaces.
4951
5052
### Configuration recommendations
5153

5254
| Recommendation | Benefit |
5355
|:---|:---|
54-
| To ensure the greatest degree of resilience, enable workspace replication. |**Cross-regional resilience for workspace data and service operations.** <br><br>[Workspace replication (preview)](../logs/workspace-replication.md) ensures high availability by creating a secondary instance of your workspace in another region and ingesting your logs to both workspaces.<br><br>When needed, switch to your secondary workspace until the issues impacting your primary workspace are resolved. You can continue ingesting logs, querying data, using dashboards, alerts, and Sentinel in your secondary workspace. You also have access to logs ingested before the region switch.<br><br>This is a paid feature, so consider whether your want to replicate all of your incoming logs, or only some data streams. |
55-
| If possible, create your workspace in a region that supports Azure Monitor service-resilience. | **In-region resilience of workspace data and service operations in the event of datacenter issues.** <br><br>Availability zones that support service resilience also support data resilience. This means that even if an entire datacenter becomes unavailable, the redundancy between zones allows Azure Monitor service operations, like ingestion and querying, to continue to work, and your ingested logs to remain available.<br><br>Availability zones provide in-region protection, but don't protect against issues that impact the entire region.<br><br>For information about which regions support data reslience, see [Enhance data and service resilience in Azure Monitor Logs with availability zones](../logs/availability-zones.md). |
56-
| Create your workspace in a region that supports data resilience. | **In-region protection against loss of the logs in your workspace in the event of datacenter issues.** <br><br>Creating your workspace in a region that supports data resilience means that even if the entire datacenter becomes unavailable, your ingested logs are safe. <br>If the service is unable to run queries, you won’t be able to view the logs until the issue is resolved.<br><br>For information about which regions support data reslience, see [Enhance data and service resilience in Azure Monitor Logs with availability zones](../logs/availability-zones.md). |
57-
| Configure data export from specific tables to a storage account that's replicated across regions. | **Maintain a backup copy of your log data in a different region.**<br><br>The [data export feature of Azure Monitor](../logs/logs-data-export.md) allows you to continuously export data sent to specific tables to Azure storage where it can be retained for extended periods. Use a geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) account to keep your data safe even if an entire region becomes unavailable. To make your data readable from the other regions, configure your storage account for read access to the secondary region. For more information see [Azure Storage redundancy on a secondary region](/azure/storage/common/storage-redundancy#redundancy-in-a-secondary-region) and [Azure Storage read access to data in the secondary region](/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region).<br><br>For [tables that don't supported continuous data export](../logs/logs-data-export.md?tabs=portal#limitations), you can use other methods of exporting data, including Logic Apps, to protect your data. This is primarily a solution to meet compliance for data retention since the data can be difficult to analyze and restore to the workspace.<br><br> Data export is susceptible to regional incidents because it relies on the stability of the Azure Monitor ingestion pipeline in your region. It doesn't provide resiliency against incidents impacting the regional ingestion pipeline.|
56+
| To ensure the greatest degree of resilience, enable workspace replication. |**Cross-regional resilience for workspace data and service operations.** <br><br>[Workspace replication (preview)](../logs/workspace-replication.md) ensures high availability by creating a secondary instance of your workspace in another region and ingesting your logs to both workspaces.<br><br>When needed, switch to your secondary workspace until the issues impacting your primary workspace are resolved. You can continue ingesting logs, querying data, using dashboards, alerts, and Sentinel in your secondary workspace. You also have access to logs ingested before the region switch.<br><br>This is a paid feature, so consider whether you want to replicate all of your incoming logs, or only some data streams. |
57+
| If possible, create your workspace in a region that supports Azure Monitor service-resilience. | **In-region resilience of workspace data and service operations in the event of datacenter issues.** <br><br>Availability zones that support service resilience also support data resilience. This means that even if an entire datacenter becomes unavailable, the redundancy between zones allows Azure Monitor service operations, like ingestion and querying, to continue to work, and your ingested logs to remain available.<br><br>Availability zones provide in-region protection, but don't protect against issues that impact the entire region.<br><br>For information about which regions support data resilience, see [Enhance data and service resilience in Azure Monitor Logs with availability zones](../logs/availability-zones.md). |
58+
| Create your workspace in a region that supports data resilience. | **In-region protection against loss of the logs in your workspace in the event of datacenter issues.** <br><br>Creating your workspace in a region that supports data resilience means that even if the entire datacenter becomes unavailable, your ingested logs are safe. <br>If the service is unable to run queries, you can't view the logs until the issue is resolved.<br><br>For information about which regions support data resilience, see [Enhance data and service resilience in Azure Monitor Logs with availability zones](../logs/availability-zones.md). |
59+
| Configure data export from specific tables to a storage account that's replicated across regions. | **Maintain a backup copy of your log data in a different region.**<br><br>The [data export feature of Azure Monitor](../logs/logs-data-export.md) allows you to continuously export data sent to specific tables to Azure storage where it can be retained for extended periods. Use a geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) account to keep your data safe even if an entire region becomes unavailable. To make your data readable from the other regions, configure your storage account for read access to the secondary region. For more information, see [Azure Storage redundancy on a secondary region](/azure/storage/common/storage-redundancy#redundancy-in-a-secondary-region) and [Azure Storage read access to data in the secondary region](/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region).<br><br>For [tables that don't supported continuous data export](../logs/logs-data-export.md?tabs=portal#limitations), you can use other methods of exporting data, including Logic Apps, to protect your data. This is primarily a solution to meet compliance for data retention since the data can be difficult to analyze and restore to the workspace.<br><br> Data export is susceptible to regional incidents because it relies on the stability of the Azure Monitor ingestion pipeline in your region. It doesn't provide resiliency against incidents impacting the regional ingestion pipeline.|
5860
| Monitor the health of your Log Analytics workspaces. | Use [Log Analytics workspace insights](../logs/workspace-design.md) to track failed queries and create [health status alert](../logs/log-analytics-workspace-health.md#view-log-analytics-workspace-health-and-set-up-health-status-alerts) to proactively notify you if a workspace becomes unavailable because of a datacenter or regional failure. |
5961

6062
#### Compare Azure Monitor Logs resilience features
6163

6264
| Feature | Service resilience | Data backup | High availability | Scope of protection | Setup | Cost |
6365
|------------------------|--------------------|-------------|-------------------|-------------------|--------------------------|------------------------------------------------------------------------------|
64-
| Workspace replication | :white_check_mark: | :white_check_mark: | :white_check_mark: | Cross-region protection against region-wide incidents | Enable replication of the workspace and related data collection rules. Switch between regions as needed. | Based on the amount of replicated GBs and region. |
65-
| Availability zones | :white_check_mark: <br>In supported regions | :white_check_mark: | :white_check_mark: | In-region protection against datacenter issues | Automatically enabled on dedicated clusters in supported regions. | No cost |
66-
| Continuous data export | | :white_check_mark: | | Protection from regional failure <sup>1</sup> | Enable per table. | Cost of data export + Storage blob or Event Hubs |
66+
| Workspace replication | :white_check_mark: | :white_check_mark: | :white_check_mark: | Cross-region protection against region-wide incidents | Enable replication of the workspace and related data collection rules. Switch between regions as needed. | Based on the number of replicated GBs and region. |
67+
| Availability zones | :white_check_mark: <br>In supported regions | :white_check_mark: | :white_check_mark: | In-region protection against datacenter issues | Automatically enabled in supported regions. | No cost |
68+
| Continuous data export | | :white_check_mark: | | Protection from data loss because of a regional failure <sup>1</sup> | Enable per table. | Cost of data export + Storage blob or Event Hubs |
6769

6870

69-
<sup>1</sup> Data export provides cross-region protection if you export logs to a different region. In the event of an incident, previously exported data is backed up and readily available; however, further export might fail, depending on the nature of the incident.
71+
<sup>1</sup> Data export provides cross-region protection if you export logs to a geo-replicated storage account. In the event of an incident, previously exported data is backed up and readily available; however, further export might fail, depending on the nature of the incident.

0 commit comments

Comments
 (0)