Compartilhar via

Perspectiva do Azure Well-Architected Framework no Log Analytics

  • Artigo

Well-Architected funcionalidade e desempenho da carga de trabalho do Framework devem ser monitorados de diversas maneiras e por diversos motivos. Os workspaces do Log Analytics do Azure Monitor são o log primário e o coletor de métricas para uma grande parte dos dados de monitoramento. Os workspaces dão suporte a vários recursos no Azure Monitor, incluindo consultas ad hoc, visualizações e alertas. Para obter princípios gerais de monitoramento, consulte Diretrizes de monitoramento e diagnóstico. As diretrizes apresentam princípios gerais de monitoramento. Ele identifica os diferentes tipos de dados. Ele identifica a análise necessária à qual o Azure Monitor dá suporte e também identifica os dados armazenados no workspace que habilita a análise.

Este artigo pressupõe que você entenda os princípios de design do sistema. Você também precisa de um conhecimento prático dos workspaces e recursos do Log Analytics no Azure Monitor que preenchem dados de carga de trabalho operacional. Para obter mais informações, confira Visão geral do workspace do Log Analytics.

Importante

Como usar este guia

Cada seção tem uma lista de verificação de design que apresenta áreas arquitetônicas preocupantes, juntamente com estratégias de design localizadas para o escopo da tecnologia.

Também estão incluídas recomendações sobre as funcionalidades de tecnologia ou topologias de implantação que podem ajudar a materializar essas estratégias. As recomendações não representam uma lista completa de todas as configurações disponíveis para workspaces do Log Analytics e seus recursos relacionados do Azure Monitor. Em vez disso, eles listam as principais recomendações mapeadas para as perspectivas de design. Use as recomendações para criar sua prova de conceito, projetar seu ambiente de monitoramento de carga de trabalho ou otimizar sua solução de monitoramento de carga de trabalho existente.

Escopo de tecnologia

Este guia se concentra nas decisões inter-relacionadas para os recursos do Azure a seguir.

  • Workspaces do Log Analytics
  • Dados de log operacional da carga de trabalho
  • Configurações de diagnóstico em recursos do Azure em sua carga de trabalho

Confiabilidade

A finalidade do pilar confiabilidade é fornecer funcionalidade contínua criando resiliência suficiente e a capacidade de se recuperar rapidamente de falhas.

Os princípios de design de confiabilidade fornecem uma estratégia de design de alto nível aplicada a componentes individuais, fluxos do sistema e o sistema como um todo.

As situações de confiabilidade a serem consideradas para workspaces do Log Analytics são:

  • Disponibilidade do workspace.
  • Proteção de dados coletados no caso raro de uma falha de datacenter ou região do Azure.

Atualmente, não há nenhum recurso padrão para failover entre workspaces em regiões diferentes, mas há estratégias a serem usadas se você tiver requisitos específicos de disponibilidade ou conformidade.

Lista de verificação de design para confiabilidade

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Confiabilidade e determine sua relevância para seus requisitos de negócios, tendo em mente as SKUs e os recursos de VMs (máquinas virtuais) e suas dependências. Estenda a estratégia para incluir mais abordagens conforme necessário.

  • Examine os limites de serviço para workspaces do Log Analytics. A seção limites de serviço ajuda você a entender as restrições na coleta e retenção de dados e outros aspectos do serviço. Esses limites ajudam a determinar como projetar corretamente sua estratégia de observabilidade de carga de trabalho. Examine os limites de serviço do Azure Monitor , pois muitas das funções discutidas nele, como consultas, funcionam lado a lado com workspaces do Log Analytics.
  • Planeje a resiliência e a recuperação do workspace. Os workspaces do Log Analytics são regionais, sem suporte interno para redundância ou replicação entre regiões. Além disso, as opções de redundância de zona de disponibilidade são limitadas. Dessa forma, você deve determinar os requisitos de confiabilidade de seus workspaces e criar estratégias para atender a esses destinos. Seus requisitos podem estipular que seu workspace deve ser resiliente a falhas de datacenter ou falhas regionais, ou eles podem estipular que você deve ser capaz de recuperar seus dados para um novo workspace em uma região de failover. Cada um desses cenários exige que recursos e processos adicionais sejam colocados em prática para serem bem-sucedidos, portanto, o balanceamento de suas metas de confiabilidade com custo e complexidade deve ser cuidadosamente considerado.
  • Escolha as regiões de implantação corretas para atender aos seus requisitos de confiabilidade. Implante seu workspace do Log Analytics e dces (pontos de extremidade de coleta de dados) colocalizados com os componentes de carga de trabalho que emitem dados operacionais. Sua escolha da região apropriada na qual implantar seu workspace e seus DCEs deve ser informada pelo local em que você implanta sua carga de trabalho. Talvez seja necessário avaliar a disponibilidade regional de determinadas funcionalidades do Log Analytics, como clusters dedicados, em relação a outros fatores mais centrais para os requisitos de confiabilidade, custo e desempenho da carga de trabalho.
  • Verifique se os sistemas de observabilidade estão íntegros. Como qualquer outro componente da carga de trabalho, verifique se os sistemas de monitoramento e registro em log estão funcionando corretamente. Para fazer isso, habilite recursos que enviam sinais de dados de integridade para suas equipes de operações. Configure sinais de dados de integridade específicos para seus workspaces do Log Analytics e recursos associados.

Recomendações de configuração para confiabilidade

