Aprimorar a resiliência replicando seu workspace do Log Analytics entre regiões

Replicar seu workspace do Log Analytics entre regiões aprimora a resiliência, permitindo que você alterne para o workspace replicado e continue as operações se houver uma falha regional. Este artigo explica como funciona a replicação do workspace do Log Analytics, como realizar a replicação do seu workspace, como alternar entre os espaços de trabalho replicados e decidir quando fazer essa alternância.

Veja um vídeo que fornece uma visão geral rápida de como funciona a replicação do workspace do Log Analytics:

Importante

Embora às vezes usemos o termo failover, por exemplo, na chamada de API, failover também é comumente usado para descrever um processo automático. Portanto, esse artigo usa o termo alternância para enfatizar que a alternância para o espaço de trabalho replicado é uma ação que você aciona manualmente.

Como funciona a replicação do workspace do Log Analytics

Seu espaço de trabalho e região originais são chamados de primário. O workspace replicado e a região alternativa são chamados de secundário.

O processo de replicação do espaço de trabalho cria uma instância dele na região secundária. O processo cria o workspace secundário com a mesma configuração do workspace primário e o Azure Monitor atualiza automaticamente o workspace secundário com quaisquer alterações futuras feitas na configuração do workspace primário.

O espaço de trabalho secundário é um espaço de trabalho "sombra" apenas para fins de resiliência. Você não pode ver o workspace secundário no portal do Azure e não pode gerenciá-lo ou acessá-lo diretamente.

Quando você habilita a replicação do espaço de trabalho, o Azure Monitor envia novos logs ingeridos no seu espaço de trabalho principal também para sua região secundária. Os logs que você ingere no espaço de trabalho antes de habilitar a replicação do espaço de trabalho não são copiados.

Observação

A replicação do espaço de trabalho replica completamente todos os esquemas de tabela, mas envia apenas novos logs ingeridos desde que a replicação foi ativada. Os logs ingeridos no espaço de trabalho antes de você habilitar a replicação do espaço de trabalho não são copiados.

Se uma interrupção afetar sua região primária, você poderá alternar e redirecionar todas as solicitações de ingestão e consulta para sua região secundária. Depois que o Azure atenuar a interrupção e seu espaço de trabalho principal estiver íntegro novamente, você poderá retornar para sua região principal.

Quando você alterna entre as áreas de trabalho, a área de trabalho secundária fica ativa e a primária fica inativa. Em seguida, o Azure Monitor ingere novos dados por meio do pipeline de ingestão em sua região secundária, em vez da região primária. Quando você alterna para sua região secundária, o Azure Monitor replica todos os dados que você ingerir da região secundária para a região primária. O processo é assíncrono e não afeta a latência de ingestão.

Observação

Depois de alternar para a região secundária, se a região primária não puder processar dados de log de entrada, o Azure Monitor armazenará os dados em buffer na região secundária por até 11 dias. Durante os primeiros quatro dias, o Azure Monitor tenta automaticamente replicar os dados periodicamente.

Proteção contra perda de dados em trânsito durante uma falha regional

O Azure Monitor tem vários mecanismos para garantir que os dados em trânsito não sejam perdidos quando houver uma falha na região primária.

O Azure Monitor protege os dados que chegam ao ponto de extremidade de ingestão da região primária quando o pipeline da região primária não está disponível para processar os dados. Quando o pipeline fica disponível, ele continua a processar dados em trânsito e o Azure Monitor ingere e replica os dados para a região secundária.

Se o ponto de extremidade de ingestão da região primária não estiver disponível, o agente do Azure Monitor tentará enviar regularmente dados de log para o ponto de extremidade. O ponto de extremidade de ingestão de dados na região secundária começa a receber dados de agentes alguns minutos após você disparar a substituição.

Se você escrever seu próprio cliente para enviar dados de log para seu espaço de trabalho do Log Analytics, certifique-se de que o cliente trate de solicitações de ingestão com falha.

Considerações de implantação

Observação

A replicação de workspace atualmente não dá suporte à replicação de tabelas auxiliares e não deve ser habilitada em workspaces que incluem tabelas auxiliares. As tabelas auxiliares não são replicadas e, portanto, não são protegidas contra perda de dados no caso de uma falha regional e não estão disponíveis quando você alterna para o workspace secundário.

• As operações de gestão do espaço de trabalho não podem ser iniciadas durante a alternância, incluindo:

  • Alteração na retenção do espaço de trabalho, nível de preço, limite diário e assim por diante
  • Alteração das configurações de rede
  • Alteração de esquema por meio de novos logs personalizados ou conexão de logs de plataforma de novos provedores de recursos, como envio de logs de diagnóstico de um novo tipo de recurso

• O processo de failover atualiza seus registros DNS (Sistema de Nomes de Domínio) para redirecionar todas as solicitações de ingestão para sua região secundária para processamento. Alguns clientes HTTP têm "conexões persistentes" e podem levar mais tempo para captar as atualizações de DNS. Durante a alternância, esses clientes podem tentar ingerir logs por meio da região primária por algum tempo. Você pode estar ingerindo logs no seu espaço de trabalho principal usando vários clientes, incluindo o Agente do Log Analytics legado, o Agente do Azure Monitor, código (usando a API de ingestão de logs ou a API de coleta de dados HTTP legada) e outros serviços, como o Microsoft Sentinel.

