alibabacloud-ecs-reboot-or-crash-diagnosis

ECS インスタンスの再起動／クラッシュ診断

ECS インスタンスが予期せず再起動またはクラッシュした原因を診断します。標準的なワークフローに従い、まずプラットフォームのメンテナンスイベントを確認し、その後、内部システムログを確認します。Linux と Windows の両システムに対応しています。

必須パラメーター

診断を開始する前に、ユーザーから次のパラメーターを必ず取得してください。

パラメーター	説明	例
INSTANCE_ID	ECS インスタンス ID	i-bp1a2b3c4d5e6f7g8h9j
REGION_ID	リージョン ID	cn-hangzhou

上記のパラメーターがユーザーから提供されていない場合は、必ず最初にユーザーに確認してください。診断を開始してはいけません。

必須の実行ルール

1. 最初にパラメーターを取得すること — インスタンス ID とリージョン ID は必須です。不足している場合は、必ずユーザーに確認してください。
2. 標準ワークフローを省略しないこと — メンテナンスイベントの確認 → OS タイプの検出 → システムログの確認、の順に必ず実行してください。
3. 診断の前に Cloud Assistant のステータスを確認すること — Step 3A／3B を実行する前に、DescribeCloudAssistantStatus を使用して Cloud Assistant が実行中であることを必ず確認してください。実行中でない場合は、代替の診断方法を提示してください。
4. 診断結果はすべて実際のデータに基づくこと — 捏造、推測、憶測は行わないでください。
5. 出力形式を厳守すること — 診断後は、references/output-format.md のテンプレート全体を必ず読み、テンプレートの構成に厳密に従って出力してください。自由形式での出力、セクションの省略、階層の変更は禁止です。テンプレート内のすべての {...} プレースホルダーに、実際のデータを入力してください。

---

前提条件

CLI ツール

• aliyun-cli 3.3.3+（必須）— Alibaba Cloud API の呼び出しに使用します
• インストールと設定については、CLI インストールガイドを参照してください

AI-Mode の設定（必須）

aliyun CLI コマンドを使用する前に、AI-Mode を設定する必要があります。

# Enable AI-Mode
aliyun configure ai-mode enable

# Set user-agent for skill identification
aliyun configure ai-mode set-user-agent --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-ecs-reboot-or-crash-diagnosis"

# Update plugins
aliyun plugin update

診断完了後、AI-Mode を無効にしてください。

aliyun configure ai-mode disable

Alibaba Cloud の認証情報

認証情報はエージェントのセッション外で事前に設定しておく必要があります。エージェントが行うのは確認のみです。

aliyun configure list

インスタンス要件

• インスタンスに Cloud Assistant クライアントがインストールされ、実行中であること
  • Alibaba Cloud Linux：デフォルトでプリインストールされています
  • Ubuntu／CentOS／その他：手動インストールが必要な場合があります。DescribeCloudAssistantStatus API で確認してください
  • インストールガイド：https://help.aliyun.com/document_detail/64930.html
• インスタンスのステータスが Running であること
• 注： Cloud Assistant が実行中でない場合、診断コマンドをリモートで実行できません。ユーザーに手動での診断手順を必ず提示してください。

---

必要な RAM 権限

必要な権限の一覧とカスタムポリシーの例については、**RAM ポリシー**を参照してください。

---

Step 1：インスタンス情報の確認（省略不可）

インスタンスの存在を確認し、基本情報を取得します。

aliyun ecs describe-instances \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-ids '["<INSTANCE_ID>"]'

返された JSON で次の項目を確認してください。

• RegionId — リージョン ID（ユーザーから提供された値と一致すること）
• Status — インスタンスのステータス（Running／Stopped）
• InstanceName — インスタンス名
• OSType — オペレーティングシステムの種類（windows／linux）

Step 3 の分岐を選択するため、OSType を記録してください。

---

ステップ 2：ECS メンテナンスイベントを確認する

