Сбой Ganglia gmetad после некоторой работы (на AWS EC2)

Мы используем Ganglia для мониторинга нашей облачной инфраструктуры на Amazon AWS. Все работает правильно (метрики текут и т. Д.), За исключением того, что иногда процесс gmetad внезапно дает сбой. Процесс gmetad выполняется на m3.medium EC2 и контролирует около 50 серверов. Серверы организованы в группы, у каждого из которых есть бастион EC2, где собираются показатели. gmetad настроен на получение показателей с этих бастионов - около 10 из них.

Несколько полезных фактов:

• Мы запускаем Debian Wheezy на всех EC2
• Авария не создает никаких журналов при нормальной работе, кроме журнала segfault, например, «gmetad [11291]: segfault at 71 ip 000000000040547c sp 00007ff2d6572260 error 4 in gmetad [400000 + e000]». Если мы запустим gmetad вручную с ведением журнала отладки, окажется, что сбой связан с очисткой gmetad.
• Когда мы поняли, что виноват процесс очистки, мы провели дополнительные исследования по этому поводу. Мы поняли, что наш дисковый ввод-вывод был слишком большим, и добавили rrdcached, чтобы уменьшить его. Операция ввода-вывода диска теперь намного ниже, и сбой происходит реже, но все же в среднем один раз в день или около того.
• У нас есть две системы (разработка и продакшн). Оба демонстрируют этот сбой, но система разработки, которая отслеживает гораздо меньшую группу серверов, дает сбой значительно реже.
• Производственная система работает под управлением ganglia 3.3.8-1 + nmu1 / rrdtool 1.4.7-2. Мы обновили ganglia в системах разработки до ganglia 3.6.0-2 ~ bpo70 + 1 / rrdtool 1.4.7-2. Похоже, это не помогло с аварией.
• У нас есть monit, работающий в обеих системах, настроенный на перезапуск gmetad в случае его смерти. Он сразу же перезапускается без проблем.

Кто-нибудь испытывал такой сбой, особенно на оборудовании Amazon? Мы находимся в упадке, пытаясь найти решение!