instance 从创建到删除的整个生命周期都是有 Nova 管理的，后面各小节我们以instance生命周期中不同操作场景为例，详细分析 Nova不同组件如何协调工作，并通过日志分析加深大家对 Nova 的理解
在研究 Nova 各个操作之前，我们先来学习一个重要的内容：OpenStack 日志。OpenStack 的日志记录了非常详细的细节信息，是我们学习和Troubleshooting的利器。
日志的位置
我们实验环境使用的是DevStack ，日志统一放在 /opt/stack/logs 下面，每个服务都有自己的日志文件，从命名上很容易区分。
对于非 DevStack 安装的OpenStack ，日志一般放在 /var/log/xxx/ 目录下
各个子服务的日志文件也是单独保存的，命名也很规范，容易区分。比如nova-api 的日志，存放路径 /var/log/nova/api.log
root@DevStack-Controller:~# ls /opt/stack/logs/ | grep -v 2019
c-api.log # cinder日志
c-sch.log
c-vol.log
dstat-csv.log
dstat.log
g-api.log # glance-api 日志
g-reg.log # glance-registry日志
horizon.log
key-access.log
key.log # keystone日志
n-api.log # nova-api日志
n-cauth.log
n-cond.log
n-cpu.log # nova-compute日志
n-dhcp.log
n-novnc.log
n-sch.log
placement-api.log
q-agt.log
q-dhcp.log # q- 是Neutron日志
q-l3.log
q-meta.log
q-svc.log
screen
stack.sh.log
stack.sh.log.summary
日志的格式
OpenStack 的日志格式都是统一的，如下：
<时间戳><日志等级><代码模块><Request ID><日志内容><源代码位置>
简单说一下：
<时间戳> 日志记录的时间点，年月日时分秒
<日志等级> INFO WARNING ERROR DEBUG 等
<代码模块> 当前运行的模块1
<Request ID> 日志会记录连续不同的操作，为了便于区分和增加可读性，每个操作都被分配唯一的 Request ID ，便于查找日志内容
<日志内容> 这是日志的主体，记录当前正在执行的操作和结果等重要信息
<源代码位置> 日志代码的位置，包括方法名称、源代码文件的目录位置和行号，这一项不是所有日志都有
2019-05-23 16:35:16.430
DEBUG
nova.compute.manager
[req-808daefa-2cd8-4c34-bd34-2730453805da admin admin]
[instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Starting instance...
from (pid=4613) _do_build_and_run_instance /opt/stack/nova/nova/compute/manager.py:1766
2019-05-23 16:35:16.528
INFO
nova.compute.claims
[req-808daefa-2cd8-4c34-bd34-2730453805da admin admin]
[instance: a0e2b485-f40c-43e4-beb6-049b6399f0ec] Attempting claim: memory 256 MB, disk 0 GB, vcpus 1 CPU
关于日志的几点说明
1、学习OpenStack 需要看日志吗？这个问题的答案取决于你是谁。如果你是OpenStack的最终用户，那么日志对你不重要。你只需要爱GUI 上操作就可以了，出过出了问题直接找管理员处理。但如果你是OpenStack的运维和管理人员，日志对你就非常重要了。因为OpenStack操作如果出错，GUI上给出的错误信息是非常笼统和简要的，日志则提供了大量的线索，特别是当debug选项打开之后。如果你正处于OpenStack的学习阶段，正如我们现在的状态，那么也强烈建议你多看日志。日志能够帮助你更加深入理解 OpenStack 的运行机制
2、日志能够帮助我们深入学习OpenStack 和排查问题。但要想高效的使用日志还有个前提：必须先掌握OpenStack的运行机制，然后针对性的查看日志。就拿Instance Launch 的操作来说，如果之前不了解 nova-* 各子服务在操作中的协作关系，如果没有理解流程图，面对如此多而且分散的日志文件，我们也很难下手。
3、对于OpenStack 的运维和管理员来说，在大部分情况下，我们不需要看源代码。因为OpenStack的日志记录的很详细了，足以帮助我们分析和定位问题。但还是有一些细节日志没有记录，必要时可以通过查看源代码来来接得更清楚。即便如此，日志也会为我们提供源代码查看的线索，不需要我们大海捞针。这一点我们会在后面的操作分析中看到。