Posted inCentos

CentOS Stream 9でのsosreport活用ガイド：プロフェッショナルなトラブルシューティングのためのシステム情報収集と分析

CentOS tutorial - IT technology blog
CentOS tutorial - IT technology blog

サーバーで障害が発生したとき、最初に何をしますか？

深夜2時にサーバーが落ちる。SSHで接続し、コマンドを一つずつ実行していく：journalctl、dmesg、netstat、df -h、top……それぞれ別のターミナルウィンドウを開き、テキストファイルにコピー＆ペーストして、同僚やサポートチームに送る。何度もやってきたが、毎回、一番必要な瞬間に何かが抜け落ちていた。

CentOS 8がEOLを迎えた際、1週間で5台のサーバーをRocky Linuxへ急いで移行しなければならなかった。そのうちの1台がreboot後にネットワークエラーを起こし、原因を突き止めるまでに2時間近く手動でログを収集し続けた。最終的な原因はmigration中にNetworkManagerのプロファイルが破損していたことだった。その経験があって初めてsosreportをちゃんと学び、それまでどれだけ時間を無駄にしていたかを思い知った。

システム情報を収集する3つの方法 — 本当の違いとは

方法1：コマンドを一つずつ手動実行する

誰もが最初はここから始める。自分でスクリプトを書いたり、必要に応じてコマンドを一つずつ実行したりする。

# 手動収集 — 時間がかかり、見落としが発生しやすい
journalctl -xe > /tmp/journal.log
dmesg > /tmp/dmesg.log
ip addr show > /tmp/network.log
df -h > /tmp/disk.log
cat /etc/os-release > /tmp/os.log
ss -tlnp > /tmp/ports.log
# ... 問題によってさらに数十のコマンドが必要になる

メリット：追加インストール不要、必要な情報だけ柔軟に取得できる、出力が軽量。

デメリット：思いつかなかった情報を見落としやすい、システムに問題がある状況で時間がかかる、出力が標準化されていないためベンダーやサポートチームとの共有が難しい。

方法2：sosreport — Red Hat公式ツール

sosreportはRed Hatの標準仕様に従い、全プロセスをコマンド一つにまとめる：

sudo sos report

メリット：プラグインで200種類以上の情報を収集、tarballファイルとして標準化された出力、Red Hatサポートにそのまま提出可能、Apache・Docker・KVM・Kubernetes専用プラグインも標準搭載。

デメリット：root権限が必要、実行に3〜10分かかる、出力ファイルが大きい（通常50〜200MB）、継続的なモニタリングには不向き。

方法3：モニタリングスタック（Prometheus、Datadogなど）

これは障害のデバッグツールではなく、問題が起きる前に積極的に警告するための仕組みだ。

メリット：視覚的なダッシュボード、自動アラート、時系列の履歴データ保存。

デメリット：詳細なログやシステム設定の収集には不向き、事前のセットアップが必要、特定の障害をデバッグする際に送付するためのツールではない。

メリット・デメリットを整理して、適切な方法を選ぶ

状況によって適切な方法は異なる。普段から参照している判断基準はこうだ：

  • 突発的な障害のデバッグ、Red Hatサポートやベンダーへの提出：sosreport — まさにこのユースケースのために設計されたツールだ。
  • 1〜2個のパラメータだけ素早く確認したい：手動コマンド — sosの実行を待たずに済み、より速い。
  • リアルタイムのパフォーマンス監視：モニタリングスタック（Prometheus + Grafana）。
  • 大きな変更前のシステム監査（migration、kernelアップデートなど）：sosreport — 前後比較のためのスナップショット作成に最適。
  • kernelや重要なパッケージ更新後のトラブルシューティング：sosreport — regressionを特定するのに十分なコンテキストが必要。

sosreportの本当の強みは、自分でも必要だと気づいていない情報まで収集してくれる点にある。先ほど触れたネットワーク障害のデバッグで原因を突き止めたのは、ip addrでもjournalctlでもなく、sosreportがtarballにそのままコピーしていた/etc/NetworkManager/system-connections/内の設定ファイルだった。

CentOS Stream 9へのsosreportの導入

ステップ1：インストール

CentOS Stream 9では、AppStreamリポジトリにsosが標準で含まれていることが多い：

sudo dnf install sos -y
sos --version
# sos version 4.x.x

ステップ2：基本的なsosreportの実行

sudo sos report

実行前に、ツールがいくつか質問してくる：

Please enter your first initial and last name [root]: hieu
Please enter the case id that you are generating this report for: CASE-2026-001

ケースIDがない場合（自分でトラブルシューティングする場合）は、Enterを押してスキップ。3〜5分後にファイルが生成される：

/var/tmp/sosreport-hostname-2026-06-20-xxxxxxx.tar.xz

ステップ3：必要な情報だけを収集するカスタマイズ

常にフルレポートが必要なわけではない。実用的なオプションをいくつか紹介する：

# 利用可能なプラグインの一覧を表示
sudo sos report --list-plugins

# ネットワークとカーネルの情報だけ収集する（大幅に速い）
sudo sos report --only-plugins networking,networkmanager,kernel,logs

