200.2 Prever a necessidade futura de Recursos
Para prever necessidade futura de algum recurso, vamos usar algumas aplicações que vão nos informar em que momento vamos necessitar de mais recursos, para que não tenhamos problemas em nossa infraestrutura.
CollectD
O CollectD é um daemon lançado em 8 de julho de 2005 para monitorar o uso de infraestrutura de TI. Ele foi escrito em C para garantir portabilidade e, originalmente, servia apenas para coletar estatísticas do sistema local. Com o tempo, ganhou suporte para coleta remota por meio de um plugin de rede, permitindo monitorar outros equipamentos.
As informações coletadas são armazenadas em um formato de banco de dados conhecido como Round Robin Database (RRD). No CollectD, esses dados ficam em /var/lib/collectd/rra/, dentro de arquivos *.rra (conhecidos como Round Robin Archive), que são arquivos binários. Para visualizar ou manipular o conteúdo deles usamos a ferramenta rrdtool, que o CollectD utiliza internamente para gravar os dados no formato RRD.
O arquivo de configuração principal fica em /etc/collectd/collectd.conf. O CollectD não mostra os dados por conta própria. Ele não tem interface gráfica, não gera gráficos e não exibe nada automaticamente.
Para instalar, use o comando abaixo:
$ sudo apt install collectd
RRDTOOL
O RRDTool é uma ferramenta criada em 16 de julho de 1999 para trabalhar com bancos de dados do tipo Round-Robin. Ele manipula e armazena os dados dentro dos arquivos *.rra, que são fixos em tamanho. Isso significa que, sempre que um valor novo é inserido, o valor mais antigo é automaticamente descartado, mantendo o arquivo com o mesmo tamanho desde sua criação.
Diferente do collectd, o rrdtool não coleta métricas. Ele apenas armazena e manipula dados no formato RRD. A relação entre as duas ferramentas fica assim: CollectD coleta e envia os dados, enquanto o RRDTool armazena tudo no banco de dados Round-Robin.
Por esse motivo, muitas ferramentas conhecidas usam o RRDTool como backend para gravar os dados coletados. Entre as mais comuns estão: Cacti, Nagios, CollectD e MRTG. Essas aplicações coletam métricas e o RRDTool cuida da forma como esses dados são armazenados.
Cacti
O Cacti é uma ferramenta Open Source desenvolvida para monitoramento e geração de gráficos. Ele é escrito em PHP e usa MySQL para armazenar suas configurações. Embora seja desenvolvido em PHP, possui diversos plugins (muitos deles escritos em C) que ampliam suas funções.
O RRDTool é fundamental no funcionamento do Cacti, já que é ele quem armazena as informações coletadas. Diferente de outras soluções completas de monitoramento, o Cacti funciona principalmente como um front-end, oferecendo uma interface para facilitar a administração, o gerenciamento de dispositivos e a exibição dos gráficos.
Como backend de coleta, o Cacti usa principalmente SNMP para obter dados dos dispositivos. Depois disso, ele envia essas métricas para o RRDTool, que é responsável por armazená-las no formato Round-Robin. Essa separação entre coleta, armazenamento e visualização torna o Cacti leve, modular e fácil de expandir.
MRTG
O MRTG (Multi Router Traffic Grapher) é uma ferramenta escrita em Perl e, de certa forma, possui a mesma ideia do Cacti. A diferença é que o MRTG foi criado com um foco bem específico: coletar e gerar gráficos de tráfego de rede.
Ele usa SNMP para obter informações dos dispositivos e, assim como outras ferramentas da mesma época, pode usar o RRDTool para armazenar os dados coletados. O MRTG foi uma das primeiras ferramentas amplamente adotadas para visualizar tráfego de interfaces, e por muito tempo foi padrão em monitoração de redes.
Em resumo, enquanto o Cacti evoluiu como um front-end mais completo e organizado, o MRTG manteve sua proposta simples: coletar dados de rede e gerar gráficos diretamente a partir deles.
Nagios/Icinga
O Nagios é um sistema de monitoramento que ajuda administradores de rede a identificar e resolver problemas na infraestrutura de TI antes que eles afetem processos críticos. De forma simples, ele verifica se algo está funcionando como deveria e notifica os responsáveis quando detecta uma falha ou alteração de estado.
O Nagios possui algumas formas de alertar os responsáveis após ser detectado uma mudança de estado de um dispositivo gerenciado, o tipo mais comum é o alerta visual no dashboard do Nagios, mas você pode configurar para que seja enviado e-mail e até mesmo integrar o envio de mensagens no telegram usando plugins.
Já o Icinga é um fork do Nagios, isso quer dizer que o código fonte do Nagios foi clonado e a partir dele nasceu um novo software, nesse caso, o Icinga, pelo menos em sua primeira versão, muda apenas o frontend, mantendo o mesmo backend do Nagios sem as limitações que nele existem.