Partilhar 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 serã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.

Ao criar um DCR, existem alguns aspetos que precisam ser considerados, tais como:

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

Considerar todos esses fatores é fundamental para uma boa organização de DCR. Todos os pontos acima impactam no esforço de gerenciamento de DCR, bem como no 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. Também é importante manter a lista de itens coletados em cada fonte de dados enxuta e orientada para o escopo da observabilidade.

Screenshot of data collection rules to virtual machines relation.

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 executando software (por exemplo, "SQL Servers") necessário para um aplicativo específico, ou contadores básicos do sistema operacional ou conjunto de eventos usados por seus administradores de TI. Também é possível criar escopos semelhantes dedicados a diferentes ambientes ("Desenvolvimento", "Teste", "Produção") para se especializar ainda mais.

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

Categoria Melhor prática Explicação Área de impacto
Recolha de Dados Definir o âmbito da observabilidade Definir o escopo da observabilidade é a chave para um gerenciamento de DCR mais fácil e bem-sucedido e o escopo de observabilidade da organização. Ele ajudará a esclarecer qual é a necessidade de coleta 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 básicos de desempenho 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 uma gestão adequada.
Criar DCRs específicos para o escopo de observabilidade Criar DCRs separados com base no escopo de observabilidade é fundamental para facilitar a manutenção. Ele permitirá que você associe 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 juntos? Essa abordagem, não apenas forçará toda e qualquer máquina virtual associada a transferir, processar e executar a configuração que está fora do escopo, mas também exigirá mais esforço quando a configuração DCR precisar ser atualizada. Pense em gerenciar um modelo que inclua entradas desnecessárias; Esta situação não é a ideal e deixa margem para erros.
Criar DCR específico para o tipo de fonte de dados dentro do(s) escopo(s) de observabilidade definido(s) A criação de DCRs separados para desempenho e eventos ajudará no gerenciamento da configuração e da associação com a granularidade com base nas máquinas de destino. Por exemplo, a criação de um DCR para coletar eventos e contadores de desempenho pode resultar em uma abordagem não ideal. Pode haver situações em que uma determinada máquina (ou conjunto de máquinas) não tenha os logs de eventos ou contadores de desempenho configurados no DCR. Nessa situação, a(s) máquina(s) virtual(is) será(ão) forçada(s) a processar e executar uma configuração que não é necessária de acordo com o software instalado nela. Não usar DCRs diferentes forçará cada máquina virtual associada 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 na configuração de processamento podem acontecer fazendo com que o Agente de Monitor do Azure (AMA) pare de responder. Além disso, a recolha de dados desnecessários aumentará os custos de ingestão de dados.
Destino dos dados Criar DCR diferente com base no destino Os DCRs têm a capacidade de enviar dados para vários destinos diferentes, como o Azure Monitor Metrics e o Azure Monitor Logs, simultaneamente. Ter DCR (s) específico para o destino é útil para gerenciar os requisitos soberanos ou legais de dados. Uma vez que, ser compatível pode exigir o envio de dados apenas para repositórios permitidos criados em regiões permitidas, ter DCRs diferentes permite uma melhor segmentação granular de destino A não separação dos DCR com base no destino dos dados pode resultar na não conformidade com os requisitos de tratamento, privacidade e acesso aos dados e pode tornar a recolha de dados desnecessária, resultando em custos inesperados.

Os princípios acima mencionados fornecem uma base para criar sua própria abordagem de gerenciamento de DCR que equilibra a capacidade de 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 tanto a criação de silos quanto a duplicação desnecessária de trabalho.

Próximos passos