Odniesienia do danych, wymiarów i filtrów Analytics

Średnia liczba transakcji, czyli żądań do serwera proxy interfejsu API, na sekundę. Pamiętaj, że jeśli w danym okresie masz stosunkowo małą liczbę transakcji, średnia liczba transakcji na sekundę może w raportach niestandardowych w interfejsie wyświetlać się jako zero, jeśli jest mniejsza niż 2 miejsca po przecinku.

Składnia interfejsu API: tps

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: sum(cache_hit)

Zwraca liczbę elementów w pamięci podręcznej L1 (w pamięci) na transakcję w danym okresie. Jeśli na przykład wybierzesz max na okres jednego dnia, a w tym dniu maksymalna liczba elementów w pamięci podręcznej dla konkretnej transakcji wynosi 12, to liczba będzie równa 12. W przypadku avg, jeśli w okresie, o który wysyłasz zapytanie, wystąpią 3 transakcje, a ich liczby w pamięci podręcznej wynoszą 5, 6 i 7, średnia wyniesie 6. Pamięć podręczna poziomu 1 to pamięć podręczna w pamięci, w przeciwieństwie do pamięci podręcznej bazy danych poziomu 2, jak opisano w sekcji Wewnętrzne działanie pamięci podręcznej.

Składnia interfejsu API: avg(ax_cache_l1_count)

Łączna liczba błędów związanych z zasadami w określonym przedziale czasu.

Błędy zasad zwykle występują z założenia. Na przykład zasada Verify API Key (Weryfikacja klucza interfejsu API) zgłasza błąd, gdy w żądaniu zostanie przekazany nieprawidłowy klucz interfejsu API, a zasada Spike Arrest (Ochrona przed nagłymi wzrostami ruchu) zgłasza błąd, jeśli liczba wywołań interfejsu API przekroczy limit zdefiniowany w zasadzie. Dlatego ten rodzaj danych jest przydatny do wykrywania potencjalnych problemów w interfejsach API. Na przykład dane policy_error, pogrupowane według wymiaru developer_app, mogą pomóc Ci wykryć, że w przypadku danej aplikacji wygasł klucz interfejsu API lub token OAuth. Możesz też zauważyć, że określony serwer proxy interfejsu API generuje wiele błędów Spike Arrest, co pozwoli Ci odkryć, że limit ochrony przed nagłymi wzrostami ruchu w przypadku tego serwera proxy nie uwzględnia wzrostu ruchu w okresie świątecznym.

Błąd zasady jest rejestrowany w usłudze Analytics tylko wtedy, gdy powoduje niepowodzenie działania serwera proxy interfejsu API. Jeśli na przykład atrybut continueOnError zasady jest ustawiony na true, serwer proxy interfejsu API kontynuuje przetwarzanie żądania nawet w przypadku niepowodzenia zasady. W takim przypadku w statystykach nie jest rejestrowany błąd zasady.

Wymiar Nazwa zasady w przypadku błędu (ax_execution_fault_policy_name) jest przydatny do grupowania błędów zasad według nazwy zasady.

Błąd miejsca docelowego (np. 404 lub 503) nie jest traktowany jako naruszenie zasad. Te wywołania są traktowane jako nieudane wywołania proxy interfejsu API (is_error).

Składnia interfejsu API: sum(policy_error)

Łączna liczba nieudanych wywołań proxy interfejsów API w określonym przedziale czasu. Błąd serwera proxy może wystąpić, gdy zasady nie działają lub gdy wystąpi błąd w czasie działania, np. błąd 404 lub 503 z usługi docelowej.

Wymiar Proxy (apiproxy) jest przydatny do grupowania błędów proxy interfejsu API według proxy.

Składnia interfejsu API: sum(is_error)

Czas (średni, minimalny lub maksymalny) w milisekundach, jaki zajmuje Edge przetwarzanie przychodzących żądań. Czas zaczyna się, gdy żądanie dociera do Edge, a kończy, gdy Edge przekazuje je do usługi docelowej.

Korzystając z różnych wymiarów, możesz sprawdzać opóźnienia w przetwarzaniu żądań według serwera proxy interfejsu API, aplikacji dewelopera, regionu itp.

Składnia interfejsu API: max(request_processing_latency)

Rozmiar ładunku żądania odebranego przez Edge w bajtach.

