DevOps知识中心
DevOps知识中心

精通 AWS 故障排除工作流程的专家指南

通过这份专家指南精通 AWS 故障排除，其中详细介绍了一个可重复的工作流程，可快速隔离并解决复杂的i基础设施问题。学习如何利用 Amazon CloudWatch 等关键工具来获取指标和日志，以及利用 AWS CloudTrail 来跟踪 API 活动，从而帮助您查明从连接问题到权限错误和服务限制等各种根本原因。本文提供了可操作的步骤、实用示例和最佳实践，以提高您的诊断技能并维护健壮、高性能的 AWS 环境。

38 浏览量

掌握 AWS 故障排除工作流的专家指南

在亚马逊网络服务 (AWS) 动态而复杂的环境中，高效识别和解决问题对于维护应用程序的可用性和性能至关重要。即使是最健壮的架构，也可能出现问题——从细微的连接故障和令人困惑的权限错误，到严苛的服务限制。掌握 AWS 故障排除的艺术能将已被动的问题解决转化为一个精简、可重复的过程，从而最大限度地减少停机时间和运营开销。

本指南旨在为您提供专家级的 AWS 故障排除理解。我们将建立一个系统化的工作流程，重点介绍 CloudWatch 和 CloudTrail 等关键 AWS 工具，并深入探讨必要的调查步骤。我们的目标是使您能够快速隔离服务故障和复杂基础设施问题的根本原因，确保您的 AWS 环境平稳可靠地运行。

核心 AWS 故障排除工作流

一个有效的故障排除工作流不是一系列随机操作，而是一种结构化的方法，指导您从问题检测到解决和预防。采用可重复的过程可确保一致性，减轻压力，并加速事件解决。

1. 定义问题：收集初始信息

第一步是清楚地了解正在发生什么。避免做出假设。尽可能收集客观信息。

  • 症状：具体是什么在失败或行为异常？（例如，“API 调用超时”、“网站返回 5xx 错误”、“EC2 实例无法访问”）。
  • 范围：问题有多普遍？（例如，单个实例、特定应用程序、整个区域、特定用户）。它影响的是生产环境、预演环境还是开发环境？
  • 影响：业务影响是什么？（例如，收入损失、客户不满意、安全风险）。
  • 上次正常状态：它上次正确工作是什么时候？
  • 错误消息：收集来自应用程序、浏览器控制台或直接 AWS 服务响应的任何错误消息。

提示：鼓励用户或系统提供具体的错误消息和时间戳。这些数据是无价的。

2. 验证范围：隔离受影响的组件

一旦问题被定义，就要缩小潜在影响范围。这有助于您集中调查精力。

  • 服务运行状况控制面板：检查 AWS 服务运行状况控制面板 以了解正在进行的区域性问题。大规模中断通常可以解释许多症状。
  • 隔离资源：如果 Web 服务器出现故障，是只有一个 EC2 实例还是所有实例都出现故障？数据库是否可以从其他实例访问？
  • 复现：问题能否稳定复现？如果可以，在什么条件下？

3. 查看最近的更改：识别潜在的触发器

大多数问题都是由更改触发的。这通常是解决问题的最快途径。

  • 部署更改：新代码部署、基础设施即代码 (IaC) 更新。
  • 配置更改：安全组修改、IAM 策略更新、负载均衡器设置、数据库参数组。
  • 扩缩事件：自动扩缩活动、服务的手动扩缩。
  • AWS CloudFormation / Terraform：查看最近的堆栈更新或资源更改。

工具亮点：AWS CloudTrail 是您的主要工具，它显示了谁在何时何地做了什么。

4. 利用 AWS 监控工具：深入挖掘数据

在这里，您将利用 AWS 的原生可观测性工具来收集经验证据。

  • Amazon CloudWatch：用于指标、日志和告警。
  • AWS CloudTrail：用于 API 活动和更改历史记录。
  • VPC Flow Logs：用于网络流量分析。
  • AWS Config：用于配置历史记录和合规性。
  • 应用程序日志：来自在 EC2、ECS、Lambda 等上运行的应用程序的日志。

5. 制定和测试假设：发展和验证理论

根据收集到的数据，就根本原因提出一个或多个假设。然后，系统地测试每一个假设。

  • 假设示例：“EC2 实例无法访问，因为其安全组不允许入站 SSH 流量。”
  • 测试：检查安全组规则。如有必要，暂时修改它们（谨慎操作并有回滚计划），以查看连接是否恢复。

6. 实施和验证解决方案：应用修复并确认解决

一旦假设得到证实，就应用修复。谨慎操作，如果可能，请先在受控环境中进行。

  • 修复：更新 IAM 策略、重新配置安全组、回滚代码部署、扩缩服务。
  • 验证：确保原始症状消失，且没有引入新问题。修复后监控相关指标和日志。

7. 记录和学习：改进未来的故障排除

