Estamos usando o Ganglia para monitorar nossa infraestrutura de nuvem no Amazon AWS. Tudo está funcionando corretamente (métricas estão fluindo, etc), exceto que ocasionalmente o processo gmetad se separa do nada. O processo gmetad está sendo executado em um EC3 m3.medium e está monitorando cerca de 50 servidores. Os servidores são organizados em grupos, cada um com um bastião EC2 onde as métricas são reunidas. O gmetad está configurado para pegar as métricas desses bastiões - cerca de 10 delas.
Alguns fatos úteis:
- Estamos executando o Debian Wheezy em todos os EC2s
- O travamento não cria nenhum log em operação normal diferente de um log de segfault como "gmetad [11291]: segfault a 71 ip 000000000040547c sp 00007ff2d6572260 erro 4 em gmetad [400000 + e000]". Se rodarmos o gmetad manualmente com o log de depuração, parece que o travamento está relacionado ao gmetad fazendo uma limpeza.
- Quando percebemos que o processo de limpeza poderia ser o culpado, fizemos mais pesquisas sobre isso. Percebemos que nosso disco IO era muito alto e incluímos o rrdcached para reduzi-lo. O disco IO é agora muito menor, e a falha está ocorrendo com menos frequência, mas ainda uma média de uma vez por dia.
- Temos dois sistemas (dev e produção). Ambos exibem essa falha, mas o sistema de desenvolvimento, que está monitorando um grupo muito menor de servidores, falha significativamente menos.
- O sistema de produção está executando o ganglia 3.3.8-1 + nmu1 / rrdtool 1.4.7-2. Nós atualizamos o ganglia nos sistemas de desenvolvimento para o gânglio 3.6.0-2 ~ bpo70 + 1 / rrdtool 1.4.7-2. Isso não parece ter ajudado no acidente.
- Temos monit executando nos dois sistemas configurados para reiniciar o gmetad se ele morrer. Ele reinicia imediatamente sem problemas.
Alguém já experimentou esse tipo de falha, especialmente no hardware da Amazon? Estamos no nosso juízo final tentando encontrar uma solução!