Aumente a resiliência replicando seu espaço de trabalho do Log Analytics entre regiões (Visualização)

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

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

Importante

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

Permissões necessárias

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

Como funciona a replicação do espaço de trabalho do Log Analytics

O espaço de trabalho e a região originais são chamados de principais. O espaço de trabalho replicado e a região alternativa são chamados de secundários.

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

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 espaço de trabalho 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 ao seu espaço de trabalho primário para sua região secundária também. 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.

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á alternar novamente para sua região principal.

Quando você alterna, o espaço de trabalho secundário fica ativo e o principal fica inativo. 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ê ingere 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.

Importante

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 replicar os dados periodicamente.

Regiões suportadas

Atualmente, há suporte para replicação de espaços de trabalho em espaços de trabalho em um conjunto limitado de regiões, organizadas 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 suportadas no mesmo grupo de regiões que o local principal do espaço de trabalho. Por exemplo, um espaço de trabalho na Europa Ocidental pode ser replicado no Norte da Europa, mas não no Oeste dos EUA 2, uma vez que essas regiões estão em grupos de regiões diferentes.

Estes grupos de regiões e regiões são atualmente suportados:

Grupo de regiões	Regiões	Notas
América do Norte	E.U.A. Leste	Não há suporte para replicação de ou para a região Leste dos EUA 2.
	E.U.A. Leste 2	Não há suporte para replicação de ou para a região Leste dos EUA.
	E.U.A. Oeste
	E.U.A. Oeste 2
	E.U.A. Central
	E.U.A. Centro-Sul
	Canadá Central
Europa	Europa Ocidental
	Europa do Norte
	Sul do Reino Unido
	Oeste do Reino Unido
	Alemanha Centro-Oeste
	França Central

Requisitos de residência de dados

Clientes diferentes têm requisitos de residência de dados diferentes, por isso é 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, consulte Regiões suportadas.

Apoio ao 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 a replicação e a alternância do espaço de trabalho. Esses serviços e recursos continuam a funcionar quando você alterna para o espaço de trabalho secundário.

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

Algumas experiências do Azure Monitor, incluindo o Application Insights e o VM Insights, são atualmente apenas parcialmente compatíveis com a replicação e a alternância do espaço de trabalho. Para obter a lista completa, consulte Restrições e limitações.

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

Você habilita e desabilita a replicação do espaço de trabalho usando um comando REST. O comando dispara uma operação de longa duração, o que significa que pode levar alguns minutos para que as novas configurações sejam aplicadas. Depois de habilitar a replicação, pode levar até uma hora para que todas as tabelas (tipos de dados) comecem a replicar, e alguns tipos de dados podem começar a replicar antes de outros. As alterações feitas nos esquemas de tabela depois de habilitar a replicação do espaço de trabalho - 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 começar a replicar.

Importante

Atualmente, não há suporte para a replicação de espaços de trabalho do Log Analytics vinculados a um cluster dedicado.

Habilitar replicação de espaço de trabalho

Para habilitar a replicação no espaço de trabalho do Log Analytics, use este PUT comando:

PUT 

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

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

Em que:

• <subscription_id>: O ID da subscrição relacionado com a sua área de trabalho.
• <resourcegroup_name> : o grupo de recursos que contém o recurso de espaço de trabalho do Log Analytics.
• <workspace_name>: O nome do seu espaço de trabalho.
• <primary_region>: a região principal do espaço de trabalho do Log Analytics.
• <secondary_region>: A região na qual o Azure Monitor cria o espaço de trabalho secundário.

Para obter os valores suportados location , consulte Regiões suportadas.

O PUT comando é uma operação de longa duração que pode levar algum tempo para ser concluída. Uma chamada bem-sucedida retorna um código de 200 status. Você pode acompanhar o estado de provisionamento da sua solicitação, conforme descrito em Verificar estado de provisionamento da solicitação.

Verificar o estado de provisionamento da solicitação

Para verificar o estado de provisionamento da sua solicitação, execute este GET comando:

GET

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

Em que:

• <subscription_id>: O ID da subscrição relacionado com a sua área de trabalho.
• <resourcegroup_name>: o grupo de recursos que contém o recurso de espaço de trabalho do Log Analytics.
• <workspace_name>: O nome do seu espaço de trabalho do Log Analytics.

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

Nota

