- 逆向行駛 - https://520.be/ -

Logwatch – 記錄檔分析軟體

內容目錄

🕵️‍♂️ 你的伺服器每天都在寫日記,只是你從來沒打開來看: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 Server Log File Analysis [49]

🍱 Logwatch 到底能幫你看什麼?

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

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

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

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

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

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

📌 欄位 說明
日期與時間 事件發生的當下時刻,就像報案單上的「案發時間」。
主機名稱 發生事件的那台伺服器叫什麼名字,等同於「案發地點(哪間分局轄區)」。
常駐程式名稱 是哪個系統程式(例如 systemd)記錄了這起事件,類似「承辦單位」。
詳細內容 事件的具體描述,也就是報案單上「案情摘要」的部分。

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

Facility(事件種類) 說明
LOG_AUTH 與系統認證相關的事件,例如 SSH 登入狀況,等於「門禁刷卡紀錄」。
LOG_CRON 例行性程式的執行情況(例如 cron、at 指令排程),像是「定時灑水系統啟動紀錄」。
LOG_DAEMON 系統上常駐程式的運作資訊,多半是網路服務的運作情形。
LOG_FTP 系統上 FTP 服務運作的相關資訊。
LOG_KERN 系統核心(Kernel)運作的相關資訊,等於「大樓中控系統的核心日誌」。
LOG_MAIL 系統上電子郵件服務運作的相關資訊。
Level(嚴重程度) 說明
LOG_INFO 最輕微的程度,通常是不影響系統或程式運作的基本資訊說明,像是「有人路過門口」的普通紀錄。
LOG_NOTICE 尚不會影響系統或程式運作,但可能有管理者需要留意的資訊,等於「巡邏員覺得有點奇怪,記一筆」。
LOG_WARNING 尚不致於影響系統整體運作,但可能會影響常駐程式的運作,類似「設備出現異音,先記錄觀察」。

在預設情況下,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 機的每一筆交易明細,格式大致如下:

📄 CLF 格式結構
Host ident authuser date RequestLine status bytes
欄位 說明(超商比喻版)
Host 使用者端的 IP 或主機名稱,等同「哪位客人刷了卡」。
Ident 通常不會使用,若有啟用身分辨識服務(如 ident)才會記錄回報的身分資訊。
Authuser 相關認證的使用者名稱,例如網站有設定基礎 HTTP 認證時會記錄使用者名稱,像「會員卡號」。
Date 使用者端發起請求的日期與時間,也就是「客人進門刷卡的時刻」。
RequestLine 使用者端所發出請求的第一行資訊,格式為「method Request-URI HTTP-Version」。method 是存取方法(如 POST、GET),Request-URI 是要存取的網路資源(例如某個網頁),HTTP-Version 是連線時使用的通訊協定版本。等同「客人買了什麼商品、用了哪種結帳方式」。
Status 網站伺服器回覆給使用者端的處理狀態碼(例如 404 代表找不到網頁),類似「結帳有沒有成功、有沒有跳出異常訊息」。
Bytes 回覆給客戶端內容的大小(單位為位元組),等於「這筆交易的商品重量/份量」。

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

Apache Nginx Web Server Log Format [50]


🟩 🟩 🟩

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

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

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

① 🌀 Debian/ Ubuntu 🟠 系統

Debian/ Ubuntu 系統是目前最多人拿來架站、租 VPS(虛擬主機,就像跟房東租一間毛坯屋,自己裝潢)的發行版,安裝流程最簡單:

🖥️ 步驟一:更新系統套件清單
# 更新套件索引,並升級已安裝的軟體版本
sudo apt update && sudo apt upgrade
🖥️ 步驟二:安裝 Logwatch 與寄信用的 Sendmail
sudo apt install logwatch sendmail

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

🖥️ 替代方案:搭配 Postfix
# 安裝 Logwatch,並加裝日期解析套件與 Postfix 郵件伺服器
sudo apt update
sudo apt install logwatch libdate-manip-perl -y
sudo apt install postfix mailutils -y

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

🖥️ 確認安裝版本
# 確認 Logwatch 是否安裝成功並顯示版本資訊
logwatch --version

② Debian 系統

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

🖥️ 更新並安裝
# 更新系統
sudo apt update && sudo apt upgrade

