Share via

Perspetiva do Azure Well-Architected Framework sobre o Log Analytics

  • Artigo

Well-Architected Framework, a funcionalidade e o desempenho da carga de trabalho têm de ser monitorizados de diversas formas e por diversas razões. As áreas de trabalho do Log Analytics do Azure Monitor são o registo principal e o sink de métricas para uma grande parte dos dados de monitorização. As áreas de trabalho suportam várias funcionalidades no Azure Monitor, incluindo consultas ad hoc, visualizações e alertas. Para obter os princípios gerais de monitorização, veja Documentação de orientação sobre monitorização e diagnóstico. A documentação de orientação apresenta princípios gerais de monitorização. Identifica os diferentes tipos de dados. Identifica a análise necessária que o Azure Monitor suporta e também identifica os dados armazenados na área de trabalho que permitem a análise.

Este artigo pressupõe que compreende os princípios de design do sistema. Também precisa de um conhecimento prático das áreas de trabalho e funcionalidades do Log Analytics no Azure Monitor que preencha dados de cargas de trabalho operacionais. Para obter mais informações, veja Descrição geral da área de trabalho do Log Analytics.

Importante

Como utilizar este guia

Cada secção tem uma lista de verificação de design que apresenta áreas de interesse arquitetónicas, juntamente com estratégias de design localizadas no âmbito da tecnologia.

Também estão incluídas recomendações sobre as capacidades tecnológicas ou topologias de implementação que podem ajudar a materializar essas estratégias. As recomendações não representam uma lista exaustiva de todas as configurações disponíveis para áreas de trabalho do Log Analytics e os respetivos recursos do Azure Monitor relacionados. Em vez disso, listam as principais recomendações mapeadas para as perspetivas de design. Utilize as recomendações para criar a prova de conceito, estruturar o ambiente de monitorização da carga de trabalho ou otimizar a solução de monitorização da carga de trabalho existente.

Âmbito da tecnologia

Este guia centra-se nas decisões interligadas para os seguintes recursos do Azure.

  • Áreas de trabalho do Log Analytics
  • Dados de registo operacional da carga de trabalho
  • Definições de diagnóstico nos recursos do Azure na carga de trabalho

Fiabilidade

O objetivo do pilar Fiabilidade é fornecer funcionalidades contínuas ao criar resiliência suficiente e a capacidade de recuperar rapidamente de falhas.

Os princípios de conceção de Fiabilidade fornecem uma estratégia de conceção de alto nível aplicada a componentes individuais, fluxos de sistema e ao sistema como um todo.

As situações de fiabilidade a considerar para as áreas de trabalho do Log Analytics são:

  • Disponibilidade da área de trabalho.
  • Proteção dos dados recolhidos no caso raro de uma falha do datacenter ou região do Azure.

Atualmente, não existe nenhuma funcionalidade padrão para a ativação pós-falha entre áreas de trabalho em diferentes regiões, mas existem estratégias a utilizar se tiver requisitos específicos de disponibilidade ou conformidade.

Lista de verificação de design para Fiabilidade

Inicie a sua estratégia de conceção com base na lista de verificação de revisão de design para Fiabilidade e determine a sua relevância para os seus requisitos empresariais, tendo em atenção os SKUs e as funcionalidades das máquinas virtuais (VMs) e respetivas dependências. Expanda a estratégia para incluir mais abordagens conforme necessário.

  • Reveja os limites de serviço das áreas de trabalho do Log Analytics. A secção limites de serviço ajuda-o a compreender as restrições à recolha e retenção de dados e a outros aspetos do serviço. Estes limites ajudam-no a determinar como conceber corretamente a sua estratégia de observabilidade da carga de trabalho. Certifique-se de que revê os limites de serviço do Azure Monitor , uma vez que muitas das funções nele abordadas, como consultas, funcionam de mãos dadas com as áreas de trabalho do Log Analytics.
  • Planeie a resiliência e a recuperação da área de trabalho. As áreas de trabalho do Log Analytics são regionais, sem suporte incorporado para redundância ou replicação entre regiões. Além disso, as opções de redundância da zona de disponibilidade são limitadas. Como tal, deve determinar os requisitos de fiabilidade das áreas de trabalho e planear para cumprir esses objetivos. Os seus requisitos podem estipular que a área de trabalho tem de ser resiliente a falhas do datacenter ou a falhas regionais, ou podem estipular que tem de conseguir recuperar os dados para uma nova área de trabalho numa região de ativação pós-falha. Cada um destes cenários requer que sejam implementados recursos e processos adicionais para serem bem-sucedidos, pelo que deve ser cuidadosamente considerado o equilíbrio dos seus objetivos de fiabilidade com custo e complexidade.
  • Escolha as regiões de implementação adequadas para satisfazer os seus requisitos de fiabilidade. Implemente a área de trabalho do Log Analytics e os pontos finais de recolha de dados (DCEs) co-localizados com os componentes da carga de trabalho que emitem dados operacionais. A sua escolha da região adequada para implementar a área de trabalho e os DCEs deve ser informada pelo local onde implementa a carga de trabalho. Poderá ter de ponderar a disponibilidade regional de determinadas funcionalidades do Log Analytics, como clusters dedicados, face a outros fatores mais centrais para os requisitos de fiabilidade, custo e desempenho da carga de trabalho.
  • Certifique-se de que os seus sistemas de observabilidade estão em bom estado de funcionamento. Tal como qualquer outro componente da carga de trabalho, certifique-se de que os sistemas de monitorização e registo estão a funcionar corretamente. Para tal, ative as funcionalidades que enviam sinais de dados de estado de funcionamento às suas equipas de operações. Configure sinais de dados de estado de funcionamento específicos das áreas de trabalho do Log Analytics e dos recursos associados.

