Wyświetlasz dokumentację Apigee Edge.
Przejdź do
dokumentacji Apigee X. info
Edge API Analytics to bardzo zaawansowana funkcja wbudowana w Apigee Edge. Zbiera i analizuje szeroki zakres danych przepływających przez interfejsy API. Przechwycone dane analityczne mogą dostarczyć bardzo przydatnych informacji. Na przykład: jak zmienia się w czasie natężenie ruchu przez interfejsy API? Który interfejs API jest najczęściej używany? Które interfejsy API mają wysoki współczynnik błędów?
Regularna analiza tych danych i informacji może posłużyć do podejmowania odpowiednich działań, takich jak przyszłe planowanie przepustowości interfejsów API na podstawie bieżącego wykorzystania, decyzji biznesowych i przyszłych inwestycji, oraz wielu innych.
Dane analityczne i ich przechowywanie
API Analytics rejestruje wiele różnych typów danych, takich jak:
- informacje o interfejsie API – identyfikator URI żądania, adres IP klienta, kody stanu odpowiedzi itp.;
- wydajność serwera proxy interfejsu API – współczynnik powodzenia/niepowodzenia, czas przetwarzania żądania i odpowiedzi itp.;
- wydajność serwera docelowego – współczynnik powodzenia/niepowodzenia, czas przetwarzania;
- informacje o błędach – liczba błędów, kod błędu, zasada powodująca błąd, liczba błędów spowodowanych przez Apigee i serwer docelowy spowodowane błędy;
- inne informacje – liczba żądań wysyłanych przez deweloperów, aplikacje deweloperów itp.
Wszystkie te dane są przechowywane w analytics schemacie utworzonym i zarządzanym w
bazie danych Postgres przez Apigee Edge.
Zwykle w czystej instalacji Edge Postgres będzie mieć te schematy:
Schemat o nazwie analytics jest używany przez Edge do przechowywania wszystkich danych analitycznych dla
każdej organizacji i środowiska. Jeśli zainstalowana jest monetyzacja, będzie dostępny schemat rkms. Pozostałe schematy są przeznaczone do użytku wewnętrznego Postgres.
Schemat analytics będzie się zmieniać, ponieważ Apigee Edge będzie dynamicznie dodawać do niego nowe tabele faktów
w czasie działania. Komponent serwera Postgres będzie agregować dane faktów w tabele zbiorcze
, które są wczytywane i wyświetlane w interfejsie Edge.
Antywzorzec
Dodawanie niestandardowych kolumn, tabel lub widoków do dowolnego schematu należącego do Apigee w bazie danych Postgres w środowiskach Private Cloud bezpośrednio za pomocą zapytań SQL jest niewskazane, ponieważ może mieć negatywne konsekwencje.
Aby to szczegółowo wyjaśnić, rozważmy ten przykład.
Załóżmy, że w schemacie analitycznym została utworzona niestandardowa tabela o nazwie account, jak
pokazano poniżej:
Po pewnym czasie może się okazać, że trzeba zaktualizować Apigee Edge z niższej wersji do wyższej wersji. Aktualizacja Apigee Edge w Private Cloud obejmuje aktualizację Postgres i wielu innych komponentów. Jeśli do bazy danych Postgres dodano niestandardowe kolumny, tabele lub widoki, aktualizacja Postgres nie powiedzie się i wyświetli błędy odwołujące się do obiektów niestandardowych, ponieważ nie zostały one utworzone przez Apigee Edge. W związku z tym aktualizacja Apigee Edge też się nie powiedzie i nie będzie można jej ukończyć.
Podobne błędy mogą wystąpić podczas czynności konserwacyjnych Apigee Edge, w których wykonywane są kopie zapasowe i przywracanie komponentów Edge, w tym bazy danych Postgres.
Wpływ
- Nie można ukończyć aktualizacji Apigee Edge, ponieważ aktualizacja komponentu Postgres nie powiedzie się i wyświetli błędy odwołujące się do obiektów niestandardowych, które nie zostały utworzone przez Apigee Edge.
- Niespójności (i błędy) podczas wykonywania konserwacji usługi Apigee Analytics (tworzenie kopii zapasowej lub przywracanie).
Sprawdzona metoda
- Nie dodawaj żadnych informacji niestandardowych w postaci kolumn, tabel, widoków, funkcji i
procedur bezpośrednio do żadnego schematu należącego do Apigee, np.
analytics. - Jeśli trzeba obsługiwać informacje niestandardowe, można je dodać jako kolumny (pola) za pomocą
zasady zbierania statystyk do
analyticsschematu.