# 安裝 Logwatch 與 Sendmail(含 binary 套件)
sudo apt install logwatch sendmail-bin sendmail

③ CentOS Stream/AlmaLinux/Rocky Linux/Fedora(RHEL 家族)

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

🖥️ 更新並安裝
# 更新系統套件
sudo dnf update

# 安裝 Logwatch 與 Sendmail
sudo dnf install logwatch sendmail

# 啟動 Sendmail 服務
sudo systemctl start sendmail

④ CentOS 7(舊版,使用 yum)

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

🖥️ 更新並安裝
# 更新系統套件
sudo yum update

# 安裝 Logwatch 與 Sendmail
sudo yum install logwatch sendmail

# 啟動 Sendmail 服務
sudo systemctl start sendmail

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

🖥️ CentOS 8 Stream 極簡安裝
yum install logwatch

⑤ Arch Linux(進階玩家專屬)

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

🖥️ 步驟一:更新系統
pacman -Syu
🖥️ 步驟二:安裝 Logwatch 與 Postfix
pacman -S logwatch postfix

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

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

📄 File: /etc/postfix/main.cf
# 請將 hostname.example.com 換成你自己的主機名稱與網域
myhostname = hostname.example.com
inet_interfaces = loopback-only

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

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

📄 File: /etc/postfix/aliases
# 請將 hostname.example.com 換成你自己的主機名稱與網域
root:           root@hostname.example.com

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

🖥️ 套用設定並啟動服務
# 更新別名資料庫,讓剛才的設定生效
newaliases

# 啟動 postfix 郵件服務
systemctl start postfix

Linux Server Terminal Postfix Setup [51]


🟨 🟨 🟨

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

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

Logwatch 的主要設定檔位於:

📁 預設設定檔位置
/usr/share/logwatch/default.conf/logwatch.conf

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

🖥️ 建立本地端專屬設定(推薦做法)
# 建立本地端設定目錄(若尚未存在)
sudo mkdir -p /etc/logwatch/conf

# 把預設設定複製一份到本地端目錄,之後只改這一份
sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf
🖥️ 開啟設定檔進行編輯
# 使用 nano 文字編輯器開啟設定檔
sudo nano /etc/logwatch/conf/logwatch.conf

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

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

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

1️⃣ 報表要寄給誰(MailTo)

📄 File: logwatch.conf
MailTo = root

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

✏️ 範例
MailTo = sysadmin@mydomain.com

2️⃣ 報表是誰寄出的(MailFrom)

📄 File: logwatch.conf
MailFrom = Logwatch

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

✏️ 範例
MailFrom = sysadmin@mydomain.com

3️⃣ 要分析哪個時間範圍(Range)

📄 File: logwatch.conf
Range = yesterday

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

選項 說明
All 從有紀錄以來的全部日誌,通常只在第一次手動測試時才會這樣用,日常不建議。
Today 只看今天的紀錄。
Yesterday 只看昨天的紀錄,這是最常見的每日排程設定,因為通常是清晨排程執行,昨天的資料才是完整的一整天。

4️⃣ 報表要多詳細(Detail)

📄 File: logwatch.conf
Detail = Low

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

等級 對應數字 說明
Low 0 只顯示重大錯誤與安全事件,雜訊最少,適合只想知道「有沒有出大事」的忙碌主管。
Med 5 重要事件加上一般警告,是最推薦的日常監控等級,資訊量與可讀性最平衡。
High 10 包含所有訊息,連一般資訊性內容都不放過,適合深度追查特定問題時使用,但日常訂閱容易變成資訊轟炸。

5️⃣ 要監控哪些服務(Service)

📄 File: logwatch.conf
Service = All

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

✏️ 範例:只監控特定服務
Service = sendmail
Service = http
Service = identd
Service = sshd2
Service = sudo

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

6️⃣ 要不要停用每日自動報表(DailyReport)

📄 File: logwatch.conf
# DailyReport = No

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

✏️ 範例:停用自動每日報表
DailyReport = No

📂 進階:把其他資料夾也納入巡邏範圍(LogDir)

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

📄 File: logwatch.conf
LogDir = /var/log
LogDir = /var/www/example.com/logs

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

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

