用日誌瞭解你的 Linux 系統

在你的 Linux 計算機上有不少不一樣的日誌。歷史上，它們通常以純文本的格式存儲到 /var/log 目錄中。如今依然有不少日誌這樣作，你能夠很方便的使用 less 來查看它們。

在新裝的 openSUSE Leap 42.3 以及大多數現代操做系統上，重要的日誌由 systemd 初始化系統存儲。 systemd 這套系統負責啓動守護進程，並在系統啓動時讓計算機作好被使用的準備。由 systemd 記錄的日誌以二進制格式存儲，這使得它們消耗的空間更小，更容易被瀏覽，也更容易被導出成其餘各類格式，不過壞處就是你必須使用特定的工具才能查看。好在這個工具已經預安裝在你的系統上了：它的名字叫 journalctl ，並且默認狀況下，它會將每一個守護進程的全部日誌都記錄到一個地方。

只須要運行 journalctl 命令就能查看你的 systemd 日誌了。它會用 less 分頁器顯示各類日誌。爲了讓你有個直觀的感覺, 下面是 journalctl 中摘錄的一條日誌記錄：

這條獨立的日誌記錄以此包含了記錄的日期和時間、計算機名、記錄日誌的進程名、記錄日誌的進程 PID，以及日誌內容自己。

若系統中某個程序運行出問題了，則能夠查看日誌文件並搜索（使用 / 加上要搜索的關鍵字）程序名稱。有可能致使該程序出問題的錯誤會記錄到系統日誌中。 有時，錯誤信息會足夠詳細到讓你可以修復該問題。其餘時候，你須要在 Web 上搜索解決方案。 Google 就很適合來搜索奇怪的 Linux 問題。不過搜索時請注意你只輸入了日誌的實際內容，行首的那些信息（日期、主機名、進程 ID) 對搜索來講是無心義的，會干擾搜索結果。

解決方法通常在搜索結果的前幾個鏈接中就會有了。固然，你不能只是無腦得運行從互聯網上找到的那些命令：請必定先搞清楚你要作的事情是什麼，它的效果會是什麼。聽說，搜索系統日誌中的特定條目要比直接描述該故障通用關鍵字要有用的多。由於程序出錯有不少緣由，並且一樣的故障表現也可能由多種問題引起的。

好比，系統沒法發聲的緣由有不少，多是播放器沒有插好，也多是聲音系統出故障了，還多是缺乏合適的驅動程序。若是你只是泛泛的描述故障表現，你會找到不少無關的解決方法，而你也會浪費大量的時間。而專門搜索日誌文件中的實際內容，你也許會查詢出其它人也有相同日誌內容的結果。

你能夠對比一下圖 1 和圖 2：

圖 1 搜索系統的故障表現只會顯示泛泛的，不精確的結果，這種搜索一般沒什麼用。

圖 2 搜索特定的日誌行會顯示出精確的，有用的結果。這種搜索一般頗有用。

也有一些系統不用 journalctl 來記錄日誌。在桌面系統中最多見的這類日誌包括用於記錄 openSUSE 包管理器的行爲的 /var/log/zypper.log ； 記錄系統啓動時消息的 /var/log/boot.log ，開機時這類消息每每滾動的特別快，根本看不過來；/var/log/ntp 用來記錄 Network Time Protocol （NTP）守護進程同步時間時發生的錯誤。 另外一個存放硬件故障信息的地方是 「Kernel Ring Buffer」（內核環狀緩衝區），你能夠輸入 demesg -H 命令來查看（這條命令也會調用 less 分頁器來查看）。「Kernel Ring Buffer」 存儲在內存中，所以會在重啓電腦後丟失。不過它包含了 Linux 內核中的重要事件，好比新增了硬件、加載了模塊，以及奇怪的網絡錯誤。

via: https://www.suse.com/communities/blog/system-logs-understand-linux-system/

做者：[chabowski] 譯者：lujun9972 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

更多Linux諮詢請查看www.linuxprobe.com