Quando você habilita a replicação para espaços de trabalho que interagem com o Sentinel, pode levar até 12 dias para replicar totalmente os dados da Lista de observação e do Threat Intelligence para o espaço de trabalho secundário.

Associar regras de coleta de dados ao ponto de extremidade de coleta de dados do sistema

Você usa regras de coleta de dados (DCR) para coletar dados de log usando o Azure Monitor Agent e a API de ingestão de logs.

Se você tiver regras de coleta de dados que enviam dados para seu espaço de trabalho principal, precisará associá-las a um ponto de extremidade de coleta de dados do sistema (DCE), que o Azure Monitor cria quando você habilita a replicação de espaço de trabalho. O nome do ponto de extremidade de coleta de dados do sistema é idêntico ao ID do espaço de trabalho. Somente as regras de coleta de dados associadas ao ponto de extremidade de coleta de dados do sistema do espaço de trabalho permitem a replicação e a alternância. Esse comportamento permite especificar o conjunto de fluxos de log a serem replicados, o que ajuda a controlar os custos de replicação.

Para replicar os dados coletados usando regras de coleta de dados, associe suas regras de coleta de dados ao ponto de extremidade de coleta de dados do sistema para seu espaço de trabalho do Log Analytics:

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 envie dados para seu espaço de trabalho 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 sistema na lista disponível:

   Para obter detalhes sobre o DCE do sistema, verifique as propriedades do objeto do espaço de trabalho.

Importante

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

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

Para desabilitar a replicação de um espaço de trabalho, use este PUT comando:

PUT 

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

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

Em que:

• <subscription_id>: O ID da subscrição relacionado com a sua área de trabalho.
• <resourcegroup_name> : O grupo de recursos que contém o recurso de espaço de trabalho.
• <workspace_name>: O nome do seu espaço de trabalho.
• <primary_region>: A região principal do seu espaço de trabalho.

O PUT comando é uma operação de longa duração que pode levar algum tempo para ser concluída. Uma chamada bem-sucedida retorna um código de 200 status. Você pode acompanhar o estado de provisionamento da sua solicitação, conforme descrito em Verificar estado de provisionamento da solicitação.

Monitorar a integridade do espaço de trabalho e do serviço

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

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

• Criar alertas com base na integridade do recurso do espaço de trabalho
• Definir seus próprios limites para métricas de integridade do espaço de trabalho
• Crie suas próprias consultas de monitoramento para servir como indicadores de integridade personalizados para seu espaço de trabalho, conforme descrito em Monitorar o desempenho do espaço de trabalho usando consultas, para:
  • Medir a latência de ingestão por tabela
  • Identificar se a fonte de latência são 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 sucesso da consulta por tabela, usuário ou recurso
  • Crie alertas com base nas suas consultas

Nota

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

Alternar para o espaço de trabalho 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 principais. No entanto, algumas operações têm um comportamento ligeiramente diferente ou são bloqueadas. Para obter mais informações, consulte Restrições e limitações.

Quando devo mudar?

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

Há vários pontos a considerar no seu plano de transição, conforme descrito nas subsecções seguintes.

Tipo de problema e âmbito

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

• Há um problema inter-regional com um recurso subjacente. Por exemplo, se os mesmos tipos de recursos falharem nas regiões primária e secundária.
• Você enfrenta um problema relacionado ao gerenciamento do espaço de trabalho, como alterar a retenção do espaço de trabalho. As operações de gerenciamento de espaço de trabalho são sempre tratadas em sua região principal. Durante a transição, as operações de gerenciamento do espaço de trabalho são bloqueadas.

Duração da emissão

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

• Ingestão: problemas com o pipeline de ingestão na região principal podem afetar a replicação de dados para o espaço de trabalho secundário. Durante a transição, os logs são enviados para o pipeline de ingestão na região secundária.

• Consulta: Se as consultas no espaço de trabalho principal falharem ou expirarem, os alertas de pesquisa de log poderão ser afetados. Nesse cenário, alterne para o espaço de trabalho secundário para garantir que todos os alertas sejam acionados corretamente.

Dados do espaço de trabalho secundário

Os logs ingeridos no espaço de trabalho principal antes de habilitar a replicação não são copiados para o espaço de trabalho secundário. Se você habilitou a replicação do espaço de trabalho há três horas e agora alterna 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, o espaço de trabalho secundário precisa conter um volume útil de logs. Recomendamos aguardar pelo menos uma semana após habilitar a replicação antes de acionar a alternância. Os sete dias permitem que dados suficientes estejam disponíveis na sua região secundária.

