DAY 03: ログ捜査官

はじめに

LabEx Corporation での 3 日目、プロジェクト・フェニックスに災難が降りかかりました！オフィスに到着すると、サラ・チェンと開発チームが危機的な状況に陥っているのを目の当たりにします。昨日あなたが整理を手伝ったアプリケーションが、最初の主要なテストフェーズで重大なエラーに遭遇したのです。

監視システムには緊急アラートが溢れ、ユーザーからはアプリケーションの不具合が報告され、デプロイパイプラインは完全に停止してしまいました。サラは必死の形相であなたに歩み寄ります。シニア DevOps エンジニアは病欠で、プロジェクトの締め切りは刻一刻と迫っています。

「この件には、最高の捜査官が必要なの」と、サラはインシデントレポートをあなたに手渡しながら言いました。「昨日のファイル整理で見せてくれた、あなたの体系的なアプローチこそが今必要なのよ。その論理的な思考で、この謎を解明してほしいの」

あなたの任務は、プロジェクト・フェニックスのサーバーを深く調査し、ログや設定ファイルを分析して、これらの一連の障害の根本原因を突き止めることです。高度な Linux コマンドラインツールを駆使して手がかりを繋ぎ合わせ、チームが心血を注いで構築してきたアプリケーションの安定性を取り戻してください。プロジェクト・フェニックスの未来、そしておそらく TechNova でのあなたのキャリアは、あなたの探偵としての腕にかかっています！

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

捜査官としての最初のステップは、プロジェクト・フェニックスのアプリケーションログファイルを確認することです。アプリケーションはログを ~/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).

ファイルには、タイムスタンプで始まり "ERROR" という単語を含む行が正確に 2 行含まれている必要があります。

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

アプリケーションのエラーは、より深刻なハードウェアやカーネルレベルの問題の兆候かもしれません。そのような問題を探すのに適した場所は、システムの起動プロセスやドライバの動作に関するメッセージが含まれているカーネルリングバッファ（kernel ring buffer）です。

タスク

• システムのカーネルメッセージを調べ、fail または error に関連する行を探してください。
• 見つかった内容を ~/project/boot_issues.txt という名前のファイルに保存してください。

要件

• カーネルメッセージを表示するには dmesg コマンドを使用すること。
• fail または error の検索は、大文字と小文字を区別しない（case-insensitive）こと。
• 結果は ~/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;

ファイルには、元のエラー2 行に加えて "worker_processes 4;" という新しい行の、計 3 行が含まれている必要があります。

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

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

タスク

• ステージング環境の設定ファイル ~/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 ファイルには 2 つの環境間の差異が表示されるはずです：

$ 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 つのディレクトリを比較して、この状況をシミュレートしてみましょう。

タスク

• 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 コマンドは、ファイルパスの代わりにディレクトリパスを指定すれば、ディレクトリの比較も可能です。
• ディレクトリを比較する際は、-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 が最初のディレクトリ（ステージングサーバーを表す server1_files）には存在するが、2 番目のディレクトリ（本番サーバーを表す server2_files）には存在しないことを示しています。ステージングを先に、本番を後に比較することで、本番環境に不足しているファイルを簡単に特定でき、これがアプリケーション障害の原因である可能性が浮上します。

まとめ

素晴らしい捜査能力です！プロジェクト・フェニックスの重大な障害の根本原因を特定し、サラ・チェンと開発チームに問題を解決するための実用的な情報を提供することができました。

体系的な調査を通じて、以下の不可欠なトラブルシューティングコマンドをマスターしました：

• grep: ログファイルをフィルタリングし、重要なエラー情報を抽出する。
• dmesg: システムレベルのハードウェアやカーネルの問題を調査する。
• diff: 設定ファイルを比較し、環境間の不一致を特定する。
• コマンドパイプラインとリダイレクト：調査結果を効率的に処理し、文書化する。

あなたの論理的なログ分析アプローチにより、プロジェクト・フェニックスは壊滅的な失敗から救われました。開発チームは、あなたが発見した設定の不一致やデプロイファイルの欠落を修正するための明確な指針を得ることができました。

サラ・チェンはあなたの調査スキルに非常に感銘を受け、あなたをセキュリティ担当に推薦しています。明日は「要塞の守護者」として、プロジェクト・フェニックスのインフラを保護し、将来の脅威から守る任務に就くことになります！