Mejora de la resistencia mediante la replicación del área de trabajo de Log Analytics entre regiones

La replicación del área de trabajo de Log Analytics entre regiones mejora la resistencia al permitirle cambiar al área de trabajo replicada y continuar las operaciones si se produce un error regional. En este artículo se explica cómo funciona la replicación del área de trabajo de Log Analytics, cómo replicar el área de trabajo, cómo cambiar de área de trabajo y cómo volver a decidir cuándo cambiar entre las áreas de trabajo replicadas.

Este es un vídeo que proporciona información general rápida sobre cómo funciona la replicación del área de trabajo de Log Analytics:

Importante

Aunque a veces se usa el término conmutación por error, por ejemplo, en la llamada API, la conmutación por error también se usa normalmente para describir un proceso automático. Por lo tanto, en este artículo se usa el término conmutación manual para resaltar que el cambio al área de trabajo replicada es una acción que se desencadena manualmente.

Funcionamiento de la replicación del área de trabajo de Log Analytics

El área de trabajo y la región originales se conocen como las principales. El área de trabajo replicada y la región alternativa se conocen como las secundarias.

El proceso de replicación del área de trabajo crea una instancia del área de trabajo en la región secundaria. El proceso crea el área de trabajo secundaria con la misma configuración que el área de trabajo principal y Azure Monitor actualiza automáticamente el área de trabajo secundaria con los cambios futuros que realice en la configuración del área de trabajo principal.

El área de trabajo secundaria es un área de trabajo "sombra" solo con fines de resiliencia. No puede ver el área de trabajo secundaria en Azure Portal y no puede administrarla ni acceder a ella directamente.

Al habilitar la replicación del área de trabajo, Azure Monitor también envía nuevos registros ingeridos al área de trabajo principal a la región secundaria. Los registros que ingiere en el área de trabajo antes de habilitar la replicación del área de trabajo no se copian.

Nota:

La replicación del área de trabajo replica completamente todos los esquemas de tabla, pero solo envía nuevos registros ingeridos desde que se activó la replicación. Los registros ingeridos en el área de trabajo antes de habilitar la replicación del área de trabajo no se copian.

Si una interrupción afecta a la región primaria, puede cambiar y volver a enrutar todas las solicitudes de ingesta y consulta a la región secundaria. Una vez que Azure mitiga la interrupción y el área de trabajo principal vuelve a estar en buen estado, puede hacer la conmutación manual a la región primaria.

Cuando realizas la conmutación, el área de trabajo secundaria se activa y la principal se vuelve inactiva. Después, Azure Monitor ingiere nuevos datos a través de la canalización de ingesta en la región secundaria, en lugar de la región primaria. Al cambiar a la región secundaria, Azure Monitor replica todos los datos que ingiere de la región secundaria a la región primaria. El proceso es asincrónico y no afecta a la latencia de ingesta.

Nota:

Después de cambiar a la región secundaria, si la región primaria no puede procesar los datos de registro entrantes, Azure Monitor almacena en búfer los datos de la región secundaria durante un máximo de 11 días. Durante los primeros cuatro días, Azure Monitor intenta de nuevo replicar los datos de manera periódica.

Protección contra la pérdida de datos en tránsito durante un error regional

Azure Monitor tiene varios mecanismos para asegurarse de que los datos en tránsito no se pierden cuando se produce un error en la región primaria.

Azure Monitor protege los datos que llegan al punto final de ingestión de la región primaria cuando la canalización de la región primaria no está disponible para procesar los datos. Cuando la canalización está disponible, continúa procesando los datos en tránsito y Azure Monitor ingiere y replica los datos en la región secundaria.

Si el punto de conexión de ingesta de la región primaria no está disponible, el agente de Azure Monitor reintenta periódicamente el envío de datos de registro al punto de conexión. El punto de conexión de ingesta de datos de la región secundaria comienza a recibir datos de agentes unos minutos después de desencadenar la conmutación.

Si escribe su propio cliente para enviar datos de registro al área de trabajo de Log Analytics, asegúrese de que el cliente controla las solicitudes de ingesta con errores.

Consideraciones de la implementación

Nota:

La replicación del área de trabajo no admite actualmente la replicación de tablas auxiliares y no debe habilitarse en áreas de trabajo que incluyan tablas auxiliares. Las tablas auxiliares no se replican y, por tanto, no están protegidas contra la pérdida de datos en caso de un error regional y no están disponibles al cambiar al área de trabajo secundaria.

• Durante la conmutación, no se pueden iniciar operaciones de administración del área de trabajo, incluidas las siguientes:

  • Cambio de retención del área de trabajo, plan de tarifa, límite diario, etc.
  • Cambio de la configuración de red
  • Cambio del esquema a través de nuevos registros personalizados o la conexión de registros de plataforma desde nuevos proveedores de recursos, como el envío de registros de diagnóstico desde un nuevo tipo de recurso

• El proceso de conmutación por error actualiza los registros del sistema de nombres de dominio (DNS) para volver a enrutar todas las solicitudes de ingesta a la región secundaria para su procesamiento. Algunos clientes HTTP tienen "conexiones persistentes" y pueden demorar más en adaptarse a las actualizaciones de DNS. Durante la conmutación, estos clientes pueden intentar ingerir registros a través de la región primaria durante algún tiempo. Es posible que esté ingiriendo registros en su área de trabajo principal mediante varios clientes, incluido el agente heredado de Log Analytics, el agente de Azure Monitor, código (utilizando la API de ingesta de registros o la API heredada de recopilación de datos HTTP), y otros servicios, como Microsoft Sentinel.

Importante