Recomendação Benefício
Não inclua seus workspaces do Log Analytics no caminho crítico da carga de trabalho. Seus workspaces são importantes para um sistema de observabilidade funcional, mas a funcionalidade da carga de trabalho não deve depender deles. Manter seus workspaces e funções associadas fora do caminho crítico da carga de trabalho minimiza o risco de problemas que afetam o sistema de observabilidade de afetar a execução de runtime da carga de trabalho.
Para dar suporte à alta durabilidade dos dados do workspace, implante workspaces do Log Analytics em uma região que dê suporte à resiliência de dados. A resiliência de dados só é possível por meio da vinculação do workspace a um cluster dedicado na mesma região. Quando você usa um cluster dedicado, ele permite que você espalhe os workspaces associados entre zonas de disponibilidade, que oferecem proteção contra interrupções de datacenter. Se você não coletar dados suficientes agora para justificar um cluster dedicado, essa escolha regional preemptiva dá suporte ao crescimento futuro.
Escolha a implantação do workspace com base na proximidade com sua carga de trabalho.

Use pontos de extremidade de coleta de dados (DCE) na mesma região que o workspace do Log Analytics.		 Implante seu workspace na mesma região que as instâncias da carga de trabalho. Ter seu workspace e DCEs na mesma região que sua carga de trabalho reduz o risco de impactos por interrupções em outras regiões.

Os DCEs são usados pelo agente do Azure Monitor e pela API de Ingestão de Logs para enviar dados operacionais de carga de trabalho para um workspace do Log Analytics. Talvez você precise de vários DCEs, embora sua implantação tenha apenas um único workspace. Para obter mais informações sobre como configurar DCEs para seu ambiente específico, consulte Como configurar pontos de extremidade de coleta de dados com base em sua implantação.<Br
Se sua carga de trabalho for implantada em um design ativo-ativo, considere o uso de vários workspaces e DCEs distribuídos entre as regiões em que sua carga de trabalho está implantada.

Implantar workspaces em várias regiões adiciona complexidade ao seu ambiente. Equilibre os critérios detalhados em Criar uma arquitetura de workspace do Log Analytics com seus requisitos de disponibilidade.
Se você precisar que o workspace esteja disponível em uma falha de região ou não coletar dados suficientes para um cluster dedicado, configure a coleta de dados para enviar dados críticos para vários workspaces em regiões diferentes. Essa prática também é conhecida como multicasting de log.

Por exemplo, configure DCRs para vários workspaces para o agente do Azure Monitor em execução em VMs. Defina várias configurações de diagnóstico para coletar logs de recursos de recursos do Azure e enviar os logs para vários workspaces.
Dessa forma, os dados operacionais da carga de trabalho estão disponíveis no workspace alternativo se houver uma falha regional. Mas saiba que os recursos que dependem dos dados, como alertas e pastas de trabalho, não seriam replicados automaticamente para as outras regiões. Considere armazenar modelos do ARM (Azure Resource Manager) para recursos críticos de alerta com configuração para o workspace alternativo ou implantá-los em todas as regiões, mas desabilitá-los para evitar alertas redundantes. Ambas as opções dão suporte à habilitação rápida em uma falha regional.

Compensação: essa configuração resulta em encargos duplicados de ingestão e retenção, portanto, use-o apenas para dados críticos.
Se você precisar que os dados sejam protegidos em uma falha de datacenter ou região, configure a exportação de dados do workspace para salvar dados em um local alternativo.

Essa opção é semelhante à opção anterior de multicasting dos dados para workspaces diferentes. Mas essa opção custa menos porque os dados extras são gravados no armazenamento.

Use as opções de redundância do Armazenamento do Azure, incluindo GRS (armazenamento com redundância geográfica) e GZRS (armazenamento com redundância de zona geográfica), para replicar ainda mais esses dados para outras regiões.

A exportação de dados não fornece resiliência contra incidentes que afetam o pipeline de ingestão regional.		 Embora os dados históricos do log operacional possam não ser prontamente consultáveis no estado exportado, eles garantem que os dados sobrevivam a uma interrupção regional prolongada e possam ser acessados e retidos por um longo período.

Se você precisar da exportação de tabelas sem suporte na exportação de dados, poderá usar outros métodos de exportação de dados, incluindo Aplicativos Lógicos, para proteger seus dados.

Para que essa estratégia funcione como um plano de recuperação viável, você deve ter processos em vigor para reconfigurar as configurações de diagnóstico para seus recursos no Azure e em todos os agentes que fornecem dados. Você também deve planejar reidratar manualmente os dados exportados para um novo workspace. Assim como acontece com a opção descrita anteriormente, você também precisa definir processos para os recursos que dependem dos dados, como alertas e pastas de trabalho.
Para cargas de trabalho críticas que exigem alta disponibilidade, considere implementar um modelo de workspace federado que usa vários workspaces para fornecer alta disponibilidade se houver uma falha regional. A missão crítica fornece diretrizes de práticas recomendadas prescritivas para criar aplicativos altamente confiáveis no Azure. A metodologia de design inclui um modelo de workspace federado com vários workspaces do Log Analytics para fornecer alta disponibilidade se houver várias falhas, incluindo a falha de uma região do Azure.

Essa estratégia elimina os custos de saída entre regiões e permanece operacional com uma falha de região. Mas isso requer mais complexidade que você deve gerenciar com a configuração e os processos descritos em Modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure.
Use IaC (infraestrutura como código) para implantar e gerenciar seus workspaces e funções associadas. Quando você automatiza a maior parte de sua implantação e seus mecanismos de resiliência e recuperação como práticos, ele garante que essas operações sejam confiáveis. Você economiza tempo crítico em seus processos de operações e minimiza o risco de erro humano.

