八回目の投稿です。今回の内容は、参画先の案件で発生した障害について紹介します。

障害発生時の暫定対応から障害回避のための恒久対応までを経験するだけでなく、

参画前に学んだLinuxの基礎知識を活かす機会となりました。Linux関連の案件に参画

予定の方にとって、本投稿が参考になれば幸いです。

※ 発生した障害とその対応内容は、実際のものとは少し異なります

◆ 障害内容

まずは障害内容の概要について説明します。

参画先の案件では、電子帳票関連のサービスを提供するために、様々なサーバが稼働

しています。ある日、それらのサーバを監視するサーバから「サーバA（OSはRHEL）の

/領域の使用率が90%を超えた」といった内容のアラートが発報されました。ディスク

使用率に関するアラートは、ディスク使用率が100%となることを防ぐため、特定の

閾値を超えると発報されるようになっています（100%に到達すると、サーバが使用

不可となり、リストアが必要となる）。

アラート発報後、監視サーバにインストールしてあるリソース監視ソフトにて、サーバ

Aのディスク使用率を確認しました。すると、ディスク使用率が依然として増え続けて

いることが分かり、早急に対応を行うこととなりました。

◆ 事前知識

対応方法について説明する前に、Linux関連のコマンドについて補足しておきます。

【コマンドの概要】

今回用いる主要なコマンドについて説明します。

・du

 どのファイルやディレクトリがどれだけディスクを使用しているのかを確認する

 ためのコマンドです。dfコマンドとともに、運用保守ではよく使われるコマンド

 だと思います。

 代表的なオプションは次の通りです。

 ・-a: ファイルのディスク使用率も表示します。このオプションを付けない場合は、

     ディレクトリのディスク使用率のみ表示されます。

 ・-h: ディスク使用率の可読性を高めるためのオプションです。K（キロ）、

     M（メガ）、G（ギガ）といった接頭語を付けた数値で表示されます。

・sort

 ファイルの中身を行単位で並べ替えるコマンドです。今回は、duの結果を並べ替える

 ために使用します。代表的なオプションは次の通りです。

 ・-h: 接頭語を付けた数値で並び替えるためのオプションです。

 ・-r: 降順で並び替えるためのオプションです。

【コマンドの使用例】

概要だけでは分かりづらいため、実際の使用例も説明します。

4つのファイルがあるディレクトリ「/home/parallels/test」にて、duコマンドを

実行した例です。

$  du /home/parallels/test

/home/parallels/testの総容量が22,532バイトであることが分かります。

オプションを付けた場合も確認してみます。

$ du -ah /home/parallels/test

ディレクトリの総容量だけでなく、各ファイルのファイルサイズも読みやすい表記で

確認できます。さらに表示を見やすくするため、並べ替えも行ってみます。

$ du -ah /home/parallels/test/ | sort -hr

結果を降順に並べ替えることができました。この結果から、fileDが最も使用率を占めて

いるファイルであることがすぐに分かります。なお、sortコマンドのオプションからhを

抜くと、使用量単位での降順にならないことも確認できます。

$ du -ah /home/parallels/test/ | sort -r

より詳細な内容については、参考1が分かりやすいです。

◆ 暫定対応

それでは、障害発生時の対応について紹介します。

監視ソフトにて/領域の使用率が急増していることは分かりましたが、具体的な要因

（どのディレクトリの容量が急増しているかなど）は、サーバAにログインして確認

する必要があります。サーバAにログイン後、duコマンドにてディレクトリやファイルの

使用率を確認しました。

# du -ah / | sort -hr

このコマンドを何度か実行し、その結果を比較してみると、/var/log/audit/audit.logの

ファイルサイズに違いが見られ、「audit.log」が急増していることが分かりました。

※ /と/varでパーティションを分割していない

audit.logは、RHELにおける監査ログのことで、どのユーザがどのコマンドを実行した

のかといった情報が記載されます。このファイルを確認すると、あるユーザが大量の

コマンドを実行していることが分かり、それによりaudit.logのファイルサイズ急増に

繋がっているようでした。幸いにもそのユーザとはすぐに連絡がつき、該当のコマンドの

実行を中断することで、ファイルサイズ増加を止めることができました。

◆ 発生原因

audit.logはファイルサイズが大きくなることがあるため、サーバAではそのファイル

サイズの上限を定め、上限を超える場合はローテート（自動的に古いログを消去）

