logwatchとは何か — サーバーの「健康診断レポート」を毎朝読む習慣　公開日: 2026-06-06

■ はじめに サーバーを管理していると、「昨日、サーバーで何が起きていたか」を知りたくなる。不正アクセスの試行、メールの配信状況、ディスクの空き容量、サービスの異常停止。 これらを毎日ログファイルを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秒が数時間の障害対応を防いでくれる。サーバー管理者にとっての定期健康診断だと思って、習慣化することをおすすめする。