本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# OpsWorks 堆栈故障排除
**重要**
该 AWS OpsWorks Stacks 服务于 2024 年 5 月 26 日终止，新客户和现有客户均已禁用。我们强烈建议客户尽快将其工作负载迁移到其他解决方案。如果您对迁移有疑问，请通过 re [AWS : Post 或通过 Pre](https://repost.aws/) mium Su [AWS pp](https://aws.amazon.com/support) ort 与 AWS 支持 团队联系。
本节包含一些常见的 OpsWorks Stacks 问题及其解决方案。
**Topics**
+ [无法管理实例](#w2ab1c14c77c17b9b9)
+ [Chef 运行后，实例不启动](#w2ab1c14c77c17b9c11)
+ [层的所有实例都没有通过 Elastic Load Balancing 状态检查](#common-issues-troubleshoot-health)
+ [无法与 Elastic Load Balancing 负载均衡器通信](#w2ab1c14c77c17b9c15)
+ [导入的本地实例重启后无法完成卷设置](#w2ab1c14c77c17b9c17)
+ [重启后 EBS 卷不重新连接](#common-issues-troubleshoot-ebs)
+ [无法删除 OpsWorks Stacks 安全组](#common-issues-troubleshoot-booting-secgroup)
+ [意外删除了 OpsWorks Stacks 安全组](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Chef 日志突然终止](#common-issues-troubleshoot-log-terminates)
+ [说明书未更新](#common-issues-troubleshoot-update)
+ [实例停滞在启动状态](#common-issues-troubleshoot-booting)
+ [实例意外重启](#common-issues-troubleshoot-restart)
+ [正在对实例运行 `opsworks-agent` 进程](#common-issues-troubleshoot-agent)
+ [意外的 execute\$1recipes 命令](#common-issues-troubleshoot-unexpected)
## 无法管理实例
**问题：**您无法继续管理过去可管理的实例。在某些情况下，日志可能会显示与以下内容相似的错误。
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**原因：**如果编辑或删除实例所依赖的 OpsWorks 以外的资源，则会发生此错误。下面是一些关于可中断与实例的通信的资源变更的示例。
+ 与该实例关联的 IAM 用户或角色在 OpsWorks 堆栈之外被意外删除。这会导致安装在实例上的 OpsWorks 代理与 OpsWorks Stacks 服务之间的通信失败。在实例的整个生命周期中，都需要与实例关联的 用户。
+ 在实例处于离线状态时编辑卷或存储配置可能会导致实例不可管理。
+ 手动向 ELB 添加 EC2 实例。 OpsWorks 每次实例进入或离开在线状态时，都会重新配置分配的 Elastic Load Balancing 负载均衡器。 OpsWorks 仅将其知道的实例视为有效成员；在其他进程之 OpsWorks外或由其他进程添加的实例将被删除。其他所有实例都将被删除。
**解决方案：**不要删除您的实例所依赖的 IAM 用户或角色。如果可以，仅当从属实例运行时编辑卷或存储配置。 OpsWorks 用于管理实例的负载均衡器或 EIP 成员资格。 OpsWorks 当您注册实例时，为了防止出现意外删除用户后无法管理注册的实例的情况，可将 `--use-instance-profile` 参数添加到您的 `register` 命令，以使用实例的内置实例配置文件。
## Chef 运行后，实例不启动
**问题：**在 Chef 11.10 或配置为使用自定义说明书的较早版本的堆栈上，当 Chef 运行 (使用社区说明书) 后，实例不启动。日志消息可表明配方无法编译 (“配方编译错误”)，或无法负载，因为它们找不到依赖项。
**原因：**最可能的原因是自定义或社区说明书不支持您的堆栈使用的 Chef 版本。一些常见的社区说明书 (如 `[apt](https://supermarket.chef.io/cookbooks/apt)` 和 `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`) 与 Chef 11.10 之间存在已知的兼容性问题。
**解决方案：**在开启了 “**使用自定义 Chef 食谱**” 设置的 Stacks OpsWorks 堆栈上，自定义或社区食谱必须始终支持堆栈使用的 Chef 版本。将社区说明书固定到一个与在您的堆栈设置中配置的 Chef 版本兼容的版本 (即，将说明书版本号设置为特定版本)。要查找受支持的社区说明书版本，请查看无法编译的说明书的变更日志，并仅使用您的堆栈将支持的说明书的最新版本。要固定说明书版本，请在您的自定义说明书存储库的 Berksfile 中指定精确的版本号。例如 `cookbook 'build-essential', '= 3.2.0'`。
## 层的所有实例都没有通过 Elastic Load Balancing 状态检查
**问题：**您将 Elastic Load Balancing 负载均衡器连接到某个应用程序服务器层，但所有实例都没有通过状态检查。
**原因：**当您创建 Elastic Load Balancing 负载均衡器时，您必须指定负载均衡器调用的 ping 路径，以确定实例的状态是否良好。请确保指定适用于您的应用程序的 ping 路径，默认值是 /index.html。如果您的应用程序不包括 `index.html`，您必须指定适当的路径，否则将无法通过状态检查。例如，中使用的简单PHPApp 应用程序[Chef 11 Linux 堆栈入门](gettingstarted.md)不使用 index.html；这些服务器的相应 ping 路径是/。
**解决方案：**编辑负载均衡器的 ping 路径。有关更多信息，请参阅 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)
## 无法与 Elastic Load Balancing 负载均衡器通信
**问题：**您创建一个 Elastic Load Balancing 负载均衡器并将它连接到一个应用程序服务器层，但当您单击负载均衡器的 DNS 名称或 IP 地址以运行该应用程序时，您得到以下错误：“The remote server is not responding (远程服务器未响应)”。
**原因：**如果您的堆栈正在默认 VPC 中运行，则当您在区域中创建 Elastic Load Balancing 负载均衡器时，您必须指定安全组。该安全组必须拥有入口规则，这些规则允许来自您的 IP 地址的入站流量。如果您指定 **default VPC security group**，则默认入口规则不接受任何入站流量。
**解决方案：**编辑安全组入口规则，以接受来自适当 IP 地址的入站流量。
1. 在 [Amazon EC2 控制台的](https://console.aws.amazon.com/ec2/)导航窗格中单击 “**安全组**”。
1. 选择负载均衡器的安全组。
1. 单击 **Inbound** 选项卡上的 **Edit**。
1. 添加入口规则，并将 **Source** 设置为适当的 CIDR。
例如，指定 **Anywhere** 会将 CIDR 设置为 0.0.0.0/0，这会指示负载均衡器接受来自任何 IP 地址的传入流量。
## 导入的本地实例重启后无法完成卷设置
**问题：**您重启已导入 OpsWorks Stacks 的 EC2 实例，Stack OpsWorks s 控制台将实例状态显示为**失败**。Chef 11 或 Chef 12 实例上都会发生此问题。
**原因：**OpsWorks Stacks 在设置过程中可能无法将卷连接到您的实例。一种可能的原因是：当您运行 `setup` 命令时， OpsWorks Stacks 覆盖了您的实例上的卷配置。
**解决方案：**打开实例的 **Details** 页面，检查 **Volumes** 区域中的卷配置。请注意，您只有在实例处于 **stopped** 状态时才能更改您的卷配置。请确保每个卷都拥有指定的挂载点和名称。在重启实例之前，请确认您在 OpsWorks Stacks 的配置中提供了正确的挂载点。
## 重启后 EBS 卷不重新连接
**问题：**您使用 Amazon EC2 控制台将 Amazon EBS 卷连接到实例，但是当您重启该实例时，该卷不再连接。
**原因：** OpsWorks 堆栈只能重新连接它知道的 Amazon EBS 卷，这些卷仅限于以下内容：
+ 由 OpsWorks Stacks 创建的卷。
+ 您账户中的卷，您已明确使用 **Resources** 页面向堆栈注册这些卷。
**解决方案：**只能使用 OpsWorks 堆栈控制台、API 或 CLI 来管理您的 Amazon EBS 卷。如果您想对一个堆栈使用您账户的 Amazon EBS 卷之一，请使用该堆栈的 **资源** 页面注册该卷并将其附加到实例。有关更多信息，请参阅 [资源管理](resources.md)。
## 无法删除 OpsWorks Stacks 安全组
**问题：**删除堆栈后，仍有许多 OpsWorks 堆栈安全组无法删除。
**原因：**必须按照特定的顺序删除安全组。
**解决方案：**首先，确保任何实例都未使用安全组。然后，按照下面的顺序删除以下任何安全组 (如果存在)。
1. AWS-OpsWorks-空白服务器
1. AWS OpsWorks-监控主服务器
1. AWS-db OpsWorks-Master-Server
1. AWS--Memcached OpsWorks-Server
1. AWS-OpsWorks-自定义服务器
1. AWS-nodej OpsWorks s-App-Server
1. AWS--php-App OpsWorks-Server
1. AWS-Rails-App OpsWorks-Server
1. AWS OpsWorks-网络服务器
1. AWS-OpsWorks-默认服务器
1. AWS OpsWorks--LB-Server
## 意外删除了 OpsWorks Stacks 安全组
**问题：**您删除了其中一个 OpsWorks Stacks 安全组，需要重新创建它。
**原因：**这些安全组通常是无意中被删除的。
**解决方案：**重新创建的组必须与原始组完全相同，包括组名称的大写字母也要相同。首选的方法不是手动重新创建组，而是让 OpsWorks Stacks 为您执行此任务。只需在同一 AWS 区域和 VPC（如果有）中创建一个新堆栈， OpsWorks Stacks 就会自动重新创建所有内置安全组，包括您删除的安全组。如果您不再需要该堆栈，则随后您可以删除它；安全组将保留。
## Chef 日志突然终止
**问题：**Chef 日志突然终止；日志结尾未指示运行成功，也未显示异常情况和堆栈跟踪。
**原因：**此行为通常是由于内存不足造成的。
**解决方案：**创建一个较大的实例，然后使用代理 CLI `run_command` 命令再次运行配方。有关更多信息，请参阅 [执行配方](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes)。
## 说明书未更新
**问题：**您更新了说明书，但是堆栈的实例仍然运行旧的配方。
**原因：** OpsWorks Stacks 在每个实例上缓存食谱，并从缓存而不是存储库中运行食谱。当您启动新实例时， OpsWorks Stacks 会将您的食谱从存储库下载到实例的缓存中。但是，如果您随后修改您的自定义说明书，则 OpsWorks Stacks 不会自动更新联机实例的缓存。
**解决方案：**运行 U [pdate Cookbooks 堆栈命令](workingstacks-commands.md)，明确指示 OpsWorks Stacks 更新在线实例的食谱缓存。
## 实例停滞在启动状态
**问题：**当您重启实例或自动修复自动重启实例时，启动操作停滞在 `booting` 状态。
**原因：**引发此问题的一种可能原因是 VPC 配置，包括默认 VPC。实例必须始终能够与 OpsWorks Stacks 服务、Amazon S3 以及软件包、食谱和应用程序存储库进行通信。例如，如果您从默认 VPC 中移除默认网关，则这些实例将失去与 OpsWorks Stacks 服务的连接。由于 OpsWorks Stacks 无法再与实例[代理](troubleshoot-debug-cli.md)通信，因此它会将实例视为失败并且 [auto 对其进行修复。](workinginstances-autohealing.md)但是，如果没有连接， OpsWorks Stacks 就无法在治疗过的实例上安装实例代理。如果没有代理， OpsWorks Stacks 就无法在实例上运行安装配方，因此启动操作无法超出 “启动” 状态。
**解决方案：**修改您的 VPC 配置，以便实例拥有所需的连接。
## 实例意外重启
**问题：**已经停止的实例意外重启。
**原因 1：**如果您为实例启用了[自动修复](workinginstances-autohealing.md)， OpsWorks Stacks 会定期对关联的 Amazon EC2 实例执行运行状况检查，并重新启动任何运行状况不佳的实例。如果您使用亚马逊 EC2 控制台、API 或 C OpsWorks LI 停止或终止堆栈管理的实例，则不会通知 OpsWorks 堆栈。它会认为已停止的实例状态不佳，并自动重启该实例。
**解决方案：**仅使用 OpsWorks Stacks 控制台、API 或 CLI 管理您的实例。如果您使用 OpsWorks Stacks 停止或删除实例，则该实例不会重启。有关更多信息，请参阅[手动启动、停止和重启全天候实例](workinginstances-starting.md)和[删除 OpsWorks 堆栈实例](workinginstances-delete.md)。
**原因 2：**实例可能会因为各种原因而失败。如果您启用了自动修复， OpsWorks Stacks 会自动重启失败的实例。
**解决方案：**这是正常操作；除非您不希望 OpsWorks Stacks 重启失败的实例，否则无需执行任何操作。在这种情况下，您应当禁用自动修复功能。
## 正在对实例运行 `opsworks-agent` 进程
**问题：**正在对您的实例运行多个 `opsworks-agent` 进程。例如：
```
aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24
```
**原因：**这些是执行代理的常规操作所需的合法进程。它们执行诸如处理部署以及将保持活动状态的消息发送回服务等任务。
**解决方案：**这是常规行为。不要停止这些进程；这样会影响代理的操作。
## 意外的 execute\$1recipes 命令
**问题：**实例的详细信息页面上的 **Logs** 部分包含意外的 `execute_recipes` 命令。意外的 `execute_recipes` 命令还可能显示在 **Stack** 和 **Deployments** 页面上。
**原因：**此问题通常是由权限变更导致的。当您更改用户或组的 SSH 或 sudo 权限时， OpsWorks Stacks 会运行`execute_recipes`以更新堆栈的实例，还会触发配置事件。出现 `execute_recipes` 命令的另一个原因是 OpsWorks Stacks 更新了实例代理。
**解决方案：**这是常规操作；无需执行其任何他操作。
要了解 `execute_recipes` 命令执行了哪些操作，请转到 **Deployments** 页面并单击该命令的时间戳。这会打开该命令的详细信息页面，上面列出了已经运行的关键配方。例如，以下详细信息页面对应的是运行了 `ssh_users` 以更新 SSH 权限的 `execute_recipes` 命令。
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/zh_cn/opsworks/latest/userguide/images/command_details.png)
要查看所有详细信息，单击该命令的 **Log** 列中的 **show** 以显示关联的 Chef 日志。在日志中搜索**Run List**。 OpsWorks 堆栈维护配方将出炉。`OpsWorks Custom Run List`例如，下面是上文中的屏幕截图中显示的 `execute_recipes` 命令的运行列表，其中显示了与该命令相关联的每个配方。
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```