本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 偵錯和故障診斷指南
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
如果您需要除錯配方或故障診斷服務問題，最佳的方法通常是遵循以下步驟依序操作：
1. 檢查[常見的除錯和故障診斷問題](common-issues.md)是否有您的特定問題。
1. 搜尋 [OpsWorks Stacks 論壇](https://forums.aws.amazon.com/forum.jspa?forumID=153#)，查看是否已討論過這些問題。
論壇包含許多經驗豐富的使用者，並由 OpsWorks Stacks 團隊監控。
1. 對於配方的問題，請參閱[除錯配方](troubleshoot-debug.md)。
1. 聯絡 OpsWorks Stacks 支援或在 [OpsWorks Stacks 論壇](https://forums.aws.amazon.com/forum.jspa?forumID=153#)上張貼您的問題。
下節提供除錯配方的指導方針。最終節說明常見的除錯和故障診斷問題及其解決方案。
**注意**
每個 Chef 執行都會產生日誌，詳細描述回合的狀況，是寶貴的故障診斷資源。若要指定日誌中詳細資訊的數量，請將 [https://docs.chef.io/resource_log.html](https://docs.chef.io/resource_log.html) 陳述式新增至指定所需日誌層級的自訂配方。預設值為 `:info`。以下範例說明如何將 Chef 日誌層級設定為 `:debug`，提供最詳細的回合描述。
```
Chef::Log.level = :debug
```
如需檢視和解釋 Chef 日誌的詳細資訊，請參閱 [Chef 日誌](troubleshoot-debug-log.md)。
**Topics**
+ [除錯配方](troubleshoot-debug.md)
+ [常見的除錯和故障診斷問題](common-issues.md)
# 除錯配方
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
當生命週期事件發生，或您執行[執行配方堆疊命令](workingstacks-commands.md)時， OpsWorks Stacks 會向[代理程式](troubleshoot-debug-cli.md)發出命令，在指定的執行個體上初始化 [Chef Solo 執行](https://docs.chef.io/ctl_chef_solo.html)，以執行適當的配方，包括您的自訂配方。本節說明一些您可以為失敗配方除錯的方法。
**Topics**
+ [登入故障的執行個體](troubleshoot-debug-login.md)
+ [Chef 日誌](troubleshoot-debug-log.md)
+ [使用 OpsWorks Stacks 代理程式 CLI](troubleshoot-debug-cli.md)
# 登入故障的執行個體
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
如果配方失敗，執行個體將會以 `setup_failed` 狀態結束，而不是線上狀態。即使與 OpsWorks Stacks 相關的執行個體尚未上線，EC2 執行個體仍在執行中，登入對問題進行疑難排解通常很有用。例如，您可以檢查應用程式或自訂技術指南是否已正確安裝。Stacks OpsWorks 內建的 [SSH](workinginstances-ssh.md) 和 [RDP](workinginstances-rdp.md) 登入支援僅適用於處於線上狀態的執行個體。不過，如果您已為執行個體指派 SSH 金鑰對，您仍可登入，說明如下：
+ Linux 執行個體 – 使用 SSH 金鑰對的私有金鑰來登入第三方 SSH 用戶端，例如 OpenSSH 或 PuTTY。
您可以使用 EC2 金鑰對或您的[個人 SSH 金鑰對](security-ssh-access.md)登入。
+ Windows 執行個體 – 使用 EC2 金鑰對的私有金鑰來擷取執行個體的管理員密碼。
使用該密碼透過您偏好的 RDP 用戶端登入。如需詳細資訊，請參閱[以管理員身分登入](workinginstances-rdp.md#workinginstances-rdp-admin)。您無法使用[個人 SSH 金鑰對](security-ssh-access.md)擷取管理員密碼。
# Chef 日誌
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
Chef 日誌是您的關鍵疑難排解資源之一，特別是用於偵錯配方。 OpsWorks Stacks 會擷取每個命令的 Chef 日誌，並保留執行個體最近 30 個命令的日誌。由於執行處於除錯模式，因此日誌內含 Chef 執行的詳細說明，包括傳送到 `stdout` 和 `stderror` 的文字。如果配方失敗，日誌會包含 Chef 堆疊追蹤。
OpsWorks Stacks 提供數種檢視 Chef 日誌的方式。一旦您擁有日誌資訊，就可用其為失敗配方除錯。
**注意**
您也可以透過使用 SSH 連線到執行個體並執行代理程式 CLI `show_log` 命令，來檢視指定日誌的結尾。如需詳細資訊，請參閱[顯示 Chef 日誌](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log)。
**Topics**
+ [使用主控台檢視 Chef 日誌](#troubleshoot-debug-log-console)
+ [使用 CLI 或 API 檢視 Chef 日誌](#troubleshoot-debug-log-cli)
+ [在執行個體上檢視 Chef 日誌](#troubleshoot-debug-log-instance)
+ [解讀 Chef 日誌](#troubleshoot-debug-log-interpret)
+ [常見的 Chef 日誌錯誤](#troubleshoot-debug-log-errors)
## 使用主控台檢視 Chef 日誌
檢視 Chef 日誌最簡單的方法是前往執行個體的詳細資訊頁面。**Logs (日誌)** 區段包含每個事件和[執行配方](workingstacks-commands.md)命令的進入點。下圖為執行個體的 **Logs (日誌)** 區段，顯示的內容是 **configure (設定)** 和 **setup (安裝)** 命令的日誌，兩者分別對應到設定和安裝生命週期事件。
![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs11.png)
按一下適當命令的**日誌**欄中的**顯示**，以檢視對應的 Chef 日誌。如果發生錯誤， OpsWorks Stacks 會自動將日誌開啟為錯誤，通常位於檔案結尾。
## 使用 CLI 或 API 檢視 Chef 日誌
您可以使用 OpsWorks Stacks CLI [https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)命令或 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html) API 動作來檢視存放在 Amazon S3 儲存貯體上的日誌。以下說明如何使用 CLI 檢視指定執行個體目前任一組日誌檔案。使用 `DescribeCommands` 的程序基本上很類似。
**使用 OpsWorks Stacks 檢視執行個體的 Chef 日誌**
1. 開啟執行個體的詳細資訊頁面，並複製其 **OpsWorks ID** 值。
1. 使用此 ID 值執行 `describe-commands` CLI 命令，如下所示：
```
aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9
```
該命令會針對 OpsWorks Stacks 在執行個體上執行的每個命令，傳回具有內嵌物件的 JSON 物件，並以最新的先到者為準。`Type` 參數包含每個內嵌物件的命令類型，在此範例中為 `configure` 命令和 `setup` 命令。
```
{
"Commands": [
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:38:36+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:38:24+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/b6c402df-5c23-45b2-a707-ad20b9c5ae40?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=YkqS5IZN2P4wixjHwoC3aCMbn5s%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "configure",
"CommandId": "b6c402df-5c23-45b2-a707-ad20b9c5ae40",
"CreatedAt": "2013-10-25T19:38:11+00:00",
"ExitCode": 0
},
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:31:08+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:29:01+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/2a90e862-f974-42a6-9342-9a4f03468358?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=cxKYHO8mCCd4MvOyFb6ywebeQtA%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "setup",
"CommandId": "2a90e862-f974-42a6-9342-9a4f03468358",
"CreatedAt": "2013-10-25T19:26:01+00:00",
"ExitCode": 0
}
]
}
```
1. 將 `LogUrl` 值複製到瀏覽器以檢視日誌。
如果執行個體具有多個命令，您可以將參數新增至 `describe-commands`，篩選出哪些命令應包含在回應物件中。如需詳細資訊，請參閱 [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)。
## 在執行個體上檢視 Chef 日誌
**注意**
本節中的主題適用於 Chef 12。如需 Chef 11.10 和較舊版 Chef 日誌位置的資訊，請參閱[為 Linux 的 Chef 11.10 和更舊版本進行故障診斷](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshooting-chef-11-linux.html)。
### Linux 執行個體
OpsWorks Stacks 會將每個執行個體的 Chef 日誌存放在其`/var/chef/runs`目錄中。(對於 Linux 執行個體，此目錄也包含相關聯的[資料包](data-bags.md)，其以 JSON 格式的檔案存放)。您需要 [sudo 權限](opsworks-security-users.md)才能存取此目錄。每個執行的日誌位於個別執行子目錄中名為 `chef.log` 的檔案。
OpsWorks Stacks 會將其內部日誌存放在執行個體的 `/var/log/aws/opsworks` 資料夾中。此資訊通常對故障診斷的幫助不大。不過，這些日誌對於 OpsWorks Stacks 支援很有用，如果您遇到服務問題，可能會要求您提供這些日誌。Linux 日誌有時也可提供有用的故障診斷資料。
### Windows 執行個體
**代理程式日誌**
在 Windows 執行個體上，OpsWorks 日誌存放於 `ProgramData` 路徑，如下所示。數字會包含時間戳記。
```
C:\ProgramData\OpsWorksAgent\var\logs\number
```
**注意**
根據預設，`ProgramData` 是隱藏的資料夾。若要將其取消隱藏，請導覽至 **Folder Options (資料夾選項)**。在 **View (檢視)** 下，選擇顯示隱藏檔案的選項。
下列範例示範 Windows 執行個體上的代理程式日誌。
```
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 5/24/2015 11:59 PM 127277 command.20150524.txt
-a--- 5/25/2015 11:59 PM 546772 command.20150525.txt
-a--- 5/26/2015 11:59 PM 551514 command.20150526.txt
-a--- 5/27/2015 9:43 PM 495181 command.20150527.txt
-a--- 5/24/2015 11:59 PM 24353 keepalive.20150524.txt
-a--- 5/25/2015 11:59 PM 106232 keepalive.20150525.txt
-a--- 5/26/2015 11:59 PM 106208 keepalive.20150526.txt
-a--- 5/27/2015 8:54 PM 92593 keepalive.20150527.txt
-a--- 5/24/2015 7:19 PM 3891 service.20150524.txt
-a--- 5/27/2015 8:54 PM 1493 service.20150527.txt
-a--- 5/24/2015 11:59 PM 112549 wire.20150524.txt
-a--- 5/25/2015 11:59 PM 501501 wire.20150525.txt
-a--- 5/26/2015 11:59 PM 499640 wire.20150526.txt
-a--- 5/27/2015 8:54 PM 436870 wire.20150527.txt
```
**Chef 日誌**
在 Windows 執行個體上，Chef 日誌存放於 `ProgramData` 路徑，如下所示。數字會包含時間戳記。
```
C:\ProgramData\OpsWorksAgent\var\commands\number
```
**注意**
此目錄僅包含第一個 (OpsWorks 擁有的) Chef 執行的輸出。
下列範例示範 Windows 執行個體上 OpsWorks 擁有的 Chef 日誌。
```
Mode LastWriteTime Name
---- ------------- ----
d---- 5/24/2015 7:23 PM configure-7ecb5f47-7626-439b-877f-5e7cb40ab8be
d---- 5/26/2015 8:30 PM configure-8e74223b-d15d-4372-aeea-a87b428ffc2b
d---- 5/24/2015 6:34 PM configure-c3980a1c-3d08-46eb-9bae-63514cee194b
d---- 5/26/2015 8:32 PM grant_remote_access-70dbf834-1bfa-4fce-b195-e50e85402f4c
d---- 5/26/2015 10:30 PM revoke_remote_access-1111fce9-843a-4b27-b93f-ecc7c5e9e05b
d---- 5/24/2015 7:21 PM setup-754ec063-8b60-4cd4-b6d7-0e89d7b7aa78
d---- 5/26/2015 8:27 PM setup-af5bed36-5afd-4115-af35-5766f88bc039
d---- 5/24/2015 6:32 PM setup-d8abeffa-24d4-414b-bfb1-4ad07319f358
d---- 5/24/2015 7:13 PM shutdown-c7130435-9b5c-4a95-be17-6b988fc6cf9a
d---- 5/26/2015 8:25 PM sync_remote_users-64c79bdc-1f6f-4517-865b-23d2def4180c
d---- 5/26/2015 8:48 PM update_custom_cookbooks-2cc59a94-315b-414d-85eb-2bdea6d76c6a
```
**使用者 Chef 日誌**
您可以在名為 `logfile.txt` 的檔案中找到您 Chef 執行的日誌，該檔案則位於以編號之 Chef 命令命名的資料夾中，如下圖所示。
C:/chef └── `runs` └── `command-12345` ├── `attribs.json` ├── `client.rb` └── `logfile.txt`
## 解讀 Chef 日誌
日誌的開頭主要包含內部 Chef 記錄。
```
# Logfile created on Thu Oct 17 17:25:12 +0000 2013 by logger.rb/1.2.6
[2013-10-17T17:25:12+00:00] INFO: *** Chef 11.4.4 ***
[2013-10-17T17:25:13+00:00] DEBUG: Building node object for php-app1.localdomain
[2013-10-17T17:25:13+00:00] DEBUG: Extracting run list from JSON attributes provided on command line
[2013-10-17T17:25:13+00:00] INFO: Setting the run_list to ["opsworks_custom_cookbooks::load", "opsworks_custom_cookbooks::execute"] from JSON
[2013-10-17T17:25:13+00:00] DEBUG: Applying attributes from json file
[2013-10-17T17:25:13+00:00] DEBUG: Platform is amazon version 2013.03
[2013-10-17T17:25:13+00:00] INFO: Run List is [recipe[opsworks_custom_cookbooks::load], recipe[opsworks_custom_cookbooks::execute]]
[2013-10-17T17:25:13+00:00] INFO: Run List expands to [opsworks_custom_cookbooks::load, opsworks_custom_cookbooks::execute]
[2013-10-17T17:25:13+00:00] INFO: Starting Chef Run for php-app1.localdomain
[2013-10-17T17:25:13+00:00] INFO: Running start handlers
[2013-10-17T17:25:13+00:00] INFO: Start handlers complete.
[2013-10-17T17:25:13+00:00] DEBUG: No chefignore file found at /opt/aws/opsworks/releases/20131015111601_209/cookbooks/chefignore no files will be ignored
[2013-10-17T17:25:13+00:00] DEBUG: Cookbooks to compile: ["gem_support", "packages", "opsworks_bundler", "opsworks_rubygems", "ruby", "ruby_enterprise", "dependencies", "opsworks_commons", "scm_helper", :opsworks_custom_cookbooks]
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook gem_support's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/gem_support/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook packages's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/packages/libraries/packages.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook dependencies's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/dependencies/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/activesupport_blank.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/monkey_patch_chefgem_resource.rb
...
```
檔案的這一部分對 Chef 專家來說非常有用。請注意，即使大多數命令包含更多配方，執行清單僅含兩個配方。這兩個配方處理載入和執行其他所有內建和自訂配方的任務。
檔案最有趣的部分通常在結尾。如果執行成功結束，您應該會看到類似以下的內容：
```
...
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: STDERR:
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: ---- End output of /sbin/service mysqld restart ----
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Ran /sbin/service mysqld restart returned 0
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: service[mysql]: restarted successfully
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Chef Run complete in 84.07096 seconds
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: cleaning the checksum cache
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-8wef7e-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-1xpwyb6-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--etc-monit-conf
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Running report handlers
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Report handlers complete
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Exiting
```
**注意**
您可以使用代理程式 CLI 在執行期間或結束後顯示日誌結尾。如需詳細資訊，請參閱[顯示 Chef 日誌](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log)。
如果配方失敗，您應該尋找 ERROR 層級的輸出，該輸出將包含例外狀況，並接續著 Chef 堆疊追蹤，如下所示：
```
...
Please report any problems with the /usr/scripts/mysqlbug script!
[ OK ]
MySQL Daemon failed to start.
Starting mysqld: [FAILED]STDERR: 130611 15:07:55 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
130611 15:07:56 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
---- End output of /sbin/service mysqld start ----
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:184:in `handle_command_failures'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:131:in `run_command'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service/init.rb:37:in `start_service'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service.rb:60:in `action_start'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `send'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:53:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `each'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:84:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:268:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:158:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:190:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `loop'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application.rb:62:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/chef-solo:25
/opt/aws/opsworks/current/bin/chef-solo:16:in `load'
/opt/aws/opsworks/current/bin/chef-solo:16
```
檔案的結尾是 Chef 堆疊追蹤。您也應該檢查例外狀況之前的輸出，通常包含系統錯誤 (例如 `package not available`)，這在故判斷失敗原因時也很有用。在此範例中，MySQL 協助程式無法啟動。
## 常見的 Chef 日誌錯誤
下列是一些常見的 Chef 日誌錯誤及其解決方法。
找不到日誌
在 Chef 執行開始時，執行個體會收到預先簽章的 Amazon S3 URL，可讓您在 Chef 執行完成時在網頁上檢視日誌。由於此 URL 會在兩個小時後過期，因此如果 Chef 執行需要超過兩個小時，即使 Chef 執行期間沒有發生任何問題，也不會將日誌上傳至 Amazon S3 網站。建立日誌的命令會成功，但僅可在執行個體上檢視日誌，而不能在預先簽章的 URL 上檢視。
日誌意外結束
如果 Chef 日誌意外結束，並未指出成功或顯示錯誤資訊，您可能發生記憶體低下的狀態，讓 Chef 無法完成日誌。最佳選項就是使用更大的執行個體重試。
缺少技術指南或配方
如果 Chef 執行發生技術指南或配方不在技術指南快取內的情況，您將看到類似以下的內容：
```
DEBUG: Loading Recipe mycookbook::myrecipe via include_recipe
ERROR: Caught exception during execution of custom recipe: mycookbook::myrecipe:
Cannot find a cookbook named mycookbook; did you forget to add metadata to a cookbook?
```
此項目指出 `mycookbook` 技術指南不在技術指南快取內。使用 Chef 11.4 時，如果您未在 `metadata.rb` 中正確宣告相依性，也可能發生此錯誤。
OpsWorks Stacks 會從執行個體的技術指南快取執行配方。其會在執行個體啟動時，將儲存庫中的技術指南下載到此快取中。不過，如果您後續修改儲存庫中的技術指南， OpsWorks Stacks 不會自動更新線上執行個體上的快取。如果您在執行個體啟動後，修改技術指南或新增技術指南，請執行以下步驟：
1. 確定您已將變更遞交到儲存庫。
1. 執行[更新技術指南堆疊命令](workingstacks-commands.md)，以使用儲存庫中的最新版本來更新技術指南快取。
本機命令失敗
如果 Chef `execute` 資源無法執行指定命令，您將會看到類似以下的內容：
```
DEBUG: ---- End output of ./configure --with-config-file-path=/ returned 2
ERROR: execute[PHP: ./configure] (/root/opsworks-agent/site-cookbooks/php-fpm/recipes/install.rb line 48) had an error:
./configure --with-config-file-path=/
```
向上捲動日誌，您應該會看到命令的 `stderr` 和 `stdout` 輸出，這有助您判斷命令失敗的原因。
套件失敗
如果套件安裝失敗，您將會看到類似以下的內容：
```
ERROR: package[zend-server-ce-php-5.3] (/root/opsworks-agent/site-cookbooks/zend_server/recipes/install.rb line 20)
had an error: apt-get -q -y --force-yes install zend-server-ce-php-5.3=5.0.4+b17 returned 100, expected 0
```
向上捲動日誌，您應該會看到命令的 STDOUT 和 STDERROR 輸出，這有助您判斷套件安裝失敗的原因。
# 使用 OpsWorks Stacks 代理程式 CLI
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
**注意**
代理程式 CLI 只適用於 Linux 執行個體。
在每個線上執行個體上， OpsWorks Stacks 都會安裝 代理程式，該代理程式會與服務通訊。Stacks OpsWorks 服務會依序傳送命令給代理程式，以執行任務，例如在生命週期事件發生時啟動執行個體上的 Chef 執行。在 Linux 執行個體上，代理程式會公開命令列界面 (CLI)，這對故障診斷非常有用。若要執行代理程式 CLI 命令，請使用 [SSH 連線到執行個體](workinginstances-ssh.md)。然後您可以執行代理程式 CLI 命令來執行各種任務，包括下列任務：
+ 執行配方。
+ 顯示 Chef 日誌。
+ 顯示[堆疊組態與部署 JSON](workingcookbook-json.md)。
如需如何設定與執行個體間 SSH 連線的詳細資訊，請參閱[使用 SSH 登入](workinginstances-ssh.md)。您也必須具有堆疊的 [SSH 和 sudo 許可](opsworks-security-users.md)。
本節說明如何使用代理程式 CLI 進行故障診斷。如需詳細資訊和完整命令參考，請參閱 [OpsWorks Stacks 代理程式 CLI](agent.md)。
**Topics**
+ [執行配方](#troubleshoot-debug-cli-recipes)
+ [顯示 Chef 日誌](#troubleshoot-debug-cli-log)
+ [顯示堆疊組態與部署 JSON](#troubleshoot-debug-cli-json)
## 執行配方
代理程式 CLI [`run_command`](agent-run.md) 命令會指示代理程式重新執行其先前執行過的命令。最實用的故障診斷命令為 `setup`、`configure`、`deploy` 和 `undeploy`，並各自對應到一個生命週期事件。這些命令會指示代理程式起始 Chef 執行，以執行相關聯的配方。
**注意**
`run_command` 命令僅限執行與指定命令相關聯的配方群組，通常是與生命週期事件相關聯的配方。您無法用它執行特定配方。若要執行一或多個指定配方，請使用[執行配方堆疊命令](workingstacks-commands.md)或同等的 CLI 或 API 動作 ([https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 和 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html))。
`run_command` 命令在為自訂配方除錯方面相當有用，尤其是指派至安裝和設定生命週期事件的配方，這些事件並無法直接從主控台加以觸發。透過使用 `run_command`，您可以隨時視需要執行特定事件的配方，而無須啟動或停止執行個體。
**注意**
OpsWorks Stacks 會從執行個體的技術指南快取執行配方，而非技術指南儲存庫。當執行個體啟動時， OpsWorks Stacks 會將技術指南下載至此快取，但如果您後續修改技術指南，則不會自動更新線上執行個體上的快取。如果您在啟動執行個體後修改了技術指南，請務必執行[更新技術指南堆疊命令](workingstacks-commands.md)堆疊命令，以使用儲存庫中的最新版本更新技術指南快取。
代理程式僅快取最新的命令。您可以執行 [`list_commands`](agent-list.md) 來列出這些命令，這會傳回已快取命令及其執行時間的清單。
```
sudo opsworks-agent-cli list_commands
2013-02-26T19:08:26 setup
2013-02-26T19:12:01 configure
2013-02-26T19:12:05 configure
2013-02-26T19:22:12 deploy
```
若要重新執行最新的命令，請執行：
```
sudo opsworks-agent-cli run_command
```
若要重新執行最新執行個體的指定命令，請執行：
```
sudo opsworks-agent-cli run_command command
```
例如，若要重新執行安裝配方，您可以執行下列命令：
```
sudo opsworks-agent-cli run_command setup
```
每個命令都有一個相關聯的[堆疊組態和部署 JSON](workingcookbook-json.md)，代表該命令執行時堆疊和部署的狀態。由於該資料可能隨著命令不同有所差異，因此較舊執行個體的命令可能使用與最新執行個體不同的資料。若要重新執行特定執行個體的命令，請複製 `list_commands` 輸出中的時間，並執行以下命令：
```
sudo opsworks-agent-cli run_command time
```
上述範例均使用預設 JSON 重新執行命令，也就是為該命令安裝的 JSON。您可以對任意 JSON 檔案重新執行命令，如下所示：
```
sudo opsworks-agent-cli run_command -f /path/to/valid/json.file
```
## 顯示 Chef 日誌
代理程式 CLI [`show_log`](agent-show.md) 命令會顯示指定的日誌。在命令完成後，您將會看到檔案結尾。因此，`show_log` 命令提供方便查看日誌結尾的方法，您通常會在這裡找到錯誤資訊。您可以向上捲動以查看日誌的先前部分。
若要顯示目前命令的日誌，請執行：
```
sudo opsworks-agent-cli show_log
```
您也可以顯示特定命令的日誌，但請注意，代理程式僅快取最後三十個命令的日誌。您可以執行 [`list_commands`](agent-list.md) 列出執行個體的命令，這會傳回已快取命令及其執行時間的清單。如需範例，請參閱 [執行配方](#troubleshoot-debug-cli-recipes)。
若要顯示特定命令最新執行狀況的日誌，請執行下列命令：
```
sudo opsworks-agent-cli show_log command
```
命令參數可以設為 `setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 或 `restart`。這些命令大部分都對應到生命週期事件，並指示代理程式執行相關聯配方。
若要顯示特定命令執行狀況的日誌，請複製 `list_commands` 輸出中的日期並執行：
```
sudo opsworks-agent-cli show_log date
```
如果命令仍在執行，`show_log` 會顯示日誌的目前狀態。
**注意**
使用 `show_log` 來為錯誤和記憶體不足問題進行故障診斷的其中一種方法，是在執行期間顯示日誌的結尾，如下所示：
使用 `run_command` 來觸發適當的生命週期事件。如需詳細資訊，請參閱[執行配方](#troubleshoot-debug-cli-recipes)。
重複執行 `show_log` 以在寫入日誌時查看日誌的結尾。
如果 Chef 記憶體不足或意外結束，日誌會突然結束。如果配方失敗，日誌的結尾為例外狀況和堆疊追蹤。
## 顯示堆疊組態與部署 JSON
配方使用的許多資料來自[堆疊組態和部署 JSON](workingcookbook-json.md)，這定義了一組 Chef 屬性，以提供堆疊組態、任何部署和使用者可新增之選用自訂屬性的詳細說明。對於每個命令， OpsWorks Stacks 會安裝代表命令 時堆疊和部署狀態的 JSON。如需詳細資訊，請參閱[堆疊組態及部署屬性](workingcookbook-json.md)。
如果自訂配方從堆疊組態和部署 JSON 取得資料，您可以檢查該 JSON 來驗證資料。顯示堆疊組態和部署 JSON 最簡單的方式，是執行代理程式 CLI [`get_json`](agent-json.md) 命令，這會顯示 JSON 物件的格式化版本。以下提供某些一般輸出的前幾行：
```
{
"opsworks": {
"layers": {
"php-app": {
"id": "4a2a56c8-f909-4b39-81f8-556536d20648",
"instances": {
"php-app2": {
"elastic_ip": null,
"region": "us-west-2",
"booted_at": "2013-02-26T20:41:10+00:00",
"ip": "10.112.235.192",
"aws_instance_id": "i-34037f06",
"availability_zone": "us-west-2a",
"instance_type": "c1.medium",
"private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal",
"private_ip": "10.252.0.203",
"created_at": "2013-02-26T20:39:39+00:00",
"status": "online",
"backends": 8,
"public_dns_name": "ec2-10-112-235-192.us-west-2.compute.amazonaws.com"
...
```
您可以顯示最新的堆疊組態和部署 JSON，如下所示：
```
sudo opsworks-agent-cli get_json
```
您可以執行下列命令來顯示指定命令的最新堆疊組態和部署 JSON：
```
sudo opsworks-agent-cli get_json command
```
命令參數可以設為 `setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 或 `restart`。這些命令大部分都對應到生命週期事件，並指示代理程式執行相關聯配方。
您可以指定命令的日期，來顯示特定命令執行的堆疊組態和部署 JSON，如下所示：
```
sudo opsworks-agent-cli get_json date
```
使用此命令的最簡單方式如下：
1. 執行 `list_commands` 會傳回清單，內含已在執行個體上執行的命令，以及每個命令的執行日期。
1. 複製適當命令的日期，並將其做為 `get_json` *date* 引數使用。
# 常見的除錯和故障診斷問題
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
本節說明一些常見的除錯和故障診斷問題，以及其解決方案。
**Topics**
+ [對 OpsWorks Stacks 進行故障診斷](common-issues-troubleshoot.md)
+ [故障診斷執行個體註冊](#common-issues-instance-registration)
# 對 OpsWorks Stacks 進行故障診斷
**重要**
AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。
本節包含一些常見的 OpsWorks Stacks 問題及其解決方案。
**Topics**
+ [無法管理執行個體](#w2ab1c14c77c17b9b9)
+ [在 Chef 執行之後，執行個體無法開機](#w2ab1c14c77c17b9c11)
+ [Layer 的執行個體皆未通過 Elastic Load Balancing 運作狀態檢查](#common-issues-troubleshoot-health)
+ [無法與 Elastic Load Balancing Load Balancer 通訊](#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 使用者或角色在 Stacks OpsWorks 之外被意外刪除。這會導致安裝在執行個體上的 OpsWorks 代理程式與 OpsWorks Stacks 服務之間的通訊失敗。與執行個體關聯的 使用者需要在執行個體的生命存續期間內存在。
+ 在執行個體離線時編輯磁碟區或儲存體組態，可能會使執行個體無法管理。
+ 手動將 EC2 執行個體新增至 ELB。每次執行個體進入或離開線上狀態時，都會 OpsWorks 重新設定指派的 Elastic Load Balancing 負載平衡器。 OpsWorks 只會將已知為有效成員的執行個體視為有效成員；在外部新增的執行個體 OpsWorks，或透過其他程序新增的執行個體會遭到移除。每一個其他的執行個體都會遭到移除。
**解決方案：**請勿刪除執行個體所依賴的 IAM 使用者或角色。若可能的話，請只在依存執行個體執行時編輯磁碟區或儲存體組態。使用 OpsWorks 管理 OpsWorks 執行個體的負載平衡器或 EIP 成員資格。當您註冊執行個體時，為協助避免在使用者意外刪除時管理已註冊執行個體的問題，請將 `--use-instance-profile` 參數新增至您的`register`命令，以改用執行個體的內建執行個體描述檔。
## 在 Chef 執行之後，執行個體無法開機
**問題：**於設定為使用自訂技術指南的 Chef 11.10 或較舊版本的堆疊上，在使用社群技術指南的 Chef 執行之後，執行個體無法開機。日誌訊息可能會表示配方編譯失敗 ("Recipe Compile Error")，或是因為找不到依存項目而無法載入。
**原因：**最有可能的原因是自訂或社群技術指南不支援堆疊所使用的 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 技術指南**設定的 OpsWorks Stacks 堆疊上，自訂或社群技術指南必須一律支援堆疊使用的 Chef 版本。請將社群技術指南固定 (即將技術指南版本編號設為特定版本) 在與您在堆疊設定中設定之 Chef 版本相容的版本。若要尋找支援的社群技術指南版本，請檢視編譯失敗之技術指南的變更記錄，並只使用您堆疊可支援的最近版本。若要固定技術指南的版本，請在您自訂技術指南儲存庫的 Berksfile 中指定明確的版本編號。例如 `cookbook 'build-essential', '= 3.2.0'`。
## Layer 的執行個體皆未通過 Elastic Load Balancing 運作狀態檢查
**問題：**您將 Elastic Load Balancing 負載平衡器連接到應用程式伺服器層，但所有執行個體都未通過運作狀態檢查。
**原因：**當您建立 Elastic Load Balancing 負載平衡器時，您必須指定負載平衡器呼叫的 ping 路徑，以判斷執行個體是否正常運作。請務必指定適合您應用程式的 ping 路徑。預設值為 /index.html。若您的應用程式不包含 `index.html`，您必須指定適當的路徑，否則運作狀態檢查將會失敗。例如，[Chef 11 Linux 堆疊入門](gettingstarted.md)中使用的 SimplePHPApp 應用程式並未使用 index.html。那些伺服器的適當 ping 路徑為 /。
**解決方案：**編輯負載平衡器的 ping 路徑。如需詳細資訊，請參閱 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)
## 無法與 Elastic Load Balancing Load Balancer 通訊
**問題：**您建立 Elastic Load Balancing 負載平衡器並將其連接到應用程式伺服器層，但當您按一下負載平衡器的 DNS 名稱或 IP 地址來執行應用程式時，您會收到下列錯誤：「遠端伺服器未回應」。
**原因：**如果您的堆疊在預設 VPC 中執行，當您在區域中建立 Elastic Load Balancing 負載平衡器時，您必須指定安全群組。安全群組必須具備輸入規則，允許來自您 IP 地址的傳入流量。若您指定 **default VPC security group (預設 VPC 安全群組)**，預設的輸入規則不會接受任何傳入流量。
**解決方案：**編輯安全群組輸入規則，以接受來自適當 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 地址的傳入流量。
## 匯入的現場部署執行個體在重新啟動之後無法完成磁碟區設定
**問題：**您重新啟動已匯入 Stacks OpsWorks 的 EC2 執行個體，且 OpsWorks Stacks 主控台顯示**失敗**為執行個體狀態。這可能會在 Chef 11 或 Chef 12 執行個體上發生。
**原因：**OpsWorks Stacks 於設定程序中可能無法將磁碟區連接至您的執行個體。其中一個可能的原因是 OpsWorks Stacks 在您執行 `setup` 命令時覆寫了您執行個體上的磁碟區組態。
**解決方案：**開啟執行個體的 **Details (詳細資訊)** 頁面，檢查 **Volumes (磁碟區)** 區域內的磁碟區組態。請注意，您只能在您的執行個體處於 **stopped (已停止)** 狀態時才能變更您的磁碟區組態。請確認每個磁碟區都有指定的掛載點和名稱。在重新啟動執行個體之前，請確認您在 OpsWorks Stacks 的組態中提供正確的掛載點。
## EBS 磁碟區在重新開機後無法重新連接
**問題：**您使用 Amazon EC2 主控台將 Amazon EBS 磁碟區連接至執行個體，但當您重新啟動執行個體時，磁碟區不再連接。
**原因：** OpsWorks Stacks 只能重新連接其已知的 Amazon EBS 磁碟區，這些磁碟區僅限於下列項目：
+ Stacks OpsWorks 建立的磁碟區。
+ 來自您帳戶的磁碟區，且已藉 **Resources (資源)** 頁面明確向堆疊註冊。
**解決方案：**僅使用 Stacks 主控台、API 或 CLI OpsWorks 管理您的 Amazon EBS 磁碟區。如果您想要將其中一個帳戶的 Amazon EBS 磁碟區與堆疊搭配使用，請使用堆疊**的資源**頁面來註冊磁碟區並將其連接至執行個體。如需詳細資訊，請參閱[資源管理](resources.md)。
## 無法刪除 OpsWorks Stacks 安全群組
**問題：**刪除堆疊後，會留下一些無法刪除的 Stacks OpsWorks 安全群組。
**原因：**安全群組必須依照特定順序進行刪除。
**解決方案：**首先，請確認沒有任何執行個體正在使用安全群組。接著，依照以下順序刪除下列任何安全群組 (若有的話)：
1. AWS-OpsWorks-Blank-Server
1. AWS-OpsWorks-Monitoring-Master-Server
1. AWS-OpsWorks-DB-Master-Server
1. AWS-OpsWorks-Memcached-Server
1. AWS-OpsWorks-Custom-Server
1. AWS-OpsWorks-nodejs-App-Server
1. AWS-OpsWorks-PHP-App-Server
1. AWS-OpsWorks-Rails-App-Server
1. AWS-OpsWorks-Web-Server
1. AWS-OpsWorks-Default-Server
1. AWS-OpsWorks-LB-Server
## 意外刪除 OpsWorks Stacks 安全群組
**問題：**您已刪除其中一個 OpsWorks Stacks 安全群組，需要重新建立。
**原因：**這些安全群組通常都是意外遭到刪除。
**解決方案：**重新建立的群組必須是和原始群組完全一模一樣的複本，其群組名稱也要有相同的大小寫。與其手動重新建立群組，建議的方法為讓 OpsWorks Stacks 為您執行這項任務。只要在相同的 AWS 區域和 VPC 中建立新的堆疊，如果有的話， Stacks OpsWorks 就會自動重新建立所有內建的安全群組，包括您刪除的安全群組。您接著可以刪除您不再需要使用的堆疊，安全群組仍會留下。
## Chef 日誌無故終止
**問題：**Chef 日誌無故終止。日誌的最後沒有指出成功執行或顯示異常和堆疊追蹤。
**原因：**此行為通常是因為記憶體不足。
**解決方案：**建立更大的執行個體，並使用代理程式 CLI `run_command` 命令重新執行配方。如需詳細資訊，請參閱[執行配方](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes)。
## 無法更新技術指南
**問題：**您更新您的技術指南，但堆疊的執行個體仍然執行舊的配方。
**Cause：** OpsWorks Stacks 會快取每個執行個體上的技術指南，並從快取執行配方，而非儲存庫。當您啟動新的執行個體時， OpsWorks Stacks 會將您的技術指南從儲存庫下載到執行個體的快取。但是，若您之後修改您的自訂技術指南， OpsWorks Stacks 不會自動更新線上執行個體的快取。
**解決方案：**執行[更新技術指南堆疊命令](workingstacks-commands.md)，明確指示 OpsWorks Stacks 更新線上執行個體的技術指南快取。
## 執行個體停滯在開機中狀態
**問題：**當您重新啟動執行個體，或自動修復自動予以重新啟動時，啟動操作停滯在 `booting` 狀態。
**原因：**此問題其中一個可能的原因是 VPC 組態，包含預設 VPC。執行個體必須始終能夠與 OpsWorks Stacks 服務、Amazon S3 和套件、技術指南和應用程式儲存庫進行通訊。例如，如果您從預設 VPC 移除預設閘道，執行個體會失去與 Stacks OpsWorks 服務的連線。由於 OpsWorks Stacks 無法再與執行個體[代理](troubleshoot-debug-cli.md)程式通訊，因此會將執行個體視為失敗並[自動修復](workinginstances-autohealing.md)。不過，如果沒有連線， OpsWorks Stacks 就無法在已修復的執行個體上安裝執行個體代理程式。如果沒有代理程式， OpsWorks Stacks 就無法在執行個體上執行安裝配方，因此啟動操作無法超過「開機」狀態。
**解決方案：**修改您的 VPC 組態，讓您的執行個體具備需要的連線能力。
## 執行個體未預期的重新啟動
**問題：**已停止的執行個體未預期的重新啟動。
**原因 1：**如果您已啟用執行個體的[自動修復](workinginstances-autohealing.md)， OpsWorks Stacks 會定期對相關聯的 Amazon EC2 執行個體執行運作狀態檢查，並重新啟動任何運作狀態不佳的執行個體。如果您使用 Amazon EC2 主控台、API 或 OpsWorks CLI 來停止或終止 Stacks 受管執行個體，則不會通知 OpsWorks Stacks。因此，它會將已停止的執行個體視為運作狀態不良，並自動重新啟動它。
**解決方案：**僅使用 OpsWorks Stacks 主控台、API 或 CLI 管理您的執行個體。如果您使用 OpsWorks Stacks 來停止或刪除執行個體，則不會重新啟動執行個體。如需詳細資訊，請參閱[手動啟動、停止和重新開機全年無休的執行個體](workinginstances-starting.md)及[刪除 OpsWorks Stacks 執行個體](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_tw/opsworks/latest/userguide/images/command_details.png)
若要查看所有詳細資訊，請按一下命令的**日誌**欄中的**顯示**以顯示相關聯的 Chef 日誌。在 日誌中搜尋 **Run List**. OpsWorks Stacks 維護配方。 `OpsWorks Custom Run List`例如，以下是在先前螢幕擷取畫面中顯示之 `execute_recipes` 命令的 run list，顯示每個與命令關聯的配方。
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```
## 故障診斷執行個體註冊
本節包含一些常見的執行個體註冊問題及其解決方案。
**注意**
若您有註冊問題，請搭配 `--debug` 引數執行 `register`，這會提供額外的除錯資訊。
**Topics**
+ [EC2User 無權執行：...](#common-issues-instance-registration-ec2user)
+ [登入資料應設定在有效區域](#common-issues-instance-registration-valid-region)
### EC2User 無權執行：...
**問題：**`register` 命令傳回類似下列內容：
```
A client error (AccessDenied) occurred when calling the CreateGroup operation:
User: arn:aws:iam::123456789012:user/ImportEC2User is not authorized to
perform: iam:CreateGroup on resource:
arn:aws:iam::123456789012:group/AWS/OpsWorks/OpsWorks-b583ce55-1d01-4695-b3e5-ee19257d1911
```
**原因：**`register`命令使用未授予必要許可的登入資料執行。使用者的政策必須允許 `iam:CreateGroup` 動作及其他動作。
**解決方案：**提供 `register` 具有必要許可的 IAM 使用者登入資料。如需詳細資訊，請參閱[安裝並設定 AWS CLI](registered-instances-register-registering-cli.md)。
### 登入資料應設定在有效區域
**問題：**`register` 命令傳回下列內容：
```
A client error (InvalidSignatureException) occurred when calling the
DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'.
```
**原因：**命令的區域必須為有效的 OpsWorks Stacks 區域。如需支援的區域的清單，請參閱[區域支援](gettingstarted_intro.md#gettingstarted-intro-region)。此錯誤通常會因下列其中一個原因發生：
+ 堆疊位於不同的區域中，但您將堆疊的區域指派給命令的 `--region` 引數。
您不需要指定堆疊區域； OpsWorks 堆疊會自動從堆疊 ID 判斷。
+ 您忽略了 `--region` 引數，其隱含指定預設區域，但您的預設區域不受 OpsWorks Stacks 支援。
**解決方案：**明確`--region`設定為支援的 OpsWorks Stacks 區域``，或編輯 `config` 檔案 AWS CLI ，將預設區域變更為支援的 OpsWorks Stacks 區域。如需詳細資訊，請參閱[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。