するといった設定となっていました。具体的には、1ファイルの上限は64MBで、

ファイル数が99を超えるとローテートされるようになっており、その合計サイズは

最大でも64MB×99≒6.3GB程度に収まるはずでした（そのため、audit.logにいくら

ログが記録されようと、ディスク逼迫には繋がらない想定だった）。ところが、

運用が進むにつれ、サーバAの/領域に様々な資材が保存されていき、気が付けば

ローテート用のバッファ6.3GBがなくなっていたというわけでした。

ディスクの空き容量が少なくなったときはログ収集を中止するといった設定はされて

いたため、ログが増加してもディスク使用率が100%になることはありません。しかし、

中止したからといって、急増したログが減るわけではないため、依然としてディスクが

逼迫された状態が続くことになります。

◆ 恒久対応

/領域に保存された資材を整理して、6.3GBの空き領域を捻出できれば本事象は解決

します。しかし、資材を整理するためにかかる工数や、今後も同様の事象が発生し

うることを考慮し、最終的には次の方法で対応することになりました。

・audit.logの出力先を/領域から/data領域に変更する

サーバAには、ディレクトリ/dataが/とは別のパーティションに割り当てられており、

ここは十分な空き容量が確保されています。audit.logに関する設定ファイル

（/etc/audit/auditd.conf）を編集することで、十分な空き容量のある/data領域に

ログが出力されるよう設定します。具体的な設定手順は次のとおりです。

①作業準備

auditd.confのバックアップを取得します。

$ sudo -s

# id

# mkdir -p /home/parallels/work_$(date '+%Y%m%d')

# cp -pi /etc/audit/auditd.conf /home/parallels/work_$(date '+%Y%m%d')/auditd.conf.bk

# ls -la /etc/audit/auditd.conf

# ls -la /home/parallels/work_$(date '+%Y%m%d')/auditd.conf.bk

# diff /etc/audit/auditd.conf /home/parallels/work_$(date '+%Y%m%d')/auditd.conf.bk

②出力先ディレクトリの作成

新しい出力先を別パーティションに作成します。

必要に応じて各ディレクトリのパーミッションを適切なものに変更します

（例：/data/log/auditはrootユーザのみアクセス可能など）。

# ls -ld /var/log/audit

# mkdir -p /data/log/audit

# ls -ld /data/log/audit

③設定ファイルの編集

出力先の変更に際しては、/etc/audit/auditd.confのパラメータ「log_file」を編集

します（参考2）。log_fileの値を、②で作成したディレクトリに書き換えます。

# grep log_file /etc/audit/auditd.conf

# vi /etc/audit/auditd.conf

# grep log_file /etc/audit/auditd.conf

# ls -la /etc/audit/auditd.conf

# ls -la /home/parallels/work_$(date '+%Y%m%d')/auditd.conf.bk

# diff /etc/audit/auditd.conf /home/parallels/work_$(date '+%Y%m%d')/auditd.conf.bk

④設定の反映

audit.logにログを記入するauditdデーモンに対し、③で編集したauditd.confファイルを

読み込ませます（参考3）。設定反映前後でデーモンの状態を表示させ、エラーが出て

いないことも確認しています。サーバを再起動させることなく気軽に設定できますが、

SELinuxが有効である場合はエラーが出る可能性があります。

※ エラーが出たからといって、安易にSELinuxを無効化しない

# service auditd status

# service auditd reload

# service auditd status

reloadした際に「No change」や「No rules」と出ていますが、今回は気にしなくても

構いません。

⑤ログ出力の確認

auditd.confファイルの読み込み後、タイムスタンプを比較してみます。

sudoコマンドなどを実行すると、監査ログが/data/log/aduit/audit.logに出力される

ようになったことが確認できます。

# ls -l /var/log/audit/audit.log

# ls -l /data/log/aduit/audit.log

なお、ログ管理ツールなどでaudit.logを収集している場合は、出力先変更後も正しく

収集されるように設定することを忘れないようにしましょう。

◆ 感想など

運用が長期的なものになれば、こういった障害が起こりうるということが分かりました。

また、恒久対応の調査や検証、設定だけでなく、一連の内容を顧客に説明するなど、

幅広く経験を積むことができて良かったです。

◆ 参考

・【参考1】https://zenn.dev/supersatton/articles/a2a3e1fb994e69

・【参考2】https://www.usupi.org/sysad/222.html

・【参考3】https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/sec-starting_the_audit_service

以上です。