503 Usługa niedostępna

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Filmy

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 503 z komunikatem Service Unavailable (Usługa niedostępna) po wywołaniu serwera proxy interfejsu API.

Komunikaty o błędach

Może wyświetlić się ten komunikat o błędzie:

HTTP/1.1 503 Service Unavailable
      

W odpowiedzi HTTP możesz też zobaczyć ten komunikat o błędzie:

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 Unavailable z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable występuje, gdy procesor komunikatów Apigee Edge napotyka błędy z powodu przekroczenia limitu czasu połączenia, nieprawidłowej nazwy hosta lub nieudanych uzgodnień protokołu SSL podczas komunikacji z serwerem backendu.

Możliwe przyczyny odpowiedzi 503 Usługa niedostępna:

Typowe etapy diagnostyki

Określ identyfikator wiadomości, której żądanie się nie powiodło.

Błędy połączenia spowodowane nieprawidłowym rozpoznawaniem nazw DNS

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) identyfikator konkretnego komunikatu żądania. Możesz zobaczyć te błędy:
   
   Błąd onConnectTimeout oznacza, że procesor komunikatów nie mógł połączyć się z serwerem backendu w ustawionym czasie oczekiwania na połączenie (domyślnie: 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. Zanotuj rozpoznany adres IP w błędzie onConnectTimeout i sprawdź, czy jest on prawidłowy dla serwera backendu. Jeśli adres IP jest prawidłowy, przejdź do sekcji Błędy połączenia.
4. Jeśli adres IP jest nieprawidłowy, przyczyną mogą być problemy z rozpoznawaniem nazw DNS.
5. Powtórz kroki 3 i 4 w przypadku kilku innych nieudanych żądań interfejsu API i sprawdź, czy widzisz te same czy inne nieprawidłowe adresy IP.
6. Przeszukaj dziennik procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) pod kątem wiadomości ze słowem kluczowym DNS Refresh. Sprawdź, czy do pamięci podręcznej DNS na procesorze komunikatów są od czasu do czasu dodawane nieprawidłowe adresy IP.

   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 pojawią się problemy z autorytatywnymi serwerami DNS lub serwerami nazw skonfigurowanymi w /etc/resolv.conf.
   
   Zazwyczaj do przeprowadzania rozpoznawania nazw DNS można skonfigurować co najmniej 1 autorytatywny serwer DNS. Jeśli nie ma autorytatywnych serwerów DNS, nastąpi powrót do konfiguracji w /etc/resolv.conf i zostanie przeprowadzone odpowiednie rozpoznawanie nazw DNS. Jeśli na przykład /etc/resolv.conf jest skonfigurowany do używania określonych serwerów nazw, będą one używane do rozpoznawania nazw DNS.
8. Jeśli wystąpią problemy z autorytatywnymi serwerami DNS lub serwerami nazw określonymi w /etc/resolv.conf, nazwy hostów serwerów backendu zostaną rozpoznane jako nieprawidłowe adresy IP. Nieprawidłowe adresy IP będą następnie przechowywane w pamięci podręcznej DNS procesora komunikatów.
   1. Jeśli problem z autorytatywnymi serwerami DNS lub serwerami nazw określonymi w /etc/resolv.conf nadal występuje, nieprawidłowe adresy IP pozostaną w pamięci podręcznej DNS procesora komunikatów. Dopóki nieprawidłowe adresy IP są przechowywane w pamięci podręcznej DNS procesora komunikatów, żądania do wszystkich interfejsów API korzystających z określonego serwera backendu będą kończyć się niepowodzeniem i wyświetlać błąd 503.
   2. Jeśli problem z autorytatywnymi serwerami DNS lub serwerami nazw określonymi w /etc/resolv.conf występuje sporadycznie, w pamięci podręcznej DNS będą okresowo przechowywane prawidłowe i nieprawidłowe adresy IP. W takim przypadku w przypadku wszystkich interfejsów API korzystających z określonego serwera backendu będą się pojawiać błędy 503.