Składnia interfejsu API: avg(request_size)

Łączna liczba wykonań zasady pamięci podręcznej odpowiedzi w danym okresie.

Ponieważ zasady Response Cache są dołączone w 2 miejscach w proxy interfejsu API (raz w żądaniu i raz w odpowiedzi), są one zwykle wykonywane 2 razy w wywołaniu interfejsu API. Pobranie z pamięci podręcznej i zapisanie w niej danych liczą się jako 1 wykonanie.

Wartość wykonania pamięci podręcznej odpowiedzi wynosi jednak 0, jeśli element <SkipCacheLookup> w zasadach ma wartość „true” (w żądaniu), a także jeśli element <SkipCachePopulation> w zasadach ma wartość „true” (w odpowiedzi).

W narzędziu do śledzenia możesz kliknąć ikonę pamięci podręcznej odpowiedzi w wykonanym wywołaniu interfejsu API i wyświetlić responsecache.executed zmienną przepływu, aby sprawdzić, czy nastąpiło wykonanie z pamięci podręcznej (wartość 1).

Składnia interfejsu API: sum(ax_cache_executed)

Czas (średni, minimalny lub maksymalny) w milisekundach, jaki zajmuje Edge przetwarzanie odpowiedzi interfejsu API. Czas ten liczy się od momentu, w którym proxy interfejsu API otrzyma odpowiedź usługi docelowej, do momentu, w którym Apigee przekaże odpowiedź do pierwotnego wywołującego.

Korzystając z różnych wymiarów, możesz analizować opóźnienia przetwarzania odpowiedzi według proxy interfejsu API, regionu itp.

Składnia interfejsu API: min(response_processing_latency)

Rozmiar ładunku odpowiedzi zwróconego klientowi w bajtach.

Składnia interfejsu API: max(response_size)

Łączna liczba odpowiedzi 5xx z usługi docelowej. Są to błędy usługi docelowej, które nie są spowodowane przez Apigee.

Składnia interfejsu API: sum(target_error)

Czas (suma, średnia, minimum lub maksimum) w milisekundach, jaki upłynął od wysłania wywołania do serwera docelowego do momentu otrzymania odpowiedzi. Te dane informują o wydajności serwerów docelowych. Czas ten zaczyna się, gdy Edge przekazuje żądanie do usługi docelowej, a kończy, gdy Edge otrzymuje odpowiedź.

Pamiętaj, że jeśli wywołanie interfejsu API zwraca odpowiedź z pamięci podręcznej (np. przy użyciu zasady Pamięć podręczna odpowiedzi), wywołanie nigdy nie dotrze do usługi docelowej i nie zostaną zarejestrowane żadne dane o czasie odpowiedzi usługi docelowej.

Składnia interfejsu API: avg(target_response_time)

Czas (suma, średnia, minimum lub maksimum) w milisekundach od momentu, gdy Edge otrzyma żądanie od klienta, do momentu, gdy Edge wyśle odpowiedź z powrotem do klienta. Czas ten obejmuje obciążenie sieci (np. czas potrzebny na wykonanie pracy przez systemy równoważenia obciążenia i routery), opóźnienie przetwarzania żądania, opóźnienie przetwarzania odpowiedzi i czas odpowiedzi usługi docelowej (jeśli odpowiedź jest obsługiwana przez usługę docelową zamiast z pamięci podręcznej).

Korzystając z różnych wymiarów, możesz analizować opóźnienia przetwarzania według serwera proxy interfejsu API, aplikacji dewelopera, regionu itp.

Składnia interfejsu API: avg(total_response_time)

Łączna liczba wywołań interfejsu API przetworzonych przez Edge w określonym przedziale czasu.

Używaj wymiarów, aby grupować liczbę wizyt w sposób, który jest dla Ciebie najbardziej przydatny.

Składnia interfejsu API: sum(message_count)

Nazwa usługi API zawierającej wywoływane serwery proxy interfejsu API. Aby uzyskać ten wymiar, aplikacje deweloperskie wykonujące wywołania interfejsu API muszą być powiązane z co najmniej 1 produktem API zawierającym proxy interfejsu API, a wywoływane proxy muszą sprawdzać klucz interfejsu API lub token OAuth wysłany z wywołaniem interfejsu API. Klucz lub token jest powiązany z usługą API. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne.

