[ 英语 | 日本語 | Deutsch | Indonesia ]
日志¶
日志在哪里？¶
大多数服务都遵循将日志文件写入 /var/log 目录 的子目录的约定，如 OpenStack 日志位置表 中所述。
节点类型 |
服务 |
日志位置 |
|---|---|---|
云控制器 |
|
|
云控制器 |
|
|
云控制器 |
|
|
云控制器 |
|
|
云控制器 |
|
|
云控制器 |
horizon |
|
所有节点 |
杂项 (swift, dnsmasq) |
|
计算节点 |
libvirt |
|
计算节点 |
虚拟机实例的控制台（启动消息） |
|
块存储节点 |
cinder-volume |
|
读取日志¶
OpenStack 服务使用标准的日志级别，严重程度递增：TRACE、DEBUG、INFO、AUDIT、WARNING、ERROR 和 CRITICAL。也就是说，只有消息的严重程度高于特定的日志级别时，才会出现在日志中，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 框架约定。
查找错误来源的第一步通常是在日志文件的底部开始搜索 CRITICAL 或 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 |
+--------------------------------------+--------+--------+--------------------+------------+
这里，与实例关联的 ID 是 faf7ded8-4a46-413b-b113-f19590746ffe。如果您在云控制器上的 /var/log/nova-*.log 文件中搜索此字符串，它将出现在 nova-api.log 和 nova-scheduler.log 中。如果您在计算节点上的 /var/log/nova-*.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 管理界面。在您的云控制器上启用它
# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart
RabbitMQ Web 管理界面可以在您的云控制器上的 https://:55672 访问。
注意
Ubuntu 12.04 安装 RabbitMQ 版本 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 引擎可用，每个引擎都有不同的功能和配置要求。