Verifique se funções como consultas de log salvas também são definidas por meio de sua IaC para recuperá-las em uma nova região se a recuperação for necessária.
Crie DCRs com um único princípio de responsabilidade para manter as regras dcr simples.

Embora um DCR possa ser carregado com todas as entradas, regras e destinos para os sistemas de origem, é preferível criar regras estreitamente focadas que dependem de menos fontes de dados. Use a composição de atribuições de regra para chegar ao escopo de observabilidade desejado para o destino lógico.

Além disso, minimize a transformação em DCRs		 Quando você usa DCRs com foco restrito, ele minimiza o risco de uma configuração incorreta de regra ter um efeito mais amplo. Ele limita o efeito apenas ao escopo para o qual o DCR foi criado. Para obter mais informações, consulte Práticas recomendadas para criação e gerenciamento de regras de coleta de dados no Azure Monitor.

Embora a transformação possa ser poderosa e necessária em algumas situações, pode ser desafiador testar e solucionar problemas do trabalho de KQL (linguagem de consulta) palavra-chave que está sendo feito. Quando possível, minimize o risco de perda de dados ingerindo os dados brutos e tratando transformações downstream no momento da consulta.
Ao definir um limite diário ou uma política de retenção, certifique-se de que você está mantendo seus requisitos de confiabilidade ingerindo e retendo os logs necessários. Um limite diário interrompe a coleta de dados de um workspace depois que uma quantidade especificada é atingida, o que ajuda você a manter o controle sobre o volume de ingestão. Mas use esse recurso somente após um planejamento cuidadoso. Verifique se o limite diário não está sendo atingido com regularidade. Se isso acontecer, seu limite será definido com muita restrição. Você precisa reconfigurar o limite diário para não perder sinais críticos provenientes da carga de trabalho.

Da mesma forma, lembre-se de abordar cuidadosamente e cuidadosamente a redução da política de retenção de dados para garantir que você não perca dados críticos inadvertidamente.
Use os insights do workspace do Log Analytics para acompanhar o volume de ingestão, os dados ingeridos versus o limite de dados, as fontes de log sem resposta e as consultas com falha entre outros dados. Crie alertas de status de integridade para notificá-lo proativamente se um workspace ficar indisponível devido a um datacenter ou falha regional. Essa estratégia garante que você seja capaz de monitorar com êxito a integridade de seus workspaces e agir proativamente se a integridade estiver em risco de degradação. Como qualquer outro componente da carga de trabalho, é fundamental que você esteja ciente das métricas de integridade e possa identificar tendências para melhorar sua confiabilidade ao longo do tempo.

Azure Policy

O Azure não oferece políticas relacionadas à confiabilidade dos workspaces do Log Analytics. Você pode criar políticas personalizadas para criar proteções de conformidade em torno de suas implantações de workspace, como garantir que os workspaces estejam associados a um cluster dedicado.

Embora não esteja diretamente relacionado à confiabilidade dos workspaces do Log Analytics, há políticas do Azure para quase todos os serviços disponíveis. As políticas garantem que diagnóstico configurações estejam habilitadas para esse serviço e validem se os dados de log do serviço estão fluindo para um workspace do Log Analytics. Todos os serviços na arquitetura de carga de trabalho devem estar enviando seus dados de log para um workspace do Log Analytics para suas próprias necessidades de confiabilidade, e as políticas podem ajudar a aplicá-los. Da mesma forma, existem políticas para garantir que plataformas baseadas em agente, como VMs e Kubernetes, tenham o agente instalado.

Assistente do Azure

O Azure não oferece recomendações do Assistente do Azure relacionadas à confiabilidade dos workspaces do Log Analytics.

Segurança

A finalidade do pilar segurança é fornecer garantias de confidencialidade, integridade e disponibilidade para a carga de trabalho.

Os princípios de design de segurança fornecem uma estratégia de design de alto nível para atingir essas metas aplicando abordagens ao design técnico em torno de sua solução de monitoramento e registro em log.

