Возможность пользователей получить консоль журналов для работающих экземпляров является благом для сопровождения— много раз они могли выяснить что происходит внутри их экземпляров и исправить то что происходит не так как надо, не утруждая вас. К сожалению, иногда излишнее усердие с журналами отказов само по себе может вызвать проблемы.

Пришло сообщение: виртуальная машина запускалась медленно или не запустилась совсем. Реплика стандартно проверяет— ничего с nagios, однако существует всплеск в сети по направлению к текущему владельцу нашего RabbitMQ кластера. Исследование началось, однако вскоре другие части очереди кластера были отмечены утечками памяти как в решете. Тогда и пришло предупреждение— главный rabbit сервер (мастер) отключился. Соединения ушли в подчиненное состояние.

В это время наши службы управления велись другой командой и мы не имели достаточно отладочной информации для определения того, что произошло с мастером и не могли перезагрузить его. Эта команда отметила, что мастер отказал без выдачи предупреждения, но сумела перезагрузить его. Через час кластер вернулся в свое нормальное состояние и мы ушли домой в конце дня.

Продолжить диагностику на следующее утро заставил удар, начатый другим идентичным отказом. Мы быстро взялись за вновь запущенные очереди сообщений и попытались выяснить почему Rabbit испытывает такой большой сетевой обмен. Разрешение ведения отладочных журналов в nova-api быстро принесло понимание. Прокрутка tail -f /var/log/nova/nova-api.log была самой быстрой из тех, что мы когда либо видели. CTRL+C на ней и мы могли с очевидностью увидеть, что содержимое системного журнала извергает отказы снова и снова - системный журнал экземпляра одного из наших пользователей.

После нахождения ID экземпляра мы направились в /var/lib/nova/instances чтобы найти console.log:

adm@cc12:/var/lib/nova/instances/instance-00000e05# wc -l console.log
92890453 console.log
adm@cc12:/var/lib/nova/instances/instance-00000e05# ls -sh console.log
5.5G console.log

Естественно, что пользователь периодически обновлял страницу журнала в консоли и 5ГБ файл пересекал rabbit кластер чтобы попасть в инструментальную панель.

Мы соединились с этим пользователями и попросили остановиться на некоторое время, и он был счастлив отказаться от ужасно сломанной виртуальной машины. После этого мы начали отслеживать размеры журналов консолей.

До сих пор вопрос (https://bugs.launchpad.net/nova/+bug/832507) не имеет постоянного решения, но мы с нетерпением ждем обсуждения на следующем саммите.