Fiabilidade no Azure Monitor Logs

Azure Monitor Logs é uma plataforma centralizada de software como serviço (SaaS) para recolher, analisar e atuar sobre dados gerados pelo sistema a partir de recursos e aplicações Azure e não Azure.

Quando se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft disponibiliza uma variedade de capacidades para apoiar a resiliência e a recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

O Azure Monitor Logs oferece funcionalidades de resiliência incorporadas que protegem os seus dados e minimizam perturbações. Este artigo descreve como pode usar essas funcionalidades para tornar os seus espaços de trabalho Log Analytics resilientes a vários potenciais cortes e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais.

Recomendações de implantação de produção

O Azure Monitor Logs oferece várias funcionalidades que pode usar individualmente ou em combinação para ajudar a aumentar a resiliência do espaço de trabalho face a vários tipos de problemas.

Para informações detalhadas sobre preços, consulte os preços do Azure Monitor.

Certas funcionalidades do Log Analytics não são compatíveis com todas as funcionalidades de fiabilidade. Por exemplo, a replicação da área de trabalho não suporta tabelas auxiliares. Para detalhes sobre compatibilidade de funcionalidades, consulte Melhores práticas de fiabilidade para Log Analytics.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

Quando usa o Azure Monitor Logs, implementa um espaço de trabalho Log Analytics, que é um armazenamento de dados capaz de recolher qualquer tipo de dados de log.

Os espaços de trabalho do Log Analytics estão associados a um cluster, que fornece os recursos computacionais para os espaços de trabalho e outras funcionalidades. A maioria dos espaços de trabalho corre num cluster partilhado, que vários clientes usam ao mesmo tempo. A Microsoft implementa e gere clusters partilhados. Pode, opcionalmente, implementar um cluster dedicado, que fornece recursos dedicados para o seu espaço de trabalho. Clusters partilhados e dedicados têm características de fiabilidade diferentes. As diferenças são descritas ao longo deste artigo.

O Azure Monitor Logs tem dois caminhos de dados distintos, cada um com as suas próprias características de fiabilidade:

• Ingestion é o caminho pelo qual os dados de registo fluem para um espaço de trabalho Log Analytics. O serviço Azure Monitor só confirma a receção dos dados depois de os gravar de forma durável no armazenamento. O caminho de ingestão inclui vários componentes:

  • As fontes de dados geram telemetria. Algumas fontes, como os registos da plataforma Azure, submetem os dados diretamente para o serviço Azure Monitor através das definições de diagnóstico. Outras fontes exigem um agente para recolher e encaminhar dados. As suas aplicações também podem usar a API de Ingestão Logs para enviar logs diretamente para Azure Monitor.

  • As regras de recolha de dados (DCRs) definem quais os dados a recolher, como os transformar e para onde os enviar. Os DCRs encaminham dados para o serviço Azure Monitor através de um endpoint de recolha de dados (DCE).

• A consulta é o caminho pelo qual recupera e analisa os dados armazenados no espaço de trabalho. As consultas de registo utilizam a Linguagem de Consulta Kusto (KQL) e são executadas sobre os dados armazenados do espaço de trabalho.

A ingestão e a consulta são tratadas como operações de serviço distintas, pelo que uma perturbação numa não afeta necessariamente a outra. Por exemplo, durante uma degradação no processo de ingestão, pode ainda conseguir consultar dados previamente ingeridos. De forma semelhante, um problema do lado da consulta não impede que novos dados sejam ingeridos e armazenados.

Para mais informações sobre os componentes principais do Azure Monitor Logs, consulte Visão geral dos Azure Monitor Logs.

Arquitetura física

Internamente, o Azure Monitor Logs utiliza múltiplas réplicas tanto dos componentes computacionais como de armazenamento dos dados de log. A Microsoft gere estas réplicas, e não precisas de as configurar ou gerir.

És responsável por implementar e gerir agentes, bem como pela fiabilidade dos recursos de computação em que eles correm.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Considere os seguintes tipos de falhas transitórias no Azure Monitor Logs:

