503 Usługa niedostępna

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Filmy

Więcej informacji o błędach 503 znajdziesz w tych filmach:

Wideo Opis
Rozwiązywanie problemów z niedostępnością usługi 503 z powodu problemu z DNS Dowiedz się więcej o:
  • Błąd 503 – usługa niedostępna z powodu rozpoznawania nazw DNS i problemów z siecią w Apigee Edge
  • Rozwiązywanie problemów z błędem 503 „Service Niedostępne” w czasie rzeczywistym spowodowanym przez problem z rozpoznawaniem nazw DNS
Rozwiązywanie problemów z niedostępnością usługi 503 z powodu problemu z siecią Rozwiązywanie problemów z dostępem do usługi 503 (działającej w czasie rzeczywistym) spowodowanym przez problem z siecią w Apigee Edge

Krótki opis problemu

Po wywołaniu serwera proxy interfejsu API aplikacja kliencka otrzymuje odpowiedź HTTP 503 z komunikatem Usługa niedostępna.

Komunikaty o błędach

Może pojawić się ten komunikat o błędzie:

HTTP/1.1 503 Service Unavailable
      

Możesz też zobaczyć ten komunikat o błędzie w odpowiedzi HTTP:

Usługa niedostępna

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

Możliwe przyczyny

Odpowiedź HTTP 503 Service AVAILABLE (Usługa niedostępna) z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable pojawia się, jeśli podczas komunikacji z serwerem backendu procesor wiadomości w Apigee Edge napotka błędy związane z przekroczeniem limitu czasu połączenia, nieprawidłową nazwą hosta lub błędami uzgadniania połączenia SSL.

Możliwe przyczyny komunikatu 503 Service AVAILABLE (Usługa niedostępna) to:

Przyczyna Opis Kto może rozwiązywać problemy
Błędy połączenia spowodowane nieprawidłowym rozpoznawaniem nazw DNS Rozpoznawanie nazw DNS serwera docelowego spowodowało nieprawidłowe adresy IP, które prowadziły do błędów połączenia. Użytkownicy chmury Private Cloud
Błędy połączeń Problemy z siecią lub połączeniem uniemożliwiają klientowi nawiązanie połączenia z serwerem. Użytkownicy chmury Private Cloud
Nieprawidłowa nazwa hosta serwera docelowego Podany host serwera docelowego jest nieprawidłowy lub zawiera niechciane znaki (takie jak spacja). Użytkownicy chmury publicznej i prywatnej usługi Edge
Nieudane uzgadnianie połączenia SSL Nie udało się nawiązać połączenia TLS/SSL między klientem a serwerem. (te rozwiązania zostały omówione w osobnym temacie). Użytkownicy chmury publicznej i prywatnej usługi Edge

Najczęstsze kroki diagnostyki

Określ identyfikator wiadomości nieudanego żądania

Narzędzie do śledzenia

Aby za pomocą narzędzia do śledzenia określić identyfikator wiadomości nieudanego żądania:

  1. Jeśli problem nadal występuje, włącz sesję śledzenia dla odpowiedniego interfejsu API.
  2. Wykonaj wywołanie interfejsu API i odtwórz problem – „Usługa 503 jest niedostępna” z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable..
  3. Wybierz jedno z niepomyślnych żądań.
  4. Przejdź do fazy AX i określ identyfikator wiadomości (X-Apigee.Message-ID) żądania, przewijając w dół sekcję Szczegóły fazy, tak jak na ilustracji poniżej.

    Identyfikator wiadomości w sekcji szczegółów fazy

Logi dostępu NGINX

Aby określić identyfikator wiadomości odrzuconego żądania przy użyciu dzienników dostępu NGINX:

Możesz też sprawdzić identyfikatory wiadomości dla błędów 503 w logach dostępu NGINX. Jest to szczególnie przydatne, jeśli problem występował w przeszłości lub występuje sporadycznie i nie możesz przechwycić logu czasu w interfejsie użytkownika. Aby określić te informacje w dziennikach dostępu NGINX, wykonaj te czynności:

  1. Sprawdź logi dostępu do NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Wyszukaj błędy 503 związane z konkretnym serwerem proxy interfejsu API w określonym czasie (jeśli problem wystąpił w przeszłości) lub jeśli nadal są jakieś żądania z błędami 503.
  3. Jeśli wystąpią błędy 503 z błędem X-Apigee-fault-code messaging.adaptors.http.flow.Serviceavailable, zapisz identyfikator wiadomości co najmniej jednego z takich żądań, jak pokazano w poniższym przykładzie:

    Przykładowy wpis z błędem 503

    Przykładowy wpis zawierający kod stanu, identyfikator komunikatu, źródło błędu i kod błędu

Błędy połączenia z powodu nieprawidłowego rozpoznawania nazw DNS

Diagnostyka

  1. Określ identyfikator wiadomości nieudanego żądania.
  2. Wyszukaj identyfikator komunikatu żądania w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log). Mogą wystąpić te błędy:

    Błąd onConnectTimeout oznacza, że procesor wiadomości nie mógł połączyć się z serwerem backendu przez ustalony czas oczekiwania połączenia (wartość domyślna: 3 sekundy).
    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. Zwróć uwagę na adres IP podany w błędzie onConnectTimeout i sprawdź, czy adres IP jest prawidłowy dla Twojego serwera backendu. Jeśli adres IP jest prawidłowy, przejdź do sekcji Błędy połączeń.
  4. Jeśli adres IP jest nieprawidłowy, najprawdopodobniej przyczyną są problemy z rozpoznawaniem nazw DNS.
  5. Powtórz kroki 3 i 4 dla kilku kolejnych nieudanych żądań do interfejsu API i sprawdź, czy wyświetlane są te same czy inne nieprawidłowe adresy IP.
  6. W dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log) wyszukaj wiadomości ze słowem kluczowym DNS refresh (Odświeżanie DNS). Sprawdź, czy błędne lub nieprawidłowe adresy IP są od czasu do czasu dodawane do pamięci podręcznej DNS procesora wiadomości.
    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. Ten problem może wystąpić, jeśli występują problemy z autorytatywnymi serwerami DNS lub serwerami nazw skonfigurowanymi w /etc/resolv.conf.

    Zwykle istnieje co najmniej jeden autorytatywny serwer DNS skonfigurowany do rozpoznawania nazw DNS. Jeśli nie ma wiarygodnych serwerów DNS, system użyje konfiguracji /etc/resolv.conf i w razie potrzeby rozpozna DNS. Jeśli na przykład /etc/resolv.conf jest skonfigurowany do używania określonych serwerów nazw, te serwery nazw będą używane do rozpoznawania nazw DNS.
  8. W przypadku wystąpienia problemów z autorytatywnymi serwerami DNS lub serwerami nazw wymienionymi w zasadzie /etc/resolv.conf nazwy hostów serwera backendu zostaną przekształcone w błędne lub nieprawidłowe adresy IP. Błędne i nieprawidłowe adresy IP są przechowywane w pamięci podręcznej DNS procesora wiadomości.
    1. Jeśli problem z autorytatywnymi serwerami DNS lub serwerami nazw wymienionymi w zasadzie /etc/resolv.conf będzie się powtarzał, nieprawidłowe lub nieprawidłowe adresy IP pozostaną w pamięci podręcznej DNS tego procesora wiadomości. Jeśli nieprawidłowe adresy IP są przechowywane w pamięci podręcznej DNS procesora wiadomości, żądania wysyłane do wszystkich tych interfejsów API korzystających z określonego serwera backendu będą kończyć się błędem 503.
    2. Jeśli problem z autorytatywnymi serwerami DNS lub serwerami nazw wymienionymi w zasadzie /etc/resolv.conf występuje sporadycznie, prawidłowe i złe adresy IP będą przechowywane w pamięci podręcznej DNS nieregularnie. W takim przypadku okresowo będą pojawiać się błędy 503 dla wszystkich tych interfejsów API korzystających z określonego serwera backendu.
  9. Jeśli problem z serwerami DNS będzie się utrzymywać, wciąż będą występować awarie. Jeśli problem z serwerami DNS nie ustąpi, będą sporadyczne awarie. Oznacza to, że za każdym razem, gdy nazwa hosta serwera backendu zostanie przekształcona w nieprawidłowy adres IP, wystąpią błędy 503. A gdy nazwy hostów serwera backendu zostaną przekształcone w prawidłowe adresy IP, zwróć uwagę na prawidłowe odpowiedzi.

Rozdzielczość

Skontaktuj się z administratorem systemu operacyjnego i rozwiąż problemy z serwerami DNS.

  1. Jeśli wystąpił problem z autorytatywnymi serwerami DNS lub serwerami nazw określonymi w zasadzie /etc/resolv.conf, rozwiąż ten problem, korzystając z właściwego serwera.
  2. Jeśli występuje jakiś problem z konfiguracją w /etc/resolv.conf w systemach obsługujących procesory wiadomości, rozwiąż ten problem.

