503 Servizio non disponibile

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X.
Informazioni

Video

Per ulteriori informazioni sugli errori 503, guarda i seguenti video:

Video Descrizione
Risolvere i problemi relativi all'errore di servizio 503 non disponibile a causa di un problema DNS Scopri di più su quanto segue:
  • Errore 503 Servizio non disponibile causato da problemi relativi alla risoluzione DNS e alla rete in Apigee Edge
  • Risoluzione di un errore in tempo reale 503 "Servizio non disponibile" causato da un problema di risoluzione DNS.
Risolvere i problemi relativi all'errore di servizio 503 non disponibile a causa di un problema di rete Risoluzione di un errore di servizio 503 non disponibile in tempo reale causato da un problema di rete in Apigee Edge

Sintomo

L'applicazione client riceve lo stato di risposta HTTP 503 con il messaggio Servizio non disponibile a seguito di una chiamata proxy API.

Messaggi di errore

Puoi visualizzare il seguente messaggio di errore:

HTTP/1.1 503 Service Unavailable
      

Puoi anche visualizzare il seguente messaggio di errore nella risposta HTTP:

Servizio non disponibile

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

Possibili cause

La risposta HTTP 503 Service Non disponibile con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable si verifica se il processore di messaggi di Apigee Edge si verificasse errori dovuti a timeout della connessione, errore nome host o errori di handshake SSL durante la comunicazione con il server di backend.

Le cause possibili della risposta 503 Service Unavailable sono:

Causa Descrizione Chi può eseguire la procedura di risoluzione dei problemi
Errori di connessione dovuti a una risoluzione DNS errata La risoluzione DNS del server di destinazione ha generato indirizzi IP errati che generano errori di connessione. Utenti Edge Private Cloud
Errori di connessione I problemi di rete o di connettività impediscono al client di connettersi al server. Utenti Edge Private Cloud
Nome host del server di destinazione non corretto L'host del server di destinazione specificato non è corretto o contiene caratteri indesiderati (ad esempio lo spazio). Utenti perimetrali di cloud pubblici e privati
Errori di handshake SSL handshake TLS/SSL non riuscito tra il client e il server. (Risoluzione dei problemi per questa classe di verrà trattato in un argomento a parte). Utenti perimetrali di cloud pubblici e privati

Passaggi diagnostici comuni

Determinare l'ID messaggio della richiesta non riuscita

Strumento Trace

Per determinare l'ID messaggio della richiesta non riuscita utilizzando lo strumento Trace:

  1. Se il problema è ancora attivo, abilita la sessione di traccia per l'API interessata.
  2. Effettua la chiamata API e riproduci il problema - 503 Servizio non disponibile con codice di errore messaging.adaptors.http.flow.ServiceUnavailable.
  3. Seleziona una delle richieste non riuscite.
  4. Vai alla fase AX e determina l'ID messaggio (X-Apigee.Message-ID) della richiesta scorrendo verso il basso nella sezione Dettagli fase come mostrato nella figura che segue.

    ID messaggio nella sezione Dettagli fase

Log di accesso NGINX

Per determinare l'ID messaggio della richiesta non riuscita utilizzando i log di accesso NGINX:

Puoi inoltre fare riferimento ai registri di accesso NGINX per determinare l'ID messaggio degli errori 503. Ciò è particolarmente utile se il problema si è verificato in passato o se il problema è intermittente e non riesci ad acquisire la traccia nell'interfaccia utente. Segui questi passaggi per determinare queste informazioni dai log di accesso di NGINX:

  1. Controlla i log di accesso NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Cerca se sono presenti errori 503 per il proxy API specifico durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono presenti richieste che non vanno ancora a buon fine con 503.
  3. Se si verificano errori 503 con X-Apigee-fault-code messages.adaptors.http.flow.ServiceUnavailable, Prendi nota dell'ID messaggio per una o più richieste di questo tipo, come mostrato nell'esempio seguente:

    Voce di esempio che mostra l'errore 503

    Voce di esempio che mostra codice di stato, ID messaggio, origine e codice di errore

Errori di connessione dovuti a una risoluzione DNS errata