Las reglas de alertas de búsqueda de registros siguen funcionando al cambiar entre regiones a menos que el servicio Alertas de la región activa no funcione correctamente o las reglas de alerta no estén disponibles. Esto puede ocurrir, por ejemplo, si la región en la que se crearon las reglas de alerta está completamente inactiva. La replicación de reglas de alerta entre regiones no se realiza automáticamente como parte de la replicación del área de trabajo, pero el usuario puede hacerlo (por ejemplo, exportando desde la región primaria e importando a la secundaria).

• La operación de purga, que elimina los registros de un área de trabajo, quita los registros pertinentes de las áreas de trabajo principal y secundaria. Si una de las instancias del área de trabajo no está disponible, se produce un error en la operación de purga.

• No se puede eliminar un área de trabajo replicada. Para eliminar correctamente un área de trabajo, primero deshabilite la replicación.

• Microsoft Sentinel actualiza los registros de las tablas Watchlist e Threat Intelligence cada 12 días. Por lo tanto, dado que solo se ingieren nuevos registros en el área de trabajo replicada, puede tardar hasta 12 días en replicar completamente la lista de vigilancia y los datos de inteligencia sobre amenazas en la ubicación secundaria.

• La funcionalidad de destino de la solución del agente heredado de Log Analytics no se admite durante la conmutación manual. Durante la conmutación, los datos de la solución se ingieren de todos los agentes.

• Actualmente, estas características no se admiten o solo se admiten parcialmente:

  Característica	Soporte técnico
  Planes de tabla auxiliar	No compatible. Azure Monitor no replica los datos de las tablas con el plan de registro auxiliar en su espacio de trabajo secundario. Por lo tanto, estos datos no están protegidos contra la pérdida de datos en caso de un error regional y no están disponibles al cambiar al área de trabajo secundaria.
  Buscar trabajos, Restaurar	Parcialmente compatible: las operaciones de búsqueda y restauración crean tablas y las rellenan con resultados de búsqueda o datos restaurados. Después de habilitar la replicación del área de trabajo, las nuevas tablas creadas para estas operaciones se replican en el área de trabajo secundaria. Las tablas rellenadas antes de habilitar la replicación no se replican. Si estas operaciones están en curso cuando realizas el cambio, el resultado es inesperado. Es posible que se complete correctamente, pero no se replique, o que se produzca un error, según el estado del área de trabajo y el tiempo exacto.
  Application Insights sobre áreas de trabajo de Log Analytics	No soportado
  VM Insights	No soportado
  Información sobre contenedores	No soportado
  Vínculos privados	No se admite durante la conmutación por error

Regiones soportadas

La replicación del área de trabajo se admite actualmente para áreas de trabajo en un conjunto limitado de regiones, organizados por grupos de regiones (grupos de regiones geográficamente adyacentes). Al habilitar la replicación, seleccione una ubicación secundaria en la lista de regiones admitidas en el mismo grupo de regiones que la ubicación principal del área de trabajo. Por ejemplo, un área de trabajo de Oeste de Europa se puede replicar en Norte de Europa, pero no en Oeste de EE. UU. 2, ya que estas regiones se encuentran en grupos de regiones diferentes.

Actualmente se admiten estos grupos de regiones y regiones:

Grupo de regiones	Regiones primarias	Regiones secundarias (ubicaciones de replicación)
Norteamérica	Canada Central Este de Canadá Centro de EE. UU. Este de EE. UU. * Este de EE. UU. 2* Centro-Norte de EE. UU Centro-sur de EE. UU. * Centro-oeste de EE. UU. Oeste de EE. UU. Oeste de EE. UU. 2 Oeste de EE. UU. 3	Canada Central Centro de EE. UU. Este de EE. UU. * Este de EE. UU. 2* Oeste de EE. UU. Oeste de EE. UU. 2 Oeste de EE. UU. 3
Sudamérica	Brasil Sur Sudeste de Brasil	Brasil Sur Sudeste de Brasil
Europa	Centro de Francia Sur de Francia Norte de Alemania Centro-oeste de Alemania Norte de Italia Norte de Europa Este de Noruega Oeste de Noruega Centro de Polonia Sur de Reino Unido Centro de España Centro de Suecia Sur de Suecia Norte de Suiza Oeste de Suiza Europa Occidental Oeste de Reino Unido	Centro de Francia Centro-oeste de Alemania Norte de Europa Sur de Reino Unido Europa Occidental Oeste de Reino Unido
Oriente Medio	Centro de Catar Centro de Emiratos Árabes Unidos Norte de Emiratos Árabes Unidos	Centro de Catar Centro de Emiratos Árabes Unidos Norte de Emiratos Árabes Unidos
India	Centro de la India Jio India Central Jio India Occidental Sur de la India	Centro de la India Jio India Central Jio India Occidental Sur de la India
Asia Pacífico	Asia Oriental Japón Oriental Japón Oeste Centro de Corea del Sur Corea del Sur Sudeste Asiático	Asia Oriental Japón Oriental Japón Oeste Centro de Corea del Sur Sudeste Asiático
Oceanía	Centro de Australia Centro de Australia 2 Este de Australia Sudeste de Australia	Centro de Australia Este de Australia Sudeste de Australia
África	Norte de Sudáfrica Oeste de Sudáfrica	Norte de Sudáfrica Oeste de Sudáfrica

Nota:

Las áreas de trabajo ubicadas en Este de EE. UU., Este de EE. UU. 2 y Centro-sur de EE. UU. solo se pueden replicar en regiones secundarias fuera de ese conjunto de tres. Seleccione otra ubicación secundaria en el grupo de regiones de Norteamérica.

Requisitos de residencia de datos