Jeśli powyższe kryteria nie zostaną spełnione, zobaczysz wartość „(not set)”. Zobacz też Co oznacza wartość „(not set)” w usłudze analitycznej?

Klucz zawierający wartość pamięci podręcznej odpowiedzi, do której uzyskano dostęp. Więcej informacji o tym, jak tworzony jest klucz do pamięci podręcznej odpowiedzi, znajdziesz w zasadach dotyczących pamięci podręcznej odpowiedzi.

W narzędziu śledzenia, gdy wybierzesz zasadę pamięci podręcznej odpowiedzi, która odczytuje dane z pamięci podręcznej lub zapisuje w niej dane, możesz zobaczyć tę wartość w responsecache.cachekey zmiennej przepływu.

Nazwa pamięci podręcznej zawierającej klucze i wartości używane przez zasadę Response Cache, poprzedzona ciągiem znaków orgName__envName__. Jeśli np. organizacja to „foo”, środowisko to „test”, a nazwa pamięci podręcznej to „myCache”, zmienna ax_cache_name będzie miała wartość foo__test__myCache.

W narzędziu śledzenia po wybraniu zasady pamięci podręcznej odpowiedzi możesz zobaczyć tę wartość w responsecache.cachename zmiennej przepływu.

Poziom pamięci podręcznej („L1” w pamięci lub „L2” w bazie danych), z którego pobrano pamięć podręczną odpowiedzi. Ten wymiar pokazuje też wartość „CACHE_MISS”, gdy odpowiedź została dostarczona z miejsca docelowego zamiast z pamięci podręcznej (a pamięć podręczna odpowiedzi została odświeżona za pomocą odpowiedzi z miejsca docelowego) lub gdy klucz pamięci podręcznej w żądaniu jest nieprawidłowy. Klucze pamięci podręcznej mają maksymalny rozmiar 2 KB.

W narzędziu śledzenia po wybraniu zasady Pamięć podręczna odpowiedzi możesz zobaczyć tę wartość w responsecache.cachesource zmiennej przepływu.

Więcej informacji o poziomach pamięci podręcznej znajdziesz w artykule Wewnętrzne działanie pamięci podręcznej.

Klucz klienta (klucz interfejsu API) aplikacji dewelopera, która wysyła wywołania interfejsu API, niezależnie od tego, czy jest przekazywany w żądaniu jako klucz interfejsu API, czy jest uwzględniony w tokenach OAuth.

Aby uzyskać ten wymiar, serwery proxy odbierające wywołania muszą być skonfigurowane tak, aby sprawdzać, czy klucz interfejsu API lub token OAuth jest prawidłowy. Aplikacje deweloperskie otrzymują klucze interfejsu API, których można używać 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 zostaną spełnione, zobaczysz wartość „(not set)”. Zobacz też Co oznacza wartość „(not set)” w usłudze analitycznej?

Aplikacja dewelopera zarejestrowana w Edge, która wywołuje interfejsy API.

Aby uzyskać ten wymiar, aplikacje muszą być powiązane z co najmniej 1 produktem API, który zawiera wywoływane serwery proxy API. Serwery proxy muszą sprawdzać klucz interfejsu API lub token OAuth wysłany z wywołaniem interfejsu API. Klucz lub token identyfikuje aplikację dewelopera. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne.

Jeśli powyższe kryteria nie zostaną spełnione, zobaczysz wartość „(not set)”. Zobacz też Co oznacza wartość „(not set)” w usłudze analitycznej?

Adres e-mail deweloperów zarejestrowanych w Edge, których aplikacja wywołała interfejsy API.

Aby uzyskać ten wymiar, deweloperzy muszą mieć aplikacje powiązane z co najmniej 1 produktem API, który zawiera wywoływane serwery proxy API. Serwery proxy muszą sprawdzać klucz interfejsu API lub token OAuth wysłany z wywołaniem interfejsu API. Klucz lub token identyfikuje aplikację dewelopera. Więcej informacji znajdziesz w artykule Pierwsze kroki: jak generować pełne dane analityczne.

Jeśli powyższe kryteria nie zostaną spełnione, zobaczysz wartość „(not set)”. Zobacz też Co oznacza wartość „(not set)” w usłudze analitycznej?

Unikalny identyfikator dewelopera wygenerowany przez Edge w formacie org_name@@@unique_id.