Importante

As regras de alertas da pesquisa de logs continuam funcionando quando você alterna entre regiões, a menos que o serviço Alertas na região ativa não esteja funcionando corretamente ou as regras de alerta não estejam disponíveis. Isso pode acontecer, por exemplo, se a região na qual as regras de alerta foram criadas estiver totalmente inoperante. A replicação de regras de alerta entre regiões não é feita automaticamente como parte da replicação do workspace, mas pode ser feita pelo usuário (por exemplo, exportando da região primária e importando para a secundária).

• A operação de limpeza, que exclui registros de um workspace, remove os registros relevantes dos workspaces primário e secundário. Se uma das instâncias do workspace não estiver disponível, a operação de limpeza falhará.

• Um workspace replicado não pode ser excluído. Para excluir corretamente um workspace, primeiro desabilite a replicação.

• O Microsoft Sentinel atualiza os logs nas tabelas Watchlist e Inteligência contra Ameaças a cada 12 dias. Portanto, como somente novos logs são ingeridos no espaço de trabalho replicado, pode levar até 12 dias para replicar completamente os dados da Lista de Observação e da Inteligência de Ameaças para o local secundário.

• O recurso de direcionamento de soluções do agente legado do Log Analytics não é suportado durante a alternância. Durante a alternância, os dados da solução são ingeridos de todos os agentes.

• Atualmente, não há suporte para esses recursos ou há suporte apenas parcial:

  Recurso	Suporte
  Planos de tabela auxiliares	Não há suporte. O Azure Monitor não replica dados em tabelas com o plano de log auxiliar para seu espaço de trabalho secundário. Portanto, esses dados não estão protegidos contra perda em caso de falha regional e não estão disponíveis quando você muda para o seu workspace secundário.
  Trabalhos de pesquisa, Restauração	Parcialmente suportado - As operações de pesquisa e restauração criam tabelas e as preenchem com resultados de pesquisa ou dados restaurados. Depois de habilitar a replicação do workspace, novas tabelas criadas para essas operações são replicadas para seu workspace secundário. As tabelas preenchidas antes de você ativar a replicação não são replicadas. Se essas operações estiverem em andamento quando você fizer a troca, o resultado será inesperado. Ele pode ser concluído com êxito, mas não replicar, ou pode falhar, dependendo da integridade do workspace e do tempo exato.
  Application Insights sobre espaços de trabalho do Log Analytics	Sem suporte
  VM Insights	Sem suporte
  Insights do contêiner	Sem suporte
  Links privados	Não há suporte durante o failover

Regiões com suporte

Atualmente, há suporte para replicação de workspaces em um conjunto limitado de regiões, organizado por grupos de regiões (grupos de regiões geograficamente adjacentes). Ao habilitar a replicação, selecione um local secundário na lista de regiões com suporte no mesmo grupo de regiões que o local primário do workspace. Por exemplo, um workspace no Oeste da Europa pode ser replicado no Norte da Europa, mas não no Oeste dos EUA 2, pois essas regiões estão em grupos de regiões diferentes.

Atualmente, há suporte para esses grupos de regiões e regiões:

Grupo de Regiões	Regiões primárias	Regiões secundárias (locais de replicação)
América do Norte	Canadá Central Leste do Canadá Centro dos EUA Leste dos EUA* Leste dos EUA 2* Centro-Norte dos EUA Centro-Sul dos EUA* Centro-Oeste dos EUA Oeste dos EUA Oeste dos EUA 2 Oeste dos EUA 3	Canadá Central Centro dos EUA Leste dos EUA* Leste dos EUA 2* Oeste dos EUA Oeste dos EUA 2 Oeste dos EUA 3
América do Sul	Sul do Brasil Sudeste do Brasil	Sul do Brasil Sudeste do Brasil
Europa	França Central Sul da França Norte da Alemanha Centro-Oeste da Alemanha Norte da Itália Europa do Norte Leste da Noruega Oeste da Noruega Polônia Central Sul do Reino Unido Espanha Central Suécia Central Sul da Suécia Norte da Suíça Oeste da Suíça Europa Ocidental Oeste do Reino Unido	França Central Centro-Oeste da Alemanha Europa do Norte Sul do Reino Unido Europa Ocidental Oeste do Reino Unido
Médio Oriente	Catar Central Centro dos Emirados Árabes Unidos Norte dos EAU	Catar Central Centro dos Emirados Árabes Unidos Norte dos EAU
Índia	Índia Central Jio India Central Jio India West Sul da Índia	Índia Central Jio India Central Jio India West Sul da Índia
Pacífico Asiático	Ásia Oriental Leste do Japão Oeste do Japão Coreia Central Coreia do Sul Sudeste Asiático	Ásia Oriental Leste do Japão Oeste do Japão Coreia Central Sudeste Asiático
Oceania	Austrália Central Austrália Central 2 Leste da Austrália Sudeste da Austrália	Austrália Central Leste da Austrália Sudeste da Austrália
África	Norte da África do Sul Oeste da África do Sul	Norte da África do Sul Oeste da África do Sul

