0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@platypus2000jp

Linux（Amazon Linux）環境活用 ライフハックスクリプト

0
Posted at

Linux（Amazon Linux）環境活用 ライフハックスクリプト
Linux | Amazon Linux 2 | AL2023

投稿日 2026年08月19日

AWS上のAmazon Linux 2およびAmazon Linux 2023（AL2023）環境における「ストレージの逼迫・空き容量低下」は、EC2インスタンスのディスク書き込み失敗やサービス停止に直結する典型的な障害パターンです。Amazon Linuxの標準ファイルシステムであるXFSの特性、DNF/YUMパッケージキャッシュの累積、Amazon SSM AgentやCloudWatch Agent等の各種ログ肥大化、プロセスに掴まれた削除済みファイル（Ghost Files）など、原因を定量的に特定せずに場当たり的なファイル削除を行っても根本解決には至りません。

Amazon Linux環境に最適化した「ファイル操作・容量診断レシピ」と、一括で一次切り分けを行う自動化シェルスクリプト『disk-doctor-al.sh』を提案します。

1. 階層的容量測定による「闇容量」の可視化

標準の du -sh * をルートディレクトリ配下で実行すると、/proc や /sys などの仮想ファイルシステム、EFSやEBSの別マウントポイントまで走査してしまい、調査の遅延や不正確な測定を招きます。

ファイルシステム境界を越えない指定（-x オプション）と、Amazon Linux固有のディレクトリ構造を意識した解析手法が必要です。

ディレクトリ別容量ランキングの算出

# ファイルシステム境界を越えずに1階層目のディレクトリ容量トップ10を抽出（並列処理・エラー抑制）
sudo du -hx --max-depth=1 / 2>/dev/null | sort -rh | head -n 11

Amazon Linux特有の調査ポイント

  • /var/log 配下の増大: cloud-init.log、amazon/ssm/（SSM Agent）、awslogs/ や amazon-cloudwatch-agent/ などのAWSエージェントログ、および audit/audit.log のローテーション設定不備が主原因となります。
  • /var/cache/dnf または /var/cache/yum: AL2023（DNF）やAL2（YUM）でパッケージ更新を繰り返すことで、ダウンロードされたRPMキャッシュが蓄積している可能性があります。
  • /var/lib/docker または /var/lib/containerd: ECSコンテナインスタンスやDocker運用環境において、未使用のイメージ・コンテナ・ビルドキャッシュが残留してストレージを圧迫します。

2. I/Oボトルネックとロック状態の特定

「ファイルを rm で削除したのに df の空き容量が増えない」「特定プロセス実行時にディスク書き込みエラーが発生する」現象は、プロセスによる削除済みファイルのファイルハンドル保持や i-node 枯渇が原因です。

削除済みファイルのプロセス保持とファイルシステム状態の検査

# 1. 削除されたがプロセスにオープンされたまま（容量を解放していない）ファイルを特定
sudo lsof +L1

# 2. i-node（ファイル数上限）の使用状況確認
df -i -h -x tmpfs -x devtmpfs

# 3. systemd journald ログが消費しているディスク容量の確認
journalctl --disk-usage
コマンド / パラメータ 意味と診断時の判定基準
lsof +L1 削除済み（deleted）にもかかわらずプロセスが開いているファイルを検出。対象プロセス（nginx や java 等）の再起動・リロードで領域が解放されます。
df -i (IUse%) ディスク容量に空きがあっても IUse% が 100% の場合、セッションファイルや微小ログの大量生成で新規ファイル作成が不可能になります。（XFSは動的割当ですが上限設定に注意）
journalctl --disk-usage システムログの総消費量。/etc/systemd/journald.conf 内の SystemMaxUse 設計見直しの指標とします。

3. 障害時にワンショットで一次切り分けを行う「自動化シェルスクリプト」

緊急時にAmazon Linux環境の全体像（パーティション状態、i-node、削除済み保持ファイル、巨大ファイル上位15件、AWSエージェント・DNF/YUMのキャッシュ状態）を整理し、ログへ保存する統合診断スクリプトです。

ワンステップ診断スクリプト：disk-doctor-al.sh

#!/usr/bin/env bash
#
# SYNOPSIS:
#   Amazon Linux (AL2 / AL2023) 用 ディスク・ファイルシステム一次診断スクリプト
#

set -u

LOG_PATH="/tmp/disk_diag_al_$(date +'%Y%m%d_%H%M%S').log"

