カテゴリー: PC Page 2 of 57

XServer VPS切り替え後のトラブル。(ログの肥大化によるサービス停止と対応・恒久的対応策)

概要

2025/08/12 朝、管理しているWebサーバーにSSHで接続できなくなり、Webサイトも全て閲覧できなくなる障害が発生しました。本記事は、その原因究明から、応急処置、そして恒久対策までの一連の流れを記録したものです。

障害発生時の状況

  • Webサイトにアクセスすると、タイムアウトエラーになる。
  • SSHでログインしようとしても、接続ができない。
  • VPSの管理コンソールから再起動をかけると、redis-serverの停止処理(DBの保存)でタイムアウトし、正常にシャットダウンできない。
  • 強制再起動後、一時的に復旧するものの、しばらくすると再び応答がなくなる。

止まっていたサービス

  • mongod
  • redis-server
  • elasticsearch
  • growi

原因の特定手順

切り分け中に原因判明

障害の切り分け中、Wasabiクラウドストレージをマウントしようとした際に、以下のエラーが発生しました。

  • クラウドストレージのマウントを実行
sudo mount -a
mount.s3fs: unable to access MOUNTPOINT /mnt/wasabi: No space left on device

No space left on device(デバイスに空き領域がありません)」というこのエラーメッセージ。150GBもディスク容量があるのになぜ……? 思いつつ調査を行います。

ディスク使用率の確認

上記のエラーを受け、ディスクの空き容量を確認しました。

df -h

実行結果:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       145G  145G     0 100% /

この結果から、**ルートディレクトリ(/)のディスク使用率が100%**になり、空き容量がゼロになっていることが、数値的にも裏付けられました。

容量を圧迫しているディレクトリの調査

次に、どのディレクトリが容量を使い果たしているのかを調査しました。

sudo du -h -d 1 /

実行結果(抜粋):

125G    /var

/varディレクトリが125GBを占めていることが分かりました。さらに詳細に調査を進めます。

sudo du -h -d 1 /var/log

実行結果(抜粋):

122G    /var/log/apache2

/var/log/apache2が122GBという、異常なサイズになっていることが特定できました。

肥大化したログファイルの特定

その後、/var/log/apache2ディレクトリの中身を確認しました。

ls -lh /var/log/apache2

実行結果(抜粋):

-rw-r-----  1 root adm   61G  8月 12 08:09 modsec_audit.log
-rw-r-----  1 root adm   59G  8月 11 00:15 modsec_audit.log.1

**ModSecurityの監査ログ(modsec_audit.log)**が、わずか2日間で120GB以上にまで肥大化していたことが、直接の原因であると確定しました。

ここまで分かれば対処はもうすぐです。

対処手順

ステップ1:応急処置(空き容量の確保)

まず、サーバーを正常に動作させるため、巨大化した監査ログを削除し、空き容量を確保します。

  • 巨大なログファイルを削除
sudo rm /var/log/apache2/modsec_audit.log*
  • Apacheを再起動して、ファイルハンドルを解放
sudo systemctl restart apache2.service

ステップ2:恒久対策(監査ログの無効化)

modsec_audit.logは、攻撃の詳細な分析やデバッグには役立ちますが、今回のようにログがディスクを圧迫し、サーバーダウンを引き起こしますため、この設定をオフにします。

  1. ModSecurityのメイン設定ファイルを開きます。 sudo nano /etc/modsecurity/modsecurity.conf
  2. SecAuditEngineの値をOffに変更します。 修正前: SecAuditEngine RelevantOnly 修正後: SecAuditEngine Off
  3. Apacheをリロードして設定を反映させます。 sudo systemctl reload apache2.service

その後、念のためサーバそのものを

```bash
sudo reboot
```

で、状況が元に戻っていることを確認しました。

まとめ

今回の障害は、ModSecurityの監査ログが有効になったまま放置され、そのログがログローテーションの対象になっていなかったために、ディスク容量を100%使い果たしたことが原因でした。

前述したとおり、よりよいスペックのサーバに引っ越した後の出来事だけに、かなりの冷や汗ものでした。

