Esta página foi traduzida pela API Cloud Translation.

503 Serviço indisponível - NoActiveTargets - HealthCheckFailures

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Vídeos

Assista aos vídeos a seguir para mais informações sobre erros 503:

Vídeo	Descrição
Solucionar e resolver 503 Serviço indisponível - NoActiveTargets	Saiba mais sobre o seguinte: Importância dos servidores-alvo e monitores de saúde Solução de problemas e resolução em tempo real de um serviço 503 indisponível - NoActiveTargets erro causado por uma falha na verificação de integridade

Sintoma

O aplicativo cliente recebe o código de status de resposta HTTP 503 com a a mensagem Service Unavailable e o código de erro NoActiveTargets para as solicitações do proxy de API.

Mensagem de erro

Você verá a seguinte resposta de erro:

HTTP/1.1 503 Service Unavailable

A seguinte mensagem de erro será exibida na resposta HTTP:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}

Causas possíveis

A resposta HTTP 503 Service Unavailable com o código de erro NoActiveTargets normalmente é observada quando você usa um ou mais servidores na configuração do endpoint de destino no proxy de API.

Este playbook aborda 503 Serviço indisponível com o código do erro NoActiveTargets causado por falhas na verificação de integridade. Consulte este manual para saber mais sobre outras causas desse erro.

Falhas na verificação de integridade

As falhas na verificação de integridade só serão observadas se você tiver configurado um Monitor de integridade como parte da configuração de balanceamento de carga do servidor de destino no endpoint de destino do proxy de API.

Quando um servidor de destino falha em uma verificação de integridade, o Edge aumenta a contagem de falhas desse servidor. Se o número de falhas na verificação de integridade desse servidor atingir o limite predefinido (<MaxFailures>), O processador de mensagens registra a mensagem de aviso no arquivo de registro conforme mostrado abaixo:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

A mensagem de aviso fornece as informações a seguir. Isso ajuda você a entender qual servidor de destino alcançou a contagem de MaxFailure:

Nome do servidor de destino
Nomes de organização e ambiente
Nome do proxy da API
Nome do endpoint de destino

Depois disso, o Edge para de enviar outras solicitações a esse servidor específico. Depois que todas as listas de servidores configurados na configuração do LoadBalancer alcancem a contagem de MaxFailure, As solicitações de API são respondidas com o erro 503 Service Unavailable (Serviço indisponível) com o código de erro NoActiveTargets.

O uso do monitoramento de integridade ajuda o Apigee Edge a incluir automaticamente um servidor de destino de volta ao quando ele se tornar íntegro, sem precisar reimplantar o proxy de API.

Estas são as possíveis causas de falhas na verificação de integridade:

Causa	Descrição	Quem pode realizar as etapas de solução de problemas
Erro de tempo limite de conexão	O processador de mensagens não consegue se conectar ao servidor de destino dentro do tempo limite especificado na configuração do LoadBalancer.	Usuários da nuvem privada de borda
Solicitação segura em porta não segura	Se o servidor de destino estiver definido como seguro, mas configurado incorretamente com uma porta não segura. Se o servidor de destino estiver definido como seguro, mas o monitor de integridade estiver configurada para executar verificações de integridade em uma porta não segura.	Usuários da nuvem privada de borda
Solicitação não segura na porta segura	Se o servidor de destino estiver definido como não seguro, mas configurado incorretamente com uma porta segura. Se o servidor de destino estiver definido como não seguro, mas o monitor de integridade estiver configurada para executar verificações de integridade em uma porta segura.	Usuários da nuvem privada de borda
A API Health Check responde com um erro	Se a API de verificação de integridade responder com um erro ou código de resposta, qualquer coisa especificada no elemento SuccessResponse do Monitor de integridade.	Usuários da nuvem privada de borda

Etapas comuns do diagnóstico

Determinar o ID da mensagem da solicitação com falha

Ferramenta Trace

Para determinar o ID da mensagem da solicitação com falha usando a ferramenta Trace:

Ative a sessão de trace, Faça a chamada de API e reproduza o problema: 503 Service Unavailable (Serviço 503 indisponível) com o código de erro NoActiveTargets.
Selecione uma das solicitações com falha.
Navegue até a fase AX e determine o ID da mensagem (X-Apigee.Message-ID) da solicitação, rolando para baixo na seção Phase Details, como mostra a figura a seguir.

Registros de acesso do NGINX