Błędy połączeń

Błąd połączenia występuje, gdy procesor wiadomości Apigee Edge próbuje połączyć się z serwerem backendu i występuje jeden z tych problemów:

  • Procesor wiadomości nie może nawiązać połączenia przed upływem ustalonego czasu oczekiwania połączenia. (Domyślnie: 3 sekundy).
  • Serwer backendu odrzuca połączenie.

Diagnostyka

  1. Określ identyfikator wiadomości nieudanego żądania.
  2. Wyszukaj identyfikator komunikatu żądania w logu procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log). Mogą pojawić się te błędy:
    1. Błąd onConnectTimeout oznacza, że procesor wiadomości nie mógł połączyć się z serwerem backendu przed upływem ustalonego limitu czasu oczekiwania na połączenie.
      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. Błąd java.net.ConnectWyjątek: Odmowa połączenia wskazuje, że serwer backendu odmówił połączenia.
      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. Sprawdź, czy możesz połączyć się z określonym serwerem backendu bezpośrednio z każdego procesora wiadomości przy użyciu polecenia telnet:
    1. Jeśli serwer backendu ma pojedynczy adres IP, użyj tego polecenia:
      telnet BackendServer-IPaddress 443
                
    2. Jeśli serwer backendu ma wiele adresów IP, użyj nazwy hosta serwera backendu w poleceniu telnet, jak pokazano poniżej:
      telnet BackendServer-HostName 443
                
  4. Jeśli możesz nawiązać połączenie z serwerem backendu, możesz zobaczyć komunikat taki jak Connected to backend-server. Jeśli nie możesz połączyć się z serwerem backendu, może to być spowodowane tym, że adresów IP procesorów wiadomości nie ma na liście dozwolonych na danym serwerze backendu.

Rozdzielczość

Przyznaj dostęp adresom IP podmiotu przetwarzającego wiadomości na określonym serwerze backendu, aby umożliwić dostęp do serwera backendu ruchowi z brzegowych systemów przetwarzania wiadomości. Na przykład w systemie Linux można użyć polecenia iptables, aby zezwolić na ruch z adresów IP procesora wiadomości na serwerze backendu.

Jeśli problem nie ustąpi, skontaktuj się z administratorem sieci, aby go rozwiązać i rozwiązać. Jeśli potrzebujesz dodatkowej pomocy dotyczącej Apigee, skontaktuj się z zespołem pomocy Apigee.

Nieprawidłowa nazwa hosta serwera docelowego

Diagnostyka

Jeśli nazwa hosta określona na serwerze docelowym jest nieprawidłowa, możesz otrzymać odpowiedź 503 Service Niedostępne z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable.

Narzędzie do śledzenia

Aby zdiagnozować za pomocą narzędzia Trace:

  1. Jeśli problem nadal występuje, włącz sesję śledzenia dla odpowiedniego interfejsu API.
  2. Wykonaj wywołanie interfejsu API i odtwórz problem – „Usługa 503 jest niedostępna” z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable..
  3. Wybierz jedno z niepomyślnych żądań.
  4. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.
  5. Wybierz FlowInfo, w którym występuje błąd. Więcej informacji znajdziesz w polu error.cause, które pomogą Ci określić przyczynę błędu, jak pokazano w tym przykładzie:

    Przykładowe żądanie wyświetlające błąd.cause w śladzie

    Przykładowe żądanie przedstawiające błąd.cause w śledzeniu
  6. Jeśli w polu error.cause widzisz komunikat Host nieosiągalny, prawdopodobna przyczyna błędu:
    • Nazwa hosta określona w konfiguracji serwera docelowego/docelowego punktu końcowego jest nieprawidłowa lub zawiera niechciane spacje lub znaki specjalne.

      Na przykład w nazwie hosta jest niechciana spacja, jak pokazano poniżej:
      "demo-target.apigee.net "
                        
    • Nazwa hosta zastąpiona zmienną target.url w serwerze proxy interfejsu API za pomocą zasady AssignMessage lub JavaScript jest nieprawidłowa lub zawiera spację lub inne niechciane znaki specjalne.
  7. Sprawdź konfigurację docelowego punktu końcowego lub definicję serwera docelowego, aby zobaczyć, czy nazwa hosta serwera docelowego jest nieprawidłowa bądź zawiera niepotrzebne spacje lub znaki specjalne.
  8. Jeśli docelowy host serwera jest tworzony dynamicznie, sprawdź odpowiednią zasadę (np. AssignMessage/JavaScript) używaną do jego utworzenia. Sprawdź, czy nazwa hosta serwera docelowego jest nieprawidłowa lub czy zawiera niepotrzebne spacje lub znaki specjalne.
  9. Po określeniu nazwy hosta serwera docelowego uruchom polecenie nslookup/dig dotyczące tej nazwy, aby sprawdzić, czy można ją rozwiązać.

    Na przykład uruchomienie polecenia nslookup dla nazwy hosta z niechcianą spacją zwraca takie dane wyjściowe:

    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. Jeśli polecenie nslookup systemu operacyjnego również nie rozpoznaje nazwy hosta, przyczyną tego problemu jest nieprawidłowa nazwa hosta używana na serwerze docelowym.

    Kliknij Rozwiązanie.

