[ English | 日本語 | Deutsch | Indonesia ]

ロギング

ログはどこにあるのか?

多くのサービスは、慣習に従い、ログファイルを /var/log ディレクトリーのサブディレクトリーに書き込みます。表: OpenStack のログの場所 に一覧化されています。

表: OpenStack のログの場所

ノード種別

サービス

ログの場所

クラウドコントローラー

nova-*

/var/log/nova

クラウドコントローラー

glance-*

/var/log/glance

クラウドコントローラー

cinder-*

/var/log/cinder

クラウドコントローラー

keystone-*

/var/log/keystone

クラウドコントローラー

neutron-*

/var/log/neutron

クラウドコントローラー

Horizon

/var/log/apache2/

全ノード

その他 (swift, dnsmasq)

/var/log/syslog

コンピュートノード

libvirt

/var/log/libvirt/libvirtd.log

コンピュートノード

仮想マシンインスタンスのコンソール (起動メッセージ):

/var/lib/nova/instances/instance-<instance id>/console.log

Block Storage ノード

cinder-volume

/var/log/cinder/cinder-volume.log

ログの読み方

OpenStack サービスは標準のロギングレベルを利用しています。重要度のレベルは次の通りです(重要度の低い順): TRACE、DEBUG、INFO、AUDIT、WARNING、ERROR、CRTICAL。特定のログレベルより「重要」な場合のみメッセージはログに出力されます。ログレベルDEBUGの場合、すべてのログが出力されます。TRACEの場合、ソフトウェアがスタックトレースを持つ場合にのみログに出力されます。INFOの場合、情報のみのメッセージも含めて出力されます。

DEBUG レベルのロギングを無効にするには、/etc/nova/nova.conf を以下のように編集します。

debug=false

Keystoneは少し異なる動作をします。ロギングレベルを変更するためには、/etc/keystone/logging.conf を編集し、logger_roothandler_file を修正する必要があります。

horizon のロギング設定は /etc/openstack_dashboard/local_settings.py で行います。 horizon は Django web アプリケーションですので、 Django Logging framework conventions に従います。

エラーの原因を見つけるための典型的な最初のステップは、 CRTICAL、ERRORなどのメッセージがログファイルの終わりで出力されていないかを確認することです。

これは、ERROR (Python のトレースバック) に対応するログメッセージの例です。

2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server [req-c0b38ace-2586-48ce-9336-6233efa1f035 6c9808c2c5044e1388a83a74da9364d5 e07f5395c
2eb428cafc41679e7deeab1 - default default] Exception during message handling
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server Traceback (most recent call last):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 4366, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     allow_reschedule=allow_reschedule, volume=volume)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 634, in create_volume
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     _run_flow()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/cinder/volume/manager.py", line 626, in _run_flow
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     flow_engine.run()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 247, in run
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     for _state in self.run_iter(timeout=timeout):
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failure.Failure.reraise_if_any(er_failures)
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 336, in reraise_if_any
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server     failures[0].reraise()
2017-01-18 15:54:00.467 32552 ERROR oslo_messaging.rpc.server   File "/openstack/venvs/cinder-14.0.0/lib/python2.7/site-packages/taskflow/types/failure.py", line 343, in reraise

この例では、ボリュームのバックエンドがストレージボリュームをセットアップができなかったため、cinder-volumes が起動に失敗し、スタックトレースを出力しています。おそらく、設定ファイルで指定された LVM ボリュームが存在しないためと考えられます。

これはエラーログの例です。

2013-02-25 20:26:33 6619 ERROR nova.openstack.common.rpc.common [-] AMQP server on localhost:5672 is unreachable:
 [Errno 111] ECONNREFUSED. Trying again in 23 seconds.

このエラーでは、novaサービスがRabbitMQへの接続に失敗していました。接続が拒否されたというエラーが出力されています。

インスタンスリクエストの追跡

インスタンスが正しく動作していない場合、インスタンスに関連したログを調べる必要があります。これらのログは複数の nova-* サービスが出力しており、クラウドコントローラーとコンピュートノードの両方に存在します。