Recomendações de configuração para Fiabilidade

Recomendação Vantagem
Não inclua as áreas de trabalho do Log Analytics no caminho crítico da carga de trabalho. As áreas de trabalho são importantes para um sistema de observabilidade funcional, mas a funcionalidade da sua carga de trabalho não deve depender delas. Manter as áreas de trabalho e as 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 do runtime da carga de trabalho.
Para suportar a elevada durabilidade dos dados da área de trabalho, implemente áreas de trabalho do Log Analytics numa região que suporte resiliência de dados. A resiliência de dados só é possível através da ligação da área de trabalho a um cluster dedicado na mesma região. Quando utiliza um cluster dedicado, este permite-lhe distribuir as áreas de trabalho associadas pelas zonas de disponibilidade, que oferecem proteção contra falhas do datacenter. Se não recolher dados suficientes agora para justificar um cluster dedicado, esta escolha regional preventiva suporta o crescimento futuro.
Escolha a implementação da área de trabalho com base na proximidade da carga de trabalho.

Utilize pontos finais de recolha de dados (DCE) na mesma região que a área de trabalho do Log Analytics.		 Implemente a área de trabalho na mesma região que as instâncias da carga de trabalho. Ter a área de trabalho e os DCEs na mesma região que a carga de trabalho mitiga o risco de impactos por interrupções noutras regiões.

Os DCEs são utilizados pelo agente do Azure Monitor e pela API de Ingestão de Registos para enviar dados operacionais da carga de trabalho para uma área de trabalho do Log Analytics. Poderá precisar de vários DCEs, embora a sua implementação tenha apenas uma única área de trabalho. Para obter mais informações sobre como configurar DCEs para o seu ambiente específico, veja Como configurar pontos finais de recolha de dados com base na sua implementação.<br
Se a carga de trabalho estiver implementada num design ativo-ativo, considere utilizar várias áreas de trabalho e DCEs distribuídos pelas regiões em que a carga de trabalho é implementada.

A implementação de áreas de trabalho em várias regiões adiciona complexidade ao seu ambiente. Equilibre os critérios detalhados em Estruturar uma arquitetura de área de trabalho do Log Analytics com os seus requisitos de disponibilidade.
Se precisar que a área de trabalho esteja disponível numa falha de região ou não recolher dados suficientes para um cluster dedicado, configure a recolha de dados para enviar dados críticos para várias áreas de trabalho em regiões diferentes. Esta prática também é conhecida como multicasting de registos.

Por exemplo, configure DCRs para várias áreas de trabalho para o agente do Azure Monitor em execução em VMs. Configure várias definições de diagnóstico para recolher registos de recursos dos recursos do Azure e enviar os registos para várias áreas de trabalho.
Desta forma, os dados operacionais da carga de trabalho estão disponíveis na área de trabalho alternativa se ocorrer uma falha regional. Mas saiba que os recursos que dependem dos dados, como alertas e livros, não seriam replicados automaticamente para as outras regiões. Considere armazenar modelos do Azure Resource Manager (ARM) para recursos de alerta críticos com configuração para a área de trabalho alternativa ou implementá-los em todas as regiões, mas desativá-los para impedir alertas redundantes. Ambas as opções suportam a ativação rápida numa falha regional.

Desvantagem: esta configuração resulta em custos de ingestão e retenção duplicados, pelo que só a utiliza para dados críticos.
Se precisar que os dados sejam protegidos numa falha de datacenter ou região, configure a exportação de dados da área de trabalho para guardar dados numa localização alternativa.

Esta opção é semelhante à opção anterior de multicasting dos dados para diferentes áreas de trabalho. No entanto, esta opção custa menos porque os dados adicionais são escritos no armazenamento.

Utilize as opções de redundância do Armazenamento do Azure, incluindo armazenamento georredundante (GRS) e armazenamento com redundância entre zonas geográficas (GZRS), para replicar ainda mais estes dados para outras regiões.

A exportação de dados não fornece resiliência relativamente a incidentes que afetam o pipeline de ingestão regional.		 Embora os dados de registo operacional histórico possam não ser facilmente consultados no estado exportado, garante que os dados sobrevivem a uma interrupção regional prolongada e podem ser acedidos e retidos durante um período prolongado.

Se precisar da exportação de tabelas não suportadas pela exportação de dados, pode utilizar outros métodos de exportação de dados, incluindo o Logic Apps, para proteger os seus dados.

Para que esta estratégia funcione como um plano de recuperação viável, tem de ter processos implementados para reconfigurar as definições de diagnóstico dos seus recursos no Azure e em todos os agentes que fornecem dados. Também tem de planear reidratar manualmente os dados exportados para uma nova área de trabalho. Tal como acontece com a opção descrita anteriormente, também tem de definir processos para os recursos que dependem dos dados, como alertas e livros.
Para cargas de trabalho fundamentais para a atividade que requerem elevada disponibilidade, considere implementar um modelo de área de trabalho federado que utiliza várias áreas de trabalho para fornecer elevada disponibilidade se ocorrer uma falha regional. O mission-critical fornece orientações prescritivas de melhores práticas para conceber aplicações altamente fiáveis no Azure. A metodologia de conceção inclui um modelo de área de trabalho federado com várias áreas de trabalho do Log Analytics para proporcionar elevada disponibilidade se existirem várias falhas, incluindo a falha de uma região do Azure.

