Compartilhar via


Práticas recomendadas para criação e gerenciamento de regras de coleta de dados no Azure Monitor

As DCRs (Regras de Coleta de Dados) determinam como coletar e processar a telemetria enviada ao Azure. Algumas regras de coleta de dados são criadas e gerenciadas pelo Azure Monitor, enquanto você pode criar outras para personalizar a coleta de dados para seus requisitos específicos. Este artigo discute algumas práticas recomendadas que devem ser aplicadas ao criar seus próprios DCRs.

Quando você cria um DCR, há alguns aspectos que precisam ser considerados, como:

  • O tipo de dados coletados, também conhecido como tipo de fonte de dados (desempenho, eventos)
  • As Máquinas Virtuais de destino às quais o DCR está associado
  • O destino dos dados coletados

Considerar todos esses fatores é essencial para uma boa organização de DCR. Todos os pontos acima afetam o esforço de gerenciamento de DCR, bem como o consumo de recursos para transferência e processamento de configuração.

Dada a granularidade nativa, que permite que um determinado DCR seja associado a mais de uma máquina virtual de destino e vice-versa, é importante manter os DCRs o mais simples possível usando menos fontes de dados cada uma. Também é importante manter a lista de itens coletados em cada fonte de dados enxuta e orientada para o escopo de observabilidade.

Captura de tela das regras de coleta de dados para a relação de máquinas virtuais.

Para esclarecer o que poderia ser um escopo de observabilidade , pense nele como seu limite lógico preferido para coletar dados. Por exemplo, um escopo possível pode ser um conjunto de máquinas virtuais que executam software (por exemplo, SQL Servers) necessárias para um aplicativo específico ou contadores básicos do sistema operacional ou conjunto de eventos usados pelos administradores de TI. Também é possível criar escopos semelhantes dedicados a ambientes diferentes (Desenvolvimento, Teste, Produção) para se especializar ainda mais.

Na verdade, não é ideal nem mesmo recomendável criar um único DCR contendo todas as fontes de dados, itens de coleção e destinos para implementar a observabilidade. Na tabela a seguir, há várias recomendações que podem ajudar a planejar melhor a criação e a manutenção do DCR:

Categoria Prática recomendada Explicação Área de impacto
Coleta de dados Defina o escopo de observabilidade. Definir o escopo de observabilidade é fundamental para um escopo de observabilidade da organização e gerenciamento mais fáceis e bem-sucedidos do DCR. Ele ajuda a esclarecer qual é a necessidade da coleção e de qual máquina virtual de destino ela deve ser executada. Como explicado anteriormente, um escopo de observabilidade pode ser um conjunto de máquinas virtuais executando software que é comum a um aplicativo específico, um conjunto de informações comuns para o departamento de TI etc. Por exemplo, coletar os contadores de desempenho básicos do sistema operacional, como utilização da CPU, memória disponível e espaço livre em disco, pode ser visto como um escopo para o Gerenciamento Central de TI. Não ter um escopo claramente definido não traz clareza e não permite um gerenciamento adequado.
Crie DCRs específicos para o escopo de observabilidade. A criação de DCRs separadas com base no escopo de observabilidade é fundamental para uma manutenção fácil. Ele permite associar facilmente os DCRs às máquinas virtuais de destino relevantes. Por que criar um único DCR que coleta contadores de desempenho do sistema operacional, além de contadores de servidor Web e contadores de banco de dados todos juntos? Essa abordagem não apenas força cada máquina virtual associada a transferir, processar e executar a configuração que está fora do escopo. Ele também requer mais esforço quando a configuração do DCR precisa ser atualizada. Pense no gerenciamento de um modelo que inclua entradas desnecessárias; essa situação é menor que o ideal e deixa espaço para erros.
Crie o DCR específico para o tipo de fonte de dados dentro dos escopos de observabilidade definidos. A criação de DCRs separados para desempenho e eventos ajuda no gerenciamento da configuração e na associação com granularidade com base nos computadores de destino. Por exemplo, a criação de um DCR para coletar eventos e contadores de desempenho pode resultar em uma abordagem não otimizada. Pode haver situações em que um determinado computador (ou conjunto de computadores) não tem os logs de eventos ou contadores de desempenho configurados no DCR. Nessa situação, as máquinas virtuais são forçadas a processar e executar uma configuração que não é necessária de acordo com o software instalado nela. O não uso de DCRs diferentes força cada máquina virtual associada a transferir, processar e executar uma configuração que pode não ser aplicável de acordo com o software instalado. Um consumo excessivo de recursos de computação e erros na configuração de processamento podem acontecer fazendo com que o AMA (Agente do Azure Monitor) não responda. Além disso, a coleta de dados desnecessários aumenta os custos de ingestão de dados.
Destino de dados Crie um DCR diferente com base no destino. Os DCRs têm a capacidade de enviar dados simultaneamente para vários destinos diferentes, como Azure Monitor Metrics e Azure Monitor Logs. Ter DCRs específicos ao destino é útil para gerenciar os requisitos de direito ou soberanos de dados. Por estar em conformidade, pode ser necessário enviar dados apenas para repositórios permitidos em regiões autorizadas, e ter diferentes DCRs permite um direcionamento mais granular dos destinos. Se você não separar DCRs com base no destino de dados, isso poderá levar à não conformidade com os requisitos de tratamento, privacidade e acesso de dados. Isso também pode resultar em coleta de dados desnecessária, causando custos inesperados.

Os princípios mencionados anteriormente fornecem uma base para criar sua própria abordagem de gerenciamento de DCR que equilibra a manutenção, a facilidade de reutilização, a granularidade e os limites de serviço. Os DCRs também precisam de governança compartilhada, para minimizar a criação de silos e a duplicação desnecessária do trabalho.

Próximas etapas