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 sã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.
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 é 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 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 a planejar melhor a criação e a manutenção do DCR:
| Categoria | Melhor prática | 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. Isso ajuda 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. |
| Crie DCRs específicos para o escopo de observabilidade. | Criar DCRs separados com base no escopo de observabilidade é fundamental para facilitar a manutenção. Isso permite 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 apenas força cada máquina virtual associada a transferir, processar e executar a configuração que está fora do escopo. Também requer mais esforço quando a configuração do DCR precisa ser atualizada. Pense em gerenciar um modelo que inclui entradas desnecessárias; essa situação nã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, 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 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 ocorrer fazendo com que o AMA (Agente do Azure Monitor) fique sem resposta. Além disso, a coleta de dados desnecessários aumenta os custos de ingestão de dados. | |
| Destino dos dados | Crie 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. | 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, gerando custos inesperados. |
Os princípios mencionados anteriormente fornecem uma base para criar sua própria abordagem de gerenciamento de DCR que equilibra a facilidade 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.