企业官网建设流程全解析

GitHub Copilot 技能实战：使用 awesome-copilot 的 AWS Resource Health Diagnose 技能完成资源健康巡检与故障修复

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

本文以 awesome-copilot 仓库中的 aws-resource-health-diagnose 技能为核心，讲解如何利用该技能对单个 AWS 资源执行"健康状态评估 → CloudWatch 日志与指标诊断 → 问题分级与根因分析 → 修复计划生成 → 报告确认"的完整闭环。读完本文，你将掌握一套可直接复用的 AWS CLI 诊断命令集、各服务类型的关键健康指标清单、问题严重度分级与根因分类框架，以及带有验证与回滚步骤的修复计划编写方法，可直接套用到 EC2、Lambda、RDS、ECS、ALB、DynamoDB、SQS、API Gateway 等常见资源的日常巡检与故障处置中。

技能定位：仓库中的 SKILL 文件如何工作

在 awesome-copilot 仓库中，Agent Skills 是自包含的文件夹，每个技能包含一个SKILL.md指令文件，Agent 在需要执行专项任务时按需加载（参见 docs/README.skills.md）。aws-resource-health-diagnose技能由文件头部的 YAML Frontmatter 声明其名称与触发描述：

name: aws-resource-health-diagnose description: 'Analyze AWS resource health, diagnose issues from CloudWatch logs and metrics, and create a remediation plan for identified problems.'

该描述直接对应其工作流目标：分析指定 AWS 资源的健康状态、利用 CloudWatch 日志与指标定位问题，并为已发现的问题制定全面的修复计划。安装该技能的方式与仓库内其他技能一致，可通过 GitHub CLI 安装：

gh skills install github/awesome-copilot aws-resource-health-diagnose

也可以将 skills/aws-resource-health-diagnose 文件夹手动复制到本地技能目录。运行前需要满足以下前置条件：

• AWS CLI 已配置并完成身份认证（aws configure或环境变量/SSO 方式）；
• 已确定目标资源（名称、类型，可选地指定区域/账号）；
• 目标资源已启用 CloudWatch 日志与指标采集——这是整个诊断流程的数据基础，若未启用，后文"错误处理"一节会给出补救建议。

工作流总览：七步诊断闭环

技能文档将整个诊断过程拆解为七个步骤，形成"参考→定位→体检→取证→定性→开方→汇报"的完整闭环：

1. 获取 AWS 诊断最佳实践：先拉取 CloudWatch 官方监控与故障排查文档，让后续诊断方向有据可依；
2. 资源发现与识别：按资源类型用对应 CLI 命令精确定位目标；
3. 健康状态评估：执行服务级健康检查，收集关键健康指标；
4. 日志与指标分析：通过 CloudWatch Logs Insights 查询与 Performance Insights 深入取证；
5. 问题分类与根因分析：按严重度分级，并映射到六类根因；
6. 生成修复计划：分"立即行动 / 短期修复 / 长期改进"三档给出可执行命令；
7. 报告与用户确认：结构化展示发现，经用户确认后产出完整 Markdown 报告。

Step 1：先参考官方诊断最佳实践

在动手之前，技能要求先获取 AWS CloudWatch 官方监控与故障排查指南（对应https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/文档集），将其作为确定诊断方法的依据。这一步的价值在于：让 Agent 在形成假设之前先建立"该服务常见故障信号有哪些、官方推荐的指标口径是什么"的基线认知，避免凭经验盲目下结论。

Step 2：资源发现与识别

针对不同资源类型，技能给出了对应的 AWS CLI 定位命令。这里的关键在于"按类型选命令"，因为不同服务在 CLI 中的检索入口完全不同：

# EC2 aws ec2 describe-instances --filters "Name=tag:Name,Values=<name>" # Lambda aws lambda get-function --function-name <name> # RDS aws rds describe-db-instances --db-instance-identifier <name> # ECS aws ecs describe-services --cluster <cluster> --services <name> # ALB aws elbv2 describe-load-balancers --names <name> # DynamoDB aws dynamodb describe-table --table-name <name> # SQS aws sqs get-queue-attributes --queue-url <url> --attribute-names All # API Gateway aws apigatewayv2 get-apis

使用要点：

• EC2 推荐以Name标签过滤，避免在海量实例中手工比对 ID；
• ECS 必须同时提供--cluster与--services两个参数；
• SQS 的定位入口是队列 URL 而非名称，获取属性时用--attribute-names All一次性取回全部属性；
• 多匹配处理：如果返回多个匹配结果，技能要求主动向用户询问确认具体的 region/account，防止跨区域或跨账号误诊。

这里可以与本仓库的 aws-resource-query 技能 形成互补——后者提供更完整的"意图→只读命令"映射表（涵盖 EC2、S3、RDS、Lambda、ECS、EKS、IAM、VPC、SQS、CloudWatch 等），可先用它完成资源清单盘点，再用本技能聚焦单个资源的深度诊断。

Step 3：健康状态评估

定位到资源后，执行服务级健康检查命令。技能给出的示例覆盖计算与数据库两大类别：