VPSをWebArena→XServerへと切り替えたときのメモ。

2024年9月から利用してきた WebARENA VPS を XServer VPS に切り替えました。
理由は大きく分けて以下の3点です。

1. 物理的リソースの逼迫

旧環境では、以下のアプリが同時稼働していました。

この構成ではメモリ使用量が常に高止まりし、スワップ発生も頻繁。
安定運用のためには、より余裕のある環境が必要でした。

2. キャンペーン終了によるコスト増

WebARENA VPS の 4GB プランはキャンペーン中であれば 月額約980円 と魅力的でしたが、
終了後は 月額約1,600円 に上昇。コスト面の優位性が失われました。

3. XServer VPS を選んだ理由

  • 既にこの WordPress をホストしている会社で信頼性が高い
  • 同価格帯でも メモリ6GB と余裕がある
  • NVMe SSD 搭載でストレージ速度が段違い
  • 年額契約でキャンペーン終了後も料金安定
  • 最終的にWebARENA 4GB プランより安くなる

サーバ移行のタイムライン

  • 8/03 : 契約、初期設定(UFW / fail2ban)
  • 8/04 : 負荷試験を兼ねて Growi 導入(Apache / MongoDB / Elasticsearch / Node)
  • 8/05 : MySQL 導入
  • 8/06 : ModSecurity 導入
  • 8/07 : PHP-FPM 導入、Wasabi 接続、Nextcloud・BookStack・Laravel アプリ移行
    • この時点で「Growiを削除しなくてもいける」と確信
  • 8/08 : Redmine 6.0 新規構築に挑戦 → DB移行でエラー
    • 方針転換し Redmine 5.1 を移植(公開用)
  • 8/09 : 残りの Redmine 2件も移行完了、DNS 切替、WebARENA 解約

結果: 7日間で全サービス移行完了。Growi 常駐のまま全サイトを載せられたのは想定外というか、嬉しすぎる誤算でした。

スペック比較

項目WebARENA(旧)XServer(新)変化
CPUXeon E3-12xx (2011年)AMD EPYC Milan (2021年)大幅性能向上
vCPUコア数4コア4コア同等
メモリ4GB6GB1.5倍
ストレージ80GB SSD150GB NVMe SSD約1.9倍+高速化
ネットワーク500Mbps100Mbps低下
月額料金約1,630円(終了後)1,439円(年額換算)安価

新環境のメモリ状況

free -h
               total        used        free      shared  buff/cache   available
Mem:           5.8Gi       2.1Gi       1.6Gi       121Mi       2.5Gi       3.6Gi
Swap:          2.0Gi       623Mi       1.4Gi

Growi(MongoDB + Elasticsearch + Node)常駐のままで 3.6GiB available
旧環境より明確に余裕があり、スワップも軽減。

感想と今後

  • 前払いの安心感:年額払いで価格変動リスクなし
  • サービス統合効果:VPSとレンタルサーバを同社で一元管理
  • 展望:Redmine 6.0 アップデート挑戦、または5.1での堅牢運用

個人的に、NWの転送速度をサーバのリソースで解決するパワープレイができたのが安心です。

Apache全般のログローテーション設定。

サーバの移設中なので、ログに関しての記録を残しています。

概要

Webサーバ全般のメンテナンスで特に必要なのは

「ログを適切に管理する」

です。

  • 不審なアクセスの兆候
  • 自分のやらかし

を目の当たりにできる手段だからです。(特に後者に助けられたことは幾度となくあります)

そのため、Webサーバ上のログのローテーションを行い、履歴を追いやすくし、更にサーバの容量も削減するログローテーションを行います。

ログローテーションとは

ログファイルが肥大化するのを防ぐために、古いログを一定のルールに基づいて新しいログに切り替えたり、削除したりする仕組みのことです。

