🕵️‍♂️ 你的伺服器每天都在寫日記，只是你從來沒打開來看：Logwatch 記錄檔分析軟體全攻略

🔥 一句話總結懶人包： 如果把你的 Linux 伺服器想像成一間24 小時不打烊的便利商店，那麼系統日誌（Log）就是它的監視器錄影帶——每一筆刷卡、每一次有人進出、每一次有奇怪的人在門口徘徊，全部都被老實地記錄下來。問題是，這些錄影帶通常一天就有好幾千小時份量，沒有人有時間從頭看到尾。Logwatch 的角色，就是那位幫你把監視器畫面剪輯成「每日重點摘要」的超勤勞助理，讓你每天早上打開信箱，就能一眼看懂昨天伺服器上到底發生了什麼事。

---

🧾 為什麼你需要認識「日誌」這回事？

先問一個扎心的問題：如果你的網站或伺服器昨天半夜被駭客嘗試入侵了 300 次，你會知道嗎？

大多數電腦小白（甚至不少工程師）的答案都是：不會知道，除非網站已經掛了。原因很簡單——系統其實一直都有在「寫日記」，只是這本日記藏在很深的資料夾裡，而且寫得密密麻麻、全是英文縮寫，一般人打開來看，感覺就像在看外星文。

這本「日記」在 Linux 的世界裡就叫做記錄檔（Log File）。每次有人嘗試登入、每次網站被訪問、每次系統程式啟動或當機，都會被系統忠實地寫進日誌檔裡。這些日誌檔案就像餐廳廚房裡貼滿整面牆的出餐紀錄單——鉅細靡遺，但也因為太過詳細、太過雜亂，一般人光用眼睛掃過去，很難抓出真正重要的資訊。

而 Logwatch，正是為了解決這個困擾而生的老牌開源工具。它會定期（通常是每天）把伺服器裡各種服務（SSH 登入、網站伺服器、郵件伺服器、防火牆⋯⋯）產生的日誌，全部耙梳過一遍，濃縮成一份「懶人包報表」，透過電子郵件寄給你，或存成一個檔案讓你隨時查閱。

💡 碎碎念冷知識： Logwatch 是用 Perl 語言撰寫的開源程式，誕生時間相當早（在 Log 分析工具還很稀少的年代就已經存在），因此在幾乎所有主流 Linux 發行版（Ubuntu、Debian、CentOS、Rocky Linux、Fedora、Arch Linux）的官方軟體庫裡都找得到它，安裝起來非常單純。它並不提供「即時警報」（不會在駭客攻擊當下立刻通知你），而是像「每日總結」的晨報，讓你養成每天花 5 分鐘檢查伺服器健康狀況的習慣。

🍱 Logwatch 到底能幫你看什麼？

把 Logwatch 想像成一位每天固定時間會來你店裡巡視、然後留一張紙條總結重點的資深店長，牠常見的巡邏重點包括：

• 🔐 每日安全稽核：抓出 SSH 登入失敗、sudo 權限濫用、未經授權的存取嘗試，就像巡邏員特別留意「有沒有人一直在後門轉來轉去」。
• 🩺 服務健康檢查：檢視 Apache、Nginx、Postfix、MySQL 等各種常駐服務的錯誤訊息，等於巡視「店內各個設備有沒有故障警示燈亮起」。
• 💾 硬碟與資源監控：抓出磁碟分區快滿了、硬體出現警告等狀況，就像提醒你「倉庫的貨架快堆不下了，該補貨或清倉了」。
• 📋 合規性報表存檔：幫忙留存系統活動紀錄，供未來稽核或事後追查使用，像超商保留監視器錄影 30 天備查一樣。
• 🔍 事件調查：當你懷疑「某天某個時段」出過事，可以快速調閱那個時間範圍的摘要報表，不用整本監視器錄影帶從頭看到尾。

💡 小提醒： Logwatch 很擅長「每日總結」，但它不是即時監控儀表板。如果你需要的是「駭客正在攻擊的當下立刻跳出警報」，那還是要搭配 Nagios、Zabbix、Grafana 這類即時監控系統，兩者是互補而非取代的關係——一個是巡邏後留的紙條，一個是隨身呼叫器。

