SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsalibabacloud-ecs-linux-troubleshooting

alibabacloud-ecs-linux-troubleshooting

General & other

View repository

Updated 10-16 04:59

About this skill

ECS Linux Troubleshooting

This skillapplies only to Linux GuestOS on Alibaba Cloud ECS, and performs abnormal issue troubleshooting for a user-specified Alibaba Cloud ECS Linux instance (target machine). The Agent runs on the target machine or another machine, and uses the aliyun CLI tool to perform remote diagnosis and data collection on the target ECS instance.

When to Use This Skill

  • When the troubleshooting target specified by the user is an Alibaba Cloud ECS Linux instance.
  • When the user describes abnormal issues involving boot/running status inconsistent with the OS, remote login failure, network unreachability, disk/expansion/mounting, performance anomalies, crashes or hangs, clock, configuration not taking effect, etc.
  • Not applicable: non-Alibaba Cloud ECS, non-Linux GuestOS, other clouds or physical machines; pure management/billing/API-side issues with no GuestOS involvement

Principles and Requirements

  1. Troubleshooting target = the Alibaba Cloud ECS Linux instance specified by the user: all checks and conclusions are for this one machine.references/ The commands, paths, etc. in are written according to the environment inside the instance.
  2. Use the aliyun CLI tool for remote diagnosis and data collection.: It is required that, except for the steps in references/utils/guestos-pe-prep.md , other steps may only usereferences/aliyun-cli-cheatsheet.mdthe subcommands listed in,and must not call subcommands not listed。
  3. Understand the problem first, then investigate: Strictly follow thetroubleshooting process, and first narrow the user description down to aphenomenon domain, then follow thetroubleshooting documentto execute troubleshooting.
  4. Prefer to run the commands required for troubleshooting as described in thereferences/<slug>.md troubleshooting document,and do not blindly guess commands on your own。
  5. Multi-instance scenario: Troubleshooting must be performed separately for each ECS instance; do not mix the results of machine A to draw conclusions about machine B.

Troubleshooting Process

Must be executed in order

Phase 1: Abnormal Issue Clarification

Before opening any domain document, if the user's problem description is vague,first refine the problem through multiple rounds of dialogue, and through aliyun CLI and ask the user to fill in as much as possible the evidence of the abnormal issue occurrence and related environment information; this usually involves the following information:

Dimension Content to Fill In How to Obtain
Basic instance information, status, specification Instance status Call aliyun CLI as needed
Scope Whether it is reproducible every time; start and end time; whether there were changes, restarts, or scaling when the abnormal issue occurred Ask the user
Channel Whether VNC is available; whether SSH/Workbench/Cloud Assistant is available Ask the user
Network direction External→instance service port, instance→external network, only intra-VPC communication, etc. Ask the user
Symptom Original error text, screenshots Ask the user

Phase 2: Categorize into a Phenomenon Domain

  1. Open references/symptom-to-domain.mdand select the phenomenon domain category and phenomenon domain based on the user's clarified abnormal issue description.
  2. Output:one phenomenon domain, and note down the troubleshooting document path corresponding to the symptom domain references/<slug>.md. At the same timeask the user to confirm whether the symptom domain is accurate. Only after it is accurate, proceed to "Phase 3". If the user says it is inaccurate, show the user the top 3 secondary symptom domains after excluding the symptom domain in step 2, and ask the user to confirm whether it belongs to these secondary symptom domains. If the user says it does not belong to any secondary symptom domain, terminate all subsequent processes and recommend that the user submit an Alibaba Cloud ticket.

Phase 3: Confirm whether it is a GuestOS issue

Open the selected references/<slug>.md , then complete the steps in the "Determine whether it is a GuestOS issue" section at the beginning of the document in order, requiring:

  1. mustconfirm that it is a GuestOS issue before proceeding to all subsequent steps; otherwise, directly return the abnormal issue conclusion to the user.
  2. prioritize completing the determination yourself in order: for any data that can be obtained through the aliyun CLI, call and obtain it directly;do not directly ask the user without first attempting to obtain data through the aliyun CLI. Only ask the user when the information can indeed only be obtained from the console or the user-side client environment.
  3. Before completing the determination, do not proceed to any subsequent steps.

Phase 4: Diagnostic tool troubleshooting