• Falhas transitórias no serviço Azure Monitor: O serviço Azure Monitor verifica se cada registo foi ingerido com sucesso no espaço de trabalho antes de ser removido do processo de ingestão. Se a ingestão não estiver disponível ou restringir as solicitações, as definições de diagnóstico e os Agentes do Azure Monitor armazenam os dados localmente e tentam reenviá-los durante várias horas, com atraso exponencial para evitar sobrecarregar o serviço. Por outro lado, uma aplicação personalizada que submete pedidos de ingestão ou consultas deve implementar a sua própria lógica de tentativa de repetição.

• Falhas transitórias que afetam a conectividade de ingestão: Os agentes e as definições de diagnóstico do Azure armazenam os dados localmente e tentam novamente a entrega quando o ponto final de ingestão está temporariamente indisponível, o que torna o percurso de ingestão mais resiliente a falhas transitórias.

• Falhas transitórias que afetam o registo personalizado de aplicações: Para validar que a sua aplicação personalizada está a lidar corretamente com erros transitórios, monitorize estas métricas:

  • Latência de ingestão
  • Falha na contagem de ingestão
  • Falhas nas exportações
  • Taxa de falha da consulta

  Uma latência de ingestão sustentada que dura mais de cinco minutos pode indicar um problema mais significativo e não transitório. Consulte as orientações nas outras secções deste documento para compreender como ser resiliente a outros tipos de falhas.

• Falhas transitórias durante consultas e outras operações: Se ocorrerem falhas transitórias durante consultas ou ao realizar outras operações, os clientes são responsáveis por tentar novamente.

Resiliência a falhas na zona de disponibilidade

Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Azure Monitor Logs oferece dois tipos de suporte para zonas de disponibilidade, dependendo da região e do tipo de cluster do seu espaço de trabalho:

• A resiliência dos dados proporciona redundância de zonas para os seus dados de registo ao replicá-los em múltiplas zonas de disponibilidade.

  A resiliência dos dados está disponível em todas as regiões que suportam zonas de disponibilidade. A maioria das regiões que suportam zonas de disponibilidade exige que o seu espaço de trabalho seja implementado num cluster dedicado. No entanto, algumas regiões suportam-no usando a configuração padrão de espaço de trabalho de um cluster partilhado. Mover para um cluster dedicado em uma região que ofereça suporte a zonas de disponibilidade protege os dados ingeridos após a mudança, não os dados históricos.

• A resiliência do serviço proporciona redundância de zona para ingestão e continuidade de consultas durante uma interrupção de zona de disponibilidade.

  Apenas algumas regiões oferecem resiliência de serviço.

Se um incidente afetar uma zona, a Microsoft gere automaticamente o failover para uma zona de disponibilidade diferente na região. Você não precisa fazer nada, pois alternar entre zonas é sem interrupções.

Requisitos

• Apoio regional: Consulte as regiões suportadas por zonas de disponibilidade para a lista de regiões que suportam resiliência de dados, resiliência de serviços e resiliência de dados em clusters partilhados e dedicados.

• Cluster dedicado: Algumas regiões requerem um cluster dedicado para a resiliência dos dados.

Considerações

• Ingestão de Event Hubs: Em algumas regiões, a ingestão dos Event Hubs no espaço de trabalho não é resiliente a uma falha na zona. Para uma lista destas regiões, consulte as notas de rodapé na lista de regiões suportadas. Avaliar caminhos alternativos de ingestão para dados críticos.

• Mudança para clusters dedicados: Clusters dedicados apenas protegem dados novos. Quando um espaço de trabalho passa para um cluster dedicado, os dados previamente ingeridos permanecem no cluster partilhado. Tudo está disponível em condições normais de funcionamento. Durante uma falha de zona, no entanto, pode só conseguir aceder aos novos dados no cluster dedicado.

Custo