📖 先搞懂日誌的「共通語言」：Syslog 標準

在正式安裝 Logwatch 之前，值得先花一分鐘理解「日誌」的共通書寫規則。畢竟系統百百種，如果每一套軟體都用自己的方式記日記，那 Logwatch 這種分析工具根本無從下手解讀。因此絕大多數 Linux 系統的日誌，都會遵循一套共通標準——Syslog。

你可以把 Syslog 想像成全台灣警局共用的「報案紀錄格式」：不管是台北分局還是高雄分局，報案單上一定會有「時間、地點、事發單位、事發內容」這四大欄位，格式統一，日後才方便彙整查詢。Syslog 的紀錄格式基本上也劃分為四個部分：

Linux 系統預設會使用 rsyslog 這套軟體來負責記錄日誌，並依照「事件種類（Facility）」與「事件嚴重程度（Level）」兩種條件，決定要不要把某筆紀錄寫進日誌檔裡。這就像警局會依照「案件類型（竊盜／交通／噪音）」與「嚴重程度（重大刑案／一般糾紛）」來分類建檔一樣：

在預設情況下，Linux 會將大部分的一般日誌資訊儲存在 /var/log/messages 檔案內，而與登入認證相關的日誌，則會另外存放在 /var/log/secure 檔案（在 Debian／Ubuntu 系統上，對應的通常是 /var/log/syslog 與 /var/log/auth.log）。

🌐 網站伺服器也有自己的「監視器格式」：CLF 共通日誌標準

除了系統層級的 Syslog，如果你的伺服器上有跑網站（Apache 或 Nginx），網站伺服器也有一套自己的共通日誌標準，叫做 CLF（Common Log Format）。你可以把它想像成超商 POS 機的每一筆交易明細，格式大致如下：

在預設情況下，Apache 網站伺服器會把相關的網站日誌資訊儲存在檔名為 access_log 的檔案上。理解了這些「共通語言」之後，我們就可以正式進入 Logwatch 的安裝與使用了。

---

🛠️ 安裝篇：三大 Linux 家族通通有解

Logwatch 的安裝方式因為 Linux 發行版不同而略有差異，但整體來說都相當單純，幾乎是「一行指令搞定」的等級。以下依照最常見的三大家族分別說明。

🚨 畫重點！千萬別踩雷： 以下所有指令都需要最高權限（root）才能執行。如果你是登入一般帳號，記得在指令前加上 sudo，或先切換到 root（su -）再操作，否則系統會直接跟你說「權限不足」。

① Ubuntu 系統

Ubuntu 是目前最多人拿來架站、租 VPS（虛擬主機，就像跟房東租一間毛坯屋，自己裝潢）的發行版，安裝流程最簡單：

如果偏好使用 Postfix 這套更現代化的郵件伺服器軟體（也是目前業界較主流的選擇），也可以改用以下方式安裝：

安裝完成後，可以用以下指令確認版本，就像收到包裹後先檢查「型號對不對」：

② Debian 系統

Debian 與 Ubuntu 系出同門（Ubuntu 其實是基於 Debian 打造的），差異只在於 Sendmail 套件名稱多了一個 sendmail-bin

③ CentOS Stream／AlmaLinux／Rocky Linux／Fedora（RHEL 家族）

這幾套發行版都是「紅帽（Red Hat）」的親戚，走的是企業級穩定路線，安裝上使用 dnf 這套套件管理員（可以把它想成 Ubuntu 世界裡 apt 的表兄弟）：

④ CentOS 7（舊版，使用 yum）

如果你手上還有一台服役中的 CentOS 7 老兵，套件管理員會是更早期的 yum：

如果你是使用更早期的 CentOS 8 Stream，也能直接透過 yum 安裝，一行指令即可完成：

⑤ Arch Linux（進階玩家專屬）

Arch Linux 是硬派玩家喜歡的「什麼都要自己動手裝」的發行版，因為官方軟體庫沒有收錄 Sendmail，所以要改用 Postfix 來取代：

💡 碎碎念： 安裝過程中 Logwatch 會跳出提示，要求你選擇要使用哪個 cron 排程服務，這裡建議選擇預設值 cronie 即可。另外也可以搭配其他 SMTP 客戶端來寄送 Logwatch 的通知信，不一定要侷限在 Postfix。