hogeサイトのアクセス記録である/var/log/access.logというファイルは、何も設定していないとログが記録され続けます。これによって以下の問題が起きます。

  • ログの肥大化によるサーバ容量の圧迫
    • テキストファイルぐらいと思う方がいるかも知れませんが、昨今の不正アクセスやAIサイトのクローラーのアクセス頻度は異常です。個人サイト程度でも一日数十MBはよくあります。
    • RedmineのようなWebアプリの場合、そのログは数百MBになります。
    • → このため、指定した期間でログを新しいログに差し替え、古いものは削除していくという仕組みを取ります。
  • ログの追記によるサーバのリソース増加
    • 追記自体の負荷は小さいですが、そのログをgrepなどで分析・検索する際に、巨大な単一ファイルだと非常に多くのメモリとCPUを消費します。
    • → ログを適切に分割(ローテーション)しておくことで、日々のログ分析が高速かつ軽量に行えるようになります。

これを行うべきタイミング

「Webサーバに新たなWebサイトやサービスを立ち上げたとき」 です。
試験運用などでもログは問題が起きたときのヒントとなるからです。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • apt(aptitude)によるパッケージ管理でインストールしているため、Apacheの実行ユーザはwww-dataです。

備考

ディストリビューションが違ってもこの手順は有効ですが、RockyやAlma等のRHEL系のApacheの実行ユーザは通常はapacheであることに注意しましょう。

さっくりとした手順

  1. (念のため)設定を行うサイトのログをwww-dataに変えます。
  2. ログローテーションのファイルを作成します。
  3. ログローテートの設定が有効かを確認します。

ここでは、hogeサイト(/var/log/hoge)のログをローテーションする方法です。

サイトのログの実行ユーザの変更(所有者変更)

これは、Redmineのlogプラグインのように、Webインタフェース上からログを閲覧できるプラグインがある場合、Apacheを実行しているサービス自体が参照できるようにするためです。

  • chownによる所有者変更
sudo chown -R www-data:www-data /var/log/hoge

ログ一式の所有者を変えます。ログファイルの形式は自分の環境に合わせます。

  • 所有者変更確認
ls -l /var/log/hoge

ログファイルの所有者とグループがwww-dataであることを確認します。

ログローテーションファイルの作成

ファイル名やログのパスは自分の環境に合わせます。 ここを間違えると元も子もありません。

cat <<- __EOF__ | sudo tee -a /etc/logrotate.d/hoge
/var/log/hoge/*.log {
    daily
    missingok
    rotate 10
    compress
    copytruncate
    notifempty 
    su www-data www-data
__EOF__

これは、以下を行います。

  • daiy
    • 1日ごとにローテーション
  • missingok
    • ログファイルが存在しなくてもエラーにしない
  • rotate 10
    • 10世代分の古いログファイルを保持する(それ以降は破棄)
  • compress
    • 古いログファイルをgzipで圧縮する
  • copytruncate
    • ログをコピーしてから元のファイルを空にする(サービス無停止でログ切替)
  • notifempty
    • ログファイルが空の場合はローテーションしない
  • su www-data www-data
    • ローテーション後のファイルの所有者を指定

他、週ごとやログのファイル形式(日付形式)などを設定できます。こちらは運用に合わせてください。

ログローテーションの確認

  • 設定確認
sudo logrotate -dv /etc/logrotate.d/hoge

※先ほど作成したファイル名に合わせます。

ここでエラーがなければログローテーションはできています。

  • ログローテーションの即時実行

すぐにローテーションを確かめる場合は以下を実行します。強制的にログローテーションを行うコマンドです。

sudo logrotate -f /etc/logrotate.d/hoge

このコマンドを実行後、/var/log/hoge/ディレクトリ内にaccess.log.1.gzのようなファイルが作成され、元のaccess.logが空になっていれば、設定は完璧です。

CPUとメモリ情報を表示するワンライナー。

概要

サーバスペックの要となる

  • CPU
  • コア数
  • メモリ量
  • スワップ量

を一度に表示するワンライナーです。

ワンライナー内容

awk 'BEGIN {FS=":"; OFS="\t"} /^model name/ && !cpu_model {cpu_model=$2; gsub(/^ */, "", cpu_model)} /^processor/ {cores++} /^MemTotal/ {mem_total=$2} /^MemAvailable/ {mem_avail=$2} /^SwapTotal/ {swap_total=$2} END {printf "CPUモデル\t: %s\n", cpu_model; printf "CPUコア数\t: %s\n", cores; printf "合計メモリ\t: %.2f GiB\n", mem_total/1024/1024; printf "利用可能メモリ\t: %.2f GiB\n", mem_avail/1024/1024; printf "合計スワップ\t: %.2f GiB\n", swap_total/1024/1024}' /proc/cpuinfo /proc/meminfo

