稼働中のインスタンスからコンソールログを取得可能なユーザはサポートの恩恵となる（インスタンスの中で何が起こっているのか何度も確認できるし、あなたが悩まずに問題を修正することができる）。不幸なことに、過剰な失敗の記録は時々、自らの問題となり得る。
報告が入った。VM の起動が遅いか、全く起動しない。標準のチェック項目は？Nagios 上は問題なかったが、RabbitMQ クラスタの現用系に向かうネットワークのみ高負荷を示していた。捜査を開始したが、すぐに RabbitMQ クラスタの別の部分がざるのようにメモリリークを起こしていることを発見した。また警報か？RabbitMQ サーバーの現用系はダウンしようとしていた。接続は待機系にフェイルオーバーした。
この時、我々のコントロールサービスは別のチームによりホスティングされており、我々には現用系サーバー上で何が起こっているのかを調査するための大したデバッグ情報がなく、再起動もできなかった。このチームは警報なしで障害が起こったと連絡してきたが、そのサーバーの再起動を管理していた。１時間後、クラスタは通常状態に復帰し、我々はその日は帰宅した。
翌朝の継続調査は別の同様の障害でいきなり始まった。我々は急いで RabbitMQ サーバーを再起動し、何故 RabbitMQ がそのような過剰なネットワーク負荷に直面しているのかを調べようとした。nova-api のデバッグログを出力することにより、理由はすぐに判明した。tail -f /var/log/nova/nova-api.log は我々が見たこともない速さでスクロールしていた。CTRL+C でコマンドを止め、障害を吐き出していたシステムログの内容をはっきり目にすることが出来た。－我々のユーザの１人のインスタンスからのシステムログだった。
インスタンスIDの発見後、console.log を探すため /var/lib/nova/instances にアクセスした。
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思った通り、ユーザはダッシュボード上のコンソールログページを定期的に更新しており、ダッシュボードに向けて5GB のファイルが RabbitMQ クラスタを通過していた。
我々はユーザを呼び、しばらくダッシュボードの更新を止めるよう申し入れた。すると、恐ろしい VM の破壊は止み、彼らは大いに喜んだ。その後、我々はコンソールログのサイズを監視するようになった。
今日に至るまで、この問題 (https://bugs.launchpad.net/nova/+bug/832507) には完全な解決策がないが、我々は次回のサミットの議論に期待している。