インスタンスの過去のシステムイベントを照会し、プラットフォームのメンテナンスが再起動の原因かどうかを判断します。

aliyun ecs describe-instance-history-events \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID> \
  --event-cycle-status Executed

イベントの分析：

イベントタイプ	意味	判定	次のステップ
SystemMaintenance.Reboot	システムメンテナンスによる再起動	プラットフォームが開始したメンテナンス	ユーザーに通知し、これ以上の調査は不要です
SystemFailure.Reboot	基盤となるハードウェアまたはシステムの障害による再起動	プラットフォームのインフラストラクチャ障害	インスタンスの移行またはサポートへの問い合わせを提案します
InstanceFailure.Reboot	インスタンスレベルの障害による再起動	プラットフォームがインスタンス内部の問題を検出しました	システムログを確認するため、ステップ 3 に進む必要があります
InstanceExpiration.Stop	有効期限切れによるインスタンスの停止	課金の問題	更新が必要です。これ以上の調査は不要です
該当するイベントなし	プラットフォームのメンテナンスイベントは見つかりませんでした	プラットフォームが開始したものではありません	ステップ 3 に進みます

InstanceFailure.Reboot に関する重要な注意事項：

• このイベントは、プラットフォームがインスタンスレベルの異常を検出し、自動復旧を開始したことを示します
• 一般的な原因：カーネルパニック、OOM、システムハング、重要なプロセスの障害
• 根本原因を特定するため、必ずステップ 3 を実行してシステムログを確認してください
• ログに明らかなエラーが見つからない場合でも、インスタンスがカーネルレベルで応答しなくなっていた可能性があります

メンテナンスイベントが見つかった場合：

• 再起動の原因（イベントタイプ、時刻、理由）をユーザーに明確に伝えます
• 対処方法を提案します
• 診断フローを終了します

メンテナンスイベントが見つからなかった場合：

• ステップ 3 に進み、OSType に応じて内部システムログを確認します

---

ステップ 3A：Linux システムの診断（OSType が linux の場合に実行）

ステップ 3A.1：Cloud Assistant のステータスを確認する（必須）

診断コマンドを実行する前に、Cloud Assistant が実行中であることを確認します。

aliyun ecs describe-cloud-assistant-status \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID>

応答を確認します：

{
  "InstanceCloudAssistantStatusSet": {
    "InstanceCloudAssistantStatus": [
      {
        "InstanceId": "i-xxx",
        "RegionId": "cn-xxx",
        "CloudAssistantStatus": "true",
        "LastHeartbeatTime": "2026-04-09T07:26:58Z"
      }
    ]
  }
}

重要な注意事項：

• CloudAssistantStatus はブール値ではなく、文字列（"true"/"false"）です
• LastHeartbeatTime を確認し、直近（数分以内）の時刻であることを確かめてください
• ステータスが "true" でも、サービスが不安定な場合は RunCommand が失敗することがあります
• RunCommand の実行結果を必ず確認し、失敗した場合は適切に対処してください
• Ubuntu と RHEL の違い：
  • RHEL/CentOS/Alibaba Cloud Linux：サービス名は kdump、クラッシュファイル名は vmcore-* です
  • Ubuntu/Debian：サービス名は kdump-tools、クラッシュファイル名は dump.* と dmesg.* です
  • 診断スクリプトは、両方のサービス名とすべての種類のクラッシュファイルを確認するようになりました

CloudAssistantStatus が false の場合、またはコマンドが失敗した場合：

• Cloud Assistant がインスタンスにインストールされていないか、実行されていません
• リモート診断コマンドを続行できません
• 代替方法：
  1. インスタンスに SSH 接続し、ログを手動で確認するようユーザーに案内します
  2. ユーザーが実行できる手動の診断コマンドを提示します
  3. Cloud Assistant のインストールを提案します：インストールガイド
  4. CloudMonitor API を使用してインスタンスのモニタリングデータを確認します

CloudAssistantStatus が true の場合：

• ステップ 3A.2 に進みます

