[ English | Indonesia | Deutsch | 日本語 ]
ロギング¶
ログはどこにあるのか？¶
多くのサービスは、慣習に従い、ログファイルを /var/log ディレクトリーのサブディレクトリーに書き込みます。表: OpenStack のログの場所 に一覧化されています。
ノード種別 |
サービス |
ログの場所 |
|---|---|---|
クラウドコントローラー |
|
|
クラウドコントローラー |
|
|
クラウドコントローラー |
|
|
クラウドコントローラー |
|
|
クラウドコントローラー |
|
|
クラウドコントローラー |
Horizon |
|
全ノード |
その他 (swift, dnsmasq) |
|
コンピュートノード |
libvirt |
|
コンピュートノード |
仮想マシンインスタンスのコンソール (起動メッセージ): |
|
Block Storage ノード |
cinder-volume |
|
ログの読み方¶
OpenStack サービスは標準のロギングレベルを利用しています。重要度のレベルは次の通りです(重要度の低い順): TRACE、DEBUG、INFO、AUDIT、WARNING、ERROR、CRTICAL。特定のログレベルより「重要」な場合のみメッセージはログに出力されます。ログレベルDEBUGの場合、すべてのログが出力されます。TRACEの場合、ソフトウェアがスタックトレースを持つ場合にのみログに出力されます。INFOの場合、情報のみのメッセージも含めて出力されます。
DEBUG レベルのロギングを無効にするには、/etc/nova/nova.conf を以下のように編集します。
debug=false
Keystoneは少し異なる動作をします。ロギングレベルを変更するためには、/etc/keystone/logging.conf を編集し、logger_root と handler_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.log と nova-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 エンジンが利用できます。それぞれ異なる機能や設定要件を持ちます。