# EC2 aws ec2 describe-instance-status --instance-ids <id> # RDS aws rds describe-db-instances --db-instance-identifier <name> \ --query 'DBInstances[0].DBInstanceStatus' # Lambda - error rate over 24h aws cloudwatch get-metric-statistics --namespace AWS/Lambda \ --metric-name Errors --dimensions Name=FunctionName,Value=<name> \ --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period 3600 --statistics Sum # ECS aws ecs describe-services --cluster <cluster> --services <name> \ --query 'services[0].[status,runningCount,desiredCount,pendingCount]'

参数说明：

• RDS 健康状态直接取自DBInstanceStatus字段（取值如available、starting、stopped、storage-full等）；
• Lambda 用get-metric-statistics拉取 24 小时 Errors 指标求和，--period 3600表示按小时聚合，--statistics Sum统计错误总数；
• ECS 用--query一次性抽取status、runningCount、desiredCount、pendingCount四个字段，running 与 desired 的差值就是扩容/缩容异常的直观信号；
• 命令中的$(date -u -d '24 hours ago' ...)为 Linux/macOS 的 GNU date 语法，用于动态生成 UTC 时间戳，Windows 环境需替换为等价的 PowerShell 时间计算。

各服务类型的关键健康指标

技能按服务类型整理了一套"看什么指标"的清单，这是健康评估的核心依据：

这些指标各自对应一类典型故障：Lambda 的 Throttles 升高意味着并发或预留并发配置不足；RDS 的 FreeStorageSpace 逼近 0 会触发storage-full状态拒写；ECS 的 runningCount 长期小于 desiredCount 通常伴随任务启动失败；SQS 的 ApproximateAgeOfOldestMessage 持续增长则指向消费端停滞。评估时应把多个指标放在同一时间窗口内交叉比对，而不是孤立看单个数值。

Step 4：日志与指标分析

健康指标只能回答"有没有问题"，日志才能回答"为什么"。技能在这一步给出了从定位日志组到执行 Logs Insights 查询的完整命令链：

# Find log groups aws logs describe-log-groups --log-group-name-prefix /aws/<service>/<name> # Start a query (last 24h errors) aws logs start-query \ --log-group-name /aws/lambda/<name> \ --start-time $(date -u -d '24 hours ago' +%s) \ --end-time $(date -u +%s) \ --query-string 'filter @message like /ERROR/ | stats count(*) as errorCount by bin(1h)' # Get results aws logs get-query-results --query-id <id> # Lambda cold starts aws logs start-query \ --log-group-name /aws/lambda/<name> \ --start-time $(date -u -d '24 hours ago' +%s) \ --end-time $(date -u +%s) \ --query-string 'filter @type = "REPORT" | filter @initDuration > 0 | stats count() as coldStarts by bin(1h)' # RDS Performance Insights (if enabled) aws pi get-resource-metrics \ --service-type RDS --identifier db:<identifier> \ --metric-queries '[{"Metric":"db.load.avg"}]' \ --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period-in-seconds 3600

关键用法说明：

• start-query是异步接口，提交后返回query-id，必须用get-query-results --query-id <id>轮询取回结果；
• 日志组命名遵循 AWS 约定：Lambda 为/aws/lambda/<name>，ECS 为/aws/ecs/<cluster>，API Gateway 为/aws/apigateway/<api-id>，可用--log-group-name-prefix做前缀匹配来发现实际日志组；
• 冷启动查询利用 Lambda REPORT 日志中的@initDuration字段——该字段存在即代表本次调用经历了初始化（冷启动），按小时统计可量化冷启动对延迟的贡献；
• RDS Performance Insights 的 identifier 需带db:前缀（如db:mydbinstance），db.load.avg返回数据库负载平均值，用于判断是 CPU/IO 型瓶颈还是锁竞争；
• 分析时需识别四类信号：重复出现的错误模式（error patterns）、与部署事件的关联（可结合 CloudTrail 的UpdateFunctionCode、UpdateService等事件）、性能趋势（performance trends）、依赖故障（downstream failures）。

这一点与仓库中的 aws-cloudwatch-investigation 技能 深度呼应——后者提供了可直接复用的 Logs Insights 查询模板（错误尖峰检测、P99 延迟分解、OOM 检测、超时检测）、告警时间到部署事件的 CloudTrail 关联规则、以及从账号→区域→服务→操作→资源的爆炸半径收窄决策树，可作为本技能 Step 4 的增强工具包。

Step 5：问题分类与根因分析

取证完成后，把所有发现的问题统一分级并归类根因。

严重度分级

技能给出四级标准，分级决定响应速度与处置优先级：

六类根因

技能将根因收敛为六个类别，诊断时逐类排除：

1. 配置问题（Configuration Issues）：错误设置、缺失环境变量、IAM 权限拒绝；
2. 资源约束（Resource Constraints）：CPU/内存/磁盘上限、Lambda 限流、RDS 连接耗尽；
3. 网络问题（Network Issues）：安全组规则、VPC 路由、DNS、NACL；
4. 应用问题（Application Issues）：代码缺陷、内存泄漏、未捕获异常、慢查询；
5. 依赖问题（Dependency Issues）：下游超时、SQS/SNS 故障、外部 API 限流；
6. 安全问题（Security Issues）：KMS 密钥问题、证书过期。