Para determinar o ID da mensagem da solicitação com falha usando os registros de acesso do NGINX:

Também é possível consultar os registros de acesso do NGINX para determinar o ID da mensagem para os erros 503. Isso será útil principalmente se o problema tiver ocorrido no passado ou se for intermitente e você não consegue capturar o rastro na interface. Siga as etapas a seguir para determinar essas informações dos registros de acesso do NGINX:

Verifique os registros de acesso do NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Pesquise se há erros 503 para o proxy de API específico durante um período específico (se o problema aconteceu no passado) ou se alguma solicitação ainda falha com 503.
Se houver erros 503 com X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, anote o ID da mensagem para uma ou mais dessas solicitações, conforme mostrado no exemplo a seguir:
Exemplo de entrada mostrando o erro 503

Mensagens de erro comuns

Quando servidores de destino são usados e um erro ocorre enquanto o processador de mensagens está tentando conectar ao servidor de back-end, você verá algumas mensagens de erro comuns na Registros do processador de mensagens. Esses erros são registrados após a mensagem de exceção/erro real. que levou à falha.

As mensagens de erro comuns observadas nos registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para o 503 Service Unavailable com o código de erro NoActiveTargets são os seguintes:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

Essas mensagens de erro indicam que a solicitação não pôde ser enviada para o servidor de back-end devido a um erro falha. Como resultado, o processador de mensagens envia a mensagem 503 Service Unavailable (Serviço 503 indisponível). com o código de erro NoActiveTargets como resposta ao cliente.

Causa: tempo limite da conexão

Diagnóstico

Determine o ID da mensagem da solicitação com falha.
Pesquise o ID da mensagem no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Aparecerá mensagens de erro comuns correspondentes ao ID da mensagem. No entanto, Para descobrir a causa real das falhas na verificação de integridade, role a tela acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.
Por exemplo, a mensagem de erro HEALTH MONITOR a seguir indica que o processador de mensagens falhou com erro de tempo limite de conexão ao fazer a solicitação de API de verificação de integridade:
```
Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
java.net.ConnectException: Connection timed out (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
…<snipped>
        
```
Se esse erro se repetir por MaxFailure de vezes configuradas no Monitor de Saúde, você verá uma mensagem de aviso como esta:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
        
```
Leia as informações fornecidas na mensagem de aviso com atenção. Confira se MaxFailure tenha sido atingida para um servidor de destino usado no proxy de API específico para o qual você está receber o código de resposta 503 com o código de erro NoActiveTargets.
No exemplo acima, a verificação de integridade falhou com o erro connection timed out. Verifique se você consegue se conectar ao servidor de back-end específico diretamente de cada um dos Processadores de mensagens que usam o comando telnet:

telnet <BackendServer-HostName> 443

Se você conseguir se conectar ao servidor de back-end, talvez veja uma mensagem como Conectado ao backend-server. Então o problema pode ser um problema temporário e ele pode ter sido resolvido ou for um problema intermitente. Repita a etapa 4 algumas vezes (mais de 10 vezes) e verifique o resultado.

Se não houver erros com o comando telnet de forma consistente, o problema é resolvido. Verifique novamente se as falhas da verificação de integridade pararam. Em caso afirmativo, você não precisa fazer mais alguma coisa.
Se não for possível se conectar ao servidor de back-end com o comando telnet de maneira intermitente, pode haver um problema de rede ou o servidor de back-end pode estar ocupado.

Se você não conseguir se conectar ao servidor de back-end com o comando telnet de forma consistente, isso pode ter acontecido porque o tráfego não é permitido dos processadores de mensagens no servidor de back-end específico.

Resolução

Se o erro connection timed out for observado de forma consistente, verifique se o back-end não tem restrições de firewall e permite o tráfego dos processadores de mensagens do Apigee Edge. Por exemplo, no Linux, você pode usar iptables para permitir o tráfego do endereços IP do processador de mensagens no servidor de back-end.

Se o problema persistir, trabalhe com o administrador da rede para determinar e corrigir o problema. Se precisar de mais ajuda da Apigee, entre em contato com o suporte da Apigee.

Causa: solicitação segura em porta não segura

Diagnóstico

Determine o ID da mensagem da solicitação com falha.
Pesquise o ID da mensagem no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Serão exibidas as mensagens de erro comuns correspondentes ao ID da mensagem. No entanto, para descobrir a causa real das falhas na verificação de integridade, role a tela acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.

Por exemplo, você pode ver um erro HEALTH MONITOR como mostrado abaixo:

Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
        at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
        at sun.security.ssl.InputRecord.read(InputRecord.java:527)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
…<snipped>

Se esse erro se repetir pelo MaxFailure número de vezes configurado no Monitor de Saúde, você verá uma mensagem de aviso como esta:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

Leia as informações fornecidas na mensagem de aviso com atenção. Confira se MaxFailure tenha sido atingida para um servidor de destino usado no proxy de API específico para o qual você está receber o código de resposta 503 com o código de erro NoActiveTargets.

A verificação de integridade falhou com o erro:
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
A mensagem de erro e o URL indicam a causa desse problema chamada segura (HTTPS) foi feita na porta não segura 80.

Esse erro pode ocorrer nestes dois cenários:
- Servidor de destino seguro definido com porta não segura
- Servidor de destino seguro definido, mas o Monitor de integridade configurado com uma porta não segura
Porta de destino não segura segura

Cenário 1: servidor de destino seguro definido com porta não segura

Se você tiver definido um servidor de destino seguro, mas com uma porta não segura como a 80, receberá esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:
1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.
2. Agora, verifique a configuração do Monitor de integridade do servidor de destino na configuração do endpoint de destino:
  Configuração do Monitor de integridade
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
          
```
  Não há um elemento <Port> especificado no Configuração do Monitor de Saúde acima. Nesse caso, o processador de mensagens do Edge usa a porta especificado na definição do servidor de destino (80) para fazer chamadas de API de verificação de integridade.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor seguro (conforme o bloco SSLInfo está ativado), mas com uma porta 80 não segura.