Esta estratégia elimina os custos de saída entre regiões e permanece operacional com uma falha de região. No entanto, requer mais complexidade que tem de gerir com a configuração e os processos descritos em Modelação do estado de funcionamento e observabilidade de cargas de trabalho fundamentais para a missão no Azure.
Utilize a infraestrutura como código (IaC) para implementar e gerir as áreas de trabalho e as funções associadas. Quando automatiza tanto a sua implementação como os seus mecanismos de resiliência e recuperação como práticos, garante que estas operações são fiáveis. Poupa tempo crítico nos seus processos de operações e minimiza o risco de erro humano.

Certifique-se de que funções como consultas de registo guardadas também são definidas através do iaC para recuperá-las para uma nova região, se for necessária a recuperação.
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 conceber regras estreitamente focadas que dependem de menos origens de dados. Utilize a composição das atribuições de regras para chegar ao âmbito de observabilidade pretendido para o destino lógico.

Além disso, minimize a transformação em DCRs		 Quando utiliza DCRs estreitamente focados, minimiza o risco de uma configuração incorreta de uma regra ter um efeito mais amplo. Limita o efeito apenas ao âmbito para o qual o DCR foi criado. Para obter mais informações, veja Melhores práticas para a criação e gestão de regras de recolha de dados no Azure Monitor.

Embora a transformação possa ser poderosa e necessária em algumas situações, pode ser difícil testar e resolver problemas com o trabalho da linguagem de consulta de palavras-chave (KQL) que está a ser feito. Sempre que possível, minimize o risco de perda de dados ao ingerir os dados não processados e processar transformações a jusante no momento da consulta.
Ao definir um limite diário ou uma política de retenção, certifique-se de que mantém os seus requisitos de fiabilidade ao ingerir e manter os registos de que precisa. Um limite diário interrompe a recolha de dados de uma área de trabalho assim que for atingido um montante especificado, o que o ajuda a manter o controlo sobre o volume de ingestão. Mas utilize esta funcionalidade apenas após um planeamento cuidadoso. Certifique-se de que o limite diário não está a ser atingido com regularidade. Se isso acontecer, o limite é definido de forma demasiado restritiva. Tem de reconfigurar o limite diário para não perder sinais críticos provenientes da carga de trabalho.

Da mesma forma, certifique-se de que se aproxima cuidadosamente e cuidadosamente da redução da política de retenção de dados para garantir que não perde inadvertidamente dados críticos.
Utilize as informações da área de trabalho do Log Analytics para controlar o volume de ingestão, os dados ingeridos em comparação com o limite de dados, as origens de registo sem resposta e as consultas falhadas entre outros dados. Crie alertas de estado de funcionamento para notificá-lo proativamente se uma área de trabalho ficar indisponível devido a uma falha do datacenter ou regional. Esta estratégia garante que consegue monitorizar com êxito o estado de funcionamento das áreas de trabalho e agir proativamente se o estado de funcionamento estiver em risco de degradação. Tal como qualquer outro componente da carga de trabalho, é fundamental que esteja ciente das métricas de estado de funcionamento e possa identificar tendências para melhorar a fiabilidade ao longo do tempo.

Azure Policy

O Azure não oferece políticas relacionadas com a fiabilidade das áreas de trabalho do Log Analytics. Pode criar políticas personalizadas para criar proteções de conformidade em torno das implementações da área de trabalho, como garantir que as áreas de trabalho estão associadas a um cluster dedicado.

Embora não esteja diretamente relacionado com a fiabilidade das áreas de trabalho do Log Analytics, existem políticas do Azure para quase todos os serviços disponíveis. As políticas garantem que as definições de diagnóstico estão ativadas para esse serviço e validam que os dados de registo do serviço estão a fluir para uma área de trabalho do Log Analytics. Todos os serviços na arquitetura da carga de trabalho devem enviar os respetivos dados de registo para uma área de trabalho do Log Analytics para as suas próprias necessidades de fiabilidade e as políticas podem ajudar a aplicá-la. Da mesma forma, existem políticas para garantir que as plataformas baseadas em agentes, como as VMs e o Kubernetes, têm o agente instalado.

Assistente do Azure

O Azure não oferece recomendações do Assistente do Azure relacionadas com a fiabilidade das áreas de trabalho do Log Analytics.

Segurança

O objetivo do pilar Segurança é fornecer garantias de confidencialidade, integridade e disponibilidade à carga de trabalho.