Observação

Espaços de trabalho localizados no Leste dos EUA, Leste dos EUA 2 e Centro-Sul dos EUA só podem ser replicados em regiões secundárias fora daquele conjunto de três regiões. Selecione outro local secundário no grupo de regiões da América do Norte.

Requisitos de residência de dados

Clientes diferentes têm diferentes requisitos de residência de dados, portanto, é importante que você controle onde seus dados são armazenados. O Azure Monitor processa e armazena logs nas regiões primária e secundária que você escolher. Para obter mais informações, confira Regiões com suporte.

Suporte para Microsoft Sentinel e outros serviços

Vários serviços e recursos que usam espaços de trabalho do Log Analytics são compatíveis com replicação e alternância de espaços de trabalho. Esses serviços e recursos continuam funcionando quando você alterna para o workspace secundário.

Por exemplo, problemas de rede regionais que causam latência de ingestão de log podem afetar os clientes do Microsoft Sentinel. Os clientes que usam espaços de trabalho replicados podem alternar para sua região secundária para continuar trabalhando com seu espaço de trabalho do Log Analytics e do Sentinel. No entanto, se o problema de rede afetar a integridade do serviço Sentinel, mudar para outra região não atenua o problema.

Algumas experiências do Azure Monitor, incluindo Application Insights e VM Insights, atualmente são apenas parcialmente compatíveis com a replicação e transferência do workspace. Para obter a lista completa, consulte Considerações sobre implantação.

Modelo de preços

Ao habilitar a replicação de workspace, você é cobrado pela replicação de todos os dados que ingerir no seu workspace, exceto dados com _IsBillable = false.

Importante

Se você enviar dados para seu espaço de trabalho usando o Agente do Azure Monitor, a API de Ingestão de Logs, os Hubs de Eventos do Azure ou outras fontes de dados que usam regras de coleta de dados, certifique-se de associar suas regras de coleta de dados ao ponto de extremidade de coleta de dados do espaço de trabalho. Essa associação garante que os dados ingeridos sejam replicados para o espaço de trabalho secundário. Se você não associar suas regras de coleta de dados ao ponto de extremidade de coleta de dados do espaço de trabalho, você ainda será cobrado por todos os dados que ingerir em seu espaço de trabalho, mesmo que os dados não sejam replicados.

Permissões necessárias

Ação	Permissões necessárias
Habilitar a replicação do espaço de trabalho	Microsoft.OperationalInsights/workspaces/write e Microsoft.Insights/dataCollectionEndpoints/write permissões, conforme fornecido pela função interna do Colaborador de Monitoramento, por exemplo
Alternar e alternar de volta (acionar failover e failback)	Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action, e Microsoft.Insights/dataCollectionEndpoints/triggerFailback/action permissões, conforme fornecido pela função interna do Colaborador de Monitoramento, por exemplo
Verificar o estado do workspace	Microsoft.OperationalInsights/workspaces/read permissões para o espaço de trabalho do Log Analytics, conforme fornecido pela função interna do Colaborador de Monitoramento, por exemplo

Habilitar e desabilitar a replicação do espaço de trabalho

Habilite e desabilite a replicação do workspace usando um comando REST. O comando dispara uma operação de execução prolongada, o que significa que pode levar alguns minutos para que as novas configurações se apliquem. Depois de habilitar a replicação, pode levar até uma hora para que todas as tabelas (tipos de dados) comecem a ser replicadas e alguns tipos de dados podem começar a ser replicados antes de outras. As alterações feitas nos esquemas de tabela depois de habilitar a replicação do workspace - por exemplo, novas tabelas de log personalizadas ou campos personalizados criados ou logs de diagnóstico configurados para novos tipos de recursos - podem levar até uma hora para iniciar a replicação.

Usando um cluster dedicado?

Se o seu espaço de trabalho estiver vinculado a um cluster dedicado, você deverá primeiro habilitar a replicação no cluster e somente depois no espaço de trabalho. Essa operação cria um segundo cluster em sua região secundária (sem custo adicional além dos encargos de replicação), a fim de permitir que seu workspace continue usando um cluster dedicado mesmo se você fizer failover. Isso também significa que recursos como CMK (chaves gerenciadas por cluster) continuam funcionando (com a mesma chave) durante o failover. Depois que a replicação entre regiões estiver habilitada, prossiga para habilitar a replicação para um ou mais dos workspaces vinculados a esse cluster.

Importante

Depois que a replicação de cluster estiver habilitada, alterar o destino de replicação exigirá desabilitar a replicação e habilitá-la novamente em um local diferente.

Para habilitar a replicação em seu cluster dedicado, use o comando a seguir. Habilitar a replicação no cluster é uma operação de execução prolongada que pode levar tempo para ser concluída e você pode acompanhar seu estado exato, conforme explicado no estado de provisionamento do cluster Check.

Azure CLI