A redundância de zonas não afeta os preços. Os espaços de trabalho em clusters partilhados são cobrados ao preço padrão dos espaços de trabalho, e os espaços de trabalho em clusters dedicados devem cumprir o nível de compromisso do cluster. Nenhum dos modelos de preços muda quando ativas a redundância de zonas. Para mais informações sobre preços, consulte preços do Azure Monitor.

Configurar o suporte à zona de disponibilidade

Para espaços de trabalho que usam clusters partilhados, quando cria um espaço de trabalho numa região que suporta zonas de disponibilidade para o Azure Monitor Logs, o serviço ativa automaticamente a redundância de zonas.

Se a região exigir um cluster dedicado para suporte de zonas, implemente o cluster dedicado e depois ligue o espaço de trabalho ao cluster dedicado.

Planejamento e gerenciamento de capacidade

Durante uma falha de zona, o seu espaço de trabalho pode enfrentar uma maior carga devido à ingestão e às tentativas de consulta. Se a sua solução for sensível a atrasos na ingestão de logs ou consultas, mesmo durante e após uma falha de zona, considere sobreabastecer a capacidade de quaisquer limites diários que configure no seu espaço de trabalho. Para clusters dedicados, selecione um nível de compromisso que permita picos temporários de ingestão. Para obter mais informações, consulte Gerenciar a capacidade por excesso de provisionamento.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um espaço de trabalho do Log Analytics tem redundância entre zonas e todas as zonas estão operacionais.

• Operação entre zonas: Para clusters com resiliência de serviço, tanto a ingestão quanto as consultas podem utilizar infraestrutura em qualquer zona. O serviço distribui automaticamente o trabalho entre zonas, otimizando para localidade e carga.

• Replicação de dados entre zonas: Para clusters com resiliência de dados, o serviço Azure Monitor compromete todas as escritas em múltiplas réplicas em zonas separadas antes de dar confirmação.

Comportamento durante uma falha de zona

Esta secção descreve o que pode esperar quando um espaço de trabalho do Log Analytics tem redundância entre zonas e ocorre uma falha numa das zonas.

• Deteção e resposta: A plataforma deteta uma falha de zona e responde automaticamente. Para clusters com resiliência de serviço, a plataforma realoca a capacidade de ingestão e de processamento de consultas para zonas sobreviventes. Para clusters com resiliência de dados, a plataforma passa a usar réplicas em zonas saudáveis. Não é necessário iniciar um failover de zona.

• Notificação: A Microsoft não o/a notifica automaticamente quando uma zona está indisponível. No entanto, pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health alerts para o notificar de problemas.

  Também pode monitorizar as métricas de saúde do espaço de trabalho e procurar latência de ingestão sustentada ou taxa elevada de falha nas consultas. Pode configurar alertas com base nestas métricas.

• Pedidos ativos: Durante uma interrupção de zona, quaisquer pedidos ativos podem falhar.

  Quaisquer consultas ativas podem ser terminadas. Os clientes podem tentar novamente as questões.

  Para clusters que não têm resiliência de serviço, o serviço Azure Monitor pode deixar de processar dados que não estão comprometidos. Agentes ou aplicações cliente podem tentar novamente quando a zona estiver saudável.

• Perda de dados esperada: Para clusters com resiliência de dados, não se espera perda de dados para dados totalmente comprometidos. O agente ou as aplicações do cliente precisam de tentar novamente lotes não confirmados.

• Tempo de inatividade previsto: Para clusters com resiliência de serviço, não se espera tempo de inatividade. Podem ocorrer aumentos temporários de latência ou controlo de rendimento à medida que o serviço reequilibra a infraestrutura entre zonas.

• Reencaminhamento: Para clusters com resiliência de serviço, balanceadores de carga internos dentro do serviço Azure Monitor Logs redirecionam o tráfego para nós de zona saudáveis. Não é necessária qualquer alteração de endpoint.

Recuperação de zona