Os princípios de conceção de segurança fornecem uma estratégia de conceção de alto nível para atingir estes objetivos ao aplicar abordagens à estrutura técnica em torno da sua solução de monitorização e registo.

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

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

  • Reveja os tópicos Linha de base de segurança do Azure Monitor e Gerir o acesso às áreas de trabalho do Log Analytics. Estes tópicos fornecem orientações sobre as melhores práticas de segurança.
  • Implemente as áreas de trabalho com a 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 as áreas de trabalho estão isoladas ao nível adequado e estão melhor protegidas contra o acesso não autorizado ao mais alto grau possível, ao mesmo tempo que cumprem os seus requisitos empresariais de fiabilidade, otimização de custos, excelência operacional e eficiência de desempenho.
  • Certifique-se de que pode auditar as atividades de leitura e escrita da área de trabalho e as identidades associadas. Os atacantes podem beneficiar da visualização de registos operacionais. Uma identidade comprometida pode levar a ataques de injeção de registos. Ative a auditoria de operações executadas a partir do Portal do Azure ou através de interações de API e dos utilizadores associados. Se não estiver configurado para auditar a área de trabalho, poderá estar a colocar a sua organização em risco de violar os requisitos de conformidade.
  • Implementar controlos de rede robustos. Ajuda a proteger o acesso de rede à área de trabalho e aos registos através do isolamento de rede e das funções de firewall. Controlos de rede configurados insuficientemente podem colocá-lo em risco de ser acedido por atores não autorizados ou maliciosos.
  • Determine que tipos de dados precisam de imutabilidade ou retenção de longo prazo. Os dados de registo devem ser tratados com o mesmo rigor que os dados da carga de trabalho dentro dos sistemas de produção. Inclua dados de registo nas práticas de classificação de dados para garantir que está a armazenar dados de registo confidenciais com êxito de acordo com os requisitos de conformidade.
  • Proteja os dados de registo inativos através da encriptação. A segmentação por si só não protege completamente a confidencialidade dos seus dados de registo. Se o acesso não autorizado não processado ocorrer, ter os dados de registo encriptados inativos ajuda a impedir que os agentes incorretos utilizem esses dados fora da área de trabalho.
  • Proteja os dados de registo confidenciais através da obfuscação. Tal como os dados da carga de trabalho que residem em sistemas de produção, tem de tomar medidas adicionais para garantir que a confidencialidade é mantida para informações confidenciais que possam estar presentes intencional ou não nos registos operacionais. Quando utiliza métodos de obfuscation, este ajuda-o a ocultar dados de registo confidenciais de olhos não autorizados.

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

Recomendação Vantagem
Utilize chaves geridas pelo cliente se precisar da sua própria chave de encriptação para proteger dados e consultas guardadas nas áreas de trabalho.

O Azure Monitor garante que todos os dados e consultas guardadas são encriptados inativos com chaves geridas pela Microsoft (MMK). Se precisar da sua própria chave de encriptação e recolher dados suficientes para um cluster dedicado, utilize a chave gerida pelo cliente. Pode encriptar dados com a 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 utilizar o Microsoft Sentinel, certifique-se de que está familiarizado com as considerações em Configurar a chave gerida pelo cliente do Microsoft Sentinel.		 Esta estratégia permite-lhe encriptar dados com a 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 consultas de registo para controlar que utilizadores estão a executar consultas.

Configure os registos de auditoria para que cada área de trabalho seja enviada para a área de trabalho local ou consolide numa área de trabalho de segurança dedicada se separar os dados operacionais e de segurança. Utilize as informações da área de trabalho do Log Analytics para rever periodicamente estes dados. Considere criar regras de alerta de consulta de registo para notificá-lo proativamente se os utilizadores não autorizados estiverem a tentar executar consultas.		 A auditoria de consultas de registo regista os detalhes de cada consulta executada numa área de trabalho. Trate estes dados de auditoria como dados de segurança e proteja adequadamente a tabela LAQueryLogs . Esta estratégia reforça a sua postura de segurança ao ajudar a garantir que o acesso não autorizado é capturado imediatamente se isso acontecer.
Ajude a proteger a sua área de trabalho através de redes privadas e medidas de segmentação.

Utilize a funcionalidade de ligação privada para limitar as comunicações entre as origens de registo e as áreas de trabalho para redes privadas.		 Quando utiliza uma ligação privada, também lhe permite controlar que redes virtuais podem aceder a uma determinada área de trabalho, reforçando ainda mais a sua segurança através da segmentação.
Utilize Microsoft Entra ID em vez de chaves de API para acesso à API da área de trabalho, sempre que disponível. O acesso baseado na chave de API às APIs de consulta não deixa um registo de auditoria por cliente. Utilize o acesso baseado em Entra ID com âmbito suficiente para que possa auditar corretamente o acesso programático.
Configure o acesso para diferentes tipos de dados na área de trabalho necessárias para diferentes funções na sua organização.

Defina o modo de controlo de acesso para a área de trabalho como Utilizar permissões de recursos ou áreas de trabalho. Este controlo de acesso permite que os proprietários de recursos utilizem o contexto de recursos para aceder aos respetivos dados sem que lhe seja concedido acesso explícito à área de trabalho.

Utilize o RBAC ao nível da tabela para os utilizadores que necessitam de acesso a um conjunto de tabelas em vários recursos.		 Esta definição simplifica a configuração da área de trabalho e ajuda a garantir que os utilizadores não conseguem aceder aos dados operacionais que não devem.

Atribua a função incorporada adequada para conceder permissões de área de trabalho aos administradores ao nível da subscrição, do grupo de recursos ou da área de trabalho, consoante o âmbito das responsabilidades.

Os utilizadores com permissões de tabela têm acesso a todos os dados na tabela, independentemente das respetivas permissões de recursos.

Veja Gerir o acesso às áreas de trabalho do Log Analytics para obter detalhes sobre as diferentes opções para conceder acesso aos dados na área de trabalho.
Exportar registos que requerem retenção ou imutabilidade de longo prazo.

Utilize 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 adulteração de dados. Nem todos os tipos de registo têm a mesma relevância para conformidade, auditoria ou segurança, por isso determine os tipos de dados específicos que devem ser exportados.		 Pode recolher dados de auditoria na área de trabalho sujeitos a regulamentos que exijam a retenção a longo prazo. Os dados numa área de trabalho do Log Analytics não podem ser alterados, mas podem ser removidos. Exportar uma cópia dos dados operacionais para efeitos de retenção permite-lhe criar uma solução que cumpra os seus requisitos de conformidade.
Determine uma estratégia para filtrar ou ocultar dados confidenciais na área de trabalho.

Poderá estar a recolher dados que incluam informações confidenciais. Filtre registos que não devem ser recolhidos através da configuração da origem de dados específica. Utilize uma transformação se apenas colunas específicas nos dados forem removidas ou ocultadas.