Los distintos clientes tienen requisitos de residencia de datos diferentes, por lo que es importante controlar dónde se almacenan los datos. Azure Monitor procesa y almacena los registros en las regiones primarias y secundarias que elija. Para obtener más información, consulte Regiones admitidas.

Compatibilidad con Microsoft Sentinel y otros servicios

Varios servicios y características que usan áreas de trabajo de Log Analytics son compatibles con la replicación y conmutación de áreas de trabajo. Estos servicios y características siguen funcionando al cambiar al área de trabajo secundaria.

Por ejemplo, los problemas de red regionales que provocan la latencia de ingesta de registros pueden afectar a los clientes de Microsoft Sentinel. Los clientes que usan áreas de trabajo replicadas pueden cambiar a su región secundaria para seguir trabajando con el área de trabajo de Log Analytics y Sentinel. Sin embargo, si el problema de red afecta el estado de salud del servicio Sentinel, cambiar a otra región no mitiga el problema.

Algunas experiencias de Azure Monitor, incluidas Application Insights y VM Insights, solo son compatibles parcialmente con la replicación y conmutación del área de trabajo. Para obtener la lista completa, vea Consideraciones de implementación.

Modelo de precios

Al habilitar la replicación del área de trabajo, se le cobra por la replicación de todos los datos que ingiere en el área de trabajo, excepto los datos con _IsBillable = false.

Importante

Si envía datos al área de trabajo mediante el agente de Azure Monitor, la API de ingesta de registros, Azure Event Hubs u otros orígenes de datos que usan reglas de recopilación de datos, asegúrese de asociar las reglas de recopilación de datos con el punto de conexión de recopilación de datos del área de trabajo. Esta asociación garantiza que los datos que ingiere se replican en el área de trabajo secundaria. Si no asocia las reglas de recopilación de datos con el punto de conexión de recopilación de datos del área de trabajo, se le seguirá cobrando por todos los datos que ingiera en el área de trabajo, aunque no se repliquen.

Permisos necesarios

Acción	Permisos necesarios
Habilitar la replicación del espacio de trabajo	Los permisos Microsoft.OperationalInsights/workspaces/write y Microsoft.Insights/dataCollectionEndpoints/write, como los proporcionados por el rol integrado de Colaborador de supervisión, por ejemplo
Conmutar manualmente y volver a conmutar (desencadenador de conmutación por error y conmutación por recuperación)	Los permisos Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action, y Microsoft.Insights/dataCollectionEndpoints/triggerFailback/action como los proporcionados por el rol integrado de Colaborador de supervisión, por ejemplo
Comprobación del estado del área de trabajo	Permisos Microsoft.OperationalInsights/workspaces/read para el área de trabajo de Log Analytics, según lo proporcionado por el rol integrado de colaborador de monitorización, por ejemplo

Habilitar y deshabilitar la replicación del área de trabajo

Habilite y deshabilite la replicación del área de trabajo mediante un comando REST. El comando desencadena una operación de larga duración, lo que significa que la nueva configuración puede tardar unos minutos en aplicarse. Después de habilitar la replicación, puede tardar hasta una hora en que todas las tablas (tipos de datos) empiecen a replicarse y algunos tipos de datos podrían empezar a replicarse antes que otros. Los cambios realizados en esquemas de tabla después de habilitar la replicación del área de trabajo (por ejemplo, nuevas tablas de registro personalizadas o campos personalizados que cree o registros de diagnóstico configurados para nuevos tipos de recursos) pueden tardar hasta una hora en iniciar la replicación.

¿Uso de un clúster dedicado?

Si el área de trabajo está vinculada a un clúster dedicado, primero debe habilitar la replicación en el clúster y solo después en el área de trabajo. Esta operación crea un segundo clúster en su región secundaria (sin cargo adicional más allá de los cargos por replicación), con el fin de permitir que su área de trabajo siga utilizando un clúster dedicado incluso si se produce una conmutación por error. Esto también significa que las características como las claves administradas por clúster (CMK) siguen funcionando (con la misma clave) durante la conmutación por error. Una vez habilitada la replicación entre regiones, continúe con la habilitación de la replicación para una o varias de las áreas de trabajo vinculadas a este clúster.

Importante

Una vez habilitada la replicación del clúster, cambiar el destino de replicación requiere deshabilitar la replicación y volver a habilitarla en otra ubicación.

Para habilitar la replicación en el clúster dedicado, use el siguiente comando. La habilitación de la replicación en el clúster es una operación de larga duración que puede tardar tiempo en completarse y puede realizar un seguimiento de su estado exacto, tal como se explica en Comprobación del estado de aprovisionamiento del clúster.

Azure CLI

Para habilitar la replicación de clústeres, use el comando az rest de la CLI de Azure para invocar la API REST de Azure Resource Manager:

az rest --method put \
  --uri "/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01" \
  --body '{
    "properties": {
      "replication": {
        "enabled": true,
        "location": "<secondary_region>"
      }
    },
    "location": "<primary_region>"
  }'

REST API

Para habilitar la replicación del clúster, use este PUT comando:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
  "properties": {
    "replication": {
      "enabled": true,
      "location": "<secondary_region>"
    }
  },
  "location": "<primary_region>"
}

Donde:

• <subscription_id>: el identificador de suscripción relacionado con el clúster.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso de clúster de Log Analytics.
• <cluster_name>: el nombre del clúster dedicado.
• <primary_region>: la región primaria del clúster dedicado de Log Analytics.
• <secondary_region>: la región en la que Azure Monitor crea el clúster dedicado secundario.

Comprobación del estado de aprovisionamiento del clúster

Azure CLI