Quando uma zona de disponibilidade recupera, o Azure Monitor Logs reintegra automaticamente a zona na topologia de serviço ativo. A zona recuperada começa a processar pedidos de ingestão e consulta em paralelo com as outras zonas. Os dados replicados para as zonas sobreviventes durante a interrupção mantêm-se intactos, e a replicação síncrona normal recomeça em todas as zonas. Você não precisa tomar medidas para recuperação e reintegração de zona.

Teste de falhas de zona

O Azure gere o encaminhamento de tráfego, o failover e a recuperação de zonas para falhas de zona, por isso não precisa de validar processos de falha de zona de disponibilidade nem fornecer mais informações.

Resiliência a falhas em toda a região

O Azure Monitor Logs suporta cenários de múltiplas regiões através da replicação do espaço de trabalho.

Duplicação de espaço de trabalho

A replicação do espaço de trabalho cria um espaço de trabalho secundário numa região secundária suportada e depois replica assíncronamente novos registos, bem como alterações de esquema e configuração. Os dados que existiam antes da configuração da replicação não são preenchidos.

Não vês o espaço de trabalho secundário como um recurso separado e gerível. Acedes a ela através do mesmo endpoint de recursos de espaço de trabalho.

Se a região principal falhar, tem de ativar uma transição usando uma API. A mudança redireciona a ingestão e as consultas para o espaço de trabalho secundário. Não há failover automático. A transição é uma decisão manual. Tem de ser acionado um switchback iniciado pelo cliente para restaurar o sistema primário.

Esta secção resume aspetos importantes da replicação em espaços de trabalho. Consulte a documentação completa para entender exatamente como funciona. Para mais informações, consulte Aumente a resiliência replicando o seu espaço de trabalho de Log Analytics entre regiões.

Requisitos

• Apoio regional: A replicação de workspace requer a seleção de uma região secundária dentro do mesmo grupo de regiões. Algumas combinações de regiões não podem apontar diretamente umas para as outras. Para pares primários e secundários permitidos e grupos regionais, veja Regiões suportadas. Se a região do teu espaço de trabalho não estiver listada, atualmente não suporta replicação.

• Clusters dedicados: Se o seu espaço de trabalho estiver ligado a um cluster dedicado, ative primeiro a replicação no cluster.

Considerações

• Regras de alerta de pesquisa de registo: Depois de mudar entre regiões, as regras de alerta de pesquisa de registo continuam a funcionar, a menos que o serviço de alertas na região ativa não esteja a funcionar corretamente ou as regras de alerta não estejam disponíveis. Esta condição pode acontecer, por exemplo, se a região onde as regras de alerta foram criadas estiver completamente desativada. A replicação das regras de alerta entre regiões não é feita automaticamente como parte da replicação do workspace, mas pode replicá-las. Por exemplo, podes exportar regras de alerta da região principal para a secundária.

• Alternância manual e retorno manual: Você é responsável por decidir quando alternar e retornar, e por acionar as ações de alternância e retorno.

  Para se preparar para uma falha de região, deve seguir os seguintes passos:

  • Estabelecer monitorização (saúde de replicação, latência de ingestão, métricas de saúde do espaço de trabalho) para a região ativa. Audite a região do espaço de trabalho inativo antes de uma transição.
  • Considere se deve criar runbooks para definir critérios de transição, que podem fazer parte do seu planeamento de recuperação de desastres. Por exemplo, pode monitorizar a latência de ingestão a nível regional, incumprimentos dos objetivos de nível de serviço (SLO), taxas sustentadas de falha de consultas ou avisos do Azure Service Health. Teste regularmente os seus runbooks.
  • Documente os seus critérios de comutação e de retorno.
  • Verifique se quaisquer utilizadores ou principais de serviço que desencadeiam a transição possuem as permissões necessárias.

• Tabelas auxiliares: As tabelas auxiliares não são replicadas. Como boa prática, não ative a replicação em espaços de trabalho que incluam tabelas auxiliares.

