instance 從創建到刪除的整個生命周期都是由 Nova 管理的。 后面各小節我們以 instance 生命周期中的不同操作場景為例，詳細分析 Nova 不同組件如何協調工作，並通過日志分析加深大家對 Nova 的理解。
在研究 Nova 各個操作之前，我們先來學習一個重要的內容：OpenStack 日志。
OpenStack 的日志記錄了非常詳細的細節信息，是我們學習和 troubleshoting 的利器。
日志的位置
我們實驗環境使用的是 devstack，日志都統一放在 /opt/stack/logs 目錄下，每個服務有自己的日志文件，從命名上很容易區分。
比如 nova-* 各個子服務的日志都以 “n-” 開頭： n-api.log 是 nova-api 的日志 n-cpu.log 是 nova-compute 的日志。
Glance 的日志文件都是 “g-” 開頭： g-api.log 是 glance-api 的日志 g-reg.log 是 glance-registry 的日志。
Cinder、Neutron 的日志分別以 “c-” 和 “q-” 開頭。
對於非 devstack 安裝的 OpenStack，日志一般放在 /var/log/xxx/ 目錄下。 比如 Nova 放在 /var/log/nova/ 下，Glance 放在/var/log/glance下……
各個子服務的日志文件也是單獨保存，命名也很規范，容易區分。 比如 nova-api 的日志一般就命名為 /var/log/nova/api.log，其他日志類似。
日志的格式
OpenStack 的日志格式都是統一的，如下
<時間戳><日志等級><代碼模塊><Request ID><日志內容><源代碼位置>
簡單說明一下
時間戳 日志記錄的時間，包括 年 月 日 時 分 秒 毫秒
日志等級 有INFO WARNING ERROR DEBUG等
代碼模塊 當前運行的模塊Request ID 日志會記錄連續不同的操作，為了便於區分和增加可讀性，每個操作都被分配唯一的Request ID,便於查找
日志內容 這是日志的主體，記錄當前正在執行的操作和結果等重要信息
源代碼位置 日志代碼的位置，包括方法名稱，源代碼文件的目錄位置和行號。這一項不是所有日志都有
下面舉例說明
2015-12-10 20:46:49.566 DEBUG nova.virt.libvirt.config [req-5c973fff-e9ba-4317-bfd9-76678cc96584 None None] Generated XML ('<cpu>\n <arch>x86_64</arch>\n <model>Westmere</model>\n <vendor>Intel</vendor>\n <topology sockets="2" cores="3" threads="1"/>\n <feature name="avx"/>\n <feature name="ds"/>\n <feature name="ht"/>\n <feature name="hypervisor"/>\n <feature name="osxsave"/>\n <feature name="pclmuldq"/>\n <feature name="rdtscp"/>\n <feature name="ss"/>\n <feature name="vme"/>\n <feature name="xsave"/>\n</cpu>\n',) to_xml /opt/stack/nova/nova/virt/libvirt/config.py:82
這條日志我們可以得知：
-
代碼模塊是 nova.virt.libvirt.config，由此可知應該是 Hypervisor Libvirt 相關的操作
-
日志內容是生成 XML
-
如果要跟蹤源代碼，可以到 /opt/stack/nova/nova/virt/libvirt/config.py 的 82 行，方法是 to_xml
又例如下面這條日志：
2015-12-10 20:46:49.671 ERROR nova.compute.manager [req-5c973fff-e9ba-4317-bfd9-76678cc96584 None None] No compute node record for host devstack-controller
這條日志我們可以得知：
-
這是一個 ERROR 日志
-
具體內容是 “No compute node record for host devstack-controller”
-
該日志沒有指明源代碼位置
關於日志的幾點說明
-
學習 OpenStack 需要看日志嗎？這個問題的答案取決於你是誰。 如果你只是 OpenStack 的最終用戶，那么日志對你不重要。你只需要在 GUI上 操作，如果出問題直接找管理員就可以了。 但如果你是 OpenStack 的運維和管理人員，日志對你就非常重要了。因為 OpenStack 操作如果出錯，GUI 上給出的錯誤信息是非常籠統和簡要的，日志則提供了大量的線索，特別是當 debug 選項打開之后。 如果你正處於 OpenStack 的學習階段，正如我們現在的狀態，那么也強烈建議你多看日志。日志能夠幫助你更加深入理解 OpenStack 的運行機制。
-
日志能夠幫助我們深入學習 OpenStack 和排查問題。但要想高效的使用日志還得有個前提： 必須先掌握 OpenStack 的運行機制，然后針對性的查看日志。 就拿 Instance Launch 操作來說，如果之前不了解 nova-* 各子服務在操作中的協作關系，如果沒有理解流程圖，面對如此多和分散的日志文件，我們也很難下手不是。
-
對於 OpenStack 的運維和管理員來說，在大部分情況下，我們都不需要看源代碼。 因為 OpenStack 的日志記錄得很詳細了，足以幫助我們分析和定位問題。 但還是有一些細節日志沒有記錄，必要時可以通過查看源代碼理解得更清楚。 即便如此，日志也會為我們提供源代碼查看的線索，不需要我們大海撈針。 這一點我們會在后面的操作分析中看到。