Porta HM não segura de destino seguro

Cenário 2: servidor de destino seguro definido, mas o Monitor de integridade configurado com uma porta não segura

Se você tiver definido um servidor de destino seguro, mas o Monitor de Saúde estiver configurado com um porta não segura como 80, você receberá esse erro. Siga as etapas abaixo para verificar se essa for a causa do problema:
1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.
  Use o Acesse a API TargetServer para receber a definição do servidor de destino.
  
  Saída da definição do servidor de destino
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
        
```
  No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor seguro, conforme indicado pelo bloco SSLInfo.
2. Em seguida, verifique a configuração do Monitor de integridade do servidor de destino na configuração do endpoint de destino:
  Configuração do Monitor de integridade
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>80</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
        
```
  No exemplo acima, o Monitor de integridade é configurado com uma porta 80 não segura, conforme indicado pelo elemento <Port>.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino foi definido como um servidor seguro (conforme o bloco SSLInfo está ativado) e usa a porta segura 443, mas o Health Monitor está configurado para executar verificações de integridade com uma porta não segura 80 (especificada no elemento <Port>).
  Ou seja, neste caso, o Edge transforma as APIs de verificação de integridade como uma chamada segura com na porta 80 e ocorre uma falha com o erro mencionado acima.
  
  Observação:o elemento <Port> configurado no Monitor de Saúde tem precedência sobre a porta usada na definição do servidor de destino.

Resolução

Porta de destino não segura segura

Cenário 1: servidor de destino seguro definido com porta não segura

Para corrigir esse erro, atualize a definição do servidor de destino para usar uma porta segura adequada.

Use o Atualize uma API TargetServer para atualizar a definição do servidor de destino e garantir que Uma porta segura (por exemplo, 443) é usada conforme mostrado no exemplo abaixo:

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>

Porta HM não segura de destino seguro

Cenário 2: servidor de destino seguro definido, mas o Monitor de integridade configurado com uma porta não segura

Para corrigir esse erro, siga as instruções abaixo:

Modifique a configuração do Monitor de Saúde para usar uma porta segura (por exemplo: 443) para executar verificações de integridade do servidor na configuração do endpoint de destino do proxy de API com falha, conforme mostrado abaixo:

<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
    <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

Salve as mudanças no proxy de API.

Causa: solicitação não segura em uma porta segura

Diagnóstico

Determine o ID da mensagem da solicitação com falha.
Pesquise o ID da mensagem no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Aparecerá mensagens de erro comuns correspondentes ao ID da mensagem. No entanto, para descobrir a causa real das falhas na verificação de integridade, role a tela acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.

Por exemplo, você pode ver um erro HEALTH MONITOR como mostrado abaixo:

Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
…<snipped>