Mudança de gatilho

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

Para alternar para o espaço de trabalho secundário, use este POST comando:

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

Em que:

• <subscription_id>: O ID da subscrição relacionado com a sua área de trabalho.
• <resourcegroup_name> : O grupo de recursos que contém o recurso de espaço de trabalho.
• <secondary_region>: A região para a qual mudar durante a transição.
• <workspace_name>: O nome do espaço de trabalho para o qual alternar durante a alternância.

O POST comando é uma operação de longa duração que pode levar algum tempo para ser concluída. Uma chamada bem-sucedida retorna um código de 202 status. Você pode acompanhar o estado de provisionamento da sua solicitação, conforme descrito em Verificar estado de provisionamento da solicitação.

Voltar ao espaço de trabalho principal

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

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

Quando devo voltar atrás?

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

Estado de replicação do log

Antes de voltar, verifique se o Azure Monitor concluiu a replicação de todos os logs ingeridos durante a transição para a região primária. Se você voltar 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 espaço de trabalho principal no portal do Azure para a região inativa, conforme descrito em Auditar o espaço de trabalho inativo.

Integridade do espaço de trabalho primário

Há dois itens de integridade importantes para verificar na preparação para alternar de volta para seu espaço de trabalho principal:

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

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

Switchback de gatilho

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

O processo de switchback 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 espaço de trabalho principal.

Para voltar ao espaço de trabalho principal, use este POST comando:

POST

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

Em que:

• <subscription_id>: O ID da subscrição relacionado com a sua área de trabalho.
• <resourcegroup_name> : O grupo de recursos que contém o recurso de espaço de trabalho.
• <workspace_name>: O nome do espaço de trabalho para o qual alternar durante a alternância.

O POST comando é uma operação de longa duração que pode levar algum tempo para ser concluída. Uma chamada bem-sucedida retorna um código de 202 status. Você pode acompanhar o estado de provisionamento da sua solicitação, conforme descrito em Verificar estado de provisionamento da solicitação.

Auditar o espaço de trabalho inativo

Por padrão, a região ativa do seu espaço de trabalho é a região onde você cria o espaço de trabalho e a região inativa é a região secundária, onde o Azure Monitor cria o espaço de trabalho 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 espaço de trabalho na região inativa tem os logs que você espera ver lá.

Consultar região inativa

Para consultar dados de log na região inativa, 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 exemplo, para executar uma consulta simples como Perf | count a do dia anterior na 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 se o Azure Monitor executa sua consulta na região pretendida verificando estes campos na tabela, que é criada quando você habilita a LAQueryLogs auditoria de consulta em seu espaço de trabalho do Log Analytics:

• isWorkspaceInFailover: Indica se o espaço de trabalho estava no modo de alternância durante a consulta. O tipo de dados é booleano (True, False).
• workspaceRegion: A região do espaço de trabalho alvo da consulta. O tipo de dados é String.

Monitorar o desempenho do espaço de trabalho usando consultas

Recomendamos usar as consultas nesta seção para criar regras de alerta que o notifiquem sobre possíveis problemas de integridade ou desempenho do espaço de trabalho. No entanto, a decisão de mudar requer uma consideração cuidadosa e não deve ser tomada automaticamente.

Na regra de consulta, você pode definir uma condição para alternar para o 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 latência de ingestão e 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 medição de tempo começa quando o evento inicial registrado ocorre e termina quando o log é armazenado em seu espaço de trabalho. A latência total de ingestão é composta por duas partes:

• Latência do agente: o tempo necessário pelo agente para relatar um evento.
• Latência do pipeline de ingestão (back-end): o tempo necessário para o pipeline de ingestão processar os logs e gravá-los em seu espaço de trabalho.

Diferentes tipos de dados têm latência de ingestão diferente. Você pode medir a ingestão para 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 meça o percentil 90 da latência de ingestão, que é mais sensível à mudança do que a média ou o percentil 50 (mediana).

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

Avaliar a latência de ingestão basal de tabelas específicas

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

Esta consulta de exemplo cria um gráfico do percentil 90 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, revise os resultados e o gráfico renderizado para determinar a latência esperada para essa tabela.

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

Depois de estabelecer a latência de ingestão da linha de base para uma tabela específica, crie uma regra de alerta de pesquisa de log para a tabela com base em alterações na latência durante 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 do que a linha de base.

