O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

503 Serviço indisponível - NoActiveTargets - HealthCheckFailures

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Vídeos

Confira os vídeos a seguir para mais informações sobre erros 503:

Vídeo	Descrição
Resolver problemas e corrigir o erro 503 "Serviço indisponível" - NoActiveTargets	Saiba mais sobre: Importância dos servidores de destino e dos monitores de integridade Solução de problemas e resolução de um erro 503 em tempo real "Service Unavailable - NoActiveTargets" causado por falha na verificação de integridade

Sintoma

O aplicativo cliente recebe o código de status da resposta HTTP 503 com a mensagem Serviço indisponível e o código de erro NoActiveTargets para as solicitações de proxy de API.

Mensagem de erro

Você vai receber a seguinte resposta de erro:

HTTP/1.1 503 Service Unavailable

Você vai ver a seguinte mensagem de erro 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 geralmente é observada quando você usa um ou mais servidores de destino na configuração do endpoint de destino no proxy de API.

Este playbook aborda o erro 503: serviço indisponível com o código 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 de verificação de integridade serão observadas apenas 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 do servidor. Se o número de falhas na verificação de integridade desse servidor atingir o limite predefinido (<MaxFailures>), o processador de mensagens vai registrar a mensagem de aviso, conforme mostrado abaixo, no arquivo de registro:

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 alerta fornece as seguintes informações: Isso ajuda a entender qual servidor de destino atingiu a contagem de MaxFailure:

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

Depois disso, o Edge para de enviar outras solicitações para esse servidor específico. Quando todos os servidores de destino configurados no LoadBalancer atingirem a contagem de MaxFailure, as solicitações de API subsequentes serão respondidas com 503 Service Unavailable e o código de erro NoActiveTargets.

O uso do Health Monitor ajuda o Apigee Edge a incluir automaticamente um servidor de destino de volta na rotação quando ele fica íntegro, sem precisar reimplantar o proxy de API.

Confira as possíveis causas das falhas na verificação de integridade:

Causa	Descrição	Quem pode executar 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 período de tempo limite especificado na configuração do LoadBalancer.	Usuários da nuvem privada do Edge
Solicitação segura em uma porta não segura	Se o servidor de destino estiver definido como um servidor seguro, mas configurado incorretamente com uma porta não segura. Se o servidor de destino estiver definido como um servidor seguro, mas o monitor de integridade estiver configurado para realizar verificações de integridade em uma porta não segura.	Usuários da nuvem privada do Edge
Solicitação não segura em uma 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 for definido como não seguro, mas o monitor de integridade estiver configurado para realizar verificações de integridade em uma porta segura.	Usuários da nuvem privada do Edge
A API Health Check responde com um erro	Se a API de verificação de integridade responder com um erro ou um código de resposta diferente do especificado no elemento "SuccessResponse" do monitor de integridade.	Usuários da nuvem privada do Edge

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 rastreamento, faça a chamada de API e reproduza o problema: 503 Serviço 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 Detalhes da fase, conforme mostrado na 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:

Você também pode consultar os registros de acesso do NGINX para determinar o ID da mensagem dos erros 503. Isso é especialmente útil se o problema tiver ocorrido no passado ou se ele for intermitente e você não conseguir capturar o rastreamento na interface. Siga estas etapas para determinar essas informações nos 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 ainda há solicitações falhando com 503.
Se houver erros 503 com X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, anote o ID da mensagem de uma ou mais 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 ocorre um erro enquanto o processador de mensagens tenta se conectar com o servidor de back-end, algumas mensagens de erro comuns aparecem nos 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 do erro NoActiveTargets são as 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 ao servidor de back-end devido a uma falha. Como resultado, o processador de mensagens envia 503 Service Unavailable com o código de erro NoActiveTargets como resposta ao cliente.

