DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Linuxシステムトラブルシューティングのための高度なログ分析

journalctl、dmesg、認証ログ、監査ツールを使用して、サービス、起動、セキュリティイベントにわたるLinuxの障害を追跡します。

Linuxシステムトラブルシューティングのための高度なログ分析

システムログは、Linuxサービスが失敗したとき、起動が停止したとき、またはサーバーのメモリが不足したときに何が起こったかを教えてくれます。難しいのは、ノイズを素早く切り抜けて有用な行を見つけることです。

このガイドは、基本的なファイル検査（cat /var/log/messages）を超えて、journalctl、dmesg、およびセキュリティ監査ログを一緒に使用する方法を示します。

1. 統合ジャーナルの習得（systemd-journald）

systemdを利用する最新のLinuxディストリビューションは、systemd-journaldを介してログを一元化し、構造化されたインデックス付きバイナリ形式でログを保存します。このデータにアクセスするための主要なツールはjournalctlです。

1.1 時間と起動によるフィルタリング

高度なトラブルシューティングでは、多くの場合、特定の時間枠や起動サイクルにイベントを分離する必要があります。-b（起動）フラグと-S/-U（開始/終了）フラグが不可欠です。

コマンド 目的 使用例
journalctl -b 現在の起動のみのログを表示します。 最後の再起動以降に発生した問題を分析します。
journalctl -b -1 前回の起動のログを表示します。 散発的な起動障害を診断します。
journalctl -S "2 hours ago" 特定の時間または期間から始まるログを表示します。 サービスがクラッシュする直前のアクティビティを確認します。
journalctl --since "YYYY-MM-DD HH:MM:SS" 正確なタイムスタンプから始まるログを表示します。 システムログを外部監視データと関連付けます。

1.2 メタデータによるフィルタリング

ジャーナルの構造化された性質により、正確なメタデータフィールドに基づいたフィルタリングが可能になり、無関係なデータをすばやく切り抜けることができます。

# SSHサービスのログを特にフィルタリング
journalctl -u sshd.service

# カーネルからのログをフィルタリング（優先度0-7）
journalctl -k

# 優先度でログをフィルタリング（例：重大なエラー以上）
# 0=emerg, 1=alert, 2=crit, 3=err
journalctl -p 0..3 -S yesterday

# 特定のプロセスID（PID）でログをフィルタリング
journalctl _PID=1234

ヒント：永続ジャーナル： システムが再起動間でログを保持しない場合は、ジャーナルディレクトリを作成して永続ログを有効にします：sudo mkdir -p /var/log/journal そして正しいパーミッションを確保します。これは起動関連の問題を診断するために重要です。

2. dmesgとjournalctlを使用したカーネルメッセージ分析

カーネルメッセージは、低レベルのハードウェア問題、ドライバ障害、およびオペレーティングシステムのパニックを診断するために重要です。dmesgはカーネルリングバッファの生のスナップショットを提供しますが、journalctlはこれらのメッセージをタイムスタンプと完全なコンテキストと統合します。

2.1 即時ハードウェア検査のためのdmesgの使用

dmesgは高速で、ジャーナルが十分に早く起動しない場合に見逃されることが多い初期化メッセージを反映します。主にハードウェア初期化エラーを見つけるのに役立ちます。

# 一般的な障害キーワードでdmesg出力をフィルタリング（大文字小文字を区別しない）
dmesg | grep -i 'fail\|error\|oops'

# 特定のハードウェアに関連するメッセージを確認（例：ディスク）
dmesg | grep sd

2.2 OOMキラーの特定

リソース不足、特にメモリ枯渇は、カーネルによってOut-Of-Memory（OOM）キラーが呼び出される原因となります。このプロセスは、メモリを解放するためにアプリケーションを選択的に終了します。このイベントを特定することは、メモリのトラブルシューティングに不可欠です。

カーネルログでoom-killerまたはkilled processを含むメッセージを探します：

# 現在の起動ジャーナルでOOMイベントを検索
journalctl -b -k | grep -i 'oom-killer\|killed process'

関連するログエントリには、どのプロセスが強制終了されたか、そのメモリフットプリント、およびその時点のシステムの合計メモリ使用量が詳細に記載されます。

3. アプリケーションとサービスログの詳細分析

特定のサービスが失敗した場合、ログ分析は依存関係と関連するアプリケーションエラーの追跡に移行する必要があります。

3.1 サービスのステータスとログの関連付け

サービス障害のトラブルシューティングは、常にそのステータスを確認することから始めます。これにより、終了コードとエラーに関するヒントが得られることがよくあります。

# Webサーバーサービスのステータスを確認
systemctl status apache2.service

# すぐにサービスのログを表示
journalctl -u apache2.service --no-pager

ゼロ以外の終了コード、セグメンテーションフォールト、またはリソース制限違反（例：ファイル記述子制限）を示すメッセージを探します。

3.2 従来のログファイルの調査

systemdはほとんどのログを処理しますが、一部のレガシーアプリケーションやサービス（特にPostgreSQLやMySQLなどのデータベース）は、依然として大量のログを直接/var/logに書き込みます。

一般的な場所とその目的：

  • /var/log/messages または /var/log/syslog：ディストリビューションに応じた一般的なシステムアクティビティ。
  • /var/log/dmesg：カーネルリングバッファの静的コピー（保存されている場合）。
  • /var/log/httpd/error_log：Apache/Nginx固有のアプリケーションエラー。
  • /var/log/faillog：失敗したログイン試行を記録します。

これらのファイルのリアルタイム監視とフィルタリングには、grep、awk、tailなどの強力なテキスト操作ツールを使用します：

# エラーを再現しながらログファイルをリアルタイムで監視
tail -f /var/log/application/database.log | grep -i 'fatal\|timeout'

4. セキュリティと監査ログの分析

セキュリティログは、認証試行、権限エラー、設定変更に関する可視性を提供します。これは、アクセス制御の問題や侵入試行の診断に重要です。

4.1 認証ログ（auth.log/secure）

Debian/Ubuntuでは、これらのログは/var/log/auth.logにあります。RHEL/CentOSでは、通常/var/log/secureにあります（またはジャーナルを介してクエリ可能）。

繰り返される接続障害や不正な試行を探します。これは多くの場合、次のように示されます：

# 失敗したSSHログイン試行を表示
grep 'Failed password' /var/log/secure

# 不正な権限昇格のためのsudo使用状況を分析
grep 'COMMAND=' /var/log/auth.log

4.2 Linux監査システム（Auditd）

ファイルアクセス、システムコール、設定変更の包括的な追跡が必要な環境では、Linux監査システム（auditd）が不可欠です。分析は通常、ausearchツールを使用して実行されます。

# ファイルアクセス拒否に関連するイベントを検索
ausearch -m AVC,USER_AVC,DENIED -ts yesterday

# 特定のユーザー（UID 1000）によって実行されたすべてのシステムコールを検索
ausearch -ua 1000

5. 実践的なトラブルシューティングシナリオ

効果的なログ分析には、観察された症状に基づいてどこを見るべきかを知ることが含まれます。

シナリオ1：起動中のファイルシステムマウント障害

システムが緊急モードで起動した場合、問題はほとんどの場合、起動初期のメッセージに記録されています。

  1. アクション： システムを再起動します。
  2. 分析ツール： journalctl -b -k（失敗した起動のカーネルログに焦点を当てます）。
  3. キーワード： ext4 error、superblock、mount error、dependency failed。
  4. 根本原因の手がかり： /dev/sdb1の明示的なエラーコードまたは/etc/fstabの欠落したUUIDに言及している行。

シナリオ2：断続的な高負荷とサービス低下

パフォーマンスが断続的に低下する場合、原因はリソースの競合またはメモリリークである可能性があります。

  1. アクション： 低下が発生した時間を特定します。
  2. 分析ツール： journalctl --since "10 minutes before event" -p warning..crit。
  3. キーワード： oom-killer、cgroup limit、CPU limit reached、deadlock。
  4. 根本原因の手がかり： OOMキラーが見つからない場合は、個々の高リソースサービスのログをフィルタリングして、繰り返し発生する内部エラー（例：データベース接続タイムアウトや過剰なログ出力）を確認します。

まとめ：繰り返し可能なログワークフローを構築する

高度なログ分析は、毎回同じパスをたどるときに最も効果的です：

  1. フィルタリングを標準化する： journalctlコマンドを学習して標準化し、起動、サービス、時間範囲をすばやく分離します。
  2. ログを一元化する： 複雑な環境には、一元化されたログソリューション（例：ELK Stack、Splunk、Graylog）を実装します。これにより、複数のサーバー間でのログの関連付けが可能になり、分散アプリケーションのトラブルシューティングに重要です。
  3. 優先度を理解する： 重大度レベル（emerg、alert、crit、err、warning、notice、info、debug）を理解し、緊急時にルーチンのinfoメッセージを無視するために-pフラグを活用します。
  4. 同期を維持する： NTPを介してすべてのシステムクロックが同期されていることを確認します。同期されていないクロックでは、システム間のログを関連付けることがほぼ不可能になります。