本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 對 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"]
```