O Zenoss tem um plug-in do EC2Manager que adiciona automaticamente todas as suas instâncias do EC2 (mesmo na versão de código aberto) e monitora o EC2 em busca de alterações. Zenoss pode ser mais pesado do que você realmente quer, no entanto.
Estamos construindo uma pilha de software de processamento de imagens médicas, atualmente hospedada em vários recursos da AWS. Como parte deste aplicativo, temos um punhado de servidores de longa duração (banco de dados, balanceadores de carga, aplicativos da Web, etc.). Coletar dados de desempenho nesses servidores é bastante simples - minha rotina de Nagios (para monitoramento / notificações) e Munin (para coleta de dados de desempenho e exibição de tendências) funcionará muito bem.
No entanto - como parte deste aplicativo, estamos constantemente iniciando e encerrando instâncias de computação no EC2. No uso típico, essas instâncias de computação são inicializadas, configuram a si mesmas, recebem um trabalho de uma fila de mensagens e, em seguida, começam a trabalhar no processamento dessa tarefa, que leva de 15 minutos a mais de 8 horas. Após a conclusão do trabalho, essas instâncias são encerradas, para nunca mais serem ouvidas.
O que é uma estratégia decente para coletar dados de desempenho nessas instâncias de curta duração?
Eu não preciso necessariamente de monitoramento sobre eles - se eles falharem por qualquer motivo, nosso aplicativo detectará isso e manipulará a reinicialização do trabalho em outra instância ou o sinalizador para que um administrador possa dar uma olhada nas coisas. No entanto, ainda seria útil para coletar informações como CPU (usuário, ocioso, iowait, etc.), uso de memória, tráfego de rede, dados de leitura / gravação de disco, etc. Em nosso banco de dados interno, rastreie o ID da instância da máquina que executa cada tarefa, e seria muito útil poder procurar dados de desempenho para uma ID de instância específica para solução de problemas e criação de perfil.
Munin não parece ser um ótimo candidato, pois requer manter uma lista de nós munin em um arquivo de texto - longe de ser ideal para um ambiente com grande quantidade de rotatividade, e pelo curto período de tempo que cada nó estar em execução, prefiro manter os dados de resolução completa indefinidamente do que ter o RRD reduzindo os dados ao longo do tempo.
No final, meu palpite é que isso exigirá um mecanismo de monitoramento que:
Há outras coisas que eu deveria estar pensando ao avaliar as opções?
Talvez eu tenha pensado demais sobre isso, e apenas execute sar em intervalos de 1 minuto nessas instâncias de curta duração e colete os arquivos sar do db antes da finalização.
O Zenoss tem um plug-in do EC2Manager que adiciona automaticamente todas as suas instâncias do EC2 (mesmo na versão de código aberto) e monitora o EC2 em busca de alterações. Zenoss pode ser mais pesado do que você realmente quer, no entanto.
Para instâncias efêmeras, o Nagios não é um ótimo ajuste, já que você teria que reescrever constantemente os arquivos de configuração.
Recentemente, pesquisei quais sistemas de monitoramento "bem conhecidos / mantidos" são adequados para situações como essas.
Os sistemas de monitoramento a seguir facilitam adicionar / remover hosts:
Acho que você precisará de algum tipo de CMDB central para ser uma fonte de verdade. Então você pode usar o CMDB como fonte de dados para o Puppet / Chef / etc, que poderá configurar os hosts monitorados e adicioná-los ao servidor de monitoramento.
Acho que a abordagem correta com instâncias efêmeras é aproveitar Amazon CloudWatch ou o CloudWatch API de alguma maneira. Mas isso depende muito do que você realmente precisa ver ...
Se você estiver usando uma solução de balanceamento de carga de qualidade na Nuvem , que quase pode ser mais benéfico do que o monitoramento por instância, pois o balanceador de carga pode tomar decisões de roteamento mais informadas com base em melhores condições em tempo real (por exemplo, # de conexões, tempo / latência de resposta do nó, localização geográfica).
No entanto, estamos procurando fazer o mesmo e, potencialmente, integrar com o conjunto de monitoramento comercial que usamos. Caso contrário, o Zenoss parece ter uma solução em lata.
Se você se preocupa em coletar dados de desempenho, mas não em monitoramento, e quer algo que não exija configuração toda vez que uma instância nasce ou morre, collectd seria um ótimo ajuste.
Configure uma instância como um servidor, ou seja, o plug-in rede configurado para receber dados e o < um plugin href="https://collectd.org/wiki/index.php/Plugin:RRDtool"> RRDtool configurado para gravar dados. Configure suas instâncias efêmeras com qualquer plug-in necessário para coletar os dados de desempenho relevantes e com o plug-in de rede configurado para enviar dados para o servidor.
Desde que essas instâncias duram pouco, você deverá alterar o RRATimespan a>. Se você não quiser armazenar os dados em arquivos RRD, o collectd pode enviar para outros armazenamentos de dados como grafite ou mongodb.
O Zabbix seria uma excelente escolha aqui.
É fácil de configurar e você pode configurar o registro automático e a descoberta, coletar dados de desempenho e ter os registros limpos após X dias.