接著需要編輯 Postfix 主設定檔，加入你的網域資訊，並限制它只做「寄信不收信」的用途：

🚨 注意： 這個網域需要同時設定好 A/AAAA 紀錄與 MX 紀錄，Postfix 才能正常運作，這部分建議先確認你的 DNS 網域管理後台是否已經設定完成。

接著編輯別名設定檔，把 root 這行取消註解，並指向你的網域信箱：

編輯完成後，記得執行以下指令讓別名設定生效，並啟動 Postfix 服務：

---

⚙️ 設定篇：讓 Logwatch 學會你要的規矩

安裝完成之後，Logwatch 並不會馬上按照你的意思運作，因為它有一份「預設劇本」——也就是設定檔。你可以把這份設定檔想像成一份「巡邏員的工作守則」：巡邏範圍多大、要巡幾天份的紀錄、寫得多詳細、紀錄要交給誰，全部寫在這裡。

Logwatch 的主要設定檔位於：

🚨 畫重點！千萬別踩雷： 強烈建議不要直接修改這份預設設定檔！原因是，每次系統更新 Logwatch 套件時，這個檔案很可能會被「洗掉重來」，等於你辛苦調整的設定一夕之間全部消失。正確做法是複製一份到 /etc/logwatch/ 目錄下，在自己的複製版本上修改，這樣不管套件怎麼更新，你的個人化設定都能安然無恙。這就像不要直接在原廠說明書上塗改，而是自己另外抄一份筆記來改。

💡 小提醒： 用 nano 編輯時，用方向鍵上下移動即可。改完之後按 Ctrl + X，接著按 Y 確認儲存，最後按 Enter 即可離開，改動會在下次 Logwatch 執行時自動生效，不需要重開機。

🔧 六大關鍵設定項目逐一拆解

打開設定檔後，你會看到落落長一串的變數清單，第一次看到可能會有點眼花，但其實真正需要調整的核心設定，主要就是以下幾項：

1️⃣ 報表要寄給誰（MailTo）

把 root 換成你自己的電子郵件地址即可，例如：

2️⃣ 報表是誰寄出的（MailFrom）

同樣可以換成你自己的寄件地址：

3️⃣ 要分析哪個時間範圍（Range）

這裡的選項就像決定「監視器要調哪一段畫面」，常見選項有三種：

4️⃣ 報表要多詳細（Detail）

這個設定決定報表的「解析度」，就像相機拍照選畫質等級一樣：

5️⃣ 要監控哪些服務（Service）

如果只想關注特定幾項服務，可以逐行列出（就像挑選「只要巡邏 A 棟跟 C 棟，B 棟先不用管」）：

💡 小知識： 若想查詢 Logwatch 支援哪些服務的完整清單，可以查看 /usr/share/logwatch/scripts/services/ 這個目錄底下的檔案，每一個檔案就對應一種可被解析的服務。

6️⃣ 要不要停用每日自動報表（DailyReport）

如果你不希望系統每天自動幫你產生報表（例如只想偶爾手動執行），可以把這行前面的井字號 # 拿掉，改成：

📂 進階：把其他資料夾也納入巡邏範圍（LogDir）

Logwatch 預設只會巡邏 /var/log 這個資料夾，但如果你有其他自訂的日誌資料夾（例如某個網站專案的獨立日誌目錄），可以透過新增 LogDir 這一行來擴大巡邏範圍：

📤 三種輸出方式：印出來、寄出去、存檔案

Logwatch 產生的報表最終要「送到哪裡」，是由 Output 這個變數決定的，總共有三種模式可以選：

如果要選擇「存成檔案」，操作方式是先把 Output 改成 file，接著找到並取消 Filename 這一行的註解，設定你想儲存的路徑與檔名即可。

---

▶️ 執行篇：手動跑一次 vs. 排程自動化

🖱️ 方法一：隨時手動執行

設定檔固然重要，但 Logwatch 也支援在指令列直接加上參數，臨時覆蓋掉設定檔的預設值，非常適合需要「馬上查一次」的情境，就像便利商店店員臨時決定「今天要不要多印一份特定時段的交易明細」。

