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 日志与指标采集——这是整个诊断流程的数据基础若未启用后文错误处理一节会给出补救建议。工作流总览七步诊断闭环技能文档将整个诊断过程拆解为七个步骤形成参考→定位→体检→取证→定性→开方→汇报的完整闭环获取 AWS 诊断最佳实践先拉取 CloudWatch 官方监控与故障排查文档让后续诊断方向有据可依资源发现与识别按资源类型用对应 CLI 命令精确定位目标健康状态评估执行服务级健康检查收集关键健康指标日志与指标分析通过 CloudWatch Logs Insights 查询与 Performance Insights 深入取证问题分类与根因分析按严重度分级并映射到六类根因生成修复计划分立即行动 / 短期修复 / 长期改进三档给出可执行命令报告与用户确认结构化展示发现经用户确认后产出完整 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 Nametag:Name,Valuesname # 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标签过滤避免在海量实例中手工比对 IDECS 必须同时提供--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 NameFunctionName,Valuename \ --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 时间计算。各服务类型的关键健康指标技能按服务类型整理了一套看什么指标的清单这是健康评估的核心依据服务类型关键健康指标LambdaError rate错误率、Throttle rate限流率、Duration P99P99 耗时、Concurrent executions并发执行数RDSCPU utilization、FreeStorageSpace、DatabaseConnections、ReadLatency/WriteLatencyECSRunning vs desired task count运行数与期望数对比、task stop reason任务停止原因ALBTargetResponseTime、HTTPCode_ELB_5XX_Count、UnHealthyHostCountSQSApproximateNumberOfMessagesNotVisible、ApproximateAgeOfOldestMessageDynamoDBConsumedReadCapacityUnits、ThrottledRequests、SuccessfulRequestLatency这些指标各自对应一类典型故障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/nameECS 为/aws/ecs/clusterAPI Gateway 为/aws/apigateway/api-id可用--log-group-name-prefix做前缀匹配来发现实际日志组冷启动查询利用 Lambda REPORT 日志中的initDuration字段——该字段存在即代表本次调用经历了初始化冷启动按小时统计可量化冷启动对延迟的贡献RDS Performance Insights 的 identifier 需带db:前缀如db:mydbinstancedb.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问题分类与根因分析取证完成后把所有发现的问题统一分级并归类根因。严重度分级技能给出四级标准分级决定响应速度与处置优先级级别判定标准Critical严重服务不可用、数据丢失、安全事件High高性能退化、错误率 5%、间歇性故障Medium中告警类问题、配置欠优、轻微性能问题Low低信息性提醒、优化机会六类根因技能将根因收敛为六个类别诊断时逐类排除配置问题Configuration Issues错误设置、缺失环境变量、IAM 权限拒绝资源约束Resource ConstraintsCPU/内存/磁盘上限、Lambda 限流、RDS 连接耗尽网络问题Network Issues安全组规则、VPC 路由、DNS、NACL应用问题Application Issues代码缺陷、内存泄漏、未捕获异常、慢查询依赖问题Dependency Issues下游超时、SQS/SNS 故障、外部 API 限流安全问题Security IssuesKMS 密钥问题、证书过期。实践中建议先看资源约束与依赖问题这两类在日志中特征最明显再排查配置与应用层最后检查安全项。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 nameput-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。其中验证清单对应技能成功标准中的实施步骤包含验证与回滚流程——任何修复动作都应给出如何确认修复生效以及失败时如何回滚两条路径。错误处理常见故障与应对技能为诊断过程中可能遇到的五类异常预置了处理策略场景应对方式Resource Not Found资源未找到向用户澄清名称/区域重新定位Authentication Issues认证失败引导用户执行aws configure完成配置Insufficient Permissions权限不足列出所需 IAM 权限logs:*、cloudwatch:*、pi:*No Logs Available无日志可用建议为该资源类型启用 CloudWatch 日志采集Query Timeouts查询超时缩短时间窗口后重试其中权限不足是实操中最常见的卡点技能要求的logs:*Logs Insights 查询、cloudwatch:*指标读取、pi:*Performance Insights均为只读范围内的权限配置时应在满足诊断需求的前提下按最小权限原则收敛。查询超时则提示了 Logs Insights 对扫描数据量的限制——把 24 小时窗口缩到 12 小时、并尽量用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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考