閱讀962 返回首頁    go 技術社區[雲棲]

LXD 2.0 係列（十二）：調試，及給 LXD 做貢獻

介紹

終於要結束了！這個大約一年前開始的這係列文章的最後一篇博文。

  1. LXD 入門
  2. 安裝與配置
  3. 你的第一個 LXD 容器
  4. 資源控製
  5. 鏡像管理
  6. 遠程主機及容器遷移
  7. LXD 中的 Docker
  8. LXD 中的 LXD
  9. 實時遷移
  10. LXD 和 Juju
  11. LXD 和 OpenStack
  12. 調試，及給 LXD 做貢獻

如果你從一開始就關注了這個係列，你應該已經使用了 LXD 相當長的時間了，並且非常熟悉它的日常操作和功能。

但如果出現問題怎麼辦？你可以做什麼來自己跟蹤問題？如果你不能，你應該記錄什麼信息，以便上遊可以跟蹤問題？

如果你想自己解決問題或通過實現你需要的功能來幫助改善LXD怎麼辦？如何構建，測試和貢獻 LXD 代碼庫？

調試 LXD 並填寫 bug 報告

LXD 日誌文件

/var/log/lxd/lxd.log：

這是 LXD 日誌的主文件。為了避免它快速充滿你的磁盤，默認隻會記錄 INFO、WARNING 或者 ERROR 級別的日誌。你可以在 LXD 守護進程中使用 –debug 改變其行為。

/var/log/lxd/CONTAINER/lxc.conf：

每當你啟動容器時，此文件將更新為傳遞給 LXC 的配置。

這裏會展示容器將如何配置，包括其所有的設備、綁定掛載等等。

/var/log/lxd/CONTAINER/forkexec.log：

這個文件包含 LXC 命令執行失敗時產生的錯誤。這個情況是非常罕見的，因為 LXD 通常會在發生之前處理大多數錯誤。

/var/log/lxd/CONTAINER/forkstart.log：

這個文件包含 LXC 在啟動容器時的錯誤信息。含 LXC 命令執行失敗時產生的錯誤。

CRIU 日誌 (對於實時遷移)

如果使用 CRIU 進行容器實時遷移或實時快照，則每次生成 CRIU 轉儲或恢複轉儲時都會記錄額外的日誌文件。

這些日誌也可以在 /var/log/lxd/CONTAINER/ 中找到，並且有時間戳，以便你可以找到與你最近的操作所匹配的那些日誌。它們包含 CRIU 轉儲和恢複的所有內容的詳細記錄，並且比典型的遷移/快照錯誤消息更容器理解。

LXD 調試消息

如上所述，你可以使用 -debug 選項將守護進程切換為執行調試日誌記錄。另一種方法是連接到守護進程的事件接口，它將顯示所有日誌條目，而不管配置的日誌級別（即使是遠程工作）。

舉例說，對於 lxc init ubuntu:16.04 xen 來說，

lxd.log 會是這樣：



    

  1. INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
    2. 

  2. INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
    3. 



