Aprimorar a resiliência replicando seu workspace do Log Analytics entre regiões (versão prévia)

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 replicar seu workspace, como alternar e voltar e como decidir quando alternar entre seus workspaces replicados.

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

Permissões necessárias

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

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

Seu workspace e região originais são conhecidos como o primário. O workspace replicado e a região alternativa são chamados de secundário.

O processo de replicação do workspace cria uma instância do workspace 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 workspace secundário é um workspace "sombra" somente 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 workspace, o Azure Monitor envia novos logs ingeridos para seu workspace primário para sua região secundária também. Os logs ingeridos no workspace antes de habilitar a replicação do workspace 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 reduzir a interrupção e seu workspace primário estiver íntegro novamente, você poderá alternar novamente para sua região primária.

Quando você alterna, o workspace secundário fica ativo e o primário 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ê 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.

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	Observações
América do Norte	Leste dos EUA	Não há suporte para a replicação de ou para a região Leste dos EUA 2.
	Leste dos EUA 2	Não há suporte para a replicação de ou para a região Leste dos EUA.
	Oeste dos EUA
	Oeste dos EUA 2
	Centro dos EUA
	Centro-Sul dos Estados Unidos
	Centro do Canadá
Europa	Europa Ocidental
	Norte da Europa
	Sul do Reino Unido
	Oeste do Reino Unido
	Centro-Oeste da Alemanha
	França Central

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 Sentinel e outros serviços

Vários serviços e recursos que usam workspaces do Log Analytics são compatíveis com a replicação e a alternância do workspace. 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 Sentinel. Os clientes que usam workspaces replicados podem alternar para sua região secundária para continuar trabalhando com o workspace 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 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 a substituição do workspace. Para obter a lista completa, consulte Restrições e limitações.

Habilitar e desabilitar a replicação do workspace

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.

Habilitar a replicação do workspace

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=2023-01-01-preview

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

Onde:

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

Para obter os valores de location com suporte, consulte Regiões com suporte.

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

Verificar o estado de provisionamento de solicitação

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

GET

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

Onde:

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

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

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 Agente do Azure Monitor 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 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 ponto de extremidade de coleta de dados do sistema é idêntico à ID do workspace. Somente as regras de coleta de dados associadas ao ponto de extremidade de coleta de dados do sistema do workspace habilitam a replicação e a substituição. 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 sistema para seu workspace 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 envia dados para o workspace principal do Log Analytics.

3. Na página Visão geral 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 workspace.

Desabilitar a replicação do workspace

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=2023-01-01-preview

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

Onde:

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

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

Monitorar o workspace e a integridade do serviço

A latência de ingestão ou falhas de consulta são exemplos de problemas que geralmente podem ser tratados com failover para sua região secundária. Esses problemas podem ser detectados 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 workspace específico (e possivelmente não todo o serviço), você pode usar outras medidas:

• Criar alertas com base na integridade do recurso do workspace
• Definir seus próprios limites para métricas de integridade do workspace
• 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

Alternar para seu workspace secundário

Durante a substituição, a maioria das operações funciona da mesma forma que quando você usa o workspace primário e a região. 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 workspace secundário e voltar para o workspace primário com base no monitoramento contínuo de desempenho e integridade e 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 substituição roteia a ingestão e solicitações de consulta para sua região secundária, o que geralmente ignora qualquer componente com falha que esteja causando latência ou falha em sua região primária. Como resultado, a alternância 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 workspace, como a alteração da retenção do workspace. As operações de gerenciamento de workspace são sempre tratadas em sua região primária. Durante a substituição, as operações de gerenciamento de workspace 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 aguarde para alternar. 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 em seu workspace primário falharem ou o tempo limite, os alertas de pesquisa de log poderão ser afetados. Nesse cenário, alterne para o workspace secundário para garantir que todos os alertas sejam disparados corretamente.

Dados secundários do workspace

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 workspace há três horas e agora alternar para o workspace secundário, suas consultas só poderão retornar dados das últimas três horas.

Antes de alternar regiões durante a substituição, seu workspace 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.

Ativar a alternância

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

Para alternar para o workspace secundário, 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=2023-01-01-preview

Onde:

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

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

Voltar para seu workspace primário

O processo de alternância cancela o redirecionamento de consultas e solicitações de ingestão de log para o workspace 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 workspace secundário para o workspace primário. 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 alternância, conforme descrito nas subseções a seguir.

Estado de replicação de log

Antes de voltar, 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ê alternar de volta antes que todos os logs sejam replicados para o workspace primário, suas consultas poderão retornar resultados parciais até que a ingestão de log 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 o workspace primário 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 voltar, confirme a Integridade do espaço de trabalho primário e conclua a replicação dos logs.

O processo de alternância 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.

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=2023-01-01-preview

Onde:

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

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

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 ela está inativa porque não é o destino direto das solicitações de consulta e ingestão de log.

É ú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á.

Região inativa de consulta

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 simples 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 workspace estava no modo de substituição durante a consulta. O tipo de dados é booliano (True, False).
• workspaceRegion: A região do workspace direcionada 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 o workspace 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.

Monitorar 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 workspace. 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 (back-end): O tempo necessário para que o pipeline de ingestão processe os logs e os grave 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 workspace.

Avaliar a latência de ingestão de linha 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 e alertar sobre a latência de ingestão atual

Depois de estabelecer a latência de ingestão de linha de base para uma tabela específica, criar 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 que a linha de base.

Determinar a origem da latência de ingestão

Quando você observar que a latência total de ingestão está aumentando, você pode usar consultas para determinar se a origem da latência é 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

Monitorar o volume de ingestão

As medidas de volume de ingestão podem ajudar a identificar alterações inesperadas no volume de ingestão total ou específico da tabela para seu workspace. 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 workspace.

Monitorar o volume total de ingestão por tabela

Você pode definir uma consulta para monitorar o volume de ingestão por tabela em seu workspace. 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 a conectividade. Uma pulsação ainda pode revelar uma parada na ingestão de logs para seu workspace. 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

Monitorar anomalias de ingestão

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

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 de cenário para a configuração do workspace. 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. Uma alta onda de erros pode indicar um problema com a disponibilidade do workspace 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

Restrições e limitações

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

• 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á.

• 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 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.

• Quando você habilita a replicação para workspaces que interagem com o Sentinel, pode levar até 12 dias para replicar totalmente os dados de Watchlist e Inteligência contra Ameaças para o workspace secundário.

• Durante a substituição, não há suporte para operações de gerenciamento de workspace, incluindo:

  • Alterar a retenção do workspace, o tipo de preço, o limite diário e assim por diante
  • Alterar configurações de rede
  • Alterar o 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

• Não há suporte para a funcionalidade de direcionamento da solução do agente herdado do Log Analytics durante a substituição. Portanto, durante a substituiçã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 autoadesivas" e podem levar mais tempo para pegar o DNS atualizado pelo DNS. Durante a substituição, esses clientes podem tentar ingerir logs pela região primária por algum tempo. Você pode estar ingerindo logs em seu workspace primário usando vários clientes, incluindo o Agente herdado do Log Analytics, o Agente do Azure Monitor, 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.

• 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 workspace 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 compatível – as operações de trabalho de pesquisa e restauração criam tabelas e as populam 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ê alternar, 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 workspaces do Log Analytics	Sem suporte
  Insights da VM	Sem suporte
  Insights do contêiner	Sem suporte
  Links privados	Não há suporte durante o failover

Conteúdo relacionado

• Monitorar a integridade do workspace do Log Analytics
• Monitorar problemas operacionais no workspace do Log Analytics do Azure Monitor