Lista de verificação de design para Segurança

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Segurança e identifique vulnerabilidades e controles para melhorar a postura de segurança. Estenda a estratégia para incluir mais abordagens conforme necessário.

  • Examine a linha de base de segurança do Azure Monitor e Gerencie o acesso aos tópicos de workspaces do Log Analytics. Esses tópicos fornecem diretrizes sobre as práticas recomendadas de segurança.
  • Implante seus workspaces com segmentação como um princípio fundamental. Implemente a segmentação nos níveis de rede, dados e acesso. A segmentação ajuda a garantir que seus workspaces estejam isolados no grau apropriado e estejam melhor protegidos contra acesso não autorizado ao mais alto grau possível, ao mesmo tempo em que atendem aos seus requisitos de negócios para confiabilidade, otimização de custos, excelência operacional e eficiência de desempenho.
  • Verifique se você pode auditar as leituras do workspace e gravar atividades e identidades associadas. Os invasores podem se beneficiar da exibição de logs operacionais. Uma identidade comprometida pode levar a ataques de injeção de log. Habilite a auditoria de operações executadas no Portal do Azure ou por meio de interações de API e usuários associados. Se você não estiver configurado para auditar seu workspace, poderá estar colocando sua organização em risco de violar os requisitos de conformidade.
  • Implemente controles de rede robustos. Ajuda a proteger o acesso à rede ao seu workspace e seus logs por meio de funções de isolamento de rede e firewall. Controles de rede insuficientemente configurados podem colocá-lo em risco de ser acessado por atores não autorizados ou mal-intencionados.
  • Determine quais tipos de dados precisam de imutabilidade ou retenção de longo prazo. Seus dados de log devem ser tratados com o mesmo rigor que os dados de carga de trabalho dentro dos sistemas de produção. Inclua dados de log em suas práticas de classificação de dados para garantir que você esteja armazenando com êxito dados de log confidenciais de acordo com seus requisitos de conformidade.
  • Proteja os dados de log inativos por meio da criptografia. A segmentação por si só não protegerá completamente a confidencialidade dos seus dados de log. Se o acesso bruto não autorizado ocorrer, ter os dados de log criptografados em repouso ajudará a impedir que atores inválidos usem esses dados fora do workspace.
  • Proteja dados de log confidenciais por meio de ofuscação. Assim como os dados de carga de trabalho que residem em sistemas de produção, você deve tomar medidas extras para garantir que a confidencialidade seja mantida para informações confidenciais que possam estar presentes intencionalmente ou involuntariamente em logs operacionais. Quando você usa métodos de ofuscação, ele ajuda a ocultar dados de log confidenciais de olhos não autorizados.

Recomendações de configuração para Segurança

Recomendação Benefício
Use chaves gerenciadas pelo cliente se precisar de sua própria chave de criptografia para proteger dados e consultas salvas em seus workspaces.

O Azure Monitor garante que todos os dados e consultas salvos sejam criptografados em repouso com as chaves gerenciadas pela Microsoft (MMK). Se você precisar de sua própria chave de criptografia e coletar dados suficientes para um cluster dedicado, use a chave gerenciada pelo cliente. Você pode criptografar dados usando sua própria chave no Azure Key Vault, para controlar o ciclo de vida da chave e a capacidade de revogar o acesso aos seus dados.

Se você usar o Microsoft Sentinel, verifique se está familiarizado com as considerações em Configurar a chave gerenciada pelo cliente do Microsoft Sentinel.		 Essa estratégia permite criptografar dados usando sua própria chave no Azure Key Vault, para controlar o ciclo de vida da chave e a capacidade de revogar o acesso aos seus dados.
Configure a auditoria de consulta de log para rastrear quais usuários estão executando consultas.

Configure os logs de auditoria para cada workspace a ser enviado para o workspace local ou consolide em um workspace de segurança dedicado se você separar seus dados operacionais e de segurança. Use os insights do workspace do Log Analytics para examinar periodicamente esses dados. Considere criar regras de alerta de consulta de log para notificá-lo proativamente se os usuários não autorizados estiverem tentando executar consultas.		 A auditoria de consulta de log registra os detalhes de cada consulta executada em um workspace. Trate esses dados de auditoria como dados de segurança e proteja a tabela LAQueryLogs adequadamente. Essa estratégia reforça sua postura de segurança, ajudando a garantir que o acesso não autorizado seja capturado imediatamente se isso acontecer.
Ajude a proteger seu workspace por meio de medidas privadas de segmentação e rede.

Use a funcionalidade de link privado para limitar as comunicações entre fontes de log e seus workspaces à rede privada.		 Quando você usa um link privado, ele também permite controlar quais redes virtuais podem acessar um determinado workspace, reforçando ainda mais sua segurança por meio da segmentação.
Use Microsoft Entra ID em vez de chaves de API para acesso à API do workspace quando disponível. O acesso baseado em chave de API às APIs de consulta não deixa uma trilha de auditoria por cliente. Use o acesso baseado em ID do Entra com escopo suficiente para que você possa auditar corretamente o acesso programático.
Configure o acesso para diferentes tipos de dados no workspace necessários para diferentes funções em sua organização.

Defina o modo de controle de acesso para o workspace como Usar permissões de recurso ou workspace. Esse controle de acesso permite que os proprietários de recursos usem o contexto de recursos para acessar seus dados sem ter acesso explícito ao workspace.

Use o RBAC de nível de tabela para usuários que exigem acesso a um conjunto de tabelas em vários recursos.		 Essa configuração simplifica a configuração do workspace e ajuda a garantir que os usuários não possam acessar dados operacionais que não deveriam.

Atribua a função interna apropriada para conceder permissões de workspace aos administradores no nível da assinatura, do grupo de recursos ou do workspace, dependendo do escopo das responsabilidades.

Os usuários com permissões de tabela têm acesso a todos os dados na tabela, independentemente de suas permissões de recurso.

Consulte Gerenciar o acesso aos workspaces do Log Analytics para obter detalhes sobre as diferentes opções para conceder acesso aos dados no workspace.
Exportar logs que exigem retenção ou imutabilidade de longo prazo.

Use a exportação de dados para enviar dados para uma conta de Armazenamento do Azure com políticas de imutabilidade para ajudar a proteger contra violação de dados. Nem todos os tipos de log têm a mesma relevância para conformidade, auditoria ou segurança, portanto, determine os tipos de dados específicos que devem ser exportados.		 Você pode coletar dados de auditoria em seu workspace sujeitos a regulamentos que exigem sua retenção de longo prazo. Os dados em um workspace do Log Analytics não podem ser alterados, mas podem ser limpos. Exportar uma cópia dos dados operacionais para fins de retenção permite criar uma solução que atenda aos seus requisitos de conformidade.
Determine uma estratégia para filtrar ou ofuscar dados confidenciais em seu workspace.