模式 說明
stdout 直接印在螢幕上(終端機主控台),這是預設值,適合手動測試,但不會保存也不會通知任何人。
mail 電子郵件寄送,需要同時設定好 MailTo 與 MailFrom,也是最推薦的日常自動化用法。
file 檔案形式儲存,需要同時設定 Filename 指定儲存路徑,適合想自己保留歷史備份的人。

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

Logwatch Output Format Configuration [52]


🟪 🟪 🟪

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

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

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

🖥️ 基本手動執行
# 產生一份「昨天」的日誌摘要報表,直接印出到終端機
sudo logwatch

官方文件列出的完整參數如下(不熟悉沒關係,接下來會逐一說明常用的部分):

📄 Logwatch 完整參數列表
logwatch  [--detail  level  ] [--logfile log-file-group ] [--service service-name ] [--print]
   [--mailto address ] [--archives] [--range range  ]  [--debug  level  ]  [--save  file-name  ]
   [--logdir  directory ] [--hostname hostname ] [--splithosts] [--multiemail] [--output output-
   type ] [--numeric] [--no-oldfiles-log] [--version] [--help|--usage]

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

參數 說明
–detail <等級> 可設 Low、Med、High,或 0~10 之間的數字,控制報表詳細程度。
–range <範圍> 可設 Today、Yesterday,或自訂範圍如 “Between 1/1/2026 and 1/15/2026″。
–service <服務名稱> 只分析特定服務,例如 sshd、postfix。
–output <類型> 可設 stdout、mail、file 三種輸出方式。
–format <格式> 可設 text(純文字)或 html(HTML 格式)。
–mailto <信箱> 指定報表要寄送到哪個電子郵件地址。
–logdir <路徑> 覆蓋預設的日誌目錄位置。
–archives 連同已經被輪替、壓縮封存的舊日誌檔也一併納入分析。
✏️ 綜合範例:指定 detail、收件人、服務、範圍
logwatch --detail Low --mailto email@address --service http --range today

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

🖥️ Low:只看重大事件,最精簡
# 低詳細度:只有關鍵事件,雜訊最少
# 最適合忙碌主管,或只想知道「有沒有出大事」的情境
sudo logwatch --detail Low --range Yesterday --output stdout
🖥️ Med:日常維運的甜蜜點
# 中等詳細度:重要事件的平衡視角
# 推薦用於每日的日常維運檢視
sudo logwatch --detail Med --range Yesterday --output stdout
🖥️ High:深度追查專用
# 高詳細度:完整資訊,適合深入調查
# 在排查特定問題時使用
sudo logwatch --detail High --range Yesterday --output stdout
🖥️ 用數字微調詳細程度
# 使用數字進行更精細的詳細度控制
# 等級 5 大約等同於 Med
sudo logwatch --detail 5 --range Yesterday --output stdout

📅 指定特定日期範圍(適合事後追查)

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

🖥️ 分析過去 7 天(適合每週安全巡查)
# 分析過去 7 天的日誌
# 適合每週例行的安全性回顧
sudo logwatch --detail Med --range "between -7 days and -1 days"
🖥️ 分析指定日期區間
# 分析特定日期範圍
# 格式:"Between MM/DD/YYYY and MM/DD/YYYY"
sudo logwatch --detail High --range "Between 1/1/2026 and 1/10/2026"
🖥️ 只看今天,高詳細度
# 以最高詳細度分析今天的日誌
sudo logwatch --detail 10 --range Today

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

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

🖥️ 解析前一天的 SSH 服務日誌並存成文字檔
# 解析前一天的 ssh 服務日誌
# 並將解析過後的資料,以文字型式儲存在 /tmp/logwatch 檔案上
logwatch --logdir /var/log --range Yesterday --output file --format text --service sshd --filename /tmp/logwatch

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

🌐 解析網站伺服器日誌

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

🖥️ 解析前一日的網站伺服器日誌
logwatch --logdir [網站日誌所在目錄] --range Yesterday --output file --format text --service http --filename /tmp/logwatch

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

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

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

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

🖥️ 查看預設的每日排程腳本
cat /etc/cron.daily/00logwatch

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

📄 /etc/cron.daily/00logwatch(預設內容範例)
#!/bin/bash
# /etc/cron.daily/00logwatch
# 每日 Logwatch 報表腳本

# 檢查 logwatch 是否已安裝
test -x /usr/sbin/logwatch || exit 0