実行結果

CPUモデル       : AMD EPYC-Milan Processor
CPUコア数       : 4
合計メモリ      : 5.78 GiB
利用可能メモリ  : 5.34 GiB
合計スワップ    : 2.00 GiB

と、分かりやすい表示で一気に表示してくれます。

出先での記録環境。

中古で購入したThinkPadがもたらしたのは、「出かけることのハードルの低さ」です。

常に行う

  • 日記
  • ブログの更新
  • 体調、入出金などライフログの記録

が、自宅で行うことなく可能になったからです。

喫茶店で食事を取りながらの入出金記録を行い(この食事代も記録しながら)

また、出先に椅子とテーブルがあると分かっていれば、このように、アナログな記録も同時に実施することができます。

記録するための道具がそろっていれば、記録する環境は問わない(というか状況に合わせて選べる)

というのが分かったのが、このThinkPadでの収穫です。

Ubuntuでhistoryの履歴を追いやすくするシェルスクリプト並びにコマンド化。

概要

設定変更時、過去のコマンド履歴を確認するため

history | grep command

として過去の履歴を確認します。これをシェルスクリプトの力で解決します。(スクリプト作成にはGemini pro 2.5を利用)

スクリプト

  • histgrep.sh
#!/bin/bash

# スクリプトに引数が渡されたかどうかで処理を分岐
if [ "$#" -gt 0 ]; then
  # 引数が存在する場合、その値を検索文字列として使用
  SEARCH_TERM="$1"
else
  # 引数がない場合、対話式でユーザーに入力を促す
  read -p "探したいコマンドを入力してください: " SEARCH_TERM
fi

# 検索文字列が空の場合はエラーメッセージを出して終了
if [ -z "${SEARCH_TERM}" ]; then
  echo "検索文字列が入力されていません。"
  exit 1
fi

# historyコマンドの代わりに、履歴ファイルを検索する
HISTFILE_PATH="${HISTFILE:-$HOME/.bash_history}"

echo "実行履歴から「${SEARCH_TERM}」を含むコマンドは以下の通りです。"
grep "${SEARCH_TERM}" "${HISTFILE_PATH}"

これを保存して、

chmod +x histgrep.sh

で実行権限をつけます。

コマンド実行例

引数無しの対話型

./histgrep.sh
探したいコマンドを入力してください: bundle
実行履歴から「bundle」を含むコマンドは以下の通りです。
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle exec gem install rake
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo -u www-data bundle install --without development test --path vendor/bundle
sudo bundle install

と、探したい文字列を含む履歴をhistory(正確には履歴ファイル)から参照します。

引数型

./histgrep.sh configtest
実行履歴から「configtest」を含むコマンドは以下の通りです。
sudo apache2ctl configtest

このように、探したい文字列を引数とすることで、そのコマンドを探せます。

コマンド化

これをコマンド化します。

sudo ln -sf /path/to/script/directory/histgrep.sh /usr/local/bin/histgrep

/path/to/script/directory/histgrep.shはフルパスで、スクリプトがある場所を指定します。

which histgrep

で、/usr/local/bin/histgrepを確認。

後は、作業中でも

histgrep tar

などとすれば、過去に実行したコマンドの履歴を容易に参照することができます。

トラックポイント付きのキーボードをデスクトップに導入。

今月購入したThinkPadキーボードが非常に自分好みだったことと、「トラックポイントをデスクトップPCでも使いたい」ことから買ってみました。

有線 ThinkPad トラックポイント・キーボード - 日本語 0B47208

  • ThinkPadロゴ付き
  • 有線