Para comprobar el estado de aprovisionamiento del clúster, use el comando az monitor log-analytics cluster show de la CLI de Azure:

az monitor log-analytics cluster show \
  --resource-group <resourcegroup_name> \
  --cluster-name <cluster_name> \
  --query "replication.provisioningState"

REST API

Para comprobar el estado de aprovisionamiento del clúster, ejecute este GET comando:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/clusters/<cluster_name>?api-version=2025-02-01

Donde:

• <subscription_id>: el identificador de suscripción relacionado con el clúster.
• <resourcegroup_name>: el grupo de recursos que contiene el recurso de clúster de Log Analytics.
• <cluster_name>: el nombre del clúster de Log Analytics.

Use el comando para comprobar que el estado de aprovisionamiento del clúster cambia de Updating a Succeededy que la región secundaria está establecida según lo previsto.

Nota:

Al habilitar la replicación del clúster, se aprovisiona un nuevo clúster en la ubicación secundaria. Este proceso puede tardar entre 1 y 2 horas.

Habilitar la replicación del espacio de trabajo

Azure CLI

Para habilitar la replicación en el área de trabajo de Log Analytics, use el comando az rest de la CLI de Azure para invocar la API rest de Azure Resource Manager:

az rest --method put \
  --uri "/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01" \
  --body '{
    "properties": {
      "replication": {
        "enabled": true,
        "location": "<secondary_region>"
      }
    },
    "location": "<primary_region>"
  }'

REST API

Para habilitar la replicación en el área de trabajo de Log Analytics, use este comando PUT:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
  "properties": {
    "replication": {
      "enabled": true,
      "location": "<secondary_region>"
    }
  },
  "location": "<primary_region>"
}

Donde:

• <subscription_id>: El ID de suscripción relacionado con su área de trabajo.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso del área de trabajo de Log Analytics.
• <workspace_name>: el nombre del área de trabajo.
• <primary_region>: la región primaria del área de trabajo de Log Analytics.
• <secondary_region>: la región en la que Azure Monitor crea el área de trabajo secundaria.

Para conocer los valores de región admitidos, consulte Regiones admitidas.

El comando habilitar replicación del área de trabajo es una operación de larga duración que puede tardar algún tiempo en completarse. Puede realizar un seguimiento del estado de aprovisionamiento de la solicitud, como se describe en Comprobación del estado de aprovisionamiento del área de trabajo.

Importante

Si el área de trabajo está vinculada a un clúster dedicado, habilite primero la replicación en el clúster. Tenga en cuenta también que la ubicación secundaria del área de trabajo debe ser idéntica a la ubicación secundaria de su clúster dedicado.

Comprobación del estado de aprovisionamiento del área de trabajo

Azure CLI

Para comprobar el estado de aprovisionamiento del área de trabajo, use el comando az monitor log-analytics workspace show de la CLI de Azure:

az monitor log-analytics workspace show \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --query "replication.provisioningState"

REST API

Para comprobar el estado de aprovisionamiento del área de trabajo, ejecute este GET comando:

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2025-02-01

Donde:

• <subscription_id>: identificador de suscripción relacionado con el área de trabajo.
• <resourcegroup_name>: el grupo de recursos que contiene el recurso del área de trabajo de Log Analytics.
• <workspace_name>: el nombre del área de trabajo de Log Analytics.

Use el comando para comprobar que el estado de aprovisionamiento del área de trabajo cambia de Updating a Succeededy que la región secundaria está establecida según lo previsto.

Nota:

En el momento en que habilitas la replicación para las áreas de trabajo que interactúan con Sentinel, puede llevar hasta 12 días replicar completamente los datos de la lista de vigilancia y de inteligencia sobre amenazas en el área de trabajo secundaria.

Comprobación de si la replicación está habilitada en un área de trabajo

Para comprobar si y dónde está habilitada la replicación del área de trabajo, revise esta configuración.

En Azure Portal, seleccione la > del área de trabajo. Si la replicación está habilitada, la sección Essentials muestra la ubicación secundaria, que indica la región del área de trabajo replicada.

La misma sección Essentials tiene una vista JSON que muestra los detalles de replicación como un objeto JSON, que también está disponible a través de REST/CLI.

Asociación de reglas de recolección de datos con el punto de conexión de recolección de datos del área de trabajo

El agente de Azure Monitor, la API de ingesta de registros y Azure Event Hubs recopilan datos y los envían al destino que especifique en función de cómo configure las reglas de recopilación de datos (DCR).

Si tiene reglas de recopilación de datos que envían datos al área de trabajo principal, debe asociar las reglas a un sistema de punto de conexión de recopilación de datos (DCE), que Azure Monitor crea al habilitar la replicación del área de trabajo. El nombre del punto de conexión de recopilación de datos del área de trabajo es idéntico a la ID de tu área de trabajo. Solo las reglas de recopilación de datos que asocie al punto de conexión de recopilación de datos del área de trabajo garantizan que la ingesta continúe durante una conmutación por error. Este comportamiento le permite especificar el conjunto de flujos de registro que se van a replicar, lo que le ayuda a controlar los costos de replicación.

Para replicar los datos que recopile mediante reglas de recopilación de datos, asocie las reglas de recopilación de datos al punto de conexión de recopilación de datos del área de trabajo:

1. En Azure Portal, seleccione Reglas de recopilación de datos.

2. En la pantalla Reglas de recopilación de datos, seleccione una regla de recopilación de datos que envíe datos al área de trabajo principal de Log Analytics.

3. En la página Información general de la regla de recopilación de datos, seleccione Configurar DCE y seleccione el punto de conexión de recopilación de datos del área de trabajo en la lista disponible:

   

   Para obtener más información sobre la DCE del sistema, compruebe las propiedades del objeto del área de trabajo.