Aby uzyskać ten wymiar, deweloperzy muszą mieć aplikacje powiązane z co najmniej 1 produktem API zawierającym wywoływane serwery proxy API. Serwery proxy muszą sprawdzać klucz interfejsu API lub token OAuth wysył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 zostaną spełnione, zobaczysz wartość „(not set)”. Zobacz też Co oznacza wartość „(not set)” w usłudze analitycznej?

Kod błędu. Na przykład:messaging.adaptors.http.flow.GatewayTimeout

Nazwana ścieżka w proxy interfejsu API, która spowodowała błąd. Na przykład „PreFlow”, „PostFlow” lub nazwa utworzonego przez Ciebie przepływu warunkowego.

Pamiętaj, że pełna nazwa, której należy użyć w interfejsie Management API, to ax_execution_fault_flow_name, bez znaku podziału wiersza.

Jeśli nie wystąpiły żadne błędy, zobaczysz wartość „(not set)”.

Nazwa przepływu serwera proxy interfejsu API, w którym wystąpiły błędy, np. „PROXY_REQ_FLOW” lub „TARGET_RESP_FLOW”.

Pamiętaj, że pełna nazwa, której należy użyć w interfejsie Management API, to ax_execution_fault_flow_state, bez znaku podziału wiersza.

Nazwa zasady, która spowodowała błąd i 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 znaku podziału wiersza).

Jeśli zasada zgłosi błąd, ale atrybut główny zasady continueOnError ma wartość true, przepływ proxy interfejsu API będzie kontynuowany bez awarii, a błąd zasady nie będzie uwzględniany w tym wymiarze.

BasePath skonfigurowany w ProxyEndpoint proxy interfejsu API. Ścieżka podstawowa nie zawiera części adresu URL serwera proxy interfejsu API, która odnosi się do domeny i portu. Jeśli na przykład podstawowy adres URL serwera proxy interfejsu API to https://apigeedocs-test.apigee.net/releasenotes/, ścieżka podstawowa to /releasenotes.

Wartość jest też przechowywana w proxy.basepath zmiennej przepływu.

Ścieżka zasobu dodana do podstawowej ścieżki serwera proxy interfejsu API. Jeśli na przykład podstawowy adres URL serwera proxy interfejsu API to https://apigeedocs-test.apigee.net/hello/, a wywołanie jest kierowane na adres https://apigeedocs-test.apigee.net/hello/json, sufiks ścieżki to /json.

Jeśli nie używasz sufiksu ścieżki, wartość jest pusta.

Wartość jest też przechowywana w proxy.pathsuffix zmiennej przepływu.

Zawiera adres IP źródłowego klienta. Wartość wymiaru ax_resolved_client_ip jest obliczana na podstawie wartości wymiarów ax_true_client_ip i x_forwarded_for_ip.

Pamiętaj, że jeśli do przechwytywania prawdziwych adresów IP klientów używasz usług routingu, takich jak Akamai, adres IP klienta jest przekazywany do Edge w nagłówku HTTP True-Client-IP, który jest następnie używany do ustawiania wymiaru ax_true_client_ip.

Wartość wymiaru ax_resolved_client_ip jest obliczana w ten sposób:

1. Jeśli ax_true_client_ip nie ma wartości null i nie zawiera lokalnego adresu IP, ustaw ax_resolved_client_ip na ax_true_client_ip.
2. W przeciwnym razie ustaw ax_resolved_client_ip na pierwszy nie lokalny adres IP w x_forwarded_for_ip.
3. Jeśli zarówno ax_true_client_ip, jak i x_forwarded_for_ip zawierają tylko lokalne adresy IP, ustaw ax_resolved_client_ip na pierwszy lokalny adres IP w x_forwarded_for_ip.
4. Jeśli zarówno ax_true_client_ip, jak i x_forwarded_for_ip mają wartość null, ustaw ax_resolved_client_ip na (not set).
5. Jeśli ax_true_client_ip jest lokalnym adresem IP, a x_forwarded_for_ip ma wartość null, ustaw ax_resolved_client_ip na (not set).

Wersja systemu operacyjnego urządzenia, z którego pochodzi połączenie.

Warto używać go jako drugiego wymiaru szczegółowego z wymiarem Rodzina systemów operacyjnych (ax_ua_os_family), aby wyświetlać wersje systemów operacyjnych.