每个事件都是一个学习机会。记录问题、调查步骤、解决方案和预防措施至关重要。

  • 事件报告：创建一份简要报告，详细说明时间线、症状、根本原因、解决方案和经验教训。
  • 知识库：添加到团队的知识库中，以供将来参考。
  • 预防措施：实施监控、告警或架构更改以防止再次发生。
  • 事后分析：进行无指责的事后分析，以识别系统性弱点。

深入了解关键 AWS 故障排除工具

AWS 提供了一套强大的工具来协助故障排除。了解它们的优势是关键。

Amazon CloudWatch

CloudWatch 以日志、指标和事件的形式收集监控和操作数据。它对于理解 AWS 资源和应用程序的健康状况及性能至关重要。

  • 指标：可视化性能数据（CPU 利用率、网络 I/O、磁盘操作、数据库连接、Lambda 调用/错误）。为您的应用程序创建自定义指标。
  • 日志：集中管理来自 EC2 实例 (CloudWatch Agent)、Lambda 函数、VPC Flow Logs、CloudTrail Logs 等的日志。使用 CloudWatch Logs Insights 进行强大的查询。
  • 告警：在指标上设置阈值，以便在出现问题时触发通知（SNS、Lambda）。

实际示例：调查无响应的 EC2 实例

  1. 检查 EC2 实例状态检查：在 EC2 控制台中，查看实例的状态检查（系统状态和实例状态）。如果其中任何一个失败，则是一个强烈的指示。
  2. CloudWatch 指标：导航到该实例的 CloudWatch 指标。
    • CPUUtilization：CPU 是否一直处于 100%？
    • NetworkIn/NetworkOut：是否有意外流量或突然下降？
    • DiskReadOps/DiskWriteOps：磁盘 I/O 是否饱和？
    • StatusCheckFailed_Instance / StatusCheckFailed_System：如果检查失败，这些指标将为 1。
  3. CloudWatch Logs：如果配置了 CloudWatch Agent，检查 /aws/ec2/instance_id/ 以获取应用程序或系统日志（例如，syslog、nginx_access_log）。使用 CloudWatch Logs Insights 查询错误或特定事件。
# CloudWatch Logs Insights 查询示例，用于查找 EC2 实例日志中的错误
fields @timestamp, @message
| sort @timestamp desc
| filter @message like /ERROR|FAIL|EXCEPTION/ and @logStream = 'i-0abcdef1234567890'
| limit 50

AWS CloudTrail

CloudTrail 记录您 AWS 账户中进行的所有 API 调用，提供用户、角色或 AWS 服务执行的操作历史记录。它对于安全审计、合规性，以及最重要的是故障排除更改至关重要。

  • 事件历史：查看管理事件的历史记录（例如，RunInstances、AuthorizeSecurityGroupIngress、UpdateFunctionConfiguration）。
  • 数据事件：配置跟踪以记录 S3 对象、Lambda 函数调用等的数据平面操作。

实际示例：诊断 IAM 权限错误（“访问被拒绝”）

应用程序或用户在尝试执行 AWS 操作（例如，s3:GetObject）时收到“访问被拒绝”错误。

  1. 识别失败操作：哪个具体的 AWS API 调用失败了？
  2. 前往 CloudTrail 事件历史记录：按以下条件筛选事件：
    • 事件名称：精确的 API 调用（例如，GetObject）。
    • 用户名：发出调用的 IAM 用户或角色。
    • 事件源：涉及的 AWS 服务（例如，s3.amazonaws.com）。
    • 时间范围：错误发生的时间点附近。
  3. 检查事件详情：查找 errorCode: "AccessDenied" 的事件。
    • errorMessage 字段通常提供有关缺少特定权限或资源策略违规的线索。
    • requestParameters 字段显示传入的参数，例如 S3 存储桶或键。
    • userIdentity 字段确认了谁尝试了该操作。

这将精确指出哪个用户或角色尝试对哪个资源执行了哪个操作，并因权限问题而失败，从而使您能够修改相关的 IAM 策略或资源策略。

AWS Config

AWS Config 提供您的 AWS 资源的详细清单、其配置以及它们随时间变化的方式。它可以根据所需的设置评估配置更改。

  • 配置历史：查看资源的配置如何更改（例如，何时添加或删除了安全组规则，或修改了 S3 存储桶策略）。
  • 合规性：定义规则以根据最佳实践或监管要求检查资源配置。

用例：如果应用程序突然失去对数据库的访问权限，您可以使用 AWS Config 检查数据库的安全组是否最近被修改，这可能撤销了您的应用程序实例的访问权限。

VPC Flow Logs

VPC 流日志捕获进出 VPC 中网络接口的 IP 流量信息。它们对于解决网络连接问题非常有价值。

  • 流量分析：识别被阻止的流量（REJECT 操作）、意外连接或进出特定 IP 的大量流量。
  • 排查连接问题：确定安全组、NACL 或路由表是否正在阻止合法流量。

