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

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

Przeglądasz dokumentację Apigee X.
Wyświetl dokumentację Apigee Edge.

Podanie szczegółowych i wymaganych informacji w zgłoszeniu do zespołu pomocy ułatwi zespołowi pomocy Google Cloud Apigee szybkie i skuteczne udzielenie odpowiedzi. Gdy w zgłoszeniu do zespołu pomocy brakuje kluczowych szczegółów, musimy poprosić Cię o więcej informacji. Może to wymagać wielokrotnych próśb o ponowne rozpatrzenie zgłoszenia. Zajmie to więcej czasu i może spowodować opóźnienia w rozwiązaniu problemów. Z tego przewodnika po sprawdzonych metodach dowiesz się, jakich informacji potrzebujemy, aby szybciej rozwiązać Twój problem techniczny.

opis problemu;

Zgłoszenie problemu powinno zawierać szczegółowe informacje o tym, co się stało, a co miało się stać, a także kiedy i jak to się stało. Dobre zgłoszenie do zespołu pomocy Apigee powinno zawierać te informacje o każdej usłudze Apigee:

Informacje o kluczu Opis Apigee Edge dla chmury publicznej Apigee Edge dla Private Cloud
Usługa Konkretna usługa Apigee, w której zaobserwowano problem, wraz z informacjami o wersji, jeśli ma to zastosowanie.
  • Wersja
Szczegóły problemu Jasny i szczegółowy opis problemu wraz z pełnym opisem błędu (jeśli występuje).
  • Komunikat o błędzie
  • Dane wyjściowe narzędzia do śledzenia
  • Kroki umożliwiające odtworzenie problemu
  • Kompletne żądanie/polecenie API
  • Komunikat o błędzie
  • Dane wyjściowe narzędzia do śledzenia
  • Kroki umożliwiające odtworzenie problemu
  • Kompletne żądanie/polecenie API
  • Dzienniki diagnostyczne komponentów
Czas Dokładna sygnatura czasowa, w której wystąpił problem 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 w miejscu, w którym zaobserwowano problem;
  • Nazwa organizacji
  • Nazwa środowiska
  • Nazwa serwera proxy interfejsu API
  • Wersja
  • Topologia sieci
  • Wadliwy komponent Edge

W poniższych sekcjach szczegółowo opisano te pojęcia.

Produkt

Istnieją różne usługi Apigee: Apigee Edge w chmurze publicznej i Apigee Edge w Private Cloud, dlatego potrzebujemy konkretnych informacji o tym, w której usłudze występuje problem.

W poniższej tabeli znajdziesz kilka przykładów pokazujących pełne informacje w kolumnie ZALECANE i niepełne informacje w kolumnie Działania, których nie należy:

DZIAŁANIA ZALECANE NIEZALECANE
Nie udało się wdrożyć serwera proxy interfejsu API OAuth2 w naszej organizacji Cloud Cloud ...

Nie udało się wdrożyć serwera 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 Edge Private Cloud w wersji 4.50.00 ...

Nie udało się zainstalować naszej konfiguracji Private Cloud.

