Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Raporty niestandardowe umożliwiają zgłębianie konkretnych danych interfejsu API i wyświetlanie dokładnych informacji, które Cię interesują. Z paneli monitorowania interfejsu API możesz utworzyć raport niestandardowy z gotowymi ustawieniami filtrów i danych na podstawie warunków skonfigurowanych w momencie tworzenia. Poza tym raport musi skonfigurować za Ciebie zestaw domyślnych wymiarów i danych.
Tworzenie raportu niestandardowego na podstawie kontekstu
Możesz szybko tworzyć raporty niestandardowe na podstawie kontekstu, co podsumowaliśmy w tabeli poniżej. Na stronie Raporty niestandardowe raporty niestandardowe utworzone za pomocą interfejsu API Monitoring domyślnie mają niepowtarzalne nazwy (zgodnie z tabelą). Możesz je zmienić podczas edytowania raportu niestandardowego.
| Kontekst raportu niestandardowego | Domyślna konwencja nazewnictwa raportów niestandardowych |
|---|---|
| Ostatni panel | API Monitoring Recent Generated |
| Panel osi czasu | API Monitoring Timeline Generated |
| Sprawdź panel | API Monitoring Investigate Generated |
| Warunek alertu | API Monitoring Generated: alert-name |
Domyślny wymiar i dane
Raport niestandardowy będzie domyślnie zawierał wymiary i dane wymienione w poniższej tabeli w przypadku wszystkich raportów generowanych za pomocą interfejsu API Monitoring.
| Komponent | Domyślne |
|---|---|
| Wymiary | Identyfikator URI żądania |
| Wskaźniki |
|
Edytowanie raportu niestandardowego
Jak wspomnieliśmy w poprzedniej sekcji, w raportach niestandardowych jest wstępnie skonfigurowany zdefiniowany wstępnie zestaw domyślnych wymiarów i danych usługi API Monitoring. Po utworzeniu raportu niestandardowego możesz go edytować, aby w razie potrzeby dodawać lub usuwać dane i wymiary. Możesz na przykład zawęzić analizę zagrożeń do konkretnego tokena dostępu, aplikacji dewelopera, serwera proxy interfejsu API lub identyfikatora żądania.
W poniższym raporcie niestandardowym dodajesz wstępnie zdefiniowany wymiar Gateway Flow ID, gdzie Gateway Flow ID zawiera unikalny identyfikator UUID każdego żądania do interfejsu API wysłanego do Edge.
Pamiętaj, że raport używa już wymiaru Request URI:
Poniższy przykład pokazuje dodanie do raportu niestandardowego wymiaru Client ID.
Wymiar Client ID zawiera klucz klienta (klucz interfejsu API) dewelopera wywołującego interfejs API niezależnie od tego, czy jest przekazywany w żądaniu jako klucz interfejsu API czy zawarty w tokenie OAuth:
Raport niestandardowy zawiera informacje o wszystkich wartościach Client ID.
W kolejnym przykładzie dodano filtr, dzięki któremu możesz utworzyć raport niestandardowy dla określonego elementu Client ID:
Więcej informacji o wszystkich wstępnie zdefiniowanych wymiarach i danych, które możesz dodać do raportu, znajdziesz w artykule Informacje o danych, wymiarach i filtrach Analytics.
W następnym przykładzie dodasz filtr do raportu niestandardowego, który rejestruje domyślne dane i wymiary kodu błędu policies.ratelimit.QuotaViolation i kodów stanu 5xx:
Szczegółowe informacje o edytowaniu raportu niestandardowego znajdziesz w artykule Zarządzanie raportami niestandardowymi.
Przykład: używanie raportów niestandardowych do diagnozowania problemów z wdrażaniem
Dołącz zasadę StatisticsCollector do serwerów proxy interfejsu API, aby zbierać niestandardowe dane analityczne, takie jak identyfikator użytkownika lub produktu, cena, działanie REST, wersja docelowa, docelowy adres URL i długość wiadomości. Dane mogą pochodzić ze zmiennych przepływu wstępnie zdefiniowanych przez Apigee, nagłówków żądań, parametrów zapytań lub zmiennych niestandardowych zdefiniowanych przez Ciebie.
Na przykład żądania wysyłane do serwera proxy interfejsu API zawierają nagłówki identyfikatora produktu, identyfikatora użytkownika i wersji serwera docelowego. Prośba może mieć postać:
curl -H "prodid:123456" -H "userid:98765" -H "targetversion:beta" http://myapi.com/myapi
Informacje z nagłówków mogą pomóc w zdiagnozowaniu problemów w czasie działania serwera proxy interfejsu API.
Aby utworzyć raport niestandardowy dla tych nagłówków:
Dodaj do interfejsu API zasadę StatisticsCollector, aby przechwytywać wartości niestandardowych nagłówków:
<StatisticsCollector name="publishPurchaseDetails"> <Statistics> <Statistic name="prodid" ref="request.header.prodid" type="integer">0</Statistic> <Statistic name="userid" ref="request.header.userid" type="integer">0</Statistic> <Statistic name="targetversion" ref="request.header.targetversion" type="string">alpha</Statistic> </Statistics> </StatisticsCollector>
Wdróż serwer proxy i poczekaj na dostęp do niego.
W interfejsie użytkownika Edge kliknij Analiza > Monitorowanie interfejsów API > Ostatnie, aby wyświetlić problemy z interfejsem API. Zwróć uwagę, że w przypadku serwera proxy myapi występują błędy 4xx i 5xx:
Wybierz wiersz serwera proxy myapi, aby wyświetlić więcej szczegółów w prawym okienku panelu Ostatnie.
W prawym okienku panelu Ostatnie kliknij
> Wyświetl w narzędziu Zbadaj, aby uzyskać dostęp do panelu Zbadaj:
Przefiltruj panel według serwera proxy myapi, a następnie wyświetl Kod stanu na wykresie u góry. Zwróć uwagę, że wyświetlają się błędy 403 i 501:
W interfejsie użytkownika Edge wybierz Analytics > Raporty niestandardowe > Raporty, aby utworzyć raport niestandardowy, który będzie zawierał wartości tych danych niestandardowych jako wymiar.
Kliknij + Raport niestandardowy, aby utworzyć raport niestandardowy o nazwie myapi_errors.
Jako wskaźnik wybierz Błędy serwera proxy, a w polu Funkcja agregująca wybierz Suma. Jeśli chcesz, możesz dodać więcej danych.
Wybierz wstępnie zdefiniowany wymiar Kod stanu odpowiedzi, a następnie dodaj do wymiarów 3 statystyki niestandardowe prodid, targetersion i userid:
Ustaw filtr tak, aby uwzględniał tylko dane dla serwera proxy myapiinterfejsu API
(apiproxy eq 'myapi'):
Zapisz raport.
Wygeneruj raport za ostatnie 24 godziny. Po pierwszym otwarciu raportu zobaczysz wykres błędów HTTP 403 i 501:
W sekcji Podsumowanie kliknij 403 lub 510, aby sprawdzić, który produkt generuje błędy. np. 403:
Kliknij identyfikator produktu w sekcji Podsumowanie, aby wyświetlić błędy według wersji docelowej (alfa lub beta):
Aby wyświetlić błędy według użytkowników, kliknij wersję docelową w sekcji Podsumowanie:
