教你看懂 OpenStack 日志 - 每天5分鐘玩轉 OpenStack（29）日志的位置日志的格式關于日志的幾點說明

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 的日志記錄得很詳細了，足以幫助我們分析和定位問題。

但還是有一些細節日志沒有記錄，必要時可以通過檢視源代碼了解得更清楚。

即便如此，日志也會為我們提供源代碼檢視的線索，不需要我們大海撈針。

這一點我們會在後面的操作分析中看到。

本文轉自CloudMan6 51CTO部落格，原文連結:

http://blog.51cto.com/cloudman/1769895