Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.
Raporty niestandardowe umożliwiają bardziej szczegółowe analizowanie konkretnych wskaźników interfejsu API i wyświetlanie dokładnych danych, które Cię interesują. W panelach monitorowania interfejsu API możesz utworzyć raport niestandardowy z gotowymi ustawieniami filtra i wskaźników na podstawie skonfigurowanych warunków w czasie tworzenia. Dodatkowo w raporcie zostanie skonfigurowany zestaw domyślnych wymiarów i danych.
Utwórz raport niestandardowy na podstawie kontekstu
Szybko twórz raporty niestandardowe na podstawie kontekstu zgodnie z podsumowaniem w tabeli poniżej. Na stronie Raporty niestandardowe raporty niestandardowe, które są tworzone za pomocą monitorowania interfejsu API, domyślnie mają unikalne nazwy, które można wpisać w tabeli. Podczas edytowania raportu niestandardowego możesz zmienić jego nazwę.
Kontekst raportu niestandardowego | Domyślna konwencja nazewnictwa raportów niestandardowych |
---|---|
Ostatni panel | API Monitoring Recent Generated |
Panel osi czasu | API Monitoring Timeline Generated |
Panel analizy | API Monitoring Investigate Generated |
Stan alertu | API Monitoring Generated: alert-name |
Wymiar domyślny i dane
Raport niestandardowy będzie domyślnie zawierał wymiary i dane wymienione w tabeli poniżej dotyczące wszystkich raportów generowanych za pomocą interfejsu API Monitoring.
Komponent | Domyślne |
---|---|
Wymiary | Identyfikator URI żądania |
Dane |
|
Edytowanie raportu niestandardowego
Jak wspomnieliśmy w poprzedniej sekcji, w raportach niestandardowych wstępnie skonfigurowano domyślne wymiary i dane interfejsu API Monitoring. Po utworzeniu raportu możesz go edytować, aby dodać lub usunąć dane i wymiary. Na przykład możesz zawęzić zakres analizy do konkretnego tokena dostępu, aplikacji programisty, serwera proxy interfejsu API lub identyfikatora żądania.
W poniższym raporcie niestandardowym dodajesz wstępnie zdefiniowany wymiar Gateway Flow ID
, w którym Gateway Flow ID
zawiera unikalny identyfikator UUID każdego żądania do interfejsu API wysyłanego do Edge.
Pamiętaj, że raport korzysta już z wymiaru Request URI
:
Poniższy przykład dodaje wymiar Client ID
do raportu niestandardowego.
Wymiar Client ID
zawiera klucz klienta (klucz interfejsu API) dewelopera wywołującego interfejs API, niezależnie od tego, czy jest on przekazywany w żądaniu jako klucz interfejsu API czy zawarty w tokenu OAuth:
Raport niestandardowy zawiera informacje dotyczące wszystkich wartości parametru Client ID
.
W następnym przykładzie dodaliśmy filtr, dzięki któremu możesz utworzyć raport niestandardowy dotyczący określonego klienta (Client ID
):
Więcej informacji o wszystkich wstępnie zdefiniowanych wymiarach i danych, które możesz dodać do raportu, znajdziesz w artykule Dane, wymiary i filtry Analytics.
W następnym przykładzie dodasz do raportu niestandardowego filtr, który będzie zbierać domyślne dane i wymiary kodów błędów policies.ratelimit.QuotaViolation
i kodów stanu 5xx:
Szczegółowe informacje o edytowaniu raportu niestandardowego znajdziesz w artykule Zarządzanie raportami niestandardowymi.
Przykład: korzystanie z raportów niestandardowych do diagnozowania problemów z wdrażaniem
Dołącz do zasad serwera proxy API zasady CollectCollect, aby zbierać niestandardowe dane statystyczne, 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 określonych przez Apigee, nagłówków żądań, parametrów zapytania i zdefiniowanych przez Ciebie zmiennych niestandardowych.
Na przykład żądania wysyłane do serwera proxy interfejsu API zawierają nagłówki identyfikatora produktu, identyfikatora użytkownika i wersji serwera docelowego. Żądanie może mieć postać:
curl -H "prodid:123456" -H "userid:98765" -H "targetversion:beta" http://myapi.com/myapi
Możesz skorzystać z informacji w nagłówkach, aby zdiagnozować problemy z czasem działania serwera proxy interfejsu API.
Aby utworzyć raport niestandardowy dla tych nagłówków:
Dodaj do interfejsu API zasady CollectionCollector, by rejestrować wartość nagłówków niestandardowych:
<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.
Aby wyświetlić problemy z interfejsem API, w interfejsie Edge kliknij Analyze > API Monitoring > Ostatni. Zwróć uwagę, że w przypadku serwera proxy myapi występują błędy 4xx i 5xx:
Wybierz wiersz proxy myapi, aby wyświetlić więcej szczegółów w panelu po prawej stronie panelu Ostatnie.
Aby uzyskać dostęp do panelu analizy, w prawym panelu panelu Ostatnie kliknij
> Wyświetl w narzędziu Zbadaj:
Przefiltruj panel Analiza na podstawie serwera proxy myapi, a następnie wyświetl Kod stanu na górnym wykresie. Zwróć uwagę na błędy 403 i 501:
W interfejsie użytkownika Edge wybierz kolejno Analytics > Raporty niestandardowe > Raporty, by utworzyć raport niestandardowy, który zawiera wartości tych danych niestandardowych jako wymiar.
Kliknij + Raport niestandardowy, aby utworzyć raport niestandardowy o nazwie myapi_errors.
Wybierz Błędy serwera proxy dla wskaźnika, a w funkcji zbiorczejustaw wartość Suma. Jeśli chcesz, możesz dodać więcej danych.
Wybierz wstępnie zdefiniowany wymiar Kod stanu odpowiedzi, a potem dodaj do wymiarów 3 statystyki niestandardowe: prodid, targetersion i userid:
Ustaw filtr tak, aby uwzględniał tylko dane dotyczące serwera proxy myapiAPI
(apiproxy eq 'myapi')
:Zapisz raport.
Wygeneruj raport z ostatnich 24 godzin. Przy pierwszym otwarciu raportu zobaczysz wykres błędów HTTP 403 i 501:
W sekcji Podsumowanie kliknij 403 lub 510, by sprawdzić, który produkt generuje błędy. Na przykład wybierzesz 403:
Kliknij identyfikator produktu w sekcji Podsumowanie, aby wyświetlić błędy według wersji docelowej (alfa lub beta):
Kliknij wersję docelową w sekcji Podsumowanie, aby wyświetlić błędy według użytkownika: