As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Guia de depuração e solução de problemas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Se você precisar depurar uma receita ou solucionar um problema de serviço, a melhor abordagem costuma ser acompanhar as seguintes etapas, em ordem:
1. Verifique em [Depuração e solução de problemas comuns](common-issues.md) seu problema específico.
1. Pesquise no [fórum do OpsWorks Stacks](https://forums.aws.amazon.com/forum.jspa?forumID=153#) para ver se o problema foi discutido lá.
O fórum inclui muitos usuários experientes e é monitorado pela equipe do OpsWorks Stacks.
1. Para problemas com receitas, consulte [Depurar receitas](troubleshoot-debug.md).
1. Entre em contato com o suporte do OpsWorks Stacks ou publique seu problema no [OpsWorks Stacks Forum](https://forums.aws.amazon.com/forum.jspa?forumID=153#).
A seção a seguir fornece orientação para depurar receitas. A última seção descreve problemas comuns de depuração e solução de problemas e suas resoluções.
**nota**
Cada execução do Chef produz um log, que fornece uma descrição detalhada da execução e é um recurso de solução de problemas valioso. Para especificar a quantidade de detalhes no log, adicione uma instrução [https://docs.chef.io/resource_log.html](https://docs.chef.io/resource_log.html) para uma receita personalizada que especifica o nível de log desejado. O valor padrão é `:info`. O exemplo a seguir mostra como definir o nível de log do Chef para `:debug`, que fornece a descrição mais detalhada da execução.
```
Chef::Log.level = :debug
```
Para obter mais informações sobre a visualização e a interpretação de logs do Chef, consulte [Logs do Chef](troubleshoot-debug-log.md).
**Topics**
+ [Depurar receitas](troubleshoot-debug.md)
+ [Depuração e solução de problemas comuns](common-issues.md)
# Depurar receitas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Quando um evento de ciclo de vida ocorre ou ao executar o [comando de pilha Execute Recipes (Executar receitas)](workingstacks-commands.md), o OpsWorks Stacks emite um comando para o [agente](troubleshoot-debug-cli.md) iniciar uma [execução de Chef Solo](https://docs.chef.io/ctl_chef_solo.html) nas instâncias especificadas para executar as receitas adequadas, incluindo as receitas personalizadas. Esta seção descreve algumas maneiras para você depurar receitas com falha.
**Topics**
+ [Efetuar login em uma Instância com falha](troubleshoot-debug-login.md)
+ [Logs do Chef](troubleshoot-debug-log.md)
+ [Usando a CLI do OpsWorks Stacks Agent](troubleshoot-debug-cli.md)
# Efetuar login em uma Instância com falha
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Se houver falha de receita, a instância terá o estado `setup_failed` em vez de online. Mesmo que a instância não esteja on-line no que diz respeito ao OpsWorks EC2 Stacks, ela está em execução e geralmente é útil fazer login para solucionar o problema. Por exemplo, você pode verificar se um aplicativo ou um livro de receitas personalizado está instalado corretamente. O suporte integrado do OpsWorks Stacks para login [SSH](workinginstances-ssh.md) e [RDP](workinginstances-rdp.md) está disponível somente para instâncias no estado online. No entanto, se você tiver atribuído um par de chaves SSH à instância, ainda é possível fazer login da seguinte maneira:
+ Instâncias Linux: use a chave privada do par de chaves SSH para fazer login com um cliente SSH de terceiros, como OpenSSH ou PuTTY.
Você pode usar um par de EC2 chaves ou seu [par de chaves SSH pessoal](security-ssh-access.md) para essa finalidade.
+ Instâncias do Windows — use a EC2 chave privada do par de chaves para recuperar a senha de administrador da instância.
Use essa senha para se conectar com seu cliente RDP preferencial. Para obter mais informações, consulte [Login como administrador](workinginstances-rdp.md#workinginstances-rdp-admin). Você não pode usar um [par de chaves SSH pessoais](security-ssh-access.md) para recuperar uma senha de Administrador.
# Logs do Chef
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Os registros do Chef são um dos seus principais recursos de solução de problemas, especialmente para receitas de depuração. OpsWorks O Stacks captura o registro do Chef para cada comando e retém os registros dos 30 comandos mais recentes de uma instância. Como a execução está no modo de depuração, o log contém uma descrição detalhada da execução do Chef, incluindo o texto que é enviado para `stdout` e `stderror`. Se uma receita falhar, o log do Chef inclui o rastreamento de pilha.
OpsWorks O Stacks oferece várias maneiras de visualizar os registros do Chef. Com as informações do log, você pode usá-las para depurar receitas com falha.
**nota**
Também é possível visualizar a parte final do log ao usar SSH para se conectar à instância e executar o comando `show_log` do agente de CLI. Para obter mais informações, consulte [Exibição de logs do Chef](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log).
**Topics**
+ [Exibir um Log do Chef com o Console](#troubleshoot-debug-log-console)
+ [Exibir um Log do Chef com CLI ou API](#troubleshoot-debug-log-cli)
+ [Exibir um Log do Chef em uma instância](#troubleshoot-debug-log-instance)
+ [Interpretar o log do Chef](#troubleshoot-debug-log-interpret)
+ [Erros comuns do log do Chef](#troubleshoot-debug-log-errors)
## Exibir um Log do Chef com o Console
A maneira mais simples de visualizar um log do Chef é acessar a página de detalhes da instância. A seção **Logs** inclui uma entrada para cada evento e o comando [Executar receitas](workingstacks-commands.md). As informações a seguir mostram a seção **Logs** de uma instância com os comandos **configure** e **setup**, que correspondem aos eventos de ciclo de vida Configurar e Configuração.
![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/gs11.png)
Clique em **show** na coluna **Log** do comando apropriado para visualizar o log do Chef correspondente. Se ocorrer um erro, o OpsWorks Stacks abrirá automaticamente o registro do erro, que geralmente está no final do arquivo.
## Exibir um Log do Chef com CLI ou API
Você pode usar o comando OpsWorks Stacks [https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)CLI ou [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html)a ação da API para visualizar os registros, que são armazenados em um bucket do Amazon S3. As informações a seguir mostram como usar a CLI para visualizar qualquer arquivo do conjunto atual de arquivos de logs de uma instância especificada. O procedimento para usar `DescribeCommands` é essencialmente semelhante.
**Para usar as OpsWorks pilhas para visualizar os registros do Chef de uma instância**
1. Abra a página de detalhes da instância e copie seu valor de **OpsWorksID**.
1. Use o valor da ID para executar o comando de CLI `describe-commands` da seguinte forma:
```
aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9
```
O comando retorna um objeto JSON com um objeto incorporado para cada comando que o OpsWorks Stacks executou na instância, com o mais recente primeiro. O parâmetro `Type` contém o tipo de comando de cada objeto integrado, além dos comandos `configure` e `setup` neste exemplo.
```
{
"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. Copie o valor de `LogUrl` para o navegador a fim de exibir o log.
Se a instância tiver mais de alguns comandos, você pode adicionar parâmetros para `describe-commands` a fim de filtrar quais comandos estão incluídos no objeto da resposta. Para obter mais informações, consulte [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html).
## Exibir um Log do Chef em uma instância
**nota**
Os tópicos desta seção se aplicam ao Chef 12. Para obter mais informações sobre a localização dos logs do Chef para Chef 11.10 e versões anteriores, consulte [Solução de problemas do Chef 11.10 e versões anteriores para Linux](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshooting-chef-11-linux.html).
### Instâncias do Linux
OpsWorks O Stacks armazena os registros do Chef de cada instância em seu `/var/chef/runs` diretório. (para instâncias do Linux, este diretório também inclui os [recipientes de dados](data-bags.md) associados, armazenados como arquivos formatados para JSON.) Você precisa de [privilégios de sudo](opsworks-security-users.md) para acessar esse diretório. O log de cada execução está em um arquivo chamado `chef.log` no subdiretório da execução individual.
OpsWorks O Stacks armazena seus registros internos na `/var/log/aws/opsworks` pasta da instância. Em geral, as informações não são muito úteis para fins de solução de problemas. No entanto, esses registros são úteis para o suporte do OpsWorks Stacks, e você pode ser solicitado a fornecê-los se encontrar algum problema com o serviço. Às vezes, os logs do Linux também podem fornecer dados de solução de problemas úteis.
### Instâncias do Windows
**Logs de agente**
Nas instâncias do Windows, os OpsWorks registros são armazenados em um `ProgramData` caminho como o seguinte. O número inclui um carimbo de data e hora.
```
C:\ProgramData\OpsWorksAgent\var\logs\number
```
**nota**
Por padrão, `ProgramData` é uma pasta oculta. Para exibi-la, vá até **Folder Options**. Em **View**, selecione a opção de mostrar arquivos ocultos.
O exemplo a seguir mostra os logs de agente em uma instância do 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
```
**Logs do Chef**
Em instâncias do Windows, os logs do Chef são armazenados em um caminho `ProgramData`, como o seguinte. O número inclui um carimbo de data e hora.
```
C:\ProgramData\OpsWorksAgent\var\commands\number
```
**nota**
Este diretório contém apenas a saída da primeira execução (de OpsWorks propriedade) do Chef.
O exemplo a seguir mostra registros OpsWorks próprios do Chef em uma instância do Windows.
```
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
```
**Logs do Chef do usuário**
Os logs de execuções do Chef podem ser encontradas em arquivos chamados `logfile.txt`, em uma pasta como mesmo nome do comando numerado do Chef, como mostrado no diagrama a seguir.
C:/chef └── `runs` └── `command-12345` ├── `attribs.json` ├── `client.rb` └── `logfile.txt`
## Interpretar o log do Chef
Em grande parte, o início do log contém registros internos do 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
...
```
Esta parte do arquivo é útil principalmente para especialistas do Chef. Observe que a lista de execução inclui apenas duas receitas, mesmo quando a maioria dos comandos envolvem mais recursos. Essas duas receitas processam a tarefa de carregar e executar todas as outras receitas internas e personalizadas.
A parte mais interessante do arquivo é geralmente no final. Se uma execução termina com sucesso, você deve visualizar algo como o seguinte:
```
...
[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
```
**nota**
Você pode usar a CLI do agente para exibir a parte final do log durante ou após a execução. Para obter mais informações, consulte [Exibição de logs do Chef](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log).
Se uma receita falhar, você deve procurar uma saída de nível de ERRO, que conterá uma exceção seguida por um rastreamento de pilha do Chef, como o seguinte:
```
...
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
```
O final do arquivo é o rastreamento de pilha do Chef. Você também deve examinar a saída antes da exceção, o que, muitas vezes, contém um erro do sistema, como `package not available`, que também pode ser útil para determinar a causa. Neste caso, o daemon MySQL falhou ao iniciar.
## Erros comuns do log do Chef
Veja a seguir alguns dos erros comuns de log do Chef e como solucioná-los.
Não foi possível encontrar o log
No início de uma execução do Chef, as instâncias recebem um URL Amazon S3 pré-designado que permite visualizar o log em uma página da Web quando a execução do Chef for concluída. Como esse URL expira após duas horas, não há log carregados no site Amazon S3 se uma execução do Chef demora mais de duas horas, mesmo se não houver nenhum problema durante a execução do Chef. O comando para criar um log foi bem-sucedido, mas o log pode ser visualizado apenas na instância, não no URL pré-designado.
Log encerrado repentinamente
Se um log de Chef for encerrado repentinamente sem indicar sucesso ou exibir informações de erro, você provavelmente encontrou um estado de memória baixa que impediu o Chef de concluir o log. Sua melhor opção é tentar novamente com uma instância maior.
Livro de receitas ou receita ausente
Se a execução do Chef encontrar um livro de receitas ou receita que não está no cache do livro de receitas, você verá algo como o seguinte:
```
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?
```
Esta entrada indica que o livro de receitas `mycookbook` não está no cache de receitas. Com o Chef 11.4, você também pode encontrar esse erro se você não declarar dependências corretamente em `metadata.rb`.
OpsWorks O Stacks executa receitas do cache do livro de receitas da instância. Ele baixa livros de receitas do repositório para o cache quando a instância é iniciada. No entanto, o OpsWorks Stacks não atualizará automaticamente o cache em uma instância on-line se você modificar posteriormente os livros de receitas em seu repositório. Se você tiver modificado os livros de receitas ou adicionado novos livros de receitas desde o início da instância, siga estas etapas:
1. Certifique-se de confirmar suas alterações no repositório.
1. Execute o comando da pilha [Atualizar livros de receitas](workingstacks-commands.md) para atualizar o cache do livro de receitas com a versão mais recente do repositório.
Falha de comando local
Se um recurso do Chef `execute` falhar ao executar o comando especificado, você visualizará algo como:
```
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=/
```
Role para cima no logo para visualizar a saída `stderr` e `stdout` do comando, que devem ajudar você a determinar o motivo da falha do comando.
Falha de pacote
Em caso de falha de pacote de instalação, você verá algo como:
```
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
```
Role para cima no log e você deve visualizar as saídas STDOUT e STDERROR do comando, que devem ajudar a determinar o motivo da falha de instalação do pacote.
# Usando a CLI do OpsWorks Stacks Agent
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
**nota**
A CLI do agente está disponível apenas em instâncias do Linux.
Em cada instância on-line, o OpsWorks Stacks instala um agente, que se comunica com o serviço. O serviço OpsWorks Stacks, por sua vez, envia comandos ao agente para realizar tarefas como iniciar execuções do Chef na instância quando ocorre um evento de ciclo de vida. Em instâncias do Linux, o agente expõe uma CLI (interface de linha de comando), o que é muito útil para a solução de problemas. Para executar os comandos de CLI, usar o [SSH para se conectar a uma instância](workinginstances-ssh.md). Em seguida, você pode executar os comandos de CLI do agente para executar diversas tarefas, incluindo o seguinte:
+ Executar receitas.
+ Exibir logs do Chef.
+ Exibir a [configuração de pilha e a implantação de JSON](workingcookbook-json.md).
Para obter mais informações sobre como configurar uma conexão SSH com uma instância, consulte [Login com SSH](workinginstances-ssh.md). Você também deve ter [permissões de SSH e sudo](opsworks-security-users.md) para a pilha.
Esta seção descreve como usar a CLI de agente para a solução de problemas. Para obter mais informações e uma referência de comando completa, consulte [OpsWorks CLI do Stacks Agent](agent.md).
**Topics**
+ [Execução de receitas](#troubleshoot-debug-cli-recipes)
+ [Exibição de logs do Chef](#troubleshoot-debug-cli-log)
+ [Exibição da configuração de pilha e implantação de JSON](#troubleshoot-debug-cli-json)
## Execução de receitas
O comando [`run_command`](agent-run.md) da CLI de agente direciona o agente para executar novamente um comando executado anteriormente. Os comandos mais úteis para a solução de problemas, `setup`, `configure`, `deploy` e `undeploy`, correspondem a um evento de ciclo de vida. Eles direcionam o agente para iniciar uma execução do Chefe a fim de executar as receitas associadas.
**nota**
O comando `run_command` é limitado a executar o grupo de receitas associado a um comando especificado. Em geral, as receitas que são associadas a um evento de ciclo de vida. Não é possível usá-lo para executar uma receita específica. Para executar uma ou mais receitas específicas, use o comando de pilha [Executar receitas](workingstacks-commands.md) ou as ações da API ou CLI equivalentes ([https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) e [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html)).
O comando `run_command` é útil para depurar receitas personalizadas, especificamente as atribuídas a eventos de ciclo de vida de Configuração e Instalação, que não podem ser acionados diretamente do console. Ao usar `run_command`, você pode executar as receitas de um evento específico com a frequência necessária sem precisas iniciar ou parar instâncias.
**nota**
OpsWorks O Stacks executa receitas do cache do livro de receitas da instância, não do repositório do livro de receitas. OpsWorks O Stacks baixa livros de receitas para esse cache quando a instância é iniciada, mas não atualiza automaticamente o cache nas instâncias on-line se você modificar seus livros de receitas posteriormente. Se você modificou os livros de receitas desde o início da instância, certifique-se de executar o comando de pilha [Atualizar livros de receitas](workingstacks-commands.md) para atualizar o cache do livro de receitas com a versão mais recente do repositório.
O agente armazena em cache somente os comandos mais recentes. É possível listá-los ao executar [`list_commands`](agent-list.md), que retorna uma lista de comandos em cache e o horário em que foram executados.
```
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
```
Para executar novamente o comando mais recente, execute:
```
sudo opsworks-agent-cli run_command
```
Para executar a instância mais recente de um comando especificado, execute:
```
sudo opsworks-agent-cli run_command command
```
Por exemplo, para executar novamente Configurar receitas, é possível executar o seguinte comando:
```
sudo opsworks-agent-cli run_command setup
```
Cada comando tem uma [configuração de pilha e implantação JSON](workingcookbook-json.md) que representa o estado do pilha e da implantação quando o comando foi executado. Como os dados podem mudar de um comando para o outro, uma instância mais antiga de um comando pode usar dados diferentes da mais recente. Para executar novamente uma instância específica de um comando, copie o horário da saída `list_commands` e execute o seguinte:
```
sudo opsworks-agent-cli run_command time
```
Os exemplos anteriores todos executam novamente o comando utilizando o JSON padrão, que é o JSON instalado para o comando. Você pode executar novamente um comando em um arquivo JSON arbitrário da seguinte forma:
```
sudo opsworks-agent-cli run_command -f /path/to/valid/json.file
```
## Exibição de logs do Chef
O comando [`show_log`](agent-show.md) da CLI do agente exibe um log especificado. Depois que o comando é concluído, você visualiza o fim do arquivo. Portanto, o comando `show_log` oferece uma maneira conveniente de analisar o fim do log, que é geralmente onde as informações de erro são encontradas. Você pode rolar para cima a fim de visualizar as partes anteriores do log.
Para exibir o log dos comandos atuais, execute isto:
```
sudo opsworks-agent-cli show_log
```
Você também pode exibir logs de um comando específico, mas saiba que o agente armazena os logs em cache somente nos trinta últimos comandos. É possível listar os comandos de uma instância ao executar [`list_commands`](agent-list.md), que retorna uma lista de comandos em cache e o horário em que foram executados. Para ver um exemplo, consulte [Execução de receitas](#troubleshoot-debug-cli-recipes).
Para mostrar o log da execução mais recente de um comando específico, execute o seguinte:
```
sudo opsworks-agent-cli show_log command
```
O parâmetro do comando pode ser definido como `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` ou `restart`. A maioria desses comandos corresponde a eventos de ciclo de vida e direciona o agente para executar as receitas associadas.
Para exibir o log de uma execução de comando específica, copie a data da saída `list_commands` e execute:
```
sudo opsworks-agent-cli show_log date
```
Se um comando ainda está em execução, `show_log` exibe o estado atual do log.
**nota**
Uma forma de usar `show_log` para solucionar erros e out-of-memory problemas é rastrear um log durante a execução, da seguinte maneira:
Use `run_command` para acionar o evento de ciclo de vida adequado. Para obter mais informações, consulte [Execução de receitas](#troubleshoot-debug-cli-recipes).
Execute repetidamente `show_log` para visualizar a parte final do log como é escrita.
Se o Chef ficar sem memória ou sair inesperadamente, o log encerra abruptamente. Caso de falha de receita, o log termina com uma exceção e um rastreamento de pilha.
## Exibição da configuração de pilha e implantação de JSON
A maior parte dos dados usados por receitas vem da [configuração de pilha e implantação JSON](workingcookbook-json.md), que define um conjunto de atributos do Chef e fornece uma descrição detalhada da configuração de pilha, implantações e atributos personalizados opcionais que os usuários podem adicionar. Para cada comando, o OpsWorks Stacks instala um JSON que representa a pilha e o estado de implantação no momento do comando. Para obter mais informações, consulte [Configuração de pilha e atributos de implantação](workingcookbook-json.md).
Se as receitas personalizadas obtêm dados da configuração de pilha e da implantação JSON, é possível verificar os dados ao examinar o JSON. A maneira mais fácil de exibir a configuração de pilha e a implantação JSON é executar o comando [`get_json`](agent-json.md) da CLI do agente, que exibe uma versão formatada do objeto JSON. Veja a seguir as primeiras linhas de uma saída típica:
```
{
"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"
...
```
Você pode exibir a configuração de pilha mais recente e a implantação JSON da seguinte forma:
```
sudo opsworks-agent-cli get_json
```
Você pode exibir a configuração de pilha e a implantação JSON mais recente de um comando especificado ao executar o seguinte:
```
sudo opsworks-agent-cli get_json command
```
O parâmetro do comando pode ser definido como `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` ou `restart`. A maioria desses comandos corresponde a eventos de ciclo de vida e direciona o agente para executar as receitas associadas.
Você pode exibir a configuração de pilha e a implantação JSON de determinado comando ao especificar a data do comando como:
```
sudo opsworks-agent-cli get_json date
```
A maneira mais simples de usar este comando é a seguinte:
1. Execute `list_commands`, que retorna uma lista de comandos que foram executados na instância e a data em que cada comando foi executado.
1. Copie a data do comando apropriado e use-a como `get_json` *date* argumento.
# Depuração e solução de problemas comuns
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Esta seção descreve alguns problemas normalmente encontrados na depuração e na solução de problemas e suas soluções.
**Topics**
+ [Pilhas de solução OpsWorks de problemas](common-issues-troubleshoot.md)
+ [Solução de problemas do registro da instância](#common-issues-instance-registration)
# Pilhas de solução OpsWorks de problemas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Esta seção contém alguns problemas comuns do OpsWorks Stacks e suas soluções.
**Topics**
+ [Não é possível gerenciar instâncias](#w2ab1c14c77c17b9b9)
+ [Depois de uma execução do Chef, as instâncias não serão inicializadas](#w2ab1c14c77c17b9c11)
+ [Todas as instâncias de uma camada falham na verificação de integridade do Elastic Load Balancing](#common-issues-troubleshoot-health)
+ [Não consigo me comunicar com um balanceador de carga do Elastic Load Balancing](#w2ab1c14c77c17b9c15)
+ [Uma instância no local importada deixa de concluir a configuração do volume após uma reinicialização](#w2ab1c14c77c17b9c17)
+ [Um volume EBS não é anexado novamente após uma reinicialização](#common-issues-troubleshoot-ebs)
+ [Não é possível excluir security groups do OpsWorks Stacks](#common-issues-troubleshoot-booting-secgroup)
+ [Excluiu acidentalmente um grupo de segurança OpsWorks do Stacks](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Log do Chef encerra abruptamente](#common-issues-troubleshoot-log-terminates)
+ [O livro de receitas não é atualizado](#common-issues-troubleshoot-update)
+ [As instâncias permanecem presas no status de inicialização](#common-issues-troubleshoot-booting)
+ [Instâncias reiniciam inesperadamente](#common-issues-troubleshoot-restart)
+ [Processos `opsworks-agent` em execução em instâncias](#common-issues-troubleshoot-agent)
+ [Comandos execute\$1recipes inesperados](#common-issues-troubleshoot-unexpected)
## Não é possível gerenciar instâncias
**Problema:** você não é mais capaz de gerenciar uma instância que foi gerenciável no passado. Em alguns casos, os logs podem mostrar um erro semelhante ao seguinte.
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**Causa:** isso poderá ocorrer se um recurso externo ao OpsWorks do qual a instância dependa tiver sido editado ou excluído. Estes são exemplos de alterações feitas no recurso que podem parar a comunicação com uma instância.
+ Um usuário ou função do IAM associado à instância foi excluído acidentalmente, fora do OpsWorks Stacks. Isso causa uma falha de comunicação entre o OpsWorks agente que está instalado na instância e o serviço OpsWorks Stacks. O usuário do associado a uma instância é obrigatório durante todo o ciclo de vida da instância.
+ Editar as configurações de volume ou armazenamento enquanto uma instância permanece off-line pode deixar uma instância ingerenciável.
+ Adicionar EC2 instâncias a um ELB manualmente. OpsWorks reconfigura um load balancer atribuído do Elastic Load Balancing sempre que uma instância entra ou sai do estado on-line. OpsWorks considera apenas as instâncias que conhece como membros válidos; as instâncias que são adicionadas fora ou por algum outro processo são removidas. OpsWorks Todas as demais instâncias são removidas.
**Solução:** não exclua usuários do IAM ou perfis de que as instâncias dependam. Se possível, só edite configurações de volume ou armazenamento enquanto as instâncias dependentes estiverem em execução. Use OpsWorks para gerenciar o balanceador de carga ou as associações EIP das instâncias. OpsWorks Quando você estiver registrando uma instância, para ajudar a evitar problemas no gerenciamento de instâncias registradas caso o usuário seja excluído acidentalmente, em vez disso, adicione o parâmetro `--use-instance-profile` ao comando `register` para usar o perfil de instância interno da instância.
## Depois de uma execução do Chef, as instâncias não serão inicializadas
**Problema:** No Chef 11.10 ou anterior, as pilhas configuradas para usar livros de receitas personalizados, depois de uma execução do Chef que usou livros de receitas da comunidade, as instâncias não serão inicializadas. As mensagens de log podem informar que as receitas deixaram de ser compiladas ("Erro na compilação da receita") ou não podem ser carregadas porque não conseguem encontrar uma dependência.
**Causa:** A causa mais provável é que o livro de receitas personalizado ou da comunidade não dá suporte à versão do Chef usada pela pilha. Alguns livros de receitas populares da comunidade, como `[apt](https://supermarket.chef.io/cookbooks/apt)` e `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`, têm problemas de compatibilidade conhecidos com o Chef 11.10.
**Solução:** Em OpsWorks pilhas com a configuração **Usar livros de receitas personalizados do Chef ativada, os livros de receitas** personalizados ou comunitários devem sempre oferecer suporte à versão do Chef que sua pilha usa. Fixe os livros de receitas da comunidade em uma versão (ou seja, defina o número da versão do livro de receitas como uma versão específica), que seja compatível com a versão do Chef configurada nas configurações da pilha. Para encontrar uma versão do livro de receitas da comunidade compatível, visualize o log de alterações de um livro de receitas não compilado e só use a versão mais recente do livro de receitas para a qual a pilha dará suporte. Para fixar uma versão do livro de receitas, especifique um número de versão exato no Berksfile do repositório do livro de receitas personalizado. Por exemplo, .`cookbook 'build-essential', '= 3.2.0'`
## Todas as instâncias de uma camada falham na verificação de integridade do Elastic Load Balancing
**Problema:** você anexa um balanceador de carga do Elastic Load Balancing a uma camada do servidor de aplicações, mas todas as instâncias falham na verificação de integridade.
**Causa:** ao criar um balanceador de carga do Elastic Load Balancing, você deve especificar o caminho de ping que o balanceador de carga chama para determinar se a instância é íntegra. Não se esqueça de especificar um caminho de ping que seja apropriado para a aplicação; o valor padrão é /index.html. Caso a aplicação não inclua um `index.html`, você deve especificar um caminho apropriado, ou a verificação de integridade falhará. Por exemplo, o PHPApp aplicativo Simple usado em [Conceitos básicos das pilhas Linux do Chef 11](gettingstarted.md) não usa index.html; o caminho de ping apropriado para esses servidores é /.
**Solução:** Edite o caminho de ping do balanceador de carga. Para obter mais informações, consulte [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)
## Não consigo me comunicar com um balanceador de carga do Elastic Load Balancing
**Problema:** você cria um balanceador de carga do Elastic Load Balancing e o anexa a uma camada do servidor de aplicações, mas ao clicar no nome DNS ou no endereço IP do balanceador de carga para executar a aplicação, você recebe um erro informando que o servidor remoto não está respondendo.
**Causa:** caso a pilha esteja em execução em uma VPC padrão, ao criar um balanceador de carga do na região, você deve especificar um grupo de segurança. O security group deve ter regras de entrada que permitem o tráfego de entrada pelo endereço IP. Caso você especifique **default VPC security group**, a regra de entrada padrão não aceitará nenhum tráfego de entrada.
**Solução:** Edite as regras de entrada do security group para aceitar tráfego de entrada por endereços IP apropriados.
1. Clique em **Security Groups** no painel [de navegação do EC2 console Amazon](https://console.aws.amazon.com/ec2/).
1. Selecione o security group do balanceador de carga.
1. Clique em **Edit** na guia **Inbound**.
1. Adicione uma regra de entrada com **Source** definido como um CIDR apropriado.
Por exemplo, a especificação de **Anywhere** define o CIDR como 0.0.0.0/0, que leva o balanceador de carga a aceitar o tráfego de entrada de qualquer endereço IP.
## Uma instância no local importada deixa de concluir a configuração do volume após uma reinicialização
**Problema:** você reinicia uma EC2 instância que importou para o OpsWorks Stacks e as exibições do console OpsWorks Stacks **falharam** como status da instância. Isso pode ocorrer em instâncias do Chef 11 ou do Chef 12.
**Causa: **O OpsWorks Stacks talvez não consiga anexar um volume à instância durante o processo de configuração. Uma causa possível é que o OpsWorks Stacks substitui a configuração do volume na instância quando você executa o comando `setup`.
**Solução:** abra a página **Details** da instância e verifique a configuração do volume na área **Volumes**. Você só pode alterar a configuração do volume quando a instância está no estado **stopped**. Certifique-se de que todo volume tenha um ponto de montagem e um nome especificados. Confirme se você forneceu o ponto de montagem correto em sua configuração no OpsWorks Stacks antes de reiniciar a instância.
## Um volume EBS não é anexado novamente após uma reinicialização
**Problema:** Você usa o EC2 console da Amazon para conectar um volume do Amazon EBS a uma instância, mas quando você reinicializa a instância, o volume não está mais conectado.
**Causa:** OpsWorks As pilhas podem reconectar somente os volumes do Amazon EBS que ela conhece, que estão limitados ao seguinte:
+ Volumes que foram criados pelo OpsWorks Stacks.
+ Os volumes da conta que você registrou explicitamente com uma pilha usando a página **Resources**.
**Solução:** gerencie seus volumes do Amazon EBS somente usando o console, a API ou a CLI do OpsWorks Stacks. Se você quiser usar um dos volumes do Amazon EBS da conta com uma pilha, use a página **Recursos** da pilha para registrar o volume e anexá-lo a uma instância. Para obter mais informações, consulte [Gerenciamento de recursos](resources.md).
## Não é possível excluir security groups do OpsWorks Stacks
**Problema:** depois de excluir uma pilha, restam vários grupos de segurança de OpsWorks pilhas que não podem ser excluídos.
**Causa:** Os security groups devem ser excluídos em uma ordem específica.
**Solução:** Primeiro, certifique-se de que nenhuma instância esteja usando os security groups. Em seguida, exclua qualquer um dos seguintes security groups, caso eles existam, na seguinte ordem:
1. AWS- OpsWorks -Servidor em branco
1. AWS- OpsWorks -Servidor-mestre de monitoramento
1. Servidor mestre de banco de dados OpsWorks da AWS
1. AWS- OpsWorks -Memcached-Server
1. AWS- OpsWorks -Servidor personalizado
1. AWS- OpsWorks -NodeJS-App-Server
1. Servidor de aplicativos AWS- OpsWorks -PHP
1. Servidor de aplicativos AWS- OpsWorks -Rails
1. AWS- OpsWorks -Servidor web
1. AWS- OpsWorks -Servidor padrão
1. Servidor AWS- OpsWorks -LB
## Excluiu acidentalmente um grupo de segurança OpsWorks do Stacks
**Problema:** você excluiu um dos grupos de segurança do OpsWorks Stacks e precisa recriá-lo.
**Causa:** Esses security groups normalmente são excluídos por acidente.
**Solução:** O grupo recriado deve ser uma cópia exata do original, inclusive a mesma capitalização para o nome do grupo. Em vez de recriar manualmente o grupo, a abordagem preferida é para o OpsWorks Stacks realizar a tarefa para você. Basta criar uma nova pilha na mesma região da AWS — e VPC, se OpsWorks presente — e o Stacks recriará automaticamente todos os grupos de segurança integrados, incluindo aquele que você excluiu. Você pode então excluir a pilha se não tiver mais uso para ela; os security groups permanecerão.
## Log do Chef encerra abruptamente
**Problema:** Um log do Chef é encerrado abruptamente; o final do log não indica uma execução bem-sucedida ou exibe uma exceção e um rastreamento da pilha.
**Causa:** Esse comportamento costuma ser causado por memória inadequada.
**Solução:** Crie uma instância maior e use o comando `run_command` da CLI do agente para reexecutar as receitas. Para obter mais informações, consulte [Execução de receitas](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes).
## O livro de receitas não é atualizado
**Problema:** você atualizou seus livros de receitas, mas as instâncias da pilha continuam executando as receitas antigas.
**Causa:** o OpsWorks Stacks armazena livros de receitas em cada instância e executa receitas do cache, não do repositório. Quando você inicia uma nova instância, o OpsWorks Stacks baixa seus livros de receitas do repositório para o cache da instância. No entanto, caso você modifique depois os livros de receitas personalizados, o OpsWorks Stacks não atualiza automaticamente os caches das instâncias online.
**Solução:** execute o [comando Atualizar pilha de livros de receitas para direcionar explicitamente as OpsWorks pilhas](workingstacks-commands.md) a atualizar os caches de livros de receitas de suas instâncias on-line.
## As instâncias permanecem presas no status de inicialização
**Problema:** Quando você reinicia uma instância, ou a correção automática é reiniciada automaticamente, a operação de inicialização para no status `booting`.
**Causa:** Uma causa possível desse problema é a configuração da VPC, inclusive uma VPC padrão. As instâncias devem sempre ser capazes de se comunicar com o serviço OpsWorks Stacks, o Amazon S3 e os repositórios de pacotes, livros de receitas e aplicativos. Se, por exemplo, você remover um gateway padrão de uma VPC padrão, as instâncias perderão a conexão com o serviço OpsWorks Stacks. Como o OpsWorks Stacks não consegue mais se comunicar com o [agente](troubleshoot-debug-cli.md) da instância, ele trata a instância como falhada e a [cura automaticamente](workinginstances-autohealing.md). No entanto, sem uma conexão, o OpsWorks Stacks não pode instalar um agente de instância na instância recuperada. Sem um agente, o OpsWorks Stacks não pode executar as receitas de configuração na instância, portanto, a operação de inicialização não pode progredir além do status de “inicialização”.
**Solução:** Modifique a configuração da VPC, de maneira que as instâncias tenham a conectividade necessária.
## Instâncias reiniciam inesperadamente
**Problema:** Uma instância interrompida reinicia inesperadamente.
**Causa 1:** Se você ativou a [recuperação automática](workinginstances-autohealing.md) para suas instâncias, o OpsWorks Stacks realiza periodicamente uma verificação de saúde nas EC2 instâncias associadas da Amazon e reinicia as que não estão íntegras. Se você interromper ou encerrar uma instância OpsWorks gerenciada pelo Stacks usando o EC2 console, a API ou a CLI da Amazon, o Stacks não será notificado. OpsWorks Em vez disso, ele irá considerar a instância parada como não íntegra e iniciá-la automaticamente.
**Solução:** Gerencie apenas as instâncias do usando a API ou a CLI do console do OpsWorks Stacks. Se você usar o OpsWorks Stacks para interromper ou excluir uma instância, ela não será reiniciada. Para obter mais informações, consulte [Descreve como iniciar, parar e reiniciar instâncias 24/7](workinginstances-starting.md) e [Excluindo instâncias do OpsWorks Stacks](workinginstances-delete.md).
**Causa 2:** As instâncias podem falhar por vários motivos. Se você tiver a recuperação automática ativada, o OpsWorks Stacks reinicia automaticamente as instâncias com falha.
**Solução:** Essa é uma operação normal; não há necessidade de fazer nada, a menos que você não queira que o OpsWorks Stacks reinicie as instâncias com falha. Neste caso, você deve desativar a correção automática.
## Processos `opsworks-agent` em execução em instâncias
**Problema:** Diversos processos `opsworks-agent` são executados nas instâncias. Por exemplo:
```
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
```
**Causa:** Estes são os processos legítimos necessários à operação normal do agente. Eles realizam tarefas como o processamento de implantações e o reenvio de mensagens keep-alive para o serviço.
**Solução:** Este é o comportamento normal. Não pare esses processos, pois isso comprometerá a operação do agente.
## Comandos execute\$1recipes inesperados
**Problema:** a seção **Logs** na página de detalhes de uma instância inclui comandos `execute_recipes` inesperados. Comandos `execute_recipes` inesperado também podem ser exibidos nas páginas **Stack** e **Deployments**.
**Causa:** Este problema normalmente é causado por alterações feitas na permissão. Quando você altera as permissões SSH ou sudo de um usuário ou grupo, o OpsWorks Stacks é executado `execute_recipes` para atualizar as instâncias da pilha e também aciona um evento Configure. Outra fonte do comando `execute_recipes` é a atualização do agente da instância pelo OpsWorks Stacks.
**Solução:** Esta é uma operação normal. Não há necessidade de fazer nada.
Para ver quais ações um comando `execute_recipes` realizou, vá até a página **Deployments** e clique no time stamp do comando. Isso abre a página de detalhes do comando, que lista as principais receitas que foram executadas. Por exemplo, a página de detalhes a seguir é de um comando `execute_recipes` que executou `ssh_users` para atualizar as permissões SSH.
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/command_details.png)
Para ver todos os detalhes, clique em **show** na coluna **Log** do comando para exibir o log do Chef associado. Pesquise no registro por**Run List**. OpsWorks As receitas de manutenção de pilhas estarão abaixo`OpsWorks Custom Run List`. Por exemplo, esta é a lista de execuções do comando `execute_recipes` mostrado na captura de tela anterior e que mostra todas as receitas associadas ao comando.
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```
## Solução de problemas do registro da instância
Esta seção contém alguns problemas normalmente encontrados no registro da instância e as soluções.
**nota**
Se você estiver enfrentando problemas no registro, execute `register` com o argumento `--debug`, que apresenta informações adicionais sobre depuração.
**Topics**
+ [EC2O usuário não está autorizado a realizar:...](#common-issues-instance-registration-ec2user)
+ [A credencial deve ter como escopo uma região válida](#common-issues-instance-registration-valid-region)
### EC2O usuário não está autorizado a realizar:...
**Problema:** Um comando `register` retorna algo semelhante ao seguinte:
```
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
```
**Causa:** o comando `register` permanece em execução com as credenciais que não concedem as permissões necessárias. A política do usuário deve permitir a ação `iam:CreateGroup`, dentre outras.
**Solução** Dê a `register` credenciais de usuário do IAM que tenham as permissões necessárias. Para obter mais informações, consulte [Instalar e configurar a AWS CLI](registered-instances-register-registering-cli.md).
### A credencial deve ter como escopo uma região válida
**Problema:** Um comando `register` retorna o seguinte:
```
A client error (InvalidSignatureException) occurred when calling the
DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'.
```
**Causa:** A região do comando deve ser uma região do OpsWorks Stacks válida. Para ver uma lista de regiões compatíveis, consulte [Suporte regional](gettingstarted_intro.md#gettingstarted-intro-region). Este erro normalmente ocorre por um dos seguintes motivos:
+ A pilha está em uma região diferente, e você atribuiu uma pilha da região ao argumento `--region` do comando.
Você não precisa especificar uma região da pilha; as OpsWorks pilhas a determinam automaticamente a partir do ID da pilha.
+ Você omitiu o argumento `--region`, o que implicitamente especifica a região padrão, mas a região padrão não é compatível com o OpsWorks Stacks.
**Solução:** `--region` defina explicitamente como uma região `` de OpsWorks pilhas compatível ou edite seu AWS CLI `config` arquivo para alterar a região padrão para uma região de OpsWorks pilhas compatível. Para obter mais informações, consulte [Configurar a interface de linha de comando da AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).