Linuxトラブルシューティングの全体像｜障害対応・原因調査の基本を徹底解説

はじめに

Linuxサーバを運用していると、「アプリケーションが遅い」「サービスが起動しない」「通信できない」「サーバが突然再起動した」といったさまざまなトラブルに遭遇します。

原因はCPUやメモリなどのリソース不足だけとは限りません。OSやミドルウェアの設定、権限、アプリケーションの処理、ネットワーク、外部サービス、仮想基盤など、さまざまなレイヤーに原因が存在する可能性があります。

障害対応で重要なのは、限られた時間の中で事象を整理し、「どこに問題がありそうか」という仮説を立てながら調査範囲を絞り込むことです。

たとえば、アプリケーションの応答が遅いからといって、すぐにCPUが原因とは限りません。Memory不足、Disk I/Oの遅延、Networkの問題、Databaseや外部APIの応答遅延なども考えられます。

そのため、「とりあえずtopを見る」「とりあえずログを大量に取得する」といった調査ではなく、事象から原因候補を考え、必要な情報を確認しながら一つずつ切り分けていくことが重要です。

また、商用システムの障害対応では、原因調査だけでなく、サービスを迅速に復旧させることも求められます。状況によっては、原因を完全に特定する前に暫定復旧を行い、その後に収集したエビデンスから根本原因を調査することもあります。

本記事では、Linuxトラブルシューティングの全体像を、「影響範囲の確認 → エビデンス収集 → 仮説検証・原因特定 → 暫定対処・復旧確認 → 恒久対処」の5段階に整理します。

個々のコマンドの詳細ではなく、「障害が発生したとき、どこから調べて、次に何を確認するのか」という調査の考え方を中心に解説します。

Linuxトラブルシューティングで明らかにすること

トラブルシューティングは、異常な数値、ログを探すだけの作業ではありません。利用者に起きている問題と、システム内部の状態を結び付け、どこへ対処すれば改善するかを判断する作業です。調査では、次の三つを分けて考えます。

観点	確認する内容	例
事象	利用者や業務に何が起きているか	注文APIがタイムアウトする
発生箇所	どの処理やリソースで問題が起きているか	APIのワーカーがDB応答を待っている
原因	なぜその状態になったか	特定のSQLが長時間ロックを保持している

「CPU使用率が高い」「メモリが少ない」は、原因を考える材料です。その値だけでは、業務の遅延を引き起こしているのか、別の問題の結果として増えているのかはわかりません。発生時刻と処理の関係を調べ、事象を説明できるかを確かめます。

また、復旧と原因特定は別の目的です。復旧は利用者への影響を解消すること、原因特定は障害が起きた仕組みを説明することです。業務影響が大きい場合は、詳細な解析を完了する前に復旧作業を行うこともあります。その場合も、操作前に短時間で残せるエビデンスを保存し、復旧後の調査につなげます。

Linuxサーバのどこを調べるか

Linuxサーバの障害は、一つの層だけで完結するとは限りません。アプリケーションが処理を行う際には、プロセスやスレッドが動き、OSを通じてCPU、メモリ、ストレージ、ネットワークを使います。さらに、DBや外部API、仮想基盤の状態にも影響されます。

調査対象	主に確認すること	問題の例
アプリケーション・ミドルウェア	処理時間、リクエスト数、エラー、内部の待ち	重いSQL、ロック競合、外部API待ち
プロセス・サービス	稼働状態、終了理由、実行ユーザー、設定、制限	設定誤り、権限不足、自動再起動の繰り返し
OS・カーネル	システムログ、タスク状態、メモリ管理、ファイルシステム	OOM、I/Oエラー、カーネルパニック
CPU・メモリ・ストレージ	使用状況、待ち、容量、負荷の変化	CPU競合、メモリ逼迫、容量不足、I/O遅延
通信・依存先	名前解決、経路、待受、接続、応答	DNS障害、接続拒否、相手サービスの遅延
ハードウェア・仮想基盤	機器の異常、リソース割り当て、管理イベント	ストレージ障害、仮想基盤側の制限、電源断

