Melhores práticas 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 de acordo com requisitos específicos. Este artigo discute algumas das melhores práticas que devem ser aplicadas ao criar suas DCRs.
Ao criar uma DCR, há alguns aspectos que precisam ser considerados, como:
- O tipo dos 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 coletados
Considerar todos esses fatores é fundamental para uma boa organização do DCR. Todos os pontos acima afetam o esforço de gerenciamento do DCR, bem como o consumo de recursos para transferência e processamento de configuração.
Devido à 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. Também é importante manter a lista de itens coletados, em cada fonte de dados enxuta e orientada para o escopo de observabilidade.
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 softwares (por exemplo, "SQL Servers") necessários para um aplicativo específico ou contadores básicos do sistema operacional ou conjunto de eventos usados pelos seus administradores de TI. Também é possível criar escopos semelhantes dedicados a ambientes diferentes ("Desenvolvimento", "Teste", "Produção") para 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 a planejar melhor a criação e a manutenção do DCR:
| Categoria | Melhor prática | Explicação | Área de impacto |
|---|---|---|---|
| Coleta de dados | Definir 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. Isso ajudará a esclarecer qual é a necessidade da coleta e de qual máquina virtual de destino ela deve ser executada. Conforme explicado anteriormente, um escopo de observabilidade pode ser um conjunto de máquinas virtuais executando softwares comuns a um aplicativo específico, um conjunto de informações comuns para o departamento de TI etc. Por exemplo, coletar 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 permite um gerenciamento adequado. |
| Criar DCRs específicos para o escopo de observabilidade | Criar DCRs separados com base no escopo de observabilidade é fundamental para facilitar a manutenção. Isso permitirá que você associe facilmente os DCRs às máquinas virtuais de destino relevantes. | Por que criar um único DCR que colete contadores de desempenho do sistema operacional mais contadores de servidor Web e contadores de banco de dados juntos? Essa abordagem não só forçará cada 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 do DCR precisar ser atualizada. Pense em gerenciar um modelo que inclui entradas desnecessárias; essa situação não é ideal e deixa espaço para erros. | |
| Criar um 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á a gerenciar a configuração e a associação com granularidade com base nos computadores de destino. Por exemplo, criar 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 tenha os logs de eventos ou contadores de desempenho configurados no DCR. Nessa situação, as máquinas virtuais serão forçadas 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 ocorrer fazendo com que o AMA (Agente do Azure Monitor) fique sem resposta. Além disso, a coleta de dados desnecessários aumentará os custos de ingestão de dados. | |
| Destino dos dados | Criar um DCR diferente com base no destino | Os DCRs têm a capacidade de enviar dados para vários destinos diferentes, como Métricas do Azure Monitor e Logs do Azure Monitor, simultaneamente. Ter DCRs específicos ao destino é útil para gerenciar os requisitos de direito ou soberanos de dados. Como a conformidade pode exigir o envio de dados somente para repositórios permitidos criados em regiões permitidas, ter DCRs diferentes permite um destino granular melhor direcionado | Não separar DCRs com base no destino de dados pode resultar em não conformidade com os requisitos de manipulação de dados, privacidade e acesso e pode tornar a coleta 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 a criação de silos e a duplicação desnecessária do trabalho.