实践中建议先看资源约束与依赖问题（这两类在日志中特征最明显），再排查配置与应用层，最后检查安全项。

Step 6：生成修复计划

修复计划按"紧急性"分三档递进，每一档都要求可执行、可验证。

立即行动（Critical）

针对严重问题的即时止血命令，技能给出了两个典型示例：

# Lambda throttling — increase reserved concurrency aws lambda put-reserved-concurrency \ --function-name <name> --reserved-concurrent-executions 100 # RDS connection exhaustion — reboot to reset connections aws rds reboot-db-instance --db-instance-identifier <name>

• put-reserved-concurrency为 Lambda 设置预留并发，为其保证独立于账号级并发池的吞吐额度，是应对限流的直接手段（数值需按实际流量评估，示例中的 100 为占位值）；
• reboot-db-instance通过重启重置 RDS 连接池，属于恢复性操作——它只能临时缓解连接耗尽，真正的修复还需定位连接泄漏的源头（见短期修复）。

短期修复（High/Medium）

面向根本性调整，包括：配置修正（如正确的环境变量、IAM 权限补齐）、right-sizing（按实际用量调整实例类型/内存规格）、CloudWatch 告警优化（合理阈值与维度）、IAM 修正（最小权限原则下的权限重建）。

长期改进（Low 及架构层）

包括面向韧性的架构改造、预防性监控建设，以及通过 EventBridge 订阅AWS Health Dashboard 通知——将 AWS 侧的服务事件提前接入告警体系，避免"故障发生在 AWS 侧却由业务告警被动发现"。

Step 7：报告与用户确认

技能要求先以结构化简报形式呈现发现，经用户确认后再产出完整报告。简报模板如下：

🏥 AWS Resource Health Assessment 📊 Resource Overview: • Resource: [Name] ([Type]) • Status: [Healthy/Warning/Critical] • Region: [Region] | Account: [Account ID] 🚨 Issues Identified: • Critical: X | High: Y | Medium: Z | Low: N 🔍 Top Issues: 1. [Issue]: [Description] — Impact: [High/Medium/Low] 2. [Issue]: [Description] — Impact: [High/Medium/Low] 🛠️ Remediation: X immediate, Y short-term, Z long-term actions ❓ Proceed with detailed remediation plan? (y/n)

确认后，生成的完整 Markdown 报告必须覆盖五部分：健康指标（health metrics）、带根因分析的问题清单（issues with root cause analysis）、带 AWS CLI 命令的分阶段修复步骤（phased remediation steps）、CloudWatch 告警建议（alarm recommendations）、验证清单（validation checklist）。其中"验证清单"对应技能成功标准中的"实施步骤包含验证与回滚流程"——任何修复动作都应给出"如何确认修复生效"以及"失败时如何回滚"两条路径。

错误处理：常见故障与应对

技能为诊断过程中可能遇到的五类异常预置了处理策略：

其中"权限不足"是实操中最常见的卡点：技能要求的logs:*（Logs Insights 查询）、cloudwatch:*（指标读取）、pi:*（Performance Insights）均为只读范围内的权限，配置时应在满足诊断需求的前提下按最小权限原则收敛。查询超时则提示了 Logs Insights 对扫描数据量的限制——把 24 小时窗口缩到 1～2 小时、并尽量用filter先行裁剪数据，是稳定取回结果的关键。

成功标准：如何判定一次诊断"做完了"

技能在结尾定义了六条完成标准，既是对 Agent 输出的约束，也可作为读者自检清单：

• 关键指标全面覆盖下的资源健康状态准确评估；
• 所有重大问题均已识别并按严重度分级；
• 主要问题完成根因分析；
• 修复计划包含可执行的 AWS CLI 命令；
• 包含 CloudWatch 监控建议；
• 实施步骤包含验证与回滚流程。

这六条标准保证了诊断结果不是"列几个指标就结束"，而是可落地、可审计、可验证的完整交付物。

与仓库内其他技能的组合使用

在 awesome-copilot 仓库的 AWS 技能矩阵中，本技能适合与两个相邻技能配合形成完整闭环：

• aws-resource-query：提供覆盖计算、存储、数据库、网络、安全、消息、成本等领域的自然语言→只读命令映射，适合在诊断前做资源大盘盘点与目标定位；
• aws-cloudwatch-investigation：提供 Logs Insights 查询模板、告警与部署事件关联、爆炸半径收窄决策树，适合在诊断中做深入的日志取证与时间线重建。

三者叠加即可覆盖"盘点资源 → 定位目标 → 健康评估 → 日志取证 → 根因定性 → 修复计划"的全流程，且全部基于 AWS CLI 的只读查询与受控变更命令，不依赖额外 Agent 基建，可直接在 Copilot CLI 会话中按需加载执行。

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot