在 Linux 中使用日誌來排錯

人們建立日誌的主要原因是排錯。通常你會診斷為什麼問題發生在你的 Linux 系統或應用程式中。錯誤資訊或一系列的事件可以給你提供找出根本原因的線索，說明問題是如何發生的，並指出如何解決它。這裡有幾個使用日誌來解決的樣例。

登入失敗原因

如果你想檢查你的系統是否安全，你可以在驗證日誌中檢查登入失敗的和登入成功但可疑的使用者。當有人通過不正當或無效的憑據來登入時會出現認證失敗，這通常發生在使用 SSH 進行遠端登入或 su 到本地其他使用者來進行訪問權時。這些是由插入式驗證模組（PAM）來記錄的。在你的日誌中會看到像 Failed password 和 user unknown 這樣的字串。而成功認證記錄則會包括像 Accepted password 和 session opened 這樣的字串。

失敗的例子:

成功的例子：

你可以使用 grep 來查詢哪些使用者失敗登入的次數最多。這些都是潛在的攻擊者正在嘗試和訪問失敗的賬戶。這是一個在 ubuntu 系統上的例子。

由於沒有標準格式，所以你需要為每個應用程式的日誌使用不同的命令。日誌管理系統，可以自動分析日誌，將它們有效的歸類，幫助你提取關鍵字，如使用者名稱。

日誌管理系統可以使用自動解析功能從 Linux 日誌中提取使用者名稱。這使你可以看到使用者的資訊，並能通過點選過濾。在下面這個例子中，我們可以看到，root 使用者登入了 2700 次之多，因為我們篩選的日誌僅顯示 root 使用者的嘗試登入記錄。

日誌管理系統也可以讓你以時間為做座標軸的圖表來檢視，使你更容易發現異常。如果有人在幾分鐘內登入失敗一次或兩次，它可能是一個真正的使用者而忘記了密碼。但是，如果有幾百個失敗的登入並且使用的都是不同的使用者名稱，它更可能是在試圖攻擊系統。在這裡，你可以看到在3月12日，有人試圖登入 Nagios 幾百次。這顯然​​不是一個合法的系統使用者。

重啟的原因

有時候，一臺伺服器由於系統崩潰或重啟而當機。你怎麼知道它何時發生，是誰做的？

關機命令
如果有人手動執行 shutdown 命令，你可以在驗證日誌檔案中看到它。在這裡，你可以看到，有人從 IP 50.0.134.125 上作為 ubuntu 的使用者遠端登入了，然後關閉了系統。

核心初始化

如果你想看看伺服器重新啟動的所有原因（包括崩潰），你可以從核心初始化日誌中尋找。你需要搜尋核心類（kernel）和 cpu 初始化（Initializing）的資訊。

檢測記憶體問題

有很多原因可能導致伺服器崩潰，但一個常見的原因是記憶體用盡。

當你係統的記憶體不足時，程式會被殺死，通常會殺死使用最多資源的程式。當系統使用了所有記憶體，而新的或現有的程式試圖使用更多的記憶體時就會出現錯誤。在你的日誌檔案查詢像 Out of Memory 這樣的字串或類似 kill 這樣的核心警告資訊。這些資訊表明系統故意殺死程式或應用程式，而不是允許程式崩潰。

例如:

你可以使用像 grep 這樣的工具找到這些日誌。這個例子是在 ubuntu 中:

請記住，grep 也要使用記憶體，所以只是執行 grep 也可能導致記憶體不足的錯誤。這是另一個你應該中央化儲存日誌的原因！

定時任務錯誤日誌

cron 守護程式是一個排程器，可以在指定的日期和時間執行程式。如果程式執行失敗或無法完成，那麼 cron 的錯誤出現在你的日誌檔案中。具體取決於你的發行版，你可以在 /var/log/cron，/var/log/messages，和 /var/log/syslog 幾個位置找到這個日誌。cron 任務失敗原因有很多。通常情況下，問題出在程式中而不是 cron 守護程式本身。

預設情況下，cron 任務的輸出會通過 postfix 傳送電子郵件。這是一個顯示了該郵件已經傳送的日誌。不幸的是，你不能在這裡看到郵件的內容。

你可以考慮將 cron 的標準輸出記錄到日誌中，以幫助你定位問題。這是一個你怎樣使用 logger 命令重定向 cron 標準輸出到 syslog的例子。用你的指令碼來代替 echo 命令，helloCron 可以設定為任何你想要的應用程式的名字。

它建立的日誌條目：

每個 cron 任務將根據任務的具體型別以及如何輸出資料來記錄不同的日誌。

希望在日誌中有問題根源的線索，也可以根據需要新增額外的日誌記錄。