Linux ログ分析：アプリケーションとシステムファイルを調査する

はじめに

LabEx Corporation での 3 日目、Project Phoenix に大きな障害が発生しました。オフィスに到着すると、Sarah Chen と開発チームが危機対応に追われています。昨日あなたが整理したアプリケーションは、初めての本格的なテスト中に重大なエラーを起こしました。

監視システムには緊急アラートが次々と届き、ユーザーからはアプリケーションの障害が報告され、デプロイパイプラインも停止しています。Sarah は困り果てた表情であなたを見ています。シニア DevOps エンジニアは病欠中で、プロジェクトの期限も迫っています。

「この件は、私たちの中で最も優秀な調査担当者に任せる必要があります」と Sarah はインシデントレポートを渡しながら言いました。「昨日、ファイルを整理してくれた体系的なアプローチが、まさに必要なものでした。今度は、その几帳面な思考力でこの謎を解決してください」

あなたの任務は、Project Phoenix のサーバーを詳しく調査し、ログと設定ファイルを分析して、障害の根本原因を突き止めることです。高度な Linux コマンドラインツールを使って手がかりを整理し、チームが懸命に開発してきたアプリケーションを安定した状態に戻します。Project Phoenix の未来、そして TechNova でのあなたのキャリアが、あなたの調査力にかかっています。

アプリケーションログファイルの内容を確認する

調査の最初のステップとして、Project Phoenix のアプリケーションログファイルを確認します。アプリケーションのログは ~/project/logs/app.log に書き込まれています。大量のメッセージを一つずつ確認するのは大変なので、重要なエラーメッセージをすばやく見つけて、昨日あなたが整理したシステムで何が起きているのかを把握します。

タスク

~/project/logs/app.log ファイルから、ERROR という単語を含むすべての行を抽出します。
抽出した行を ~/project/error_report.txt という新しいファイルに保存します。

要件

ファイルの検索にはコマンドラインツールを使用してください。
検索対象の入力ファイルは ~/project/logs/app.log です。
出力は ~/project ディレクトリ内の ~/project/error_report.txt というファイルに保存してください。
出力ファイルには、ERROR という単語を含む行だけを保存してください。

ヒント

grep コマンドは、テキストファイル内のパターン検索に適しています。
コマンドの出力をファイルに保存するには、> リダイレクト演算子を使用します。対象ファイルが存在しない場合は作成され、存在する場合は上書きされます。

例

ログファイルの抽出に成功すると、~/project/error_report.txt にはエラー行だけが含まれます。

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).

ファイルには合計 2 行だけが含まれ、どちらもタイムスタンプで始まり、ERROR という単語を含みます。

システムのブートメッセージを調査する

アプリケーションのエラーは、より深刻なハードウェアまたはカーネルレベルの問題の兆候かもしれません。このような問題を調べるには、カーネルリングバッファが適しています。ここには、システムのブート処理やドライバーの動作に関するメッセージが保存されています。

タスク

システムのカーネルメッセージから、fail または error に関連する行を確認します。
調査結果を ~/project/boot_issues.txt というファイルに保存します。

要件

カーネルメッセージの表示には dmesg コマンドを使用してください。
fail または error の検索では、大文字と小文字を区別しないでください。
結果は ~/project/boot_issues.txt というファイルに保存してください。
注：カーネルメッセージにアクセスするには、管理者権限（sudo）が必要になる場合があります。

ヒント

dmesg コマンドはカーネルメッセージを表示します。出力を別のコマンドに「パイプ」して絞り込めます。
パイプ演算子 | は、あるコマンドの出力を別のコマンドの入力として渡します。
grep の -i オプションを使用すると、大文字と小文字を区別せずに検索できます。
fail または error のように複数のパターンを一度に検索するには、grep -E 'pattern1|pattern2' を使用します。
注：「Operation not permitted」エラーが表示された場合は、必要な権限を得るために sudo を付けてコマンドを実行してください。

例

カーネルメッセージの抽出に成功すると、~/project/boot_issues.txt には関連するシステムメッセージが含まれます。

$ cat ~/project/boot_issues.txt
[    0.330755] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[    1.026520] RAS: Correctable Errors collector initialized.
[   28.260800] kernel: [   10.123456] my-driver: probe of 0000:00:1f.0 failed with error -2

ファイルには、fail または error を含むカーネルメッセージが、大文字と小文字を区別せずに保存されます。これらのメッセージは、システムのブート中に発生した可能性のあるハードウェアまたはドライバーの問題を示します。

Web サーバー設定ファイルを確認する

重大なハードウェア問題は見つかりませんでした。問題は Web サーバーの設定にあるかもしれません。Nginx の設定ファイルを調べて、どのように設定されているかを確認します。ワーカープロセスの数が少なすぎるといった設定ミスは、パフォーマンスのボトルネックを引き起こし、高負荷時にアプリケーション障害につながることがあります。

タスク

~/project/config/nginx.conf にある Web サーバー設定ファイルを検索します。
worker_processes ディレクティブを含む行を見つけます。
その行を、最初のステップで作成した ~/project/error_report.txt ファイルに追記します。

要件

入力ファイルは ~/project/config/nginx.conf です。
結果は ~/project/error_report.txt に追記してください。ファイルを上書きしてはいけません。

ヒント

このタスクでも grep を使用できます。
出力を上書きせずにファイルへ追記するには、>> 演算子を使用します。

例

