Sprawdzone metody obsługi zgłoszeń do zespołu pomocy Google Cloud Apigee

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

Wyświetlasz dokumentację Apigee X.
Wyświetl dokumentację Apigee Edge.

Podanie szczegółowych i wymaganych informacji w zgłoszeniu ułatwia zespołowi pomocy Google Cloud Apigee szybkie i skuteczne udzielenie odpowiedzi. Jeśli w Twoim zgłoszeniu brakuje istotnych szczegółów, musimy poprosić Cię o dodatkowe informacje, co może wymagać wielokrotnego przesyłania wiadomości. Wymaga to więcej czasu i może opóźnić rozwiązanie problemów. Z tego przewodnika po sprawdzonych metodach dowiesz się, jakich informacji potrzebujemy, aby szybciej rozwiązać Twój problem techniczny.

Opis problemu

Problem powinien zawierać informacje wyjaśniające, co się stało, a co miało się wydarzyć, a także kiedy i jak to się stało. Dobre zgłoszenie do zespołu pomocy Apigee powinno zawierać te kluczowe informacje o każdym z produktów Apigee:

Najważniejsze informacje Opis Apigee Edge w chmurze publicznej Apigee Edge for Private Cloud
Produkt Konkretna usługa Apigee, w której występuje problem, w tym w stosownych przypadkach informacje o wersji.
  • Wersja
Szczegóły problemu Jasny i szczegółowy opis problemu, który zawiera pełny komunikat o błędzie (jeśli występuje).
  • Komunikat o błędzie
  • Wyniki narzędzia do śledzenia
  • Kroki umożliwiające odtworzenie problemu
  • Pełne żądanie do interfejsu API lub polecenie
  • Komunikat o błędzie
  • Wyniki narzędzia do śledzenia
  • Kroki umożliwiające odtworzenie problemu
  • Pełne żądanie do interfejsu API lub polecenie
  • Logi diagnostyczne komponentów
Czas Konkretna sygnatura czasowa, kiedy problem się pojawił, i jak długo trwał.
  • Data, godzina i strefa czasowa wystąpienia problemu
  • Czas trwania problemu
  • Data, godzina i strefa czasowa wystąpienia problemu
  • Czas trwania problemu
Konfiguracja Szczegółowe informacje o miejscu występowania problemu.
  • Nazwa organizacji
  • Nazwa środowiska
  • Nazwa proxy interfejsu API
  • Wersja
  • Topologia sieci
  • Nieprawidłowy komponent Edge

W kolejnych sekcjach opisujemy te pojęcia bardziej szczegółowo.

Produkt

Istnieją różne usługi Apigee, Apigee Edge w chmurze publicznej i Apigee Edge w chmurze prywatnej, dlatego potrzebujemy szczegółowych informacji o tym, z którą z nich występuje problem.

W tabeli poniżej znajdziesz przykłady pokazujące kompletne informacje w kolumnie DOs i niekompletne informacje w kolumnie DON'Ts:

DZIAŁANIA ZALECANE Działania niezalecane
Wdrożenie proxy interfejsu API OAuth2 nie powiodło się w naszej organizacji Public Cloud…

Nie udało się wdrożyć proxy interfejsu API

(Musimy wiedzieć, w której usłudze Apigee występuje problem).

Instalacja nie powiodła się z powodu tego błędu w naszej wersji Edge Private Cloud 4.50.00 ...

Instalacja nie powiodła się w konfiguracji chmury prywatnej.

(Brak informacji o wersji)

Szczegóły problemu

Podaj dokładne informacje o obserwowanym problemie, w tym komunikat o błędzie (jeśli występuje) oraz oczekiwane i rzeczywiste zachowanie.

W tabeli poniżej znajdziesz przykłady pokazujące kompletne informacje w kolumnie DOs i niepełne informacje w kolumnie DON'Ts:

DZIAŁANIA ZALECANE Działania niezalecane

Nowy serwer proxy edgemicro edgemicro_auth nie działa z powodu tego błędu:

{"error":"missing_authorization","error_description":"Missing Authorization header"}

Nowy serwer proxy edgemicro utworzony dzisiaj nie działa

