Logwatch 解决的是一个否则根本无人解决的问题：它替你把服务器的全部日志读一遍，然后发来前一天的摘要。没有人会每天翻 auth.log 和 Web 服务器日志，而早上读一封邮件是做得到的。

已知的问题是：第一封信带着几百行来了，第二封被扫了一眼，一周后邮件客户端的某条规则把它们扔进了单独的文件夹，盯着看这件事就此结束。原因几乎总是默认设置，而修好它要十分钟。

安装，以及在哪里改设置

sudo apt install logwatch

你把自己的值放在哪里很重要。文件 /usr/share/logwatch/default.conf/logwatch.conf 不能动——包更新时它会被覆盖。你的文件是 /etc/logwatch/conf/logwatch.conf。它可以是空的；只加上你要改的那些就够了。

Output = mail
Format = html
MailTo = admin@example.com
Detail = Low
Range = yesterday

详细程度决定一切

Detail 接受 0 到 10 的数值，或者 Low、Med、High 这几个词。差别巨大：在 High 下报告会包含每一个连接和每一个请求；在 Low 下只有汇总和异常。

实践做法是：整体用 Low，只为你真正关心的那些服务有选择地提高详细程度。按服务的设置放进 /etc/logwatch/conf/services/——例如一个含有 Detail = High 一行的 sshd.conf。

检验的标尺是：报告应当能放进一屏到一屏半。再长的东西就会不再被读——不是因为懒，而是因为在三百行的日常里，一处偏差根本看不出来。

不必等到早上就想看结果：

sudo logwatch --detail Low --range today --output stdout

Debian 12 上空掉的 SSH 一节

较新系统上的一个单独陷阱。Logwatch 读的是 /var/log 里的文本文件，而 Debian 12 和 Ubuntu 24.04 默认不再安装 rsyslog——文件 /var/log/auth.log 干脆就不存在，一切都进了 systemd 的日志。报告照旧准时到来，但最要紧的一节——SSH 登录——却是空的，或者干脆没有。

检查只需一秒：

ls -l /var/log/auth.log

文件不在的话，要么装上 rsyslog，要么承认在这台机器上 Logwatch 给出的是一幅不完整的图景。而把空掉的一节读成「什么也没发生」太容易了，而那正是最危险的后果。

邮件去了哪里

「报告收不到」的第二个常见原因是：服务器上根本没有配置好邮件投递。Logwatch 把信交给系统的代理，代理哪儿也不送，于是信就躺在 root 的本地邮箱里，而那里从来没人去看：

sudo cat /var/mail/root | tail -50

有两条路。要么通过外部 SMTP 中继配置好投递，要么干脆不用邮件，把报告写进一个文件：

Output = file
Filename = /var/log/logwatch/report.txt

第二种更诚实：一封谁也送不出去的邮件制造的是「有人在盯着」的错觉，而磁盘上的一个文件至少还能打开。

报告里该读什么

按有用程度递减排列：

  • sshd。成功的登录——谁、从哪里。恰恰是成功的那些，而不是成千上万次失败：失败是背景噪声，而来自陌生地址的一次登录则需要解释；
  • sudo 与 pam_unix。谁提升了权限、谁创建了用户；
  • Disk Space。一行字，提前警告磁盘正在被填满；
  • cron。新出现的任务，以及失败的任务；
  • http。404 响应的激增通常意味着有人在试探路径；而 500 的激增意味着你的某个东西坏了；
  • postfix，如果服务器发邮件的话：外发队列不断增长，是服务器被拿去当垃圾邮件中继的典型信号。

它的边界

Logwatch 是前一天的摘要，不是告警。它不会在夜里叫醒你，而且按定义就是滞后的：它由凌晨的每日任务运行，覆盖的是昨天。对于「此刻正在发生什么」，它既不适合也不是为此而生的。

它的长处在别处——它让你看到一个普通日子的形状。读上一个月，你就知道正常情况下有多少次失败登录、站点接多少请求、发出去多少邮件；而当其中某个数字翻倍时，它会立刻显现出来，不需要任何阈值和任何规则。正因如此，这份报告值得放在会映入眼帘的地方，而不是某个邮件文件夹里。它在一个页面上是什么样子，见下面的演示。