https://rheb.hatenablog.com/entry/2025/12/02/122914

Red Hatの森若です。

サポートへのお問いあわせを受けていると、実際にトラブルが起きたあとで「そもそも調査に必要な情報が取得されていなかった」「取得されたログやcoredumpなどが消えていた」というケースに遭遇することがあります。

今日はRHEL構築時にやっておくべき、トラブルシュートのための準備をまとめます。

sosreport 取得

sosreportはRHELのサポートをうける際に必須です。インストーラでMinimal Install等を選ぶとsosパッケージが入っていない場合があります。

sosパッケージを導入
- dnf install sos でsosパッケージを導入します
sosreportが取得できることを確認
- LANG=en_US.utf8 sos report --batch を実行して/var/tmpにsosreportのアーカイブが作成されることを確認します
- 負荷の確認: sosreport取得時の CPUやI/Oへの負荷がサービス要件に対して許容範囲内かを確認します。
- セキュリティ規定などで情報を隠すことが必要な場合は sos clean によるホスト名やIPなどのマスクの実施、マスクが十分かの確認なども行います。 ※マスクにより利用できる情報が減り調査の難易度が上がりますので、可能であれば生のsosreport利用が望ましいです。
運用手順へのsosreport取得組み込み
- 問題解消後ではなく、問題発生中に sosreportを収集することで調査に有用な情報が収集できます。
- 問いあわせ時にsosreportを最初から添付することで実質的な調査開始が早くなります。

基本的なパッケージの導入

トラブルシュートに利用される主なソフトウェアをあらかじめインストールしておきます。必要なものは利用ソフトウェアにより変わりますが、どこでも必要となりうるものとしては以下があげられます。
- sysstat: 10分おきの統計情報保存
- lsof: どのプロセスがどのファイルを利用しているかを確認
- net-tools: ネットワークの情報取得
- strace: システムコール呼び出しを記録
- tcpdump: パケットキャプチャの取得
- gdb: gcoreコマンドで実行中プロセスのcoredumpを取得
- bind-utils: digコマンドによるDNS調査

kdump動作確認

カーネルパニックやハングアップ時にメモリ内容を保全するkdumpを設定します。

kdumpの有効化とテスト
- 表記は英語ですが Kdump Helper を利用すると簡単に設定できます。
- NMIスイッチ押下により任意の時点でダンプを取得できることを確認します。注意: echo c > /proc/sysrq-trigger のようなコマンドによる取得は実際の障害時に利用できない場合があります
- 「NMIスイッチ押下」はハードウェアや仮想化環境によりどのように実施するかが変わります。これらの手順をあらかじめ確認しておくことも大切です。
VMware環境であればkdumpのかわりに、スナップショットを取得することが可能です。 How to capture a vmcore of hung Red Hat Enterprise Linux VMware guest system with a snapshot or suspending VM

ログの設定

journalの永続化設定
- mkdir /var/log/journal && journalctl --flush で永続化します
- RHEL 7以降でシャットダウン処理をログへ記録するために必要な設定です
プログラムが異常終了したらcoredumpを保存するよう設定をおこなう。
- RHEL 7, 8, 9.0から9.4のデフォルトではプロセスが異常終了しても、coredumpが保存されません。設定手順: How do I use systemd-coredump to collect crashing application core files?
- RHEL 9.5, 10.0以降はデフォルトでcoredumpを保存します。
/etc/systemd/coredump.conf の設定を変更
- プロセスのメモリサイズが大きい場合、デフォルトではcoredumpを取得しない場合があります。
- 保存することが重要な場合ProcessSizeMaxとExternalSizeMaxに実際のメモリ総量を上限として設定します。(反対に少なくするのは、coredump取得によるストレージI/O発生を抑制したい場合。)
- 複数回coredumpが発生したときにcoredumpが利用していいストレージサイズの上限をMaxUseに設定します。
```
     ※(メモリ128GB, ストレージは500GBまで使っていい場合の例)
 ProcessSizeMax=128G
 ExternalSizeMax=128G
 MaxUse=500G
```
coredumpの保存期間を延長
- RHEL 9.4までのデフォルトの保存期間は3日です。 RHEL 9.5からは14日になりました。
- 障害発生から、実際に解析するまで最大どれくらいの期間が想定されるかにもとづいて十分長い期間に変更します。
- 変更手順: Why coredump gets deleted in RHEL 8/9 in 3 days?

その他

パッケージの追加・更新手順を決めておく。
- パッケージ更新をして問題が再現するかにより既知の問題か、未知の問題かを切り分けるため必要です。

おわりに

トラブルは起きないのが一番ですが、起きてしまった時に「何も情報がない」状態では調査や解決は見込めません。システム構築時のチェックリストとして、これらの設定をぜひ組み込んでみてください。