用例：您的 EC2 实例无法连接到外部 API。检查流日志中从实例 ENI 到 API IP 地址的 REJECT 条目，这可能表明安全组或网络 ACL 限制。

AWS Systems Manager

Systems Manager 提供了一个统一界面，用于查看来自多个 AWS 服务的操作数据并自动化操作任务。用于故障排除的关键组件包括：

  • Session Manager：无需打开入站端口（如 SSH 端口 22）即可安全地通过 shell 连接到 EC2 实例，从而降低安全风险并简化访问。
  • Run Command：在 EC2 实例上远程执行脚本或命令，以收集诊断数据或应用修复（例如，重启服务、检索日志）。
  • 自动化：创建运行手册以自动化常见的故障排除和修复步骤。

常见的 AWS 故障排除场景和解决方案

连接问题

连接问题很常见，可能源于各种网络组件。

  • 安全组：作为 EC2 实例的虚拟防火墙。检查入站和出站规则，以了解所需的端口和 IP 范围。
  • 网络访问控制列表 (NACL)：子网级别的无状态防火墙。检查入站和出站规则，注意规则顺序和显式的 DENY 规则。
  • 路由表：确保存在适当的路由，使流量能够到达其目的地（例如，公共流量的 Internet Gateway，私有实例访问互联网的 NAT Gateway，VPC 间通信的 VPC Peering）。
  • DNS 解析：验证实例能否解析主机名。检查 VPC DNS 设置和任何自定义 DNS 服务器。
  • 子网 CIDR 重叠：如果使用 VPC 对等连接或 VPN，请确保没有重叠的 CIDR 块。

权限错误（访问被拒绝）

当 IAM 主体（用户、角色）在没有必要权限的情况下尝试执行操作时，就会发生这些错误。

  • IAM 策略：最常见的罪魁祸首。检查附加到用户或角色的 IAM 策略。使用 IAM 策略模拟器 测试特定操作和资源。
  • 资源策略：对于 S3、SQS、KMS 和 ECR 等服务，资源策略定义了谁可以访问资源。确保在此处授予调用主体访问权限。
  • 服务控制策略 (SCP)：如果使用 AWS Organizations，SCP 可能会在账户或组织单位 (OU) 级别限制操作。
  • 权限边界：一种高级 IAM 功能，可以限制 IAM 实体可以拥有的最大权限。
  • 会话策略：可以覆盖或限制身份有效权限的临时策略。

服务限制与节流

AWS 服务有软限制和硬限制。达到这些限制可能导致服务降级或故障。

  • 监控限制：通过 AWS Service Quotas 控制台定期检查您的服务配额。为接近临界限制的指标创建 CloudWatch 告警。
  • 请求增加：大多数软限制可以通过向 AWS 提交支持工单来增加。
  • 节流：当调用速率超出预置容量或突发限制时，Lambda、DynamoDB 和 API Gateway 等服务可能会对请求进行节流。在日志中查找 TooManyRequestsException 或 ThrottlingException 错误。
  • 扩缩：确保您的 Auto Scaling Groups、ECS 服务或数据库只读副本配置为根据需求进行充分扩缩。

主动故障排除的最佳实践

预防总是胜于治疗。实施这些实践以最大程度地减少事件并加速解决。

  1. 实施强大的监控和告警：为关键指标、系统健康状况和应用程序错误配置 CloudWatch 告警。与通知系统（SNS、Slack、PagerDuty）集成。
  2. 集中式日志记录：将所有应用程序和基础设施日志整合到 CloudWatch Logs 或专用日志解决方案中（例如，EC2/ECS 上的 ELK 堆栈、Datadog、Splunk）。
  3. 基础设施即代码 (IaC)：使用 CloudFormation、Terraform 或 CDK 管理您的基础设施。这提供了版本控制并简化了回滚。
  4. 最小权限原则：仅授予用户和角色必要的权限。这减少了潜在安全事件的影响范围，并简化了权限故障排除。
  5. 定期审查 IAM 策略：定期审计 IAM 策略，查找过于宽松的语句或未使用的权限。
  6. 了解服务限制：了解您区域和账户的默认服务配额。主动请求增加配额以应对预期增长。
  7. 自动化常见任务：使用 AWS Systems Manager Automation 或 Lambda 函数来自动化诊断检查和针对重复出现问题的修复。
  8. 标签策略：为所有资源实施一致的标签策略。这有助于在故障排除期间组织、成本分配和筛选资源。
  9. 实践事件响应：定期进行关键事件演练。这有助于团队在压力下熟悉工作流程和工具。

结论

掌握 AWS 故障排除工作流是一个持续的旅程，它结合了系统化调查和对 AWS 服务及工具的深入理解。通过采用结构化的方法——从定义问题到记录解决方案——并有效利用 CloudWatch、CloudTrail 和 VPC Flow Logs 等强大服务，您可以显著提高诊断和解决最复杂问题的能力。拥抱主动监控、持续学习和无指责事后分析的文化，以构建更具弹性、更高性能的 AWS 环境。