Para habilitar a replicação de cluster, use o comando az rest da CLI do Azure para invocar a API REST do 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 a replicação de cluster, 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>"
}

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu cluster
• <resourcegroup_name>: O grupo de recursos que contém seu recurso de cluster do Log Analytics
• <cluster_name>: O nome do seu cluster dedicado
• <primary_region>: a região primária do cluster dedicado do Log Analytics
• <secondary_region>: a região na qual o Azure Monitor cria o cluster dedicado secundário

Verificar o estado de provisionamento do cluster

Azure CLI

Para verificar o estado de provisionamento do cluster, use o comando da CLI do Azure az monitor log-analytics cluster show.

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

REST API

Para verificar o estado de provisionamento do cluster, execute 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

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu cluster
• <resourcegroup_name>: O grupo de recursos que contém seu recurso de cluster do Log Analytics
• <cluster_name>: O nome do seu cluster do Log Analytics

Use o comando para verificar se o estado de provisionamento de cluster muda de Updating para Succeeded, e a região secundária está definida conforme o esperado.

Observação

Quando você habilita a replicação de cluster, um novo cluster está sendo provisionado no local secundário. Esse processo pode levar de 1 a 2 horas.

Habilitar a replicação do espaço de trabalho

Azure CLI

Para habilitar a replicação no workspace do Log Analytics, use o comando az rest da CLI do Azure para invocar a API REST do 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 a replicação no workspace do 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>"
}

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu espaço de trabalho
• <resourcegroup_name>: O grupo de recursos que contém o recurso de workspace do Log Analytics
• <workspace_name>: O nome do seu workspace
• <primary_region>: A região principal para seu espaço de trabalho do Log Analytics
• <secondary_region>: A região na qual o Azure Monitor cria o workspace secundário

Para obter os valores de região com suporte, consulte regiões com suporte.

O comando habilitar a replicação do workspace é uma operação de execução prolongada que pode levar algum tempo para ser concluída. Você pode acompanhar o estado de provisionamento de sua solicitação, conforme descrito em Check workspace provisioning state.

Importante

Se o workspace estiver vinculado a um cluster dedicado, primeiro habilite a replicação no cluster. Observe também que o local secundário do seu workspace deve ser idêntico ao local secundário de seu cluster dedicado.

Verifique o estado de provisionamento do espaço de trabalho

Azure CLI

Para verificar o estado de provisionamento do seu workspace, use o comando da CLI do Azure az monitor log-analytics workspace show:

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

REST API

Para verificar o estado de provisionamento do workspace, execute 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

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu espaço de trabalho.
• <resourcegroup_name>: O grupo de recursos que contém o recurso de workspace do Log Analytics.
• <workspace_name>: O nome do seu espaço de trabalho do Log Analytics.

Use o comando para verificar se o estado de provisionamento do workspace muda de Updating para Succeeded, e a região secundária está definida conforme o esperado.

Observação

Quando você habilita a replicação para espaços de trabalho que interagem com o Sentinel, pode levar até 12 dias para replicar completamente os dados da Lista de Observação e da Inteligência de Ameaças para o espaço de trabalho secundário.

Verificar se a replicação está habilitada em um workspace

Para verificar se e onde a replicação do workspace está habilitada, examine essas configurações.

No portal do Azure, selecione a >Visão geral do workspace. Se a replicação estiver habilitada, a seção Essentials exibirá o local secundário, indicando a região do workspace replicado.

A mesma seção Essentials tem uma exibição JSON que exibe os detalhes de replicação como um objeto JSON, que também está disponível por meio de REST/CLI.

Associar regras de coleta de dados ao ponto de extremidade de coleta de dados do espaço de trabalho

O Agente do Azure Monitor, a API de Ingestão de Logs e os Hubs de Eventos do Azure coletam dados e os enviam para o destino especificado com base em como você configura suas regras de coleta de dados (DCR).

Se você tiver regras de coleta de dados que enviam dados para seu espaço de trabalho primário, precisará associar as regras a um sistema de ponto de extremidade de coleta de dados (DCE), que o Azure Monitor cria quando você ativa a replicação do espaço de trabalho. O nome do endpoint de coleta de dados do espaço de trabalho é idêntico ao ID do seu espaço de trabalho. Somente as regras de coleção associadas ao ponto de extremidade de coleção de dados do espaço de trabalho garantem a continuidade da ingestão durante uma falha. Esse comportamento permite que você especifique o conjunto de fluxos de log a serem replicados, o que ajuda você a controlar os custos de replicação.

Para replicar dados coletados usando regras de coleta de dados, associe suas regras de coleta de dados ao ponto de extremidade de coleta de dados do espaço de trabalho:

1. No portal do Azure, selecione Regras de coleta de dados.

2. Na tela Regras de coleta de dados, selecione uma regra de coleta de dados que envia dados para o workspace principal do Log Analytics.

3. Na página Visão geral da regra de coleta de dados, selecione Configurar DCE e selecione o ponto de extremidade de coleta de dados do espaço de trabalho na lista disponível:

   

   Para obter detalhes sobre o DCE do Sistema, verifique as propriedades do objeto da área de trabalho.

Importante

As regras de coleta de dados conectadas a um ponto de extremidade de coleta de dados do espaço de trabalho podem ter como alvo apenas esse espaço de trabalho específico. As regras de coleta de dados não devem ter como alvo outros destinos, como outros espaços de trabalho ou contas de armazenamento do Azure.

O que verificar se a replicação do espaço de trabalho falhar

• O workspace está vinculado a um cluster dedicado?
  • A replicação deve ser habilitada no cluster antes de poder ser habilitada no workspace.
  • A replicação do cluster e do espaço de trabalho deve ser definida para o mesmo local secundário. Por exemplo, se o cluster for replicado para o Norte da Europa, os workspaces vinculados a ele só poderão ser replicados para o Norte da Europa também.
• Você usou a API REST para habilitar a replicação?
  • Verifique se você usou a API versão 2025-02-01 ou posterior.
• O espaço de trabalho principal está localizado em East US, East US 2 ou South Central US?
  • Leste dos EUA, Leste dos EUA 2 e Centro-Sul dos EUA não podem se replicar entre si.
• Onde fica o espaço de trabalho principal e onde fica o secundário? Ambos os locais devem estar no mesmo grupo de regiões. Por exemplo, espaços de trabalho localizados em regiões dos EUA não podem ter uma replicação (região secundária) na Europa e vice-versa. Para obter a lista de grupos de regiões, consulte regiões com suporte.
• Você tem as permissões necessárias?
• Você permitiu tempo suficiente para a conclusão da operação de replicação? replicação é uma operação de execução longa. Monitore o estado da operação, conforme explicado no estado de provisionamento do workspace Check.
• Você tentou habilitar novamente a replicação para alterar o local secundário do espaço de trabalho? Para alterar o local do workspace secundário, primeiro desabilite a replicação do workspace, permita que a operação seja concluída e, em seguida, habilite a replicação para outro local secundário.

O que verificar se a replicação do espaço de trabalho estiver definida, mas os logs não forem replicados?

• A replicação pode levar até uma hora para começar a ser aplicada, e alguns tipos de dados podem começar a replicar antes de outros.
• Os logs ingeridos no workspace antes da replicação ser habilitada não são copiados para o workspace secundário. Somente os logs ingeridos após a habilitação de replicação são replicados.
• Se alguns logs forem replicados e outros não forem – verifique se todas as DCRs (regras de coleta de dados) que transmitem logs para o workspace estão configuradas corretamente. Para examinar os DCRs direcionados à área de trabalho, consulte a guia Coleta de Dados do Log Analytics Workspace Insights, no portal do Azure.

Desabilitar a replicação do workspace

Azure CLI

Para desabilitar a replicação de um workspace, use o comando az monitor log-analytics workspace update CLI do Azure:

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

REST API

Para desabilitar a replicação de um workspace, 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>"
}

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu espaço de trabalho.
• <resourcegroup_name>: O grupo de recursos que contém o recurso do seu espaço de trabalho.
• <workspace_name>: nome do seu espaço de trabalho.
• <primary_region>: A região principal do seu espaço de trabalho.

O comando de desabilitar replicação é uma operação de execução prolongada que pode levar algum tempo para ser concluída. Você pode acompanhar o estado de provisionamento de sua solicitação, conforme descrito em Check workspace provisioning state.

Importante

Se você estiver usando um cluster dedicado, desabilite a replicação do cluster depois de desabilitar a replicação para cada workspace vinculado a esse cluster.

Desabilitar a replicação de cluster

A desabilitação da replicação de cluster só pode ser feita depois de desabilitar a replicação para todos os workspaces vinculados a esse cluster (se habilitado anteriormente).

Azure CLI

Para desabilitar a replicação de um cluster, use o comando az monitor log-analytics cluster update da CLI do Azure:

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

REST API

Para desabilitar a replicação de um cluster, 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>"
}

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu cluster.
• <resourcegroup_name> : o grupo de recursos que contém o recurso do cluster.
• <workspace_name>: O nome do seu cluster.
• <primary_region>: a região primária do cluster.

O comando é uma operação de execução prolongada que pode levar algum tempo para ser concluída. Você pode acompanhar o estado de provisionamento de sua solicitação, conforme descrito em Check workspace provisioning state.

Observação

Depois que a replicação é desabilitada e o cluster replicado é limpo, os logs replicados são excluídos e não podem ser acessados novamente. A cópia original no seu local principal não é alterada nesse processo.

Importante

O processo de remoção da replicação de cluster leva 14 dias. Se você precisar que esse processo seja concluído mais rapidamente, crie uma solicitação de Suporte do Azure.

Monitorar o workspace e a integridade do serviço

Latência de ingestão ou falhas de consulta são exemplos de problemas que geralmente podem ser resolvidos com failover para sua região secundária. Esses problemas podem ser detectados usando notificações de saúde do serviço e consultas de log.

As notificações de Saúde do Serviço são úteis para problemas relacionados ao serviço. Para identificar problemas que afetam seu workspace específico (e possivelmente não todo o serviço), você pode usar outras medidas:

• Crie alertas com base na integridade dos recursos do espaço de trabalho

• Defina seus próprios limites para métricas de saúde do ambiente de trabalho

• Crie suas próprias consultas de monitoramento para servir como indicadores de integridade personalizados para seu workspace, conforme descrito em Monitorar o desempenho do workspace usando consultas, para:

  • Medir a latência de ingestão por tabela
  • Identificar se a origem da latência é os agentes de coleta ou o pipeline de ingestão
  • Monitorar anomalias de volume de ingestão por tabela e recurso
  • Monitorar a taxa de êxito da consulta por tabela, usuário ou recurso
  • Criar alertas com base em suas consultas

Observação

Você também pode usar consultas de log para monitorar seu espaço de trabalho secundário, mas tenha em mente que a replicação de logs é feita em processos em lote. A latência medida pode variar e não indica nenhum problema de saúde com seu espaço de trabalho secundário. Para obter mais informações, consulte Auditar o espaço de trabalho inativo.

Alternar para seu workspace secundário

Durante a alternância, a maioria das operações funciona da mesma forma que quando você usa o espaço de trabalho e a região primária. No entanto, algumas operações têm um comportamento ligeiramente diferente ou são bloqueadas. Para obter mais informações, consulte Considerações sobre implantação.

Quando devo mudar?

Você decide quando alternar para o espaço de trabalho secundário e voltar para o primário com base no monitoramento contínuo de desempenho e saúde, bem como nos padrões e requisitos do sistema.

Há vários pontos a serem considerados em seu plano de substituição, conforme descrito nas subseções a seguir.

Tipo de problema e escopo

O processo de alternância encaminha solicitações de ingestão e consulta para sua região secundária, o que geralmente ignora qualquer componente defeituoso que esteja causando latência ou falha em sua região primária. Como resultado, a mudança provavelmente não ajudará se:

• Há um problema entre regiões com um recurso subjacente. Por exemplo, se os mesmos tipos de recurso falharem em suas regiões primárias e secundárias.
• Você enfrenta um problema relacionado ao gerenciamento de espaço de trabalho, como a alteração da retenção do espaço de trabalho. As operações de gerenciamento de workspace sempre ocorrem na sua região primária. Durante a alternância, as operações de gerenciamento do espaço de trabalho são bloqueadas.

Duração do problema

A substituição não é instantânea. O processo de redirecionamento de solicitações depende de atualizações de DNS, que alguns clientes captam em minutos, enquanto outros podem levar mais tempo. Portanto, é útil entender se o problema pode ser resolvido em alguns minutos. Se o problema observado for consistente ou contínuo, não espere para mudar. Estes são alguns exemplos:

• Ingestão: Problemas com o pipeline de ingestão em sua região primária podem afetar a replicação de dados para seu workspace secundário. Durante a substituição, os logs são enviados para o pipeline de ingestão na região secundária.

• Consulta: Se as consultas no seu espaço de trabalho principal falharem ou atingirem o tempo limite, os alertas de pesquisa de log poderão ser afetados. Nesse cenário, mude para a área de trabalho secundária para garantir que todos os alertas sejam disparados corretamente.

Dados secundários do espaço de trabalho

Os logs ingeridos no workspace primário antes de habilitar a replicação não são copiados para o workspace secundário. Se você habilitou a replicação do espaço de trabalho há três horas e agora alternou para o espaço de trabalho secundário, suas consultas só poderão retornar dados das últimas três horas.

Antes de alternar regiões durante a alternância, seu espaço de trabalho secundário precisa conter um volume útil de logs. É recomendável aguardar pelo menos uma semana depois de habilitar a replicação antes de disparar a substituição. Os sete dias permitem que dados suficientes estejam disponíveis em sua região secundária.

Troca de gatilho

Antes de alternar, confirme se a operação de replicação do espaço de trabalho foi concluída com êxito. A troca só é bem-sucedida quando o espaço de trabalho secundário está configurado corretamente.

Azure CLI

Para alternar para o espaço de trabalho secundário, use o comando da CLI do Azure az monitor log-analytics workspace failover:

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

REST API

Para trocar para sua área de trabalho secundária, use 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

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu espaço de trabalho.
• <resourcegroup_name>: O grupo de recursos que contém o recurso do seu espaço de trabalho.
• <secondary_region>: A região para a qual alternar durante a substituição.
• <workspace_name>: O nome do espaço de trabalho para alternar durante a alternância.

O comando é uma operação de execução prolongada que pode levar algum tempo para ser concluída. Você pode acompanhar o estado de provisionamento de sua solicitação, conforme descrito em Check workspace provisioning state.

O que verificar se a troca (failover) falhar

• Você usou a API REST para acionar a alternância (failover)?
  • Verifique se você usou a API versão 2025-02-01 ou posterior.
  • Verifique se o local secundário fornecido no comando de failover é o local secundário definido para este workspace. Essas informações estão disponíveis na exibição do espaço de trabalho no portal do Azure e por meio da API.
• Alternar regiões requer uma função colaborador do Log Analytics no grupo de recursos do workspace e não apenas no workspace em si.

Voltar para a sua área de trabalho principal

O processo de retorno cancela o redirecionamento de consultas e solicitações de ingestão de log para o espaço de trabalho secundário. Quando você alterna de volta, o Azure Monitor volta para roteamento de consultas e solicitações de ingestão de log para seu workspace primário.

