Retenção de Dados do InfluxDB

Shawn Stafford Blocked Unblock Seguir Seguindo 7 de janeiro

Os dados de séries temporais costumam ser usados pelas equipes de operações para investigar problemas de desempenho. Como não podemos prever antecipadamente a origem de um problema de desempenho, muitas vezes erramos ao lado da precaução e coletamos o máximo possível de dados com a maior frequência possível. Isso facilita a obtenção de uma imagem muito granular do que estava acontecendo em um ambiente na última hora, dia ou semana. No entanto, manter mais de uma semana ou duas de dados pode se tornar difícil à medida que o número de hosts e o volume de dados aumenta.

Há muitas razões pelas quais pode ser necessário manter os dados por períodos mais longos. Geralmente, é útil referir-se a dados com semanas, meses ou até anos nos seguintes casos:

  • Planejamento de capacidade – analisando a utilização de recursos nos últimos 12 a 24 meses, você pode projetar o avanço de uso para prever suas necessidades de orçamento para o próximo ano fiscal.
  • Degradação de desempenho – os usuários geralmente relatam que o desempenho do aplicativo “parece mais lento” do que há algumas semanas ou meses atrás. Ter dados históricos ao seu alcance torna possível quantificar quanto tempo as tarefas estão demorando ou se existe uma correlação entre o aumento de carga e o desempenho mais lento.

Ao lidar com dados de séries temporais, você inevitavelmente alcançará um ponto em que não poderá reter todos os dados com granularidade total por um período de tempo indefinido. Um trade-off deve ser feito entre quanto tempo você retém os dados, quantos dados você retém e como os dados são granulares. Este artigo aborda como implementar uma política de retenção de dados no InfluxDB para garantir que você possa extrair amostras de seus dados, retê-los por um período especificado e executar backups regulares para evitar a perda de dados.

Para o propósito deste exemplo, nos concentraremos nas métricas de utilização da CPU que estão sendo coletadas por um daemon do sistema collectd em execução em 3 hosts. Nesse cenário, o collectd está enviando dados da CPU ("load_shortterm") em intervalos de 10 segundos de cada host sendo monitorado. Os dados estão sendo enviados diretamente para o InfluxDB usando o daemon collectd e armazenados em um banco de dados de "métricas" que é definido com uma política de retenção de 7 dias. O objetivo é reter esses dados em um banco de dados “de longo prazo” com uma política de retenção de 3 anos.