而 lxc monitor –type=logging 會是：




    

  1. metadata:
    2. 

  2.  context: {}
    3. 

  3.  level: dbug
    4. 

  4.  message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'
    5. 

  5. timestamp: 2017-02-24T18:14:01.025989062-05:00
    6. 

  6. type: logging
    7. 

    8. 

  8. metadata:
    9. 

  9.  context:
    10. 

  10.  ip: '@'
    11. 

  11.  method: GET
    12. 

  12.  url: /1.0
    13. 

  13.  level: dbug
    14. 

  14.  message: handling
    15. 

  15. timestamp: 2017-02-24T18:14:09.341283344-05:00
    16. 

  16. type: logging
    17. 

    18. 

  18. metadata:
    19. 

  19.  context:
    20. 

  20.  driver: storage/zfs
    21. 

  21.  level: dbug
    22. 

  22.  message: StorageCoreInit
    23. 

  23. timestamp: 2017-02-24T18:14:09.341536477-05:00
    24. 

  24. type: logging
    25. 

    26. 

  26. metadata:
    27. 

  27.  context:
    28. 

  28.  ip: '@'
    29. 

  29.  method: GET
    30. 

  30.  url: /1.0/containers/xen
    31. 

  31.  level: dbug
    32. 

  32.  message: handling
    33. 

  33. timestamp: 2017-02-24T18:14:09.347709394-05:00
    34. 

  34. type: logging
    35. 

    36. 

  36. metadata:
    37. 

  37.  context:
    38. 

  38.  ip: '@'
    39. 

  39.  method: PUT
    40. 

  40.  url: /1.0/containers/xen/state
    41. 

  41.  level: dbug
    42. 

  42.  message: handling
    43. 

  43. timestamp: 2017-02-24T18:14:09.357046302-05:00
    44. 

  44. type: logging
    45. 

    46. 

  46. metadata:
    47. 

  47.  context: {}
    48. 

  48.  level: dbug
    49. 

  49.  message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    50. 

  50. timestamp: 2017-02-24T18:14:09.358387853-05:00
    51. 

  51. type: logging
    52. 

    53. 

  53. metadata:
    54. 

  54.  context: {}
    55. 

  55.  level: dbug
    56. 

  56.  message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    57. 

  57. timestamp: 2017-02-24T18:14:09.358578599-05:00
    58. 

  58. type: logging
    59. 

    60. 

  60. metadata:
    61. 

  61.  context:
    62. 

  62.  ip: '@'
    63. 

  63.  method: GET
    64. 

  64.  url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait
    65. 

  65.  level: dbug
    66. 

  66.  message: handling
    67. 

  67. timestamp: 2017-02-24T18:14:09.366213106-05:00
    68. 

  68. type: logging
    69. 

    70. 

  70. metadata:
    71. 

  71.  context:
    72. 

  72.  driver: storage/zfs
    73. 

  73.  level: dbug
    74. 

  74.  message: StoragePoolInit
    75. 

  75. timestamp: 2017-02-24T18:14:09.369636451-05:00
    76. 

  76. type: logging
    77. 

    78. 

  78. metadata:
    79. 

  79.  context:
    80. 

  80.  driver: storage/zfs
    81. 

  81.  level: dbug
    82. 

  82.  message: StoragePoolCheck
    83. 

  83. timestamp: 2017-02-24T18:14:09.369771164-05:00
    84. 

  84. type: logging
    85. 

    86. 

  86. metadata:
    87. 

  87.  context:
    88. 

  88.  container: xen
    89. 

  89.  driver: storage/zfs
    90. 

  90.  level: dbug
    91. 

  91.  message: ContainerMount
    92. 

  92. timestamp: 2017-02-24T18:14:09.424696767-05:00
    93. 

  93. type: logging
    94. 

    95. 

  95. metadata:
    96. 

  96.  context:
    97. 

  97.  driver: storage/zfs
    98. 

  98.  name: xen
    99. 

  99.  level: dbug
    100. 

  100.  message: ContainerUmount
    101. 

  101. timestamp: 2017-02-24T18:14:09.432723719-05:00
    102. 

  102. type: logging
    103. 

    104. 

  104. metadata:
    105. 

  105.  context:
    106. 

  106.  container: xen
    107. 

  107.  driver: storage/zfs
    108. 

  108.  level: dbug
    109. 

  109.  message: ContainerMount
    110. 

  110. timestamp: 2017-02-24T18:14:09.721067917-05:00
    111. 

  111. type: logging
    112. 

    113. 

  113. metadata:
    114. 

  114.  context:
    115. 

  115.  action: start
    116. 

  116.  created: 2017-02-24 23:11:45 +0000 UTC
    117. 

  117.  ephemeral: "false"
    118. 

  118.  name: xen
    119. 

  119.  stateful: "false"
    120. 

  120.  used: 1970-01-01 00:00:00 +0000 UTC
    121. 

  121.  level: info
    122. 

  122.  message: Starting container
    123. 

  123. timestamp: 2017-02-24T18:14:09.749808518-05:00
    124. 

  124. type: logging
    125. 

    126. 

  126. metadata:
    127. 

  127.  context:
    128. 

  128.  ip: '@'
    129. 

  129.  method: GET
    130. 

  130.  url: /1.0
    131. 

  131.  level: dbug
    132. 

  132.  message: handling
    133. 

  133. timestamp: 2017-02-24T18:14:09.792551375-05:00
    134. 

  134. type: logging
    135. 

    136. 

  136. metadata:
    137. 

  137.  context:
    138. 

  138.  driver: storage/zfs
    139. 

  139.  level: dbug
    140. 

  140.  message: StorageCoreInit
    141. 

  141. timestamp: 2017-02-24T18:14:09.792961032-05:00
    142. 

  142. type: logging
    143. 

    144. 

  144. metadata:
    145. 

  145.  context:
    146. 

  146.  ip: '@'
    147. 

  147.  method: GET
    148. 

  148.  url: /internal/containers/23/onstart
    149. 

  149.  level: dbug
    150. 

  150.  message: handling
    151. 

  151. timestamp: 2017-02-24T18:14:09.800803501-05:00
    152. 

  152. type: logging
    153. 

    154. 

  154. metadata:
    155. 

  155.  context:
    156. 

  156.  driver: storage/zfs
    157. 

  157.  level: dbug
    158. 

  158.  message: StoragePoolInit
    159. 

  159. timestamp: 2017-02-24T18:14:09.803190248-05:00
    160. 

  160. type: logging
    161. 

    162. 

  162. metadata:
    163. 

  163.  context:
    164. 

  164.  driver: storage/zfs
    165. 

  165.  level: dbug
    166. 

  166.  message: StoragePoolCheck
    167. 

  167. timestamp: 2017-02-24T18:14:09.803251188-05:00
    168. 

  168. type: logging
    169. 

    170. 

  170. metadata:
    171. 

  171.  context:
    172. 

  172.  container: xen
    173. 

  173.  driver: storage/zfs
    174. 

  174.  level: dbug
    175. 

  175.  message: ContainerMount
    176. 

  176. timestamp: 2017-02-24T18:14:09.803306055-05:00
    177. 

  177. type: logging
    178. 

    179. 

  179. metadata:
    180. 

  180.  context: {}
    181. 

  181.  level: dbug
    182. 

  182.  message: 'Scheduler: container xen started: re-balancing'
    183. 

  183. timestamp: 2017-02-24T18:14:09.965080432-05:00
    184. 

  184. type: logging
    185. 

    186. 

  186. metadata:
    187. 

  187.  context:
    188. 

  188.  action: start
    189. 

  189.  created: 2017-02-24 23:11:45 +0000 UTC
    190. 

  190.  ephemeral: "false"
    191. 

  191.  name: xen
    192. 

  192.  stateful: "false"
    193. 

  193.  used: 1970-01-01 00:00:00 +0000 UTC
    194. 

  194.  level: info
    195. 

  195.  message: Started container
    196. 

  196. timestamp: 2017-02-24T18:14:10.162965059-05:00
    197. 

  197. type: logging
    198. 

    199. 

  199. metadata:
    200. 

  200.  context: {}
    201. 

  201.  level: dbug
    202. 

  202.  message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    203. 

  203. timestamp: 2017-02-24T18:14:10.163072893-05:00
    204. 

  204. type: logging
    205. 



lxc monitor 的格式有點不同於每個條目都縮合成一行的日誌文件，但更重要的是，你可以看到所有 level：dbug 條目。



如何報告 bug



LXD 的 bug


最好報告 bug 的地方是 https://github.com/lxc/lxd/issues。確保完整填寫了 bug 報告模板中的內容，這些信息可以節省我們我們時間來複現環境。



Ubuntu 的 bug


如果你發現 Ubuntu 包本身有問題，無法安裝、升級或刪除。或者遇到 LXD init 腳本的問題。報告此類錯誤的最好是在 Launchpad 上。


在 Ubuntu 係統上，你可以使用：ubuntu-bug lxd ，它將自動包括一些日誌文件和包信息供我們查看。



CRIU 的 bug


與 CRIU 相關的 Bug，你可以通過 CRIU 的錯誤輸出發現，你應該在 Launchpad 上報告這些：ubuntu-bug criu


請注意，通過 LXD 使用 CRIU 屬於測試版功能，除非你願意通過 Canonical 的支持合同付費支持，要麼可能需要一段時間才能查看你的錯誤報告。



貢獻給 LXD


LXD 用 Go 寫成並托管在 Github。我們歡迎任外部的貢獻。為 LXD 貢獻不需要 CLA 或類似的法律協議簽署，隻是通常的開發者所有權證書（Signed-off-by: 行）。