(Nazwa serwera proxy jest nieznana. Nie jest jasne, czy serwer proxy zwraca błąd, czy nieoczekiwaną odpowiedź).

Nasi klienci otrzymują błędy 500 z tym komunikatem o błędzie podczas wysyłania żądań do serwera proxy interfejsu API:

{"fault":{"faultstring":"Execution of JSReadResponse failed with error: Javascript runtime error: \"TypeError: Cannot read property \"content\" from undefined. (JSReadResponse.js:23)","detail":{"errorcode":"steps.javascript.ScriptExecutionFailed"}}}

Nasi klienci otrzymują błędy 500 podczas wysyłania żądań do serwera proxy interfejsu API.

(Samo przekazanie informacji o 500 błędach nie dostarcza nam wystarczających informacji do zbadania problemu. Musimy znać rzeczywisty komunikat o błędzie i kod błędu, które są obserwowane).

Godzina

Czas jest bardzo ważną informacją. Inżynier pomocy musi wiedzieć, kiedy problem został zauważony po raz pierwszy, jak długo trwał i czy nadal występuje.

Inżynier pomocy rozwiązujący problem może nie znajdować się w Twojej strefie czasowej, więc względne określenia czasu utrudniają diagnozę. Dlatego zalecamy używanie formatu ISO 8601 w przypadku daty i godziny, aby podać dokładne informacje o tym, kiedy wystąpił problem.

W tabeli poniżej znajdziesz przykłady pokazujące dokładny czas i okres, w którym wystąpił problem, w kolumnie DOs oraz niejednoznaczne lub niejasne informacje o tym, kiedy wystąpił problem, w kolumnie DON'Ts:

DZIAŁANIA ZALECANE Działania niezalecane
Wczoraj między 6 listopada 2020 r., 17:30 czasu PDT a 6 listopada 2020 r., 17:35 czasu PDT zaobserwowano ogromną liczbę 503s...

Wczoraj o 17:30 przez 5 minut zaobserwowano ogromną liczbę 503s.

(Jesteśmy zmuszeni użyć domniemanej daty, a także nie wiemy, w której strefie czasowej wystąpił ten problem).

W przypadku tych proxy interfejsów API od 9 listopada 2020 r. od 15:30 czasu IST do 9 listopada 2020 r. do 18:10 czasu IST zaobserwowano duże opóźnienia...

W zeszłym tygodniu w przypadku niektórych proxy interfejsów API zaobserwowano wysokie opóźnienia.

(Nie wiadomo, w którym dniu i jak długo ten problem występował w ostatnim tygodniu).

Konfiguracja

Musimy znać szczegóły dotyczące tego, gdzie dokładnie występuje problem. W zależności od używanej usługi potrzebujemy tych informacji:

  • Jeśli korzystasz z Apigee Cloud, możesz mieć więcej niż jedną organizację, dlatego musimy znać konkretną organizację i inne szczegóły, w których występuje problem:
    • Nazwy organizacji i środowisk
    • Nazwa proxy interfejsu API i numery wersji (w przypadku nieudanych żądań do interfejsu API)
  • Jeśli używasz chmury prywatnej , możesz korzystać z jednej z wielu obsługiwanych topologii instalacji. Musimy więc wiedzieć, jakiej topologii używasz, w tym szczegóły takie jak liczba centrów danych i węzłów.

W tabeli poniżej znajdziesz przykłady pokazujące kompletne informacje w kolumnie DOs i niepełne informacje w kolumnie DON'Ts:

DZIAŁANIA ZALECANE Działania niezalecane

401 Od 6 listopada 2020 r. o godzinie 9:30 czasu CST liczba błędów w chmurze publicznej Edge wzrosła.

Szczegóły konfiguracji krawędzi:

Szczegóły interfejsu API, który nie działa:
  Nazwy organizacji: myorg
  Nazwy środowisk: test
  Nazwy serwerów proxy interfejsu API: myproxy
  Numery wersji: 3

Błąd:

{"fault":{"faultstring":"Failed to resolve API Key variable request.header.X-APP-API_KEY","detail":{"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"}}}