Diagnosi

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio della richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti osservare i seguenti errori:

    Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout della connessione preimpostato (valore predefinito: 3 secondi).
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
    
    2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
          
  3. Prendi nota dell'indirizzo IP risolto nell'errore onConnectTimeout e controlla se l'indirizzo IP è valido per il tuo server di backend. Se l'indirizzo IP è valido, vai a Errori di connessione.
  4. Se l'indirizzo IP non è valido, molto probabilmente la causa potrebbe essere dovuta a problemi con la risoluzione del DNS.
  5. Ripeti i passaggi 3 e 4 per altre richieste API non riuscite e verifica se vedi indirizzi IP uguali o non validi.
  6. Cerca nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) i messaggi con la parola chiave DNS Refresh. Controlla se di tanto in tanto vengono aggiunti indirizzi IP non validi o non validi alla cache DNS del processore di messaggi.
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
          
  7. Questo problema può verificarsi in caso di problemi con i server DNS autorevoli o con i server dei nomi configurati in /etc/resolv.conf.
    .
    In genere, potrebbero esserci uno o più server DNS autorevoli configurati per eseguire la risoluzione DNS. Se non esistono server DNS autorevoli, si ricorrerà alla configurazione della configurazione in /etc/resolv.conf e eseguirà la risoluzione DNS in base alle esigenze. Ad esempio, se /etc/resolv.conf è configurato in modo da utilizzare server dei nomi specifici, questi verranno utilizzati per eseguire la risoluzione DNS.
  8. In caso di problemi con i server DNS o i server dei nomi autorevoli specificati in /etc/resolv.conf, i nomi host dei server di backend verranno risolti in indirizzi IP non validi o non validi. Gli indirizzi IP non validi o non validi vengono quindi archiviati nella cache DNS del processore di messaggi.
    1. Se il problema dei server DNS autorevoli o dei server dei nomi specificati in /etc/resolv.conf persiste, gli indirizzi IP non validi o non validi continueranno a rimanere nella cache DNS del processore di messaggi. Se gli indirizzi IP non validi vengono archiviati nella cache DNS del processore di messaggi, le richieste per tutte le API che utilizzano lo specifico server di backend non riusciranno e restituiranno l'errore 503.
    2. Se il problema con i server DNS autorevoli o i server dei nomi specificati in /etc/resolv.conf è intermittente, gli indirizzi IP validi e non validi verranno archiviati a intermittenza nella cache DNS. In questo caso, visualizzerai errori 503 a intermittenza per tutte quelle API che utilizzano lo specifico server di backend.
  9. Se il problema dei server DNS persiste, noterai degli errori continui. Se il problema dei server DNS è intermittente, gli errori risulteranno intermittenti. In altre parole, ogni volta che il nome host del server di backend viene risolto in indirizzi IP non validi, vengono visualizzati errori 503. E quando i nomi host dei server di backend vengono risolti su indirizzi IP validi, noterai delle risposte positive.

Risoluzione

Collabora con l'amministratore del tuo sistema operativo e risolvi i problemi con i server DNS.

  1. Se si verifica un problema con i tuoi server DNS o server dei nomi autorevoli specificati in /etc/resolv.conf, risolvilo con il server appropriato per risolverlo.
  2. In caso di problemi con la configurazione in /etc/resolv.conf sui sistemi con processori di messaggi, risolvi il problema di configurazione.

Errori di connessione

Si verifica un errore di connessione quando un processore di messaggi Apigee Edge tenta di connettersi a un backend server e si verifica uno dei seguenti problemi:

  • Il processore di messaggi non è in grado di connettersi nel periodo di timeout della connessione preimpostato. (valore predefinito: 3 secondi)
  • Il server di backend rifiuta la connessione.

Diagnosi

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio di richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti osservare i seguenti errori:
    1. Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout della connessione preimpostato.
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
      
    2. Un errore java.net.Connecteccezione: Connessione rifiutata indica che la connessione è stata rifiutata. è stata rifiutata dal server di backend.
      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
      
  3. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascun server Processori di messaggi che utilizzano il comando telnet:
    1. Se il server di backend si risolve in un singolo indirizzo IP, utilizza il seguente comando:
      telnet BackendServer-IPaddress 443
                
    2. Se il server di backend si risolve in più indirizzi IP, utilizza il nome host il server di backend nel comando telnet, come mostrato di seguito:
      telnet BackendServer-HostName 443
                
  4. Se riesci a connetterti al server di backend, potresti visualizzare un messaggio simile a Connected to backend-server. Se non riesci a connetterti al server di backend, è possibile che perché il team dei processori di messaggi Gli indirizzi IP non sono inclusi nella lista consentita sul backend specifico server web.

Risoluzione

Concedi l'accesso agli indirizzi IP del processore di messaggi sullo specifico server di backend per consentire proveniente dai processori di messaggi Edge per accedere al server di backend. Ad esempio, su Linux, puoi utilizzare iptables per consentire il traffico dagli indirizzi IP del processore di messaggi sul server di backend.

Se il problema persiste, rivolgiti all'amministratore di rete per determinare e risolvere il problema. problema. Se hai bisogno di ulteriore assistenza da parte di Apigee, contatta l'assistenza Apigee.

Nome host del server di destinazione non corretto

Diagnosi

Se il nome host specificato nel server di destinazione non è corretto, puoi ricevere la risposta 503 Servizio non disponibile con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable.

Strumento Trace

Per eseguire la diagnosi utilizzando lo strumento Trace:

  1. Se il problema è ancora attivo, abilita la sessione di traccia per l'API interessata.
  2. Effettua la chiamata API e riproduci il problema - 503 Servizio non disponibile con codice di errore messaging.adaptors.http.flow.ServiceUnavailable.
  3. Seleziona una delle richieste non riuscite.
  4. Naviga attraverso le varie fasi della traccia e individua dove si è verificato l'errore.
  5. Seleziona le FlowInfo che presentano l'errore. Nel campo error.cause potresti trovare ulteriori informazioni che possono indicare la causa dell'errore, come illustrato nell'esempio seguente:

    Richiesta di esempio che mostra error.cause nella traccia

    Richiesta di esempio che mostra error.cause nella traccia
  6. Se noti che error.cause mostra Host non raggiungibile, la causa più probabile dell'errore è una delle seguenti:
      .
    • Il nome host specificato nella configurazione del server di destinazione/dell'endpoint di destinazione non è corretto o contiene spazi o caratteri speciali indesiderati.

      Ad esempio, nel nome host è presente uno spazio indesiderato come mostrato di seguito:
      "demo-target.apigee.net "
                        
    • Il nome host sovrascritto dalla variabile target.url nel proxy API utilizzando AssignMessage o Il criterio JavaScript non è corretto o contiene uno spazio o altri caratteri speciali indesiderati.
  7. Controlla la configurazione dell'endpoint di destinazione e/o la definizione del server di destinazione per verificare se il nome host del server di destinazione non è corretto o se contiene spazi o caratteri speciali indesiderati.
  8. Se l'host del server di destinazione viene creato in modo dinamico, seleziona il criterio appropriato (ad esempio il criterio AssignMessage/JavaScript) utilizzato per crearlo. Seleziona per verifica se il nome host del server di destinazione non è corretto o se contiene spazi o caratteri speciali indesiderati.
  9. Una volta determinato il nome host del server di destinazione, esegui il comando nslookup/dig sul nome host per vedere se il problema può essere risolto.

    Ad esempio, l'esecuzione del comando nslookup sul nome host con uno spazio indesiderato restituisce il seguente output:

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
    
  10. Se anche il comando nslookup del sistema operativo non riesce a risolvere il nome host, la causa del problema è il nome host errato utilizzato per il server di destinazione.

    Vai a Risoluzione.

Log del processore di messaggi

Per eseguire la diagnostica mediante i log del processore di messaggi:

  1. Determina l'ID messaggio della richiesta non riuscita.
  2. Cerca l'ID messaggio nel log del processore di messaggi. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Se vengono visualizzati i seguenti messaggi di avviso/errore, il processore di messaggi non è riuscito a risolvere il nome host. Dal momento che il messaggio verrà posticipato, potresti non vederlo per tutti gli ID/richieste dei messaggi.
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
        
  4. Segue un messaggio di avviso in cui il processore di messaggi rimuove l'indirizzo dalla cache DNS, poiché non è stato possibile raggiungere l'host del server di destinazione.
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
        
  5. Potresti quindi visualizzare un messaggio di errore del processore di messaggi, con l'eccezione "Host non raggiungibile". A volte, nel messaggio di errore viene visualizzato il nome host:
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  6. A volte potrebbe essere visualizzato come nullo perché il nome host non può essere risolto o raggiungibile come mostrato di seguito:
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
    java.lang.RuntimeException: Host not reachable
    	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
    	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
    	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
    	…<snipped>
        
  7. L'errore Host not reachable si verifica in genere in uno dei seguenti casi:
    • Il nome host specificato nella configurazione del server di destinazione/dell'endpoint di destinazione non è corretto o contiene spazi o caratteri speciali indesiderati.

      Ad esempio, c'è uno spazio indesiderato nel nome host "demo-target.apigee.net " nel seguente messaggio di errore:
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
              
    • Il nome host sovrascritto dalla variabile target.url nel proxy API utilizzando il criterio AssignMessage o JavaScript non è corretto o contiene uno spazio o altri caratteri speciali indesiderati.
  8. Determina il nome host del server di destinazione con cui il processore di messaggi tenta di comunicare utilizzando uno dei seguenti elementi:
    1. Esamina attentamente il messaggio di errore contenente Host not reachable .
    2. Se il messaggio di errore mostra il nome host, copialo, inclusi gli spazi o i caratteri speciali.
    3. Se il messaggio di errore mostra null per il nome host, come illustrato nel seguente messaggio,
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
              
      1. Determina il nome host controllando la definizione del server di destinazione utilizzata nel proxy API che presenta errori.
      2. Se l'host del server di destinazione viene creato in modo dinamico, seleziona il criterio appropriato (ad esempio, il criterioAssignMessage/JavaScript) utilizzato per crearlo.
  9. Una volta determinato il nome host del server di destinazione, esegui il comando nslookup/dig sul nome host e controlla se il problema può essere risolto.

    Ad esempio, esegui il comando nslookup sul nome host che include uno spazio

    nslookup "demo-target.apigee.net "
    Server:	49.205.75.2
    Address:	49.205.75.2#53
    
    ** server can't find demo-target.apigee.net\032: NXDOMAIN
          
  10. Se anche il comando del sistema operativo nslookup non riesce a risolvere il nome host, la causa del problema è il nome host errato utilizzato per il server di destinazione.

Risoluzione

  1. Assicurati che il nome host del server di destinazione specificato nella configurazione dell'endpoint di destinazione o nel server di destinazione è corretta e non contiene spazi o caratteri speciali indesiderati.
  2. Se utilizzi un criterioAssignMessage/JavaScript per generare in modo dinamico il nome host del server di destinazione, esamina la definizione del criterio e il codice e assicurati che il nome host del server di destinazione sia generato correttamente.

Errori di handshake SSL

Un intero playbook per la risoluzione dei problemi è dedicato agli errori di handshake TLS/SSL. Vedi Errori di handshake SSL.

Stabilire l'origine del problema

Alcuni tipi di errori possono verificarsi nella rete in entrata (in direzione nord) o in uscita (in direzione sud) connessione. Un errore in arrivo (in direzione nord) si verifica tra l'applicazione client e Edge. Un l'errore in uscita (in direzione sud) si verifica tra Edge e il server di destinazione di backend. Per eseguire la diagnosi problemi, il primo compito è capire se l'errore si verifica nella zona nord o verso sud.

Informazioni sulle connessioni verso nord e sud

In Edge, puoi riscontrare un errore 503 Servizio non disponibile sulla connessione in entrata o in uscita:

  • In entrata (o verso nord): la connessione tra il client. e il router Edge. Il router è il componente di Apigee Edge che gestisce richieste in arrivo inviate al sistema.
  • Connessione in uscita (o verso sud): la connessione tra il perimetro il processore di messaggi e il server di backend. Il processore di messaggi è un componente di Apigee Edge che esegue il proxy delle richieste API ai server di destinazione di backend.

Se sei un utente Edge Public Cloud, probabilmente non sei a conoscenza di componenti interni come il router o il processore di messaggi. Questi componenti interni non sono visibili o accessibili a per gli utenti del cloud pubblico. Se possibile, forniamo metodi alternativi per esaminare il problema non richiedono l'accesso diretto a questi componenti.

La figura seguente illustra le connessioni verso nord e sud per Apigee perimetrali.

Flusso dell&#39;applicazione client (connessione nord) attraverso il perimetro al server di backend (connessione verso sud)

Determinazione della posizione in cui si è verificato l'errore 503 Servizio non disponibile

Utilizza una delle seguenti procedure per determinare se si è verificato l'errore 503 "Servizio non disponibile" alla connessione in direzione nord o sud.

Traccia UI

Per determinare dove si è verificato l'errore utilizzando UI Trace:

  1. Se il problema è ancora attivo, abilita la traccia UI per l'API interessata.
  2. Se la traccia UI per la richiesta API non riuscita mostra che l'errore 503 Servizio non disponibile si verifica durante il flusso di richieste target o viene inviata dal server di backend, il problema southbound (ovvero tra il processore di messaggi e il backend server web).
  3. Se non ricevi la traccia per la chiamata API specifica, il problema è northbound tra l'applicazione client e il router.

Monitoraggio delle API

Il monitoraggio delle API consente di isolare rapidamente le aree problematiche per diagnosticare i problemi di errore, prestazioni e latenza e la loro origine. come app per sviluppatori, proxy API, target di backend o la piattaforma API.

Esamina uno scenario di esempio che dimostri come risolvere i problemi 5xx relativi alle tue API utilizzando il monitoraggio delle API. Ad esempio, puoi configurare un avviso per ricevere una notifica quando il numero di messaging.adaptors.http.flow.ServiceUnavailable errori supera una determinata soglia.

Log di accesso NGINX

Per determinare dove si è verificato l'errore utilizzando UI Trace:

Se il problema si è verificato in passato o se è intermittente e non riesci a acquisire la traccia, quindi eseguire questi passaggi:

  1. Controlla i log di accesso di NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log ).
  2. Cerca se sono presenti errori 503 per il proxy API specifico.
  3. Se riesci a identificare eventuali errori 503 per l'API specifica in un dato momento, si è verificato alla connessione southbound (tra il processore di messaggi e il server di backend).
  4. In caso contrario, il problema si è verificato a livello di connessione northbound (tra l'applicazione client e il router).