Você pode estar coletando dados que incluem informações confidenciais. Filtre registros que não devem ser coletados usando a configuração da fonte de dados específica. Use uma transformação se apenas colunas específicas nos dados devem ser removidas ou ofuscadas.

Se você tiver padrões que exigem que os dados originais não sejam modificados, poderá usar o literal 'h' em consultas KQL para ofuscar os resultados da consulta exibidos em pastas de trabalho.		 Ofuscar ou filtrar dados confidenciais em seu workspace ajuda a manter a confidencialidade sobre informações confidenciais. Em muitos casos, os requisitos de conformidade determinam as maneiras pelas quais você pode lidar com informações confidenciais. Essa estratégia ajuda você a cumprir os requisitos proativamente.

Azure Policy

O Azure oferece políticas relacionadas à segurança dos workspaces do Log Analytics para ajudar a impor sua postura de segurança desejada. Exemplos dessas políticas são:

O Azure também oferece várias políticas para ajudar a impor a configuração de link privado, como workspaces do Log Analytics, que devem bloquear a ingestão de logs e consultas de redes públicas ou até mesmo configurar a solução por meio de políticas DINE, como Configurar o Escopo Link Privado do Azure Monitor para usar zonas DNS privadas.

Assistente do Azure

O Azure não oferece recomendações do Assistente do Azure relacionadas à segurança dos workspaces do Log Analytics.

Otimização de custos

A Otimização de Custos se concentra na detecção de padrões de gastos, na priorização de investimentos em áreas críticas e na otimização em outras pessoas para atender ao orçamento da organização enquanto atende aos requisitos de negócios.

Os princípios de design da Otimização de Custos fornecem uma estratégia de design de alto nível para atingir essas metas de negócios. Eles também ajudam você a fazer compensações conforme necessário no design técnico relacionado à sua solução de monitoramento e registro em log.

Para obter mais informações sobre como os encargos de dados são calculados para seus workspaces do Log Analytics, consulte Cálculos e opções de custo dos Logs do Azure Monitor.

Lista de verificação de design para Otimização de Custos

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Otimização de Custos para investimentos e ajuste o design para que a carga de trabalho seja alinhada com o orçamento alocado para a carga de trabalho. Seu design deve usar os recursos corretos do Azure, monitorar investimentos e encontrar oportunidades para otimizar ao longo do tempo.

  • Execute exercícios de modelagem de custo. Essas exercizações ajudam você a entender os custos atuais do workspace e prever seus custos em relação ao crescimento do workspace. Analise suas tendências de crescimento em sua carga de trabalho e verifique se você entende os planos de expansão da carga de trabalho para prever corretamente seus custos futuros de registro em log operacional.
  • Escolha o modelo de cobrança certo. Use seu modelo de custo para determinar o melhor modelo de cobrança para seu cenário. A forma como você usa seus workspaces atualmente e como planeja usá-los à medida que sua carga de trabalho evolui determina se um modelo de camada de compromisso ou pago conforme o uso é o mais adequado para seu cenário.

    Lembre-se de que você pode escolher modelos de cobrança diferentes para cada workspace e pode combinar custos de workspace em determinados casos, para que você possa ser granular em sua análise e tomada de decisão.
  • Colete apenas a quantidade certa de dados de log. Execute a análise agendada regularmente das configurações de diagnóstico em seus recursos, configuração de regra de coleta de dados e registro em log de código de aplicativo personalizado para garantir que você não esteja coletando dados de log desnecessários.
  • Trate ambientes de não produção de forma diferente da produção. Examine seus ambientes de não produção para garantir que você tenha definido as configurações de diagnóstico e as políticas de retenção adequadamente. Geralmente, eles podem ser significativamente menos robustos do que a produção, especialmente para ambientes de desenvolvimento/teste ou área restrita.

Recomendações de configuração para Otimização de Custos

Recomendação Benefício
Configure o tipo de preço para a quantidade de dados que cada workspace do Log Analytics normalmente coleta. Por padrão, os workspaces do Log Analytics usam preços pago conforme o uso sem volume mínimo de dados. Se você coletar dados suficientes, poderá diminuir significativamente seu custo usando uma camada de compromisso, o que permite que você se comprometa com um mínimo diário de dados coletados em troca de uma taxa mais baixa. Se você coletar dados suficientes entre workspaces em uma única região, poderá vinculá-los a um cluster dedicado e combinar o volume coletado usando preços de cluster.