官方文件列出的完整參數如下（不熟悉沒關係，接下來會逐一說明常用的部分）：

不特別指定的參數，Logwatch 就會自動去讀取設定檔裡的預設值。以下整理最實用的參數速查表：

🎚️ 不同詳細等級的實戰比較

📅 指定特定日期範圍（適合事後追查）

–range 參數其實非常有彈性，可以自訂查詢區間，就像跟超商店長說「請幫我調某年某月某日到某日的監視器畫面」：

🔎 用中文版案例實際跑一次：解析 SSH 日誌

以下是一個相當完整的實戰範例，示範如何解析前一天的 SSH 服務日誌，並把結果以純文字格式存成檔案：

如果想要換成 HTML 格式（方便直接用瀏覽器開啟、排版更美觀），只要把上面指令裡的 –format text 改成 –format html 即可，其餘完全不用動。

🌐 解析網站伺服器日誌

同樣的邏輯，也可以用來解析 Apache 或 Nginx 網站伺服器的日誌：

🔥 一句話總結： 只要記得「–range 決定看哪一天、–service 決定看哪個服務、–output 決定送到哪裡、–format 決定長什麼樣子」這四個參數的邏輯，你就已經掌握了 Logwatch 手動操作的 80% 精華。

⏰ 方法二：交給 Cron 排程，每天自動幫你巡邏

手動執行固然方便查詢，但 Logwatch 真正的威力，在於「設定一次、之後每天自動幫你巡邏並寄報表」。這就要借助 Linux 系統內建的排程小幫手——Cron（可以把它想成是伺服器裡的鬧鐘 App，時間一到就自動執行你設定好的任務）。

💡 小知識： 事實上，Ubuntu 安裝 Logwatch 之後，系統通常會自動幫你建立一個預設的每日排程檔案，路徑在 /etc/cron.daily/00logwatch，可以先檢查看看它的內容：

這個預設腳本的內容通常長得像這樣：

如果想要更彈性的時間控制（例如指定幾點幾分執行），可以自行編輯 crontab 排程表：

加入以下這一行，代表每天凌晨 00:30 自動執行 Logwatch（時間點很重要——通常會選在午夜日誌輪替之後、天還沒亮的離峰時段，避免佔用系統白天的效能）：

如果想要更豐富的排程組合，也可以參考以下範例，同時安排「每日、每週、每小時、每月」不同頻率的報表：

更詳細的排程語法用法，可以另外參考 Cron 排程的專門教學文章。

---

🧩 進階客製化篇：讓 Logwatch 認識你自己的 App

Logwatch 內建的服務清單已經涵蓋了絕大多數常見的系統服務（SSH、Apache、Postfix、MySQL⋯⋯），但如果你自己開發或架設了一套冷門的應用程式（例如一套自製的 Node.js 服務），Logwatch 當然不會天生就認識它的日誌格式。好消息是，Logwatch 從設計之初就考慮到了這種擴充需求，允許使用者自訂日誌檔群組（Log File Group）與服務解析腳本，就像教一位新來的巡邏員「這棟大樓的特殊規矩」一樣。

📁 認識三層設定檔架構

在深入客製化之前，理解 Logwatch 的組態檔架構會很有幫助。它主要由三個目錄組成，執行時會依照優先順序尋找設定：

換句話說，Logwatch 執行時會先看 /etc/logwatch/ 有沒有相關設定，沒有的話再往下找 dist.conf，最後才會退回使用 default.conf 裡的內容。這也是為什麼前面章節反覆強調「請把設定複製到 /etc/logwatch/ 底下再修改」的原因——這樣才會真正生效，也才不會被套件更新洗掉。

①️⃣ 建立自訂日誌檔群組（LogFile Group）

日誌檔群組定義了「Logwatch 該去哪裡找日誌檔案」。原廠的定義檔放在 /usr/share/logwatch/default.conf/logfiles/，若要自訂，新增到 /etc/logwatch/conf/logfiles/ 即可：

設定檔內容範例如下，每一行都有詳細的中文註解說明用途：

如果你的應用程式日誌來源不只一個檔案，也可以在同一個群組裡合併定義多個來源，就像把「同一間店的收銀機日誌＋監視器日誌」合併成一份報表：