# 不要で時間のかかるプラグインをスキップ
sudo sos report --skip-plugins rpm,yum,docker

# インタラクティブな質問なしで実行 — スクリプト内で使用
sudo sos report --batch --label "post-migration-$(hostname)"

# 出力ディレクトリを指定
sudo sos report --tmp-dir /data/sos-reports/

# 収集するログファイルのサイズ制限（MB）
sudo sos report --log-size 20

# 特定の時点以降のログのみ取得
sudo sos report --since "2026-06-19 00:00:00"

migration後のネットワーク問題をデバッグする際はよくこのコマンドを使う。フルレポートより速く、それでいて必要な情報は十分に揃っている：

sudo sos report \
  --only-plugins networking,networkmanager,firewalld,kernel,logs \
  --batch \
  --label "net-debug-$(hostname)-$(date +%Y%m%d)"

ステップ4：出力の分析

tarballファイルはきちんと整理されている。解凍すれば構造がすぐにわかる：

cd /var/tmp/
tar -xJf sosreport-*.tar.xz
ls -la sosreport-*/

典型的なディレクトリ構造：

sosreport-hostname-2026-06-20-xxxxxxx/
├── etc/                    # /etc の全内容がそのままコピーされている
│   ├── systemd/
│   ├── NetworkManager/
│   └── sysconfig/
├── var/log/                # Log files
│   ├── messages
│   └── audit/audit.log
├── proc/                   # 実行時点の /proc スナップショット
├── sos_commands/           # sosが実行した各コマンドの出力
│   ├── networking/
│   │   ├── ip_addr
│   │   ├── ip_route
│   │   └── ss_-tlnp
│   └── kernel/
│       ├── dmesg
│       └── uname
└── sos_logs/               # sos自体の実行ログ

解凍後に素早く情報を検索する：

# 収集時点のネットワーク状態
cat sosreport-*/sos_commands/networking/ip_addr

# messagesファイルからエラーを検索
grep -i "error\|failed\|critical" sosreport-*/var/log/messages | tail -50

# NetworkManager接続の設定を確認
ls sosreport-*/etc/NetworkManager/system-connections/

# OOM killerまたはkernel panicを検索
grep -r "Out of memory\|Killed process\|kernel panic" sosreport-*/var/log/

# ハードウェアとカーネルの情報を確認
cat sosreport-*/sos_commands/kernel/uname

ステップ5：sos collectで複数サーバーから一括収集

クラスターや複数のサーバーを管理している場合、sos collectを使えばSSH経由で一括収集できる：

sudo sos collect \
  --nodes web1,web2,web3,db1 \
  --ssh-user admin \
  --only-plugins networking,logs,kernel

インシデント対応フローへのスクリプト統合

このスクリプトは事前にチームでセットアップしておくことを推奨する。重大なインシデント発生時に即座に実行できる：

#!/bin/bash
# /usr/local/sbin/emergency-sos.sh

LABEL="incident-$(date +%Y%m%d-%H%M)"
OUTPUT_DIR="/data/sos-reports"

mkdir -p "$OUTPUT_DIR"
echo "[$(date)] sosreportを収集中: $LABEL"

sudo sos report \
  --batch \
  --label "$LABEL" \
  --tmp-dir "$OUTPUT_DIR" \
  --log-size 50 \
  2>&1 | tee "/var/log/sos-${LABEL}.log"

echo "[$(date)] 完了:"
ls -lh "$OUTPUT_DIR"/sosreport-*"$LABEL"* 2>/dev/null

CentOS 8からRocky Linuxへの移行時、各サーバーの前後でこのスクリプトを実行して比較用スナップショットを取得した。何時間もかかるデバッグから救ってくれたのは、複雑なツールではなく、必要なタイミングで十分な情報が手元にあったことだ。

よくあるエラーと対処法

sosreportの実行が遅すぎる、またはフリーズする

rpmプラグインはパッケージ数の多いサーバーでは特に遅く、単体で5〜10分かかる場合がある。不要ならスキップしよう：

sudo sos report --skip-plugins rpm,yum

# どのプラグインが実行中かデバッグで確認する
sudo sos report --debug 2>&1 | grep "Running plugin"

出力ファイルが大きすぎる

# ログサイズを制限してonly-pluginsを使用する
sudo sos report --log-size 10 --only-plugins networking,logs,kernel

一部の情報収集に必要な権限が不足している

# su - ではなく sudo を使う
sudo sos report        # 正しい方法
su -c "sos report"     # environmentが不足する場合がある。sudoが推奨

実践的なまとめ

sosreportはLinuxを理解することの代替ではない。問題を理解するために必要な情報を十分に収集できるようにしてくれるツールだ。30個のコマンドを実行して何か見落とさないかと心配する代わりに、sudo sos reportの一発で5分以内に必要なものが全て揃う。

得た教訓：sosreportは早めに実行すること。サービスをrestartしてから考え始めてはいけない。問題がまだそのままの状態でスナップショットを取ってこそ意味がある。rebootやrestartは多くのエラー状態を消してしまい、真の原因を永遠に見つけられなくなる。

Share:
Tags: