ログの管理をカスタマイズするならログローテーションを忘れずに

何ぃ！？　リバースプロキシのエラーログが90GBだと！？！？(愚か)

---

CentOS Stream 9でアップデートをかけようとすると「No space left on device」というエラーが出た。
ちょっと変だなと思って調べてみると、/varの容量が肥大化してた(ノ∀`)

▼参考にしたサイト

【緊急対処】VPSが動かない！「No space left on device」が出た時に空き容量を確保する完全手順

Linuxサーバーで「No space left on device」エラーが出て困っていませんか？安価なVPSでよくあるディスク容量不足の原因特定（df/duコマンド）から、肥大化したログファ…

www.linuxkoubou.com

参考サイトにあるように、どこが重いのかを探す。そして/varに原因があったので詳細を探す。

du -sh /* 2>/dev/null | sort -hr

du -sh /var/* 2>/dev/null | sort -hr

/var/logが最大の犯人ということで、/var/log/nginxを確認すると、/var/log/nginx直下ではなく/var/log/nginx/debugのよう独自で用意したディレクトリのリバースプロキシ用エラーログが肥大化していた。90GB……。
ファイルに何が書かれているのか気になったけれども、さすがに90GBレベルになると何が起こるかわからなかったので、まずはコマンドからファイルの中身をいずれかのコマンドを使って空にする。

cat /dev/null > /var/log/nginx/debug/hoge_error.log

truncate -s 0 /var/log/nginx/debug/hoge_error.log

一旦サーバーがある程度動くようになったところで、ずっとなぜかtest_error-yyyymmdd.gzというファイルが生成されないと思い、ここでようやくログローテーションというものを知る。

ログローテーションの設定見直し

vi /etc/logrotate.d/nginx

中に書かれていたのは以下のような記述

/var/log/nginx/*.log {
    create 0640 nginx root
    daily
    rotate 10
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

個別に用意したディレクトリには反映されないや(ノ∀`)
/var/log/nginx/debugというディレクトリを用意したなら、ひとまず元のコードをコピペ。

#
# add
#

/var/log/nginx/debug/*.log {
    create 0640 nginx root
    daily
    rotate 10
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

そして、WEBサーバーはApacheなので、Apache側のログの設定も見直すこと。

vi /etc/logrotate.d/httpd

案の定、/var/log/httpd/直下にあるログファイルだけローテーションされてた(ノ∀`)

/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
        /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    endscript
}

ログローテーションのチェックと設定反映

ログローテーションの設定をチェックするため、以下コマンドでシミュレーションする。(ファイルの削除や圧縮等は行なわれない)

▼Nginxのログローテーションチェック

logrotate -d /etc/logrotate.d/nginx

▼Apacheのログローテーションチェック

logrotate -d /etc/logrotate.d/httpd

赤文字で「error:」といった内容がなければOK。

ログローテーションは次の定期実行で自動的に新しい設定が反映されるため、放っておいてもよい。
ただしすぐに反映させたいなら以下のコマンドを打つ。

▼Nginxのログローテーションをすぐに試すコマンド(デバッグあり)

logrotate -df /etc/logrotate.d/nginx

▼Apacheのログローテーションをすぐに試すコマンド(デバッグあり)

logrotate -df /etc/logrotate.d/httpd

元のログファイルやディレクトリの権限／権限グループを見直す

ログローテーションを反映させたタイミングによっては前の権限や権限グループが残っているので、一応直しておく。

chmod 640 /var/log/nginx/debug/hoge_error.log

chown -R nginx:root /var/log/nginx/debug

もし/var/log/nginx/debugの中に入っているlogファイルの権限や権限グループを一括で変更するなら、以下の通り。

find /var/log/nginx/debug -type f -exec chmod 640 {} +

find /var/log/nginx/debug -type f -exec chown nginx:root {} +

現在のログの確認と削除

ログローテーションが済んでも、他のエラーログやアクセスログの容量も膨れ上がっているので、とりあえず一回ファイルの中身を確認しつつ、最後に空にする。

▼最新（末尾）の20行だけ見る

tail -n 20 test_error.log

▼先頭の20行だけ見る

head -n 20 test_error.log

▼特定のエラー種別(今回はerror)が出た最新のログを20行分だけ見る

grep -o '\[error\].*' test_error.log | tail -n 20 | sort | uniq -c

NginxやApacheの設定ファイルのエラー種別を見直す

エラーログのエラー種別を「debug」にしていた(ノ∀`)
アクセス拒否の処理が多いため、「warn」ではなく「error」に変更。

最終結果

色々あれこれ試した結果、/var/logは485Mに収まった(´・ω・｀)
/var/lib？そいつはまだ3.7Gだ。今度ちゃんとDBを見直す()

Geminiとの対話メモ