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 para o 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, existem alguns aspetos que precisam ser considerados, tais 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 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.
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 | Defina o escopo 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 ajuda 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. |
| Crie DCRs específicos para o escopo de observabilidade. | Criar DCRs separados com base no escopo de observabilidade é fundamental para facilitar a manutenção. Ele permite 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ç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 DCR precisa ser atualizada. Pense em gerenciar um modelo que inclua entradas desnecessárias; Esta situação não é a ideal e deixa margem para erros. | |
| Crie 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 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, 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. | Não usar DCRs diferentes força 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 aumenta os custos de ingestão de dados. | |
| Destino dos dados | Crie DCR diferentes 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 DCRs específicos 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 do destino. | Se você não separar DCRs com base no destino dos dados, isso pode levar à não conformidade com os requisitos de tratamento de dados, privacidade e acesso. Pode também resultar numa recolha 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 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.