本文是從OpenStack官網翻譯出來，從多個方面描述了OpenStack在日志分析和日志管理方面的內容，可以供大家參考學習。

一、日志的位置

大多數服務都默認將日志寫入子目錄為/var/log，下面為OpenStack各服務的位置列表。

二、日志查閱

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

關閉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網頁應用，遵守Dango logging framework約定。

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

下面是一個日志消息的實例，其中緊接著出現了響應的錯誤（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（堆棧跟蹤）。因為其卷后端無法設置存儲卷，這可能因為配置中預期的LVM卷不存在。

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

下面是一個Error日志實例：

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。

考慮下面的例子：

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

四、添加自定義日志語句

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

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

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

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

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

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

五、RabbitMQ Web管理界面或rabbitmqctl

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

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

# service rabbitmq-server restart

RabbitMQ網頁管理界面通過http://localhost:55672來訪問。

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

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

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

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

RabbitMQ要監視的項目包括每個隊列中的項目數以及服務器的處理時間統計信息。

六、集中管理日志

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

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