日誌排查不僅僅是盲目搜尋，更是一門科學。當問題發生時，遵循一個標準化的流程能幫助你快速找到根源，而不是浪費時間在錯誤的方向。
核心原則：從宏觀到微觀
當一個服務崩潰時，問題可能來自多個層面。我們應遵循「從系統層級到應用程式層級」的檢查原則。

系統層級：檢查伺服器核心日誌，看是否有硬體、核心或核心服務的錯誤。

服務層級：檢查出問題的服務（例如：網頁伺服器）自身日誌，看是否有啟動失敗或配置錯誤。

應用層級：如果服務正常運行但行為不正確，則檢查應用程式自己的日誌，找出程式碼層面的錯誤。

假設網頁（使用 Apache 或 Nginx）突然無法訪問，並且發現該服務已經停止運行。
我的日誌排查步驟：
步驟 1：系統層級檢查
首先，使用 systemctl status 檢查服務的最新狀態，並透過 journalctl 查看最近的日誌。這能幫助判斷服務為何停止。
指令：
systemctl status httpd.service(檢查服務狀態)
journalctl -u httpd.service -n 50 -p err(查看服務日誌，顯示最近 50 行，並過濾出錯誤訊息)
步驟 2：服務層級檢查
如果 journalctl 提供的訊息不夠詳細，需要深入檢查服務自己的錯誤日誌。這些日誌通常會記錄更具體的配置或執行錯誤。
日誌位置：
Apache：/var/log/httpd/error_log
Nginx：/var/log/nginx/error.log
指令：
tail -n 100 /var/log/httpd/error_log(顯示錯誤日誌的最後 100 行)
grep "AH00095" /var/log/httpd/error_log(搜尋日誌中的特定錯誤關鍵字)
預期發現：可能會在這裡找到明確的錯誤訊息，例如「配置檔第 X 行語法錯誤」或「埠號 YYYY 已被佔用」。
步驟 3：應用程式層級檢查
如果服務已成功啟動但網站仍然顯示錯誤（例如 HTTP 500 錯誤），問題很可能來自應用程式本身。
日誌位置：
Apache/Nginx 存取日誌：
/var/log/httpd/access_log
/var/log/nginx/access.log
應用程式自定義日誌：如 /var/www/html/app/logs/。
指令：
grep " 500 " /var/log/httpd/access_log(搜尋所有 500 錯誤狀態碼)
預期發現：透過篩選 500 錯誤，可以找到是哪個特定的請求觸發了應用程式錯誤，然後可以去檢查對應的應用程式日誌，找出錯誤堆疊追蹤。

掌握這個流程後，將能更有效率地進行故障排除，即使每個問題都不盡相同。