Before entering detailed troubleshooting within the domain, first perform quick troubleshooting based on the diagnostic tools recommended for the symptom domain.

  1. View references/phenomenon-domain.md the "Recommended diagnostic sets" column corresponding to the current symptom domain to determine the list of diagnostic sets to call. If the recommended column is "—" (no recommended diagnostic sets), skip this phase and directly proceed to "Phase 5".
  2. First, confirm with the user whether to execute the recommended diagnostic sets。If the user agrees, then based on the diagnostic set list obtained in step 1in orderrefer to references/create-diagnostic-report.md the steps in to create a resource diagnostic report and execute diagnostics.If the user does not agree, skip this phase. Note:
  3. If the diagnostic set requires additional input parameters, prioritize querying the relevant data through the aliyun CLI tool, and only require the user to provide it when the data cannot be obtained through the aliyun CLI.
  4. If the diagnostic set does not exist or creating the resource diagnostic report fails, first explain the situation to the user, then skip this phase and directly proceed to the next phase.
  5. View the resource diagnostic report details. If the diagnostic report already contains diagnostic items strongly related to the abnormal issue, directly proceed to "Phase 6". Otherwise, the diagnostic report output results should be carried into subsequent phases and analyzed together with the in-domain process.

Phase 5: Troubleshooting components related to the issue within GuestOS

Read references/<slug>.md the within GuestOS section of:

  1. Read the related components list therein; these are the GuestOS components possibly involved in the current symptom domain, such as NIC, routing, DNS, firewall, sshd, PAM, disk, kernel, etc.
  2. Troubleshoot according to the problem localization steps given in the document. When the troubleshooting steps point to a component troubleshooting document linkreferences/utils/<component-slug>.md, open the corresponding referenced document and perform component troubleshooting in order. Requiringdata collection through the aliyun CLI tool(when it is necessary to collect data within GuestOS for the current symptom domain, you may call aliyun.ecs.RunCommand). In addition, the commands should be as detailed as possible, and should as much as possiblecollect all required data for this symptom domain in one go, to reduce the number of RunCommand executions.
  3. Do not perform any remediation operations, only provide conclusions and remediation suggestions.

Phase 6: Summary and Recommendations

Finally, provide a summary and recommendations based on the following two cases:

  • Root cause identified: provide a structured diagnostic report explaining the symptom domain, the evidence chain of the troubleshooting process, the conclusion, and give recommendations to fix or work around the issue. Requirements:
    1. Mustfollow the templatereferences/diagnosis-report-template.mdto generate the diagnostic report.
    2. Clear and readable, avoid being vague.
    3. When multiple root causes exist, their relationships need to be analyzed: whether one root cause leads to another root cause, or multiple root causes jointly cause the problem.
  • Root cause still uncertain: list the candidate root causes that have been ruled out, and provide recommendations for the next troubleshooting step.

Process Overview

flowchart TD
  A[阶段1 收集事实 + aliyun CLI采集元数据] --> B[阶段2 确定现象域（symptom-to-domain + phenomenon-domain）]
  B --> C[选定 references/slug.md]
  C --> D[阶段3 确认问题边界: GuestOS / 管控 / 客户端]
  D -->|非 GuestOS 主因| E[先处理/网络/平台侧]
  D -->|GuestOS| D2[阶段4 快速排查：资源诊断报告排查]
  D2 -->|有推荐诊断集合| D3[调用 aliyun.ecs.CreateDiagnosticReport]
  D2 -->|无推荐诊断集合| F[阶段5 域内排查: 组件排查 + 定位步骤]
  D3 --> F
  F --> G{需 utils / 更多数据?}
  G -->|是| H[打开对应引用文档按顺序进行组件排查]
  G -->|否| I[阶段6 总结与建议]
  H --> I
  E --> I

Referenced Document Index

Path Purpose
symptom-to-domain.md Natural language → symptom domain routing
phenomenon-domain.md Authoritative table: unique identifier, concept, typical symptoms, slug, recommended diagnostic tools
aliyun-cli-cheatsheet.md aliyun CLI tool quick reference (whitelisted subcommands)
create-diagnostic-report.md Resource diagnostic report creation and interpretation
references/<slug>.md Complete troubleshooting process for each symptom domain
references/utils/<component-slug>.md GuestOS component-level troubleshooting