Se esse erro se repetir pelo MaxFailure número de vezes configurado no Monitor de Saúde, você verá uma mensagem de aviso como esta:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}

A verificação de integridade falhou com o erro:
```
Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
      
```
A mensagem de erro e o URL indicam a causa desse problema chamada não segura (HTTP) foi feita na porta segura 443.

Esse erro pode ocorrer nestes dois cenários:
- Servidor de destino não seguro definido com porta segura
- Servidor de destino não seguro definido, mas o Monitor de integridade configurado com uma porta segura
Porta segura de destino não segura

Cenário 1: servidor de destino não seguro definido com porta segura

Se você definiu um servidor de destino não seguro, mas com uma porta segura como a 443, você vai receber esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:
1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.
  Use o Acesse a API TargetServer para receber a definição do servidor de destino.
  
  Saída da definição do servidor de destino
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              
```
  No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor não seguro porque não há nenhum bloco SSLInfo. No entanto, está incorretamente configurados com uma porta 443 segura.
2. Agora, verifique a configuração do Monitor de integridade do servidor de destino na configuração do endpoint de destino:
  Configuração do Monitor de integridade
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
                
```
  Não há um elemento <Port> especificado no Monitor de Saúde. acima. Nesse caso, o processador de mensagens do Edge usará a porta especificada no a definição do servidor de destino, que é 443.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino foi definido como um servidor não seguro (conforme o bloco SSLInfo não está definido), mas com uma porta 443 segura.
  Ou seja, o Edge faz as verificações de integridade como uma chamada não segura com a porta segura 443 e falha pelo erro mencionado acima.
Porta HM segura de destino não seguro

Cenário 2: servidor de destino não seguro definido, mas o Monitor de integridade configurado com uma porta segura

Se você definiu um servidor de destino não seguro, mas o Monitor de Saúde está configurado com uma porta segura, como a 443, você vai receber esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:
1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.
  Use o Acesse a API TargetServer para receber a definição do servidor de destino.
  
  Saída da definição do servidor de destino
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
        
```
  No exemplo acima, a definição mostra que o servidor de destino mocktarget não é seguro servidor (já que não há um bloco SSLInfo) configurado com uma porta 80 não segura corretamente.
2. Em seguida, verifique a configuração do Monitor de integridade do servidor de destino na configuração do endpoint de destino:
  Configuração do Monitor de integridade
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
      
```
  No exemplo acima, o Monitor é configurado com uma porta segura 443, conforme indicado pelo elemento <Port>.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino é definido como um servidor não seguro (conforme o bloco SSLInfo não está definido) com a porta 80 não segura corretamente; mas o Monitor está configurado para executar verificações de integridade com uma porta segura 443 (especificada no elemento <Port>).
  Ou seja, nesse caso, o Edge faz as verificações de integridade como uma chamada não segura com a porta segura 443 e falha com o erro mencionado acima.

Resolução

Porta segura de destino não segura

Cenário 1: servidor de destino não seguro definido com porta segura

Para corrigir esse erro, atualize a definição do servidor de destino para usar uma porta segura adequada.

Use o Atualizar uma API do servidor de destino para atualizar a definição do servidor de destino e garantir que uma porta não segura (por exemplo, 80) é usada como mostrado no exemplo abaixo:

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

Porta HM segura de destino não seguro

Cenário 2: servidor de destino não seguro definido, mas o Monitor de integridade configurado com uma porta segura

Para corrigir esse erro, siga as instruções abaixo:

Remova o elemento <Port> da configuração do Monitor de Saúde ou modifique a configuração do Monitor de Saúde para usar uma porta não segura (por exemplo: 80) para realizar verificações de integridade do servidor de destino na configuração do endpoint de destino do proxy de API com falha, conforme mostrado abaixo:

<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>80</Port>
      <Verb>GET</Verb>
      <Path>/statuscode/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

Salve as mudanças no proxy de API.

Causa: a API de verificação de integridade responde com um erro

Diagnóstico