Determinar a origem da latência de ingestão

Quando notar 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.

Esta consulta traça a latência do percentil 90 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

Nota

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

Monitorizar 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 o seu espaço de trabalho. As medições de volume de consulta podem ajudá-lo a identificar problemas de desempenho com a ingestão de logs. Algumas medições de volume úteis incluem:

• Volume total de ingestão por tabela
• Volume de ingestão constante (imobilizaçã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.

Monitorizar o volume total de ingestão por tabela

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

Esta 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 a ingestão está parada

Se você ingerir logs por meio de agentes, poderá usar a pulsação do agente para detetar conectividade. Um batimento cardíaco ainda pode revelar uma parada na ingestão de logs para o seu espaço de trabalho. Quando os dados da 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 detetar problemas de conectividade:

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

Monitorizar 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 crie seu próprio detetor de anomalias para dar suporte aos cenários exclusivos do espaço de trabalho.

Identificar anomalias usando series_decompose_anomalies

A series_decompose_anomalies() função identifica anomalias em uma série de valores de dados. Essa consulta calcula o volume de ingestão por hora de cada tabela no espaço de trabalho 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 detetar anomalias em dados de log, consulte Detetar e analisar anomalias usando recursos de aprendizado de máquina KQL no Azure Monitor.

Crie o seu próprio detetor de anomalias

Você pode criar um detetor de anomalias personalizado para dar suporte aos requisitos de 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 variação: Mais de 150% ou menos de 66% do volume esperado, por tabela
• Volume de variação: indica se o volume aumentado ou diminuído é superior a 0,1% do volume mensal desse quadro

// 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 sucesso e a falha da consulta

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

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

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

Restrições e limitações

• Atualmente, não há suporte para a replicação de espaços de trabalho do Log Analytics vinculados a um cluster dedicado.

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

• Atualmente, não há suporte para a replicação de regras de alerta entre regiões. Como o Azure Monitor dá suporte à consulta da região inativa, os alertas baseados em consulta continuam a funcionar 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.

• Quando você habilita a replicação para espaços de trabalho que interagem com o Sentinel, pode levar até 12 dias para replicar totalmente os dados da Lista de observação e do Threat Intelligence para o espaço de trabalho secundário.

• Durante a transição, as operações de gerenciamento de espaço de trabalho não são suportadas, incluindo:

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

• O recurso de direcionamento de solução do agente herdado do Log Analytics não é suportado durante a transição. Portanto, durante a transição, os dados da solução são ingeridos de todos os agentes.

• 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 adesivas" e podem levar mais tempo para pegar o DNS atualizado. Durante a transição, esses clientes podem tentar ingerir logs através da região primária por algum tempo. Você pode estar ingerindo logs em seu espaço de trabalho principal usando vários clientes, incluindo o Log Analytics Agent herdado, o Azure Monitor Agent, o código (usando a API de Ingestão de Logs ou a API de coleta de dados HTTP herdada) e outros serviços, como o Sentinel.

• Estes recursos não são suportados atualmente ou apenas parcialmente suportados:

  Caraterística	Suporte
  Planos de mesa auxiliares	Não suportado. 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 são protegidos contra perda de dados no caso de uma falha regional e não estão disponíveis quando você alterna para o espaço de trabalho secundário.
  Pesquisar empregos, Restaurar	Parcialmente suportado - Tarefas de pesquisa e operações de restauração, criam tabelas e preenchem-nas com resultados de pesquisa ou dados restaurados. Depois de habilitar a replicação do espaço de trabalho, as novas tabelas criadas para essas operações serão replicadas para o espaço de trabalho secundário. As tabelas preenchidas antes de habilitar a replicação não são replicadas. Se essas operações estiverem em andamento quando você mudar, o resultado será inesperado. Ele pode ser concluído com êxito, mas não replicado, ou pode falhar, dependendo da integridade do seu espaço de trabalho e do tempo exato.
  Espaços de trabalho do Application Insights sobre o Log Analytics	Não suportado
  Informações de VMs	Não suportado
  Container Insights	Não suportado
  Ligações privadas	Não suportado durante failover

Conteúdos relacionados

• Monitorar a integridade do espaço de trabalho do Log Analytics
• Monitorar problemas operacionais em seu espaço de trabalho do Azure Monitor Log Analytics