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. 不得跳过标准工作流 — 必须按顺序执行：维护事件检查 → 操作系统类型检测 → 系统日志检查
3. 诊断前必须检查云助手状态 — 执行步骤 3A／3B 前，必须通过 DescribeCloudAssistantStatus 确认云助手正在运行。如果未运行，须提供替代诊断方法。
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 凭证

凭证必须在 Agent 会话之外预先配置。Agent 仅进行验证：

aliyun configure list

实例要求

• 实例上必须安装并运行云助手客户端
  • Alibaba Cloud Linux：默认预装
  • Ubuntu/CentOS/其他系统：可能需要手动安装，请通过 DescribeCloudAssistantStatus API 检查
  • 安装指南：https://help.aliyun.com/document_detail/64930.html
• 实例状态必须为 Running
• 注意： 如果云助手未运行，就无法远程执行诊断命令。必须向用户提供手动诊断步骤。

---

RAM 权限要求

完整权限列表和自定义策略示例，请参见 RAM 策略。

---

步骤 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）

记录 OSType，以便在步骤 3 中选择对应分支。

---

步骤 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：检查云助手状态（必做）

执行诊断命令前，请确认云助手正在运行：

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 或命令失败：

• 实例上未安装或未运行云助手
• 无法继续执行远程诊断命令
• 替代方案：
  1. 引导用户通过 SSH 登录实例并手动检查日志
  2. 提供手动诊断命令供用户执行
  3. 建议安装云助手：安装指南
  4. 通过 CloudMonitor API 检查实例监控数据

如果 CloudAssistantStatus 为 true：

• 继续执行步骤 3A.2

步骤 3A.2：执行 Linux 诊断脚本

通过 Cloud Assistant 执行 Linux 诊断脚本，检查：

• 系统重启记录（last reboot、/var/log/messages 或 /var/log/syslog）
• 内核 Panic 记录（dmesg）
• OOM 记录和 vm.panic_on_oom 配置
• Kdump 配置和崩溃转储文件状态
• 崩溃转储文件：vmcore（RHEL/CentOS）或 dump./dmesg.（Ubuntu/Debian）

完整诊断命令：请参阅 diagnostic-commands.md

Linux 结果分析：

发现	可能原因	建议
内核 Panic + 崩溃转储（vmcore/dump.*）	内核崩溃，已生成转储文件	阅读 dmesg.* 文件以了解 Panic 原因，并联系 Alibaba Cloud 技术支持进行深入分析
内核 Panic + 无崩溃转储	内核崩溃，但未配置 Kdump 或 Kdump 未正常工作	继续执行步骤 5：建议配置 Kdump，以便在今后捕获崩溃信息
OOM + panic_on_oom=1	OOM 触发了内核 Panic	禁用 panic_on_oom 或增加内存
OOM Killer	内存不足导致进程被终止	优化内存使用或升级实例规格
SysRq 触发崩溃	通过 /proc/sysrq-trigger 手动触发崩溃	检查是否为有意测试，并查看 bash 历史记录和审计日志
正常重启记录	用户或程序触发了重启	检查 cron 任务或运维脚本
未发现异常记录	未发现系统级问题	可能是外部因素，建议进行监控

---

步骤 3B：Windows 系统诊断（当 OSType 为 windows 时执行）

步骤 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 正在运行，继续执行步骤 3B.2
• CloudAssistantStatus: false — Cloud Assistant 未运行
  • 无法继续执行远程诊断命令
  • 指引用户通过 SSH/RDP 登录实例并手动运行诊断
  • 建议重新安装 Cloud Assistant：Windows 安装指南

步骤 3B.2：执行 Windows 诊断脚本

通过 Cloud Assistant 执行 Windows 诊断脚本，检查：

• 系统运行时间和意外关机事件（事件 ID 41、1074、6008、6006）
• 内存转储配置和页面文件设置
• MEMORY.DMP 和 minidump 文件是否存在
• BSOD 事件和应用程序崩溃

完整诊断命令：请参阅 diagnostic-commands.md

Windows 结果分析：

发现	可能原因	建议
事件 41（Kernel-Power）	意外关机/崩溃	检查是否发生 BSOD 以及是否存在转储文件
已配置转储 + 转储文件存在	系统发生崩溃并已捕获转储	联系 Alibaba Cloud 技术支持分析转储文件
已配置转储 + 无转储文件	发生了崩溃，但未捕获转储	检查页面文件和磁盘空间
未配置转储	已禁用崩溃转储	启用内存转储以进行诊断
发现 BSOD 事件	发生了蓝屏崩溃	检查转储文件中的错误检查代码
未发现异常事件	未发现系统级崩溃记录	可能是电源问题或外部因素

---

步骤 3.5：获取 Cloud Assistant 命令输出（步骤 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（而非 --instance-id.1）
• InvokeId 由 RunCommand API 调用返回
• 将 Output 字段从 Base64 解码，以获取诊断结果
• 检查 InvokeStatus，确保命令已成功执行

---

第 4 步：分析崩溃转储文件

如果第 3 步发现了崩溃转储文件（Linux 上的 vmcore，Windows 上的 MEMORY.DMP/minidump），请进行初步分析。

完整分析命令：参见 diagnostic-commands.md

重要提示： 如果需要深入分析 Linux vmcore 文件，或发现了 Windows 转储文件（MEMORY.DMP/minidump），建议用户联系阿里云技术支持团队，寻求专业的崩溃转储分析协助。

---

第 5 步：建议配置 Kdump（如果尚未配置）

如果第 3A 步发现了 Kernel Panic 记录，但没有 vmcore 文件，必须建议用户配置 Kdump。

何时建议配置 Kdump

• 在 dmesg 或系统日志中发现 Kernel panic 记录，但 /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. 严格按照模板结构输出 — 根据实际结果选择相应模板

---

参考资料

• 输出格式 — 诊断结果输出模板
• 常见场景 — 典型问题诊断示例
• 诊断命令 — 完整的诊断脚本和分析命令