(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 zaobserwowane zachowanie.

W tej tabeli znajdziesz kilka przykładów pokazujących pełne informacje w kolumnie ZALECANE i niepełne informacje w kolumnie Działania, których nie należy:

DZIAŁANIA ZALECANE NIEZALECANE

Na nowym serwerze proxy edgemicro_auth edgemicro występuje błąd i występuje ten błąd:

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

Nowy serwer proxy edgemicro nie działa dzisiaj

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

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

{"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 wskazanie błędów 500 nie dostarcza wystarczających informacji, które pozwoliłyby nam zbadać problem. Musimy znać rzeczywisty komunikat o błędzie i zaobserwowany kod błędu.

Godzina

Czas to bardzo ważna informacja. inżynier z zespołu pomocy powinien wiedzieć, kiedy problem został zauważony po raz pierwszy, jak długo występował i czy problem nadal występuje.

Inżynier pomocy zajmujący się problemem może nie znajdować się w Twojej strefie czasowej, dlatego względne informacje o czasie utrudniają zdiagnozowanie problemu. Dlatego zalecamy używanie formatu ISO 8601 w przypadku sygnatury czasowej, aby podać dokładną godzinę wystąpienia problemu.

W tabeli poniżej znajdziesz kilka przykładów dokładnego czasu i czasu, podczas którego wystąpił problem, w kolumnie DOTYCZĄCE, a w kolumnie Działania, których nie należy unikać zawierają niejednoznaczne lub niejasne informacje o tym, kiedy wystąpił problem:

DZIAŁANIA ZALECANE NIEZALECANE
Ogromną liczbę 503s zaobserwowano wczoraj między 17:30 czasu PDT 2020-11-06 a 17:35 czasu PDT 2020-11-06...

Ogromna liczba 503s zaobserwowano wczoraj o 17:30 przez 5 minut.

(musimy użyć domniemanej daty, a nie jest również jasne, w jakiej strefie czasowej występuje problem).

W następujących serwerach proxy interfejsu API zaobserwowano duże opóźnienia od 15:30 czasu IST do 18:10 czasu IST.

W zeszłym tygodniu w niektórych serwerach proxy interfejsu API zaobserwowano duże opóźnienia.

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

Konfiguracja

Musimy znać szczegółowe informacje o tym, gdzie dokładnie występuje problem. W zależności od tego, z której usługi korzystasz, potrzebujemy tych informacji:

  • Jeśli korzystasz z Apigee Cloud, być może masz więcej niż 1 organizację. Dlatego musimy znać konkretną organizację i inne informacje, w których występuje problem:
    • Nazwy organizacji i środowisk
    • Nazwa serwera proxy interfejsu API i numery wersji (w przypadku nieudanych żądań do interfejsu API)
  • Jeśli korzystasz z Private Cloud , być może korzystasz z jednej z wielu obsługiwanych topologii instalacji. Musimy więc wiedzieć, jakiej topologii używasz, w tym takich informacji jak liczba centrów danych i węzłów.

W tej tabeli znajdziesz kilka przykładów pokazujących pełne informacje w kolumnie ZALECANE i niepełne informacje w kolumnie Działania, których nie należy:

DZIAŁANIA ZALECANE NIEZALECANE

401 – liczba błędów w Edge Public Cloud od 06.11.2020 r.

Szczegóły konfiguracji Edge:

Szczegóły niedziałającego interfejsu API:
Nazwy organizacji: myorg
Nazwy środowiska: test
Nazwy 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"}}}

Wzrosła liczba błędów: 401.

Nie zawiera on żadnych informacji o używanej usłudze, ponieważ czas zaobserwowania problemu lub szczegóły konfiguracji.

Po dodaniu kolejnych węzłów bramy nie udało się uruchomić procesora wiadomości w Edge Private Cloud w wersji 4.19.06 .

Dzienniki diagnostyczne:
Załączono logi procesora wiadomości.

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

Po dodaniu kolejnych węzłów bramy nie udało się uruchomić procesora wiadomości w Edge Private Cloud w wersji 4.19.06 .

(Brak dzienników procesora wiadomości i topologii sieci).

Przydatne artefakty

Przesłanie nam artefaktów związanych z problemem przyspieszy jego rozwiązanie, ponieważ pomoże nam to lepiej zrozumieć zaobserwowane zachowanie i uzyskać więcej informacji na jego temat.

W tej sekcji opisano kilka przydatnych artefaktów dla wszystkich usług Apigee:

Typowe artefakty wszystkich usług Apigee

Te artefakty są przydatne we wszystkich usługach Apigee: Apigee Edge w chmurze publicznej i Apigee Edge w Private Cloud:

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

Dodatkowe artefakty dla Apigee Edge dla Private Cloud

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

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

Ten plik przydaje się do sprawdzania, czy wszystkie ustawienia są prawidłowe w przypadku problemów z instalacją lub migracją.

Zrzuty sterty Zrzuty sterty to zrzuty ekranu procesu pamięci Java. Jest to pomocne, jeśli w niektórych komponentach Edge zaobserwowano wysokie wykorzystanie pamięci lub błędy OutOfMemory.
Zrzuty wątków Zrzut wątku to zrzut wszystkich wątków uruchomionego procesu Java.

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

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

W tej sekcji znajdziesz szablony zgłoszeń i przykładowe przypadki dla różnych usług przygotowane na podstawie sprawdzonych metod opisanych w tym dokumencie:

Apigee Edge w chmurze publicznej

Szablon

W tej sekcji znajdziesz przykładowy szablon dla Apigee Edge w chmurze publicznej.

Problem:

<Podaj szczegółowy opis problemu lub zaobserwowanego zachowania. W razie potrzeby podaj nazwę i wersję produktu.>

Komunikat o błędzie:

<Podaj pełny zaobserwowany komunikat o błędzie (jeśli występuje)>

Czas rozpoczęcia problemu (w formacie ISO 8601):

Czas zakończenia problemu (w formacie ISO 8601):

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

Kroki umożliwiające odtworzenie problemu:

<W miarę możliwości podaj czynności prowadzące do pojawienia się błędu>

Informacje diagnostyczne:

<Lista załączonych plików>

Przykładowe zgłoszenie

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

Problem:

W naszej organizacji Public Cloud obserwujemy dużą liczbę błędów 503 (Service Niedostępne). Czy możesz zbadać ten problem i go rozwiązać lub doradzić, jak go rozwiązać?

Komunikat o błędzie:

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

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

Czas zakończenia problemu (w formacie ISO 8601): problem nadal występuje.

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

Kroki umożliwiające odtworzenie problemu:

Uruchom to polecenie curl, aby odtworzyć problem:

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

Informacje diagnostyczne:

Dane wyjściowe narzędzia do śledzenia (trace-503.xml)

Apigee Edge dla Private Cloud

Szablon

W tej sekcji znajdziesz przykładowy szablon dla Apigee Edge dla Private Cloud.

Problem:

<Podaj szczegółowy opis problemu lub zaobserwowanego zachowania. W razie potrzeby podaj nazwę i wersję produktu.>

Komunikat o błędzie:

<Podaj pełny zaobserwowany komunikat o błędzie (jeśli występuje)>

Czas rozpoczęcia problemu (w formacie ISO 8601):

Czas zakończenia problemu (w formacie ISO 8601):

Szczegóły konfiguracji Edge Private Cloud:

<Dołącz topologię sieci z opisem konfiguracji chmury prywatnej, w tym centrów danych i węzłów>

Kroki umożliwiające odtworzenie problemu:

<W miarę możliwości podaj czynności prowadzące do pojawienia się błędu>

Informacje diagnostyczne

<Lista załączonych plików>

Przykładowe zgłoszenie

W tej sekcji znajdziesz przykładowy przypadek użycia Apigee Edge w chmurze prywatnej.

Problem:

Podczas instalowania serwera Apigee Management Server w węźle 10 w ramach środowiska Edge Private Cloud 4.19.06 w systemie Linux RHEL 7.6, występuje następujący 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 (w formacie ISO 8601): pojawia się przy każdej instalacji.

Czas zakończenia problemu(w formacie ISO 8601): nie dotyczy.

Szczegóły konfiguracji Edge Private Cloud:

Załączono plik network-topology.png

Kroki umożliwiające odtworzenie problemu:

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łączono te pliki:

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