Para obter mais informações sobre camadas de compromisso e diretrizes sobre como determinar o que é mais apropriado para seu nível de uso, consulte Cálculos e opções de custo dos Logs do Azure Monitor. Para exibir os custos estimados para seu uso em diferentes tipos de preço, consulte Uso e custos estimados.
Configure a retenção e o arquivamento de dados. Há uma cobrança por reter dados em um workspace do Log Analytics além do padrão de 31 dias. Serão 90 dias se o Microsoft Sentinel estiver habilitado no workspace e 90 dias para dados do Application Insights. Considere seus requisitos específicos para ter dados prontamente disponíveis para consultas de log. Você pode reduzir significativamente seu custo configurando logs arquivados. Os logs arquivados permitem reter dados por até sete anos e ainda acessá-los ocasionalmente. Você acessa os dados usando trabalhos de pesquisa ou restaurando um conjunto de dados no workspace.
Se você usar o Microsoft Sentinel para analisar logs de segurança, considere empregar um workspace separado para armazenar esses logs. Quando você usa um workspace dedicado para dados de log que seu SIEM usa, ele pode ajudá-lo a controlar os custos. Os workspaces que o Microsoft Sentinel usa estão sujeitos aos preços do Microsoft Sentinel. Seus requisitos de segurança determinam os tipos de logs que precisam ser incluídos em sua solução SIEM. Talvez você possa excluir logs operacionais, que seriam cobrados nos preços padrão do Log Analytics se eles estiverem em um workspace separado.
Configure as tabelas usadas para depuração, solução de problemas e auditoria como Logs Básicos. As tabelas em um workspace do Log Analytics configurado para Logs Básicos têm um custo de ingestão menor em troca de recursos limitados e uma cobrança pelas consultas de log. Se você consulta essas tabelas com pouca frequência e não as usa para alertas, esse custo de consulta pode ser mais do que compensado pelo custo reduzido de ingestão.
Limite a coleta de dados de fontes de dados para o workspace. O principal fator para o custo do Azure Monitor é a quantidade de dados coletados no workspace do Log Analytics. Certifique-se de não coletar mais dados do que você precisa para avaliar a integridade e o desempenho de seus serviços e aplicativos. Para cada recurso, selecione as categorias certas para as configurações de diagnóstico que você configura para fornecer a quantidade de dados operacionais necessários. Ele ajuda você a gerenciar com êxito sua carga de trabalho e não a gerenciar dados ignorados.

Pode haver uma compensação entre o custo e seus requisitos de monitoramento. Por exemplo, você pode ser capaz de detectar um problema de desempenho mais rapidamente com uma taxa de exemplo alta, mas talvez você queira uma taxa de exemplo mais baixa para economizar custos. A maioria dos ambientes tem várias fontes de dados com diferentes tipos de coleção, portanto, você precisa equilibrar seus requisitos específicos com suas metas de custo para cada uma. Consulte Otimização de custos no Azure Monitor para obter recomendações sobre como configurar a coleta para diferentes fontes de dados.
Analise regularmente os dados de uso do workspace para identificar tendências e anomalias.

Use os insights do workspace do Log Analytics para examinar periodicamente a quantidade de dados coletados em seu workspace. Analise ainda mais a coleta de dados usando métodos em Analisar o uso no workspace do Log Analytics para determinar se há outras configurações que podem diminuir ainda mais seu uso.		 Ao ajudá-lo a entender a quantidade de dados coletados por diferentes fontes, ele identifica anomalias e tendências ascendentes na coleta de dados que podem resultar em custo excessivo. Essa consideração é importante quando você adiciona um novo conjunto de fontes de dados à carga de trabalho. Por exemplo, se você adicionar um novo conjunto de VMs, habilite novas configurações de diagnóstico do Azure em um serviço ou altere os níveis de log em seu aplicativo.
Criar um alerta para quando a coleta de dados for alta. Para evitar cobranças inesperadas, você deve receber notificações proativas sempre que ocorrer uso excessivo. A notificação permite que você resolva possíveis anomalias antes do final do período de cobrança.
Considere um limite diário como uma medida preventiva para garantir que você não exceda um orçamento especificado. Um limite diário desabilita a coleta de dados em um workspace do Log Analytics pelo resto do dia quando o limite configurado é atingido. Não use essa prática como um método para reduzir os custos, conforme descrito em Quando usar um limite diário, mas sim para evitar a ingestão descontrolada devido a erros de configuração ou abuso.

Se você definir um limite diário, crie um alerta quando o limite for atingido. Certifique-se de também criar uma regra de alerta quando algum percentual for atingido. Por exemplo, você pode definir uma regra de alerta para quando a capacidade de 90% for atingida. Esse alerta oferece a oportunidade de investigar e abordar a causa dos dados aumentados antes que o limite desligue a coleta de dados crítica da carga de trabalho.

Azure Policy

O Azure não oferece políticas relacionadas à otimização de custos de workspaces do Log Analytics. Você pode criar políticas personalizadas para criar proteções de conformidade em torno de suas implantações de workspace, como garantir que seus workspaces contenham as configurações de retenção corretas.

Assistente do Azure

O Assistente do Azure faz recomendações para mover tabelas específicas em um workspace para o plano de dados de log básico de baixo custo para tabelas que recebem volume de ingestão relativamente alto. Entenda as limitações usando logs básicos antes de alternar. Para obter mais informações, consulte Quando devo usar logs básicos?. O Assistente do Azure também pode recomendar a alteração do tipo de compromisso de preços para todo o workspace com base no volume de uso geral.

Excelência operacional

A Excelência Operacional concentra-se principalmente em procedimentos para práticas de desenvolvimento, observabilidade e gerenciamento de lançamentos.

Os princípios de design de Excelência Operacional fornecem uma estratégia de design de alto nível para atingir essas metas em relação aos requisitos operacionais da carga de trabalho.