②️⃣ 建立自訂服務定義與 Perl 解析腳本

光是告訴 Logwatch「日誌檔在哪裡」還不夠，還需要一支解析腳本來告訴它「這些日誌內容該怎麼被讀懂、整理成摘要」。這支腳本通常是用 Perl 語言撰寫（因為 Logwatch 本身就是 Perl 寫成的），概念上很像餐廳的「驗貨員」：把一堆原始食材（日誌原始行）送進來，驗貨員依照規則分類、計數，最後端出一份清楚的驗收清單。

首先建立服務定義檔：

接著，建立真正負責解析內容的 Perl 腳本：

以下是一個完整可運作的 Perl 客製化服務腳本範例，會統計日誌中出現的錯誤（ERROR）與警告（WARNING）訊息，並依照出現次數排序輸出：

寫好之後，記得賦予腳本「可執行」權限，否則 Logwatch 會因為沒有執行權限而跳過它：

💡 白話文解說： 這整套客製化流程可以理解成三層分工——logfiles 設定檔負責「告訴 Logwatch 食材（日誌）放在哪個倉庫」，services 設定檔負責「幫這道菜取名字、決定要用哪個倉庫的食材」，而 Perl 解析腳本則是真正的「主廚」，負責把食材（原始日誌行）加工成一道可以端上桌的菜（摘要報表）。三者環環相扣，缺一不可。

---

🖨️ 輸出格式篇：純文字 vs. HTML，各有各的舞台

Logwatch 支援兩種輸出格式：純文字（text）與HTML。兩者就像同一份新聞稿的「純文字簡訊版」跟「圖文並茂的網頁版」，適合的使用情境不太一樣。

📝 純文字輸出：終端機與長期歸檔的好夥伴

🎨 HTML 輸出：寄信與網頁瀏覽的最佳選擇

如果想把 HTML 設為預設格式，讓每次執行都自動套用，可以直接寫進設定檔裡：

🗂️ 進階實戰：打造一個自動彙整的 HTML 報表網頁

對於喜歡把所有紀錄都留存下來、甚至想架一個內部網頁供團隊查閱的管理者，這裡提供一個更完整的自動化腳本範例，會每天自動產生 HTML 報表、建立索引頁面，並自動清除超過 30 天的舊報表，就像超商定期清理過期的監視器錄影檔案一樣：

🚨 安全性提醒： 如果採用這種方式把報表放到 /var/www/html/ 網頁目錄下，等於任何知道網址的人都有可能看到你的伺服器日誌摘要（裡面可能包含 IP 位址、登入失敗紀錄、系統路徑等敏感資訊）。務必記得在網頁伺服器（Apache／Nginx）上額外加上帳號密碼保護或 IP 白名單限制，不要讓這個目錄對外公開裸奔。

---

🚑 疑難排解篇：常見地雷與急救 SOP

就算是設定得再仔細，實際上線後難免會遇到「怎麼跟我想的不一樣」的狀況。以下整理幾個最常見的踩雷情境與對應排查方式，就像常備藥箱一樣，遇到狀況先照著步驟走一遍。

❓ 狀況一：Logwatch 完全沒有輸出，或報表是空的

❓ 狀況二：設定了寄信，但一直收不到報表

💡 小提醒： 若你的主機供應商（VPS）預設封鎖了郵件連接埠，可能還需要另外開放對外的 25 埠（SMTP 通訊埠），例如：

❓ 狀況三：自訂的服務沒有出現在報表裡

❓ 狀況四：執行時出現權限錯誤

❓ 狀況五：報表太長、雜訊太多，看得很痛苦

🔬 萬用偵錯模式：Debug Mode

當上述方法都無法定位問題時，可以祭出最強力的偵錯模式，就像把監視器畫面切換成「逐格慢動作播放」：

🔍 檢查目前生效的設定內容

---

📋 速查表：Ubuntu 系統上常見的服務代稱

在使用 –service 參數篩選特定服務時，經常需要用到「服務代稱」。以下整理 Ubuntu 系統上最常見的服務名稱對照，方便直接複製貼上使用：

---

🎭 對號入座：你適合怎麼用 Logwatch？

Logwatch 雖然安裝簡單，但不同身分的使用者，真正在意的重點其實不太一樣。以下用幾種常見情境，幫助你快速找到最適合自己的操作組合：