Quando você alterna para sua região secundária, o Azure Monitor replica logs do seu espaço de trabalho secundário para o seu espaço de trabalho principal. Se uma interrupção afetar o processo de ingestão de log na região primária, poderá levar tempo para que o Azure Monitor conclua a ingestão dos logs replicados para seu workspace primário.

Quando devo voltar?

Há vários pontos a serem considerados em seu plano de retorno, conforme descrito nas subseções a seguir.

Estado de replicação de log

Antes de retornar, verifique se o Azure Monitor concluiu a replicação de todos os logs ingeridos durante a alternância para a região primária. Se você retornar antes que todos os logs sejam replicados para o espaço de trabalho principal, suas consultas poderão retornar resultados parciais até que a ingestão de logs seja concluída.

Você pode consultar seu workspace primário no portal do Azure para a região inativa, conforme descrito em Auditar o workspace inativo.

Integridade do workspace primário

Há dois itens de integridade importantes para verificar a preparação para voltar ao workspace primário:

• Confirme se não há notificações pendentes de Integridade do Serviço para o workspace primário e a região.
• Confirme se seu espaço de trabalho principal está ingerindo logs e processando consultas conforme o esperado.

Para obter exemplos de como consultar seu workspace primário quando o workspace secundário estiver ativo e ignorar o redirecionamento de solicitações para seu workspace secundário, consulte Auditar o workspace inativo.

Gatilho de alternância

Antes de retornar, confirme a integridade do espaço de trabalho primário e conclua a replicação dos logs.

O processo de reversão atualiza seus registros DNS. Após a atualização dos registros DNS, pode levar tempo para que todos os clientes recebam as configurações de DNS atualizadas e retomem o roteamento para o workspace primário.

Azure CLI

Para alternar de volta para o workspace primário, use o comando az monitor log-analytics workspace failback da CLI do Azure:

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

REST API

Para voltar ao workspace primário, 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

Em que:

• <subscription_id>: O ID da assinatura relacionada ao seu espaço de trabalho.
• <resourcegroup_name>: O grupo de recursos que contém o recurso do seu espaço de trabalho.
• <workspace_name>: O nome do espaço de trabalho para alternar durante o switchback.

O comando é uma operação de execução prolongada que pode levar algum tempo para ser concluída. Você pode acompanhar o estado de provisionamento de sua solicitação, conforme descrito em Check workspace provisioning state.

Auditar o workspace inativo

Por padrão, a região ativa do workspace é a região em que você cria o workspace e a região inativa é a região secundária, em que o Azure Monitor cria o workspace replicado.

Quando você aciona o failover, isso muda – a região secundária é ativada e a região primária fica inativa. Dizemos que ele está inativo porque não é o alvo direto da ingestão de logs e solicitações de consulta.

É útil consultar a região inativa antes de alternar entre regiões para verificar se o workspace na região inativa tem os logs que você espera ver lá.

Para interagir com a região inativa, você precisa usar a API do Log Analytics do Azure Monitor. Para obter mais informações, incluindo como autenticar, consulte Acessar a API do Log Analytics do Azure Monitor.

Consultar região inativa

Para consultar dados de log na região inativa, use esse comando GET:

GET

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

Por exemplo, para executar uma consulta curta como Perf | count no último dia em sua região secundária, use:

GET

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

Você pode confirmar que o Azure Monitor executa sua consulta na região pretendida verificando esses campos na tabela LAQueryLogs, que é criada quando você habilita a auditoria de consultas em seu workspace do Log Analytics:

• isWorkspaceInFailover: Indica se o espaço de trabalho estava no modo de transição durante a consulta. O tipo de dados é booliano (True, False).
• workspaceRegion: A região do espaço de trabalho especificada pela consulta. O tipo de dados é String.

Monitorar o desempenho do workspace usando consultas

É recomendável usar as consultas nesta seção para criar regras de alerta que notifiquem você sobre possíveis problemas de desempenho ou integridade do workspace. No entanto, a decisão de mudar requer sua consideração cuidadosa e não deve ser feita automaticamente.

Na regra de consulta, você pode definir uma condição para alternar para seu espaço de trabalho secundário após um número especificado de violações. Para obter mais informações, consulte Criar ou editar uma regra de alerta de pesquisa de log.

Duas medições significativas do desempenho do espaço de trabalho incluem a latência de ingestão e o volume de ingestão. As seções a seguir exploram essas opções de monitoramento.

Monitore a latência de ingestão de ponta a ponta

A latência de ingestão mede o tempo necessário para ingerir logs no espaço de trabalho. A medida de tempo começa quando o evento registrado inicial ocorre e termina quando o log é armazenado em seu workspace. A latência total de ingestão é composta por duas partes:

• Latência do agente: O tempo necessário para que o agente informe um evento.
• Latência do pipeline de ingestão (backend): O tempo necessário para o pipeline de ingestão processar os logs e gravá-los no seu espaço de trabalho.

Tipos de dados diferentes têm latência de ingestão diferente. Você pode medir a ingestão de cada tipo de dados separadamente ou criar uma consulta genérica para todos os tipos e uma consulta mais refinada para tipos específicos que são de maior importância para você. Sugerimos que você meça o 90º percentil da latência de ingestão, que é mais sensível à alteração do que a média ou o 50º percentil (mediana).