9. Jeśli problem z serwerami DNS będzie się powtarzać, ciągle będą występować błędy. Jeśli problem z serwerami DNS występuje sporadycznie, będziesz widzieć sporadyczne błędy. Oznacza to, że gdy nazwa hosta serwera backendu zostanie rozpoznana jako nieprawidłowy adres IP, pojawią się błędy 503. Gdy nazwy hostów serwera backendu zostaną rozpoznane jako prawidłowe adresy IP, zobaczysz odpowiedzi w sytuacjach powodzenia.

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 /etc/resolv.conf, rozwiąż go na odpowiednim serwerze.
2. Jeśli wystąpi problem z konfiguracją w /etc/resolv.conf na systemach z procesorami wiadomości, rozwiąż go.

Błędy połączeń

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

• Procesor komunikatów nie może nawiązać połączenia w ustawionym okresie limitu czasu połączenia. (Domyślnie: 3 sekundy)
• Serwer backendu odrzuca połączenie.

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) identyfikator konkretnej wiadomości z żądaniem. Możesz zobaczyć te błędy:
   1. Błąd onConnectTimeout oznacza, że procesor komunikatów nie mógł połączyć się z serwerem backendu w ustawionym czasie 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.ConnectException: Connection refused oznacza, że serwer backendu odrzucił połączenie.

      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 za pomocą polecenia telnet:
   1. Jeśli serwer backendu rozpoznaje pojedynczy adres IP, użyj tego polecenia:

      telnet BackendServer-IPaddress 443
                

   2. Jeśli serwer backendu odnosi się do kilku adresów IP, użyj nazwy hosta serwera backendu w poleceniu telnet, jak pokazano poniżej:

      telnet BackendServer-HostName 443
                

4. Jeśli uda Ci się połączyć z serwerem backendu, może pojawić się komunikat podobny do tego: Connected to backend-server. Jeśli nie możesz połączyć się z serwerem backendu, może to być spowodowane tym, że adresy IP procesorów wiadomości nie znajdują się na liście dozwolonych na tym serwerze.

Rozdzielczość

Udziel dostępu do adresów IP procesora wiadomości na konkretnym serwerze backendu, aby umożliwić ruch z procesorów wiadomości Edge do serwera backendu. Na przykład w systemie Linux możesz użyć polecenia iptables, aby zezwolić na ruch z adresów IP procesora wiadomości na serwerze backendu.

Jeśli problem nadal występuje, skontaktuj się z administratorem sieci, aby go zdiagnozować i rozwiązać. Jeśli potrzebujesz dalszej pomocy ze strony Apigee, skontaktuj się z zespołem pomocy Apigee.

Nieprawidłowa nazwa hosta serwera docelowego

Diagnostyka

Jeśli nazwa hosta podana na serwerze docelowym jest nieprawidłowa, możesz otrzymać odpowiedź 503 Usługa niedostępna z kodem błędu messaging.adaptors.http.flow.ServiceUnavailable.

Rozdzielczość

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

Nieudane uzgodnienia połączenia za pomocą protokołu SSL

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

Określanie źródła problemu

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

Omówienie połączeń wychodzących i przychodzących

W Edge może wystąpić błąd 503 „Usługa niedostępna” w przypadku połączenia przychodzącego lub wychodzącego:

• Połączenie przychodzące (lub północne) – połączenie między aplikacją kliencką a routerem brzegowym. Router to komponent Apigee Edge, który obsługuje przychodzące żądania kierowane do systemu.
• Połączenie wychodzące (lub południowe) – połączenie między procesorem komunikatów Edge a serwerem backendu. Procesor komunikatów to komponent Apigee Edge, który przekazuje żądania interfejsu API do serwerów docelowych backendu.

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

Na poniższym rysunku przedstawiono połączenia przychodzące i wychodzące w Apigee Edge.

Określanie, gdzie wystąpił błąd „503: Usługa niedostępna”

Aby sprawdzić, czy błąd 503 Service Unavailable wystąpił w połączeniu wychodzącym czy przychodzącym, wykonaj jedną z tych procedur.