Adres IP klienta wywołującego, przechowywany w proxy.client.ip zmiennej przepływu. Jest to zwykle adres X-Forwarded-For połączenia przychodzącego, czyli adres IP, który Edge otrzymał z ostatniego zewnętrznego uzgadniania TCP. Może to być klient wywołujący lub system równoważenia obciążenia. Jeśli w nagłówku X-Forwarded-For jest kilka adresów IP, jest to ostatni z nich.

Jeśli do przechwytywania prawdziwych adresów IP klientów używasz usług routingu, takich jak Akamai, adresy IP klientów są przekazywane do Edge w nagłówku HTTP True-Client-IP. Ten wymiar rejestruje rzeczywiste adresy IP klientów z tego nagłówka.

Aby określić pierwotny adres IP klienta, do którego dostęp uzyskuje się za pomocą wymiaru ax_resolved_client_ip, Edge używa wymiarów ax_true_client_ip i x_forwarded_for_ip.

Ścieżka zasobu (bez domeny) do usługi docelowej, z wyłączeniem parametrów zapytania.

Na przykład przykładowy cel Apigee http://mocktarget.apigee.net zawiera kilka zasobów, w tym /user, który zwraca powitanie. Niezależnie od tego, jak serwer proxy interfejsu API wywołuje http://mocktarget.apigee.net/user, ścieżka żądania to /user.

Ścieżka zasobu (bez domeny) do usługi docelowej, w tym parametry zapytania.

Na przykład przykładowy cel Apigee http://mocktarget.apigee.net zawiera kilka zasobów, w tym zasób /user?user={name} i parametr zapytania, który zwraca niestandardowe powitanie z podaną nazwą. Niezależnie od tego, jak serwer proxy interfejsu API wywołuje http://mocktarget.apigee.net/user?user=Dude, request_uri to /user?user=Dude.

Nazwa klienta użytkownika lub agenta oprogramowania użytego do wywołania interfejsu API. Przykłady:

• Pixel XL podczas rozmowy przez Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• iPad, na którym jest prowadzona rozmowa w Chrome: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL z terminala: curl/7.51.0

Wersja agenta użytkownika.

Warto używać tego wymiaru jako drugiego wymiaru szczegółowego z wymiarem Rodzina klientów użytkownika (ax_ua_agent_family), aby uzyskać wersję rodziny klientów.

Ścieżka zasobu (bez domeny) do usługi docelowej, z wyłączeniem parametrów zapytania, która jest zdefiniowana w <TargetEndpoint> serwera proxy.

Załóżmy na przykład, ż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 to /user.

Jeśli celem byłoby:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

Wartość target_basepath będzie wtedy wartością null.

W narzędziu śledzenia, gdy klikniesz ikonę AX na końcu diagramu przepływu, target.basepath zmienna przepływu zostanie zmapowana na wymiar target_basepath.

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 nigdy nie dotarło do usługi docelowej. Dzieje się tak, gdy odpowiedź jest obsługiwana przez zasadę pamięci podręcznej odpowiedzi lub gdy wystąpi błąd w przetwarzaniu żądania.

Różni się on od wymiaru Kod stanu odpowiedzi (response_status_code).

Pełny adres URL usługi docelowej zdefiniowany w elemencie TargetEndpoint proxy interfejsu API.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

W tym przykładzie target_url to http://mocktarget.apigee.net/user?user=Dude.

Pamiętaj, że adres URL można też zastąpić podczas przetwarzania serwera proxy interfejsu API za pomocą target.url zmiennej przepływu.

W przypadku łączenia serwerów proxy i używania skryptów docelowych (Node.js) adres target_url w wywołującym serwerze proxy ma wartość null.

Lista adresów IP w nagłówku X-Forwarded-For.

Aby określić pierwotny adres IP klienta, do którego dostęp uzyskuje się za pomocą wymiaru ax_resolved_client_ip, Edge używa wymiarów ax_true_client_ip i x_forwarded_for_ip.

Na podstawie 24-godzinnego zegara 2-cyfrowa godzina, w której wykonano wywołania interfejsu API. Na przykład w przypadku wywołań interfejsu API wykonanych w godzinach od 22:00 do 23:00 wartość parametru ax_hour_of_day wyniesie 22.

Wartość czasu jest podana w UTC.