Lista de verificação de design para Excelência Operacional

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Excelência Operacional para definir processos para observabilidade, teste e implantação relacionados aos workspaces do Log Analytics.

  • Use IaC (infraestrutura como código) para todas as funções relacionadas aos workspaces do Log Analytics da carga de trabalho. Minimize o risco de erro humano que pode ocorrer com a administração manual e operação de suas funções de coleta, ingestão, armazenamento e consulta de logs, incluindo consultas salvas e pacotes de consultas, automatizando o máximo possível dessas funções por meio do código. Além disso, inclua alertas que relatam alterações status de integridade e a configuração das configurações de diagnóstico para recursos que enviam logs para seus workspaces no código IaC. Inclua o código com seu outro código relacionado à carga de trabalho para garantir que suas práticas de implantação seguras sejam mantidas para o gerenciamento de seus workspaces.
  • Verifique se seus workspaces estão íntegros e se você será notificado quando surgirem problemas. Como qualquer outro componente da carga de trabalho, seus workspaces podem encontrar problemas. Os problemas podem custar tempo e recursos valiosos para solucionar problemas e resolve e potencialmente deixar sua equipe sem saber da carga de trabalho de produção status. Ser capaz de monitorar proativamente workspaces e atenuar possíveis problemas ajuda as equipes de operações a minimizar o tempo gasto na solução de problemas e na correção de problemas.
  • Separe a produção das cargas de trabalho de não produção. Evite complexidade desnecessária que possa causar trabalho extra para uma equipe de operações usando workspaces diferentes para seu ambiente de produção do que aqueles usados por ambientes de não produção. Os dados recebidos também podem causar confusão, pois as atividades de teste podem parecer eventos em produção.
  • Preferir ferramentas e funções internas em vez de soluções que não sejam da Microsoft Use ferramentas internas para estender a funcionalidade de seus sistemas de monitoramento e registro em log. Talvez seja necessário colocar configurações adicionais em vigor para dar suporte a requisitos como capacidade de recuperação ou soberania de dados que não estão disponíveis prontas para uso com workspaces do Log Analytics. Nesses casos, sempre que for prático, use ferramentas nativas do Azure ou da Microsoft para manter o número de ferramentas que sua organização deve dar suporte ao mínimo.
  • Tratar seus workspaces como componentes estáticos em vez de efêmeros Assim como outros tipos de armazenamentos de dados, os workspaces não devem ser considerados entre os componentes efêmeros da carga de trabalho. O Well-Architected Framework geralmente favorece a infraestrutura imutável e a capacidade de substituir recursos de forma rápida e fácil em sua carga de trabalho como parte de suas implantações. Mas a perda de dados do workspace pode ser catastrófica e irreversível. Por esse motivo, deixe os workspaces fora dos pacotes de implantação que substituem a infraestrutura durante as atualizações e executem apenas atualizações in-loco nos workspaces.
  • Verifique se a equipe de operações é treinada em Linguagem de Consulta Kusto Treinar a equipe para criar ou modificar consultas quando necessário. Se os operadores não puderem gravar ou modificar consultas, isso poderá retardar a solução de problemas críticos ou outras funções, pois os operadores devem contar com outras equipes para fazer esse trabalho para eles.

Recomendações de configuração para Excelência Operacional

Recomendação Benefício
Crie uma estratégia de workspace para atender aos seus requisitos de negócios.

Consulte Criar uma arquitetura de workspace do Log Analytics para obter diretrizes sobre como criar uma estratégia para seus workspaces do Log Analytics. Inclua quantos para criar e onde colocá-los.

Se você precisar que sua carga de trabalho use uma oferta de equipe de plataforma centralizada, certifique-se de definir todo o acesso operacional necessário. Além disso, construa alertas para garantir que as necessidades de observabilidade da carga de trabalho sejam atendidas.		 Um número único ou mínimo de workspaces maximiza a eficiência operacional da carga de trabalho. Ele limita a distribuição de seus dados operacionais e de segurança, aumenta a visibilidade de possíveis problemas, facilita a identificação de padrões e minimiza seus requisitos de manutenção.

Você pode ter requisitos para vários workspaces, como vários locatários, ou talvez precise de workspaces em várias regiões para dar suporte aos seus requisitos de disponibilidade. Portanto, verifique se você tem processos apropriados para gerenciar essa complexidade aumentada.
Use IaC (infraestrutura como código) para implantar e gerenciar seus workspaces e funções associadas. Use IaC (infraestrutura como código) para definir os detalhes de seus workspaces em modelos do ARM, no Azure BICEP ou no Terraform. Ele permite que você use seus processos de DevOps existentes para implantar novos workspaces e Azure Policy para impor sua configuração.

Colocar todo o código iac com o código do aplicativo ajuda a garantir que suas práticas de implantação seguras sejam mantidas para todas as implantações.
Use os insights do workspace do Log Analytics para acompanhar a integridade e o desempenho dos workspaces do Log Analytics e criar alertas significativos e acionáveis para serem notificados proativamente sobre problemas operacionais.

O Insights do Workspace do Log Analytics fornece uma exibição unificada do uso, do desempenho, da integridade, do agente, das consultas e do log de alteração de todos os workspaces.

Cada workspace tem uma tabela de operações que registra atividades importantes que afetam o workspace.		 Examine as informações que os insights do Log Analytics fornecem regularmente para acompanhar a integridade e a operação de cada um dos workspaces. Quando você usa essas informações, ela permite que você crie visualizações facilmente compreendidas, como painéis ou relatórios que as operações e os stakeholders podem usar para acompanhar a integridade de seus workspaces.

Crie regras de alerta com base nessa tabela para serem notificadas proativamente quando ocorrer um problema operacional. Você pode usar alertas recomendados para o workspace para simplificar a forma como você cria as regras de alerta mais críticas.
Pratique o aprimoramento contínuo revisitando com frequência as configurações de diagnóstico do Azure em seus recursos, regras de coleta de dados e detalhamento do log de aplicativos.