Causa: tempo limite de 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).
Você vai encontrar 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 para cima além dessas mensagens de erro comuns e verifique se há erros de MONITOR DE SAÚDE.
Por exemplo, a seguinte mensagem de erro do MONITOR DE INTEGRIDADE indica que o processador de mensagens falhou com um 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 MaxFailure vezes, conforme configurado no monitor de integridade, uma mensagem de aviso como esta será exibida:
```
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 com atenção as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi atingida para um servidor de destino usado no proxy de API específico em que você está recebendo 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 é possível se conectar ao servidor de back-end específico diretamente de cada um dos processadores de mensagens usando o comando telnet:

telnet <BackendServer-HostName> 443

Se você conseguir se conectar ao servidor de back-end, uma mensagem como Conectado ao servidor de back-end vai aparecer. Nesse caso, o problema pode ser temporário e pode ser resolvido ou ser intermitente. Repita a etapa 4 algumas vezes (mais de 10 vezes) e verifique a saída.

Se não houver erros com o comando telnet, o problema será resolvido. Verifique novamente se as falhas na verificação de integridade pararam. Se sim, não é preciso fazer mais nada.
Se você não conseguir se conectar ao servidor de back-end com o comando telnet de forma 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 ocorrer 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 servidor de 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 dos endereços IP do processador de mensagens no servidor de back-end.

Se o problema persistir, trabalhe com seu administrador de 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 uma 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).

Você vai encontrar 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 para cima além dessas mensagens de erro comuns e verifique se há erros de MONITOR DE INTEGRIDADE.

Por exemplo, você pode ver um erro de MONITOR DE INTEGRIDADE, 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 MaxFailure vezes, conforme configurado no monitor de integridade, você vai receber 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 com atenção as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi atingida para um servidor de destino usado no proxy de API específico em que você está recebendo 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 que o problema é causado por uma chamada segura (HTTPS) feita na porta 80 não segura.

Esse erro pode ocorrer nos seguintes cenários:
- Servidor de destino seguro definido com uma porta não segura
- Servidor de destino seguro definido, mas monitor de integridade configurado com uma porta não segura
Proteger o destino com uma porta não segura

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

Se você definiu um servidor de destino seguro, mas com uma porta não segura, como 80, esse erro vai aparecer. 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 Health Monitor
  <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 na configuração do monitor de integridade acima. Nesse caso, o processador de mensagens do Edge usa a porta especificada na definição do servidor de destino (que é 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 é definido como um servidor seguro (já que o bloco SSLInfo está ativado), mas com uma porta 80 não segura.
Proteja a porta HM não segura de destino

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

Esse erro vai aparecer se você tiver definido um servidor de destino seguro, mas o monitor de integridade estiver configurado com uma porta não segura, como 80. 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 a API Get 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 para o servidor de destino na configuração do endpoint de destino:
  Configuração do Health Monitor
  <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 está definido como um servidor seguro (já que o bloco SSLInfo está ativado) e usa a porta segura 443, mas o monitor de integridade está configurado para realizar verificações de integridade com uma porta não segura 80 (especificada no elemento <Port>).
  Ou seja, nesse caso, o Edge faz as APIs de verificação de integridade como uma chamada segura com a porta 80 não segura e falha com o erro mencionado acima.
  
  Observação:o elemento <Port> configurado no monitor de integridade tem precedência sobre a porta usada na definição do servidor de destino.

Resolução

Proteger o destino com uma porta não segura

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

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

Use a API Update a TargetServer para atualizar a definição do servidor de destino e garantir que uma porta segura (por exemplo, 443) seja 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>

Proteja a porta HM não segura de destino

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 integridade para usar uma porta segura (por exemplo, 443) e 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>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).

Por exemplo, você pode ver um erro de MONITOR DE INTEGRIDADE, 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 MaxFailure vezes, conforme configurado no monitor de integridade, você vai receber 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 que a causa do problema é que uma chamada não segura (HTTP) foi feita na porta segura 443.

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

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

Esse erro vai aparecer se você tiver definido um servidor de destino não seguro, mas com uma porta segura, como 443. 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 a API Get 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 não é seguro porque não há um bloco SSLInfo. No entanto, ele está configurado incorretamente 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 Health Monitor
  <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 na configuração do monitor de integridade acima. Nesse caso, o processador de mensagens do Edge vai usar a porta especificada na definição do servidor de destino, que é 443.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor não seguro (já que o bloco SSLInfo não está definido), mas com uma porta segura 443.
  Ou seja, 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.
Porta HM segura de destino não segura

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

Esse erro vai aparecer se você tiver definido um servidor de destino não seguro, mas o monitor de integridade estiver configurado com uma porta segura, como 443. 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 a API Get 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 é um servidor não seguro (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 para o servidor de destino na configuração do endpoint de destino:
  Configuração do Health Monitor
  <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 de integridade é configurado com uma porta 443 segura, conforme indicado pelo elemento <Port>.
3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor não seguro (já que o bloco SSLInfo não está definido) com a porta 80 não segura corretamente, mas o Health Monitor está configurado para realizar verificações de integridade com uma porta 443 segura (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 de destino segura 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 a API "Atualizar um servidor de destino" para atualizar a definição do servidor de destino e garantir que uma porta não segura (por exemplo, 80) seja usada , conforme 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 segura

Cenário 2: servidor de destino não seguro definido, mas 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 integridade ou modifique a configuração do monitor de integridade 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).
Você vai encontrar 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 para cima dessas mensagens de erro comuns e verifique se há erros/avisos do MONITOR DE INTEGRIDADE.
Por exemplo, você pode ver um aviso de MONITOR DE INTEGRIDADE, como 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 MaxFailure vezes, conforme configurado no monitor de integridade, você vai receber 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 com atenção as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi atingida para um servidor de destino usado no proxy de API específico em que você está recebendo 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 afirma que o código de resposta esperado para a API de verificação de integridade era 200, mas o código de resposta real recebido é 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 o código de resposta 200 para a API de verificação de integridade. Para isso, verifique a configuração do monitor de integridade do servidor de destino na configuração do endpoint de destino:
Configuração do Health Monitor
```
<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>
        
