本文是從OpenStack官網(wǎng)翻譯出來，從多個方面描述了OpenStack在日志分析和日志管理方面的內(nèi)容，可以供大家參考學(xué)習(xí)。

一、日志的位置

大多數(shù)服務(wù)都默認(rèn)將日志寫入子目錄為/var/log，下面為OpenStack各服務(wù)的位置列表。

二、日志查閱

OpenStack服務(wù)使用標(biāo)準(zhǔn)的loggin級別，嚴(yán)重程度逐漸增高，如TRACE, DEBUG, INFO, AUDIT, WARNING, ERROR, and CRITICAL。也就是說，只有當(dāng)日志消息比特定日志級別更高時才出現(xiàn)在日志文件中，Debug允許所有日志語句通過。例如，僅當(dāng)軟件具有堆棧跟蹤時才記錄跟蹤，而記錄每條日志消息的信息，包括僅用于提供info的日志消息。

關(guān)閉DEBUG-level日志記錄，編輯/etc/nova/nova.conf 文件如下

Debug=false

keystone的處理有些不同，修改logging級別，編輯
/etc/keystone/logging.conf文件，看logger_root和handler_file部分。

而Horizon的logging配置在
/etc/openstack_dashboard/local_settings.py，因為horizon是一個Django網(wǎng)頁應(yīng)用，遵守Dango logging framework約定。

查找錯誤源的第一步通常是從日志文件底部開始搜索日志中的關(guān)鍵或錯誤信息。

下面是一個日志消息的實(shí)例，其中緊接著出現(xiàn)了響應(yīng)的錯誤（Python traceback）:

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-volume啟動失敗和提供一個stack trace（堆棧跟蹤）。因為其卷后端無法設(shè)置存儲卷，這可能因為配置中預(yù)期的LVM卷不存在。

備注：Stacktrace（堆棧跟蹤）是一個非常有用的調(diào)試工具. 在未捕獲的異常被拋出時（或者手動制造堆棧跟蹤的時候）它讓你看到你調(diào)到的堆（意思是，在某一點(diǎn)調(diào)用方法的堆). 不僅顯示出出現(xiàn)錯誤的地方, 也顯示出程序在那個地方是如何結(jié)束的.

下面是一個Error日志實(shí)例：

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服務(wù)不能連接到RabbitMQ服務(wù)器，因為它有一個拒絕連接的錯誤。

三、跟蹤實(shí)例請求

當(dāng)一個實(shí)例無法正常運(yùn)行時，您通常需要在各種nova-*服務(wù)的日志文件中以及在云控制器和計算節(jié)點(diǎn)上跟蹤與該實(shí)例相關(guān)的活動。

典型的方法是在服務(wù)日志中跟蹤與實(shí)例關(guān)聯(lián)的UUID。

考慮下面的例子：

在這里，與實(shí)例關(guān)聯(lián)的ID是
faf7ded8-4a46-413b-b113-f19590746ffe，如果是在云控制器的/var/log/nova-*日志文件中搜索此字符串，它出現(xiàn)在nova-api.log和nova-scheduler.log中。如果你在計算點(diǎn)的/var/log/nova-*.log日志文件中搜索，它會出現(xiàn)在nova-compute.log中。日志如果沒有出現(xiàn)Error或Critical消息，則在最新日志條目可能會提示出現(xiàn)了什么問題。

四、添加自定義日志語句

如果現(xiàn)有日志中沒有足夠的信息，您可能需要將自己的自定義日志語句添加到nova-*服務(wù)中。

源文件位于
/usr/lib/python2.7/dist-packages/nova.

添加日志記錄語句，下面一行應(yīng)該位于文件頂部附近。對于大多數(shù)文件，這些文件應(yīng)該已經(jīng)存在。

要添加DEBUG 日志記錄語句，你要做：

您可能注意到，所有現(xiàn)有日志消息前面都有一個下劃線，并用括號括起來，例如：

此格式用于支持使用gettex 國際化庫將日志消息轉(zhuǎn)換為不同語言。您不需要為自己的自定義日志消息執(zhí)行此操作。但是，如果希望將代碼貢獻(xiàn)回包含日志語句的OpenStack項目，則必須用下劃線和括號將日志消息括起來。

五、RabbitMQ Web管理界面或rabbitmqctl

除了連接失敗之外，RabbitMQ日志文件通常對調(diào)試OpenStack相關(guān)問題沒有用處。相反，我們建議使用RabbitMQ web管理界面。在云控制器上啟用它：

# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management

# service rabbitmq-server restart

RabbitMQ網(wǎng)頁管理界面通過http://localhost:55672來訪問。

其中Ubuntu的不同版本的訪問端口會有所不同，如2.7.1是使用55672，而3.0以上則使用15672。

可以通過以下命令查看版本

另外，使用rabbitmqctl命令行也是可以查看隊列情況，如

rabbitmqctl list_queues| grep cinder 可以顯示剩余在隊列中的消息。如果有消息，可能表明cinder服務(wù)未正確連接到rabbitmq，可能必須重新啟動。

RabbitMQ要監(jiān)視的項目包括每個隊列中的項目數(shù)以及服務(wù)器的處理時間統(tǒng)計信息。

六、集中管理日志

因為云平臺很可能由許多服務(wù)器組成，所以你必須檢查每臺服務(wù)器上的日志，才能正確地將一個事件關(guān)聯(lián)在一起。更好的解決方案是將所有服務(wù)器的日志發(fā)送到一個集中的地方，以便可以統(tǒng)一管理和方便查閱。

統(tǒng)一日志管理方案的選擇將取決于所使用的操作系統(tǒng)以及對日志工具的需求。目前業(yè)內(nèi)比較有名的ElasticStack，是一個比較流行的開源解決方案。