Se tiver normas que exijam que os dados originais não sejam modificados, pode utilizar o literal "h" nas consultas KQL para ocultar os resultados da consulta apresentados nos livros.		 Ocultar ou filtrar dados confidenciais na sua área de trabalho ajuda a garantir a confidencialidade das informações confidenciais. Em muitos casos, os requisitos de conformidade ditam as formas de lidar com informações confidenciais. Esta estratégia ajuda-o a cumprir proativamente os requisitos.

Azure Policy

O Azure oferece políticas relacionadas com a segurança das áreas de trabalho do Log Analytics para ajudar a impor a postura de segurança pretendida. Exemplos dessas políticas são:

O Azure também oferece várias políticas para ajudar a impor a configuração de ligações privadas, como as áreas de trabalho do Log Analytics, deve bloquear a ingestão de registos e a consulta a partir de redes públicas ou até mesmo configurar a solução através de políticas de DINE, como Configurar o Azure Monitor Private Link Âmbito para utilizar zonas DNS privadas.

Assistente do Azure

O Azure não oferece recomendações do Assistente do Azure relacionadas com a segurança das áreas de trabalho do Log Analytics.

Otimização de Custos

A Otimização de Custos concentra-se na deteção de padrões de gastos, na atribuição de prioridades a investimentos em áreas críticas e na otimização noutros para cumprir o orçamento da organização ao cumprir os requisitos empresariais.

Os princípios de conceção da Otimização de Custos fornecem uma estratégia de design de alto nível para alcançar esses objetivos empresariais. Também o ajudam a fazer trocas conforme necessário na estrutura técnica relacionada com a sua solução de monitorização e registo.

Para obter mais informações sobre como os custos de dados são calculados para as áreas de trabalho do Log Analytics, veja Cálculos e opções de custos dos Registos do Azure Monitor.

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

Inicie a sua estratégia de conceção com base na lista de verificação de revisão de design para Otimização de Custos para investimentos e ajuste a estrutura para que a carga de trabalho esteja alinhada com o orçamento atribuído à carga de trabalho. A sua estrutura deve utilizar as capacidades certas do Azure, monitorizar os investimentos e encontrar oportunidades para otimizar ao longo do tempo.

  • Realizar exercícios de modelação de custos. Estes exercizes ajudam-no a compreender os custos atuais da área de trabalho e a prever os custos relativos ao crescimento da área de trabalho. Analise as tendências de crescimento na carga de trabalho e certifique-se de que compreende os planos de expansão da carga de trabalho para prever corretamente os seus futuros custos de registo operacional.
  • Escolha o modelo de faturação correto. Utilize o modelo de custos para determinar o melhor modelo de faturação para o seu cenário. A forma como utiliza as suas áreas de trabalho atualmente e como planeia utilizá-las à medida que a carga de trabalho evolui determina se um modelo pay as you go ou de escalão de alocação é o mais adequado para o seu cenário.

    Lembre-se de que pode escolher diferentes modelos de faturação para cada área de trabalho e pode combinar os custos da área de trabalho em determinados casos, para que possa ser granular na sua análise e tomada de decisões.
  • Recolha a quantidade certa de dados de registo. Efetue análises agendadas regularmente das definições de diagnóstico nos seus recursos, configuração de regras de recolha de dados e registo de códigos de aplicações personalizados para garantir que não está a recolher dados de registo desnecessários.
  • Trate os ambientes de não produção de forma diferente da produção. Reveja os ambientes de não produção para garantir que configurou adequadamente as definições de diagnóstico e as políticas de retenção. Muitas vezes, estes podem ser significativamente menos robustos do que a produção, especialmente para ambientes de desenvolvimento/teste ou sandbox.

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

Recomendação Vantagem
Configure o escalão de preço para a quantidade de dados que cada área de trabalho do Log Analytics normalmente recolhe. Por predefinição, as áreas de trabalho do Log Analytics utilizam preços pay as you go sem volume de dados mínimo. Se recolher dados suficientes, pode diminuir significativamente o seu custo através de um escalão de alocação, o que lhe permite consolidar um mínimo diário de dados recolhidos em troca de uma taxa mais baixa. Se recolher dados suficientes em áreas de trabalho numa única região, pode ligá-los a um cluster dedicado e combinar o volume recolhido através dos preços do cluster.