Importante

Las reglas de recopilación de datos conectadas a un punto de conexión de recopilación de datos del área de trabajo solo pueden tener como destino esa área de trabajo específica. Las reglas de recopilación de datos no deben establecer como destino otros destinos, como otras áreas de trabajo o cuentas de Azure Storage.

¿Qué comprobar si se produce un error en la replicación del área de trabajo?

• ¿El área de trabajo está vinculada a un clúster dedicado?
  • La replicación debe estar habilitada en el clúster para poder habilitarla en el área de trabajo.
  • Tanto la replicación del clúster como del área de trabajo deben establecerse en la misma ubicación secundaria. Por ejemplo, si el clúster se replica en norte de Europa, las áreas de trabajo vinculadas a él solo se pueden replicar también en Norte de Europa.
• ¿Ha usado la API REST para habilitar la replicación?
  • Compruebe que ha usado la versión de API 2025-02-01 o posterior.
• ¿Se encuentra el área de trabajo principal en Este de EE. UU., Este de EE. UU. 2 o Centro-sur de EE. UU.?
  • Este de EE. UU., Este de EE. UU. 2 y Centro-sur de EE. UU. no se pueden replicar entre sí.
• ¿Dónde se encuentra el área de trabajo principal y dónde está la secundaria? Ambas ubicaciones deben estar en el mismo grupo de regiones. Por ejemplo, las áreas de trabajo ubicadas en regiones de EE. UU. no pueden tener una replicación (región secundaria) en Europa y viceversa. Para obtener la lista de grupos de regiones, consulte Regiones admitidas.
• ¿Tiene los permisos necesarios?
• ¿Ha permitido tiempo suficiente para que se complete la operación de replicación? la replicación es una operación de larga duración. Supervise el estado de la operación, tal como se explica en Comprobación del estado de aprovisionamiento del área de trabajo.
• ¿Ha intentado volver a habilitar la replicación para cambiar la ubicación secundaria del área de trabajo? Para cambiar la ubicación del área de trabajo secundaria, primero debe deshabilitar la replicación del área de trabajo, permitir que la operación se complete y, a continuación, habilitar la replicación en otra ubicación secundaria.

¿Qué se debe comprobar si se establece la replicación del área de trabajo, pero no se replican los registros?

• La replicación puede tardar hasta una hora en empezar a aplicarse y algunos tipos de datos pueden empezar a replicarse antes que otros.
• Los registros ingresados al área de trabajo antes de habilitar la replicación no se copian al área de trabajo secundaria. Solo se replican los registros ingeridos después de la habilitación de la replicación.
• Si algunos registros se replican y otros no, compruebe que todas las reglas de recopilación de datos (DCR) que transmiten registros al área de trabajo están configurados correctamente. Para revisar las DCR que tienen como destino el área de trabajo, consulte la pestaña Recopilación de datos de Información del Área de Trabajo en el portal de Azure de Log Analytics.

Deshabilitar la replicación del área de trabajo

Azure CLI

Para deshabilitar la replicación de un área de trabajo, use el comando az monitor log-analytics workspace update de la CLI de Azure:

az monitor log-analytics workspace update \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --replication-enabled false

REST API

Para deshabilitar la replicación de un área de trabajo, use este comando PUT:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
  "properties": {
    "replication": {
      "enabled": false
    }
  },
  "location": "<primary_region>"
}

Donde:

• <subscription_id>: identificador de suscripción relacionado con el área de trabajo.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso del área de trabajo.
• <workspace_name>: el nombre del área de trabajo.
• <primary_region>: la región primaria del área de trabajo.

El comando deshabilitar replicación es una operación de larga duración que puede tardar algún tiempo en completarse. Puede realizar un seguimiento del estado de aprovisionamiento de la solicitud, como se describe en Comprobación del estado de aprovisionamiento del área de trabajo.

Importante

Si está utilizando un clúster dedicado, debe desactivar la replicación del clúster después de desactivar la replicación para cada área de trabajo vinculada a este clúster.

Deshabilitación de la replicación del clúster

La deshabilitación de la replicación del clúster solo se puede realizar después de deshabilitar la replicación de todas las áreas de trabajo vinculadas a este clúster (si se habilitó anteriormente).

Azure CLI

Para deshabilitar la replicación de un clúster, use el comando az monitor log-analytics cluster update de la CLI de Azure:

az monitor log-analytics cluster update \
  --resource-group <resourcegroup_name> \
  --cluster-name <cluster_name> \
  --replication-enabled false

REST API

Para deshabilitar la replicación de un clúster, use este PUT comando:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Donde:

• <subscription_id>: identificador de suscripción relacionado con el clúster.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso de clúster.
• <workspace_name>: nombre del clúster.
• <primary_region>: la región primaria del clúster.

El comando es una operación de larga duración que puede tardar algún tiempo en completarse. Puede realizar un seguimiento del estado de aprovisionamiento de la solicitud, como se describe en Comprobación del estado de aprovisionamiento del área de trabajo.

Nota:

Una vez deshabilitada la replicación y el clúster replicado se purga, los registros replicados se eliminan y no pueden acceder de nuevo. Su copia original en su ubicación primaria no se modifica en este proceso.

Importante

El proceso de eliminación de la replicación del clúster tarda 14 días. Si necesita que este proceso se complete más rápido, cree una solicitud de soporte técnico de Azure.

Supervisión del estado del área de trabajo y del servicio

La latencia de ingesta o los errores de consulta son ejemplos de problemas que a menudo se pueden controlar mediante la conmutación por error a la región secundaria. Estos problemas se pueden detectar mediante notificaciones de Service Health y consultas de registro.

Las notificaciones de Service Health son útiles para problemas relacionados con el servicio. Para identificar problemas que afectan a su área de trabajo específica (y posiblemente no a todo el servicio), puede usar otras medidas:

• Creación de alertas basadas en el estado de los recursos del área de trabajo

• Establezca sus propios umbrales para métricas de estado del área de trabajo

• Cree sus propias consultas de supervisión para servir como indicadores de estado personalizados para el área de trabajo, como se describe en Supervisión del rendimiento del área de trabajo mediante consultas, para:

  • Medición de la latencia de ingesta por tabla
  • Identificar si el origen de la latencia son los agentes de recopilación o la canalización de ingesta
  • Supervisión de anomalías de volumen de ingesta por tabla y recurso
  • Supervisión de la tasa de éxito de consultas por tabla, usuario o recurso
  • Creación de alertas basadas en las consultas

Nota:

También puede usar consultas de registro para supervisar el área de trabajo secundaria, pero tenga en cuenta que la replicación de registros se realiza en operaciones por lotes. La latencia medida puede fluctuar y no indica ningún problema de estado con el área de trabajo secundaria. Para obtener más información, consulte Auditar el área de trabajo inactiva.

Cambiar al área de trabajo secundaria

Durante la conmutación, la mayoría de las operaciones funcionan de la misma manera que cuando se utiliza el espacio de trabajo principal y la región. Sin embargo, algunas operaciones tienen un comportamiento ligeramente diferente o están bloqueadas. Para más información, vea Consideraciones de implementación.

¿Cuándo debo cambiar?

Usted decide cuándo hacer la conmutación manual al área de trabajo secundaria y volver al área de trabajo principal en función del seguimiento continuo del estado y rendimiento, así como los estándares y requisitos del sistema.

Hay varios puntos que se deben tener en cuenta en el plan de conmutación, como se describe en las siguientes subsecciones.

Tipo de problema y ámbito

El proceso de conmutación enruta las solicitudes de ingesta y consulta a la región secundaria, que normalmente omite cualquier componente defectuoso que esté causando latencia o falla en la región primaria. Por lo tanto, es poco probable que la conmutación sea útil si:

• Hay un problema entre regiones con un recurso subyacente. Por ejemplo, si los mismos tipos de recursos fallan en tu región primaria y secundaria.
• Experimenta un problema relacionado con la administración del área de trabajo, como cambiar la retención del área de trabajo. Las operaciones de administración del área de trabajo siempre se gestionan en la región primaria. Durante la conmutación, se bloquean las operaciones de administración del área de trabajo.

Duración del problema

La conmutación no es instantánea. El proceso de reenrutar solicitudes se basa en las actualizaciones de DNS, que algunos clientes toman en cuestión de minutos, mientras que otros pueden tardar más tiempo. Por lo tanto, resulta útil comprender si el problema se puede resolver en unos minutos. Si el problema observado es coherente o continuo, no espere para realizar la conmutación manual. Estos son algunos ejemplos:

• Ingesta: los problemas con la canalización de ingesta de la región primaria pueden afectar a la replicación de datos en el área de trabajo secundaria. Durante la conmutación, los registros se envían en su lugar a la canalización de ingesta en la región secundaria.

• Consulta: si las consultas del área de trabajo principal producen un error o tiempo de expiración, las alertas de Búsqueda de registros pueden verse afectadas. En este escenario, cambie al área de trabajo secundaria para asegurarse de que todas las alertas se desencadenen correctamente.

Datos del área de trabajo secundaria

Los registros ingeridos en el área de trabajo principal antes de habilitar la replicación no se copian en el área de trabajo secundaria. Si ha habilitado la replicación del área de trabajo hace tres horas y ahora cambia al área de trabajo secundaria, las consultas solo pueden devolver datos de las últimas tres horas.

Antes de cambiar de región durante la conmutación, el área de trabajo secundaria debe contener un volumen adecuado de registros. Se recomienda esperar al menos una semana después de habilitar la replicación antes de iniciar la conmutación. Los siete días permiten que los datos suficientes estén disponibles en la región secundaria.

Desencadenar la conmutación manual

Antes de cambiar, confirme que la operación de replicación del área de trabajo se completó correctamente. La conmutación solo se realiza correctamente cuando el área de trabajo secundaria está configurada correctamente.

Azure CLI

Para cambiar al área de trabajo secundaria, use el comando az monitor log-analytics workspace failover de la interfaz de línea de comandos de Azure:

az monitor log-analytics workspace failover \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --location <secondary_region>

REST API

Para cambiar a tu espacio de trabajo secundario, utiliza este comando POST.

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2025-02-01

Donde:

• <subscription_id>: identificador de suscripción relacionado con el área de trabajo.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso del área de trabajo.
• <secondary_region>: la región a la que se va a cambiar durante la conmutación manual.
• <workspace_name>: nombre del área de trabajo a la que se va a cambiar durante la conmutación.

El comando es una operación de larga duración que puede tardar algún tiempo en completarse. Puede realizar un seguimiento del estado de aprovisionamiento de la solicitud, como se describe en Comprobación del estado de aprovisionamiento del área de trabajo.

¿Qué comprobar si falla la conmutación por error?

• ¿Ha usado la API de REST para desencadenar la conmutación por error?
  • Compruebe que ha usado la versión de API 2025-02-01 o posterior.
  • Compruebe que la ubicación secundaria proporcionada en el comando de conmutación por error es la ubicación secundaria establecida para esta área de trabajo. Esta información está disponible en la vista de Azure Portal del área de trabajo y en la API.