この分類は、すべてを順番に調べるための一覧ではありません。どこで起きた問題が、どこへ影響しているかを整理するためのものです。たとえば、アプリケーションのメモリ消費が増え、スワップの入出力が増加し、ディスクを共有する別の処理まで遅くなる場合があります。

同じホストで動いているサービス、共有するディスク、接続先、ロードバランサなどの関係を把握すると、調査範囲を絞りやすくなります。「一台だけ遅い」のか「同じDBを使うすべてのサーバが遅い」のかによって、優先する調査対象は変わります。

事象から調査の入口を選ぶ

問い合わせや監視通知は、「サーバがおかしい」という曖昧な表現から始まることがあります。まず事象を具体化し、その事象を確認できる情報を選びます。以下は、よくある事象と調査の入口です。

事象	最初に確認すること	代表的な確認手段
サービスが起動しない・停止する	終了理由、設定、権限、依存サービス	systemctl status、journalctl、設定ファイル
CPU使用率が高い	CPU時間の内訳、負荷を出すプロセスとスレッド	top、mpstat、pidstat、sarデータ
メモリ使用率が高い	利用可能量、スワップ活動、消費元、OOMの記録	free、vmstat、ps、sarデータ、カーネルログ
ファイルへ書き込めない	容量、inode、権限、マウント状態	df、df -i、ls、findmnt
ディスクI/Oが遅い	対象デバイスの待ちと、I/Oを発生させる処理	iostat、pidstat、iotop、アプリケーションのログ
通信できない・通信が遅い	名前解決、経路、待受、接続と応答の段階	getent、ip、ss、curl、tcpdump
OSが停止・再起動する	前回起動のログ、基盤イベント、ダンプの有無	journalctl、仮想化基盤・ハードウェアのイベント、kdump
現在は正常で再現しない	障害時刻の履歴、定期処理、変更履歴	sarデータ、監視、ジョブログ

この表で選ぶのは、原因ではなく最初の確認先です。たとえば、接続後の応答が遅い場合、TCP接続自体は正常で、相手のアプリケーションが処理を待っている可能性があります。「通信のタイムアウトだからネットワーク障害」と決めず、どの段階で時間がかかっているかを分けます。

CPUやメモリの通知についても、使用率だけでは判断しません。処理件数が増えた結果なのか、通常と同じ仕事で消費が増えたのかを確認します。平常時の記録があると、異常の意味を説明しやすくなります。

障害対応の基本的な流れ

障害対応は、大きく次の5段階に整理できます。

ただし、実際の障害対応が常にこの順番で進むとは限りません。調査によって新しい事実が判明すれば原因の仮説を見直します。また、業務影響が大きい場合は、必要なエビデンスを確保したうえで原因特定よりもサービス復旧を優先し、復旧後に詳細な原因分析を行うこともあります。

1. 影響範囲を確認する

最初に、「何が、いつから、どの範囲で発生しているのか」を確認します。

たとえば、システム全体が遅いのか、特定のAPIだけが遅いのか、複数サーバのうち一部のノードだけで発生しているのかを切り分けます。障害が発生している範囲だけでなく、正常に動いている範囲との違いも原因を絞り込む重要な材料になります。

あわせて、発生時刻と直前の変更を確認します。アプリケーションのデプロイ、OSやミドルウェアの設定変更、バッチ処理の開始、データ量の増加、仮想化基盤やネットワークの作業などを時系列で整理します。

監視で検知した時刻と実際に問題が発生した時刻は一致するとは限りません。そのため、ログや監視データは通知時刻だけでなく、その少し前から確認することが重要です。

2. エビデンスを収集する

次に、原因調査に必要なエビデンスを収集します。

障害が継続している場合は、CPU、Memory、I/O、Network、Processなどの現在の状態に加えて、関連するログやMetricを記録します。

特に再起動やProcess停止などの操作を行うと、Memoryの内容、PID、Connectionの状態など、その時点でしか確認できない情報が失われることがあります。復旧操作を行う前に、後から取得できない情報を優先して確保することが重要です。

一方、すでに正常な状態へ戻っている場合、現在の状態を確認するだけでは原因を特定できません。

その場合は、sarなどの履歴情報、監視システムのMetric、journalctl、アプリケーションログ、Jobの実行記録などから、障害発生時の状態を確認します。

障害対応では、「何を見るか」だけでなく、「今しか取得できない情報は何か」を意識してエビデンスを収集します。

3. 仮説を検証し、原因を特定する

収集したエビデンスから原因候補を考え、仮説を立てて検証します。

たとえば、「CPU使用率が高い」という状態だけでは原因とは言えません。
「Batch処理の開始によってCPUが逼迫し、アプリケーションProcessが十分なCPU時間を確保できず、Response Timeが悪化した」
というように、観測された事象を説明できる仮説を立てます。

そのうえで、その仮説が正しければ何が観測されるはずかを考えます。この例であれば、Batch処理開始時刻とResponse Time悪化のタイミング、CPUの実行待ち、Batch ProcessのCPU使用量などを確認します。

もしCPUに余裕があり、代わりにI/O Waitが増加しているのであれば、仮説を見直してDisk I/Oなど別の原因を調査します。

このように、「仮説を立てる → エビデンスで検証する → 原因候補を絞る → 必要なら仮説を見直す」というサイクルを繰り返しながら原因を特定していきます。

重要なのは、疑った原因を裏付ける情報だけを見るのではなく、その仮説を否定する情報も確認することです。

なお、業務影響が大きい場合は、原因を完全に特定できるまで調査を続けるのではなく、必要なエビデンスを確保したうえで次の暫定対処を優先することもあります。

4. 暫定対処を行い、復旧を確認する

原因または有力な原因候補が見つかったら、業務影響を抑えるための暫定対処を検討します。

たとえば、問題のあるNodeを切り離して正常なNodeへ処理を切り替える、直前の設定変更を切り戻す、再実行可能なBatchを停止する、Processを再起動するといった対応です。

暫定対処を行う際は、対処前の状態、実施した操作、実施時刻を記録します。また、可能な範囲で一度に変更する条件を絞ることで、どの操作によって状態が改善したのかを判断しやすくなります。

そして、暫定対処を実施しただけでは復旧完了とは言えません。

CPU使用率やMemory使用量といったシステムリソースだけでなく、アプリケーションが正常に応答すること、Response Timeが正常な範囲に戻ったこと、Errorが解消したことなど、実際のサービス状態を確認します。

たとえばCPU使用率が下がっていても、実はアプリケーションがRequestを受け付けなくなった結果として負荷が下がっている、という可能性も考えられます。

そのため、「システムの正常性 + サービス・業務の正常性」の両方から復旧を確認することが重要です。

QueueやRetry処理が残っている場合は、それらが正常に収束するまで確認します。また、中断したBatchや失敗した処理がある場合は、再実行やデータ補正などの残作業についても整理します。

5. 恒久対処につなげる

サービス復旧後は、根本原因を整理し、同じ障害を繰り返さないための恒久対処を検討します。

暫定対処によって復旧を優先し、原因を完全に特定できていない場合は、保存したログやMetricなどのエビデンスを使って詳細な原因分析を行います。

原因がApplicationであればProgramの修正、Resource不足であればCapacityやResource配分の見直し、Batchとの競合であれば実行時間や実行環境の分離など、根本原因に応じた対策を検討します。

また、障害そのものだけでなく、障害対応のプロセスも振り返ります。

「調査に必要なログが保存されていなかった」「監視による検知が遅かった」「復旧手順が明確になっていなかった」といった問題も改善対象です。

対策は「監視を強化する」「手順を改善する」といった抽象的な内容で終わらせず、何をどのように改善し、どのように効果を確認するのかまで具体化します。

障害対応は、単にサービスを復旧させて終わりではありません。原因を明らかにし、次回は「発生させない」「早く検知する」「早く復旧する」状態につなげることまでがトラブルシューティングの重要な役割です。

調査に使うエビデンスと、それぞれの役割

一つのコマンドですべての原因を特定することはできません。情報ごとに、わかることとわからないことがあります。調べたい仮説に合わせて、複数の情報を組み合わせます。

エビデンス	主にわかること	注意する点
Metric	負荷や待ちが、いつ、どの程度変わったか	集計間隔によって短い異常が埋もれる
ログ	エラー、処理開始・終了、設定変更などの出来事	記録されていない事象や、原因の結果として出たエラーもある
プロセス・スレッド情報	どの実行主体が資源を使い、どの状態にあるか	現在の情報だけでは終了済みの処理を追えない
パケット	取得した場所で通信がどこまで進んだか	暗号化、取得漏れ、取得場所によって見える範囲が違う
ダンプ	取得時点のメモリや実行状態	取得に負荷や停止が伴う場合があり、解析の準備も必要
変更・ジョブの記録	障害の前後で何が変わったか	時刻が一致しただけでは原因を確定できない

複数の記録を比較するときは、ホスト、プロセス、日時、タイムゾーンをそろえます。UTCのアプリログと日本時間の監視をそのまま並べると、前後関係を誤ります。プロセスが再起動している場合は、PIDと起動時刻も確認します。

ログやダンプの取得は、量より目的を優先します。問題が起きた期間と対象を絞り、保存先の容量とアクセス権を確認します。パケットやメモリの内容には業務データが含まれる場合があるため、保存と共有の範囲も決めておきます。

障害対応では図解して整理することも重要

障害対応では、ログやMetricを確認するだけでなく、集めた情報を図解して整理することも重要です。

システムが複雑になるほど、サーバ、アプリケーション、Database、Network、外部サービスなど複数の要素が関係します。また、障害発生前後の変更、エラー、Resourceの変化など、時系列で確認すべき情報も増えていきます。

こうした情報を文章やログだけで追いかけると、全体の関係が分かりにくくなります。

たとえば、システム構成を簡単に図にすると、「どこまでは正常なのか」「どこから異常なのか」を整理しやすくなります。

また、障害発生前後の出来事を時系列に並べることも有効です。時系列で整理すると、個別に確認していたログやMetricの関係が見えやすくなり、原因の仮説を立てる材料になります。

特に障害対応では、次のような情報を図解すると効果的です。

• システム構成図：Componentや依存関係を整理する
• 事象の整理：どこで何が起きているのかを整理する
• タイムライン：障害前後に何が起きたかを整理する
• 仮説とエビデンス：何が原因候補で、何がそれを支持・否定しているかを整理する

図解の目的は、きれいな資料を作ることではありません。

複雑な情報を可視化し、「どこまで分かっているのか」「次に何を確認すべきなのか」を明確にすることが目的です。

複数人で障害対応する場合にも、図を共有することで認識を合わせやすくなります。特に複数のサーバやNetwork、Databaseなどが関係する障害では、頭の中だけで構成や仮説を管理するのではなく、簡単な図に書き出しながら調査を進めることが有効です。

障害対応の5段階を使った調査例

ここからは、先ほど説明した5段階に沿って、実際にどのように障害を調査するのかを仮想事例で見ていきます。

注文APIと集計Jobが同じLinux サーバを使用しており、午前10時ごろから注文APIのResponse Timeが悪化し、Timeoutが発生するようになったとします。

なお、ここで紹介するのは調査の流れを説明するための仮想事例であり、実測結果や実際の障害報告ではありません。

1. 影響範囲の確認

まず、どの機能にどの程度の影響が出ているのかを確認します。

確認したところ、商品検索など他の機能は正常ですが、注文APIではResponse Timeが悪化し、一部のRequestでTimeoutが発生しています。

また、複数のサーバを確認したところ、集計Jobと注文APIが動作しているサーバで問題が発生していることが分かりました。

発生時刻を確認すると、午前10時ごろからResponse Timeが悪化しています。直前のアプリケーションのDeployや設定変更はありませんでしたが、同じ午前10時から集計Jobが開始されていました。

この時点では集計Jobとの関連が疑われますが、発生時刻が一致しているだけでは原因とは断定できません。

2. エビデンス収集

次に、障害発生時の状態を確認するためのエビデンスを収集します。