As seções a seguir mostram como usar consultas para verificar a latência de ingestão do seu espaço de trabalho.

Avalie a latência de ingestão de base de tabelas específicas

Comece determinando a latência de linha de base de tabelas específicas ao longo de vários dias.

Esta consulta de exemplo cria um gráfico do 90º percentil de latência de ingestão na tabela 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

Depois de executar a consulta, examine os resultados e o gráfico renderizado para determinar a latência esperada para essa tabela.

Monitorar a latência de ingestão atual e alertar sobre ela

Depois de estabelecer a latência de ingestão de base para uma tabela específica, crie uma regra de alerta de pesquisa de log para a tabela com base nas alterações na latência em um curto período de tempo.

Esta consulta calcula a latência de ingestão nos ú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)

Como você pode esperar algumas flutuações, crie uma condição de regra de alerta para verificar se a consulta retorna um valor significativamente maior que a linha de base.

Determinar a origem da latência de ingestão

Ao perceber que a latência total de ingestão está aumentando, você pode usar consultas para determinar se a origem da latência são os agentes ou o pipeline de ingestão.

Essa consulta mapeia a latência do 90º percentil dos agentes e do pipeline separadamente:

// 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

Observação

Embora o gráfico exiba os dados do 90º percentil como colunas empilhadas, a soma dos dados nos dois gráficos não é igual ao 90º percentil de ingestão total.

Monitorar o volume de ingestão

As medições do volume de ingestão podem ajudar a identificar alterações inesperadas no volume de ingestão total ou específico da tabela para seu espaço de trabalho. As medidas de volume de consulta podem ajudá-lo a identificar problemas de desempenho com a ingestão de log. Algumas medidas de volume úteis incluem:

• Volume total de ingestão por tabela
• Volume de ingestão constante (paralisação)
• Anomalias de ingestão - picos e quedas no volume de ingestão

As seções a seguir mostram como usar consultas para verificar o volume de ingestão do seu espaço de trabalho.

Monitorar o volume total de ingestão por tabela

Você pode definir uma consulta para monitorar o volume de ingestão por tabela no seu espaço de trabalho. A consulta pode incluir um alerta que verifica se há alterações inesperadas no total ou em volumes específicos da tabela.

Essa consulta calcula o volume total de ingestão na última hora por tabela em megabytes por segundo (MBs):

// 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

Verificar se há paralisação de ingestão

Se você ingerir logs por meio de agentes, poderá usar a pulsação do agente para detectar conectividade. Um batimento cardíaco parado pode revelar uma interrupção na ingestão de logs no seu espaço de trabalho. Quando os dados de consulta revelam uma paralisação de ingestão, você pode definir uma condição para disparar uma resposta desejada.

A consulta a seguir verifica a pulsação do agente para detectar problemas de conectividade:

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

Monitoramento de anomalias de ingestão

Você pode identificar picos e quedas nos dados de volume de ingestão do seu espaço de trabalho de várias maneiras. Use a função series_decompose_anomalies() para extrair anomalias dos volumes de ingestão que você monitora em seu espaço de trabalho ou criar seu próprio detector de anomalias para dar suporte aos seus cenários exclusivos do espaço de trabalho.

Identificar anomalias usando "series_decompose_anomalies"

A função series_decompose_anomalies() identifica anomalias em uma série de valores de dados. Essa consulta calcula o volume de ingestão por hora de cada tabela no workspace do Log Analytics e usa series_decompose_anomalies() para identificar anomalias:

// 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 obter mais informações sobre como usar series_decompose_anomalies() para detectar anomalias nos dados de log, consulte Detectar e analisar anomalias usando recursos de aprendizado de máquina KQL no Azure Monitor.

Criar seu próprio detector de anomalias

Você pode criar um detector de anomalias personalizado para dar suporte aos requisitos do cenário para a configuração do espaço de trabalho. Esta seção fornece um exemplo para demonstrar o processo.

A consulta a seguir calcula:

• Volume de ingestão esperado: Por hora, por tabela (com base na mediana das medianas, mas você pode personalizar a lógica)
• Volume de ingestão real: por hora, por tabela

Para filtrar diferenças insignificantes entre o volume de ingestão esperado e real, a consulta aplica dois filtros:

• Taxa de alteração: Mais de 150% ou menos de 66% do volume esperado, por tabela
• Volume de alteração: indica se o volume aumentado ou reduzido é mais de 0,1% do volume mensal dessa tabela

// 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

Monitorar o êxito e a falha da consulta

Cada consulta retorna um código de resposta que indica êxito ou falha. Quando a consulta falha, a resposta também inclui os tipos de erro. Um grande aumento de erros pode indicar um problema com a disponibilidade do espaço de trabalho ou o desempenho do serviço.

Essa consulta conta quantas consultas retornaram um código de erro do servidor:

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

Conteúdo relacionado

• Monitorar a integridade do espaço de trabalho do Log Analytics
• Monitore problemas operacionais na área de trabalho do Log Analytics do Azure Monitor