Logi procesora wiadomości

Aby zdiagnozować za pomocą logów procesora wiadomości:

  1. Określ identyfikator wiadomości nieudanego żądania.
  2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Jeśli widzisz poniższe ostrzeżenia lub komunikaty o błędach, oznacza to, że procesor wiadomości nie może rozpoznać nazwy hosta. Ponieważ wiadomość zostanie odłożona, możesz nie widzieć tego ostrzeżenia w przypadku niektórych identyfikatorów wiadomości/żądań.
    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. Po tym pojawi się komunikat z ostrzeżeniem, który oznacza, że procesor wiadomości usuwa adres z pamięci podręcznej DNS, ponieważ nie można nawiązać połączenia z hostem serwera docelowego.
    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. Następnie może pojawić się komunikat, w którym występują błędy przetwarzania wiadomości z wyjątkiem „Host nieosiągalny”. Czasami razem z komunikatem o błędzie pojawia się nazwa hosta:
    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. Czasami może mieć wartość null, ponieważ nie można rozpoznać lub osiągnąć nazwy hosta, jak pokazano poniżej:
    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. Błąd Host not reachable zwykle występuje w jednym z tych przypadków:
    • Nazwa hosta określona w konfiguracji serwera docelowego/docelowego punktu końcowego jest nieprawidłowa lub zawiera niechciane spacje lub znaki specjalne.

      Na przykład w nazwie hosta „demo-target.apigee.net” jest niechciana spacja w tym komunikacie o błędzie:
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
              
    • Nazwa hosta zastąpiona zmienną target.url w serwerze proxy interfejsu API za pomocą zasady AssignMessage lub JavaScript jest nieprawidłowa lub zawiera spację lub inne niechciane znaki specjalne.
  8. Ustal nazwę hosta serwera docelowego, z którym procesor wiadomości próbuje się połączyć, korzystając z jednego z tych rozwiązań:
    1. Uważnie zapoznaj się z komunikatem o błędzie zawierającym hasło Host not reachable .
    2. Jeśli komunikat o błędzie zawiera nazwę hosta, skopiuj ją ze spacjami i znakami specjalnymi.
    3. Jeśli w przypadku nazwy hosta pojawia się komunikat o błędzie null (jak w poniższym komunikacie o błędzie),
      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. Określ nazwę hosta, sprawdzając definicję serwera docelowego używanego w niesprawnym serwerze proxy interfejsu API.
      2. Jeśli docelowy host serwera jest tworzony dynamicznie, sprawdź odpowiednią zasadę (na przykład zasadę AssignMessage/JavaScript) używaną do jego utworzenia.
  9. Po ustaleniu nazwy hosta serwera docelowego uruchom polecenie nslookup/dig w nazwie hosta i sprawdź, czy da się ją rozpoznać.

    Na przykład uruchom polecenie nslookup na nazwie hosta ze spacją

    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. Jeśli polecenie nslookup w systemie operacyjnym nie rozpozna nazwy hosta, przyczyną tego problemu jest nieprawidłowa nazwa hosta używana na serwerze docelowym.

Rozdzielczość

  1. Sprawdź, czy nazwa hosta serwera docelowego określona w konfiguracji docelowego punktu końcowego lub w definicji serwera docelowego jest prawidłowa i nie zawiera zbędnej spacji ani znaków specjalnych.
  2. Jeśli używasz dowolnej zasady AssignMessage/JavaScript do dynamicznego generowania nazwy hosta serwera docelowego, sprawdź definicję zasady i kod oraz upewnij się, że nazwa hosta serwera docelowego jest generowana prawidłowo.