Determine o ID da mensagem da solicitação com falha.
Pesquise o ID da mensagem no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Serão exibidas as mensagens de erro comuns correspondentes ao ID da mensagem. No entanto, para descobrir a causa real das falhas na verificação de integridade, role a tela acima dessas mensagens de erro comuns e verifique se há erros/avisos do HEALTH MONITOR.
Por exemplo, você pode receber um aviso do HEALTH MONITOR conforme mostrado abaixo:
```
Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
        
```
Se esse erro se repetir pelo MaxFailure número de vezes configurado no Monitor de Saúde, você verá uma mensagem de aviso como esta:
```
Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
        
```
Leia as informações fornecidas na mensagem de aviso com atenção. Confira se MaxFailure tenha sido atingida para um servidor de destino usado no proxy de API específico para o qual você está receber o código de resposta 503 com o código de erro NoActiveTargets.
A verificação de integridade retornou a mensagem de aviso:
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
A mensagem de aviso acima informa que o código de resposta esperado para a API de verificação de integridade era 200. mas a resposta real recebida é 404. Portanto, isso é tratado como uma falha.
Antes de investigar a causa da resposta de erro da API de verificação de integridade, determine por que o Edge espera que o código de resposta seja 200 para a API de verificação de integridade. Para isso, verifique o Monitor de Saúde para o servidor de destino na configuração do endpoint de destino:
Configuração do Monitor de integridade
```
<HealthMonitor>
  <IsEnabled>true</IsEnabled>
  <IntervalInSec>5</IntervalInSec>
  <HTTPMonitor>
    <Request>
      <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
   	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
      <Port>443</Port>
      <Verb>GET</Verb>
      <Path>/status/200</Path>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>
        
```
A configuração do Monitor de Saúde é definida com o código de resposta 200 no elemento <SuccessResponse>. Isso significa que, se o Edge receber um código de resposta (como 400, 401, 404, 500) diferente do 200 da API de verificação de integridade, isso será tratado como um erro e aumentará a contagem de falhas.
Agora, para investigar a causa da resposta de erro da API de verificação de integridade, siga as etapas abaixo:

Observe a mensagem anterior à mensagem de aviso no registro do Processador de mensagens.

Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

Anote o URL de verificação de integridade dessa mensagem.

Você pode fazer uma chamada direta para esse URL a partir do processador de mensagens e verificar a resposta real
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
A resposta da chamada acima gera um erro 404, como visto nos registros do processador de mensagens:
```
< HTTP/2 404
          
```
Isso mostra que mesmo a chamada direta ao URL de verificação de integridade falha com o mesmo código de resposta 404. Isso significa que o URL de verificação de integridade pode estar incorreto ou que o recurso acessado como parte do URL não está mais disponível.
No exemplo de API de verificação de integridade fornecida acima, o problema ocorre porque um URL incorreto foi usado na configuração do Monitor. O URL correto é https://mocktarget.apigee.net:443/statuscode/200 de API de destino simulado.

Se você receber outra resposta de erro, determine a causa dela seguindo o etapas acima. Se necessário, trabalhe com sua equipe de back-end.

Resolução

Corrija o problema com a API de verificação de integridade no servidor de back-end.
Para corrigir o problema no exemplo discutido acima:

Modifique o elemento <Path> na configuração do Monitor de Saúde para /statuscode/200, conforme mostrado abaixo:
```
<Path>/statuscode/200</Path>
        
```
Salve as alterações no proxy da API.

Se o problema persistir, acesse É necessário coletar informações de diagnóstico.

Diagnosticar problemas usando o monitoramento de APIs

O API Monitoring permite isolar o problema áreas para diagnosticar rapidamente problemas de erro, desempenho e latência e suas origens, como problemas apps, proxies de API, destinos de back-end ou a plataforma de API.

Veja um exemplo de cenário que demonstra como resolver problemas 5xx com suas APIs usando a API Monitoring. Por exemplo: defina um alerta para ser notificado quando a quantidade de messaging.adaptors.http.flow.NoActiveTargets em excesso excedem um determinado limite.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações: informações de diagnóstico. Entre em contato com eles e compartilhe com o suporte da Apigee:

Se você é usuário da nuvem pública, forneça as seguintes informações:

Nome da organização
Nome do ambiente
Nome do proxy da API
Complete o comando curl para reproduzir o erro
Arquivo de rastreamento contendo as solicitações com o status 503 Serviço Indisponível com o código de erro NoActiveTargets

Se você é usuário da nuvem privada, forneça as seguintes informações:
1. Mensagem de erro completa observada
2. Nome do ambiente
3. Pacote de proxy de API
4. Arquivo de rastreamento contendo as solicitações com o status 503 Serviço Indisponível com o código de erro NoActiveTargets
5. Registros de acesso do NGINX
  (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)
6. Registros do processador de mensagens
  (/opt/apigee/var/log/edge-message-processor/logs/system.log)