Step 3A.2: Linux 診断スクリプトを実行する

Cloud Assistant を使用して Linux 診断スクリプトを実行し、以下を確認します。

• システムの再起動記録（last reboot、/var/log/messages または /var/log/syslog）
• カーネルパニックの記録（dmesg）
• OOM の記録と vm.panic_on_oom の設定
• Kdump の設定とクラッシュダンプファイルの状態
• クラッシュダンプファイル：vmcore（RHEL/CentOS）または dump./dmesg.（Ubuntu/Debian）

診断コマンドの全一覧：diagnostic-commands.md を参照してください

Linux の結果分析：

検出内容	考えられる原因	提案
カーネルパニック + クラッシュダンプ（vmcore/dump.*）	カーネルがクラッシュし、ダンプファイルが生成された	dmesg.* ファイルでパニックの原因を確認し、詳細な分析について Alibaba Cloud テクニカルサポートに問い合わせてください
カーネルパニック + クラッシュダンプなし	カーネルがクラッシュしたが、kdump が設定されていない、または動作していない	ステップ 5 に進んでください：今後のクラッシュを記録できるよう、Kdump の設定を推奨します
OOM + panic_on_oom=1	OOM によってカーネルパニックが発生した	panic_on_oom を無効にするか、メモリを増やしてください
OOM Killer	メモリ不足によりプロセスが強制終了された	メモリ使用量を最適化するか、インスタンスタイプをアップグレードしてください
SysRq によるクラッシュ	/proc/sysrq-trigger によって手動でクラッシュが発生した	意図的なテストか確認し、bash 履歴と監査ログを確認してください
正常な再起動記録	ユーザーまたはプログラムによって再起動が実行された	cron ジョブまたは運用スクリプトを確認してください
異常な記録なし	システムレベルの問題は検出されませんでした	外部要因の可能性があります。監視を推奨します

---

Step 3B: Windows システム診断（OSType が windows の場合に実行）

Step 3B.1: Cloud Assistant のステータスを確認する（必須）

診断コマンドを実行する前に、Cloud Assistant が実行中であることを確認してください。

aliyun ecs describe-cloud-assistant-status \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID>

応答を確認してください。

• CloudAssistantStatus: true — Cloud Assistant は実行中です。Step 3B.2 に進んでください
• CloudAssistantStatus: false — Cloud Assistant は実行されていません
  • リモート診断コマンドを実行できません
  • インスタンスに SSH/RDP で接続して、診断を手動で実行するようユーザーを案内してください
  • Cloud Assistant の再インストールを提案してください：Windows Installation Guide

Step 3B.2: Windows 診断スクリプトを実行する

Cloud Assistant を使用して Windows 診断スクリプトを実行し、以下を確認します。

• システムの稼働時間と予期しないシャットダウンイベント（イベント ID 41、1074、6008、6006）
• メモリダンプの設定とページファイルの設定
• MEMORY.DMP およびミニダンプファイルの有無
• BSOD イベントとアプリケーションのクラッシュ

診断コマンドの全一覧：diagnostic-commands.md を参照してください

Windows の結果分析：

検出内容	考えられる原因	提案
イベント 41（Kernel-Power）	予期しないシャットダウン／クラッシュ	BSOD とダンプファイルを確認してください
ダンプが設定済み + ダンプファイルあり	システムがクラッシュし、ダンプが取得された	ダンプファイルの分析について Alibaba Cloud テクニカルサポートに問い合わせてください
ダンプが設定済み + ダンプファイルなし	クラッシュが発生したが、ダンプは取得されなかった	ページファイルとディスク容量を確認してください
ダンプが未設定	クラッシュダンプが無効になっている	診断のためにメモリダンプを有効にしてください
BSOD イベントあり	ブルースクリーンによるクラッシュが発生した	ダンプ内のバグチェックコードを確認してください
異常なイベントなし	システムレベルのクラッシュ記録はありません	電源の問題または外部要因の可能性があります

---