Verifique se você está otimizando sua estratégia de coleta de logs por meio de revisões frequentes de suas configurações de recurso. Do ponto de vista operacional, procure reduzir o ruído em seus logs, concentrando-se nesses logs que fornecem informações úteis sobre a integridade de um recurso status.		 Ao otimizar dessa maneira, você permite que os operadores investiguem e solucionem problemas quando eles surgirem ou executem outras tarefas rotineiras, improvisadas ou de emergência.

Quando novas categorias de diagnóstico forem disponibilizadas para um tipo de recurso, examine os tipos de logs emitidos com essa categoria para entender se habilitá-las pode ajudá-lo a otimizar sua estratégia de coleção. Por exemplo, uma nova categoria pode ser um subconjunto de um conjunto maior de atividades que estão sendo capturadas. O novo subconjunto pode permitir que você reduza o volume de logs que estão chegando, concentrando-se nas atividades que são importantes para que suas operações acompanhem.

Azure Policy e Assistente do Azure

O Azure não oferece políticas nem recomendações do Assistente do Azure relacionadas à excelência operacional dos workspaces do Log Analytics.

Eficiência de desempenho

A Eficiência de Desempenho se trata de manter a experiência do usuário mesmo quando há um aumento na carga gerenciando a capacidade. A estratégia inclui dimensionar recursos, identificar e otimizar possíveis gargalos e otimizar o desempenho de pico.

Os princípios de design de Eficiência de Desempenho fornecem uma estratégia de design de alto nível para atingir essas metas de capacidade em relação ao uso esperado.

Lista de verificação de design para Eficiência de Desempenho

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Eficiência de Desempenho para definir uma linha de base para seus workspaces do Log Analytics e funções associadas.

  • Familiarize-se com os conceitos básicos da latência de ingestão de dados de log no Azure Monitor. Há vários fatores que contribuem para a latência ao ingerir logs em seus workspaces. Muitos desses fatores são inerentes à plataforma do Azure Monitor. Entender os fatores e o comportamento de latência normal pode ajudá-lo a definir as expectativas apropriadas em suas equipes de operações de carga de trabalho.
  • Separe suas cargas de trabalho de não produção e produção. Workspaces específicos de produção reduzem qualquer sobrecarga que os sistemas de não produção possam introduzir. Ele reduz o volume geral de seus workspaces, exigindo menos recursos para lidar com o processamento de dados de log.
  • Escolha as regiões de implantação corretas para atender aos seus requisitos de desempenho. Implante o workspace do Log Analytics e os DCEs (pontos de extremidade de coleta de dados) próximos à carga de trabalho. Sua escolha da região apropriada na qual implantar seu workspace e seus DCEs deve ser informada pelo local em que você implanta a carga de trabalho. Talvez seja necessário avaliar os benefícios de desempenho da implantação de seus workspaces e DCEs na mesma região que sua carga de trabalho em relação aos seus requisitos de confiabilidade se você já tiver implantado sua carga de trabalho em uma região que não possa dar suporte a esses requisitos para seus dados de log.

Recomendações de configuração para Eficiência de Desempenho

Recomendação Benefício
Configure a auditoria de consulta de log e use os insights do workspace do Log Analytics para identificar consultas lentas e ineficientes.

A auditoria de consulta de log armazena o tempo de computação necessário para executar cada consulta e o tempo até que os resultados sejam retornados. Os insights do workspace do Log Analytics usam esses dados para listar consultas potencialmente ineficientes em seu workspace. Considere reescrever essas consultas para melhorar seu desempenho. Consulte Otimizar consultas de log no Azure Monitor para obter diretrizes sobre como otimizar suas consultas de log.		 Consultas otimizadas retornam resultados mais rapidamente e usam menos recursos no back-end, o que torna os processos que dependem dessas consultas mais eficientes também.
Entenda os limites de serviço para workspaces do Log Analytics.

Em determinadas implementações de alto tráfego, você pode encontrar limites de serviço que afetam seu desempenho e seu design de workspace ou carga de trabalho. Por exemplo, a API de consulta limita o número de registros e o volume de dados retornados por uma consulta. A API de Ingestão de Logs limita o tamanho de cada chamada à API.

Para obter uma lista completa dos limites e limites de workspaces do Azure Monitor e do Log Analytics específicos do workspace em si, consulte Limites de serviço do Azure Monitor.		 Entender os limites que podem afetar o desempenho do workspace ajuda você a projetar adequadamente para atenuá-los. Você pode decidir usar vários workspaces para evitar atingir limites associados a um único workspace.

Avalie as decisões de design para atenuar os limites de serviço em relação a requisitos e destinos para outros pilares.
Crie DCRs específicos para tipos de fonte de dados dentro de um ou mais escopos de observabilidade definidos. Crie DCRs separados para desempenho e eventos para otimizar a utilização da computação de processamento de back-end. Quando você usa DCRs separados para desempenho e eventos, isso ajuda a atenuar o esgotamento de recursos de back-end. Ao ter DCRs que combinam eventos de desempenho, ele força todas as máquinas virtuais associadas a transferir, processar e executar configurações que podem não ser aplicáveis de acordo com o software instalado. Um consumo excessivo de recursos de computação e erros no processamento de uma configuração podem acontecer e fazer com que o AMA (Agente do Azure Monitor) fique sem resposta.

Azure Policy e Assistente do Azure

O Azure não oferece políticas nem recomendações do Assistente do Azure relacionadas ao desempenho dos workspaces do Log Analytics.

Próxima etapa