• Microsoft Sentinel: Microsoft Sentinel listas de vigilância e entradas de inteligência de ameaças só se replicam quando são atualizadas, pelo que podem demorar até 12 dias a atingir a paridade total após a ativação inicial.

• Operações de purga: As operações de purga removem registos tanto dos espaços de trabalho primários como secundários. Se qualquer um dos espaços de trabalho estiver indisponível, a purga falha. Neste caso, deve planear os seus prazos de conformidade em conformidade com isso.

Para mais considerações, veja Considerações de Implantação.

Custo

Quando ativa a replicação do espaço de trabalho, paga pela replicação de todos os dados que ingere no seu espaço de trabalho. Os DCRs que associa à replicação determinam diretamente os seus custos de replicação. Para mais informações sobre preços, consulte preços do Azure Monitor.

Configurar suporte multirregional

• Ativar a replicação do espaço de trabalho: Os passos gerais necessários para permitir a replicação do espaço de trabalho são:

  1. Ative a replicação e especifique a região secundária.

  2. Valide o estado de provisionamento.

     Sugestão

     Mesmo quando o estado de provisionamento é Succeeded, os esquemas de tabela podem continuar a replicar-se. Para verificar quando os esquemas das tabelas estão totalmente replicados, audite o espaço de trabalho secundário.

  3. Associe os DCRs ao ponto final de recolha de dados do workspace (DCE) após ativar a replicação, para que esses fluxos sejam replicados durante a comutação.

• Desativar a replicação do espaço de trabalho: Para passos detalhados para desativar a replicação do espaço de trabalho, consulte Ativar e desativar a replicação do espaço de trabalho.

  Desabilitar a replicação impede que novos registos sejam replicados, mas não remove cópias já replicadas até que a funcionalidade esteja totalmente desativada. Para monitorizar o progresso da operação de desativação, veja Verificar estado de provisionamento do espaço de trabalho.

Planejamento e gerenciamento de capacidade

Durante uma falha de região ou outro evento de troca ou conmutação, o seu espaço de trabalho pode sofrer maior carga devido à ingestão e tentativas de consulta. Se a sua solução for sensível a atrasos na ingestão de registos ou nas consultas, mesmo durante e após uma falha numa região, considere sobredimensionar a capacidade associada a quaisquer limites diários do seu espaço de trabalho. Para clusters dedicados, selecione um nível de compromisso com margem para picos temporários de ingestão. Para obter mais informações, consulte Gerenciar a capacidade por excesso de provisionamento.

Comportamento quando todas as regiões estão saudáveis

Esta secção descreve o que esperar quando configura um espaço de trabalho Log Analytics para replicação de espaços de trabalho, e todas as regiões estão operacionais.

• Operação entre regiões: Todas as ingestão e consultas visam o espaço de trabalho da região principal enquanto este está saudável. O espaço de trabalho da região secundária mantém uma réplica passiva de dados, esquemas e configuração até à transição.

• Replicação de dados entre zonas: Os novos logs, as atualizações de esquemas e de configurações são replicados assincronamente em lotes para o servidor secundário. Como é assíncrono, este processo de replicação não afeta a latência de ingestão. Os dados são normalmente replicados em cerca de dois minutos, mas este intervalo de tempo não é garantido.

A replicação de workspace aplica-se ao nível do workspace, por isso não podes selecionar tabelas individuais para replicar. No entanto, pode controlar a replicação associando apenas os DCRs que contêm fluxos de dados críticos ao endpoint de recolha de dados do espaço de trabalho. DCRs que não estão associados ao DCE do workspace não replicam os seus dados. Para mais informações, consulte Regras de recolha de dados para associados.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando configura um espaço de trabalho Log Analytics para replicação de espaços de trabalho, e há uma falha numa das regiões.

