本文是从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/ target=_blank class=infotextkey>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，是一个比较流行的开源解决方案。