Para obter mais informações sobre os escalões de alocação e documentação de orientação sobre como determinar o que é mais adequado para o seu nível de utilização, veja Cálculos e opções de custos dos Registos do Azure Monitor. Para ver os custos estimados da utilização em diferentes escalões de preço, veja Utilização e custos estimados.
Configurar a retenção de dados e o arquivo. Existe um custo para reter dados numa área de trabalho do Log Analytics para além da predefinição de 31 dias. São 90 dias se o Microsoft Sentinel estiver ativado na área de trabalho e 90 dias para os dados do Application Insights. Considere os seus requisitos específicos para ter dados prontamente disponíveis para consultas de registo. Pode reduzir significativamente os custos ao configurar registos arquivados. Os registos arquivados permitem-lhe reter dados até sete anos e continuar a aceder-lhe ocasionalmente. Pode aceder aos dados com tarefas de pesquisa ou restaurar um conjunto de dados para a área de trabalho.
Se utilizar o Microsoft Sentinel para analisar os registos de segurança, considere utilizar uma área de trabalho separada para armazenar esses registos. Quando utiliza uma área de trabalho dedicada para dados de registo que o SIEM utiliza, pode ajudá-lo a controlar os custos. As áreas de trabalho que o Microsoft Sentinel utiliza estão sujeitas aos preços do Microsoft Sentinel. Os seus requisitos de segurança ditam os tipos de registos que têm de ser incluídos na sua solução SIEM. Poderá excluir registos operacionais, que seriam cobrados nos preços padrão do Log Analytics se estiverem numa área de trabalho separada.
Configure tabelas utilizadas para depuração, resolução de problemas e auditoria como Registos Básicos. As tabelas numa área de trabalho do Log Analytics configurada para Registos Básicos têm um custo de ingestão mais baixo em troca de funcionalidades limitadas e um custo para consultas de registo. Se consultar estas tabelas com pouca frequência e não as utilizar para alertas, este custo de consulta pode ser mais do que compensado pelo custo de ingestão reduzido.
Limitar a recolha de dados de origens de dados para a área de trabalho. O principal fator para o custo do Azure Monitor é a quantidade de dados que recolhe na área de trabalho do Log Analytics. Certifique-se de que não recolhe mais dados do que o necessário para avaliar o estado de funcionamento e o desempenho dos seus serviços e aplicações. Para cada recurso, selecione as categorias certas para as definições de diagnóstico que configurar para fornecer a quantidade de dados operacionais de que precisa. Ajuda-o a gerir com êxito a carga de trabalho e não a gerir dados ignorados.

Poderá existir uma troca entre os custos e os seus requisitos de monitorização. Por exemplo, poderá conseguir detetar um problema de desempenho mais rapidamente com uma taxa de exemplo elevada, mas poderá querer uma taxa de exemplo mais baixa para poupar custos. A maioria dos ambientes tem múltiplas origens de dados com diferentes tipos de coleção, pelo que tem de equilibrar os seus requisitos específicos com os seus objetivos de custos para cada um. Veja Otimização de custos no Azure Monitor para obter recomendações sobre como configurar a recolha para diferentes origens de dados.
Analise regularmente os dados de utilização da área de trabalho para identificar tendências e anomalias.

Utilize as informações da área de trabalho do Log Analytics para rever periodicamente a quantidade de dados recolhidos na área de trabalho. Analise ainda mais a recolha de dados através de métodos em Analisar a utilização na área de trabalho do Log Analytics para determinar se existem outras configurações que possam diminuir ainda mais a sua utilização.		 Ao ajudá-lo a compreender a quantidade de dados recolhidos por diferentes origens, identifica anomalias e tendências ascendentes na recolha de dados que podem resultar em custos excessivos. Esta consideração é importante quando adiciona um novo conjunto de origens de dados à carga de trabalho. Por exemplo, se adicionar um novo conjunto de VMs, ative novas definições de diagnóstico do Azure num serviço ou altere os níveis de registo na sua aplicação.
Crie um alerta quando a recolha de dados for elevada. Para evitar faturas inesperadas, deve ser notificado proativamente sempre que tiver utilização excessiva. A notificação permite-lhe resolver eventuais anomalias antes do fim do período de faturação.
Considere um limite diário como uma medida preventiva para garantir que não excede um orçamento específico. Um limite diário desativa a recolha de dados numa área de trabalho do Log Analytics durante o resto do dia após o limite configurado ser atingido. Não utilize esta prática como método para reduzir os custos conforme descrito em Quando utilizar um limite diário, mas sim para evitar a ingestão em fuga devido a configuração incorreta ou abuso.

Se definir um limite diário, crie um alerta quando o limite for atingido. Certifique-se de que também cria uma regra de alerta quando alguma percentagem for atingida. Por exemplo, pode definir uma regra de alerta para quando a capacidade de 90% for atingida. Este alerta dá-lhe a oportunidade de investigar e resolver a causa do aumento dos dados antes de o limite encerrar a recolha de dados crítica da carga de trabalho.

Azure Policy

O Azure não oferece políticas relacionadas com a otimização de custos das áreas de trabalho do Log Analytics. Pode criar políticas personalizadas para criar proteções de conformidade em torno das implementações da área de trabalho, como garantir que as áreas de trabalho contêm as definições de retenção corretas.

Assistente do Azure

O Assistente do Azure faz recomendações para mover tabelas específicas numa área de trabalho para o plano de dados de Registo Básico de baixo custo para tabelas que recebem um volume de ingestão relativamente elevado. Compreenda as limitações ao utilizar registos básicos antes de mudar. Para obter mais informações, consulte Quando devo utilizar os Registos Básicos?. O Assistente do Azure também pode recomendar a alteração do escalão de alocação de preços para toda a área de trabalho com base no volume de utilização geral.

Excelência Operacional

A Excelência Operacional centra-se principalmente nos procedimentos de práticas de desenvolvimento, observabilidade e gestão de versões.

Os princípios de design de Excelência Operacional fornecem uma estratégia de design de alto nível para alcançar esses objetivos para os requisitos operacionais da carga de trabalho.

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

