教你看懂 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

這條日誌咱們能夠得知：

1. 代碼模塊是 nova.virt.libvirt.config，由此可知應該是 Hypervisor Libvirt 相關的操做

2. 日誌內容是生成 XML

3. 若是要跟蹤源代碼，能夠到 /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

這條日誌咱們能夠得知：

1. 這是一個 ERROR 日誌

2. 具體內容是 「No compute node record for host devstack-controller」

3. 該日誌沒有指明源代碼位置

關於日誌的幾點說明

1. 學習 OpenStack 須要看日誌嗎？這個問題的答案取決於你是誰。 若是你只是 OpenStack 的最終用戶，那麼日誌對你不重要。你只須要在 GUI上 操做，若是出問題直接找管理員就能夠了。 但若是你是 OpenStack 的運維和管理人員，日誌對你就很是重要了。由於 OpenStack 操做若是出錯，GUI 上給出的錯誤信息是很是籠統和簡要的，日誌則提供了大量的線索，特別是當 debug 選項打開以後。 若是你正處於 OpenStack 的學習階段，正如咱們如今的狀態，那麼也強烈建議你多看日誌。日誌可以幫助你更加深刻理解 OpenStack 的運行機制。

2. 日誌可以幫助咱們深刻學習 OpenStack 和排查問題。但要想高效的使用日誌還得有個前提： 必須先掌握 OpenStack 的運行機制，而後針對性的查看日誌。 就拿 Instance Launch 操做來講，若是以前不瞭解 nova-* 各子服務在操做中的協做關係，若是沒有理解流程圖，面對如此多和分散的日誌文件，咱們也很難下手不是。

3. 對於 OpenStack 的運維和管理員來講，在大部分狀況下，咱們都不須要看源代碼。 由於 OpenStack 的日誌記錄得很詳細了，足以幫助咱們分析和定位問題。 但仍是有一些細節日誌沒有記錄，必要時能夠經過查看源代碼理解得更清楚。 即使如此，日誌也會爲咱們提供源代碼查看的線索，不須要咱們大海撈針。 這一點咱們會在後面的操做分析中看到。