一般的な方法はインスタンスのUUIDをキーにして、各サービスのログを追跡することです。

次のような例を考えてみましょう。

$ openstack server list
+--------------------------------+--------+--------+--------------------------+------------+
| ID                             | Name   | Status | Networks                 | Image Name |
+--------------------------------+--------+--------+--------------------------+------------+
| fafed8-4a46-413b-b113-f1959ffe | cirros | ACTIVE | novanetwork=192.168.100.3| cirros     |
+--------------------------------------+--------+--------+--------------------+------------+

ここで、インスタンスのUUIDは faf7ded8-4a46-413b-b113-f19590746ffe です。クラウドコントローラー上の /var/log/nova-*.log ファイルをこの文字列で検索すると、 nova-api.lognova-scheduler.log で見つかります。同様にコンピュートノードで検索した場合、 nova-compute.log で見つかります。もし、 ERROR や CRITICAL のメッセージが存在しない場合、最後のログエントリが、何が悪いかのヒントを示しているかもしれません。

カスタムログの追加

十分な情報が既存のログにない場合、独自のロギング宣言を nova-* サービスに追加する必要があるかもしれません。

ソースファイルは /usr/lib/python2.7/dist-packages/nova にあります。

ログステートメントを追加するには、次の行をファイルの先頭に置きます。ほとんどのファイルでは、これらは既に存在します。

from nova.openstack.common import log as logging
LOG = logging.getLogger(__name__)

DEBUGログステートメントを追加するには次のようにします。

LOG.debug("This is a custom debugging statement")

以下に例を示しますが、全てのログメッセージはアンダースコアで始まり、括弧で括られていることに気づいたでしょうか?

LOG.debug(_("Logging statement appears here"))

このフォーマットは、ログメッセージを異なる言語に翻訳するために gettext 国際化ライブラリーを利用しているためです。カスタムログには必要ありませんが、もし、OpenStackプロジェクトにログステートメントを含むコードを提供する場合は、アンダースコアと括弧でログメッセージを囲わなければなりません。

RabbitMQ Web管理インターフェイス および rabbitmqctl

接続エラーは別として、RabbitMQ のログファイルは一般的に OpenStack 関連の問題をデバッグするために役立ちません。代わりに、RabbitMQ の Web 管理インターフェースを使用することを推奨します。クラウドコントローラーで Web 管理インターフェースを有効にするには以下のようにします。

# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart

RabbitMQ Web 管理インターフェイスは、クラウドコントローラーから http://localhost:55672 でアクセスできます。

注釈

Ubuntu 12.04はRabiitMQのバージョン2.7.1を55672番ポートを使うようにインストールします。RabbitMQバージョン3.0以降では15672が利用されます。Ubuntuマシン上でどのバージョンのRabbitMQが実行されているかは次のように確認できます。

$ dpkg -s rabbitmq-server | grep "Version:"
Version: 2.7.1-0ubuntu4

RabbitMQ Web 管理インターフェイスを有効にするもう一つの方法としては、 rabbitmqctl コマンドを利用します。例えば rabbitmqctl list_queues| grep cinder は、キューに残っているメッセージを表示します。メッセージが存在する場合、Cinder サービスが RabbitMQ に正しく接続できてない可能性があり、再起動が必要かもしれません。

RabbitMQで監視すべき項目としては、各キューでのアイテムの数と、サーバーでの処理時間の統計情報があります。

ログの集中管理

クラウドは多くのサーバーから構成されるため、各サーバー上にあるイベントログを繋ぎあわせて、ログをチェックしなければなりません。よい方法は全てのサーバーのログを一ヶ所にまとめ、同じ場所で確認できるようにすることです。

一元化したロギングエンジンの選択は、使用するオペレーティングシステム、組織のロギングツールに関する要件に依存します。

Syslog の選択肢

数多くの syslog エンジンが利用できます。それぞれ異なる機能や設定要件を持ちます。