Inicie a sua estratégia de conceção com base na lista de verificação de revisão de design para Excelência Operacional para definir processos de observabilidade, teste e implementação relacionados com áreas de trabalho do Log Analytics.

  • Utilize a infraestrutura como código (IaC) para todas as funções relacionadas com as áreas de trabalho do Log Analytics da carga de trabalho. Minimize o risco de erro humano que pode ocorrer ao administrar e operar manualmente as funções de recolha, ingestão, armazenamento e consulta de registos, incluindo consultas guardadas e pacotes de consultas, automatizando o maior número possível dessas funções através do código. Além disso, inclua alertas que reportam alterações ao estado de funcionamento e a configuração das definições de diagnóstico dos recursos que enviam registos para as áreas de trabalho no código IaC. Inclua o código com o outro código relacionado com a carga de trabalho para garantir que as suas práticas de implementação seguras são mantidas para a gestão das áreas de trabalho.
  • Certifique-se de que as áreas de trabalho estão em bom estado de funcionamento e que é notificado quando surgirem problemas. Tal como qualquer outro componente da carga de trabalho, as áreas de trabalho podem encontrar problemas. Os problemas podem custar tempo e recursos valiosos para resolver problemas e, potencialmente, deixar a sua equipa desconheça o estado da carga de trabalho de produção. A capacidade de monitorizar proativamente áreas de trabalho e mitigar potenciais problemas ajuda as equipas de operações a minimizar o tempo que passam a resolver problemas.
  • Separe a produção das cargas de trabalho de não produção. Evite complexidades desnecessárias que possam causar trabalho extra para uma equipa de operações ao utilizar áreas de trabalho diferentes para o seu ambiente de produção do que as utilizadas por ambientes de não produção. Os dados recebidos também podem causar confusão, uma vez que as atividades de teste podem parecer eventos em produção.
  • Preferir ferramentas e funções incorporadas em vez de soluções que não sejam da Microsoft Utilize ferramentas incorporadas para expandir a funcionalidade dos seus sistemas de monitorização e registo. Poderá ter de implementar configurações adicionais para suportar requisitos como a capacidade de recuperação ou a soberania de dados que não estão disponíveis fora da caixa com áreas de trabalho do Log Analytics. Nestes casos, sempre que for prático, utilize ferramentas nativas do Azure ou da Microsoft para manter o número de ferramentas que a sua organização tem de suportar no mínimo.
  • Tratar as áreas de trabalho como componentes estáticos em vez de efémeros À semelhança de outros tipos de arquivos de dados, as áreas de trabalho não devem ser consideradas entre os componentes efémeros da sua carga de trabalho. Geralmente, o Framework de Well-Architected favorece a infraestrutura imutável e a capacidade de substituir recursos de forma rápida e fácil na sua carga de trabalho como parte das suas implementações. Contudo, a perda de dados da área de trabalho pode ser catastrófica e irreversível. Por este motivo, deixe as áreas de trabalho fora dos pacotes de implementação que substituem a infraestrutura durante as atualizações e efetue apenas atualizações no local nas áreas de trabalho.
  • Certifique-se de que o pessoal de operações está preparado para Linguagem de Pesquisa Kusto Preparar pessoal para criar ou modificar consultas quando necessário. Se os operadores não conseguirem escrever ou modificar consultas, pode abrandar a resolução de problemas críticos ou outras funções, uma vez que os operadores têm de depender de outras equipas para que funcionem para as mesmas.

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

Recomendação Vantagem
Crie uma estratégia de área de trabalho para satisfazer os seus requisitos empresariais.

Veja Estruturar uma arquitetura de área de trabalho do Log Analytics para obter orientações sobre a conceção de uma estratégia para as suas áreas de trabalho do Log Analytics. Inclua quantos para criar e onde colocá-los.

Se precisar da carga de trabalho para utilizar uma oferta de equipa de plataforma centralizada, certifique-se de que define todo o acesso operacional necessário. Além disso, crie alertas para garantir que as necessidades de observabilidade da carga de trabalho são satisfeitas.		 Um número único ou mínimo de áreas de trabalho maximizam a eficiência operacional da carga de trabalho. Limita a distribuição dos seus dados operacionais e de segurança, aumenta a visibilidade sobre potenciais problemas, facilita a identificação dos padrões e minimiza os seus requisitos de manutenção.

Pode ter requisitos para várias áreas de trabalho, como vários inquilinos, ou pode precisar de áreas de trabalho em várias regiões para suportar os seus requisitos de disponibilidade. Por isso, certifique-se de que tem processos adequados para gerir esta complexidade acrescida.
Utilize a infraestrutura como código (IaC) para implementar e gerir as áreas de trabalho e as funções associadas. Utilize a infraestrutura como código (IaC) para definir os detalhes das suas áreas de trabalho em modelos arm, Azure BICEP ou Terraform. Permite-lhe utilizar os seus processos de DevOps existentes para implementar novas áreas de trabalho e Azure Policy para impor a configuração.

Colocar todo o código IaC no código da aplicação ajuda a garantir que as suas práticas de implementação seguras são mantidas para todas as implementações.
Utilize as informações da área de trabalho do Log Analytics para controlar o estado de funcionamento e o desempenho das áreas de trabalho do Log Analytics e crie alertas significativos e acionáveis para serem notificados proativamente de problemas operacionais.

As informações da área de trabalho do Log Analytics fornecem uma vista unificada da utilização, desempenho, estado de funcionamento, agentes, consultas e registo de alterações para todas as áreas de trabalho.

Cada área de trabalho tem uma tabela de operações que regista atividades importantes que afetam a área de trabalho.		 Reveja as informações que as informações do Log Analytics fornecem regularmente para controlar o estado de funcionamento e o funcionamento de cada uma das suas áreas de trabalho. Quando utiliza estas informações, esta permite-lhe criar visualizações facilmente compreendidas, como dashboards ou relatórios que as operações e os intervenientes podem utilizar para controlar o estado de funcionamento das suas áreas de trabalho.

Crie regras de alerta com base nesta tabela para ser notificado proativamente quando ocorrer um problema operacional. Pode utilizar alertas recomendados para a área de trabalho para simplificar a forma como cria as regras de alerta mais críticas.
Pratique melhorias contínuas ao revisitar frequentemente as definições de diagnóstico do Azure nos seus recursos, regras de recolha de dados e verbosidade do registo de aplicações.