在我們的問題追蹤器工具中，我們列有許多潛在的功能需求，新的貢獻者可以以此作為良好的起點。通常最好在開始處理代碼先發出 issue，這樣每個人都知道你正在做這項工作，以便我們可以提供一些早期反饋。



從源碼源碼構建 LXD


這裏有上遊的維護說明：https://github.com/lxc/lxd#building-from-source


你需要在 Github 上 fork 上遊倉庫，然後將你的更改推送到你的分支。我們建議每天 rebase 上遊的 LXD，因為我們傾向於定期合並更改。



運行測試套件


LXD 維護了兩套測試集，單元測試和集成測試。你可以用下麵的命令測試所有：




  1. sudo -E make check


要隻運行單元測試，使用：




  1. sudo -E go test ./...


要運行集成測試，使用：




    

  1. cd test
    2. 

  2. sudo -E ./main.sh
    3. 



後者支持相當多的環境變量來測試各種存儲後端、禁用網絡測試、使用 ramdisk 或隻是調整日誌輸出。其中一些是：


    

  • 
LXD_BACKEND：btrfs、dir、lvm 或 zfs” 之一（默認為 dir）   
    
運行 LXD 存儲驅動程序相關的所有測試。
    • 

  • 
LXD_CONCURRENT：true 或 false（默認為 false）   
    
這啟用一些額外的並發測試。
    • 

  • 
LXD_DEBUG：true 或 false（默認為 false）   
    
記錄所有 shell 命令，並在調試模式下運行所有​​ LXD 命令。
    • 

  • 
LXD_INSPECT：true 或 false（默認為 false）   
    
測試程序會在故障時掛起，以便你可以檢查環境。
    • 

  • 
LXD_LOGS：將所有 LXD 日誌文件轉儲到的目錄（默認為 “”）   
    
所有生成的 LXD 守護進程的 logs 目錄將被複製到此路徑。
    • 

  • 
LXD_OFFLINE：true 或 false（默認為 false）   
    
禁用任何依賴於外部網絡連接的測試。
    • 

  • 
LXD_TEST_IMAGE： unified 格式的 LXD 鏡像的路徑（默認為 “”）   
    
可以使用自定義測試鏡像，而不是默認的最小 busybox 鏡像。
    • 

  • 
LXD_TMPFS：true 或 false（默認為 false）   
    
在 tmpfs 安裝中運行整個測試套件，這會使用相當多的內存，但會使測試速度明顯更快。
    • 

  • 
LXD_VERBOSE：true 或 false（默認為 false）   
    
不太極端的 LXD_DEBUG 版本。shell 命令仍然會記錄，但 -debug 不會傳遞給 LXC 命令，LXD 守護進程隻能使用 -verbose 運行。
    • 



測試程序將在實際運行之前提醒你任何缺失的依賴項。在相當快的機器上運行該測試可在 10 分鍾內完成。


原文發布時間為：2017-03-09


本文來自雲棲社區合作夥伴“Linux中國”


最後更新：2017-05-24 16:31:57
  上一篇：go  LXD 2.0 係列（十一）：LXD 和 OpenStack 
  下一篇：go  如何在 Debian 和 Ubuntu 上安裝 MariaDB 10