401 Wzrost liczby błędów.

(Nie zawiera żadnych informacji o używanym produkcie, czasie występowania problemu ani szczegółów konfiguracji).

Nie można uruchomić procesora komunikatów w Edge Private Cloud w wersji 4.19.06 po dodaniu dodatkowych węzłów bramy.

Dzienniki diagnostyczne:
 Załączono dzienniki procesora komunikatów.

Topologia sieci:
Załącz plik network-topology.png zawierający dodatkowe węzły.

Nie można uruchomić procesora komunikatów w Edge Private Cloud w wersji 4.19.06 po dodaniu dodatkowych węzłów bramy.

(Brak dzienników procesora komunikatów i topologii sieci).

Przydatne artefakty

Przesłanie nam artefaktów związanych z problemem przyspieszy jego rozwiązanie, ponieważ pomoże nam zrozumieć, jak dokładnie zachowuje się usługa, i uzyskać więcej informacji na ten temat.

W tej sekcji opisujemy przydatne artefakty, które są pomocne w przypadku wszystkich usług Apigee:

Typowe artefakty dla wszystkich usług Apigee

Poniższe artefakty są przydatne w przypadku wszystkich usług Apigee: Apigee Edge w chmurze publicznej i Apigee Edge w chmurze prywatnej:

Artefakt Opis
Dane wyjściowe narzędzia Trace Dane wyjściowe narzędzia Trace zawierają szczegółowe informacje o żądaniach interfejsu API przepływających przez usługi Apigee. Jest to przydatne w przypadku błędów środowiska wykonawczego, takich jak 4XX, 5XX i problemy z opóźnieniami.
Zrzuty ekranu Zrzuty ekranu pomagają przekazać kontekst obserwowanego zachowania lub błędu. Jest to przydatne w przypadku wszelkich zaobserwowanych błędów lub problemów, np. w interfejsie lub Analytics.
HAR (Http ARchive) HAR to plik przechwytywany przez narzędzia do sesji HTTP w celu debugowania problemów związanych z interfejsem. Można to zrobić za pomocą przeglądarek takich jak Chrome, Firefox czy Internet Explorer.
tcpdumps Narzędzie tcpdump przechwytuje pakiety TCP/IP przesyłane lub odbierane przez sieć. Jest to przydatne w przypadku problemów związanych z siecią, takich jak błędy uzgadniania protokołu TLS, błędy 502 i opóźnienia.

Dodatkowe artefakty Apigee Edge for Private Cloud

W przypadku Apigee Edge for Private Cloud możemy potrzebować dodatkowych artefaktów, które ułatwią szybsze diagnozowanie problemów.

Artefakt Opis
Topologia sieci Schemat topologii instalacji Edge opisujący konfigurację chmury prywatnej, w tym wszystkie centra danych, węzły i komponenty zainstalowane w każdym węźle.
Logi diagnostyczne komponentu Edge Dzienniki diagnostyczne związane z określonym komponentem Apigee Edge, takim jak procesor wiadomości, router lub Cassandra.
Plik konfiguracji instalacji Plik konfiguracji cichej używany podczas instalowania lub uaktualniania Apigee Edge.

Ten plik jest przydatny do sprawdzania, czy wszystkie ustawienia są prawidłowe w przypadku wystąpienia problemów z instalacją lub migracją.

Zrzuty sterty Zrzuty sterty to migawka procesu pamięci Java. Jest to przydatne, jeśli w przypadku niektórych komponentów Edge występuje wysokie wykorzystanie pamięci lub błędy OutOfMemory.
Zrzuty wątków Zrzut wątków to migawka wszystkich wątków działającego procesu Java.

Jest to przydatne, jeśli w przypadku niektórych komponentów Edge obserwujesz wysokie wykorzystanie procesora lub duże obciążenie.

Szablony zgłoszeń i przykładowe zgłoszenia

W tej sekcji znajdziesz szablony zgłoszeń i przykładowe zgłoszenia dotyczące różnych usług, które są zgodne ze sprawdzonymi metodami opisanymi w tym dokumencie:

Apigee Edge w chmurze publicznej