• La conmutación de regiones requiere un rol colaborador de Log Analytics en el grupo de recursos del área de trabajo y no solo en el propio área de trabajo.

Vuelve a tu área de trabajo principal

El proceso de conmutación de regreso cancela el re enrutamiento de consultas y solicitudes de ingesta de registros al área de trabajo secundaria. Al hacer la conmutación de regreso, Azure Monitor vuelve a enrutar las consultas y las solicitudes de ingesta de registros al área de trabajo principal.

Al hacer la conmutación manual a la región secundaria, Azure Monitor replica los registros del área de trabajo secundaria en el área de trabajo principal. Si una interrupción afecta al proceso de ingesta de registros en la región primaria, Azure Monitor puede tardar tiempo en completar la ingesta de los registros replicados en el área de trabajo principal.

¿Cuándo debo volver?

Hay varios puntos que se deben tener en cuenta en el plan de conmutación de regreso, como se describe en las siguientes subsecciones.

Estado de replicación del registro

Antes de volver, compruebe que Azure Monitor ha completado la replicación de todos los registros ingeridos durante el cambio a la región primaria. Si hace la conmutación de regreso antes de que todos los registros se repliquen en el área de trabajo principal, las consultas podrían devolver resultados parciales hasta que se complete la ingesta de registros.

Puede consultar el área de trabajo principal en Azure Portal para la región inactiva, como se describe en Auditar el área de trabajo inactiva.

Estado del área de trabajo principal

Hay dos elementos de salud importantes que debes comprobar en preparación para el regreso a tu área de trabajo principal.

• Confirme que no hay ninguna notificación pendiente de Service Health para el área de trabajo principal y la región.
• Confirme que el área de trabajo principal está ingiriendo datos de registro y procesando consultas como se espera.

Para obtener ejemplos de cómo consultar el área de trabajo principal cuando el área de trabajo secundaria está activa y omitir el reenrutamiento de solicitudes al área de trabajo secundaria, consulte Auditar el área de trabajo inactiva.

Cambio de desencadenador

Antes de hacer la conmutación de regreso, confirme el estado del área de trabajo principal y complete la replicación de registros.

El proceso de reversión actualiza los registros DNS. Después de actualizar los registros DNS, todos los clientes pueden tardar tiempo en recibir la configuración de DNS actualizada y reanudar el enrutamiento al área de trabajo principal.

Azure CLI

Para volver al área de trabajo principal, use el comando az monitor log-analytics workspace failback de la CLI de Azure:

az monitor log-analytics workspace failback \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name>

REST API

Para volver al área de trabajo principal, use este comando POST:

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2025-02-01

Donde:

• <subscription_id>: identificador de suscripción relacionado con el área de trabajo.
• <resourcegroup_name> : el grupo de recursos que contiene el recurso del área de trabajo.
• <workspace_name>: nombre del área de trabajo a la que se va a cambiar durante la conmutación de regreso.

El comando es una operación de larga duración que puede tardar algún tiempo en completarse. Puede realizar un seguimiento del estado de aprovisionamiento de la solicitud, como se describe en Comprobación del estado de aprovisionamiento del área de trabajo.

Auditar el área de trabajo inactiva

De forma predeterminada, la región activa del área de trabajo es la región donde se crea el área de trabajo y la región inactiva es la región secundaria, donde Azure Monitor crea el área de trabajo replicada.

Al desencadenar la conmutación por error, esto cambia: la región secundaria se activa y la región primaria se desactiva. Decimos que está inactivo porque no es el objetivo directo de la ingesta de registros ni de las solicitudes de consulta.

Es útil consultar la región inactiva antes de cambiar entre regiones para comprobar que el área de trabajo de la región inactiva tiene los registros que espera ver allí.

Para interactuar con la región inactiva, debe usar la API de Log Analytics de Azure Monitor. Para más información, incluido cómo autenticarse, consulte Acceso a la API de Log Analytics de Azure Monitor.

Consultar región inactiva

Para consultar datos de registro en la región inactiva, use este comando GET:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Por ejemplo, para ejecutar una consulta corta como Perf | count para el último día en la región secundaria, use:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Puede confirmar que Azure Monitor ejecuta la consulta en la región prevista comprobando estos campos en la tabla LAQueryLogs, que se crea al habilitar la auditoría de consultas en el área de trabajo de Log Analytics:

• isWorkspaceInFailover: indica si el área de trabajo estaba en modo de conmutación durante la consulta. El tipo de datos es booleano (True, False).
• workspaceRegion: la región del área de trabajo de destino de la consulta. El tipo de datos es String.

Supervisión del rendimiento del área de trabajo mediante consultas

Se recomienda usar las consultas de esta sección para crear reglas de alerta que le notifiquen sobre posibles problemas de estado o rendimiento del área de trabajo. Sin embargo, la decisión de cambiar requiere una cuidadosa consideración y no debe realizarse automáticamente.

En la regla de consulta, puede definir una condición para cambiar al espacio de trabajo secundario después de un número especificado de violaciones. Para obtener más información, consulte Crear o editar una regla de alertas de búsqueda de registros.

Dos medidas significativas del rendimiento del área de trabajo incluyen latencia de ingesta y volumen de ingesta. En las secciones siguientes se exploran estas opciones de supervisión.

Supervisión de la latencia de ingesta de un extremo a otro

La latencia de ingesta mide el tiempo necesario para ingerir registros en el área de trabajo. La medida de tiempo se inicia cuando se produce el evento registrado inicial y finaliza cuando el registro se almacena en el área de trabajo. La latencia total de ingesta se compone de dos partes:

