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á.
# Monitoramento de ambientes no Elastic Beanstalk
Com o monitoramento da integridade do Elastic Beanstalk, você pode verificar a disponibilidade da aplicação e criar alertas que são ativados quando as métricas excedem seus limites. Você pode usar o monitoramento da integridade do Elastic Beanstalk tanto no console quanto na linha de comando para acompanhar o status do seu ambiente.
**Topics**
+ [Monitorando a integridade do ambiente no console AWS de gerenciamento](environment-health-console.md)
+ [Usar a EB CLI para monitorar a integridade do ambiente](health-enhanced-ebcli.md)
+ [Relatórios de integridade básica](using-features.healthstatus.md)
+ [Relatórios e monitoramento de integridade aprimorados no Elastic Beanstalk](health-enhanced.md)
+ [Gerenciar alarmes](using-features.alarms.md)
+ [Visualizar o histórico de alterações de um ambiente do Elastic Beanstalk](using-features.changehistory.md)
+ [Visualizar o stream de eventos de um ambiente do Elastic Beanstalk](using-features.events.md)
+ [Listar e conectar com instâncias de servidor](using-features.ec2connect.md)
+ [Visualizar logs de instâncias do Amazon EC2 no ambiente do Elastic Beanstalk](using-features.logging.md)
+ [Visualização de registros de implantação para um ambiente do Elastic Beanstalk](environments-deployment-logs.md)
# Monitorando a integridade do ambiente no console AWS de gerenciamento
É possível acessar informações operacionais sobre sua aplicação no console do Elastic Beanstalk. O console exibe o status do ambiente e a integridade do aplicativo rapidamente. Na página **Environments (Ambientes)** do console e na página de cada aplicativo, os ambientes na lista são codificados por cores para indicar o status.
**Como monitorar um ambiente no console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Monitoring (Monitoramento)**.
A página Monitoramento mostra as estatísticas gerais do ambiente, como a latência média e a utilização de CPU. Além das estatísticas gerais, é possível visualizar gráficos de monitoramento que mostram o uso de recursos ao longo do tempo. Você pode clicar em qualquer um dos gráficos para visualizar informações mais detalhadas.
**nota**
Por padrão, somente CloudWatch métricas básicas são ativadas, que retornam dados em períodos de cinco minutos. Você pode ativar CloudWatch métricas mais granulares de um minuto editando as configurações do seu ambiente.
## Grafos de monitoramento
A página **Monitoring** (Monitoramento) exibe uma visão geral das métricas relacionadas à integridade do seu ambiente. Isso inclui o conjunto padrão de métricas fornecido pelo Elastic Load Balancing e pela Amazon EC2, além de gráficos que mostram como a saúde do ambiente mudou ao longo do tempo.
A barra acima dos gráficos fornece uma variedade de intervalos de tempo para você selecionar. Por exemplo, selecione **1w** para exibir informações que abrangem a última semana. Ou selecione **3h** para exibir informações que abrangem as últimas três horas.
Para uma maior variedade de seleções de intervalo de tempo, escolha **Custom (Personalizar)**. A partir daqui, você tem duas opções de intervalo: *Absoluto* ou *Relativo*. A opção **Absolute** permite que você especifique um intervalo de datas específico, como *1º de janeiro de 2023 a 30 de junho de 2023*. A opção **Relativo** permite selecionar um número inteiro com uma unidade de tempo específica: *minutos**, horas*, *dias*, *semanas* ou *meses*. Os exemplos incluem *10 horas*, *10 dias* e *10 meses*.
![\[Seção de monitoramento da integridade do ambiente na página de monitoramento do ambiente do console do Elastic Beanstalk\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
## Personalizar o console de monitoramento
Para criar e visualizar métricas personalizadas, você deve usar a Amazon CloudWatch. Com CloudWatch você pode criar painéis personalizados para monitorar seus recursos em uma única visualização. Selecione **Adicionar ao painel** para navegar até o CloudWatch console da Amazon a partir da página de **monitoramento**. CloudWatch A Amazon oferece a opção de criar um novo painel ou selecionar um existente. Para obter mais informações, consulte [Usando CloudWatch painéis da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) no *Guia do CloudWatch usuário da Amazon*.
![\[Seção de monitoramento da integridade do ambiente na página de monitoramento do ambiente do console do Elastic Beanstalk\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
As EC2 métricas do [Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) e [da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) estão habilitadas para todos os ambientes.
Com a [integridade aprimorada](health-enhanced.md), a EnvironmentHealth métrica é ativada e um gráfico é adicionado automaticamente ao console de monitoramento. A integridade aprimorada também acrescenta a [página Integridade](health-enhanced-console.md#health-enhanced-console-healthpage) ao console de gerenciamento. Para obter uma lista das métricas de integridade aprimorada, consulte [Publicação de métricas CloudWatch personalizadas da Amazon para um ambiente](health-enhanced-cloudwatch.md).
# Usar a EB CLI para monitorar a integridade do ambiente
A interface de linha de comando do [Elastic Beanstalk (EB CLI) é uma ferramenta de linha](eb-cli3.md) de comando para gerenciar ambientes. AWS Elastic Beanstalk Também é possível usar a CLI do EB para monitorar a integridade do ambiente em tempo real e com mais granularidade do que está disponível atualmente no console do Elastic Beanstalk
Depois de [instalar](eb-cli3.md#eb-cli3-install) e [configurar](eb-cli3-configuration.md) a EB CLI, você pode iniciar um novo ambiente e implantar seu código com o comando **eb create**. Se você já tem um ambiente criado no console do Elastic Beanstalk, é possível anexar a CLI do EB a ele, executando **eb init** em uma pasta do projeto e seguindo as solicitações (a pasta do projeto pode estar vazia).
**Importante**
Certifique-se de que está usando a versão mais recente da EB CLI executando `pip install` com a opção `--upgrade`:
```
$ sudo pip install --upgrade awsebcli
```
Para concluir as instruções de instalação da CLI do EB, consulte [Instalar a EB CLI com script de configuração (recomendado)](eb-cli3.md#eb-cli3-install).
Para usar a EB CLI para monitorar a integridade do ambiente, configure primeiro uma pasta de projeto local executando **eb init** e seguindo as solicitações. Para obter instruções completas, consulte [Configurar a EB CLI](eb-cli3-configuration.md).
Se você já tem um ambiente em execução no Elastic Beanstalk e deseja usar a CLI do EB para monitorar a integridade, siga estas etapas para anexá-lo ao ambiente existente.
**Para anexar a EB CLI a um ambiente existente**
1. Abra um terminal de linha de comando e navegue até a pasta do usuário.
1. Crie e abra uma nova pasta para o seu ambiente.
1. Execute o comando **eb init** e escolha o aplicativo e o ambiente cuja integridade que você quer monitorar. Se você tiver apenas um ambiente executando o aplicativo escolhido, a CLI do EB o selecionará automaticamente e não será necessário escolher o ambiente, como mostra o exemplo a seguir.
```
~/project$ eb init
Select an application to use
1) elastic-beanstalk-example
2) [ Create new Application ]
(default is 2): 1
Select the default environment.
You can change this later by typing "eb use [environment_name]".
1) elasticBeanstalkEx2-env
2) elasticBeanstalkExa-env
(default is 1): 1
```
**Para monitorar a integridade usando a EB CLI**
1. Abra uma linha de comando e navegue até a pasta do projeto.
1. Execute o comando **eb health** para exibir o status de integridade das instâncias em seu ambiente. Neste exemplo, há cinco instâncias em execução em um ambiente Linux.
```
~/project $ eb health
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-d581497d Ok
i-d481497c Ok
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-d581497d 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-d481497c 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-136e00c0 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-126e00c1 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-8b2cf575 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.04 6.2 0.0 1.0 92.5 0.1
i-d481497c t2.micro 1a 12 mins 0.01 0.09 5.9 0.0 1.6 92.4 0.1
i-136e00c0 t2.micro 1b 12 mins 0.15 0.07 5.5 0.0 0.9 93.2 0.0
i-126e00c1 t2.micro 1b 12 mins 0.17 0.14 5.7 0.0 1.4 92.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.19 0.08 6.5 0.0 1.2 92.1 0.1
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
Neste exemplo, há uma única instância em execução em um ambiente Windows.
```
~/project $ eb health
WindowsSampleApp-env Ok 2018-05-22 17:33:19
WebServer IIS 10.0 running on 64bit Windows Server 2016/2.2.0
total ok warning degraded severe info pending unknown
1 1 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-065716fba0e08a351 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-065716fba0e08a351 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
instance-id type az running % user time % privileged time % idle time cpu
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.1 99.7
instance-id status id version ago deployments
i-065716fba0e08a351 Deployed 2 Sample Application 4 hours
```
## Leitura da saída
A saída exibe o nome do ambiente, a integridade geral do ambiente e a data atual na parte superior da tela.
```
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
```
As próximas três linhas exibem o tipo de ambiente (” WebServer "neste caso), a configuração (Ruby 2.1 com Puma) e um detalhamento de quantas instâncias estão em cada um dos sete estados.
```
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
```
O resto da saída é dividido em quatro seções. A primeira exibe o *status* e a *causa* do status do ambiente geral e, em seguida, de cada instância. O exemplo a seguir mostra duas instâncias no ambiente com o status `Info` e a causa indicando que uma implantação foi iniciada.
```
instance-id status cause health
Overall Ok
i-d581497d Info Performing application deployment (running for 3 seconds)
i-d481497c Info Performing application deployment (running for 3 seconds)
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
```
Para informações sobre o status de integridade e cores, consulte [Status e cores de integridade](health-enhanced-status.md).
A seção de **solicitações** exibe informações de logs do servidor Web sobre cada instância. Neste exemplo, cada instância está fazendo solicitações normalmente e não há erros.
```
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-d581497d 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
i-d481497c 2.7 100.0 0.0 0.0 0.0 0.842* 0.788 0.480 0.305 0.062
i-136e00c0 4.1 100.0 0.0 0.0 0.0 1.520* 1.088 0.883 0.524 0.104
i-126e00c1 2.2 100.0 0.0 0.0 0.0 1.334* 0.791 0.760 0.344 0.197
i-8b2cf575 2.3 100.0 0.0 0.0 0.0 1.162* 0.867 0.698 0.477 0.076
```
A seção de **cpu** mostra as métricas do sistema operacional de cada instância. A saída difere de acordo com o sistema operacional. Veja aqui a saída para ambientes Linux.
```
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-d481497c t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-136e00c0 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-126e00c1 t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
```
Veja aqui a saída para ambientes Windows.
```
instance-id type az running % user time % privileged time % idle time
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.0 99.8
```
Para obter informações sobre as métricas de servidor e de sistema operacional mostradas, consulte [Métricas de instância](health-enhanced-metrics.md).
A seção final, de **implantações**, mostra o status da implantação de cada instância. Se uma implantação contínua falhar, use o ID da implantação, o status e o rótulo da versão mostrados para identificar as instâncias no ambiente que estão executando a versão incorreta.
```
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
## Visualização de integridade interativa
O comando **eb health** exibe um snapshot da integridade do ambiente. Para atualizar as informações exibidas a cada 10 segundos, use a opção `--refresh`.
```
$ eb health --refresh
elasticBeanstalkExa-env Ok 2015-07-09 22:10:04 (1 secs)
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-bb65c145 Ok Application deployment completed 35 seconds ago and took 26 seconds
i-ba65c144 Ok Application deployment completed 17 seconds ago and took 25 seconds
i-f6a2d525 Ok Application deployment completed 53 seconds ago and took 26 seconds
i-e8a2d53b Ok Application deployment completed 32 seconds ago and took 31 seconds
i-e81cca40 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-bb65c145 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-ba65c144 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-f6a2d525 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-e8a2d53b 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-e81cca40 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-bb65c145 t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-ba65c144 t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-f6a2d525 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-e8a2d53b t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-e81cca40 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
instance-id status id version ago deployments
i-bb65c145 Deployed 1 Sample Application 12 mins
i-ba65c144 Deployed 1 Sample Application 12 mins
i-f6a2d525 Deployed 1 Sample Application 12 mins
i-e8a2d53b Deployed 1 Sample Application 12 mins
i-e81cca40 Deployed 1 Sample Application 1 hour
(Commands: Help,Quit, ▼ ▲ ◄ ►)
```
Este exemplo mostra um ambiente que foi recentemente ampliado de uma para cinco instâncias. A operação de escalabilidade foi bem-sucedida e agora todas as instâncias passam pelas verificações de integridade e estão prontas para fazer solicitações. No modo interativo, o status de integridade é atualizado a cada 10 segundos. No canto superior direito, um temporizador faz a contagem regressiva para a próxima atualização.
No canto inferior esquerdo, o relatório exibe uma lista de opções. Para sair do modo interativo, pressione **Q**. Para rolar, pressione as teclas de seta. Para ver uma lista de comandos adicionais, pressione **H**.
## Opções de visualização de integridade interativa
Na visualização interativa da integridade do ambiente, use o teclado para ajustar a visualização e informar ao Elastic Beanstalk para substituir ou reinicializar instâncias individuais. Para ver uma lista de comandos disponíveis na visualização do relatório de integridade no modo interativo, pressione **H**.
```
up,down,home,end Scroll vertically
left,right Scroll horizontally
F Freeze/unfreeze data
X Replace instance
B Reboot instance
<,> Move sort column left/right
-,+ Sort order descending/ascending
P Save health snapshot data file
Z Toggle color/mono mode
Q Quit this program
Views
1 All tables/split view
2 Status Table
3 Request Summary Table
4 CPU%/Load Table
H This help menu
(press Q or ESC to return)
```
# Relatórios de integridade básica
Este tópico explica a funcionalidade oferecida pela integridade básica do Elastic Beanstalk.
AWS Elastic Beanstalk usa informações de várias fontes para determinar se seu ambiente está disponível e processando solicitações da Internet. A integridade de um ambiente é representada por uma das quatro cores e é exibida na página de [visão geral do ambiente](environments-console.md) do console do Elastic Beanstalk. Também está disponível na [DescribeEnvironments](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_DescribeEnvironments.html)API e por meio de chamadas **eb status** com a [CLI do EB](eb-cli3.md).
O sistema básico de relatórios de integridade fornece informações sobre a integridade das instâncias em um ambiente do Elastic Beanstalk com base em verificações de integridade realizadas pelo Elastic Load Balancing para ambientes com carga balanceada ou pelo Amazon Elastic Compute Cloud para ambientes de instância única.
Além de verificar a integridade de suas EC2 instâncias, o Elastic Beanstalk também monitora os outros recursos em seu ambiente e relata recursos ausentes ou configurados incorretamente que podem fazer com que seu ambiente fique indisponível para os usuários.
As métricas coletadas pelos recursos em seu ambiente são publicadas CloudWatch na Amazon em intervalos de cinco minutos. Isso inclui métricas do sistema operacional e métricas EC2 de solicitação do Elastic Load Balancing. Você pode visualizar gráficos com base nessas CloudWatch métricas na [página Monitoramento](environment-health-console.md) do console do ambiente. Para integridade básica, essas métricas não são usadas para determinar a integridade de um ambiente.
**Topics**
+ [Cores de integridade](#using-features.healthstatus.colors)
+ [Verificações de saúde do Elastic Load Balancing](#using-features.healthstatus.understanding)
+ [Verificações de integridade do ambiente de nível do operador e instância única](#monitoring-basic-healthcheck-singleinstance)
+ [Verificações adicionais](#monitoring-basic-additionalchecks)
+ [CloudWatch Métricas da Amazon](#monitoring-basic-cloudwatch)
## Cores de integridade
O Elastic Beanstalk relata a integridade de um ambiente de servidor Web de acordo com o modo como a aplicação em execução responde à verificação de integridade. O Elastic Beanstalk usa uma de quatro cores para descrever o status, como mostrado na tabela a seguir:
****
| Cor | Description |
| --- | --- |
| Cinza | O ambiente está sendo atualizado. |
| Verde | O ambiente passou na verificação de integridade mais recente. Pelo menos uma instância em seu ambiente está disponível e aceitando solicitações. |
| Amarelo | Seu ambiente falhou em uma ou mais verificações de integridade. Algumas solicitações a seu ambiente estão falhando. |
| Vermelha | Seu ambiente falhou em três ou mais verificações de integridade, ou um recurso do ambiente ficou indisponível. As solicitações falham consistentemente. |
Essas descrições se aplicam somente a ambientes que usam relatórios de integridade básica. Consulte [Status e cores de integridade](health-enhanced-status.md) para obter detalhes relacionados à integridade aprimorada.
## Verificações de saúde do Elastic Load Balancing
Em um ambiente com carga balanceada, o Elastic Load Balancing envia uma solicitação para cada instância em um ambiente a cada 10 segundos para confirmar que as instâncias estão íntegras. Por padrão, o load balancer é configurado para abrir uma conexão TCP na porta 80. Se a instância reconhece a conexão, ela é considerada íntegra.
Você pode optar por substituir essa configuração especificando um recurso existente no seu aplicativo. Se você especificar um caminho, como `/health`, o URL da verificação de integridade é definido como `HTTP:80/health`. O URL da verificação de integridade deve ser definido como um caminho que sempre é atendido pelo seu aplicativo. Se estiver definido como uma página estática que é atendida ou armazenada em cache pelo servidor web na frente de seu aplicativo, as verificações de integridade não revelarão problemas com o servidor de aplicativo ou o contêiner da Web. Para obter instruções sobre como modificar o URL de verificação de integridade, consulte [Verificação de saúde](environments-cfg-clb.md#using-features.managing.elb.healthchecks).
Se o URL de uma verificação de integridade está configurado, o Elastic Load Balancing espera uma solicitação GET que ele envia para retornar a resposta `200 OK`. O aplicativo na passará na verificação de integridade se não responder dentro de 5 segundos ou se responder com qualquer outro código de status HTTP. Após 5 falhas consecutivas na verificação de integridade, o Elastic Load Balancing tira a instância de serviço.
Para obter mais informações sobre verificações de integridade do Elastic Load Balancing, consulte [Verificação de integridade](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/TerminologyandKeyConcepts.html#healthcheck) no *Guia do usuário do Elastic Load Balancing*
**nota**
A configuração de um URL de verificação de integridade não altera o comportamento de verificação de integridade de um grupo de Auto Scaling de um ambiente. Uma instância não íntegra é removida do balanceador de carga, mas não é substituída automaticamente pelo Amazon Auto EC2 Scaling, a menos que você configure o Amazon Auto EC2 Scaling para usar a verificação de saúde do Elastic Load Balancing como base para substituir instâncias. Para configurar o Amazon EC2 Auto Scaling para substituir instâncias que falham em uma verificação de integridade do Elastic Load Balancing, consulte. [Configuração da verificação de integridade do ajuste de escala automático para o seu ambiente Elastic Beanstalk](environmentconfig-autoscaling-healthchecktype.md)
## Verificações de integridade do ambiente de nível do operador e instância única
Em uma única instância ou ambiente de nível de trabalho, o Elastic Beanstalk determina a integridade da instância monitorando o status da instância Amazon. EC2 As configurações de integridade do Elastic Load Balancing, incluindo a verificação de integridade HTTP URLs, não podem ser usadas nesses tipos de ambiente.
Para obter mais informações sobre as verificações de status de EC2 instâncias da Amazon, consulte [Monitoramento de instâncias com verificações de status](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) no *Guia EC2 do usuário da Amazon*.
## Verificações adicionais
Além das verificações de integridade do Elastic Load Balancing, o Elastic Beanstalk monitora recursos no ambiente e altera o status de integridade para vermelho caso eles não sejam implantados, não estiverem configurados corretamente ou ficarem indisponíveis. Essas verificações confirmam que:
+ O grupo de Auto Scaling do ambiente está disponível e tem no mínimo uma instância.
+ O security group do ambiente está disponível e configurado para permitir o tráfego de entrada na porta 80.
+ O CNAME do ambiente existe e está apontando para o load balancer correto.
+ Em um ambiente de operador, a fila do Amazon Simple Queue Service (Amazon SQS) está sendo pesquisada pelo menos uma vez a cada três minutos.
## CloudWatch Métricas da Amazon
Com relatórios básicos de saúde, o serviço Elastic Beanstalk não publica nenhuma métrica na Amazon. CloudWatch As CloudWatch métricas usadas para produzir gráficos na [página Monitoramento](environment-health-console.md) do console do ambiente são publicadas pelos recursos do seu ambiente.
Por exemplo, EC2 publica as seguintes métricas para as instâncias no grupo Auto Scaling do seu ambiente:
`CPUUtilization`
Porcentagem de unidades de computação em uso no momento.
`DiskReadBytes``DiskReadOps``DiskWriteBytes``DiskWriteOps`
O número de bytes lidos e gravados e o número de operações de leitura e gravação.
`NetworkIn``NetworkOut`
O número de bytes enviados e recebidos.
O Elastic Load Balancing publica as métricas a seguir para o balanceador de carga do ambiente:
`BackendConnectionErrors`
Número de falhas de conexão entre o load balancer e as instâncias do ambiente.
`HTTPCode_Backend_2XX``HTTPCode_Backend_4XX`
Número de códigos de resposta de êxito (2XX) e erro do cliente (4XX) gerados pelas instâncias em seu ambiente.
`Latency`
O número de segundos entre o momento em que o load balancer retransmite uma solicitação para uma instância e o momento em que a resposta é recebida.
`RequestCount`
O número de solicitações concluídas.
Essas listas não são abrangentes. Para obter uma lista completa das métricas que podem ser relatadas para esses recursos, consulte os seguintes tópicos no Amazon CloudWatch Developer Guide:
**Metrics**
| Namespace | Tópico |
| --- | --- |
| AWS::ElasticLoadBalancing::LoadBalancer | [Métricas e recursos do Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) |
| AWS::AutoScaling::AutoScalingGrupo | [Métricas e recursos do Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) |
| AWS::SQS::Queue | [Métricas e recursos do Amazon SQS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/sqs-metricscollected.html) |
| AWS: :RDS:: DBInstance | [Métricas e dimensões do Amazon RDS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html) |
### Métrica de integridade do ambiente de operador
Somente para ambientes de trabalho, o daemon SQS publica uma métrica personalizada para a integridade do ambiente CloudWatch, em que um valor de 1 é verde. Você pode revisar os dados da métrica de CloudWatch saúde em sua conta usando o `ElasticBeanstalk/SQSD` namespace. A dimensão da métrica é `EnvironmentName` e o nome da métrica é `Health`. Todas as instâncias publicam suas métricas no mesmo namespace.
Para permitir que o daemon publique métricas, o perfil de instância do ambiente deve ter permissão para chamar `cloudwatch:PutMetricData`. Essa permissão está incluída no perfil de instância padrão. Para obter mais informações, consulte [Gerenciar perfis de instância do Elastic Beanstalk](iam-instanceprofile.md).
# Relatórios e monitoramento de integridade aprimorados no Elastic Beanstalk
Esta seção explica a funcionalidade do recurso Integridade aprimorada do Elastic Beanstalk.
Os relatórios de integridade aprimorados são um recurso que você pode ativar em seu ambiente AWS Elastic Beanstalk para permitir a coleta de informações adicionais sobre recursos em seu ambiente. O Elastic Beanstalk analisa as informações reunidas para fornecer uma visão melhor da integridade geral do ambiente e ajudar na identificação de problemas que podem fazer com que a aplicação se torne indisponível.
Além das alterações na forma como as cores de integridade funcionam, a integridade aprimorada adiciona um descritor de *status* que fornece um indicador da gravidade dos problemas observados quando um ambiente está amarelo ou vermelho. Quando mais informações sobre o status atual estiverem disponíveis, você poderá escolher o botão **Causes** para ver informações detalhadas de integridade na [página de integridade](health-enhanced-console.md).
Para fornecer informações de integridade detalhadas sobre as instâncias do Amazon EC2 em execução no ambiente, o Elastic Beanstalk inclui um [agente de integridade](#health-enhanced-agent) na Imagem de máquina da Amazon (AMI) para cada versão de plataforma compatível com a integridade aprimorada. O agente de integridade monitora os logs de servidor da Web e as métricas do sistema, e os transmite para o serviço do Elastic Beanstalk. O Elastic Beanstalk analisa essas métricas e dados do Elastic Load Balancing e do Amazon EC2 Auto Scaling para fornecer uma visão geral da integridade de um ambiente.
Além de coletar e apresentar informações sobre os recursos de ambiente, o Elastic Beanstalk monitora os recursos no ambiente em busca de várias condições de erro e fornece notificações para ajudar você a evitar falhas e resolver problemas de configuração. [Os fatores que influenciam a integridade do seu ambiente](#health-enhanced-factors) incluem os resultados de cada solicitação atendida pelo seu aplicativo, as métricas do sistema operacional de suas instâncias e o status da implantação mais recente.
É possível visualizar o status de integridade em tempo real usando a página [visão geral do ambiente](health-enhanced-console.md) do console do Elastic Beanstalk ou o comando [eb health](health-enhanced-ebcli.md) na [Interface de Linhas de Comando do Elastic Beanstalk](eb-cli3.md) (CLI do EB). Para registrar e monitorar a integridade do ambiente e da instância ao longo do tempo, você pode configurar seu ambiente para publicar as informações coletadas pelo Elastic Beanstalk para melhorar os relatórios de saúde para a CloudWatch Amazon como métricas personalizadas. CloudWatch [as cobranças](https://aws.amazon.com/cloudwatch/pricing/) por métricas personalizadas se aplicam a todas as métricas`EnvironmentHealth`, exceto, o que é gratuito.
**Notas da plataforma Windows**
Ao habilitar os relatórios de integridade aprimorada em um ambiente do Windows Server, não altere a [configuração de log do IIS](https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis). Para o monitoramento de integridade aprimorada funcionar corretamente, o registro do IIS deve ser configurado com o formato **W3C** e os destinos de evento de log **ETW event only (Evento ETW somente)** ou **Both log file and ETW event (Arquivo de log e evento ETW)**.
Além disso, não desabilite nem interrompa o serviço do Windows do [agente de integridade do Elastic Beanstalk](#health-enhanced-agent) em nenhuma das instâncias do ambiente. Para coletar e relatar informações de integridade aprimorada em uma instância, esse serviço deve estar habilitado e em execução.
Na primeira vez que você cria um ambiente, o Elastic Beanstalk solicita a criação dos perfis necessários e habilita relatórios de integridade aprimorados por padrão. Continue lendo para obter detalhes sobre como os relatórios de integridade aprimorada funcionam ou consulte [Habilitar relatórios de integridade aprimorada do Elastic Beanstalk](health-enhanced-enable.md) para começar a usá-los imediatamente.
**Topics**
+ [Agente de integridade do Elastic Beanstalk](#health-enhanced-agent)
+ [Fatores que determinam a integridade de instâncias e ambientes](#health-enhanced-factors)
+ [Personalização de regra de verificação de integridade](#health-enhanced.rules)
+ [Funções de integridade aperfeiçoada](#health-enhanced-roles)
+ [Autorização de integridade aprimorada](#health-enhanced-authz)
+ [Eventos de integridade aprimorada](#health-enhanced-events)
+ [Comportamento dos relatórios de integridade aprimorada durante as atualizações, as implantações e a escalabilidade](#health-enhanced-effects)
+ [Habilitar relatórios de integridade aprimorada do Elastic Beanstalk](health-enhanced-enable.md)
+ [Monitoramento de integridade aprimorada com o console de gerenciamento do ambiente](health-enhanced-console.md)
+ [Status e cores de integridade](health-enhanced-status.md)
+ [Métricas de instância](health-enhanced-metrics.md)
+ [Configurar as regras de integridade aperfeiçoada de um ambiente](health-enhanced-rules.md)
+ [Publicação de métricas CloudWatch personalizadas da Amazon para um ambiente](health-enhanced-cloudwatch.md)
+ [Usar relatórios de integridade aprimorada com a API do Elastic Beanstalk](health-enhanced-api.md)
+ [Formato de log de integridade aprimorado](health-enhanced-serverlogs.md)
+ [Notificações e solução de problemas](environments-health-enhanced-notifications.md)
+ [Análise de ambiente baseada em IA](health-ai-analysis.md)
## Agente de integridade do Elastic Beanstalk
O agente de integridade do Elastic Beanstalk é um processo daemon (ou serviço, em ambientes do Windows) que é executado em cada instância do Amazon EC2 no ambiente, monitorando as métricas de integridade em nível de sistema operacional e aplicação e relatando os problemas para o Elastic Beanstalk. O agente de integridade está incluído em todas as versões da plataforma, a partir da versão 2.0 de cada plataforma.
O agente de saúde relata métricas semelhantes [às publicadas CloudWatch](using-features.healthstatus.md#monitoring-basic-cloudwatch) pelo Amazon EC2 Auto Scaling e pelo Elastic Load Balancing como [parte dos relatórios básicos de](using-features.healthstatus.md) saúde, incluindo carga de CPU, códigos HTTP e latência. O agente de integridade, no entanto, relata diretamente ao Elastic Beanstalk, com maior granularidade e frequência do que os relatórios de integridade básica.
Para a integridade básica, essas métricas são publicados a cada cinco minutos e podem ser monitoradas com gráficos no console de gerenciamento do ambiente. Com a integridade aprimorada, o agente de integridade do Elastic Beanstalk relata métricas para o Elastic Beanstalk a cada 10 segundos. O Elastic Beanstalk usa as métricas fornecidas pelo agente de integridade para determinar o status de integridade de cada instância no ambiente e, combinadas com outros [fatores](#health-enhanced-factors), para determinar a integridade geral do ambiente.
A integridade geral do ambiente pode ser visualizada em tempo real na página de visão geral do ambiente do console do Elastic Beanstalk e é publicada CloudWatch pela Elastic Beanstalk a cada 60 segundos. É possível visualizar as métricas detalhadas relatadas pelo agente de integridade em tempo real com o comando [**eb health**](health-enhanced-ebcli.md) na [CLI do EB](eb-cli3.md).
Por uma taxa adicional, você pode optar por publicar métricas individuais de instância e ambiente a CloudWatch cada 60 segundos. As métricas publicadas no CloudWatch podem ser usadas para criar [gráficos de monitoramento](environment-health-console.md#environment-health-console-customize) no [console de gerenciamento de ambiente](environments-console.md).
Os relatórios de integridade aprimorada implicam em cobrança apenas se você optar por publicar métricas de integridade aprimorada no CloudWatch. Quando você usa a integridade aprimorada, ainda tem as métricas de integridade básica publicadas gratuitamente, mesmo se optar por não publicar as métricas de integridade aprimorada.
Consulte [Métricas de instância](health-enhanced-metrics.md) para obter detalhes sobre as métricas relatadas pelo agente de integridade. Para obter detalhes sobre a publicação de métricas de saúde aprimoradas em CloudWatch, consulte[Publicação de métricas CloudWatch personalizadas da Amazon para um ambiente](health-enhanced-cloudwatch.md).
## Fatores que determinam a integridade de instâncias e ambientes
Além das verificações do sistema de relatórios de integridade básica, incluindo o [Verificações de saúde do Elastic Load Balancing](using-features.healthstatus.md#using-features.healthstatus.understanding) e o [monitoramento de recursos](using-features.healthstatus.md#monitoring-basic-additionalchecks), os relatórios de integridade aprimorada do Elastic Beanstalk coletam dados adicionais sobre o estado das instâncias no ambiente. Isso inclui métricas de sistema operacional, logs de servidor e o estado de operações contínuas de ambiente, como implantações e atualizações. O serviço de relatório de integridade do Elastic Beanstalk combina informações de todas as origens disponíveis e as analisa para determinar a integridade geral do ambiente.
### Operações e comandos
Quando você executa uma operação no ambiente, como a implantação de uma nova versão de uma aplicação, o Elastic Beanstalk faz várias alterações que afetam o status de integridade do ambiente.
Por exemplo, quando você implanta uma nova versão de um aplicativo em um ambiente que está executando várias instâncias, você pode ver mensagens semelhantes à seguinte ao monitorar a integridade do ambiente [com a CLI do EB](health-enhanced-ebcli.md).
```
id status cause
Overall Info Command is executing on 3 out of 5 instances
i-bb65c145 Pending 91 % of CPU is in use. 24 % in I/O wait
Performing application deployment (running for 31 seconds)
i-ba65c144 Pending Performing initialization (running for 12 seconds)
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
i-e8a2d53b Pending 94 % of CPU is in use. 52 % in I/O wait
Performing application deployment (running for 33 seconds)
i-e81cca40 Ok
```
Neste exemplo, o status geral do ambiente é `Ok` e a causa desse status é que o *comando está sendo executado em 3 de 5 instâncias*. Três das instâncias no ambiente têm o status *Pendente*, indicando que há uma operação em andamento.
Quando uma operação é concluída, o Elastic Beanstalk relata as informações adicionais sobre ela. Por exemplo, o Elastic Beanstalk exibe as informações a seguir sobre uma instância que já foi atualizada com a nova versão da aplicação:
```
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
```
As informações de integridade da instância também incluem detalhes sobre a implantação mais recente a cada instância em seu ambiente. Cada instância relata um ID de implantação e o status. O ID de implantação é um número inteiro que aumenta em um a cada vez que você implanta uma nova versão do aplicativo ou altera as definições das opções de configuração na instância, como as variáveis de ambiente. Você pode usar as informações de implantação para identificar as instâncias que estão executando a versão incorreta de seu aplicativo após uma falha [de implantação contínua](using-features.rolling-version-deploy.md).
Na coluna de causa, o Elastic Beanstalk inclui mensagens informativas sobre operações bem-sucedidas e outros estados de integridade em várias verificações de integridade, mas elas não são mantidas indefinidamente. As causas para status de não integridade no ambiente são mantidas até o ambiente retornar a um status de integridade.
### Tempo de espera do comando
O Elastic Beanstalk aplica um tempo de espera do comando a partir do momento que uma operação começa para permitir que uma instância faça a transição para um estado de integridade. Esse tempo limite do comando é definido na configuração de implantação e atualização do ambiente (no namespace [aws:elasticbeanstalk:command](command-options-general.md#command-options-general-elasticbeanstalkcommand)), sendo 10 minutos o padrão.
Durante atualizações contínuas, o Elastic Beanstalk aplica um tempo de espera separado para cada lote na operação. Esse tempo de espera é definido como parte da configuração de atualização contínua do ambiente (no namespace [aws:autoscaling:updatepolicy:rollingupdate](command-options-general.md#command-options-general-autoscalingupdatepolicyrollingupdate)). Se todas as instâncias no lote estiverem íntegras dentro do tempo limite de atualização contínua, a operação continuará no próximo lote. Se não, a operação falha.
**nota**
Caso a aplicação não passe nas verificações de integridade com um status **OK**, mas esteja estável em outro nível, você poderá definir a opção `HealthCheckSuccessThreshold` no [`aws:elasticbeanstalk:command namespace`](command-options-general.md#command-options-general-elasticbeanstalkcommand) para alterar o nível no qual o Elastic Beanstalk considera uma instância como íntegra.
Para que um ambiente de servidor web seja considerado íntegro, cada instância no ambiente ou no lote deve passar por 12 verificações de integridade consecutivas ao longo de dois minutos. Para um ambiente do nível de operador, cada instância deve passar por 18 verificações de integridade. Antes de o comando atingir o tempo limite, o Elastic Beanstalk não reduz o status de integridade de um ambiente quando a verificação de integridade falha. Se as instâncias no ambiente se tornarem íntegras dentro do tempo limite do comando, a operação será bem-sucedida.
### Solicitações HTTP
Quando nenhuma operação está em andamento em um ambiente, a origem principal de informações sobre a integridade do ambiente e da instância são os logs do servidor web de cada instância. Para determinar a integridade de uma instância e a integridade geral do ambiente, o Elastic Beanstalk considera o número de solicitações, o resultado de cada uma e a velocidade com que cada solicitação foi resolvida.
Em plataformas Linux, o Elastic Beanstalk lê e analisa logs do servidor Web para obter informações sobre solicitações HTTP. Na plataforma Windows Server, o Elastic Beanstalk recebe essas informações [diretamente do servidor Web do IIS](health-enhanced-metrics-server-iis.md).
O ambiente pode não ter um servidor web ativo. Por exemplo, a plataforma do Docker de vários contêineres não inclui um servidor web. Outras plataformas incluem um servidor web e o aplicativo pode desabilitá-lo. Nesses casos, o ambiente exige configuração adicional para fornecer ao [agente de integridade do Elastic Beanstalk](#health-enhanced-agent) os logs no formato necessário para que as informações de integridade sejam retransmitidas ao serviço do Elastic Beanstalk. Para mais detalhes, consulte [Formato de log de integridade aprimorado](health-enhanced-serverlogs.md).
### Métricas do sistema operacional
O Elastic Beanstalk monitora as métricas do sistema operacional relatadas pelo agente de integridade para identificar as instâncias que são consistentemente baixas em recursos do sistema.
Consulte [Métricas de instância](health-enhanced-metrics.md) para obter detalhes sobre as métricas relatadas pelo agente de integridade.
## Personalização de regra de verificação de integridade
Os relatórios de integridade aprimorada do Elastic Beanstalk dependem de um conjunto de regras para determinar a integridade do ambiente. Algumas dessas regras podem não ser adequadas para o seu aplicativo. Um caso comum é um aplicativo que retorna erros HTTP 4xx frequentes por padrão. O Elastic Beanstalk, usando uma de suas regras padrão, conclui que algo está errado e altera o status de integridade do ambiente de OK para Warning (Aviso), Degraded (Reduzido) ou Severe (Grave), de acordo com a taxa de erros. Para lidar com esse caso corretamente, o Elastic Beanstalk permite configurar essa regra e ignorar erros de HTTP 4xx da aplicação Para obter mais detalhes, consulte [Configurar as regras de integridade aperfeiçoada de um ambiente](health-enhanced-rules.md).
## Funções de integridade aperfeiçoada
Os relatórios de integridade aperfeiçoada requerem duas funções: uma função de serviço para o Elastic Beanstalk e um perfil de instância para o ambiente. A função de serviço permite que o Elastic Beanstalk interaja AWS com outros serviços em seu nome para coletar informações sobre os recursos em seu ambiente. O perfil de instância permite que as instâncias no ambiente gravem logs no Amazon S3 e comuniquem informações de integridade aprimoradas ao serviço do Elastic Beanstalk.
Quando você cria um ambiente do Elastic Beanstalk usando o console do Elastic Beanstalk ou a CLI do EB, o Elastic Beanstalk cria uma função de serviço padrão e anexa as políticas gerenciadas necessárias a um perfil de instância padrão para o ambiente.
Se você usa a API, um SDK ou o AWS CLI para criar ambientes, deve criar essas funções com antecedência e especificá-las durante a criação do ambiente para usar a integridade aprimorada. Para obter instruções sobre a criação de funções adequadas para seus ambientes, consulte [Perfis do Elastic Beanstalk Service, perfis de instância e políticas de usuário](concepts-roles.md).
Recomendamos que você use *políticas gerenciadas* para o perfil de instância e a função de serviço. Políticas gerenciadas são políticas AWS Identity and Access Management (IAM) que o Elastic Beanstalk mantém. O uso de políticas gerenciadas garante que o ambiente tenha todas as permissões necessárias para funcionar corretamente.
Para o perfil de instância, você pode usar a política gerenciada `AWSElasticBeanstalkWebTier` ou `AWSElasticBeanstalkWorkerTier`, para um ambiente de [nível de servidor Web](concepts-webserver.md) ou de [nível de operador](concepts-worker.md), respectivamente. Para obter detalhes sobre essas duas políticas gerenciadas de perfil de instância, consulte [Gerenciar perfis de instância do Elastic Beanstalk](iam-instanceprofile.md).
## Autorização de integridade aprimorada
As políticas gerenciadas do perfil da instância do Elastic Beanstalk contêm permissão para a ação `elasticbeanstalk:PutInstanceStatistics` . Essa ação não faz parte da API do Elastic Beanstalk. Ela faz parte de uma API diferente que as instâncias de ambiente usam internamente para transmitir informações de integridade aprimoradas para o serviço do Elastic Beanstalk. Você não chama essa API diretamente.
Quando você cria um novo ambiente, a autorização para a ação `elasticbeanstalk:PutInstanceStatistics` é habilitada por padrão. Para aumentar a segurança do ambiente e ajudar a impedir a falsificação de dados de integridade em seu nome, recomendamos manter a autorização para esta ação habilitada. Se você usar políticas gerenciadas para seu perfil da instância, esse recurso estará disponível para seu novo ambiente sem necessidade de configuração adicional. Se você usar um *perfil da instância personalizado* em vez de uma *política gerenciada*, o ambiente poderá mostrar o status de integridade **Sem dados** Isso acontece porque as instâncias não estão autorizadas para a ação que comunica dados de integridade aprimorados ao serviço.
Para autorizar a ação, inclua a instrução a seguir no perfil de instância.
```
{
"Sid": "ElasticBeanstalkHealthAccess",
"Action": [
"elasticbeanstalk:PutInstanceStatistics"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticbeanstalk:*:*:application/*",
"arn:aws:elasticbeanstalk:*:*:environment/*"
]
}
```
Se você não quiser usar a autorização de integridade aprimorada no momento, desabilite-a definindo a opção `EnhancedHealthAuthEnabled` no namespace [aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) como `false`. Se a opção estiver desabilitada, as permissões descritas anteriormente não são necessárias. Você pode removê-las do perfil de instância para [acesso mínimo](security-best-practices.md#security-best-practices.preventive.least-priv) a suas aplicações e ambientes.
**nota**
Anteriormente, a configuração padrão para `EnhancedHealthAuthEnabled` foi `false`, que resultou na autorização para a ação `elasticbeanstalk:PutInstanceStatistics` também ser desabilitada por padrão. Para habilitar essa ação para um ambiente existente, defina a opção `EnhancedHealthAuthEnabled` no [aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) namespace to `true`. É possível configurar essa opção usando uma [configuração de opção](ebextensions-optionsettings.md) em um [arquivo de configuração](ebextensions.md).
## Eventos de integridade aprimorada
O sistema de integridade aprimorada gera eventos quando um ambiente alterna entre estados. O exemplo a seguir mostra eventos gerados pela transição de um ambiente entre os estados **Info (Informações)**, **OK** e **Severe (Grave)**.
![\[A página de visão geral do ambiente do Elastic Beanstalk do console do Elastic Beanstalk mostrando eventos recentes de integridade aprimorada\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-events.png)
Quando ocorre uma transição para um estado pior, o evento de integridade aprimorada inclui uma mensagem indicando a causa da transição.
Nem todas as alterações no status em um nível de instância fazem com que o Elastic Beanstalk gere um evento. Para evitar alarmes falsos, o Elastic Beanstalk gerará um evento relacionado à integridade somente se um problema persistir em várias verificações.
As informações de integridade em tempo real no nível do ambiente, incluindo status, cor e causa, estão disponíveis na página de [visão geral do ambiente](environments-dashboard.md) do console do Elastic Beanstalk e na [CLI do EB](eb-cli3.md). Ao anexar a CLI do EB ao ambiente e executar o comando [**eb health**](health-enhanced-ebcli.md), você também poderá visualizar o status em tempo real de cada uma das instâncias no ambiente.
## Comportamento dos relatórios de integridade aprimorada durante as atualizações, as implantações e a escalabilidade
Habilitar os relatórios de integridade aprimorada pode afetar como seu ambiente se comporta durante atualizações e implantações de configuração. O Elastic Beanstalk não concluirá um lote de atualizações até que todas as instâncias passem nas verificações de integridade de forma consistente. Além disso, como os relatórios de integridade aprimorada aplicam um critério mais rigoroso de integridade e monitoram mais fatores, as instâncias que passam na [verificação de integridade do ELB](using-features.healthstatus.md#using-features.healthstatus.understanding) dos relatórios de integridade básica não passarão necessariamente com os relatórios de integridade aprimorada. Consulte os tópicos sobre [atualizações de configuração contínuas](using-features.rollingupdates.md) e [implantações contínuas](using-features.rolling-version-deploy.md) para obter detalhes sobre como as verificações de integridade afetam o processo de atualização.
Os relatórios de integridade aprimorada também podem destacar a necessidade de definir um [URL de verificação de integridade](environments-cfg-clb.md#using-features.managing.elb.healthchecks) adequado para o Elastic Load Balancing. Quando seu ambiente expandir para atender à demanda, novas instâncias começarão a atender solicitações assim que passarem por verificações de integridade do ELB suficientes. Se não for configurado um URL de verificação de integridade, isso poderá levar apenas 20 segundos após uma nova instância ser capaz de aceitar uma conexão TCP.
Se o seu aplicativo não tiver concluído a inicialização até o momento em que o load balancer o declarar íntegro o suficiente para receber tráfego, você verá um afluxo de solicitações falhadas e seu ambiente começará a não passar nas verificações de integridade. Um URL de verificação de integridade que atinge um caminho fornecido pelo aplicativo pode evitar esse problema. As verificações de integridade do ELB não passarão até que uma solicitação GET para a URL de verificação de integridade retorne um código de status 200.
# Habilitar relatórios de integridade aprimorada do Elastic Beanstalk
Este tópico explica como os relatórios de integridade aprimorados são habilitados. Ele fornece procedimentos para ativar o recurso de integridade aprimorada para o seu ambiente com o console do Elastic Beanstalk, a EB CLI e com uma configuração .ebextensions.
Os novos ambientes criados com as [versões mais recentes da plataforma](concepts.platforms.md) incluem o [agente de AWS Elastic Beanstalk saúde](health-enhanced.md#health-enhanced-agent), que oferece suporte a relatórios de saúde aprimorados. Se você criar o ambiente no console do Elastic Beanstalk ou com a CLI do EB, a integridade aprimorada será habilitada por padrão. Também é possível definir a preferência de relatórios de integridade no código-fonte do aplicativo usando [arquivos de configuração](ebextensions.md).
Os relatórios de integridade aprimorada exigem o [perfil da instância](concepts-roles-instance.md) e a [função de serviço](concepts-roles-service.md) com o conjunto padrão de permissões. Quando você cria um ambiente no console do Elastic Beanstalk, o Elastic Beanstalk cria as funções necessárias automaticamente. Para obter instruções sobre como criar seu primeiro ambiente, consulte [Saiba como começar a usar o Elastic Beanstalk](GettingStarted.md).
**Topics**
+ [Habilitar relatórios de integridade aprimorada usando o console do Elastic Beanstalk](#health-enhanced-enable-console)
+ [Habilitar relatórios de integridade aprimorada usando a CLI do EB](#health-enhanced-enable-ebcli)
+ [Habilitar relatórios de integridade aprimorada usando um arquivo de configuração](#health-enhanced-enable-config)
## Habilitar relatórios de integridade aprimorada usando o console do Elastic Beanstalk
**Como habilitar relatórios de integridade aprimorada em um ambiente em execução usando o console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Configuration (Configuração)**.
1. Na categoria de configuração **Monitoring (Monitoramento)**, escolha **Edit (Editar)**.
1. Em **Health reporting** (Relatórios de integridade), para **System** (Sistema), escolha **Enhanced** (Avançado).
**nota**
As opções de relatórios de integridade avançados não serão exibidas se você estiver usando uma [Plataforma ou versão incompatível](health-enhanced.md).
1. Para salvar as alterações, escolha **Apply (Aplicar)** na parte inferior da página.
O console do Elastic Beanstalk usa como padrão os relatórios de integridade aprimorada ao criar um novo ambiente com uma versão de plataforma de versão 2 (v2). Você pode desabilitar os relatórios de integridade aprimorada alterando a respectiva opção durante a criação do ambiente.
**Como desabilitar os relatórios de integridade aprimorada durante a criação de um ambiente usando o console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. [Crie um aplicativo](applications.md) ou selecione um que já exista.
1. [Crie um ambiente](using-features.environments.md). Na página **Create a new environment** (Criar um novo ambiente), antes de escolher **Create environment** (Criar ambiente), escolha **Configure more options** (Configurar mais opções).
1. Na categoria de configuração **Monitoring (Monitoramento)**, escolha **Edit (Editar)**.
1. Em **Health reporting** (Relatórios de integridade), para **System** (Sistema), escolha **Basic** (Básico).
1. Escolha **Salvar**.
## Habilitar relatórios de integridade aprimorada usando a CLI do EB
Quando você cria um novo ambiente com o comando **eb create**, a EB CLI habilita relatórios de integridade aprimorada, por padrão, e aplica a função de serviço e o perfil da instância padrão.
É possível especificar outra função de serviço por nome usando a opção `--service-role`.
Se você tem um ambiente em execução com relatórios de integridade básica da versão de plataforma v2 e quer mudar para a integridade aprimorada, siga estas etapas.
**Para habilitar a integridade aprimorada no ambiente em execução usando a [EB CLI](eb-cli3.md)**
1. Use o comando **eb config** para abrir o arquivo de configuração no editor de texto padrão.
```
~/project$ eb config
```
1. Localize o namespace `aws:elasticbeanstalk:environment` na seção de configurações. Certifique-se de que o valor de `ServiceRole` não seja nulo e que corresponda ao nome da sua [função de serviço](concepts-roles-service.md).
```
aws:elasticbeanstalk:environment:
EnvironmentType: LoadBalanced
ServiceRole: aws-elasticbeanstalk-service-role
```
1. No namespace `aws:elasticbeanstalk:healthreporting:system:`, altere o valor de `SystemType` para **enhanced**.
```
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
```
1. Salve o arquivo de configuração e feche o editor de texto.
1. A EB CLI inicia uma atualização do ambiente para aplicar as alterações de configuração. Aguarde a conclusão da operação ou pressione **Ctrl\$1C** para sair com segurança.
```
~/project$ eb config
Printing Status:
INFO: Environment update is starting.
INFO: Health reporting type changed to ENHANCED.
INFO: Updating environment no-role-test's configuration settings.
```
## Habilitar relatórios de integridade aprimorada usando um arquivo de configuração
Habilite os relatórios de integridade aprimorada, incluindo um [arquivo de configuração](ebextensions.md) no pacote de origem. O exemplo a seguir mostra um arquivo de configuração que habilita relatórios de integridade aprimorada e atribui o perfil da instância e serviço padrão ao ambiente:
**Example .ebextensions/enhanced-health.config**
```
option_settings:
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
aws:elasticbeanstalk:environment:
ServiceRole: aws-elasticbeanstalk-service-role
```
Se você criou seu próprio perfil de instância ou função de serviço, substitua o texto destacado pelos nomes dessas funções.
# Monitoramento de integridade aprimorada com o console de gerenciamento do ambiente
Ao habilitar os relatórios de integridade aprimorados no AWS Elastic Beanstalk, você pode monitorar a integridade do ambiente no [console de gerenciamento do ambiente](environments-console.md).
**Topics**
+ [Visão geral do ambiente](#health-enhanced-console-overview)
+ [Página de integridade do ambiente](#health-enhanced-console-healthpage)
+ [Página de monitoramento](#health-enhanced-console-monitoringpage)
## Visão geral do ambiente
A [visão geral do ambiente](environments-dashboard.md) exibe o [status da integridade](health-enhanced-status.md) do ambiente e lista eventos que fornecem informações sobre alterações recentes no status da integridade.
**Como visualizar a visão geral do ambiente**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
Para obter informações detalhadas sobre a integridade do ambiente atual, abra a página **Health (Integridade)** selecionando **Causes (Causas)**. Como alternativa, no painel de navegação, escolha **Health (Integridade)**.
## Página de integridade do ambiente
A página **Health** exibe status de saúde, métricas e causas para o meio ambiente e para cada EC2 instância da Amazon no ambiente.
**nota**
O Elastic Beanstalk exibirá a página **Health (Integridade)** somente se você tiver [habilitado o monitoramento de integridade aprimorada](health-enhanced-enable.md) para o ambiente.
A imagem a seguir mostra a página **Health (Integridade)** para um ambiente Linux.
![\[A página de integridade do ambiente para um ambiente Linux\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-instances.png)
A imagem a seguir mostra a página **Health (Integridade)** para um ambiente Windows. Observe que as métricas de CPU são diferentes das contidas em um ambiente Linux.
![\[A página de integridade do ambiente para um ambiente Windows.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-instances-win.png)
Na parte superior da página, é possível ver o número total de instâncias de ambiente, bem como o número de instâncias por status. Para exibir somente as instâncias que têm um status específico, escolha **Filter By (Filtrar por)** e selecione um [status](health-enhanced-status.md).
![\[Página de integridade do ambiente exibindo o filtro por menu para escolher um status de instância a ser exibido\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-instances-status.png)
Para reinicializar ou encerrar uma instância não íntegra, escolha **Instance Actions** e, em seguida, **Reboot** ou **Terminate**.
![\[Página de integridade do ambiente mostrando o menu Ações da instância para reinicializar ou encerrar instâncias não íntegras.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-instances-actions.png)
O Elastic Beanstalk atualiza a página **Health (Integridade)** a cada 10 segundos. Ela relata informações sobre o ambiente e a integridade da instância.
Para cada EC2 instância da Amazon no ambiente, a página exibe o ID e o [status](health-enhanced-status.md) da instância, a quantidade de tempo desde que a instância foi lançada, o ID da implantação mais recente executada na instância, as respostas e a latência das solicitações atendidas pela instância e as informações de carga e utilização da CPU. A linha **Overall (Geral)** exibe informações de médias de resposta e latência para todo o ambiente.
A página exibe muitos detalhes em uma tabela muito ampla. Para ocultar algumas das colunas, escolha ![\[the cog icon.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/cog.png) (**Preferences (Preferências)**). Selecione ou desmarque os nomes das colunas e escolha **Confirm (Confirmar)**.
![\[Selecionando colunas a serem exibidas na página de integridade do ambiente\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-console-preferences.png)
Escolha o **Instance ID (ID da instância)** de qualquer instância para exibir mais informações sobre a instância, incluindo a zona de disponibilidade e o tipo de instância.
![\[Métricas do servidor na página de integridade do ambiente com informações da instância\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-console-instance.png)
Escolha o **Deployment ID (ID de implantação)** de qualquer instância para exibir informações sobre a última [implantação](using-features.deploy-existing-version.md) na instância.
![\[Métricas do servidor na página de integridade do ambiente com informações da implantação\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-console-deployment.png)
As informações de implantação incluem:
+ **ID da implantação**: o identificador exclusivo da [implantação](using-features.deploy-existing-version.md). IDs A implantação começa em 1 e aumenta em um cada vez que você implanta uma nova versão do aplicativo ou altera as configurações que afetam o software ou o sistema operacional em execução nas instâncias do seu ambiente.
+ **Versão**: o rótulo da versão do código-fonte da aplicação usada na implantação.
+ **Status**: o status da implantação, que pode ser `In Progress`, `Deployed` ou `Failed`.
+ **Horário**: para implantações em andamento, o horário em que a implantação começou. Para implantações concluídas, o horário em que a implantação terminou.
Se você [habilitar a integração do X-Ray](environment-configuration-debugging.md) em seu ambiente e instrumentar seu aplicativo com o AWS X-Ray SDK, a página **Health** adicionará links para o AWS X-Ray console na linha de visão geral.
![\[Solicitar métricas na página de integridade do ambiente\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-console-xray.png)
Escolha um link para ver os traços relacionados à estatística destacada no AWS X-Ray console.
## Página de monitoramento
A página de **monitoramento** exibe estatísticas resumidas e gráficos das CloudWatch métricas personalizadas da Amazon geradas pelo sistema aprimorado de relatórios de saúde. Consulte [Monitorando a integridade do ambiente no console AWS de gerenciamento](environment-health-console.md) para obter instruções sobre como adicionar gráficos e estatísticas a essa página.
# Status e cores de integridade
Relatórios de integridade aprimorada representam a integridade geral do ambiente e da instância usando quatro cores, semelhantes aos [relatórios de integridade básica](using-features.healthstatus.md). Os relatórios de integridade aprimorada também fornecem sete status de integridade, que são descritores de palavra única que fornecem uma melhor indicação do estado do ambiente.
## Status da instância e status do ambiente
Toda vez que o Elastic Beanstalk executa uma verificação de integridade no ambiente, os relatórios de integridade aprimorada verificam a integridade de cada instância do ambiente, analisando todos [os dados](health-enhanced.md#health-enhanced-factors) disponíveis. Se alguma verificação de nível inferior falhar, o Elastic Beanstalk fará downgrade da integridade da instância.
O Elastic Beanstalk exibe as informações de integridade do ambiente geral (cor, status e causa) no [console de gerenciamento do ambiente](environments-console.md). Essas informações também estão disponíveis na EB CLI. As mensagens de causa e status de integridade de instâncias individuais são atualizadas a cada dez segundos e estão disponíveis a partir da [CLI do EB](eb-cli3.md) quando você visualiza o status de integridade com [**eb health**](health-enhanced-ebcli.md).
O Elastic Beanstalk usa as alterações de integridade da instância para avaliar a integridade do ambiente, mas não altera imediatamente o status de integridade do ambiente. Quando uma instância não passa nas verificações de integridade pelo menos três vezes no período de um minuto, o Elastic Beanstalk pode fazer downgrade da integridade do ambiente. Dependendo do número de instâncias no ambiente e do problema identificado, uma instância não íntegra pode fazer com que o Elastic Beanstalk exiba uma mensagem informativa ou altere o status de integridade do ambiente de verde (**OK**) para amarelo (**Warning (Aviso)**) ou vermelho (**Degraded (Reduzido**) ou **Severe (Grave)**).
## OK (verde)
Esse status é exibido quando:
+ Uma instância está passando nas verificações de integridade e o agente de integridade não está encontrando nenhum problema.
+ A maioria das instâncias do ambiente está passando nas verificações de integridade e o agente de integridade não está encontrando problemas importantes.
+ Uma instância está passando nas verificações de integridade e está concluindo as solicitações normalmente.
*Exemplo:* o ambiente foi implantado recentemente e está recebendo solicitações normalmente. Cinco por cento das solicitações estão retornando erros da série 400. Implantação concluída normalmente em cada instância.
*Mensagem (instância):* implantação do aplicativo concluída há 23 segundos e levou 26 segundos.
## Aviso (amarelo)
Esse status é exibido quando:
+ O agente de integridade está encontrando um número moderado de falhas de solicitação ou outros problemas em uma instância ou ambiente.
+ Uma operação está em andamento em uma instância e está demorando muito.
*Exemplo:* uma instância no ambiente tem um status de **Severe (Grave)**.
*Mensagem (ambiente):* serviços com problemas em 1 de 5 instâncias.
## Reduzido (vermelho)
Esse status é exibido quando o agente de integridade está encontrando um número alto de falhas de solicitação ou outros problemas em uma instância ou ambiente.
*Exemplo:* o ambiente está no processo de aumentar para até 5 instâncias.
*Mensagem (ambiente)*: 4 instâncias ativas estão abaixo do tamanho mínimo 5 do grupo de Auto Scaling.
## Grave (vermelho)
Esse status é exibido quando o agente de integridade está encontrando um número muito alto de falhas de solicitação ou outros problemas em uma instância ou ambiente.
*Exemplo:* o Elastic Beanstalk não consegue entrar em contato com o balanceador de carga para obter a integridade da instância.
*Mensagem (ambiente):* a integridade do ELB está falhando ou não está disponível para todas as instâncias. Nenhuma das instâncias está enviando dados. Não é possível assumir a função “arn:aws:iam: :123456789012:role/”. aws-elasticbeanstalk-service-role Verifique se a função existe e se está configurada corretamente.
*Mensagem (instâncias):* a integridade do ELB da instância não está disponível há 37 minutos. Não há dados. Visto pela última vez 37 minutos atrás.
## Informações (verde)
Esse status é exibido quando:
+ Uma operação está em andamento em uma instância.
+ Uma operação está em andamento em várias instâncias de um ambiente.
*Exemplo:* uma nova versão do aplicativo está sendo implantada nas instâncias em execução.
*Mensagem (ambiente):* o comando está sendo executado em 3 de 5 instâncias.
*Mensagem (instância):* realizando a implantação do aplicativo (em execução por 3 segundos).
## Pendente (cinza)
Esse status é exibido quando uma operação está em andamento em uma instância dentro do [tempo limite do comando](health-enhanced.md#health-enhanced-factors-timeout).
*Exemplo:* você criou recentemente o ambiente e as instâncias estão sendo inicializadas.
*Mensagem:* realizando a inicialização (em execução por 12 segundos).
## Desconhecido (cinza)
Esse status é exibido quando o Elastic Beanstalk e o agente de integridade estão relatando uma quantidade insuficiente de dados em uma instância.
*Exemplo:* não há dados sendo recebidos.
## Suspenso (cinza)
Esse status é exibido quando o Elastic Beanstalk interrompe o monitoramento da integridade do ambiente. O ambiente pode não funcionar corretamente. Se algumas condições de integridade graves durarem muito tempo, o Elastic Beanstalk fará a transição do ambiente para o status **Suspended (Suspenso)**.
*Exemplo:* o Elastic Beanstalk não pode acessar a [função de serviço](iam-servicerole.md)do ambiente.
*Exemplo:* o [grupo de Auto Scaling](using-features.managing.as.md) criado pelo Elastic Beanstalk para o ambiente foi excluído.
*Mensagem:* a integridade do ambiente mudou de **OK** para **Severe (Grave)**. Não há instâncias listadas. A capacidade desejada do grupo do Auto Scaling está definida como 1.
# Métricas de instância
As métricas de instância fornecem informações sobre a integridade das instâncias em seu ambiente. O [agente de integridade do Elastic Beanstalk](health-enhanced.md#health-enhanced-agent) é executado em cada instância. Ele reúne e transmite novamente métricas sobre instâncias para o Elastic Beanstalk, que as analisa para determinar a integridade das instâncias em seus ambientes.
O agente de integridade do Elastic Beanstalk na instância reúne métricas sobre instâncias de servidores Web e o sistema operacional. Para obter informações sobre o servidor Web em plataformas Linux, o Elastic Beanstalk lê e analisa os logs do servidor Web. Na plataforma Windows Server, o Elastic Beanstalk recebe essas informações diretamente do servidor Web do IIS. Os servidores web fornecem informações sobre solicitações HTTP recebidas: quantas solicitações chegaram, quantas resultaram em erros e quanto tempo levaram para serem resolvidas. O sistema operacional fornece informações do snapshot sobre o estado dos recursos das instâncias: a carga de CPU e a distribuição de tempo gasto em cada tipo de processo.
O agente de integridade reúne métricas de sistema operacional e servidor Web e as transmite novamente para o Elastic Beanstalk a cada 10 segundos. O Elastic Beanstalk analisa os dados e usa os resultados para atualizar o status de integridade de cada instância e o ambiente.
**Topics**
+ [Métricas do servidor web](#health-enhanced-metrics-server)
+ [Métricas do sistema operacional](#health-enhanced-metrics-os)
+ [Métricas do servidor web capturadas no IIS no Windows Server](health-enhanced-metrics-server-iis.md)
## Métricas do servidor web
Em plataformas baseadas no Linux, o agente de integridade do Elastic Beanstalk lê métricas do servidor Web nos logs gerados pelo contêiner da Web ou pelo servidor que processa solicitações em cada instância no ambiente. As plataformas do Elastic Beanstalk são configuradas para gerar dois logs: um no formato legível por humanos e um no formato legível por máquina. O agente de integridade transmite logs legíveis por máquina para o Elastic Beanstalk a cada 10 segundos.
Para obter mais informações sobre o formato de log usado pelo Elastic Beanstalk, consulte [Formato de log de integridade aprimorado](health-enhanced-serverlogs.md).
Na plataforma do Windows Server, o Elastic Beanstalk adiciona um módulo ao pipeline de solicitações do servidor Web do IIS e captura as métricas sobre os tempos de solicitação HTTP e os códigos de resposta. O módulo envia essas métricas para o agente de integridade na instância usando um canal IPC (comunicação entre processos) de alta performance. Para obter mais detalhes sobre a implementação, visite [Métricas do servidor web capturadas no IIS no Windows Server](health-enhanced-metrics-server-iis.md).Métricas do servidor web relatadas
`RequestCount`
Número de solicitações atendidas pelo servidor Web por segundo nos últimos 10 segundos. Mostrado como uma média `r/sec` (solicitações por segundo) na CLI do EB e [Página de integridade do ambiente](health-enhanced-console.md#health-enhanced-console-healthpage).
`Status2xx``Status3xx``Status4xx``Status5xx`
Número de solicitações que resultaram em cada tipo de código de status nos últimos 10 segundos. Por exemplo, as solicitações bem-sucedidas retornam um 200 OK, redirecionamentos são 301, e se o URL inserido não corresponder a nenhum recurso no aplicativo, retornará 404.
A CLI do EB e [Página de integridade do ambiente](health-enhanced-console.md#health-enhanced-console-healthpage) mostram essas métricas como um número bruto de solicitações de instâncias e como uma porcentagem do total de solicitações de ambientes.
`p99.9``p99``p95``p90``p85``p75``p50``p10`
A latência média para *x* % mais lento de solicitações nos últimos 10 segundos, em que *x* é a diferença entre o número e 100. Por exemplo, `p99 1.403` indica que 1% das solicitações mais lentas nos últimos 10 segundos tiveram uma latência média de 1,403 segundos.
## Métricas do sistema operacional
O agente de integridade do Elastic Beanstalk relata as métricas a seguir do sistema operacional. O Elastic Beanstalk usa essas métricas para identificar instâncias que estão sob carga pesada constante. As métricas diferem por sistema operacional.Métricas do sistema operacional relatadas — Linux
`Running`
O tempo que passou desde que a instância foi iniciada.
`Load 1``Load 5`
Média de carga nos últimos períodos de um minuto e cinco minutos. Mostrado como um valor decimal indicando o número médio de processos em execução durante esse período. Se o número mostrado for maior que o número de v CPUs (threads) disponíveis, o restante será o número médio de processos que estavam aguardando.
Por exemplo, se seu tipo de instância tiver quatro v CPUs e a carga for 4,5, haverá uma média de 0,5 processos em espera durante esse período, o equivalente a um processo aguardando 50% do tempo.
`User %``Nice %``System %``Idle %``I/O Wait %`
Porcentagem de tempo que a CPU passou em cada estado nos últimos 10 segundos.Métricas do sistema operacional relatadas — Windows
`Running`
O tempo que passou desde que a instância foi iniciada.
`% User Time``% Privileged Time``% Idle Time`
Porcentagem de tempo que a CPU passou em cada estado nos últimos 10 segundos.
# Métricas do servidor web capturadas no IIS no Windows Server
Na plataforma do Windows Server, o Elastic Beanstalk adiciona um módulo ao pipeline de solicitações do servidor Web do IIS e captura as métricas sobre os tempos de solicitação HTTP e os códigos de resposta. O módulo envia essas métricas para o agente de integridade na instância usando um canal IPC (comunicação entre processos) de alta performance. O agente de integridade agrega essas métricas, combina-as com as métricas do sistema operacional e as envia para o serviço do Elastic Beanstalk.
## Detalhes da implantação
Para capturar as métricas do IIS, o Elastic Beanstalk implementa um [https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx](https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx) gerenciado e assina os eventos [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx) e [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx). Isso permite que o módulo relate a latência das solicitações HTTP e os códigos de resposta de todas as solicitações da web atendidas pelo IIS. Para adicionar o módulo ao pipeline de solicitações do IIS, o Elastic Beanstalk registra o módulo na seção [https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/](https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/) do arquivo de configuração do IIS, `%windir%\System32\inetsrv\config\applicationHost.config`.
O módulo do Elastic Beanstalk no IIS envia as métricas capturadas da solicitação da Web ao agente de integridade na instância, que é um serviço Windows chamado `HealthD`. Para enviar esses dados, o módulo usa [https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx), que fornece uma vinculação segura e confiável que é otimizada para a comunicação na máquina.
# Configurar as regras de integridade aperfeiçoada de um ambiente
AWS Elastic Beanstalk os relatórios de integridade aprimorados dependem de um conjunto de regras para determinar a integridade do seu ambiente. Algumas dessas regras podem não ser adequadas para o seu aplicativo. Veja a seguir alguns exemplos comuns:
+ Você usa ferramentas de teste no lado do cliente. Nesse caso, são esperados erros frequentes de cliente HTTP (4xx).
+ Use o [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/) junto com o Application Load Balancer do ambiente para bloquear tráfego de entrada indesejado. Nesse caso, o Application Load Balancer retorna HTTP 403 para cada mensagem recebida rejeitada.
Por padrão, o Elastic Beanstalk inclui todos os erros HTTP 4xx da aplicação ao determinar a integridade do ambiente. Ele altera o status de integridade do ambiente de **OK** para **Aviso**, **Degradado** ou **Grave**, dependendo da taxa de erros. Para lidar corretamente com casos como os exemplos que mencionamos, o Elastic Beanstalk permite configurar algumas regras de integridade aprimorada. É possível optar por ignorar os erros HTTP 4xx do aplicativo nas instâncias do ambiente ou ignorar os erros HTTP 4xx retornados pelo load balancer do ambiente. Este tópico descreve como fazer essas alterações de configuração.
**nota**
No momento, essas são as únicas personalizações de regras de integridade avançada disponíveis. Não é possível configurar a integridade avançada para ignorar outros erros HTTP além do 4xx.
## Configurar regras de integridade aprimorada usando o console do Elastic Beanstalk
É possível usar o console do Elastic Beanstalk para configurar regras de integridade aprimorada no ambiente.
**Como configurar a verificação de código de status HTTP 4xx usando o console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Configuration (Configuração)**.
1. Na categoria de configuração **Monitoring (Monitoramento)**, escolha **Edit (Editar)**.
1. Em **Health monitoring rule customization (Personalização da regra de monitoramento de integridade)**, habilite ou desabilite as opções **Ignore (Ignorar)** desejadas.
![\[Seção de personalização da regra de monitoramento de integridade na página de configuração de monitoramento do console do Elastic Beanstalk\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/enhanced-health-rule-customization.png)
1. Para salvar as alterações, escolha **Apply (Aplicar)** na parte inferior da página.
## Configurar regras de integridade aprimorada usando a EB CLI
Use a CLI do EB para configurar regras de integridade aprimorada, salvando a configuração do ambiente localmente, adicionando uma entrada que defina essas regras e fazendo upload da configuração no Elastic Beanstalk. Você pode aplicar a configuração salva a um ambiente durante ou após a criação.
**Como configurar a verificação de código de status HTTP 4xx usando a CLI do EB e configurações salvas**
1. Inicialize a pasta do projeto com [**eb init**](eb-cli3-configuration.md).
1. Crie um ambiente executando o comando **eb create**.
1. Salve um modelo de configuração localmente, executando o comando **eb config save**. O exemplo a seguir usa a opção `--cfg` para especificar o nome da configuração.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Abra o arquivo de configuração salvo em um editor de texto.
1. Em `OptionSettings` > `aws:elasticbeanstalk:healthreporting:system:`, adicione uma chave `ConfigDocument` para listar cada regra de integridade aprimorada a ser configurada. O `ConfigDocument` a seguir desabilita a verificação dos códigos de status HTTP 4xx do aplicativo, mantendo a verificação do código HTTP 4xx do load balancer habilitada.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
Rules:
Environment:
Application:
ApplicationRequests4xx:
Enabled: false
ELB:
ELBRequests4xx:
Enabled: true
Version: 1
SystemType: enhanced
...
```
**nota**
É possível combinar `Rules` e `CloudWatchMetrics` na mesma configuração da opção `ConfigDocument`. `CloudWatchMetrics` são descritas em [Publicação de métricas CloudWatch personalizadas da Amazon para um ambiente](health-enhanced-cloudwatch.md).
Se você tiver habilitado `CloudWatchMetrics` anteriormente, o arquivo de configuração recuperado usando o comando **eb config save** já terá uma chave `ConfigDocument` com uma seção `CloudWatchMetrics`. *Não o exclua*, em vez disso, adicione uma seção `Rules` no mesmo valor da opção `ConfigDocument`.
1. Salve o arquivo de configuração e feche o editor de texto. Neste exemplo, o arquivo de configuração atualizado é salvo com um nome (`02-cloudwatch-enabled.cfg.yml`) diferente do arquivo de configuração obtido por download. Isso cria uma configuração salva separada quando o arquivo é carregado. Você pode usar o mesmo nome que o arquivo baixado para substituir a configuração existente, sem criar um novo.
1. Use o comando **eb config put** para fazer upload do arquivo de configuração atualizado no Elastic Beanstalk.
```
$ eb config put 02-cloudwatch-enabled
```
Ao usar os comandos **eb config**, `get` e `put` com configurações salvas, não inclua a extensão do nome do arquivo.
1. Aplique a configuração salva ao ambiente em execução.
```
$ eb config --cfg 02-cloudwatch-enabled
```
A opção `--cfg` especifica um arquivo de configuração nomeado que é aplicado ao ambiente. É possível salvar o arquivo de configuração localmente ou no Elastic Beanstalk. Se um arquivo de configuração com o nome especificado já existir em ambos os locais, a EB CLI usará o arquivo local.
## Configurar regras de integridade aprimorada usando um documento de configuração
O documento de configuração (config) para regras de integridade aprimorada é um documento JSON que lista as regras a serem configuradas.
O exemplo a seguir mostra um documento de configuração que desabilita a verificação de códigos de status HTTP 4xx do aplicativo e habilita a verificação de códigos de status HTTP 4xx do load balancer.
```
{
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
Para o AWS CLI, você passa o documento como um valor para a `Value` chave em um argumento de configurações de opção, que por si só é um objeto JSON. Nesse caso, você deve escapar as aspas no documento incorporado. O comando a seguir verifica se as definições de configuração são válidas.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"Rules\": { \"Environment\": { \"Application\": { \"ApplicationRequests4xx\": { \"Enabled\": false } }, \"ELB\": { \"ELBRequests4xx\": {\"Enabled\": true } } } }, \"Version\": 1 }"
}
]'
```
Para um arquivo de configuração `.ebextensions` em YAML, você pode fornecer o documento JSON no estado em que está.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
# Publicação de métricas CloudWatch personalizadas da Amazon para um ambiente
Você pode publicar os dados coletados por meio de relatórios de saúde AWS Elastic Beanstalk aprimorados na Amazon CloudWatch como métricas personalizadas. A publicação de métricas CloudWatch permite monitorar as mudanças no desempenho do aplicativo ao longo do tempo e identificar possíveis problemas rastreando como o uso de recursos e a latência da solicitação aumentam com a carga.
Ao publicar métricas em CloudWatch, você também as disponibiliza para uso com [gráficos de monitoramento e [alarmes](using-features.alarms.md)](environment-health-console.md#environment-health-console-graphs). Uma métrica gratuita, *EnvironmentHealth*, é ativada automaticamente quando você usa relatórios de saúde aprimorados. Métricas personalizadas que não *EnvironmentHealth*sejam [CloudWatch cobranças](https://aws.amazon.com/cloudwatch/pricing/) padrão.
Para publicar métricas CloudWatch personalizadas para um ambiente, você deve primeiro habilitar relatórios de integridade aprimorados sobre o ambiente. Para obter instruções, consulte [Habilitar relatórios de integridade aprimorada do Elastic Beanstalk](health-enhanced-enable.md).
**Topics**
+ [Métricas de relatórios de integridade aprimorada](#health-enhanced-cloudwatch-metrics)
+ [Configurando CloudWatch métricas usando o console do Elastic Beanstalk](#health-enhanced-cloudwatch-console)
+ [Configurando métricas CloudWatch personalizadas usando o EB CLI](#health-enhanced-cloudwatch-ebcli)
+ [Fornecer documentos Config de métrica personalizada](#health-enhanced-cloudwatch-configdocument)
## Métricas de relatórios de integridade aprimorada
Quando você ativa relatórios de integridade aprimorados em seu ambiente, o sistema aprimorado de relatórios de integridade publica automaticamente uma [métrica CloudWatch personalizada](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/publishingMetrics.html), *EnvironmentHealth*. [Para publicar métricas adicionais CloudWatch, configure seu ambiente com essas métricas usando o [console do [Elastic Beanstalk](#health-enhanced-cloudwatch-console),](#health-enhanced-cloudwatch-ebcli) EB CLI ou .ebextensions.](command-options.md)
Você pode publicar as seguintes métricas de saúde aprimoradas do seu ambiente para CloudWatch.Métricas disponíveis — todas as plataformas
`EnvironmentHealth`
*Ambiente apenas. * Essa é a única CloudWatch métrica que o sistema aprimorado de relatórios de saúde publica, a menos que você configure métricas adicionais. A integridade do ambiente é representada por um dos sete [status](health-enhanced-status.md). No CloudWatch console, esses status são mapeados para os seguintes valores:
+ 0: OK
+ 1: Informações
+ 5: Desconhecido
+ 10: Sem dados
+ 15: Aviso
+ 20: Reduzido
+ 25: Grave
`InstancesSevere``InstancesDegraded``InstancesWarning``InstancesInfo``InstancesOk``InstancesPending``InstancesUnknown``InstancesNoData`
*Ambiente apenas. * Essas métricas indicam o número de instâncias no ambiente com cada status de integridade. `InstancesNoData` indica o número de instâncias para as quais não há dados recebidos.
`ApplicationRequestsTotal``ApplicationRequests5xx``ApplicationRequests4xx``ApplicationRequests3xx``ApplicationRequests2xx`
*Instância e ambiente. * Indica o número total de solicitações concluídas pela instância ou ambiente, e o número de solicitações que foram concluídas com cada categoria de código de status.
`ApplicationLatencyP10``ApplicationLatencyP50``ApplicationLatencyP75``ApplicationLatencyP85``ApplicationLatencyP90``ApplicationLatencyP95``ApplicationLatencyP99``ApplicationLatencyP99.9`
*Instância e ambiente. * Indica o tempo médio, em segundos, que leva para concluir com mais rapidez *x* % de solicitações.
`InstanceHealth`
*Instância apenas.* Indica o status da integridade atual da instância. A integridade da instância é representada por um dos sete [status](health-enhanced-status.md). No CloudWatch console, esses status são mapeados para os seguintes valores:
+ 0: OK
+ 1: Informações
+ 5: Desconhecido
+ 10: Sem dados
+ 15: Aviso
+ 20: Reduzido
+ 25: GraveMétricas disponíveis — Linux
`CPUIrq``CPUIdle``CPUUser``CPUSystem``CPUSoftirq``CPUIowait``CPUNice`
*Instância apenas.* Indica a porcentagem de tempo que a CPU passou em cada estado no último minuto.
`LoadAverage1min`
*Instância apenas.* A carga média de CPU da instância durante o último minuto.
`RootFilesystemUtil`
*Instância apenas.* Indica a porcentagem do espaço em disco em uso.Métricas disponíveis — Windows
`CPUIdle``CPUUser``CPUPrivileged`
Instância apenas. Indica a porcentagem de tempo que a CPU passou em cada estado no último minuto.
## Configurando CloudWatch métricas usando o console do Elastic Beanstalk
Você pode usar o console do Elastic Beanstalk para configurar seu ambiente para publicar CloudWatch métricas aprimoradas de relatórios de saúde e disponibilizá-las para uso com gráficos de monitoramento e alarmes.
**Para configurar métricas CloudWatch personalizadas no console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Configuration (Configuração)**.
1. Na categoria de configuração **Monitoring (Monitoramento)**, escolha **Edit (Editar)**.
1. Em **Health reporting (Relatórios de integridade)**, selecione as métricas de instância e de ambiente a serem publicadas no CloudWatch. Para selecionar várias métricas, mantenha pressionada a tecla **Ctrl** enquanto escolhe.
1. Para salvar as alterações, escolha **Apply (Aplicar)** na parte inferior da página.
A ativação de métricas CloudWatch personalizadas as adiciona à lista de métricas disponíveis na [página **Monitoramento**](environment-health-console.md).
## Configurando métricas CloudWatch personalizadas usando o EB CLI
Use a CLI do EB para configurar métricas personalizadas, salvando a configuração do ambiente localmente, adicionando uma entrada que define as métricas para publicação e fazendo upload da configuração no Elastic Beanstalk. Você pode aplicar a configuração salva a um ambiente durante ou após a criação.
**Para configurar métricas CloudWatch personalizadas com a CLI do EB e configurações salvas**
1. Inicialize a pasta do projeto com [**eb init**](eb-cli3-configuration.md).
1. Crie um ambiente executando o comando **eb create**.
1. Salve um modelo de configuração localmente, executando o comando **eb config save**. O exemplo a seguir usa a opção `--cfg` para especificar o nome da configuração.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Abra o arquivo de configuração salvo em um editor de texto.
1. Em `OptionSettings` >`aws:elasticbeanstalk:healthreporting:system:`, adicione uma `ConfigDocument` chave para ativar cada uma das CloudWatch métricas desejadas. Por exemplo, `ConfigDocument` publica as métricas `ApplicationRequests5xx` e `ApplicationRequests4xx` no nível de ambiente e as métricas `ApplicationRequestsTotal` no nível de instância.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
CloudWatchMetrics:
Environment:
ApplicationRequests5xx: 60
ApplicationRequests4xx: 60
Instance:
ApplicationRequestsTotal: 60
Version: 1
SystemType: enhanced
...
```
No exemplo, 60 indica o número de segundos entre as medidas. No momento, este é o único valor aceito.
**nota**
É possível combinar `CloudWatchMetrics` e `Rules` na mesma configuração da opção `ConfigDocument`. `Rules` são descritas em [Configurar as regras de integridade aperfeiçoada de um ambiente](health-enhanced-rules.md).
Se você tiver usado `Rules` anteriormente para configurar as regras de integridade aprimorada, o arquivo de configuração recuperado por meio do comando **eb config save** já terá uma chave `ConfigDocument` com uma seção `Rules`. *Não o exclua*, em vez disso, adicione uma seção `CloudWatchMetrics` no mesmo valor da opção `ConfigDocument`.
1. Salve o arquivo de configuração e feche o editor de texto. Neste exemplo, o arquivo de configuração atualizado é salvo com um nome (`02-cloudwatch-enabled.cfg.yml`) que seja diferente do arquivo de configuração que foi baixado. Isso cria uma configuração salva separada quando o arquivo é carregado. Você pode usar o mesmo nome que o arquivo baixado para substituir a configuração existente, sem criar um novo.
1. Use o comando **eb config put** para fazer upload do arquivo de configuração atualizado no Elastic Beanstalk.
```
$ eb config put 02-cloudwatch-enabled
```
Ao usar os comandos **eb config** `get` e `put` com configurações salvas, não inclua a extensão de arquivo.
1. Aplique a configuração salva ao ambiente em execução.
```
$ eb config --cfg 02-cloudwatch-enabled
```
A opção `--cfg` especifica um arquivo de configuração nomeado que é aplicado ao ambiente. É possível salvar o arquivo de configuração localmente ou no Elastic Beanstalk. Se um arquivo de configuração com o nome especificado já existir em ambos os locais, a EB CLI usará o arquivo local.
## Fornecer documentos Config de métrica personalizada
O documento de configuração (config) das métricas CloudWatch personalizadas da Amazon é um documento JSON que lista as métricas a serem publicadas nos níveis de ambiente e instância. O exemplo a seguir mostra um documento config que habilita todas as métricas disponíveis no Linux.
```
{
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
Para o AWS CLI, você passa o documento como um valor para a `Value` chave em um argumento de configurações de opção, que por si só é um objeto JSON. Nesse caso, você deve escapar as aspas no documento incorporado.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"CloudWatchMetrics\": {\"Environment\": {\"ApplicationLatencyP99.9\": 60,\"InstancesSevere\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"InstancesUnknown\": 60,\"ApplicationLatencyP85\": 60,\"InstancesInfo\": 60,\"ApplicationRequests2xx\": 60,\"InstancesDegraded\": 60,\"InstancesWarning\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"InstancesNoData\": 60,\"InstancesPending\": 60,\"ApplicationLatencyP10\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"InstancesOk\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60},\"Instance\": {\"ApplicationLatencyP99.9\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"ApplicationLatencyP85\": 60,\"CPUUser\": 60,\"ApplicationRequests2xx\": 60,\"CPUIdle\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"RootFilesystemUtil\": 60,\"LoadAverage1min\": 60,\"CPUIrq\": 60,\"CPUNice\": 60,\"CPUIowait\": 60,\"ApplicationLatencyP10\": 60,\"LoadAverage5min\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"CPUSystem\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60,\"InstanceHealth\": 60,\"CPUSoftirq\": 60}},\"Version\": 1}"
}
]'
```
Para um arquivo de configuração `.ebextensions` em YAML, você pode fornecer o documento JSON no estado em que está.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
# Usar relatórios de integridade aprimorada com a API do Elastic Beanstalk
Como os relatórios de integridade AWS Elastic Beanstalk aprimorados têm requisitos de função e pilha de soluções, você deve atualizar os scripts e o código usados antes do lançamento dos relatórios de integridade aprimorados antes de poder usá-los. Para manter a compatibilidade com versões anteriores, os relatórios de integridade aprimorada não são habilitados por padrão quando você cria um ambiente usando a API do Elastic Beanstalk.
Você configura relatórios de saúde aprimorados definindo a função de serviço, o perfil da instância e as opções de CloudWatch configuração da Amazon para seu ambiente. Você pode fazer isso de três formas: definindo as opções de configuração na pasta `.ebextensions`, com as configurações salvas, ou configurando-as diretamente no parâmetro `create-environment` da chamada `option-settings`.
Para usar a API ou a interface de linha de AWS comando (CLI) para criar um ambiente que ofereça suporte à integridade aprimorada, você deve: SDKs
+ Criar uma função de serviço e um perfil da instância com as [permissões](concepts-roles.md) apropriadas
+ Crie um ambiente com uma nova [versão da plataforma](concepts.platforms.md)
+ Definir as [opções de configuração](command-options.md) de tipo de sistema, perfil da instância e função de serviço
Use as seguintes opções de configuração nos namespaces `aws:elasticbeanstalk:healthreporting:system`, `aws:autoscaling:launchconfiguration` e `aws:elasticbeanstalk:environment` para configurar seu ambiente para os relatórios de integridade aprimorada.
## Opções de configuração de integridade aprimorada
**SystemType**
Namespace: `aws:elasticbeanstalk:healthreporting:system`
Para habilitar os relatórios de integridade aprimorada, defina como **enhanced**.
**IamInstanceProfile**
Namespace: `aws:autoscaling:launchconfiguration`
Defina como o nome de um perfil da instância configurado para uso com o Elastic Beanstalk.
**ServiceRole**
Namespace: `aws:elasticbeanstalk:environment`
Defina como o nome de uma função de serviço configurada para uso com o Elastic Beanstalk.
**ConfigDocument** (opcional)
Namespace: `aws:elasticbeanstalk:healthreporting:system`
Um documento JSON que define as métricas de instância e ambiente nas quais publicar CloudWatch. Por exemplo:
```
{
"CloudWatchMetrics":
{
"Environment":
{
"ApplicationLatencyP99.9":60,
"InstancesSevere":60
}
"Instance":
{
"ApplicationLatencyP85":60,
"CPUUser": 60
}
}
"Version":1
}
```
**nota**
Os documentos de configuração podem exigir formatação especial, como aspas de escape, dependendo de como você os disponibiliza no Elastic Beanstalk. Consulte [Fornecer documentos Config de métrica personalizada](health-enhanced-cloudwatch.md#health-enhanced-cloudwatch-configdocument) para ver exemplos.
# Formato de log de integridade aprimorado
AWS Elastic Beanstalk as plataformas usam um formato de log de servidor web personalizado para transmitir com eficiência as informações sobre solicitações HTTP para o sistema aprimorado de relatórios de saúde. O sistema analisa os logs, identifica os problemas e define a integridade da instância e do ambiente adequadamente. Se você desabilitar o servidor de proxy da Web no ambiente e atender às solicitações diretamente do contêiner da Web, ainda poderá usar totalmente os relatórios de integridade aprimorada configurando o servidor para enviar logs para o local e no formato usado pelo [agente de integridade do Elastic Beanstalk](health-enhanced.md#health-enhanced-agent).
**nota**
As informações desta página são relevantes apenas para plataformas Linux. Na plataforma Windows Server, o Elastic Beanstalk recebe informações sobre solicitações HTTP diretamente do servidor Web do IIS. Para obter detalhes, consulte [Métricas do servidor web capturadas no IIS no Windows Server](health-enhanced-metrics-server-iis.md).
## Configuração do log de servidor web
As plataformas do Elastic Beanstalk são configuradas para gerar dois logs com informações sobre solicitações HTTP. O primeiro está no formato verboso e fornece informações detalhadas sobre a solicitação, incluindo informações sobre o agente do usuário do solicitante e um carimbo de data e hora legível.
**/var/log/nginx/access.log**
O exemplo a seguir é de um proxy nginx em execução em um ambiente de servidor da web Ruby, mas o formato é semelhante ao do Apache.
```
172.31.24.3 - - [23/Jul/2015:00:21:20 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:21 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
```
O segundo log está no formato conciso. Ele inclui informações relevantes apenas para os relatórios de integridade aprimorados. Esse log é gerado em uma subpasta chamada `healthd` e muda de hora em hora. Os logs antigos são excluídos imediatamente após o rodízio.
**/var/log/nginx/healthd/application.log.2015-07-23-00**
O exemplo a seguir mostra um log no formato legível por máquina.
```
1437609879.311"/"200"0.083"0.083"177.72.242.17
1437609879.874"/"200"0.347"0.347"177.72.242.17
1437609880.006"/bad/path"404"0.001"0.001"177.72.242.17
1437609880.058"/"200"0.530"0.530"177.72.242.17
1437609880.928"/bad/path"404"0.001"0.001"177.72.242.17
```
O formato do log de integridade aprimorado inclui as seguintes informações:
+ A hora da solicitação, no horário do Unix.
+ O caminho da solicitação
+ O código de status HTTP para o resultado
+ A hora da solicitação
+ A hora de upstream
+ O cabeçalho HTTP `X-Forwarded-For`
Para os proxies nginx, os horários são impressos em segundos de ponto flutuante, com três casas decimais. Para o Apache, são usados microssegundos inteiros.
**nota**
Se você vir um aviso semelhante ao seguinte em um arquivo de log, em que `DATE-TIME` é uma data e hora, e estiver usando um proxy personalizado, como em um ambiente do Docker de vários contêineres, você deverá usar um .ebextension para configurar o ambiente a fim que de `healthd` possa ler os arquivos de log:
```
W, [DATE-TIME #1922] WARN -- : log file "/var/log/nginx/healthd/application.log.DATE-TIME" does not exist
```
É possível começar com .ebextension no [Docker de vários contêineres demonstrativo](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/docker-multicontainer-v2.zip).
**/etc/nginx/conf.d/webapp\$1healthd.conf**
O exemplo a seguir mostra a configuração do log para nginx com o formato de log `healthd` destacado.
```
upstream my_app {
server unix:///var/run/puma/my_app.sock;
}
log_format healthd '$msec"$uri"'
'$status"$request_time"$upstream_response_time"'
'$http_x_forwarded_for';
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
```
**/etc/httpd/conf.d/healthd.conf**
O exemplo a seguir mostra a configuração do log para Apache.
```
LogFormat "%{%s}t\"%U\"%s\"%D\"%D\"%{X-Forwarded-For}i" healthd
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/healthd/application.log.%Y-%m-%d-%H 3600" healthd
```
## Gerar logs para a geração de relatórios de integridade aprimorados
Para fornecer logs para o agente de integridade, faça o seguinte:
+ Gere os logs no formato correto, como mostrado na seção anterior
+ Gere logs em `/var/log/nginx/healthd/`
+ Nomeie os logs usando o seguinte formato: `application.log.$year-$month-$day-$hour`
+ Faça rodízio dos logs uma vez por hora
+ Não trunque os logs
# Notificações e solução de problemas
**Experimente a Amazon Q Developer CLI para solução de problemas assistida por IA**
A Amazon Q Developer CLI pode ajudar a solucionar problemas de ambiente rapidamente. A Q CLI fornece soluções verificando o status do ambiente, analisando eventos, analisando logs e fazendo perguntas esclarecedoras. Para obter mais informações e orientações detalhadas, consulte Solução de problemas de [ambientes do Elastic Beanstalk com o Amazon](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) Q Developer CLI nos blogs. AWS
Esta página lista mensagens de problemas comuns e links para mais informações. As mensagens aparecem no [Painel de visão geral do ambiente](environments-dashboard-envoverview.md) do Elastic Beanstalk e são registradas em [eventos](using-features.events.md) quando os problemas de integridade persistem em várias verificações.
## Implantações
O Elastic Beanstalk monitora a consistência do ambiente após as implantações. Se uma implantação contínua falhar, a versão do aplicativo em execução nas instâncias de seu ambiente pode variar. Isso poderá ocorrer se uma implantação for bem-sucedida em um ou mais lotes, mas falhar antes da conclusão de todos os lotes.
*Versão incorreta do aplicativo encontrada em 2 de 5 instâncias. Versão esperada "v1" (implantação 1).*
*Versão incorreta do aplicativo nas instâncias do ambiente. Versão esperada "v1" (implantação 1).*
A versão esperada do aplicativo não está em execução em algumas ou todas as instâncias de um ambiente.
*Versão incorreta do aplicativo "v2" (implantação 2). Versão esperada "v1" (implantação 1).*
O aplicativo implantado em uma instância não tem a versão esperada. Se uma implantação falhar, a versão esperada será redefinida para a versão da implantação bem-sucedida mais recente. No exemplo acima, a primeira implantação (versão "v1") foi bem-sucedida, mas a segunda falhou (versão "v2"). Todas as instâncias que executam "v2" não são consideradas íntegras.
Para resolver esse problema, inicie outra implantação. Você pode [reimplantar uma versão anterior](using-features.deploy-existing-version.md) que você sabe que funciona, ou configurar seu ambiente para [ignorar verificações de integridade](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console) durante a implantação e reimplantar a nova versão para forçar a conclusão da implantação.
Você também pode identificar e encerrar as instâncias que estão executando a versão incorreta do aplicativo. O Elastic Beanstalk iniciará instâncias com a versão correta para substituir as instâncias encerradas. Use o [comando de integridade da EB CLI](health-enhanced-ebcli.md) para identificar as instâncias que estão executando a versão incorreta do aplicativo.
## Servidor de aplicativos
*15% das solicitações estão com erro de HTTP 4xx*
*20% das solicitações para o ELB estão com erro de HTTP 4xx.*
Uma alta porcentagem de solicitações HTTP para uma instância ou um ambiente está falhando com erros 4xx.
Um código de status da série 400 indica que o usuário fez uma solicitação incorreta, como solicitar uma página que não existe (404 Arquivo não encontrado) ou que o usuário não tem acesso (403 Proibido). Um pequeno número de 404s não é incomum, mas um grande número pode significar que existem links internos ou externos para páginas indisponíveis. Esses problemas podem ser resolvidos ao corrigir os links internos inválidos e ao adicionar redirecionamentos de links externos inválidos.
*5% das solicitações estão falhando com HTTP 5xx*
*3% das solicitações para o ELB estão falhando com HTTP 5xx.*
Uma alta porcentagem de solicitações HTTP para uma instância ou um ambiente está falhando com códigos de status da série 500.
Uma código de status da série 500 indica que o servidor de aplicativos detectou um erro interno. Esses problemas indicam que há um erro no código do aplicativo que deve ser identificado e corrigido rapidamente.
*95% da CPU está em uso*
Em uma instância, o agente de integridade está relatando uma porcentagem extremamente alta de uso da CPU e define a integridade da instância como **Aviso** ou **Reduzido**.
Escale o ambiente para retirar carga das instâncias.
## Instância do operador
*20 mensagens em espera na fila (25 segundos atrás)*
As solicitações estão sendo adicionadas à fila do ambiente do operador com mais rapidez do que podem ser processadas. Escale o ambiente para aumentar a capacidade.
*5 mensagens em Dead Letter Queue (15 segundos atrás)*
As solicitações de operador estão falhando repetidamente e sendo adicionadas à [Filas de mensagens não entregues](using-features-managing-env-tiers.md#worker-deadletter). Verifique o motivo da falha das solicitações na fila de mensagens mortas.
## Outros recursos
*4 instâncias ativas estão abaixo do tamanho mínimo 5 do grupo de Auto Scaling*
O número de instâncias em execução no ambiente é menor do que o mínimo configurado para o grupo de Auto Scaling.
*As notificações do grupo de Auto Scaling (groupname) foram excluídas ou modificadas*
As notificações configuradas para o seu grupo de Auto Scaling foram modificadas fora do Elastic Beanstalk.
# Análise de ambiente baseada em IA
AWS Elastic Beanstalk A análise baseada em inteligência artificial da identifica as causas principais e recomenda soluções para problemas de saúde ambiental. Quando seu ambiente enfrenta problemas, você pode solicitar uma análise de IA usando as operações de `RetrieveEnvironmentInfo` API `RequestEnvironmentInfo` e com o tipo de `analyze` informação para obter insights gerados pela IA e soluções recomendadas.
**nota**
A análise de IA está disponível somente nas versões compatíveis do Amazon Linux 2 e AL2023 da plataforma lançadas em ou após 16 de fevereiro de 2026.
## Como funciona
[Quando você solicita uma análise de IA, o Elastic Beanstalk executa um script em uma instância em seu ambiente que coleta eventos recentes, integridade da instância e registros (até 170.000 tokens de dados).](https://docs.aws.amazon.com/bedrock/latest/userguide/key-definitions.html) Em seguida, ele envia esses dados para o Amazon Bedrock em sua conta e retorna insights e as próximas etapas recomendadas.
## Pré-requisitos
Antes de usar a análise de IA, verifique se seu ambiente atende aos seguintes requisitos:
+ Ambiente executando uma [versão de plataforma compatível](#health-ai-analysis-supported-platforms)
+ [Perfil da instância](iam-instanceprofile.md) com as permissões necessárias (veja [Permissões obrigatórias](#health-ai-analysis-permissions) abaixo)
+ **Detalhes do caso de uso antrópico** — a análise de IA usa modelos Anthropic Claude por meio do Amazon Bedrock. A Anthropic exige que você envie um formulário único de detalhes do caso de uso antes de poder invocar seus modelos. Para enviar esse formulário, selecione qualquer modelo antrópico do catálogo de modelos no [console do Amazon Bedrock](https://console.aws.amazon.com/bedrock/) ou ligue para a [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html)API. Você só precisa fazer isso uma vez por AWS conta. Se você enviar o formulário da conta de gerenciamento da AWS Organizations, ele cobrirá automaticamente todas as contas dos membros da organização. Para obter mais informações, consulte [Acesse os modelos básicos do Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html).
+ **GovCloud regiões** — Se você estiver usando regiões AWS GovCloud (EUA), deverá habilitar o acesso ao and/or modelo mais recente do Anthropic Claude Sonnet Opus no Amazon Bedrock antes de usar a análise de IA. Para obter instruções sobre como habilitar o acesso a modelos em GovCloud regiões, consulte [Gerenciar o acesso aos modelos da Amazon Bedrock Foundation](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html#model-access-govcloud). Para obter informações sobre o modelo mais recente disponível do Anthropic Claude Sonnet and/or Opus, consulte [Regiões e modelos suportados](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html) para perfis de inferência.
## Permissões obrigatórias
Para usar a análise de IA, o perfil de instância do Amazon EC2 para seu ambiente deve ter permissões para invocar o Amazon Bedrock. Adicione as seguintes permissões ao seu perfil de instância:
+ `bedrock:InvokeModel`
+ `bedrock:ListFoundationModels`
+ `elasticbeanstalk:DescribeEvents`
+ `elasticbeanstalk:DescribeEnvironmentHealth`
Para obter mais informações sobre como configurar perfis de instância, consulte[Gerenciar perfis de instância do Elastic Beanstalk](iam-instanceprofile.md).
## Usando a análise de IA no console
**Da visão geral do ambiente**
Quando o status de saúde do seu ambiente é **Advertido**, **Degradado ou **Grave****, um botão **Análise de IA** aparece na seção de visão geral do ambiente. Clique nesse botão para iniciar uma análise de IA do seu ambiente.
**Na página Registros**
Você também pode acessar a análise de IA na página **Registros** no painel de navegação. Clique no botão **Análise de IA** para solicitar uma análise baseada em IA do estado atual do seu ambiente.
## Usando a análise de IA com o AWS CLI
Você pode usar a API do Elastic Beanstalk AWS CLI por meio do para solicitar e recuperar análises de IA de forma programática.
**Solicitar análise de IA**
Use a [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html)operação com o `InfoType` parâmetro definido como`analyze`.
**Example AWS CLI - Solicitar análise de IA**
```
aws elasticbeanstalk request-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
**Recupere a análise de IA**
Use a [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html)operação com o conjunto de `InfoType` parâmetros `analyze` para recuperar os resultados da análise.
**Example AWS CLI - Recupere a análise de IA**
```
aws elasticbeanstalk retrieve-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
A resposta inclui uma análise gerada por IA do estado atual do ambiente, juntamente com soluções recomendadas para quaisquer problemas identificados.
## Usando a análise de IA com o EB CLI
Se você usar a CLI do EB, poderá solicitar a análise de IA com a opção `--analyze` (`-ai`) do **eb logs** comando. O comando solicita a análise, espera que ela seja concluída e exibe os resultados.
**Example EB CLI - Solicitar análise de IA**
```
$ eb logs --analyze
```
A `--analyze` opção não é compatível com`--instance`,`--all`,`--zip`, ou`--log-group`. Para obter a referência completa do comando, consulte[**eb logs**](eb3-logs.md).
**nota**
A `--analyze` opção requer o EB CLI versão 3.27 ou posterior.
## Considerações importantes
+ **Preços** — A análise de IA usa o Amazon Bedrock para processar os dados do seu ambiente, e os preços padrão do Amazon Bedrock se aplicam às invocações do modelo. Para obter detalhes de preço, consulte [Preços do Amazon Bedrock](https://aws.amazon.com/bedrock/pricing/).
+ **Requisito de plataforma** — A análise de IA está disponível somente no Amazon Linux 2 e AL2023 nas versões baseadas da plataforma lançadas em ou após 16 de fevereiro de 2026. Para usar esse recurso, atualize seu ambiente para uma versão de plataforma compatível. Para obter mais informações, consulte [Atualizar a versão de plataforma do ambiente Elastic Beanstalk](using-features.platform.upgrade.md).
+ **Permissões** — Antes de usar a análise de IA, certifique-se de que seu perfil de instância tenha as permissões necessárias do Amazon Bedrock (`bedrock:InvokeModel`e`bedrock:ListFoundationModels`) e as permissões do Elastic `elasticbeanstalk:DescribeEvents` Beanstalk (e). `elasticbeanstalk:DescribeEnvironmentHealth`
+ **Privacidade de dados** — A análise envia eventos e registros do ambiente para o Amazon Bedrock em sua conta para processamento. Para obter informações sobre como o Amazon Bedrock lida com seus dados, consulte [Amazon Bedrock Security and](https://aws.amazon.com/bedrock/security-compliance/) Compliance.
+ **Cotas de serviço** — A análise de IA usa um modelo Anthropic Claude no Amazon Bedrock, que tem cotas padrão para solicitações por minuto e tokens por minuto. Se você encontrar erros de limitação, poderá solicitar um aumento de cota. Consulte [Solicitar um aumento de cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)para ter mais informações.
## Versões compatíveis da plataforma
A análise de IA é suportada no Amazon Linux 2 e AL2023 nas versões baseadas da plataforma lançadas em ou após [16 de fevereiro de 2026](RELEASE_NOTES_URL). Para verificar a versão da sua plataforma, consulte as notas de lançamento do [Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/welcome.html).
# Gerenciar alarmes
Este tópico orienta pelas etapas para criar alarmes para métricas que você está monitorando. Ele também fornece instruções para visualizar alarmes existentes e verificar o estado deles.
É possível criar alarmes para as métricas que você está monitorando usando o console do Elastic Beanstalk. Os alarmes ajudam você a monitorar as mudanças em seu AWS Elastic Beanstalk ambiente para que você possa identificar e mitigar facilmente os problemas antes que eles ocorram. Por exemplo, defina um alarme que notifique quando o uso da CPU no ambiente exceder um determinado limite, garantindo que você seja notificado antes que ocorra um problema em potencial. Para obter mais informações, consulte [Usando o Elastic Beanstalk com a Amazon CloudWatch](AWSHowTo.cloudwatch.md).
**nota**
O Elastic CloudWatch Beanstalk usa para monitoramento e alarmes CloudWatch , o que significa que os custos são aplicados AWS à sua conta para todos os alarmes que você usa.
Para obter mais informações sobre monitoramento de métricas específicas, consulte [Relatórios de integridade básica](using-features.healthstatus.md).
**Para verificar o estado dos alarmes**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, selecione **Alarmes**.
A página exibe uma lista de alarmes existentes. Se algum alarme estiver no estado de alarme, ele será sinalizado com o ícone de aviso (![\[Image of the warning icon.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/warning.png)).
1. Para filtrar alarmes, escolha o menu suspenso e selecione um filtro.
1. Para editar ou excluir um alarme, selecione o ícone de edição (![\[Image of a cog, which serves as the edit icon.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/cog.png)) ou o ícone de exclusão (![\[Image of an x, which servers as the delete icon.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/x.png)), respectivamente.
**Para criar um alarme**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Monitoring (Monitoramento)**.
1. Localize a métrica para a qual você deseja criar um alarme e, em seguida, selecione o ícone de alarme (![\[Image of a bell, which serves as the alarm icon.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/bell.png)). A página **Add alarm (Adicionar alarme)** é exibida.
1. Insira detalhes sobre o alarme:
+ **Name**: o nome desse alarme.
+ **Description** (opcional): uma breve descrição do alarme.
+ **Period**: o intervalo de tempo entre as leituras.
+ **Threshold**: descreve o comportamento e o valor que a métrica deve exceder para acionar um alarme.
+ **Change state after**: o tempo após o limite ter sido excedido para acionar uma alteração no estado do alarme.
+ **Notify (Notificar)**: o tópico do Amazon SNS que é notificado quando um alarme muda de estado.
+ **Notify when state changes to**:
+ **OK**: a métrica está dentro do limite definido.
+ **Alarm**: a métrica excedeu o limite definido.
+ **Insufficient data**: o alarme acabou de ser acionado, a métrica não está disponível ou não há dados suficientes para a métrica determinar o estado do alarme.
1. Escolha **Adicionar**. O status do ambiente muda para cinza enquanto o ambiente é atualizado. É possível visualizar o alarme criado escolhendo **Alarms (Alarmes)** no painel de navegação.
# Visualizar o histórico de alterações de um ambiente do Elastic Beanstalk
Este tópico explica como você pode usar o Console do Elastic Beanstalk para visualizar um histórico das alterações de configuração que foram feitas nos seus ambientes Elastic Beanstalk.
O Elastic Beanstalk busca seu histórico de alterações em eventos registrados no [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) e os exibe em uma lista em que você pode navegar e filtrar facilmente.
O painel Change History (Histórico de alterações) exibe as seguintes informações sobre alterações feitas nos seus ambientes:
+ A data e a hora em que uma alteração foi feita
+ O usuário do IAM que foi responsável por uma alteração feita
+ A ferramenta de origem (interface de linhas de comando do Elastic Beanstalk (CLI do EB) ou console) que foi usada para fazer a alteração
+ O parâmetro de configuração e os novos valores que foram definidos
Quaisquer dados confidenciais que fazem parte da alteração, como os nomes dos usuários do banco de dados afetados pela alteração, não são exibidos no painel.
**Para ver o histórico de alterações**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Change history** (Histórico de alterações).
A página Change history (Histórico de alterações) mostra uma lista das alterações de configuração que foram feitas nos seus ambientes do Elastic Beanstalk.
Observe os seguintes pontos sobre como navegar pelas informações desta página:
+ Você pode pesquisar a lista escolhendo **<**(previous) (anterior) ou, **>** (next) (próximo), ao selecionar um número de página específico.
+ Na coluna **Configuration changes** (Alterações de configuração), selecione o ícone de seta para alternar entre expandir e recolher a lista de alterações no cabeçalho **Changes made** (Alterações feitas).
+ Use a barra de pesquisa para filtrar os resultados da lista de histórico de alterações. Você pode inserir qualquer string para refinar a lista de alterações que são exibidas.
Observe o seguinte sobre como filtrar os resultados exibidos:
+ O filtro de pesquisa não diferencia maiúsculas de minúsculas.
+ Você pode filtrar as alterações exibidas com base nas informações da coluna **Configuration changes ** (Alterações de configuração), mesmo quando ela não estiver visível por estar recolhida dentro **das alterações feitas**.
+ Você só pode filtrar os resultados exibidos. No entanto, o filtro permanece no lugar mesmo se você optar por ir para outra página para exibir mais resultados. Seus resultados filtrados também são anexados ao conjunto de resultados da página seguinte.
Os exemplos a seguir demonstram como os dados mostrados na tela anterior podem ser filtrados:
+ Digite **GettingStartedApp-env** na caixa de pesquisa para restringir os resultados e incluir apenas as alterações feitas no ambiente chamado *GettingStartedApp-env*.
+ Digite **example3** na caixa de pesquisa para refinar os resultados para incluir apenas as alterações feitas por usuários do IAM cujo nome de usuário contém a string *example3*.
+ Digite **2020-10** na caixa de pesquisa para refinar os resultados para incluir apenas as alterações feitas durante o mês de outubro de 2020. Altere o valor da pesquisa **2020-10-16** para filtrar ainda mais os resultados exibidos para incluir apenas as alterações feitas no dia 16 de outubro de 2020.
+ Digite **proxy:staticfiles** na caixa de pesquisa para refinar os resultados para incluir apenas as alterações feitas no namespace denominado *aws:elasticbeanstalk:environment:proxy:staticfiles*. As linhas exibidas são o resultado do filtro. Isso é verdade mesmo para resultados que são recolhidos em **Changes made** (Alterações feitas).
# Visualizar o stream de eventos de um ambiente do Elastic Beanstalk
Este tópico explica como acessar eventos e notificações associados à sua aplicação.
## Visualizar eventos com o console do Elastic Beanstalk
**Para visualizar eventos com o console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Eventos**.
A página de eventos exibe uma lista de todos os eventos que foram registrados para o ambiente. É possível percorrer a lista escolhendo **<** (anterior), **>** (próximo) ou números de página. É possível filtrar por tipo de evento usando a lista suspensa **Severity (Gravidade)**.
## Visualizar eventos com ferramentas de linha de comando
A [EB CLI](eb-cli3.md) e a [AWS CLI](https://aws.amazon.com/cli/) fornecem comandos para recuperar eventos. Se você estiver gerenciando seu ambiente usando a EB CLI, use [**eb events**](eb3-events.md) para imprimir uma lista de eventos. Este comando também tem uma opção `--follow` que continua a mostrar novos eventos até que você pressione **Ctrl\$1C** para interromper a saída.
Para extrair eventos usando o AWS CLI, use o `describe-events` comando e especifique o ambiente por nome ou ID:
```
$ aws elasticbeanstalk describe-events --environment-id e-gbjzqccra3
{
"Events": [
{
"ApplicationName": "elastic-beanstalk-example",
"EnvironmentName": "elasticBeanstalkExa-env",
"Severity": "INFO",
"RequestId": "a4c7bfd6-2043-11e5-91e2-9114455c358a",
"Message": "Environment update completed successfully.",
"EventDate": "2015-07-01T22:52:12.639Z"
},
...
```
Para obter mais informações sobre ferramentas de linha de comando, consulte [Configurar a interface de linha de comando EB (EB CLI) para gerenciar o Elastic Beanstalk](eb-cli3.md).
# Listar e conectar com instâncias de servidor
Este tópico explica como visualizar uma lista das EC2 instâncias da Amazon que executam seu ambiente de aplicativos do Elastic Beanstalk e como se conectar a elas.
Você pode ver uma lista de EC2 instâncias da Amazon executando seu ambiente de AWS Elastic Beanstalk aplicativos por meio do console do Elastic Beanstalk. Você pode se conectar a instâncias usando qualquer cliente SSH. Você pode se conectar a instâncias que executam o Windows usando a Área de Trabalho Remota.
**Importante**
Antes de acessar suas instâncias Amazon provisionadas pelo Elastic Beanstalk, você deve criar um par de chaves EC2 da Amazon e configurar sua Amazon provisionada pelo Elastic Beanstalk para usar o EC2 par de chaves da Amazon. EC2instances EC2 Você pode configurar seus pares de EC2 chaves da Amazon usando o [AWS Management Console](https://console.aws.amazon.com/). Para obter instruções sobre como criar um par de chaves para a Amazon EC2, consulte o *Amazon EC2 Getting Started Guide*. Para obter mais informações sobre como configurar suas EC2 instâncias da Amazon para usar um par de EC2 chaves da Amazon, consulte[EC2 key pair](using-features.managing.security.md#using-features.managing.security.keypair).
Por padrão, o Elastic Beanstalk não permite EC2 conexões remotas com instâncias em um contêiner do Windows, exceto aquelas em contêineres legados do Windows. (O Elastic EC2 Beanstalk configura instâncias em contêineres antigos do Windows para usar a porta 3389 para conexões RDP.) Você pode habilitar conexões remotas com suas EC2 instâncias que executam o Windows adicionando uma regra a um grupo de segurança que autoriza o tráfego de entrada para as instâncias. Recomendamos enfaticamente que você remova a regra quando encerrar sua conexão remota. Você pode adicioná-la novamente na próxima vez que precisar fazer login remotamente. Para obter mais informações, consulte [Adicionar uma regra para tráfego de entrada RDP para uma instância do Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html#authorizing-access-to-an-instance-rdp) e [Conectar-se à instância do Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2Win_GetStarted.html#connecting_to_windows_instance) no *Guia do usuário do Amazon Elastic Compute Cloud para Microsoft Windows*.
**Para visualizar e se conectar às EC2 instâncias da Amazon para um ambiente**
1. Abra o EC2 console da Amazon em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação do console, escolha **Load Balancers**.
1. Os balanceadores de carga criados pelo Elastic Beanstalk têm **awseb** no nome. Encontre e clique no load balancer do seu ambiente.
1. Escolha a guia **Instances** (Instâncias) no painel inferior do console.
Uma lista de instâncias que o balanceador de carga do seu ambiente do Elastic Beanstalk usa é exibida. Anote o ID da instância à qual você deseja se conectar.
1. No painel de navegação do EC2 console da Amazon, escolha **Instâncias** e encontre o ID da sua instância na lista.
1. Clique com o botão direito do mouse no ID da EC2 instância da Amazon em execução no balanceador de carga do seu ambiente e selecione **Connect** no menu de contexto.
1. Anote o endereço DNS público da instância na guia **Description**.
1. Conecte-se a uma instância executando Linux usando o cliente SSH de sua escolha e digite **ssh -i .ec2/mykeypair.pem EC2-user@. of-the-instance
Para obter mais informações sobre como se conectar a uma instância do Amazon EC2 Linux, consulte [Getting Started with Amazon EC2 Linux Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) no *Amazon EC2 User Guide*.
*Se o seu ambiente do Elastic Beanstalk [usa o.NET na plataforma Windows](create_deploy_NET.container.console.md) Server, [consulte Getting Started with EC2 Amazon Windows Instances no Amazon](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html) User Guide. EC2 *
# Visualizar logs de instâncias do Amazon EC2 no ambiente do Elastic Beanstalk
Este tópico explica os tipos de logs de instância fornecidos pelo Elastic Beanstalk. Também fornece instruções detalhadas para recuperá-los e gerenciá-los.
As instâncias do Amazon EC2 no ambiente do Elastic Beanstalk geram logs que podem ser visualizados para solucionar problemas com sua aplicação ou arquivos de configuração. Os registros são criados pelo servidor web, servidor de aplicativos e scripts da plataforma Elastic Beanstalk e são armazenados localmente em CloudFormation instâncias individuais. Você pode recuperá-los facilmente usando o [console de gerenciamento do ambiente](environments-console.md) ou a CLI do EB. Você também pode configurar seu ambiente para transmitir registros para o Amazon CloudWatch Logs em tempo real.
Logs finais são as últimas 100 linhas dos arquivos de log usados com mais frequência, ou seja, logs operacionais do Elastic Beanstalk e logs do servidor Web ou do servidor de aplicações. Quando logs finais são solicitados no console de gerenciamento do ambiente ou com **eb logs**, uma instância no ambiente concatena as entradas de log mais recentes em um único arquivo de texto e o carrega no Amazon S3.
Logs em pacote são logs completos para uma maior variedade de arquivos de log, incluindo logs do yum e do cron e vários logs do CloudFormation. Quando logs em pacote são solicitados, uma instância no ambiente empacota todos os arquivos de log em um arquivo ZIP e o carrega no Amazon S3.
Para fazer upload de logs alternados para o Amazon S3, as instâncias no ambiente precisam ter um [perfil da instância](concepts-roles-instance.md) com permissão para gravar no bucket do Amazon S3 do Elastic Beanstalk. Essas permissões são incluídas no perfil de instância padrão cuja criação o Elastic Beanstalk solicita ao iniciar um ambiente no console do Elastic Beanstalk pela primeira vez.
**Como recuperar logs de instâncias**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, selecione **Logs**.
1. Escolha **Request Logs (Logs de solicitação)** e escolha o tipo de logs a serem recuperados. Para obter logs finais, escolha **Últimas 100 linhas**. Para obter logs em pacote, selecione **Logs completos**.
1. Quando o Elastic Beanstalk terminar de recuperar seus logs, escolha **Download**.
O Elastic Beanstalk armazena logs finais e em pacote em um bucket do Amazon S3 e gera um URL pré-assinado do Amazon S3 que pode ser usado para acessar os logs. O Elastic Beanstalk exclui os arquivos do Amazon S3 após 15 minutos.
**Atenção**
Qualquer pessoa que tenha o URL do Amazon S3 pré-assinado poderá acessar os arquivos antes que eles sejam excluídos. Disponibilize o URL somente para partes confiáveis.
**nota**
Sua política de usuário deve ter a permissão `s3:DeleteObject`. O Elastic Beanstalk usa suas permissões de usuário para excluir os logs do Amazon S3.
Para mantê-los, configure o ambiente para publicá-los no Amazon S3 automaticamente depois que forem alternados. Para habilitar a alternância de logs para o Amazon S3, siga o procedimento em [Configurar visualização de logs de instância](environments-cfg-logging.md#environments-cfg-logging-console). As instâncias em seu ambiente tentarão fazer upload dos logs que foram girados uma vez por hora.
Se o aplicativo gera logs em um local que não faz parte da configuração padrão da plataforma do ambiente, você pode estender a configuração padrão usando arquivos de configuração (`[.ebextensions](ebextensions.md)`). É possível adicionar arquivos de log de seu aplicativo aos logs finais, aos logs em pacote e à rotação de logs.
Para streaming de registros em tempo real e armazenamento de longo prazo, configure seu ambiente para [transmitir registros para o Amazon CloudWatch Logs](#health-logs-cloudwatchlogs).
Para obter uma análise baseada em IA dos registros, eventos e integridade da instância do seu ambiente para identificar as causas-raiz e as soluções para problemas de saúde, consulte. [Análise de ambiente baseada em IA](health-ai-analysis.md)
**Topics**
+ [Local de log em instâncias do Amazon EC2](#health-logs-instancelocation)
+ [Local de log no Amazon S3](#health-logs-s3location)
+ [Configurações de rotação de log no Linux](#health-logs-logrotate)
+ [Extensão da configuração padrão da tarefa de log](#health-logs-extend)
+ [Transmissão de arquivos de log para o Amazon CloudWatch Logs](#health-logs-cloudwatchlogs)
## Local de log em instâncias do Amazon EC2
Os logs são armazenados em locais padrão nas instâncias do Amazon EC2 no ambiente. O Elastic Beanstalk gera os logs a seguir.
**Amazon Linux 2**
+ `/var/log/eb-engine.log`
**Amazon Linux AMI (AL1)**
**nota**
[Em 18 de julho de 2022,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **o Elastic Beanstalk definiu o status de todas as ramificações da plataforma baseadas no Amazon Linux AMI AL1 () como descontinuadas.** Para obter mais informações sobre como migrar para uma ramificação da plataforma Amazon Linux 2023 atual e totalmente compatível, consulte [Migrar a aplicação Linux do Elastic Beanstalk para o Amazon Linux 2023 ou Amazon Linux 2](using-features.migration-al.md).
+ `/var/log/eb-activity.log`
+ `/var/log/eb-commandprocessor.log`
**Windows Server**
+ `C:\Program Files\Amazon\ElasticBeanstalk\logs\`
+ `C:\cfn\log\cfn-init.log`
Esses logs contêm mensagens sobre atividades de implantação, incluindo mensagens relacionadas a arquivos de configuração ([`.ebextensions`](ebextensions.md)).
Cada aplicativo e servidor web armazena logs em uma pasta própria:
+ **Apache**: `/var/log/httpd/`
+ **IIS**: `C:\inetpub\wwwroot\`
+ **Node.js**: `/var/log/nodejs/`
+ **nginx**: `/var/log/nginx/`
+ **Passenger**: `/var/app/support/logs/`
+ **Puma**: `/var/log/puma/`
+ **Python**: `/opt/python/log/`
+ **Tomcat**: `/var/log/tomcat/`
## Local de log no Amazon S3
Ao solicitar logs finais ou em pacote de seu ambiente, ou quando as instâncias fazem upload de logs alternados, eles são armazenados em seu bucket do Elastic Bucket no Amazon S3. O Elastic Beanstalk cria um `elasticbeanstalk-region-account-id` bucket com o nome de cada região na qual AWS você cria ambientes. Dentro desse bucket, os logs são armazenados no caminho `resources/environments/logs/logtype/environment-id/instance-id`.
Por exemplo, os registros da instância`i-0a1fd158`, no AWS ambiente do Elastic `e-mpcwnwheky` Beanstalk `us-west-2` na região na conta, são `123456789012` armazenados nos seguintes locais:
+ **Logs finais**:
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/tail/e-mpcwnwheky/i-0a1fd158`
+ **Logs em pacote**:
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/bundle/e-mpcwnwheky/i-0a1fd158`
+ **Logs alternados**:
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/publish/e-mpcwnwheky/i-0a1fd158`
**nota**
Você pode localizar o ID do ambiente no console de gerenciamento do ambiente.
O Elastic Beanstalk exclui os logs finais e em pacote do Amazon S3 automaticamente 15 minutos após eles serem criados. Os logs alternados são mantidos até você excluí-los ou movê-los para o Amazon Glacier.
## Configurações de rotação de log no Linux
Em plataformas Linux, o Elastic Beanstalk usa `logrotate` para alternar logs periodicamente. Se configurado, depois que um log é alternado localmente, a tarefa de alternância de logs o seleciona e faz upload dele no Amazon S3. Por padrão, os logs que são alternados localmente não são exibidos em logs finais ou em pacote.
É possível encontrar arquivos de configuração do Elastic Beanstalk para `logrotate` em `/etc/logrotate.elasticbeanstalk.hourly/`. Essas configurações de rotação são específicas da plataforma e podem mudar em futuras versões dela. Para obter mais informações sobre as definições disponíveis e configurações de exemplo, execute `man logrotate`.
Os arquivos de configuração são chamado de trabalhos cron em `/etc/cron.hourly/`. Para obter mais informações sobre `cron`, execute `man cron`.
## Extensão da configuração padrão da tarefa de log
O Elastic Beanstalk usa arquivos em subpastas de `/opt/elasticbeanstalk/tasks` (Linux) ou `C:\Program Files\Amazon\ElasticBeanstalk\config` (Windows Server) na instância do Amazon EC2 para configurar tarefas para logs finais, logs em pacote e alternância de logs.
**No Amazon Linux:**
+ **Logs finais**:
`/opt/elasticbeanstalk/tasks/taillogs.d/`
+ **Logs em pacote**:
`/opt/elasticbeanstalk/tasks/bundlelogs.d/`
+ **Logs alternados**:
`/opt/elasticbeanstalk/tasks/publishlogs.d/`
**No Windows Server:**
+ **Logs finais**:
`c:\Program Files\Amazon\ElasticBeanstalk\config\taillogs.d\`
+ **Logs em pacote**:
`c:\Program Files\Amazon\ElasticBeanstalk\config\bundlelogs.d\`
+ **Logs alternados**:
`c:\Program Files\Amazon\ElasticBeanstalk\config\publogs.d\`
Por exemplo, o arquivo `eb-activity.conf` no Linux adiciona dois arquivos de log à tarefa de logs finais.
**`/opt/elasticbeanstalk/tasks/taillogs.d/eb-activity.conf `**
```
/var/log/eb-commandprocessor.log
/var/log/eb-activity.log
```
Você pode usar arquivos de configuração do ambiente (`[.ebextensions](ebextensions.md)`) para adicionar seus próprios arquivos `.conf` a essas pastas. Um arquivo `.conf` lista os arquivos de log específicos para a aplicação, que o Elastic Beanstalk adiciona às tarefas de arquivo de log.
Use a seção `files` para adicionar os arquivos de configuração às tarefas que você deseja modificar. Por exemplo, o texto de configuração a seguir adiciona um arquivo de configuração de log a cada instância em seu ambiente: Este arquivo de configuração de log, `cloud-init.conf`, adiciona `/var/log/cloud-init.log` a logs finais.
```
files:
"/opt/elasticbeanstalk/tasks/taillogs.d/cloud-init.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/log/cloud-init.log
```
Adicione esse texto a um arquivo com a extensão de nome de arquivo `.config` em seu pacote de origem em uma pasta chamada `.ebextensions`.
```
~/workspace/my-app
|-- .ebextensions
| `-- tail-logs.config
|-- index.php
`-- styles.css
```
Em plataformas Linux, você também pode usar caracteres curinga em configurações de tarefas de log. Este arquivo de configuração adiciona todos os arquivos com a extensão de nome de arquivo `.log` da pasta `log` na raiz do aplicativo aos logs em pacote.
```
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/applogs.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/app/current/log/*.log
```
As configurações de tarefas de log não oferecem suporte a caracteres curinga em plataformas Windows.
**nota**
Para ajudar a se familiarizar com os procedimentos de personalização de log, é possível implantar uma aplicação de exemplo usando a [CLI do EB](eb-cli3.md). Para isso, a CLI do EB cria um diretório de aplicação local que contém um subdiretório `.ebextentions` com uma configuração de exemplo. Também é possível usar os arquivos de log da aplicação de exemplo para explorar o recurso de recuperação de log descrito neste tópico.
Para obter mais informações sobre o uso de arquivos de configuração, consulte [Personalização avançada de ambiente com arquivos de configuração (`.ebextensions`)](ebextensions.md).
Assim como é possível estender logs finais e logs de pacote, você pode estender a rotação de log usando um arquivo de configuração. Sempre que o Elastic Beanstalk alterna seus próprios logs e os envia para o Amazon S3, ele também alterna e faz upload de seus logs adicionais. A extensão de rotação de log se comporta de forma diferente dependendo da plataforma do sistema operacional. As seções a seguir descrevem os dois casos.
### Extensão de rotação de log no Linux
Conforme explicado em [Configurações de rotação de log no Linux](#health-logs-logrotate), o Elastic Beanstalk usa `logrotate` para alternar logs em plataformas Linux. Quando você configura os arquivos de log do seu aplicativo para a rotação de log, o aplicativo não precisa criar cópias de arquivos de log. O Elastic Beanstalk configura `logrotate` para criar uma cópia dos arquivos de log da aplicação para cada alternância. Portanto, o aplicativo deve manter os arquivos de log desbloqueados quando não estiver gravando nesses arquivos.
### Extensão da rotação de log no Windows Server
No Windows Server, quando você configura os arquivos de log do seu aplicativo para a rotação de log, o aplicativo deve girar os arquivos de log periodicamente. O Elastic Beanstalk procura arquivos com nomes iniciados pelo padrão que você configurou e seleciona-os para fazer upload para o Amazon S3. Além disso, pontos no nome de arquivo são ignorados e o Elastic Beanstalk considera o nome até o ponto como a base do nome do arquivo de log.
O Elastic Beanstalk faz upload de todas as versões de um arquivo de log base, exceto da mais recente, porque considera essa a versão do arquivo de log da aplicação ativa, que pode ser bloqueada. O aplicativo pode, portanto, manter o arquivo de log ativo bloqueado entre alternâncias.
Por exemplo: o aplicativo grava em um arquivo de log chamado `my_log.log` e você especifica esse nome no arquivo `.conf`. O aplicativo periodicamente gira o arquivo. Durante o ciclo de alternância do Elastic Beanstalk, ele localiza os seguintes arquivos na pasta do arquivo de log: `my_log.log`, `my_log.0800.log`, `my_log.0830.log`. O Elastic Beanstalk considera todos eles como versões do nome base `my_log`. O arquivo `my_log.log` tem a hora de modificação mais recente, então o Elastic Beanstalk faz upload apenas dos outros dois arquivos, `my_log.0800.log` e `my_log.0830.log`.
## Transmissão de arquivos de log para o Amazon CloudWatch Logs
[Você pode configurar seu ambiente para transmitir logs para o Amazon CloudWatch Logs no console do Elastic Beanstalk ou usando opções de configuração.](command-options.md) Com o CloudWatch Logs, cada instância em seu ambiente transmite registros para grupos de registros que você pode configurar para serem retidos por semanas ou anos, mesmo após o encerramento do ambiente.
O conjunto de logs transmitido varia por ambiente, mas sempre inclui o `eb-engine.log` e os logs de acesso do servidor de proxy nginx ou Apache executado à frente do aplicativo.
É possível configurar o streaming de logs no console do Elastic Beanstalk [durante a criação do ambiente](environments-create-wizard.md#environments-create-wizard-software) ou [em um ambiente existente](environments-cfg-logging.md#environments-cfg-logging-console). Você pode definir as seguintes opções no console: ativar/desativar o streaming de CloudWatch registros para Logs, definir o número de dias de retenção e selecionar entre as opções de ciclo de vida. No exemplo a seguir, os logs são salvos por até sete dias, mesmo quando o ambiente é encerrado.
![\[Imagem da tela das configurações de CloudWatch registros no console do Elastic Beanstalk.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/log-streaming-screen.png)
O [arquivo de configuração](ebextensions.md) a seguir permite o streaming de logs com retenção de 180 dias, mesmo se o ambiente estiver encerrado.
**Example .ebextensions/log-streaming.config**
```
option_settings:
aws:elasticbeanstalk:cloudwatch:logs:
StreamLogs: true
DeleteOnTerminate: false
RetentionInDays: 180
```
# Visualização de registros de implantação para um ambiente do Elastic Beanstalk
O Elastic Beanstalk gera um log de implantação para cada implantação em seu ambiente. O registro de implantação fornece uma visão consolidada e cronológica do que aconteceu durante a implantação, incluindo a instalação da dependência, a saída da compilação, a inicialização do aplicativo e quaisquer erros encontrados. Você pode usar os registros de implantação para diagnosticar rapidamente falhas nas implantações sem precisar usar SSH nas instâncias ou correlacionar vários arquivos de log.
Os registros de implantação são gravados em cada instância localmente. Para implantações acionadas por meio do console, CLI, API ou atualizações gerenciadas, uma instância carrega continuamente seu log no Amazon S3 durante a implantação. O console do Elastic Beanstalk lê o log do Amazon S3, para que você possa monitorar o progresso sem se conectar à instância.
Os registros de implantação foram projetados para serem concisos. Em caso de sucesso, o registro mostra somente mensagens resumidas (por exemplo, quais comandos foram executados e concluídos). Em caso de falha, o registro inclui até 50 linhas de saída da etapa com falha, para que você possa ver o erro sem examinar a saída detalhada.
**nota**
Os registros de implantação estão disponíveis nas versões das plataformas [Amazon Linux 2](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2.html) [e Amazon Linux 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html) lançadas em ou após 11 de março de 2026. Atualmente, não há suporte para plataformas Windows.
## Operações compatíveis
Os registros de implantação são gerados para as seguintes operações:
+ **Implantações de aplicativos** — Implantação de uma nova versão do aplicativo em seu ambiente.
+ **Atualizações de configuração** — Alteração das configurações do ambiente que exigem atualizações de instância.
+ **Criação de ambiente** — A implantação inicial quando você cria um novo ambiente.
+ **Reinicie o servidor do aplicativo** — Reinicie o servidor do aplicativo em suas instâncias.
As operações que não modificam o estado do aplicativo ou da configuração nas instâncias, como solicitação de registros, troca ou atualização de tags CNAMEs, não geram registros de implantação.
## Conteúdo do log de implantação
Um registro de implantação captura as seguintes informações durante uma implantação:
+ **Ciclo de vida da implantação** — mensagens de início e conclusão para cada fase de implantação, como e. `Starting Application deployment` `Completed Application deployment`
+ **Saída.ebextensions** — Em caso de sucesso, os nomes dos comandos executados. Em caso de falha, as últimas 50 linhas de `cfn-init` saída para ajudar a diagnosticar o problema.
+ **Saída de ganchos de plataforma** — Em caso de sucesso, os nomes dos scripts de ganchos executados. Em caso de falha, as últimas 50 linhas de saída do gancho.
+ **Instalação de dependência** — Saída de gerenciadores de pacotes como **npm install****pip install**,**composer install**, e. **bundle install** Em caso de sucesso, somente uma mensagem de conclusão é registrada. Em caso de falha, as últimas 50 linhas de saída são incluídas.
+ **Saída de compilação** — Saída de comandos de compilação**docker build**, como**go build**, e compilações Java. Em caso de falha, as últimas 50 linhas de saída são incluídas.
+ **Saída de inicialização do aplicativo** — Saída inicial do seu aplicativo após sua inicialização. A fonte depende da sua plataforma:
+ *Docker* — registros de contêineres de ou **docker logs** **docker compose logs**
+ *Java SE, Go, Node.js, Python, Ruby, .NET* — registros de stdout de processos
+ *Tomcat — Saída* de log Catalina
+ *PHP* — registros de erros do master e do pool do PHP-FPM
+ *ECS* — registros de contêiner de cada contêiner de tarefas
**nota**
A saída do aplicativo é capturada a partir de 2 segundos após o início do aplicativo. Somente as mensagens iniciais de inicialização são incluídas — se seu aplicativo demorar mais para produzir a saída, ele não aparecerá no registro de implantação. Para ver os registros completos do aplicativo, solicite os registros do pacote ou conecte-se diretamente à instância. Para obter mais informações, consulte [Visualizar logs da instância](using-features.logging.md).
Quando uma etapa de implantação falha, o registro a marca com `[ERROR]` e inclui até 50 linhas de saída da etapa com falha. Se o registro de implantação não contiver detalhes suficientes, você poderá recuperar os registros completos da instância (`eb-engine.log`incluindo `eb-hooks.log` registros de aplicativos e) na guia **Registros**. Para obter mais informações, consulte [Visualizar logs de instâncias do Amazon EC2 no ambiente do Elastic Beanstalk](using-features.logging.md).
## Visualizando registros de implantação no console
O console do Elastic Beanstalk **fornece** uma guia Implantações no painel do ambiente, onde você pode visualizar seu histórico e registros de implantação.
### Visualizando o histórico de implantação
**Para ver o histórico de implantação**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel do ambiente, escolha a guia **Implantações.**
A guia Implantações mostra uma tabela de implantações para o ambiente. Cada linha inclui as seguintes informações:
+ **ID da solicitação** — O identificador exclusivo da implantação.
+ **Status** — *Bem-sucedido*, *falhado* ou *em andamento*.
+ **Tipo** — O tipo de implantação, como *criação de ambiente*, *implantação de aplicativo*, atualização de *configuração, atualização* de *plataforma gerenciada*, *reinicialização do servidor de aplicativos*, ambiente de *reconstrução, ambiente* de *restauração, domínio do ambiente* *de troca ou ambiente* de *encerramento*.
+ **Hora de início** — Quando a implantação começou.
+ **Duração** — Quanto tempo a implantação levou para ser concluída.
Quando uma implantação está em andamento, a guia pesquisa automaticamente as atualizações. Você também pode escolher o botão de atualização para recarregar manualmente a lista.
### Visualizando detalhes e registros de implantação
**Para ver os detalhes da implantação**
1. Na guia **Implantações**, escolha o link **ID da solicitação** para a implantação que você deseja inspecionar.
1. A página de detalhes da implantação mostra uma seção resumida com o ID da solicitação, o status, o tipo de implantação, a hora de início, a duração e a política de implantação. A política de implantação (por exemplo, *All at once*, *Rolling*, *Rolling with additional batch*, *Imutable* ou *Traffic splitting*) é exibida quando pode ser determinada a partir dos eventos de implantação.
1. Abaixo do resumo, escolha uma das seguintes guias:
+ **Eventos** — Uma linha do tempo de eventos relacionados a essa implantação, filtrada para mostrar somente os eventos da implantação selecionada.
+ **Registros de implantação** — O registro consolidado de implantação da instância. Você pode pesquisar, filtrar por nível de log e baixar o arquivo de log.
Para implantações em andamento, a guia de registros é atualizada automaticamente para mostrar novas entradas de registro à medida que elas são gravadas. Após a conclusão da implantação, o console busca o estado final do log para garantir que você veja a saída completa.
**Importante**
A visualização dos registros de implantação no console requer `s3:GetObject` permissão no bucket de armazenamento Amazon S3 do ambiente ()`elasticbeanstalk-region-account-id`. Se sua política do IAM não incluir essa permissão, o histórico de implantação e os eventos ainda estarão disponíveis, mas a guia de registros mostrará um erro.
## Arquivos de log de implantação em instâncias
Os registros de implantação são gravados no `/var/log/deployments/` diretório de cada instância. O nome do arquivo de log depende de como a implantação foi acionada:
+ **Implantações controladas por fluxo de trabalho** (acionadas por meio do console, CLI ou API) —`eb-deployment-request-id.log`, onde *request-id* está o ID exclusivo da solicitação de implantação.
+ **Implantações de inicialização automática** (inicialização da instância ou reinicialização do servidor do aplicativo) —. `eb-deployment-unix-timestamp.log`
O Elastic Beanstalk faz a rotação automática desses arquivos, mantendo os 50 registros de implantação mais recentes em cada instância.
Para implantações controladas por fluxo de trabalho, o log é carregado no Amazon S3 no seguinte caminho:
```
s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/log-filename
```
Em ambientes de várias instâncias, a primeira instância a começar o upload reivindica a função de toda a implantação. Essa instância carrega seu log no Amazon S3 durante a implantação. Todas as instâncias ainda gravam registros de implantação localmente.
**Importante**
O upload de registros de implantação para o Amazon S3 `s3:PutObject` requer permissão no bucket de armazenamento Amazon S3 do ambiente no perfil da instância, e a configuração da VPC deve permitir a conectividade com o Amazon S3.
Os uploads de registros de implantação são limitados a 1 MB por arquivo. Se um registro de implantação exceder esse tamanho, a versão carregada será truncada com uma mensagem indicando que o registro completo está disponível na instância.
### Desativando os uploads de registros do S3
Para evitar que os registros de implantação sejam enviados para o Amazon S3, defina a seguinte propriedade de ambiente em seu ambiente:
```
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: EB_DEPLOYMENT_LOG_S3_DISABLED
value: true
```
Quando essa propriedade de ambiente é definida, os registros de implantação ainda são gravados localmente `/var/log/deployments/` em cada instância, mas não são enviados para o Amazon S3 e não estarão disponíveis na guia **Implantações** do console. Você também pode definir essa propriedade na página **Configuração**, em **Software**, ou usando a CLI do EB ou. AWS CLI