Szablon

Ta sekcja zawiera przykładowy szablon Apigee Edge w chmurze publicznej.

Problem:

<Podaj szczegółowy opis problemu lub zaobserwowanego u Ciebie zachowania. W stosownych przypadkach podaj nazwę i wersję produktu.>

Komunikat o błędzie:

<Include the complete error message observed (if any)>

Czas rozpoczęcia problemu (format ISO 8601):

Czas zakończenia problemu (format ISO 8601):

Szczegóły konfiguracji Apigee:
  Nazwy organizacji:
  Nazwy środowisk:
  Nazwy serwerów proxy interfejsu API:
  Numery wersji:

Kroki prowadzące do pojawienia się błędu:

<Podaj kroki umożliwiające odtworzenie problemu, jeśli to możliwe>

Informacje diagnostyczne:

<Lista załączonych plików>

Przykład

W tej sekcji znajdziesz przykładowy przypadek użycia Apigee Cloud (Apigee w Google Cloud/Apigee Edge w chmurze publicznej).

Problem:

W naszej organizacji Public Cloud występuje duża liczba błędów 503 Service Unavailable. Czy możesz sprawdzić ten problem i go rozwiązać lub doradzić nam, jak to zrobić?

Komunikat o błędzie:

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

Godzina rozpoczęcia problemu (format ISO 8601): 2020-10-04 06:30 IST

Godzina zakończenia problemu (format ISO 8601): problem nadal występuje.

Szczegóły konfiguracji Apigee Cloud:
  Nazwy organizacji: myorg
  Nazwy środowisk: dev
  Nazwy serwerów proxy interfejsu API: myproxy
  Numery wersji: 3

Kroki prowadzące do pojawienia się błędu:

Aby odtworzyć problem, uruchom to polecenie curl:

curl -X GET 'https://myorg-dev.apigee.net/v1/myproxy'

Informacje diagnostyczne:

Dane wyjściowe narzędzia śledzącego (trace-503.xml)

Apigee Edge for Private Cloud

Szablon

Ta sekcja zawiera przykładowy szablon Apigee Edge Private Cloud.

Problem:

<Podaj szczegółowy opis problemu lub zaobserwowanego u Ciebie zachowania. W stosownych przypadkach podaj nazwę i wersję produktu.>

Komunikat o błędzie:

<Include the complete error message observed (if any)>

Czas rozpoczęcia problemu (format ISO 8601):

Czas zakończenia problemu (format ISO 8601):

Szczegóły konfiguracji Edge Private Cloud:

<Dołącz topologię sieci opisującą konfigurację chmury prywatnej, w tym centra danych i węzły>

Kroki prowadzące do pojawienia się błędu:

<Podaj kroki umożliwiające odtworzenie problemu, jeśli to możliwe>

Informacje diagnostyczne

<Lista załączonych plików>

Przykład

Ta sekcja zawiera przykładowy przypadek użycia Apigee Edge for Private Cloud.

Problem:

Podczas instalowania serwera zarządzania Apigee na węźle 10 w ramach Edge Private Cloud 4.19.06 na Linux RHEL 7.6 wystąpił ten błąd.

Komunikat o błędzie:

<snipped as the output is too long>
Checking for management-server uuid ................................................
Unable to get uuid for management-server.
Error: setup.sh: /opt/apigee/apigee-service/bin/apigee-service exited with unexpected status 1

Czas rozpoczęcia problemu (format ISO 8601): występuje, gdy instalujemy

Czas zakończenia problemu(format ISO 8601): nie dotyczy

Szczegóły konfiguracji Edge Private Cloud:

Załączony plik network-topology.png

Kroki prowadzące do pojawienia się błędu:

Oto polecenie, które spowodowało powyższy błąd:

/opt/apigee/apigee-setup/bin/setup.sh -p ms -f /app/NonProdConfig.txt

Informacje diagnostyczne:

Załączone pliki:

  • output.txt zawierający pełne dane wyjściowe powyższego polecenia, w tym komunikat o błędzie.
  • logi serwera zarządzania,
  • Plik konfiguracyjny NonProdConfig.txt