• Deteção e resposta: És responsável por decidir quando mudar o espaço de trabalho secundário para se tornar o novo espaço principal. A Microsoft não toma essa decisão nem inicia o processo por si, mesmo que haja uma falha regional. Switchover e switchback são ações manuais.

  Para informações sobre como decidir quando mudar, veja Quando devo mudar?. Para saber como monitorizar a saúde do seu espaço de trabalho durante uma possível transição, consulte Monitorizar o desempenho do espaço de trabalho usando consultas.

  Para detalhes sobre como promover um espaço de trabalho secundário para o novo espaço de trabalho principal, consulte Mudar para o seu espaço de trabalho secundário.

• Notificações: A Microsoft não o notifica automaticamente quando uma região está indisponível. No entanto, pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

  Para validar a novidade do seu espaço de trabalho secundário, pode monitorizar o estado da replicação e também auditar o espaço de trabalho secundário. Para aprender a monitorizar a saúde do seu espaço de trabalho ao tomar a decisão de mudar, consulte Monitorizar o desempenho do espaço de trabalho usando consultas.

• Pedidos ativos: Qualquer ingestão ativa da região falhada pode falhar, e quaisquer consultas em curso na região falhada também podem falhar.

  Após o processo de transição alterar as entradas DNS do espaço de trabalho, o espaço secundário fica disponível para ingestão e consulta. Os agentes da Microsoft repetem automaticamente as tentativas falhadas de ingestão de registos. As aplicações que utilizam a API de ingestão de logs também devem tentar novamente.

• Perda de dados esperada: Quaisquer registos ou outras alterações que ainda não foram replicadas não estão disponíveis na região secundária. Os dados são normalmente replicados em cerca de dois minutos, mas este intervalo de tempo não é garantido.

  Depois de mudar para a região secundária, se a região primária não conseguir processar os dados de log recebidos, o Azure Monitor armazena os dados na região secundária durante até 11 dias. Durante os primeiros quatro dias, o Azure Monitor tenta automaticamente replicar os dados periodicamente.

  A quantidade total de perda de dados é por vezes chamada de objetivo do ponto de recuperação (RPO).

• Tempo de inatividade previsto: O processo de transição envolve ativar a ingestão para o espaço de trabalho secundário e atualizar os registos DNS desse espaço.

  Embora a alteração do registo DNS aconteça rapidamente, a propagação do DNS pode demorar mais tempo. Se os agentes ou outros clientes não respeitarem o tempo de vida (TTL) do DNS, podem continuar a tentar ingestão no workspace principal. Garante que os clientes não armazenam entradas DNS por mais tempo do que o seu TTL.

  As consultas são retomadas no espaço de trabalho secundário depois de concluída a comutação.

  A quantidade de tempo que passa antes de o espaço de trabalho secundário ficar disponível é por vezes chamada de objetivo de tempo de recuperação (RTO).

• Redistribuição: O processo de transição atualiza os registos DNS dos endpoints de ingestão para apontarem para a região secundária. A plataforma encaminha as consultas internamente para a região ativa.

  Enquanto o espaço de trabalho estiver no estado pós-comutação, os registos são replicados de volta para a região primária através de replicação assíncrona.

Recuperação da região

Switchback é manual. És responsável por decidir quando voltar atrás. Depois de o primário estar estável e sincronizado, pode iniciar uma reversão. Valide que não existem registos em atraso no secundário e que a replicação é retomada com sucesso a partir do primário restaurado.

Para informações sobre como decidir quando voltar atrás, veja Quando devo voltar atrás?. Para obter instruções detalhadas sobre como voltar ao espaço de trabalho principal, consulte Voltar ao espaço de trabalho principal.

Teste para falhas regionais

Pode ativar uma alternância e um retrocesso a qualquer momento, incluindo para executar testes ou exercícios de recuperação de desastres.

Se realizar exercícios, recomendamos que siga estas melhores práticas:

Soluções multirregional personalizadas para resiliência

Se a replicação de workspace não estiver disponível para a sua região, ou se tiver de usar um tipo de tabela que a replicação de workspace não suporta, considere estas abordagens alternativas para resiliência multirregional:

• Escrita dupla: Configure fontes, como definições de diagnóstico, agentes e ingestão baseada em DCR, para enviar registos para dois espaços de trabalho independentes em regiões diferentes.

  Esta abordagem fornece análises quase em tempo real em ambas as regiões. No entanto, duplica o custo de ingestão e introduz o risco de desvio de configuração entre os espaços de trabalho.

• Exportar e reidratar: Se a sua região estiver emparelhada com outra região Azure, pode usar exportação de dados para exportar continuamente os seus registos para Armazenamento de Blobs do Azure. Configure a conta de armazenamento para usar um dos tipos de armazenamento geo-redundante (GRS). O Armazenamento do Azure replica automaticamente e de forma assíncrona os registos exportados para a região emparelhada.

  Durante um desastre, desloque um novo espaço de trabalho e incorpore seletivamente os dados críticos mais recentes. Também pode consultar manualmente o histórico a longo prazo diretamente do Armazenamento de Blobs usando o Azure Data Explorer. Para mais informações, consulte Consultar dados exportados.

Backup e restauração

O Azure Monitor Logs não oferece uma capacidade tradicional de backup ou restauro em um momento específico. Em vez disso, a durabilidade e recuperação dependem da replicação intrarregional (incluindo redundância de zona), replicação opcional do espaço de trabalho e exportação de dados para manter uma cópia externa. Para uma recuperação rápida de análises após uma falha, confie na replicação da plataforma em vez das operações de restauro.

Pode ativar a exportação de dados, que exporta automaticamente cópias dos seus registos para o Armazenamento do Azure. Se a sua região do Azure estiver emparelhada, pode considerar ativar o armazenamento geo-redundante (GRS) para replicar os dados de registo para a região emparelhada.

Resiliência a eliminações acidentais

Para cumprir requisitos rigorosos de conformidade e para proteção contra violações, considere a utilização de políticas de imutabilidade para evitar a eliminação de dados de registo da conta de armazenamento.

Resiliência à manutenção de serviços

A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não se espera tempo de inatividade durante os eventos de manutenção, a menos que tenha sido informado através do Azure Service Health, manutenção programada.

Para minimizar o efeito da manutenção, o Azure Monitor realiza manutenção contínua entre réplicas de espaços de trabalho e zonas de disponibilidade.

Se a sua solução for sensível à latência de ingestão e de consulta, monitorize a latência de ingestão e as métricas de saúde do espaço de trabalho durante e após eventos de manutenção programados.

Algumas alterações de configuração de longa duração podem ser exigentes em recursos, como permitir replicação, ligar clusters e adicionar grandes esquemas. Se precisar de fazer estas alterações, evite agenda-las quando a manutenção da plataforma também estiver agendada. Use a manutenção planeada do Azure Service Health para perceber quando a manutenção está agendada.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) para serviços Azure descreve a disponibilidade esperada de cada serviço e as condições que a sua solução deve cumprir para atingir essa expectativa de disponibilidade. Para mais informações, consulte SLAs para serviços online.

O Azure Monitor Logs é único entre os serviços online porque é a plataforma recomendada para recolher dados essenciais e insights necessários para submeter uma reclamação ao suporte da Microsoft para um problema de SLA.

Dois SLAs cobrem o Azure Monitor Logs:

• O Log Analytics Query Availability SLA define expectativas de disponibilidade para consultar os dados a partir de um espaço de trabalho Log Analytics.

• O Azure Monitor SLA define expectativas de disponibilidade para regras de alerta e grupos de ação, incluindo expectativas para a análise de sinais de telemetria e para a entrega de notificações.

Conteúdo relacionado

• Melhores práticas de fiabilidade para Azure Monitor Logs
• Zonas de disponibilidade em Azure Monitor
• Aumente a resiliência replicando o seu espaço de trabalho Log Analytics
• Exportação de dados do espaço de trabalho do Log Analytics
• Regras de recolha de dados
• Crie e gere um cluster dedicado