CPU、Memory、Swap、Disk I/OなどのResource状況に加えて、ProcessごとのResource使用量、アプリケーションログ、DBの処理状況などを確認します。

確認したところ、CPU使用率やRun Queueには余裕があり、CPU逼迫は確認されませんでした。

一方で、午前10時以降に次の変化が確認できました。

• Available Memoryが減少
• vmstatでSwap In / Out（si / so）が増加
• iostatでDisk I/OとI/O Waitが増加
• 集計ProcessのMemory使用量が増加
• 注文APIのResponse Timeが悪化

また、同じ時刻のDBの処理記録とアプリケーションログを確認したところ、DB側の処理時間には大きな変化がないことも分かりました。

3. 仮説検証・原因特定

収集したエビデンスをもとに原因の仮説を立てます。

当初はCPU不足、DB遅延、Networkなど複数の原因を想定していました。しかし、CPUには余裕があり、DBの処理時間にも大きな変化はありません。

一方で、「集計Job開始 → Memory使用量増加 → Swap / I/O Wait増加 → 注文APIのResponse Time悪化」という時間的な関係が確認できました。

そこで、「集計Jobが大量のMemoryを使用したことでMemoryが逼迫し、Swap In / Outを伴うDisk I/Oが増加して、同じサーバ上の注文APIの処理に影響した」という仮説を立てます。

追加のエビデンスでもこの関係が確認できれば、共有するサーバ Resourceの競合が原因である可能性が高いと判断できます。

4. 暫定対処・復旧確認

業務影響を抑えるため、集計Jobを一時的に停止することを検討します。

停止前に、集計Jobが後から再実行可能であること、途中まで処理したDataが二重登録されないことなどを確認したうえで停止します。

その結果、「Available Memoryが回復 → Swap / I/O Waitが減少 → 注文APIのResponse Time・成功率が回復」したとします。

注文APIが実際に正常に利用できることまで確認できれば、サービスが復旧したと判断できます。

また、集計Jobの停止によってMemory、Swap、Disk I/O、注文APIの状態が連動して改善したことは、集計JobによるResource競合という仮説をさらに支持するエビデンスになります。この結果も踏まえて、障害の直接的な原因を判断します。

5. 恒久対処

サービスが復旧しても、ここで障害対応が終わるわけではありません。

集計Jobを停止すると改善したことと、「なぜ集計Jobが大量のMemoryを使用したのか」を特定することは別の問題です。

復旧後に、集計Jobの一括読み込み、Cache、処理件数、同時実行数などを調査し、Memory使用量が増加した根本的な原因を特定します。

そのうえで、

• 一度に処理するData量を減らす
• 処理を分割する
• Memory使用量を抑える
• 集計Jobと注文APIの実行環境を分離する

などの恒久対処を検討します。

必要に応じて検証環境で同じ条件を再現し、対策によってMemory使用量やI/O Waitが抑えられ、注文APIへの影響が発生しないことまで確認します。

このように、障害対応では「影響範囲を確認する → エビデンスを集める → 仮説を検証して原因を絞る → 暫定対処と復旧確認で仮説を補強する → 根本原因に対して恒久対処する」という流れで調査を進めます。

まとめ

Linuxの障害対応では、最初から特定のResourceやコマンドに決め打ちするのではなく、事象と影響範囲を整理し、必要なエビデンスから仮説を立てて検証することが重要です。

本記事では、障害対応を「影響範囲の確認 → エビデンス収集 → 仮説検証・原因特定 → 暫定対処・復旧確認 → 恒久対処」の5段階に整理しました。

実際の障害対応では、この流れを一直線に進むとは限りません。新しいエビデンスが見つかれば仮説を見直し、業務影響が大きい場合は、必要な情報を確保したうえで原因特定よりも復旧を優先することもあります。

また、複雑な障害では、システム構成、時系列、仮説とエビデンスの関係を図解することで、「どこまで分かっているのか」「次に何を確認すべきなのか」を整理しやすくなります。

Linuxトラブルシューティングの詳細については以下の書籍にまとめているので、興味がありましたらぜひ読んでみてください。