Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Ten temat zawiera informacje o danych, wymiarach i filtrach Analytics. Więcej informacji o używaniu ich znajdziesz w omówieniu interfejsów API Analytics.
W tym temacie przedstawiamy nazwy danych i wymiarów w takiej postaci, w jakiej pojawiają się w interfejsie użytkownika oraz jak trzeba używać ich w wywołaniach interfejsu API.
- Nazwy użytkowników pojawiają się podczas tworzenia raportów niestandardowych.
- Używaj nazw interfejsów API podczas pobierania wskaźników, tworzenia definicji raportu lub aktualizowania definicji raportu.
Wskaźniki
Poniżej znajdziesz dane interfejsu API, które możesz pobierać w raportach niestandardowych i wywołaniach interfejsu API zarządzania.
Nazwa raportów niestandardowych | Nazwa, która ma być używana w interfejsie API zarządzania | Funkcje | Opis |
---|---|---|---|
Średnia liczba transakcji na sekundę | tps | Brak |
Średnia liczba transakcji, czyli żądań serwera proxy API na sekundę. Pamiętaj, że jeśli masz stosunkowo małą liczbę transakcji w danym okresie, średnia liczba transakcji na sekundę może wydawać się zerowa w raportach niestandardowych interfejsu, jeśli jest ona mniejsza niż 2 miejsca po przecinku. Składnia interfejsu API: |
Trafienie w pamięci podręcznej | cache_hit | suma |
Liczba udanych żądań do interfejsu API, które korzystają z pamięci podręcznej odpowiedzi zamiast odpowiedzi z usługi docelowej. Składnia interfejsu API: |
Liczba elementów pamięci podręcznej L1 | ax_cache_l1_count | śr, min, maksymalna |
Zwraca liczbę elementów w pamięci podręcznej L1 (w pamięci) na transakcję w danym okresie. Jeśli np. wybierzesz Składnia interfejsu API: |
Błędy związane z zasadami | policy_error | suma |
Łączna liczba błędów związanych z naruszeniem zasad w wybranym okresie. Błędy związane z zasadami zwykle występują z założenia. Na przykład zasada Weryfikacja klucza interfejsu API zgłasza błąd, gdy w żądaniu zostanie przekazany nieprawidłowy klucz interfejsu API, a zasada Spike Arrest zwraca błąd, jeśli liczba wywołań interfejsu API przekracza limit określony w zasadzie. Ten wskaźnik jest więc przydatny do znajdowania potencjalnych problemów w interfejsach API. Na przykład dane policy_error pogrupowane według wymiaru developer_app mogą pomóc ustalić, czy dla danej aplikacji wygasł klucz interfejsu API lub token protokołu OAuth. Może się też okazać, że określony serwer proxy interfejsu API generuje dużo błędów dotyczących zatrzymania Spike’a, co prowadzi do odkrycia, że nagły limit miejsca na serwerze proxy nie odpowiada zwiększonemu ruchowi w okresie świątecznym. Błąd zasad jest rejestrowany w Analytics tylko wtedy, gdy powoduje on błąd serwera proxy interfejsu API.
Jeśli na przykład atrybut Wymiar Nazwa zasady w przypadku błędu (ax_execution_fault_policy_name) jest przydatny do grupowania błędów zasad według nazwy. Niepowodzenie w przypadku celu (np. 404 lub 503) nie jest liczone jako błąd zasady. Są one liczone jako błędy serwera proxy interfejsu API (is_error). Składnia interfejsu API: |
Błędy serwera proxy | is_error | suma |
Łączna liczba awarii serwerów proxy API w określonym przedziale czasu. Awaria serwera proxy może wystąpić w przypadku błędu zasady lub awarii środowiska wykonawczego, na przykład błędu 404 lub 503 z usługi docelowej. Wymiar Serwer proxy (apiproxy) przydaje się do grupowania błędów interfejsu API według serwera proxy. Składnia interfejsu API: |
Opóźnienie przetwarzania żądań | request_processing_latency | śr, min, maksymalna |
Wyrażony w milisekundach czas (średni, minimalny lub maksymalny) potrzebny aplikacji Edge do przetworzenia żądań przychodzących. Czas zaczyna się, gdy żądanie dociera do brzegu, i kończy, gdy Edge przekaże je do usługi docelowej. Za pomocą różnych wymiarów możesz przeanalizować opóźnienia przetwarzania żądań według serwera proxy interfejsu API, aplikacji dewelopera, regionu itd. Składnia interfejsu API: |
Rozmiar prośby | request_size | suma, śr, min, maksymalna |
Rozmiar ładunku żądania odebranego przez Edge (w bajtach). Składnia interfejsu API: |
Pamięć podręczna odpowiedzi została wykonana | ax_cache_executed | suma |
Łączna liczba uruchomień zasady pamięci podręcznej odpowiedzi w danym okresie. Ponieważ zasada buforowania odpowiedzi jest połączona w 2 miejscach na serwerze proxy interfejsu API (raz w żądaniu i raz w odpowiedzi), zwykle jest wykonywana 2 razy w wywołaniu interfejsu API. Wartości „get” w pamięci podręcznej i „put” w pamięci podręcznej są liczone jako jedno wykonanie. Wykonanie pamięci podręcznej odpowiedzi ma jednak wartość 0, jeśli element W narzędziu śledzenia możesz kliknąć ikonę pamięci podręcznej odpowiedzi w wykonanym wywołaniu interfejsu API i wyświetlić zmienną przepływu Składnia interfejsu API: |
Opóźnienie przetwarzania odpowiedzi | response_processing_latency | śr, min, maksymalna |
Wyrażony w milisekundach czas (średni, minimalny lub maksymalny) potrzebny aplikacji Edge do przetworzenia odpowiedzi interfejsu API. Czas zaczyna się, gdy serwer proxy interfejsu API otrzyma odpowiedź usługi docelowej, i kończy, gdy Apigee przekaże odpowiedź do pierwotnego elementu wywołującego. Za pomocą różnych wymiarów możesz zbadać opóźnienia przetwarzania odpowiedzi według serwera proxy interfejsu API, regionu itd. Składnia interfejsu API: |
Rozmiar odpowiedzi | response_size | suma, śr, min, maksymalna |
Rozmiar ładunku odpowiedzi zwróconego klientowi (w bajtach). Składnia interfejsu API: |
Błędy docelowe | target_error | suma |
Łączna liczba odpowiedzi 5xx z usługi docelowej. Są to błędy usługi docelowej, które nie zostały spowodowane przez Apigee. Składnia interfejsu API: |
Docelowy czas reakcji | target_response_time | suma, śr, min, maksymalna |
Czas (suma, średni, minimalny lub maksymalny) wyrażony w milisekundach, przez jaki serwer docelowy odpowiada na wywołanie. Ten wskaźnik informuje o wydajności serwerów docelowych. Czas zaczyna się, gdy Edge przekazuje żądanie do usługi docelowej, a kończy się, gdy Edge otrzyma odpowiedź. Pamiętaj, że jeśli wywołanie interfejsu API zwróci odpowiedź z pamięci podręcznej (np. z użyciem zasady pamięci podręcznej odpowiedzi), nie dotrze ono do usługi docelowej i nie zostaną zarejestrowane żadne wskaźniki czasu docelowej odpowiedzi. Składnia interfejsu API: |
Całkowity czas odpowiedzi | total_response_time | suma, śr, min, maksymalna |
Czas (suma, średni, minimalny lub maksymalny) w milisekundach od otrzymania żądania od klienta do momentu, gdy Edge wysyła odpowiedź do klienta. Czas uwzględnia narzut sieci (np. czas potrzebny na wykonywanie zadań przez systemy równoważenia obciążenia i routery), czas oczekiwania na przetwarzanie żądań, czas oczekiwania na przetwarzanie odpowiedzi oraz docelowy czas odpowiedzi (jeśli odpowiedź jest dostarczana z usługi docelowej, a nie z pamięci podręcznej). Za pomocą różnych wymiarów możesz analizować opóźnienia przetwarzania według serwera proxy interfejsu API, aplikacji dewelopera, regionu itd. Składnia interfejsu API: |
natężenie ruchu drogowego, | message_count | suma |
Łączna liczba wywołań interfejsu API przetworzonych przez Edge w określonym czasie. Używaj wymiarów do grupowania liczby wizyt w najbardziej odpowiedni dla Ciebie sposób. Składnia interfejsu API: |
Wymiary
Wymiary umożliwiają wyświetlanie danych w grupach. Na przykład wyświetlanie łącznej liczby ruchu staje się znacznie bardziej efektywne, gdy wyświetlasz je dla każdej aplikacji dewelopera lub serwera proxy interfejsu API.
Poniżej znajdziesz wymiary oferowane przez Apigee w pakiecie. Możesz też utworzyć własne wymiary, jak opisano w artykule Analizowanie treści wiadomości w interfejsie API przy użyciu statystyk niestandardowych.
Nazwa raportów niestandardowych | Nazwa, która ma być używana w interfejsie API zarządzania | Opis |
---|---|---|
Encje Apigee | ||
Token dostępu | access_token | Token dostępu protokołu OAuth użytkownika aplikacji. |
Usługa API | api_product |
Nazwa usługi API zawierającej wywoływane serwery proxy API. Aby można było uzyskać ten wymiar, aplikacje deweloperów wykonujące wywołania muszą być powiązane z co najmniej jedną usługą API, która zawiera serwery proxy interfejsu API, a wywoływane serwery proxy muszą sprawdzać klucz interfejsu API lub token OAuth wysłany przy użyciu wywołania interfejsu API. Klucz lub token są powiązane z usługą API. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne. Jeśli powyższe kryteria nie są spełnione, wyświetlana jest wartość „(nie ustawiono)”. Przeczytaj też: Co oznacza wartość elementu Analytics „(nie ustawiono)”? |
Klucz pamięci podręcznej | ax_cache_key |
Klucz zawierający wartość pamięci podręcznej odpowiedzi, do której uzyskano dostęp. Więcej informacji o konstrukcji klucza na potrzeby pamięci podręcznej odpowiedzi znajdziesz w artykule Zasady buforowania odpowiedzi. Jeśli w narzędziu śledzenia wybierzesz zasadę pamięci podręcznej odpowiedzi, która odczytuje dane z pamięci podręcznej lub zapisuje je w pamięci podręcznej, zobaczysz tę wartość w zmiennej przepływu |
Nazwa pamięci podręcznej | ax_cache_name |
Nazwa pamięci podręcznej zawierającej klucze/wartości używane przez zasadę pamięci podręcznej odpowiedzi, poprzedzona ciągiem orgName__envName__. Jeśli na przykład organizacja to „foo”, środowisko to „test”, a nazwa pamięci podręcznej to „myCache”, wartość ax_cache_name to foo__test__myCache. Jeśli w narzędziu śledzenia wybierzesz zasadę buforowania odpowiedzi, zobaczysz tę wartość w zmiennej przepływu |
Źródło pamięci podręcznej | ax_cache_source |
Poziom pamięci podręcznej („L1” w pamięci lub baza danych „L2”), z którego została pobrana pamięć podręczna odpowiedzi. Ten wymiar pokazuje też wartość „CACHE_MISS”, gdy odpowiedź została dostarczona ze środowiska docelowego, a nie z pamięci podręcznej (a pamięć podręczna odpowiedzi została odświeżona za pomocą odpowiedzi docelowej) lub gdy klucz pamięci podręcznej w żądaniu jest nieprawidłowy. Rozmiar klucza pamięci podręcznej nie może przekraczać 2 KB. W narzędziu śledzenia po wybraniu zasady buforowania odpowiedzi zobaczysz tę wartość w zmiennej przepływu Więcej informacji o poziomach pamięci podręcznej znajdziesz w artykule Informacje o pamięci wewnętrznej. |
Identyfikator klienta | client_id |
Klucz klienta (klucz interfejsu API) aplikacji dewelopera wykonującej wywołania interfejsu API, niezależnie od tego, czy jest przekazywany w żądaniu jako klucze interfejsu API czy zawarty w tokenach OAuth. Aby uzyskać ten wymiar, serwer proxy odbierający wywołania musi być skonfigurowany tak, aby sprawdzał, czy ma prawidłowy klucz interfejsu API lub token OAuth. Aplikacje deweloperskie otrzymują klucze interfejsu API, które można wykorzystać do generowania tokenów OAuth, gdy aplikacje są zarejestrowane w Edge. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne. Jeśli powyższe kryteria nie są spełnione, wyświetlana jest wartość „(nie ustawiono)”. Przeczytaj też artykuł Co oznacza wartość elementu Analytics „(nie ustawiono)”? |
Aplikacja dewelopera | developer_app |
Zarejestrowana w Edge aplikacja deweloperska wykonująca wywołania interfejsu API. Aby można było uzyskać ten wymiar, aplikacje muszą być powiązane z co najmniej jedną usługą API, która zawiera wywoływane serwery proxy interfejsu API, a serwery proxy muszą sprawdzić klucz interfejsu API lub token OAuth wysłany przez wywołanie interfejsu API. Klucz lub token identyfikuje aplikację dewelopera. Więcej informacji znajdziesz w sekcji Pierwsze kroki: jak generować pełne dane Analytics. Jeśli powyższe kryteria nie są spełnione, wyświetlana jest wartość „(nie ustawiono)”. Przeczytaj też artykuł Co oznacza wartość elementu Analytics „(nie ustawiono)”? |
Adres e-mail dewelopera | developer_email |
Adres e-mail deweloperów zarejestrowanych w Edge, których aplikacja wywołała interfejs API. Aby uzyskać ten wymiar, deweloperzy muszą mieć aplikacje powiązane z co najmniej jedną usługą API, która zawiera wywoływane serwery proxy interfejsu API, a serwery proxy muszą sprawdzić klucz interfejsu API lub token OAuth wysłany przy użyciu wywołania interfejsu API. Klucz lub token identyfikuje aplikację dewelopera. Więcej informacji znajdziesz w sekcji Pierwsze kroki: jak generować pełne dane Analytics. Jeśli powyższe kryteria nie są spełnione, wyświetlana jest wartość „(nie ustawiono)”. Przeczytaj też artykuł Co oznacza wartość elementu Analytics „(nie ustawiono)”? |
Identyfikator dewelopera | programista |
Unikalny identyfikator dewelopera wygenerowany na brzegu sieci, w formacie org_name@@@org_name. Aby uzyskać ten wymiar, deweloperzy muszą mieć aplikacje powiązane z co najmniej jedną usługą API zawierającą wywoływane serwery proxy interfejsu API, a serwery proxy muszą sprawdzić klucz interfejsu API lub token OAuth wysłany z wywołaniami interfejsu API. Klucz lub token identyfikuje dewelopera. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne. Jeśli powyższe kryteria nie są spełnione, wyświetlana jest wartość „(nie ustawiono)”. Przeczytaj też artykuł Co oznacza wartość elementu Analytics „(nie ustawiono)”? |
Środowisko | środowisko | Środowisko brzegowe, w którym są wdrożone serwery proxy interfejsów API. Na przykład „test” lub „prod”. |
Kod błędu w przypadku błędu | ax_edge_execution_fault_code |
Kod błędu. Przykład:
|
Nazwa przepływu w przypadku błędu | ax_execution_fault _flow_name |
Nazwa flow w serwerze proxy interfejsu API, która zgłosiła błąd. Na przykład „PreFlow”, „PostFlow” lub nazwa utworzonego przepływu warunkowego. Pamiętaj, że pełna nazwa do użycia w interfejsie Management API to ax_execution_fault_flow_name, bez podziału wiersza. Jeśli nie wystąpiły żadne błędy, widoczna będzie wartość „(nie ustawiono)”. |
Zasób przepływu | flow_resource | Tylko do użytku z Apigee. Jeśli chcesz dowiedzieć się więcej, przeczytaj tego posta na karcie Społeczność. |
Błąd stanu przepływu | ax_execution_fault _flow_state |
Nazwa przepływu serwera proxy interfejsu API informuje o błędach, takich jak „PROXY_REQ_FLOW” lub „TARGET_RESP_FLOW”. Pamiętaj, że pełna nazwa do użycia w interfejsie Management API to ax_execution_fault_flow_state, bez podziału wiersza. |
Identyfikator przepływu bramy | gateway_flow_id | Gdy wywołania interfejsu API przechodzą przez Edge, każde wywołanie otrzymuje własny identyfikator przepływu bramy. Przykład: rrt329ea-12575-114653952-1. Identyfikator przepływu bramy przydaje się do rozróżniania wskaźników w sytuacjach o dużej liczbie TPS, gdy inne wymiary, takie jak organizacja, środowisko i sygnatura czasowa, są identyczne w wielu wywołaniach. |
Organizacja | organizacja | Organizacja brzegowa, w której są wdrożone serwery proxy interfejsów API. |
Nazwa zasady w przypadku błędu | ax_execution_fault _policy_name |
Nazwa zasady, która zwróciła błąd i spowodował niepowodzenie wywołania interfejsu API. Pamiętaj, że pełna nazwa do użycia w interfejsie Management API to ax_execution_fault_policy_name, bez podziału wiersza. Jeśli zasada spowoduje zgłoszenie błędu, ale główny atrybut zasady |
Proxy (Serwer proxy) | apiproxy | Nazwa komputera (nie wyświetlana nazwa) serwera proxy interfejsu API. |
Ścieżka podstawowa serwera proxy | proxy_basepath |
Ścieżka BasePath skonfigurowana w punkcie końcowym serwera proxy interfejsu API. Ścieżka podstawowa nie obejmuje domeny i portu z adresu URL serwera proxy interfejsu API. Jeśli na przykład podstawowy adres URL serwera proxy interfejsu API to https://apigeedocs-test.apigee.net/releasenotes/, ścieżka bazowa to /releasenotes. Wartość jest również przechowywana w zmiennej przepływu |
Sufiks ścieżki serwera proxy | proxy_pathsuffix |
Ścieżka zasobu dodana do ścieżki bazowej serwera proxy interfejsu API. Jeśli na przykład podstawowy adres URL serwera proxy interfejsu API to Jeśli nie jest używany żaden przyrostek ścieżki, wartość jest pusta. Wartość jest również przechowywana w zmiennej przepływu |
Wersja serwera proxy | apiproxy_revision | Numer wersji serwera proxy interfejsu API, który obsługiwał wywołania interfejsu API. Nie musi to oznaczać najnowszej wersji serwera proxy interfejsu API. Jeśli serwer proxy interfejsu API ma 10 wersji, 8 wersja może być obecnie wdrożona. Dodatkowo interfejs API może mieć wiele wersji, o ile wersje mają różne ścieżki podstawowe zgodnie z opisem w sekcji Wdrażanie serwerów proxy w interfejsie. |
Adres IP klienta z rozwiązaniem | ax_resolved_client_ip |
Zawiera źródłowy adres IP klienta. Wartość wymiaru Pamiętaj, że jeśli używasz usług do routingu, takich jak Akamai, do przechwytywania prawdziwych adresów IP klientów, adres IP klienta jest przekazywany do Edge w nagłówku HTTP Wartość wymiaru
|
Kod stanu odpowiedzi | response_status_code | Kod stanu odpowiedzi HTTP przekazany z Apigee do klienta, np. 200, 404, 503 itd. W Edge kod stanu odpowiedzi z miejsca docelowego może zostać zastąpiony zasadami takimi jak Przypisz wiadomość i Zgłaszanie błędu, dlatego ten wymiar może się różnić od atrybutu Kod odpowiedzi docelowej (target_response_code). |
Host wirtualny | virtual_host | Nazwa hosta wirtualnego, do którego wykonano wywołanie interfejsu API. Na przykład organizacje mają domyślnie 2 hosty wirtualne: default (http) i secure (https). |
Przychodzący/klient | ||
Adres IP klienta | client_ip | Adres IP systemu, który trafia na router, takiego jak pierwotny klient (proxy_client_ip) czy system równoważenia obciążenia. Jeśli w nagłówku X-Forwarded-For znajduje się wiele adresów IP, jest to ostatni adres IP na liście. |
Kategoria urządzenia | ax_ua_device_category | Typ urządzenia, z którego wykonano wywołanie interfejsu API, np. „Tablet” lub „Smartfon”. |
Rodzina systemów operacyjnych | ax_ua_os_family | Rodzina systemu operacyjnego urządzenia, które nawiązuje połączenie, np. „Android” lub „iOS”. |
Wersja systemu operacyjnego | ax_ua_os_version |
Wersja systemu operacyjnego urządzenia, z którego pochodzi połączenie. Warto użyć tego wymiaru jako drugiego wymiaru szczegółowego w ramach rodziny systemów operacyjnych (ax_ua_os_family), aby wyświetlić wersje systemów operacyjnych. |
Adres IP klienta serwera proxy | proxy_client_ip |
Adres IP wywołującego klienta przechowywany w zmiennej przepływu |
Odesłany adres IP klienta | ax_true_client_ip | Gdy używasz usług routingu, takich jak Akamai, do przechwytywania prawdziwych adresów IP klientów, adresy IP klientów są przekazywane do Edge w nagłówku HTTP Aby określić oryginalny adres IP klienta, do którego uzyskano dostęp za pomocą wymiaru |
Ścieżka żądania | request_path |
Ścieżka zasobu (bez domeny) do usługi docelowej, z wyłączeniem parametrów zapytania. Na przykład przykładowy cel Apigee |
Identyfikator URI żądania | request_uri |
Ścieżka zasobu (bez domeny) do usługi docelowej, w tym parametry zapytania. Na przykład przykładowy cel Apigee |
Czasownik żądania | request_verb | Czasownik żądania HTTP w żądaniach interfejsu API, np. GET, POST, PUT, DELETE. |
klient użytkownika, | klient użytkownika |
Nazwa klienta użytkownika lub klienta oprogramowania użytego do wywołania interfejsu API. Przykłady:
|
Rodzina klientów użytkownika | ax_ua_agent_family | Rodzina klienta użytkownika, np. „Chrome Mobile” lub „cURL”. |
Typ klienta użytkownika | ax_ua_agent_type | Typ klienta użytkownika, np. „Przeglądarka”, „Przeglądarka mobilna”, „Biblioteka”. |
Wersja klienta użytkownika | ax_ua_agent_version |
Wersja klienta użytkownika. Przydaje się to jako drugi wymiar dogłębna analizy rodziny klientów użytkownika (ax_ua_agent_family) w celu uzyskania wersji rodziny agentów. |
Wychodzące/Cel | ||
Ścieżka bazowa celu | target_basepath |
Ścieżka zasobu (bez domeny) do usługi docelowej z wyłączeniem parametrów zapytania określona w Załóżmy, że serwer proxy interfejsu API wywołuje ten cel: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> W tym przykładzie target_basepath jest wartością Gdyby wartości docelowe były takie: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> Parametr target_basepath ma wartość null. Gdy w narzędziu śledzenia wybierzesz ikonę AX na końcu diagramu przepływu, zmienna przepływu |
Host docelowy | target_host | Host usługi docelowej. Jeśli na przykład serwer proxy interfejsu API wywołuje http://mocktarget.apigee.net/help , host_docelowy ma wartość mocktarget.apigee.net . |
Docelowy adres IP | target_ip | Adres IP usługi docelowej zwracającej odpowiedź na serwer proxy interfejsu API. |
Kod odpowiedzi docelowej | target_response_code |
Kod stanu odpowiedzi HTTP zwrócony przez usługę docelową do serwera proxy interfejsu API, np. 200, 404, 503 itd. Wartość „null” oznacza, że żądanie nie dotarło do usługi docelowej. Dzieje się tak, gdy odpowiedź jest udostępniana przez zasadę pamięci podręcznej odpowiedzi lub gdy podczas przetwarzania żądań wystąpi błąd. Różni się on od wymiaru Kod stanu odpowiedzi (response_status_code). |
Docelowy URL | target_url |
Pełny adres URL usługi docelowej zdefiniowany w docelowym punkcie końcowym serwera proxy interfejsu API. <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> W tym przykładzie target_url jest Pamiętaj, że adres URL można też zastąpić podczas przetwarzania serwera proxy interfejsu API za pomocą zmiennej przepływu W łańcuchu proxy i przy korzystaniu z elementów docelowych skryptu (Node.js) wartość target_url w wywołującym serwerze proxy ma wartość null. |
X Przesłane dla | x_forwarded_for_ip | Lista adresów IP w nagłówku Aby określić oryginalny adres IP klienta, do którego uzyskano dostęp za pomocą wymiaru |
Czas | ||
Dzień tygodnia | ax_day_of_week | Trzyliterowy skrót dnia tygodnia, w którym wykonano wywołania interfejsu API. Na przykład: pon, wt, śr. |
Miesiąc | ax_month_of_year | Miesiąc, w którym wykonano wywołania interfejsu API. Na przykład „03” dla marca. |
Pora dnia | ax_hour_of_day |
Na podstawie zegara 24-godzinnego jest to 2-cyfrowa godzina, w której wykonano wywołania interfejsu API. Na przykład wywołania interfejsu API wykonane między 22:00 a 23:00 wartością ax_hour_of_day będzie 22. Wartość czasu jest podana w strefie czasowej UTC. |
Strefa czasowa | ax_geo_timezone | Popularne nazwy stref czasowych, z których pochodziły wywołania interfejsu API, np. America/New_York i Europa/Dublin. |
Tydzień miesiąca | ax_week_of_month | Liczbowy tydzień miesiąca. Na przykład w przypadku wywołań interfejsu API wykonanych w 3 tygodniu miesiąca wartość ax_week_of_month wynosi 3. |
Lokalizacja | ||
Miasto | ax_geo_city | Miasto, z którego wykonano wywołania interfejsu API. |
Kontynent | ax_geo_continent | Dwuliterowy kod kontynentu, z którego wykonano wywołania interfejsu API. np. NA w przypadku Ameryki Północnej. |
Kraj | ax_geo_country | Dwuliterowy kod kraju, z którego wykonano wywołania interfejsu API. np. „PL” w przypadku Stanów Zjednoczonych. |
Region geograficzny | ax_geo_region | Łączony kod regionu geograficznego, np. STATE-COUNTRY. Na przykład WA-US w przypadku Waszyngton-Stany Zjednoczone. |
Region | ax_dn_region | Nazwa centrum danych Apigee, w którym są wdrożone serwery proxy interfejsów API, np. us-east-1. |
Zarabianie | ||
Komunikat o zignorowaniu transakcji | x_apigee_mint_tx_ignoreMessage | Flaga określająca, czy mają być ignorowane wiadomości związane z zarabianiem. Ustaw jako false w przypadku wszystkich organizacji generujących przychody. |
Stan transakcji tworzenia | x_apigee_mint_tx_status | Stan prośby o zarabianie, np. „powodzenie”, „niepowodzenie”, „nieprawidłowe” lub „brak”. |
Filtry
Filtry umożliwiają ograniczanie wyników do danych o określonych cechach. Poniżej znajdziesz kilka przykładowych filtrów. Podczas definiowania filtrów używaj nazw danych i wymiarów w stylu interfejsu API.
Zwraca wskaźniki dotyczące serwerów proxy API z książkami lub muzyką:
filter=(apiproxy in 'books','music')
Zwraca wskaźniki dotyczące serwerów proxy interfejsu API o nazwach zaczynających się od „m”:
filter=(apiproxy like 'm%')
Zwraca wskaźniki dotyczące serwerów proxy interfejsu API o nazwach, które nie zaczynają się od „m”:
filter=(apiproxy not like 'm%')
Zwraca dane dotyczące wywołań interfejsu API z kodami stanu odpowiedzi z przedziału od 400 do 599:
filter=(response_status_code ge 400 and response_status_code le 599)
Zwraca wskaźniki wywołań interfejsu API z kodem stanu odpowiedzi 200 i docelowym kodem odpowiedzi 404:
filter=(response_status_code eq 200 and target_response_code eq 404)
Zwraca dane dotyczące wywołań interfejsu API z kodem stanu odpowiedzi 500:
filter=(response_status_code eq 500)
Zwraca dane dotyczące wywołań interfejsu API, które nie spowodowały błędów:
filter=(is_error eq 0)
Poniżej znajdziesz operatory, których możesz używać do tworzenia filtrów raportów.
Operator | Opis |
---|---|
in |
Uwzględnij na liście |
notin |
Wyklucz z listy |
eq |
Równa się, == |
ne |
Inne niż != |
gt |
Więcej niż > |
lt |
Mniejsze niż, < |
ge |
Większe lub równe: >= |
le |
Mniejsze lub równe: <= |
like |
Zwraca wartość „prawda”, jeśli wzorzec ciągu znaków pasuje do podanego wzorca. |
not like |
Zwraca wartość false, jeśli wzorzec ciągu znaków pasuje do podanego wzorca. |
similar to |
Zwraca wartość „true” (prawda) lub „false” (fałsz) w zależności od tego, czy jej wzorzec pasuje do danego ciągu. Działa podobnie do like , ale interpretuje wzorzec na podstawie definicji wyrażenia regularnego zgodnie ze standardem SQL. |
not similar to |
Zwraca wartość „false” (fałsz) lub „true” (prawda) w zależności od tego, czy wzorzec pasuje do danego ciągu. Działa podobnie do not like z tą różnicą, że interpretuje wzorzec na podstawie definicji wyrażenia regularnego zdefiniowanej w standardzie SQL. |
and |
Umożliwia użycie logiki „and” w celu uwzględnienia więcej niż 1 wyrażenia filtra. Filtr uwzględnia dane spełniające wszystkie warunki. |
or |
Umożliwia korzystanie z operatorów logicznych „lub” do oceny różnych możliwych wyrażeń filtra. Filtr uwzględnia dane, które spełniają co najmniej 1 z warunków. |