# 依照設定檔內的預設值執行 logwatch
# 設定檔中的 --output mail 會觸發電子郵件寄送
/usr/sbin/logwatch --output mail

如果想要更彈性的時間控制(例如指定幾點幾分執行),可以自行編輯 crontab 排程表:

🖥️ 開啟排程編輯器
crontab -e

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

📄 File: /etc/crontab
30 0  * * *          /usr/sbin/logwatch

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

🖥️ 多頻率排程組合範例
# 每日報表:早上 6:00 執行,涵蓋昨天的日誌
# 排在午夜日誌輪替之後執行,確保資料完整
0 6 * * * /usr/sbin/logwatch --output mail --mailto admin@example.com --detail Med --range Yesterday

# 每週摘要:每週一早上 7:00,涵蓋過去 7 天
# 提供更宏觀的系統活動視角
0 7 * * 1 /usr/sbin/logwatch --output mail --mailto admin@example.com --detail High --range "between -7 days and -1 days"

# 每小時 SSH 安全檢查:高詳細度,異常時寄信通知
# 有助於快速察覺暴力破解攻擊
0 * * * * /usr/sbin/logwatch --service sshd --output mail --mailto admin@example.com --detail High --range "between -1 hours and now"

# 每月報表:每月 1 號早上 8:00,涵蓋過去 30 天
0 8 1 * * /usr/sbin/logwatch --output mail --mailto admin@example.com --detail High --range "between -30 days and -1 days"

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

Automated Cron Scheduling [53]


🟦 🟦 🟦

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

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

📁 認識三層設定檔架構

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

目錄 用途
/etc/logwatch/ 使用者自訂設定目錄,優先權最高,會最先被讀取。
/usr/share/logwatch/dist.conf/ 發行版(distribution)層級的設定,優先權次之。
/usr/share/logwatch/default.conf/ 原廠預設設定,優先權最低,通常只有這裡才會實際存放預設組態檔。

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

①️⃣ 建立自訂日誌檔群組(LogFile Group)

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

🖥️ 建立自訂應用程式的日誌群組設定
# 建立一個 Node.js 應用程式的自訂日誌檔群組
# 這會告訴 Logwatch 去哪裡找日誌
sudo mkdir -p /etc/logwatch/conf/logfiles
sudo nano /etc/logwatch/conf/logfiles/myapp.conf

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

📄 File: /etc/logwatch/conf/logfiles/myapp.conf
# /etc/logwatch/conf/logfiles/myapp.conf
# 定義自訂應用程式的日誌檔位置

# 報表中顯示的標題名稱
Title = "My Node.js Application"