英語配列キーボードでなかったのは、使っているノートに合わせての配慮です。

ノートPCと比べるとこの通り。x13の方が心持ち狭く、トラックパッドもありません。

とはいえ、キーストロークは自分好みだったのは分かっているため、安心して使うことができそうです。

Redmine5.1にadditionalsをインストール

以前も書いていたadditonalsプラグインのインストール、Redmine5.1版です。

このプラグインの最新版はRedmine6.0のみ対応しています。そのため、ややバージョンの落ちるRedmine5.1で動かすには少し手間があります。

概要

Redmineにかなり強力なマクロを付与するプラグイン:additionalsをインストールします。

また、このプラグインは「additonal_tags」プラグインでも必要です。

プラグイン名

注意

2025年にリリースされているプラグインはRedmine 5.xをサポートしていないため、動くバージョン(タグ)をダウンロードしてのインストールです。

動作を確認した環境

  • Ruby 3.1
  • Redmine 5.1
  • Apache 2.4

さっくりとした手順

  1. SSHログイン後、作業ディレクトリに移動
  2. wgetでRedmine5.1に即したパッケージをダウンロード
  3. パッケージの配置
  4. 新規ジェムをインストール
  5. DBマイグレーション
  6. Webサービス再起動

作業用ディレクトリに移動します。

cd /hoge

任意のディレクトリに移動します

Redmine5,1に即したバージョンをダウンロードして展開します。

  • ファイル入手
wget https://github.com/AlphaNodes/additionals/archive/refs/tags/3.4.0.zip
  • zipファイルの所有者変更
sudo chown www-data:www-data 3.4.0.zip

apache / nginxの実行ユーザに所有者を合わせます

  • 解凍
sudo -u www-data unzip 3.4.0.zip

Redmineディレクトリにプログラムを配置します。

  • ファイル配置
sudo -u www-data mv additionals-3.4.0 /path/to/redmine/root/directory/plugins/additionals

このとき、リネームも行います。(-3.4.0を外す)

自分の環境に合わせます。(筆者環境/home/www-data/redmine/plugins/)

Redmineのルートディレクトリに移動します。

cd /path/to/redmine/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/redmine)

Gemをインストールします。

sudo -u www-data bundle install

DBのマイグレーションを行います

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

Webサービスを再起動します。

sudo systemctl restart apache2

動作確認

  1. Redmineに管理者アカウントでログインします。
  2. 管理に「Additionals」が加わっていればインストールされています。

公開用Redmineの整備。

別サイトとして運営している

(上記マルチドメインのため、どちらのサイトでも同じ内容です)

こちら、『ライザのアトリエ トリロジーDX』のリリースにより整備する必要が出てきました。

プロジェクトの追加とキャッチ画像の追加

プロジェクト - クーケン島観光ガイド

それぞれにBing Image Creatorで生成したアイコンを指定。

更に、今まで作っていなかったプロジェクトとして

概要 - 02_arライザのアトリエ1 - クーケン島観光ガイド

『ライザのアトリエ』を追加です。DX版に伴い、もう一度、最初からやっていき言語化していきたいなと思った次第です。

ただ、それまでの間に今止まっている

  • 『ユミアのアトリエ』のクエストなどの整理
  • 『ライザのアトリエ2』陽炎の島の装備の解説

など、やることは多いです。

モバイルバッテリー・流用。

中古で購入したThinkPad。

状態がよいとはいえ、5年も前の機体なのでバッテリーの損耗はどうしても発生します。

現状、稼働時間に不満はありませんが、外出時のバッテリー切れに対応できるものはということで

MSI Claw用のモバイルバッテリー導入。 – Manualmaton's Laboratory

こちらをそのまま使うことにしました。AnkerのPowerbank。

ノートPCと比してもその存在感は相当なもの。

昨今のPCモデルらしく、PD給電に対応しているのが幸いしていました。

無事にUSB-Cケーブルと接続して、

充電されていることを確認です。これなら、いざというときにも使えると判明したので助かりました。

Page 2 of 57

Powered by WordPress & Theme by Anders Norén