1. ㊀ 個人小型網站站長（例如經營部落格的你）
   你可能只租了一台入門等級的 VPS，平常沒空天天緊盯後台。建議直接採用「每日一封信」的懶人設定——Range = Yesterday、Detail = Med、Output = mail，搭配前面教的 Cron 排程，每天早上起床滑手機時，信箱裡自然會躺著一份摘要，就像訂閱了一份「伺服器日報」。
2. ㊁ 中小企業 IT 管理者（要顧好幾台主機）
   建議善用多頻率排程組合：每日摘要抓大方向、每週彙整做趨勢觀察、針對 SSH 登入這種高風險項目再加開每小時的高詳細度監控，形成多層次的巡邏網。同時強烈建議把 MailTo 設成部門的共用信箱或發送清單，而不是單一個人信箱，避免「唯一知道密碼的人請假時，沒人看得到警訊」的窘境。
3. ㊂ 正在學 Linux 的資訊系學生／自學者
   Logwatch 其實是認識「Syslog 標準」與「Perl 文字處理」的絕佳教材。建議先動手玩自訂服務腳本那個章節，把範例 Perl 腳本改一改，套用到自己模擬的日誌檔案上，實際體會「原始日誌 → 結構化摘要」的轉換過程，會比死背指令更有感。
4. ㊃ 誤把 Logwatch 當成即時防禦系統的人（常見誤解）
   這點務必說清楚：Logwatch 是「事後總結」，不是「當下攔截」。如果駭客正在對你的伺服器發動暴力破解攻擊，Logwatch 最快也要等到隔天的報表才會告訴你「昨天有人狂敲你家大門」，等看到信的時候，攻擊早就結束了。真正需要即時阻擋的防護，還是得搭配 fail2ban 這類即時封鎖工具，或前面提過的 Nagios、Zabbix 等即時監控系統，Logwatch 扮演的是「事後複盤」的角色，而非「當下守門員」。

🚨 畫重點！千萬別踩雷： 千萬不要因為裝了 Logwatch，就誤以為伺服器已經「有在防護」了。Logwatch 只負責看紀錄、寫報告，完全不會主動採取任何攔截或封鎖動作。真正的第一道防線，仍然是基本功——強密碼、SSH 金鑰登入、防火牆規則、系統定期更新，Logwatch 只是幫你在做完這些基本功之後，多一雙「回頭檢查昨天有沒有異常」的眼睛。

---

📊 三種輸出模式效能與適用性比較表

---

🏁 總結：把「監視器錄影帶」變成「每日晨報」

回到文章最開頭的比喻：你的伺服器每天都在默默寫日記，只是這本日記寫得又長又雜，沒有工具輔助的話，幾乎沒有人有耐心天天翻閱。Logwatch 的價值，就在於它用最輕量、幾乎零成本的方式，把這些原始又枯燥的紀錄，轉換成一份你真的會想打開來看的每日摘要。

總結今天學到的重點：

• Logwatch 是「每日總結型」的日誌分析工具，不是即時警報系統，兩者互補而非取代。
• 安裝方式因發行版而異，但整體都是一到兩行指令就能完成的簡單任務。
• 設定檔務必複製到 /etc/logwatch/ 底下再修改，避免套件更新時被洗掉。
• 記住四大核心參數口訣：–range 決定看哪天、–service 決定看哪個服務、–output 決定送到哪、–format 決定長怎樣。
• 搭配 Cron 排程，可以完全自動化，每天定時把報表寄到信箱，養成每日檢查的好習慣。
• 進階玩家可以透過自訂 Perl 服務腳本，讓 Logwatch 認識自己的冷門應用程式。
• 千萬別忘記：Logwatch 只是「回頭看紀錄」的工具，強密碼、SSH 金鑰、防火牆這些基本防護功夫，一樣都不能少。

🔥 一句話總結懶人包： 如果你到現在都還沒替自己的伺服器裝上 Logwatch，不妨花個十分鐘動手試試看——這絕對是投資報酬率最高的維運習慣之一，讓你從「出事才驚慌查日誌」，進化成「每天早餐配一份系統晨報，安心掌握伺服器狀態」。