# 主要日誌檔位置,支援萬用字元比對多個檔案
LogFile = /var/log/myapp/*.log

# 啟用 --archives 時,也一併納入已壓縮的舊日誌
# 這裡設定的是 gzip 壓縮格式的封存日誌樣式
Archive = /var/log/myapp/*.log.*.gz

# 另一種常見的封存日誌命名規則(數字結尾,未壓縮)
Archive = /var/log/myapp/*.log.[0-9]

# 展開日誌檔名中的日期代碼
# 適用於檔名內含日期的日誌,例如 myapp-2026-01-15.log
# *ExpandRepeats

# 依照 --range 參數篩選出對應時間範圍的日誌行
# 這行範例對應的日誌格式類似:
# [2026-01-15 10:30:00] ERROR: Database connection failed
*ApplyStdDate = "\[%Y-%m-%d %H:%M:%S\] "

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

📄 File: /etc/logwatch/conf/logfiles/webapp.conf
# /etc/logwatch/conf/logfiles/webapp.conf
# 把多個日誌來源合併成一個邏輯群組

Title = "Web Application Stack"

# 納入 Nginx 存取日誌
LogFile = /var/log/nginx/access.log

# 納入 Nginx 錯誤日誌
LogFile = /var/log/nginx/error.log

# 納入應用程式自身的日誌
LogFile = /var/log/webapp/application.log

# 同時納入這三種日誌各自的封存版本
Archive = /var/log/nginx/access.log.*.gz
Archive = /var/log/nginx/error.log.*.gz
Archive = /var/log/webapp/application.log.*.gz

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

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

首先建立服務定義檔:

🖥️ 建立服務設定目錄與定義檔
# 建立服務設定目錄
sudo mkdir -p /etc/logwatch/conf/services

# 建立服務定義檔
sudo nano /etc/logwatch/conf/services/myapp.conf
📄 File: /etc/logwatch/conf/services/myapp.conf
# /etc/logwatch/conf/services/myapp.conf
# 自訂應用程式的服務定義

# 在 Logwatch 報表中顯示的標題
Title = "My Application"

# 要分析的日誌檔群組(對應前面 logfiles/myapp.conf 裡定義的名稱)
LogFile = myapp

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

🖥️ 建立解析腳本目錄與檔案
# 建立腳本目錄
sudo mkdir -p /etc/logwatch/scripts/services

# 建立服務解析腳本
sudo nano /etc/logwatch/scripts/services/myapp

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

📄 File: /etc/logwatch/scripts/services/myapp(Perl 語言)
#!/usr/bin/perl
# /etc/logwatch/scripts/services/myapp
# 自訂 Logwatch 服務腳本,用來解析應用程式日誌

# 這支腳本會從標準輸入(STDIN)讀取日誌行,並產出摘要報表
# Logwatch 會先依照 logfiles 設定篩選出相關行,再傳給這支腳本

use strict;
use warnings;

# 初始化計數器,分別記錄不同種類的事件
my %errors;          # 用雜湊表統計各種錯誤訊息出現的次數
my %warnings;        # 用雜湊表統計各種警告訊息出現的次數
my $total_lines = 0; # 總共處理了多少行日誌
my $error_count = 0; # 錯誤訊息總數
my $warning_count = 0; # 警告訊息總數

# 從環境變數取得 Logwatch 目前設定的詳細等級(0-10)
my $detail = $ENV{'LOGWATCH_DETAIL_LEVEL'} || 5;

# 逐行讀取 Logwatch 傳進來的日誌內容
while (defined(my $line = <STDIN>)) {
    chomp($line);
    $total_lines++;

    # 擷取錯誤訊息,正規表示式可依實際日誌格式調整
    # 範例格式:[2026-01-15 10:30:00] ERROR: Database connection failed
    if ($line =~ /ERROR[:\s]+(.+)/i) {
        my $error_msg = $1;
        $errors{$error_msg}++;
        $error_count++;
    }

    # 擷取警告訊息
    # 範例格式:[2026-01-15 10:30:00] WARNING: High memory usage detected
    if ($line =~ /WARNING[:\s]+(.+)/i) {
        my $warning_msg = $1;
        $warnings{$warning_msg}++;
        $warning_count++;
    }
}

# 輸出摘要報表
# 這裡印出的內容,就是最終會出現在 Logwatch 報表裡的樣子

if ($total_lines > 0) {
    print "\n";
    print "  已處理日誌總行數:$total_lines\n";
    print "\n";

    # 錯誤訊息一律顯示(不受詳細等級影響)
    if ($error_count > 0) {
        print "  ========== 錯誤事件(共 $error_count 筆) ==========\n";
        foreach my $msg (sort { $errors{$b} <=> $errors{$a} } keys %errors) {
            print "    出現 $errors{$msg} 次:$msg\n";
        }
        print "\n";
    }

    # 警告訊息只在詳細等級達到中等(5)以上才顯示
    if ($warning_count > 0 && $detail >= 5) {
        print "  ========== 警告事件(共 $warning_count 筆) ==========\n";
        foreach my $msg (sort { $warnings{$b} <=> $warnings{$a} } keys %warnings) {
            print "    出現 $warnings{$msg} 次:$msg\n";
        }
        print "\n";
    }

    # 若完全沒有錯誤或警告,顯示安心訊息
    if ($error_count == 0 && $warning_count == 0) {
        print "  未偵測到任何錯誤或警告。\n";
    }
}

exit 0;

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

🖥️ 賦予執行權限並測試
# 讓腳本具有可執行權限
sudo chmod +x /etc/logwatch/scripts/services/myapp

# 針對這個自訂服務單獨測試執行結果
sudo logwatch --service myapp --detail High --range Today

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

Logwatch Custom Parsing Script [54]


🟫 🟫 🟫

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

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

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

🖥️ 產生純文字報表並印出
# 產生純文字格式報表,輸出到終端機
sudo logwatch --format text --detail Med --range Yesterday
🖥️ 依日期存檔,方便長期歸檔查詢
# 建立存放報表的目錄
sudo mkdir -p /var/log/logwatch

# 將純文字報表依照日期存檔,方便日後查閱歷史紀錄
sudo logwatch --format text --output file --filename /var/log/logwatch/report-$(date +%Y-%m-%d).txt

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

🖥️ 產生 HTML 報表並存成檔案
# 產生 HTML 格式報表並存成檔案
sudo logwatch --format html --output file --filename /tmp/logwatch-report.html
🖥️ 以 HTML 格式透過郵件寄送
# 以 HTML 格式透過電子郵件寄送報表
sudo logwatch --format html --output mail --mailto admin@example.com

# 若在有圖形介面的桌面系統上,也可以直接用瀏覽器打開來看
# xdg-open /tmp/logwatch-report.html

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

📄 File: /etc/logwatch/conf/logwatch.conf
# 所有報表皆使用 HTML 格式輸出
Format = html

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

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

📄 File: /etc/cron.daily/logwatch-html-archive
#!/bin/bash
# /etc/cron.daily/logwatch-html-archive
# 產生並封存 HTML 格式的 Logwatch 報表

# 基本設定
REPORT_DIR="/var/www/html/logwatch"
DAYS_TO_KEEP=30

# 若報表目錄不存在則建立
mkdir -p "$REPORT_DIR"

# 產生「今天執行、內容為昨天日誌」的報表
REPORT_DATE=$(date -d "yesterday" +%Y-%m-%d)
REPORT_FILE="$REPORT_DIR/logwatch-$REPORT_DATE.html"

/usr/sbin/logwatch \
    --format html \
    --output file \
    --filename "$REPORT_FILE" \
    --detail High \
    --range Yesterday \
    --archives

# 建立一個指向最新報表的捷徑連結
ln -sf "$REPORT_FILE" "$REPORT_DIR/latest.html"

# 產生列出所有歷史報表的索引頁面
cat > "$REPORT_DIR/index.html" << 'HTMLEOF'
<!DOCTYPE html>
<html>
<head><title>Logwatch Reports</title></head>
<body>
<h1>Logwatch Reports</h1>
<ul>
HTMLEOF

# 依時間反序列出所有報表連結
for report in $(ls -r "$REPORT_DIR"/logwatch-*.html 2>/dev/null); do
    filename=$(basename "$report")
    echo "<li><a href=\"$filename\">$filename</a></li>" >> "$REPORT_DIR/index.html"
done

cat >> "$REPORT_DIR/index.html" << 'HTMLEOF'
</ul>
</body>
</html>
HTMLEOF

# 清除超過保留天數的舊報表,避免硬碟被塞爆
find "$REPORT_DIR" -name "logwatch-*.html" -mtime +$DAYS_TO_KEEP -delete

logger "Logwatch HTML report archived: $REPORT_FILE"

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

Logwatch HTML Report Web Interface [55]


🔷 🔷 🔷

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

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

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

🖥️ 排查步驟
# 確認日誌檔案確實存在且有內容
ls -la /var/log/syslog /var/log/auth.log

# 用偵錯模式檢查 Logwatch 能否正常讀取日誌
sudo logwatch --debug High --range Today 2>&1 | head -100

# 確認指定的時間範圍內是否真的有日誌資料
sudo logwatch --range "Between 1/10/2026 and 1/15/2026" --detail High

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

🖥️ 排查步驟
# 先測試最基本的郵件寄送功能是否正常
echo "Test" | mail -s "Test" admin@example.com

# 檢查郵件佇列,看看是否有卡住沒送出的信件
mailq

# 查看郵件系統的日誌,找出寄送失敗的原因
sudo tail -50 /var/log/mail.log

# 確認 Postfix 郵件服務是否正常運作中
sudo systemctl status postfix

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

🖥️ 開放對外 25 埠(視主機商防火牆規則而定)
sudo iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT

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

🖥️ 排查步驟
# 確認自訂日誌檔群組設定內容是否正確
cat /etc/logwatch/conf/logfiles/myapp.conf

# 確認對應的日誌檔案確實存在且有內容
ls -la /var/log/myapp/

# 直接手動測試解析腳本,確認腳本本身邏輯正確
cat /var/log/myapp/application.log | /etc/logwatch/scripts/services/myapp

# 以偵錯模式單獨執行該自訂服務
sudo logwatch --service myapp --debug High 2>&1 | less

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

🖥️ 排查步驟
# Logwatch 需要 root 權限才能讀取系統日誌
# 務必搭配 sudo 執行以取得完整存取權限
sudo logwatch --detail High --range Yesterday

# 檢查日誌檔案本身的權限設定
ls -la /var/log/*.log

# 確認 Logwatch 各服務腳本的執行權限是否正常
ls -la /usr/share/logwatch/scripts/services/

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

🖥️ 解決方式
# 方法一:降低詳細等級,減少不必要的資訊
sudo logwatch --detail Low --range Yesterday

# 方法二:排除特定「吵鬧」的服務(例如磁碟空間檢查)
sudo logwatch --service All --service "-zz-disk_space" --service "-http"

# 方法三:寫進設定檔,永久排除特定服務
echo "Service = -zz-disk_space" | sudo tee -a /etc/logwatch/conf/logwatch.conf

🔬 萬用偵錯模式:Debug Mode

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

🖥️ 偵錯模式綜合範例
# 以最高偵錯層級執行,輸出所有內部運作細節
# 偵錯等級可選:Low、Med、High
sudo logwatch --debug High --range Today 2>&1 | less

# 針對特定服務進行偵錯(例如只想深挖 sshd 的解析過程)
sudo logwatch --debug High --service sshd --range Today 2>&1 | less

# 將偵錯輸出完整存檔,方便日後分析或提供技術支援參考
sudo logwatch --debug High --range Yesterday > /tmp/logwatch-debug.txt 2>&1

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

🖥️ 確認設定是否正確被讀取
# 顯示目前實際生效的設定內容
sudo logwatch --debug Med 2>&1 | grep -i "config"

# 列出目前可用的日誌檔群組清單
ls /usr/share/logwatch/default.conf/logfiles/
ls /etc/logwatch/conf/logfiles/ 2>/dev/null

# 列出目前可用的服務清單
ls /usr/share/logwatch/scripts/services/
ls /etc/logwatch/scripts/services/ 2>/dev/null

🟩 🟩 🟩

📋 速查表:🌀 Debian/ Ubuntu 🟠 系統上常見的服務代稱

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

服務代稱 白話說明
sshd SSH 遠端登入認證,等於大門刷卡紀錄,是資安監控的重點對象。
pam_unix PAM 認證機制(sudo、login 等),類似內部各扇門的身分驗證紀錄
postfix 郵件伺服器,記錄信件收發狀況。
http Apache/Nginx 網站伺服器,記錄網站的訪客與錯誤紀錄。
kernel 系統核心訊息,屬於最底層的系統運作紀錄。
cron 排程任務執行紀錄,也就是「鬧鐘 App 有沒有準時響鈴」的紀錄。
dpkg 套件管理紀錄,記錄軟體的安裝/移除/更新狀況。
iptables 防火牆規則紀錄,等於保全系統的攔截紀錄
fail2ban 入侵防禦系統紀錄,記錄自動封鎖可疑 IP 的行為,像保全主動趕人的紀錄
systemd Systemd 系統日誌,涵蓋各種服務的啟動與停止事件。

🟧 🟧 🟧

🎭 對號入座:你適合怎麼用 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 只是幫你在做完這些基本功之後,多一雙「回頭檢查昨天有沒有異常」的眼睛。


🔶 🔶 🔶

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

輸出模式 適合情境 優點 限制
stdout 終端機顯示 手動臨時查詢、除錯測試 即時看到結果,不需額外設定 不會保存,關掉終端機就沒了,無法自動通知
mail 電子郵件寄送 日常自動化排程監控 主動推播,不用自己記得去查看 需要額外設定並確認 MTA(郵件伺服器)運作正常
file存成檔案 長期歸檔、合規稽核留存 方便批次保存與日後查閱,可搭配網頁瀏覽 需要自行規劃保存期限與清理機制,避免塞爆硬碟

🟪 🟪 🟪

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

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

總結今天學到的重點:

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

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

列印本文 [56] 👨‍👩‍👧‍👦 8 次瀏覽