```
Observe que a configuração do monitor de integridade está definida com o código de resposta 200 no elemento <SuccessResponse>. Isso significa que, se o Edge receber qualquer código de resposta (como 400, 401, 404, 500) diferente de 200 da API de verificação de integridade, ele será tratado como um erro e incrementará a contagem de falhas.
Agora, para investigar a causa da resposta de erro da API de verificação de integridade, siga as etapas abaixo:

Confira a mensagem anterior à 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 da verificação de integridade dessa mensagem.

Você pode fazer uma chamada direta para esse URL no processador de mensagens e verificar a resposta real.
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
A resposta da chamada acima retorna 404, conforme mostrado nos registros do Processador de mensagens:
```
< HTTP/2 404
          
```
Isso mostra que até mesmo a chamada direta para o URL de verificação de integridade falha com o mesmo código de resposta 404. Isso significa que o URL da 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 fornecido acima, o problema ocorre porque um URL incorreto foi usado na configuração do Health Monitor. O URL correto foi https://mocktarget.apigee.net:443/statuscode/200 da API Mock Target.

Se você receber outra resposta de erro, siga as etapas acima para determinar a causa. 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 acima:

Modifique o elemento <Path> na configuração do monitor de integridade para /statuscode/200, conforme mostrado abaixo:
```
<Path>/statuscode/200</Path>
        
```
Salve as mudanças no proxy de API.

Se o problema persistir, acesse Precisa de informações de diagnóstico.

Diagnosticar problemas usando o API Monitoring

Com a API Monitoring, é possível isolar as áreas problemáticas rapidamente para diagnosticar erros, problemas de desempenho e latência e a origem deles, como aplicativos de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Confira um cenário de exemplo que demonstra como resolver problemas 5xx com suas APIs usando o API Monitoring. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de falhas de messaging.adaptors.http.flow.NoActiveTargets exceder 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 de diagnóstico. Entre em contato e compartilhe com o suporte da Apigee:

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

Nome da organização
Nome do ambiente
Nome do proxy de API
Comando curl completo para reproduzir o erro
Arquivo de rastreamento que contém as solicitações com "503 Service Unavailable" e o código de erro "NoActiveTargets".

Se você for um 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 que contém as solicitações com "503 Service Unavailable" e 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)