Step 3.5: Cloud Assistant コマンドの出力を取得する（Step 3 の後に必須）

RunCommand を使用して診断スクリプトを実行した後、実行結果を照会します。

aliyun ecs describe-invocations \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID> \
  --invoke-id <INVOKE_ID>

重要な注意事項：

• describe-invocations API では --instance-id.1 ではなく --instance-id を使用してください
• InvokeId は RunCommand API 呼び出しによって返されます
• Output フィールドを Base64 からデコードして、診断結果を取得してください
• InvokeStatus を確認し、コマンドの実行が正常に完了したことを確かめてください

---

ステップ 4：クラッシュダンプファイルを分析する

ステップ 3 でクラッシュダンプファイル（Linux の vmcore、Windows の MEMORY.DMP/minidump）が見つかった場合は、予備分析を実施します。

分析コマンドの全容については、diagnostic-commands.mdを参照してください。

重要： Linux の vmcore ファイルの詳細な分析が必要な場合、または Windows のダンプファイル（MEMORY.DMP/minidump）が見つかった場合は、専門的なクラッシュダンプ分析の支援を受けるため、Alibaba Cloud テクニカルサポートチームへの問い合わせをユーザーに推奨してください。

---

ステップ 5：Kdump の設定を推奨する（未設定の場合）

ステップ 3A でカーネルパニックの記録が見つかり、vmcore ファイルがない場合は、ユーザーに Kdump の設定を必ず案内してください。

Kdump の設定を推奨する状況

• dmesg またはシステムログにカーネルパニックの記録が見つかったが、/var/crash に vmcore ファイルがない
• Kdump サービスの状態が inactive または failed
• /proc/cmdline に crashkernel= パラメーターが含まれていない

伝えるべきポイント

1. Kdump が必要な理由：Kdump がないと、カーネルクラッシュ時に vmcore ファイルが生成されず、根本原因の分析ができません。

2. 設定要件：

   • crashkernel= カーネルパラメーターを使用して、クラッシュカーネル用のメモリを確保する
   • kdump（RHEL/CentOS）または kdump-tools（Ubuntu/Debian）サービスを有効化して起動する
   • /var/crash（または設定済みのパス）に十分なディスク容量を確保する

3. 設定の参考情報：diagnostic-commands.mdに記載されたガイダンスを提供する

Kdump 設定手順の概要

RHEL/CentOS/Alibaba Cloud Linux：

1. インストール：yum install -y kexec-tools
2. /etc/default/grub のカーネルパラメーターに crashkernel=auto を追加する
3. grub2-mkconfig -o /boot/grub2/grub.cfg を実行する
4. インスタンスを再起動する
5. 有効化：systemctl enable --now kdump

Ubuntu/Debian：

1. インストール：apt-get install -y kdump-tools
2. /etc/default/kdump-tools で USE_KDUMP=1 を設定する
3. update-grub を実行する（通常、crashkernel パラメーターは自動的に追加されます）
4. インスタンスを再起動する
5. 確認：systemctl status kdump-tools

Windows のメモリダンプ設定

ステップ 3B で BSOD イベントが見つかり、ダンプファイルがない場合：

1. ページファイルが設定され、十分なサイズがあることを確認する
2. メモリダンプを有効にする：システムのプロパティ → 詳細設定 → 起動と回復 → 設定
3. 「自動メモリダンプ」または「カーネルメモリダンプ」を選択する
4. CrashDumpEnabled レジストリ値が 0 でないことを確認する

---

最終出力（診断完了後に必ず実行）

すべての診断手順が完了したら、以下の両方を必ず実行してください。

1. references/output-format.md を読む — 出力形式の完全なテンプレートを確認します
2. テンプレートの構成に厳密に従って出力する — 実際の結果に基づいて該当するテンプレートを選択します

---

参考資料

• 出力形式 — 診断結果の出力テンプレート
• 一般的なシナリオ — 典型的な問題の診断例
• 診断コマンド — 診断スクリプトと分析コマンドの全容