alibabacloud-ecs-reboot-or-crash-diagnosis：诊断 ECS 实例重启或崩溃问题。首先检查是否存在异常维护事件，其次排查内部重启日志或内核崩溃（Kernel Panic）现象，支持linux和Windows操作系统。当用户报告相关ECS相关问题时，请使用此技能进行诊断。

ECS 实例重启/崩溃诊断

诊断 ECS 实例意外重启或崩溃的根本原因。使用标准工作流：先检查平台维护事件，再检查内部系统日志。支持 Linux 和 Windows 系统。

必需参数

开始诊断前，必须从用户处获取以下参数：

如果用户未提供上述任何参数，必须先询问用户。不要开始诊断。

强制执行规则

1. 必须先获取参数——实例 ID 和地域 ID 必需。缺失时必须询问用户。
2. 标准工作流不可跳过——必须按顺序执行：维护事件检查 → OSType 检测 → 系统日志检查
3. 诊断前必须检查云助手状态——执行步骤 3A/3B 之前，必须通过 DescribeCloudAssistantStatus 验证云助手正在运行。如果未运行，提供替代诊断方法。
4. 所有诊断结论必须基于实际数据——不得捏造、推测或假设
5. 必须严格遵循输出格式——诊断后，必须阅读 references/output-format.md 中的完整模板，严格按模板结构输出。不得自由格式输出，不得省略章节，不得改变层级。模板中的每个占位符 {...} 都必须填入实际数据。

前置条件

CLI 工具

• aliyun-cli 3.3.3+（必需）——用于调用阿里云 API
• 安装与配置：见 CLI 安装指南

AI-Mode 配置（必需）

使用 aliyun CLI 命令前，必须配置 AI-Mode：

启用 AI-Mode

aliyun configure ai-mode enable

设置 user-agent 以标识 Skill

aliyun configure ai-mode set-user-agent --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-ecs-reboot-or-crash-diagnosis"

更新插件

aliyun plugin update

**诊断完成后禁用 AI-Mode：**

aliyun configure ai-mode disable

### 阿里云凭证
凭证必须**在 Agent 会话之外**预先配置。Agent 仅验证：

aliyun configure list

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

---

所需 RAM 权限

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

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

事件分析：

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 诊断脚本

通过云助手执行 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 结果分析：

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

步骤 3B.1：检查云助手状态（强制）

执行诊断命令前，验证云助手正在运行：

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

检查响应：

• CloudAssistantStatus: true —— 云助手正在运行，继续步骤 3B.2
• CloudAssistantStatus: false —— 云助手未运行
• 无法继续远程诊断命令
• 引导用户 SSH/RDP 进入实例手动运行诊断
• 建议重新安装云助手：Windows 安装指南

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

通过云助手执行 Windows 诊断脚本，检查：

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

完整诊断命令：见 diagnostic-commands.md

Windows 结果分析：

步骤 3.5：获取云助手命令输出（步骤 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 发现内核崩溃记录但无 vmcore 文件，必须建议用户配置 Kdump。

何时建议 Kdump 配置

• 在 dmesg 或系统日志中发现内核崩溃记录，但 /var/crash 无 vmcore 文件
• Kdump 服务状态显示 inactive 或 failed
• /proc/cmdline 不含 crashkernel= 参数

需要传达的关键点

1. 为什么需要 Kdump：没有 Kdump，内核崩溃不会生成 vmcore 文件，无法进行根因分析。

1. 配置要求：

• 通过 crashkernel= 内核参数为崩溃内核预留内存
• 启用并启动 kdump（RHEL/CentOS）或 kdump-tools（Ubuntu/Debian）服务
• 确保 /var/crash（或配置路径）有足够磁盘空间

1. 配置参考：提供 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. 严格按模板结构输出 —— 根据实际结果选择对应模板

参考

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

文档 4 / 6：alibabacloud-hologres-instance-manage