在昨天的篇章中，我們完成了網路連線與通訊埠監聽的排查。但在日常維運伺服器時，更常遇到的情況往往是：「網路明明正常，但背景跑的程式卻突然停止運作了。」

在 Day 24 時，我們將 Python 爬蟲做成了 Systemd 背景常駐服務。常駐服務雖然方便，但當程式發生錯誤而崩潰時，終端機畫面上並不會直接跳出報錯訊息。這時候想還原現場、找出問題原因，就必須依賴系統日誌（System Logs）。

在 Ubuntu 這類現代 Linux 系統中，所有的系統訊息與背景服務輸出，都由Systemd Journal統一負責記錄。今天這篇就來分享如何運用 journalctl 這個核心工具，在龐大的日誌紀錄中精準定位故障原因。

1.傳統文字日誌 vs Systemd Journal
在開始下指令前，先簡單了解 Linux 常見的兩種日誌形式：
(1) 傳統文字日誌（/var/log 目錄） ：

• 早期 Linux 的標準做法，將紀錄以純文字檔案形式存放。
• 最具代表性的是 /var/log/auth.log，專門記錄使用者的登入驗證、密碼錯誤嘗試以及 sudo 提權紀錄。

(2)現代集中化日誌（Systemd Journal）：

• Ubuntu 預設的主力日誌系統，由 systemd-journald 集中管理。
• 它會把作業系統核心訊息、開機程序，以及所有 Systemd 背景服務的標準輸出與錯誤輸出統整起來，並以二進位格式壓縮儲存。
• 由於是二進位檔案，無法直接用 cat 或 nano 開啟，必須透過專門的檢視工具 journalctl 進行查詢。

2.鎖定單一服務進行除錯
當自建的常駐服務（如 crypto-tracker.service）狀態顯示為 failed 或 inactive 時，最直接的排查方式是只調閱該服務專屬的日誌，避免被其他系統訊息干擾。

(1)檢視特定服務的完整日誌（-u）

sudo journalctl -u crypto-tracker.service

• -u（Unit）：指定 Systemd 服務名稱，終端機就只會列出該服務產生的所有紀錄。

(2)即時滾動監控日誌（-f）
如果剛修改完程式碼並重新啟動服務，想要即時觀察它的執行狀況，可加上 -f（follow）參數：

sudo journalctl -u crypto-tracker.service -f

終端機會保持在等待狀態，並持續印出最新的日誌輸出。若要離開監控畫面，按下 Ctrl + C 即可。
(3)直接查看最新筆數或跳至底端（-n 與 -e）
程式崩潰時的報錯回溯通常都在最末端，可透過以下方式快速查看：

# 只列出最後 50 行，搭配 --no-pager 直接在終端機輸出而不進入分頁模式
sudo journalctl -u crypto-tracker.service -n 50 --no-pager
# 或是加上 -e 直接捲動至日誌最底部
sudo journalctl -u crypto-tracker.service -e

3.運用時間與錯誤等級縮小範圍
伺服器運行一段時間後，即使指定了單一服務，累積的日誌行數依然十分龐大。善用 journalctl 的過濾參數能大幅提升排查效率：

(1)依時間範圍過濾（--since / --until）
當得知異常發生在特定時間點時，可以直接指定篩選區間：

# 僅檢視今天產生的日誌
sudo journalctl --since "today"
# 僅檢視最近 1 小時以內的日誌
sudo journalctl --since "1 hour ago"
# 指定明確的時間區間
sudo journalctl --since "2026-09-28 14:00:00" --until "2026-09-28 15:00:00"

(2)依錯誤等級過濾（-p）
Linux 的日誌依照嚴重程度分為不同等級（Priority）。如果不想閱讀一般的資訊紀錄，只想找出異常或警告，可加上 -p 參數：

# 僅顯示錯誤（err）與警告（warning）等級以上的訊息
sudo journalctl -p err..warning

(3)檢視前一次開機的紀錄（-b）
如果主機曾發生非預期的重開機，需要調閱上一次運作期間最後留下的訊息，可以使用 -b（boot）參數：

# 檢視上一次開機週期的日誌（-1 代表前一次）
sudo journalctl -b -1 -e

4.確認 SSH 密碼停用防禦是否生效
在 Day 26 中，我們關閉了 SSH 的密碼登入功能，強制只能使用金鑰認證。透過日誌檢驗，可以確認這道安全防線是否確實發揮作用：

(1)檢視登入失敗的紀錄
在終端機中執行：

sudo journalctl -u ssh | grep "Failed"

如果在 Day 26 有使用強制略過金鑰的指令測試登入，日誌中會出現類似以下內容：

sshd[2314]: Failed publickey for invalid user ... from 10.0.2.2 port ...
sshd[2314]: Connection closed by authenticating user ... [preauth]

其中的 [preauth] 代表連線在「預先驗證」階段就被伺服器主動中斷，完全沒有進入輸入密碼的流程，這表示密碼驗證管道確實已被阻斷。
(2)檢視合法登入紀錄
若要確認正常連線的紀錄：

sudo journalctl -u ssh | grep "Accepted publickey"

此指令能清楚列出成功登入的使用者帳號、來源 IP 以及所使用的公鑰指紋，有助於進行日常存取稽核。

明日目標：迎來第30天！明天將全面複盤這台虛擬主機從零到有的建置成果，完成我們的30天 Linux 避坑挑戰。|