はじめに
サーバーを管理していると、「昨日、サーバーで何が起きていたか」を知りたくなる。不正アクセスの試行、メールの配信状況、ディスクの空き容量、サービスの異常停止。
これらを毎日ログファイルを1つずつ開いて確認するのは現実的ではない。Linuxサーバーのログは /var/log/ 以下に数十ファイル散らばっていて、1日分だけでも数万行になることがある。
logwatchは、この「昨日のログを全部読んで要約する」作業を自動でやってくれるツールだ。
logwatchの正体
logwatchはPerl製のログ解析・レポートツールで、ほとんどのLinuxディストリビューションに標準で入っている（または簡単にインストールできる）。cronで毎朝自動実行され、前日のログを解析してメールで送ってくれる。
やっていることはシンプルで、
- /var/log/ 以下の各種ログファイルを読み込む
- サービスごとに分類・集計する
- テキスト形式のレポートを生成する
- 指定のメールアドレス（通常root）に送信する
人間が毎日やるには面倒すぎる作業を、毎朝決まった時間に黙々とこなしてくれる。
レポートの構成
logwatchのレポートは、ヘッダーの後にサービスごとのセクションが並ぶ構造になっている。
ヘッダー
################### Logwatch 7.5.5 (01/22/21) ####################
Processing Initiated: Sat Jun 6 03:23:07 2026
Date Range Processed: yesterday
( 2026-Jun-05 )
Detail Level of Output: 0
Type of Output/Format: mail / text
Logfiles for Host: server.example.com
##################################################################
処理日時、対象期間（通常は「yesterday」）、ホスト名が記載される。Detail Levelは0〜10で、数字が大きいほど詳細な情報が出力される。
主要セクション
サーバーの構成によって出るセクションは変わるが、メールサーバーを運用している環境では概ね以下のセクションが出る。
dnf-rpm — パッケージの更新履歴。セキュリティアップデートが適用されたか一目でわかる。
Dovecot — IMAP/POP3サーバーの状態。配信数、切断数、認証エラー、接続上限超過など。「killed」の文字が出たら要注意。
httpd — Webサーバー。mod_proxyを悪用したプロキシ試行などが検出される。
iptables firewall — ファイアウォールで遮断されたパケットの統計。大量スキャンのIPが一覧で出る。
pam_unix — 認証の成功・失敗。SSHやsudoの認証失敗がここに出る。
SpamAssassin — メールのスパム判定統計。アカウントごとのclean/spam件数が一覧になる。
SSHD — SSH接続の試行。認証前のタイムアウトやブルートフォース攻撃の痕跡。
Systemd — 各サービスのCPU消費、メモリピーク、エラー。サービスが異常停止していた場合はここに出る。
Disk Space — ディスク使用率。あふれそうなパーティションを早期発見できる。
何を見ればいいのか — 実務で注目する5つのポイント
毎日のlogwatchを全行読む必要はない。経験上、以下の5箇所を見るだけで問題の9割は拾える。
1. SpamAssassinのスパム率
Summary:
Total Clean: 1851 ( 42%)
Total Spam: 2581 ( 58%)
正常な目安：clean 60〜80%、spam 20〜40%。
spam率が0%の場合、SpamAssassinが無効になっている可能性がある。これは「スパムがない」のではなく「スパム判定が動いていない」ことを意味する。実際にこのパターンで発見が遅れ、Gmail転送障害が複数サーバーに広がった事例がある。
逆にspam率が80%を超えるアカウントがあれば、catch-all設定の見直しやフォワーダーの確認が必要。
2. Dovecotの異常
Dovecot was killed, and not restarted afterwards.
この一文が出たら、IMAP/POP3が停止している可能性がある。ただし、logwatchの集計タイミングとサービス再起動のタイミングによっては、実際には正常復旧しているケースもある。
確認方法：
systemctl status dovecot
「active (running)」なら問題なし。「inactive」や「dead」なら即再起動が必要。
付随して Processes aren’t dying after reload 等のWarningが出ている場合は、設定リロード時のプロセス停止に問題があった証拠。根本原因がメモリ不足であるケースもあるので、Systemdセクションのメモリピーク値とあわせて確認する。
3. SSHの認証失敗パターン
pam_unixセクションとSSHDセクションを見る。
Authentication Failures:
unknown (172.xxx.xxx.xxx): 14 Time(s)
root (152.xxx.xxx.xxx): 3 Time(s)
注意すべきパターン：
- 特定IPからの大量失敗 → ブルートフォース攻撃（通常はCSF/LFDが自動ブロック）
- unknown ユーザーへの試行 → 存在しないユーザー名での攻撃。SSHポートを変更していれば大幅に減る
- 特定の実在アカウントへの試行 → パスワード漏洩の可能性。要警戒
ただし、認証失敗 ≠ 攻撃 とは限らない。実際に、1日870件の認証失敗が記録されたIPを調査したところ、顧客が利用しているグループウェアサービスのIPだったケースがある。パスワード変更後にグループウェア側の設定を更新していなかったため、定期巡回のたびに認証失敗が記録されていた。安易にブロックすると正規サービスを止めてしまう。
4. Systemdのメモリピークと異常停止
exim.service: State ‘final-sigterm’ timed out. Killing.
imunify-antivirus.service: Consumed 23min CPU time, 8.1G memory peak.
final-sigterm や Killing はサービスが正常終了できなかったことを示す。メモリピークが異常に高いプロセスがあれば、そのプロセスがメモリを圧迫して他のサービスを巻き添えにした可能性がある。
OOM Killerが発動していないかは dmesg | grep -i oom で確認できる。
5. ディスク使用率
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 394G 171G 204G 46% /
80%を超えたら黄色信号。90%を超えたらメール受信やログ書き込みに支障が出始める。特に /var/log/ や /backup/ が肥大化しやすい。
logwatchに出ない、でも重要なこと
logwatchは万能ではない。以下は自分で確認する必要がある。
Gmailへの転送状況
logwatchのSpamAssassinセクションにはスパム判定統計が出るが、「そのスパムがGmailに転送されたかどうか」「Gmailが受信拒否しているかどうか」は出ない。
これを確認するにはEximログを直接調べる必要がある：
# Gmail宛の550拒否（スパム送信元と判定された）
grep -c ‘550.*5\.7\.1’ /var/log/exim_mainlog
# Gmail宛の421制限（レート制限がかかっている）
grep -c ‘421.*gmail\|rate.*gmail\|too many’ /var/log/exim_mainlog
# Gmail宛の成功/失敗内訳
grep ‘gmail\.com’ /var/log/exim_mainlog | grep -c ‘Completed’
grep ‘gmail\.com’ /var/log/exim_mainlog | grep -c ‘defer’
grep ‘gmail\.com’ /var/log/exim_mainlog | grep -c ‘Failed’
550や421が1件でも出ていたら、サーバーのIPレピュテーションが低下し始めている。SpamAssassinの有効/無効とシステムフィルタの設定を即座に確認すべきサインだ。
DKIM/SPFの設定状態
メール認証の設定はlogwatchに出ない。DKIMが未設定のままGmailに転送すると、Googleに不信扱いされてレピュテーション低下につながる。
# cPanel: DKIM有効化済みドメイン数
/usr/local/cpanel/bin/dkim_keys_installed | wc -l
# DNS反映確認（サンプル）
dig +short default._domainkey.example.com TXT
メールキューの状態
キューに何通溜まっているかもlogwatchには出ない。
# キュー内のメール数
exim -bpc
# バウンスメール数
exim -bp | grep ‘<>’ | wc -l
キューが100通を超えていたら、何かが詰まっている。バウンスが大量にあれば、スパム転送の副作用でバウンスが溜まっている可能性がある。
logwatchを活用するための設定
配信先の設定
# /etc/logwatch/conf/logwatch.conf
MailTo = admin@example.com
Detail = Low
Detail Levelは Low（0）で十分。情報が多すぎると読まなくなる。異常を発見したら個別にログを調べればいい。
cPanelサーバーでの注意
cPanelサーバーでは、Dovecotセクションに大量の __cpanel__service__auth__imap__ エントリが出ることがある。これはcPanelの内部認証で、すべて 127.0.0.1 からの接続。正常な動作なので無視して構わない。行数的にはセクションの大部分を占めるが、フィルタリングすべき対象ではない。
DirectAdminサーバーでの注意
DAサーバーではログパスがcPanelと異なる。
| 項目 | cPanel | DirectAdmin |
|---|---|---|
| Eximログ | /var/log/exim_mainlog | /var/log/exim/mainlog |
| Dovecotログ | /var/log/maillog | /var/log/dovecot.log |
logwatchは自動的にログパスを検出するが、手動でログを調べる際はパスの違いに注意。
まとめ — logwatchは「読む」ものではなく「チェックする」もの
logwatchを毎朝全行読むのは非効率だ。以下の5つの数値だけをチェックする習慣をつければ、問題の早期発見率は格段に上がる。
| チェック項目 | 見る場所 | 正常 | 異常の目安 |
|---|---|---|---|
| SpamAssassin spam率 | SpamAssassin Summary | 20〜40% | 0%（無効の疑い）or 80%超 |
| Dovecot killed | Dovecot セクション冒頭 | なし | 「killed」の文字 |
| SSH認証失敗 | pam_unix | 数十件程度 | 特定IPから100件超 |
| Systemdメモリピーク | Systemd Unmatched | 数百MB | 数GB超 |
| ディスク使用率 | Disk Space | 50%以下 | 80%超 |
1日30秒の確認で、数日後に大きな障害になるかもしれない問題を事前に潰せる。今日紹介した「Gmail転送障害を全台修復した話」も、logwatchのSpamAssassinセクションで「spam率58%、ちょっと高いな」と気づいたところから始まった。
logwatchは派手なツールではないが、毎朝の30秒が数時間の障害対応を防いでくれる。サーバー管理者にとっての定期健康診断だと思って、習慣化することをおすすめする。