worker_processes の行を既存のエラーレポートに追記すると、~/project/error_report.txt には元のエラー行と新しい設定行の両方が含まれます。

$ cat ~/project/error_report.txt
[2023-10-26 10:00:03] ERROR: Failed to process payment transaction #12345.
[2023-10-26 10:00:05] ERROR: NullPointerException at com.innovatech.Billing.process(Billing.java:101).
worker_processes 4;

ファイルは合計 3 行になります。元のエラー行 2 行と、worker_processes 4; の新しい行 1 行です。

ステージング環境と本番環境の設定ファイルを比較する

本番環境で問題が発生する一般的な原因は、ステージング環境と本番環境の間にある差異です。ステージングでは正常に動作する機能が、わずかな設定の違いによって本番環境では失敗することがあります。両環境のアプリケーション設定ファイルを比較して、違いを見つけましょう。

タスク

ステージング環境の設定ファイル ~/project/config/staging/app.conf と、本番環境の設定ファイル ~/project/config/production/app.conf を比較します。
差分を ~/project/config_diff.txt という新しいファイルに保存します。

要件

diff コマンドを使用してください。
差分を示す出力は ~/project/config_diff.txt に保存してください。

ヒント

diff コマンドは、2 つのファイルを 1 行ずつ比較するためのコマンドです。
基本構文は diff file1 file2 です。file1 を file2 と同じ内容にするために必要な変更が表示されます。
ファイルの順序は重要です。diff A B と diff B A では異なる出力になります。
grep の場合と同じように、diff の出力もファイルへリダイレクトできます。

例

ステージング環境と本番環境の設定ファイルを比較すると、~/project/config_diff.txt には両環境の差分が表示されます。

$ cat ~/project/config_diff.txt
1,5c1,5
< ## Staging Configuration
< database.url=jdbc:mysql://staging-db:3306/nexus
< api.key=staging_key_abc123
< feature.flag.new_dashboard=true
< timeout.ms=3000
---
> ## Production Configuration
> database.url=jdbc:mysql://prod-db:3306/nexus
> api.key=prod_key_xyz789
> feature.flag.new_dashboard=false
> timeout.ms=5000

この diff 出力は、ステージング設定を本番設定と一致させるために必要な変更を示しています。< で始まる行はステージングファイルの内容、> で始まる行は本番ファイルの内容です。これにより、本番環境ではステージング環境と異なるデータベース URL、API キー、機能フラグ、タイムアウト値が使用されていることが分かります。

サーバー間のディレクトリの整合性を確認する

設定の差異は有力な手がかりです。本番サーバーには、ステージングサーバーに存在する重要なファイルが一部ない可能性もあります。デプロイに失敗したことが原因かもしれません。ここでは、異なるサーバーのファイル構成を表す 2 つのディレクトリを比較して、この状況を再現します。

タスク

2 つのディレクトリがあります。/home/labex/project/server1_files はステージングサーバー、/home/labex/project/server2_files は本番サーバーを表します。
2 つのディレクトリを比較し、server1_files にだけ存在するファイルを見つけます。
比較結果全体を /home/labex/project/missing_files.txt というファイルに保存します。

要件

2 つのディレクトリの比較には diff コマンドを使用してください。
出力は /home/labex/project/missing_files.txt に保存してください。

ヒント

diff は、ファイルパスの代わりにディレクトリパスを指定して、ディレクトリも比較できます。
diff の -r または --recursive オプションを使うと、ディレクトリ内のすべてのファイルを比較できるため便利です。
ディレクトリを比較した diff の出力には、特定のディレクトリにしか存在しないファイルが「Only in」と明示されます。
ファイルの場合と同様に、ディレクトリの順序も重要です。diff dir1 dir2 は dir1 にあり dir2 にないものを示し、diff dir2 dir1 はその逆を示します。

例

2 つのサーバーディレクトリを比較すると、/home/labex/project/missing_files.txt に本番サーバーにないファイルが表示されます。

$ cat /home/labex/project/missing_files.txt
Only in /home/labex/project/server1_files: asset2.js

この出力は、asset2.js が 1 つ目のディレクトリ（ステージングサーバーを表す server1_files）には存在するものの、2 つ目のディレクトリ（本番サーバーを表す server2_files）にはないことを示しています。ステージングを先、本番を後に指定することで、本番環境にないファイルを簡単に特定できます。これは、アプリケーション障害の原因の一つになっている可能性があります。

まとめ

見事な調査でした。Project Phoenix の重大な障害の根本原因を突き止め、Sarah Chen と開発チームが問題を解決するために利用できる具体的な情報を提供できました。

体系的な調査を通じて、次の基本的なトラブルシューティングコマンドを身につけました。

grep：ログファイルを絞り込み、重要なエラー情報を抽出するために使用します。
dmesg：システムレベルのハードウェアやカーネルの問題を調査するために使用します。
diff：設定ファイルを比較し、環境間の差異を特定するために使用します。
コマンドパイプラインとリダイレクト：調査結果を効率的に処理し、記録するために使用します。

あなたの几帳面なログ分析によって、Project Phoenix は壊滅的な障害を免れました。開発チームは、見つかった設定の不一致とデプロイファイルの不足を修正するための明確な方針を得ました。

Sarah Chen はあなたの調査能力に大きな感銘を受け、セキュリティ担当の仕事を推薦してくれることになりました。明日は Fortress Guardian として Project Phoenix のインフラを保護し、将来の脅威から守ることになります。

ログ調査官