Najczęstsze pytania

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

Poniżej znajdziesz odpowiedzi na najczęstsze pytania:

Apigee zaleca te metody:

  1. Zacznij od konfigurowania alertów dla dowolnego serwera proxy interfejsu API z określonym progiem. Na przykład 10% błędów 4xx przez 5 minut. Skonfiguruj powiadomienia i odwiedź stronę Historia alertów, aby monitorować wyzwalane alerty. Konfigurowanie dodatkowych alertów i powiadomień dla określonych usług proxy API i usług docelowych. Kontynuuj dostosowywanie alertów i powiadomień na podstawie swoich obserwacji.
  2. Poproś zespoły odpowiedzialne za tworzenie interfejsów API, aby zaleciły zespołowi operacyjnemu, który konfiguruje alerty, wartości progowe dotyczące odsetka błędów i czasu oczekiwania.

Które role mają dostęp do monitorowania interfejsu API?

Zapoznaj się z informacjami o rolach monitorowania interfejsu API.

Dlaczego na stronie Ostatnie nie widzę wszystkich serwerów proxy API?

Panel Ostatnie zawiera tylko te serwery proxy interfejsu API, które miały ruch w ostatnim czasie. Nie wyświetla on wszystkich serwerów proxy API w organizacji. W panelu Oś czasu możesz wyświetlać dane dotyczące wszystkich serwerów proxy interfejsu API.

Dlaczego nie widzę wykresów opóźnień na osi czasu?

Wykresy oczekiwań są wyświetlane na osi czasu tylko wtedy, gdy wybierzesz region i serwer proxy interfejsu API, a wybrany zakres czasu nie przekracza 7 dni.

Logi są przydatne do identyfikowania kodów stanu, które powodują błędy, ale jak mogę zidentyfikować identyfikatory deweloperów, które generują wywołania?

Identyfikatory deweloperów nie są uwzględniane w dziennikach monitorowania interfejsu API. Aby pobrać identyfikatory deweloperów, możesz utworzyć raport niestandardowy.

Czy mogę monitorować łańcuch serwerów proxy?

Możesz użyć jednego serwera proxy API jako docelowego punktu końcowego innego serwera proxy API, łącząc w ten sposób oba serwery w łańcuchu serwerów proxy. Jednak monitorowanie interfejsu API rejestruje tylko żądania wysyłane do pierwszego serwera proxy w łańcuchu, a nie do serwera proxy interfejsu API używanego jako docel. Więcej informacji znajdziesz w artykule Łączenie proxy interfejsu API w łańcuch.

Dlaczego na panelach widzę „nie ustawiono”?

Jeśli wartość proxy API, źródła błędu, kodu błędu lub zasady dotyczącej błędów jest nieprawidłowa lub nie można jej określić, na panelu wyświetli się wartość „nie ustawiono”. Przykłady scenariuszy, które mogą spowodować ustawienie wartości „nie ustawiono”:

  • Błędy związane z klientem
  • kody błędów HTTP, które są zastępowane odpowiedzią z powodzeniem;
  • kody stanu HTTP 2xx (ponieważ zwykle nie powodują błędów);

Więcej informacji o wartości „(not set)” (nie ustawiono) znajdziesz w artykule Co oznacza wartość „(not set)” (nie ustawiono) w entytetach Analytics?

Czy monitorowanie interfejsu API jest dostępne w interfejsie klasycznym czy Edge w chmurze prywatnej?

Monitorowanie interfejsów API Apigee jest obecnie dostępne tylko dla klientów Apigee Edge Cloud Enterprise, którzy korzystają z nowego interfejsu Edge API.

Monitorowanie interfejsu Apigee API nie jest dostępne w interfejsie klasycznej wersji Edge ani w Edge dla chmury prywatnej.

Co to jest playbook?

Podczas konfigurowania alertu w polu Playbook podajesz krótki opis zalecanych działań, które należy wykonać, aby rozwiązać problemy, gdy wystąpią alerty. Możesz też podać link do wewnętrznej strony wiki lub strony społeczności, na której znajdziesz sprawdzone metody. Informacje w tym polu zostaną uwzględnione w powiadomieniu.

Jak obsługiwać kody błędów HTTP 429?

Zasada dotycząca limitu w Edge i zasada SpikeArrest zwracają kod błędu HTTP 429, gdy przekroczony zostanie limit (zasada dotycząca limitu) lub limit szybkości (zasada SpikeArrest).

W panelu Alerty nie można jednak zdefiniować alertu dla kodu błędu HTTP 429. Zamiast tego możesz ustawić warunek alertu Zasady zarządzania ruchem > Limity > Naruszenie limitu, jak pokazano poniżej, lub Zasady zarządzania ruchem > Spike Arrest > Naruszenie SpikeArrest:

naruszenie limitu