# root権限チェック
if [ "$EUID" -ne 0 ]; then
    echo "エラー: このスクリプトは sudo または root 権限で実行してください。" >&2
    exit 1
fi

exec &> >(tee -a "${LOG_PATH}")

echo "=========================================="
echo " Storage Diagnostic Report (Amazon Linux) - $(date)"
echo " Host: $(hostname)"
echo " OS: $(cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2 | tr -d '"')"
echo " Kernel: $(uname -r)"
echo "=========================================="

echo -e "\n[1. Volume & Partition Status (Disk Space & Inode)]"
echo "--- Storage Capacity ---"
df -h -T -x tmpfs -x devtmpfs

echo -e "\n--- Inode Usage ---"
df -i -T -x tmpfs -x devtmpfs

echo -e "\n[2. Deleted but Open Files (Ghost Space Leak)]"
DELETED_FILES=$(lsof +L1 2>/dev/null | head -n 15)
if [ -n "$DELETED_FILES" ]; then
    echo "$DELETED_FILES"
else
    echo "No deleted open files found."
fi

echo -e "\n[3. Top 15 Largest Files in Root Filesystem]"
find / -xdev -type f -size +10M -exec du -h {} + 2>/dev/null | sort -rh | head -n 15

echo -e "\n[4. Amazon Linux / AWS Specific Cleanup Targets Summary]"

# DNF Cache (AL2023)
if [ -d "/var/cache/dnf" ]; then
    DNF_SIZE=$(du -sh /var/cache/dnf 2>/dev/null | cut -f1)
    echo "DNF Package Cache Size: ${DNF_SIZE}"
fi

# YUM Cache (AL2)
if [ -d "/var/cache/yum" ]; then
    YUM_SIZE=$(du -sh /var/cache/yum 2>/dev/null | cut -f1)
    echo "YUM Package Cache Size: ${YUM_SIZE}"
fi

# AWS Agent Logs (SSM & CloudWatch)
if [ -d "/var/log/amazon" ]; then
    AWS_LOG_SIZE=$(du -sh /var/log/amazon 2>/dev/null | cut -f1)
    echo "Amazon Agent Logs Size (/var/log/amazon): ${AWS_LOG_SIZE}"
fi

# Docker / Containerd Storage
if [ -d "/var/lib/docker" ]; then
    DOCKER_SIZE=$(du -sh /var/lib/docker 2>/dev/null | cut -f1)
    echo "Docker Storage Size: ${DOCKER_SIZE}"
fi

# Systemd Journal Logs
if command -v journalctl &>/dev/null; then
    echo -n "Journald Log Usage: "
    journalctl --disk-usage 2>/dev/null
fi

# Temp Directories
echo "Temp Directories Size:"
du -sh /tmp /var/tmp 2>/dev/null

echo -e "\n[5. Recent Storage & I/O Errors (dmesg & Kernel Logs)]"
dmesg -T -l err,crit,alert,emerg 2>/dev/null | grep -iE 'xfs|ext4|nvme|blk|I/O|error' | tail -n 10 || echo "No critical I/O errors found in dmesg."

echo "=========================================="
echo "Diagnostic complete. Saved to: ${LOG_PATH}"

実行方法

# スクリプトに実行権限を付与して管理者権限で実行
chmod +x disk-doctor-al.sh
sudo ./disk-doctor-al.sh

決定論的アプローチによるストレージ管理

障害対応時に「容量が足りないから勘で /var/log を削除する」という対症療法は、根本原因（ロギング設定の不備、プロセスによるファイルハンドルの掴みっぱなし、パッケージキャッシュのクリア漏れ、EBSボリュームサイズ見積もりの誤り）の隠蔽につながります。

  • L1（物理・ボリューム・インデックス層）: df -h および df -i によるディスク・i-node枯渇率とファイルシステム種別（XFS/ext4）の検証
  • L2（ファイルツリー構造層）: -x オプションを付与した du や find による、巨大ファイル・Amazon Linux特有キャッシュ（DNF/YUM/AWS Agent）の特定
  • L3（カーネル・プロセス層）: lsof +L1 による「削除済みだが解放されない領域」の検出と、dmesg によるNVMe/EBSのI/Oエラーログ解析

OSネイティブの解析コマンドとAmazon Linux固有の仕組みを整理して組み合わせることで、再現可能で根拠のあるストレージ障害解析が可能になります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?