• Latencia del agente: el tiempo requerido por el agente para notificar un evento.
• Latencia de la canalización de ingesta (back-end): el tiempo necesario para que la canalización de ingesta procese los registros y los escriba en el área de trabajo.

Los distintos tipos de datos tienen una latencia de ingesta diferente. Puede medir la ingesta de cada tipo de datos por separado, o crear una consulta genérica para todos los tipos, y una consulta más detallada para tipos específicos que son de mayor importancia para usted. Se recomienda medir el percentil 90 de la latencia de ingesta, que es más sensible al cambio que el promedio o el percentil 50 (mediana).

En las siguientes secciones se muestra cómo usar consultas para comprobar la latencia de ingesta de datos del área de trabajo.

Evaluación de la latencia de ingesta de línea base de tablas específicas

Comience por determinar la latencia de línea base de tablas específicas durante varios días.

Esta consulta de ejemplo crea un gráfico del percentil 90 de latencia de ingesta en la tabla Perf:

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

Después de ejecutar la consulta, revise los resultados y el gráfico representado para determinar la latencia esperada para esa tabla.

Supervisión y alerta sobre la latencia de ingesta actual

Después de establecer la latencia de ingesta de línea base para una tabla específica, cree una regla de alertas de búsqueda de registros para la tabla en función de los cambios en la latencia durante un breve período de tiempo.

Esta consulta calcula la latencia de ingesta en los últimos 20 minutos:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

Dado que puede esperar algunas fluctuaciones, cree una condición de regla de alerta para comprobar si la consulta devuelve un valor significativamente mayor que la línea base.

Determinar el origen de la latencia de ingesta

Cuando observe que la latencia total de ingesta está subiendo, puede usar consultas para determinar si el origen de la latencia son los agentes o la canalización de ingesta.

Esta consulta representa la latencia del percentil 90 de los agentes y de la canalización, por separado:

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
    PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

Nota:

Aunque el gráfico muestra los datos del percentil 90 como columnas apiladas, la suma de los datos de los dos gráficos no es igual al percentil 90 de ingesta total.

Supervisión del volumen de ingesta

Las medidas de volumen de ingesta pueden ayudar a identificar cambios inesperados en el volumen de ingesta total o específico de la tabla para el área de trabajo. Las medidas de volumen de consulta pueden ayudarle a identificar problemas de rendimiento con la ingesta de registros. Algunas medidas de volumen útiles incluyen:

• Volumen total de ingesta por tabla
• Volumen de ingesta constante (sin cambios)
• Anomalías de ingesta: picos y caídas en el volumen de ingesta

En las secciones siguientes se muestra cómo usar consultas para comprobar el volumen de ingesta del área de trabajo.

Supervisión del volumen total de ingesta por tabla

Puede definir una consulta para supervisar el volumen de ingesta por tabla en su espacio de trabajo. La consulta puede incluir una alerta que comprueba si hay cambios inesperados en los volúmenes totales o específicos de la tabla.

Esta consulta calcula el volumen total de ingesta en la última hora por tabla en megabytes por segundo (MB):

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

Comprobar el estancamiento de la ingestión

Si ingiere registros a través de agentes, puede usar el latido del agente para detectar la conectividad. Un latido todavía puede revelar una detención en la ingesta de registros en el área de trabajo. Cuando los datos de la consulta revelan un estancamiento en la ingesta, puede definir una condición para activar una respuesta deseada.

La consulta siguiente comprueba el latido del agente para detectar problemas de conectividad:

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

Supervisión de anomalías de ingesta

Puede identificar picos y caídas en los datos de volumen de ingesta de su área de trabajo de diversas maneras. Use la función series_decompose_anomalies() para extraer anomalías de los volúmenes de ingesta que supervisa en el área de trabajo o cree su propio detector de anomalías para admitir escenarios de área de trabajo únicos.

Identificación de anomalías mediante series_decompose_anomalies

La función series_decompose_anomalies() identifica anomalías en una serie de valores de datos. Esta consulta calcula el volumen de ingesta por hora de cada tabla del área de trabajo de Log Analytics y usa series_decompose_anomalies() para identificar anomalías:

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

Para más información sobre cómo usar series_decompose_anomalies() para detectar anomalías en los datos de registro, consulte Detección y análisis de anomalías mediante funcionalidades de aprendizaje automático de KQL en Azure Monitor.

Creación de su propio detector de anomalías

Puede crear un detector de anomalías personalizado para admitir los requisitos de escenario para la configuración del área de trabajo. En esta sección se proporciona un ejemplo para demostrar el proceso.

La consulta siguiente calcula:

• Volumen de ingesta esperado: por hora, por tabla (basado en el valor medio de medianas, pero puede personalizar la lógica)
• Volumen de ingesta real: por hora, por tabla

Para filtrar diferencias insignificantes entre el volumen de ingesta esperado y real, la consulta aplica dos filtros:

• Tasa de cambio: más del 150 % o inferior al 66 % del volumen esperado, por tabla
• Volumen de cambios: indica si el volumen aumentado o reducido es superior al 0,1 % del volumen mensual de esa tabla

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

Supervisión del éxito y el error de la consulta

Cada consulta devuelve un código de respuesta que indica éxito o error. Cuando se produce un error en la consulta, la respuesta también incluye los tipos de error. Un aumento elevado de errores puede indicar un problema con la disponibilidad del área de trabajo o el rendimiento del servicio.

Esta consulta cuenta cuántas consultas devolvieron un código de error del servidor:

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

Contenido relacionado

• Supervisión del estado del área de trabajo de Log Analytics
• Supervisión de problemas operativos en el área de trabajo de Log Analytics de Azure Monitor