Nieudane uzgadnianie połączenia SSL

Cały scenariusz rozwiązywania problemów jest poświęcony błędom uzgadniania połączenia TLS/SSL. Zobacz Błędy uzgadniania połączenia SSL.

Ustalenie źródła problemu

Pewne typy błędów mogą występować w połączeniu przychodzącym (w kierunku północnym) lub wychodzącym (południowym). Między aplikacją kliencką a Edge występuje błąd przychodzący (w kierunku północnym). Między brzegiem a serwerem docelowym backendu występuje błąd wychodzący (południowy). Aby zdiagnozować tego rodzaju problemy, najpierw musisz sprawdzić, czy błąd występuje na połączeniu w kierunku północnym czy południowym.

Omówienie połączeń w kierunku północnym i południowym

W przeglądarce Edge może pojawić się błąd 503 Service Niedostępne przy połączeniu przychodzącym lub wychodzącym:

  • Połączenie przychodzące (lub w kierunku północnym) – połączenie między aplikacją kliencką a routerem brzegowym. Router jest komponentem Apigee Edge, który obsługuje przychodzące żądania wysyłane do systemu.
  • Połączenie wychodzące (lub w kierunku południowym) – połączenie między procesorem wiadomości brzegowym a serwerem backendu. Procesor wiadomości jest komponentem Apigee Edge, który przekierowuje żądania interfejsu API do serwerów docelowych backendu.

Jeśli korzystasz z Edge Public Cloud, prawdopodobnie nie wiesz o komponentach wewnętrznych, takich jak router czy procesor wiadomości. Te komponenty wewnętrzne nie są widoczne ani dostępne dla użytkowników chmury publicznej. W miarę możliwości udostępniamy alternatywne sposoby badania problemu, które nie wymagają bezpośredniego dostępu do tych komponentów.

Poniższy rysunek przedstawia połączenia w kierunku północnym i południowym dla Apigee Edge.

Przepływ aplikacji klienckiej (połączenie w kierunku północnym) przez serwer brzegowy do serwera backendu (połączenie południowe)

Określam, gdzie wystąpił błąd 503 Niedostępna usługa

Skorzystaj z jednej z poniższych procedur, aby sprawdzić, czy błąd 503 Service Niedostępne wystąpił na połączeniu w kierunku północnym czy południowym.

Śledzenie UI

Aby określić, gdzie wystąpił błąd, za pomocą śledzenia interfejsu użytkownika:

  1. Jeśli problem nadal występuje, włącz śledzenie interfejsu API, którego dotyczy problem.
  2. Jeśli log czasu interfejsu użytkownika dla nieudanego żądania do interfejsu API pokazuje, że błąd 503 Service Niedostępne podczas docelowego przepływu żądania lub jest wysyłany przez serwer backendu, oznacza to, że problem występuje southbound (czyli między procesorem wiadomości a serwerem backendu).
  3. Jeśli nie otrzymasz logu czasu dla określonego wywołania interfejsu API, oznacza to, że problem występuje na północ między aplikacją kliencką a routerem.

Monitorowanie interfejsów API

Monitorowanie interfejsów API umożliwia szybkie wyizolowanie problematycznych obszarów w celu diagnozowania problemów dotyczących błędów, wydajności i opóźnień oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsów API, cele backendu czy platforma API.

Przejrzyj przykładowy scenariusz pokazujący, jak rozwiązać problemy 5xx z interfejsami API przy użyciu API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba błędów w messaging.adaptors.http.flow.ServiceUnavailable przekroczy określony próg.

Logi dostępu NGINX

Aby określić, gdzie wystąpił błąd, za pomocą śledzenia interfejsu użytkownika:

Jeśli problem wystąpił w przeszłości lub jest przejściowy i nie możesz przechwycić logu czasu, wykonaj te czynności:

  1. Sprawdź logi dostępu do NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log).
  2. Sprawdź, czy występują błędy 503 dla określonego serwera proxy interfejsu API.
  3. Jeśli w określonym momencie możesz wykryć błędy 503 dla określonego interfejsu API, oznacza to, że problem wystąpił na połączeniu southbound (między procesorem wiadomości a serwerem backendu).
  4. Jeśli nie, problem wystąpił na połączeniu północnym (między aplikacją kliencką a routerem).