Certifique-se de que está a otimizar a sua estratégia de recolha de registos através de revisões frequentes das definições de recursos. Do ponto de vista operacional, procure reduzir o ruído nos seus registos ao concentrar-se nos registos que fornecem informações úteis sobre o estado de funcionamento de um recurso.		 Ao otimizar desta forma, permite que os operadores investiguem e resolvam problemas quando surgem ou realizem outras tarefas de rotina, improvisadas ou de emergência.

Quando forem disponibilizadas novas categorias de diagnóstico para um tipo de recurso, reveja os tipos de registos emitidos com esta categoria para compreender se a sua ativação poderá ajudá-lo a otimizar a sua estratégia de coleção. Por exemplo, uma nova categoria pode ser um subconjunto de um conjunto maior de atividades que estão a ser capturadas. O novo subconjunto poderá permitir-lhe reduzir o volume de registos que estão a ser recebidos ao concentrar-se nas atividades que são importantes para as suas operações controlarem.

Azure Policy e Assistente do Azure

O Azure não oferece políticas nem recomendações do Assistente do Azure relacionadas com a excelência operacional das áreas de trabalho do Log Analytics.

Eficiência de desempenho

A Eficiência de Desempenho tem a ver com a manutenção da experiência do utilizador, mesmo quando existe um aumento de carga através da gestão da capacidade. A estratégia inclui dimensionar recursos, identificar e otimizar potenciais estrangulamentos e otimizar o desempenho máximo.

Os princípios de design de Eficiência de Desempenho fornecem uma estratégia de design de alto nível para alcançar esses objetivos de capacidade face à utilização esperada.

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

Inicie a sua estratégia de conceção com base na lista de verificação de revisão de design para Eficiência de Desempenho para definir uma linha de base para as suas áreas de trabalho do Log Analytics e funções associadas.

  • Familiarize-se com as noções básicas da latência de ingestão de dados de registo no Azure Monitor. Existem vários fatores que contribuem para a latência ao ingerir registos nas áreas de trabalho. Muitos destes fatores são inerentes à plataforma do Azure Monitor. Compreender os fatores e o comportamento de latência normal pode ajudá-lo a definir as expectativas adequadas nas suas equipas de operações de carga de trabalho.
  • Separe as cargas de trabalho de não produção e de produção. As áreas de trabalho específicas da produção mitigam qualquer sobrecarga que os sistemas de não produção possam introduzir. Reduz a pegada geral das áreas de trabalho, exigindo menos recursos para processar o processamento de dados de registo.
  • Escolha as regiões de implementação certas para cumprir os seus requisitos de desempenho. Implemente a área de trabalho do Log Analytics e os pontos finais de recolha de dados (DCEs) perto da carga de trabalho. A sua escolha da região adequada para implementar a área de trabalho e os DCEs deve ser informada pelo local onde implementa a carga de trabalho. Poderá ter de ponderar os benefícios de desempenho da implementação das áreas de trabalho e dos DCEs na mesma região que a carga de trabalho em relação aos seus requisitos de fiabilidade se já tiver implementado a carga de trabalho numa região que não possa suportar esses requisitos para os seus dados de registo.

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

Recomendação Vantagem
Configure a auditoria de consultas de registo e utilize as informações da área de trabalho do Log Analytics para identificar consultas lentas e ineficientes.

A auditoria de consultas de registo armazena o tempo de computação necessário para executar cada consulta e a hora até que os resultados sejam devolvidos. As informações da área de trabalho do Log Analytics utilizam estes dados para listar consultas potencialmente ineficientes na sua área de trabalho. Considere reescrever estas consultas para melhorar o desempenho. Veja Otimizar consultas de registo no Azure Monitor para obter orientações sobre como otimizar as consultas de registo.		 As consultas otimizadas devolvem resultados mais rapidamente e utilizam menos recursos no back-end, o que torna os processos que dependem dessas consultas também mais eficientes.
Compreender os limites de serviço das áreas de trabalho do Log Analytics.

Em determinadas implementações de tráfego elevado, poderá deparar-se com limites de serviço que afetam o desempenho e a estrutura da área de trabalho ou da carga de trabalho. Por exemplo, a API de consulta limita o número de registos e o volume de dados devolvidos por uma consulta. A API de Ingestão de Registos limita o tamanho de cada chamada à API.

Para obter uma lista completa dos limites e limites das áreas de trabalho do Azure Monitor e do Log Analytics específicos da área de trabalho, veja Limites de serviço do Azure Monitor.		 Compreender os limites que podem afetar o desempenho da área de trabalho ajuda-o a conceber adequadamente para os mitigar. Pode optar por utilizar várias áreas de trabalho para evitar atingir limites associados a uma única área de trabalho.

Pondere as decisões de conceção para mitigar os limites de serviço em relação a requisitos e destinos para outros pilares.
Crie DCRs específicos para tipos de origem de dados dentro de um ou mais âmbitos de observabilidade definidos. Crie DCRs separados para desempenho e eventos para otimizar a utilização da computação de processamento de back-end. Quando utiliza DCRs separados para desempenho e eventos, ajuda a mitigar o esgotamento dos recursos de back-end. Ao ter DCRs que combinam eventos de desempenho, 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. Pode ocorrer um consumo excessivo de recursos de computação e erros no processamento de uma configuração e fazer com que o Agente do Azure Monitor (AMA) não responda.

Azure Policy e Assistente do Azure

O Azure não oferece políticas nem recomendações do Assistente do Azure relacionadas com o desempenho das áreas de trabalho do Log Analytics.

Passo seguinte