Referenz zu Analysemesswerten, -dimensionen und -filtern

Die durchschnittliche Anzahl von Transaktionen, also API-Proxy-Anfragen, pro Sekunde. Beachten Sie, dass die durchschnittliche Anzahl der Transaktionen pro Sekunde in benutzerdefinierten Berichten der Benutzeroberfläche null sein kann, wenn die Anzahl kleiner als zwei Dezimalstellen ist.

API-Syntax: tps

Die Anzahl erfolgreicher API-Anfragen, die den Antwortcache anstelle der Antwort des Zieldienstes verwenden.

API-Syntax: sum(cache_hit)

Gibt die Anzahl der Elemente im L1-Cache (im Arbeitsspeicher) pro Transaktion über einen bestimmten Zeitraum zurück. Wenn Sie beispielsweise max für den Zeitraum eines Tages auswählen und innerhalb dieses Tages die höchste Anzahl von Elementen im Cache für eine bestimmte Transaktion 12 ist, beträgt die Anzahl 12. Wenn für avg in dem von Ihnen abgefragten Zeitraum drei Transaktionen vorhanden sind und die Cache-Anzahl 5, 6 und 7 beträgt, beträgt der Durchschnitt 6. Der L1-Cache befindet sich im Cache statt im L2-Datenbankcache, wie unter Cache-Interna beschrieben.

API-Syntax: avg(ax_cache_l1_count)

Die Gesamtzahl der Richtlinienfehler im angegebenen Zeitraum.

Richtlinienfehler treten normalerweise konstruktionsbedingt auf. Beispielsweise gibt die Richtlinie zum Prüfen des API-Schlüssels einen Fehler aus, wenn ein ungültiger API-Schlüssel in der Anforderung übergeben wird, und eine Spike Arrest-Richtlinie gibt einen Fehler aus, wenn die Anzahl der API-Aufrufe den in der Richtlinie festgelegten Grenzwert überschreitet. Daher ist diese Metrik hilfreich, um potenzielle Problemstellen in Ihren APIs zu finden. Beispielsweise könnten policy_error-Messwerte, gruppiert nach der developer_app-Dimension, Ihnen helfen zu entdecken, dass ein API-Schlüssel oder ein OAuth-Token für eine bestimmte Anwendung abgelaufen ist; oder Sie könnten feststellen, dass ein bestimmter API-Proxy viele Spike Arrest Fehler ausgibt, was Sie zu der Erkenntnis führt, dass das Spike Arrest-Limit des Proxys nicht für eine Zunahme des Feiertagstraffics verantwortlich ist.

Ein Richtlinienfehler wird nur in der Analyse protokolliert, wenn der Fehler zum Ausfall des API-Proxys führt. Beispiel: Wenn das continueOnError-Attribut einer Richtlinie auf true festgelegt wird, enthält der API-Proxy eine Anfrage auch dann weiter, wenn die Richtlinie fehlschlägt. In diesem Fall wird in Analytics kein Richtlinienfehler protokolliert.

Die Dimension "Richtlinienname bei Fehler" (ax_execution_fault_policy_name) ist nützlich, um Richtlinienfehler nach Richtliniennamen zu gruppieren.

Ein Zielfehler (z. B. 404 oder 503) zählt nicht als Richtlinienfehler. Diese zählen als API-Proxy-Fehler (is_error).

API-Syntax: sum(policy_error)

Die Gesamtzahl, wie oft API-Proxys im angegebenen Zeitraum fehlgeschlagen sind. Ein Proxy-Fehler kann auftreten, wenn eine Richtlinie fehlschlägt oder ein Laufzeitfehler auftritt, z. B. 404 oder 503 des Zieldienstes.

Die Proxy-Dimension (apiproxy) ist hilfreich, um API-Proxy-Fehler nach Proxy zu gruppieren.

API-Syntax: sum(is_error)

Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden , die Edge zur Verarbeitung eingehender Anfragen benötigt. Die Zeit beginnt, wenn die Anfrage Edge erreicht, und endet, wenn Edge die Anfrage an den Zieldienst weiterleitet.

Mithilfe verschiedener Dimensionen können Sie Latenzen für die Anforderungsverarbeitung nach API-Proxy, Entwickler-App, Region usw. prüfen.

API-Syntax: max(request_processing_latency)

Die Größe der von Edge empfangenen Anforderungsnutzlast in Byte.

API-Syntax: avg(request_size)

Die Gesamtzahl, in der eine Antwort-Cache-Richtlinie im angegebenen Zeitraum ausgeführt wurde.

Da die Antwort-Cache-Richtlinie an zwei Stellen in einem API-Proxy angehängt ist (einmal in der Anfrage und einmal in der Antwort), wird sie normalerweise zweimal in einem API-Aufruf ausgeführt. Ein Cache "get" und ein Cache-"Put" zählen jeweils als eine Ausführung.

Die Ausführung des Antwort-Caches ist jedoch 0, wenn das <SkipCacheLookup>-Element in der Richtlinie "true" (in der Anfrage) lautet, und 0, wenn das Element <SkipCachePopulation> in der Richtlinie als "true" eingestuft wird. wird mit "true" (in der Antwort) ausgewertet.

Wählen Sie in der Trace-Tool eingeben, können Sie in einem ausgeführten API-Aufruf auf das Symbol für den Response-Cache klicken und die responsecache.executed Flussvariable um zu ermitteln, ob eine Cache-Ausführung (Wert 1) aufgetreten ist.

API-Syntax: sum(ax_cache_executed)

Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden , die Edge zur Verarbeitung von API-Antworten benötigt. Die Zeit beginnt, wenn der API-Proxy die Zieldienstantwort erhält, und endet, wenn Apigee die Antwort an den ursprünglichen Anrufer weiterleitet.

Mithilfe verschiedener Dimensionen können Sie die Latenz der Antwortverarbeitung nach API-Proxy, -Region usw. prüfen.

API-Syntax: min(response_processing_latency)

Die Größe der an den Client zurückgegebenen Antwortnutzlast in Byte.

API-Syntax: max(response_size)

Die Gesamtzahl der 5xx-Antworten des Zieldienstes. Dies sind Zieldienstfehler, die nicht von Apigee verursacht werden.

API-Syntax: sum(target_error)

Die Zeit (Summe, Durchschnitt, Minimum oder Maximum) in Millisekunden, die der Zielserver auf einen Anruf antwortet. Diese Metrik gibt an, wie die Zielserver arbeiten. Die Zeit beginnt, wenn Edge eine Anfrage an den Zieldienst weiterleitet, und endet, wenn Edge die Antwort empfängt.

Wenn ein API-Aufruf eine Antwort aus dem Cache zurückgibt (z. B. mit der Response-Cache-Richtlinie), wird der Aufruf niemals den Zieldienst erreichen. Außerdem werden keine Messwerte für die Zielantwortzeit erfasst.

API-Syntax: avg(target_response_time)

Der Zeitraum (Summe, Durchschnitt, Minimum oder Maximum) in Millisekunden, ab dem Edge eine Anfrage von einem Client empfängt, bis zu dem Edge die Antwort an den Client zurücksendet. Die Zeit beinhaltet den Netzwerkaufwand (z. B. die Zeit, die Load-Balancer und Router benötigen, um ihre Arbeit zu erledigen), die Verarbeitungslatenz, die Antwortverarbeitungslatenz und die Zielantwortzeit (wenn die Antwort statt des Caches vom Zieldienst bereitgestellt wird).

Mithilfe verschiedener Dimensionen können Sie Latenzen für die Anfrageverarbeitung nach API-Proxy, Entwickler-App, Region usw. prüfen.

API-Syntax: avg(total_response_time)

Die Gesamtzahl der API-Aufrufe, die von Edge im angegebenen Zeitraum verarbeitet wurden.

Verwenden Sie Dimensionen, um die Anzahl der Zugriffe so zu gruppieren, wie es für Sie am aussagekräftigsten ist.

API-Syntax: sum(message_count)

Der Name des API-Produkts, das die aufgerufenen API-Proxys enthält. Um diese Dimension zu erhalten, müssen Entwickleranwendungen, die die Aufrufe ausführen, einem oder mehreren API-Produkten zugeordnet sein, die die API-Proxys enthalten, und die aufgerufenen Proxys müssen nach einem API-Schlüssel oder OAuth-Token suchen, das mit dem API-Aufruf gesendet wurde. Der Schlüssel oder das Token ist einem API-Produkt zugeordnet. Weitere Informationen finden Sie unter Erste Schritte: Generieren vollständiger Analysedaten.

Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert "(nicht festgelegt)" angezeigt. Siehe auch Was bedeutet ein Analytics-Entity-Wert "(nicht festgelegt)"?.

Der Schlüssel mit dem Response-Cache-Wert, auf den zugegriffen wurde. Weitere Informationen dazu, wie der Schlüssel für den Antwortcache erstellt wird, finden Sie unter Antwort-Cache-Richtlinie.

Wenn Sie im Trace-Tool eine Antwort-Cache-Richtlinie auswählen, die aus dem Cache gelesen oder in den Cache geschrieben wurde, können Sie diesen Wert in der responsecache.cachekey Ablaufvariablen sehen.

Der Name des Caches, der die Schlüssel/Werte enthält, die von der Response-Cache-Richtlinie verwendet werden, mit dem Präfix orgName__envName__. Wenn die Organisation beispielsweise "foo" ist, ist die Umgebung "test" und der Cache-Name "myCache". Der ax_cache_name lautet foo__test__myCache.

Wenn Sie im Trace-Tool eine Antwort-Cache-Richtlinie auswählen, können Sie diesen Wert in der Ablaufvariablen responsecache.cachename sehen.

Die Cache-Ebene ("L1"-In-Memory- oder "L2"-Datenbank), aus der der Antwort-Cache abgerufen wurde. Diese Dimension zeigt auch "CACHE_MISS" an, wenn die Antwort vom Ziel statt vom Cache gesendet wurde und der Antwortcache mit der Zielantwort aktualisiert wurde, oder wenn ein Cache-Schlüssel in der Anfrage ungültig ist. Cache-Schlüssel sind auf 2 KB begrenzt.

Wenn Sie im Trace-Tool die Response-Cache-Richtlinie auswählen, können Sie diesen Wert in der Ablaufvariablen responsecache.cachesource sehen.

Weitere Informationen zu Cache-Levels finden Sie unter Interne Cashes.

Der Consumer-Schlüssel (API-Schlüssel) der Entwickler-App, die die API-Aufrufe durchführt, unabhängig davon, ob sie in der Anfrage als API-Schlüssel übergeben oder in OAuth-Tokens enthalten ist.

Um diese Dimension zu erhalten, müssen Proxys, die Anrufe empfangen, konfiguriert sein, um nach einem gültigen API-Schlüssel oder OAuth-Token zu suchen. Entwickler-Apps erhalten API-Schlüssel, die zum Generieren von OAuth-Tokens verwendet werden können, wenn die Apps in Edge registriert werden. Weitere Informationen finden Sie unter Erste Schritte: Generieren vollständiger Analysedaten.

Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert "(nicht festgelegt)" angezeigt. Siehe auch Was bedeutet ein Analytics-Entity-Wert "(nicht festgelegt)"?.

Die von Edge registrierte Entwickler-App, die API-Aufrufe durchführt.

Um diese Dimension zu erhalten, müssen Apps einem oder mehreren API-Produkten zugeordnet sein, die die aufgerufenen API-Proxys enthalten, und die Proxys müssen nach einem mit dem API-Aufruf gesendeten API-Schlüssel oder OAuth-Token suchen. Der Schlüssel oder das Token identifiziert die Entwickler-App. Weitere Informationen finden Sie unter Erste Schritte: Generieren vollständiger Analysedaten.

Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert "(nicht festgelegt)" angezeigt. Siehe auch Was bedeutet ein Analytics-Entity-Wert "(nicht festgelegt)"?.

Die E-Mail der Edge-registrierten Entwickler, deren App die API-Aufrufe durchgeführt hat.

Um diese Dimension zu erhalten, müssen Entwickler-Apps mit einem oder mehreren API-Produkten verbunden sein, die die aufgerufenen API-Proxys enthalten, und die Proxys müssen nach einem mit dem API-Aufruf gesendeten API-Schlüssel oder OAuth-Token suchen. Der Schlüssel oder das Token identifiziert die Entwickler-App. Weitere Informationen finden Sie unter Erste Schritte: Generieren vollständiger Analysedaten.

Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert "(nicht festgelegt)" angezeigt. Siehe auch Was bedeutet ein Analytics-Entity-Wert "(nicht festgelegt)"?.

Die von Edge-generierte Entwickler-ID in Form von org_name@@@unique_id.

Um diese Dimension zu erhalten, müssen Entwickler-Apps mit einem oder mehreren API-Produkten verbunden sein, die die aufgerufenen API-Proxys enthalten, und die Proxys müssen nach einem mit den API-Aufrufen gesendeten API-Schlüssel oder OAuth-Token suchen. Der Schlüssel oder das Token identifiziert den Entwickler. Weitere Informationen finden Sie unter Erste Schritte: Generieren vollständiger Analysedaten.

Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert "(nicht festgelegt)" angezeigt. Siehe auch Was bedeutet ein Analytics-Entity-Wert "(nicht festgelegt)"?.

Der Fehlercode des Fehlers. Zum Beispiel messaging.adaptors.http.flow.GatewayTimeout.

Der benannte Ablauf in einem API-Proxy, der einen Fehler ausgelöst hat. Beispiel: "PreFlow", "PostFlow" oder der Name eines bedingten Ablaufs, den Sie erstellt haben.

Beachten Sie, dass der vollständige Name, der in der Verwaltungs-API verwendet werden soll, ax_Execution_Fehler_flow_name ohne Zeilenumbruch lautet.

Wenn keine Fehler aufgetreten sind, wird der Wert "(nicht festgelegt)" angezeigt.

Der Name des API-Proxy-Flusses gibt an, dass Fehler ausgelöst wurden, z. B. "PROXY_REQ_FLOW" oder "TARGET_RESP_FLOW".

Beachten Sie, dass der vollständige Name, der in der Verwaltungs-API verwendet werden soll, ax_ausführung_Fehler_flow_state ohne Zeilenumbruch lautet.

Der Name der Richtlinie, die einen Fehler ausgelöst hat und der dazu geführt hat, dass der API-Aufruf fehlgeschlagen ist.

Beachten Sie, dass der vollständige Name, der in der Verwaltungs-API verwendet werden soll, ax_ausführung_Fehler_policy_name ohne Zeilenumbruch lautet.

Wenn eine Richtlinie einen Fehler ausgibt, aber das Richtlinienstammattribut continueOnError auf true festgelegt ist, wird der API-Proxy-Ablauf ohne Fehler fortgesetzt, und der Richtlinienfehler wird in dieser Dimension nicht gezählt.

Der BasePath, der auf dem API-Proxy-ProxyEndpoint konfiguriert wurde. Der Basispfad enthält nicht die Domain und den Portteil der API-Proxy-URL. Wenn die Basis-URL eines API-Proxys beispielsweise https://apigeedocs-test.apigee.net/releasenotes/ lautet, lautet der Basispfad /releasenotes.

Der Wert wird auch in der Ablaufvariablen proxy.basepath gespeichert.

Der Ressourcenpfad, der dem API-Proxy-Basispfad hinzugefügt wurde. Wenn die Basis-URL eines API-Proxys beispielsweise https://apigeedocs-test.apigee.net/hello/ lautet und ein Aufruf an https://apigeedocs-test.apigee.net/hello/json erfolgt, lautet das Pfadsuffix /json.

Wenn kein Pfadsuffix verwendet wird, ist der Wert leer.

Der Wert wird auch in der Ablaufvariablen proxy.pathsuffix gespeichert.

Enthält die ursprüngliche IP-Adresse des Clients. Der Wert der Dimension ax_resolved_client_ip wird aus den Werten in der Dimension ax_true_client_ip und x_forwarded_for_ip berechnet.

Wenn Sie Routingprodukte wie Akamai verwenden, um die echten IP-Adressen von Clients zu erfassen, wird die Client-IP-Adresse im HTTP-Header True-Client-IP an Edge übergeben. Damit wird dann die Dimension ax_true_client_ip festgelegt.

Der Wert der Dimension ax_resolved_client_ip wird so berechnet:

1. Wenn ax_true_client_ip nicht null ist und keine lokale IP-Adresse enthält, setzen Sie ax_resolved_client_ip auf ax_true_client_ip.
2. Andernfalls legen Sie ax_resolved_client_ip auf die erste nicht lokale IP-Adresse in x_forwarded_for_ip fest.
3. Wenn sowohl ax_true_client_ip als auch x_forwarded_for_ip nur lokale IP-Adressen enthalten, legen Sie ax_resolved_client_ip auf die erste lokale IP-Adresse in x_forwarded_for_ip fest.
4. Wenn sowohl ax_true_client_ip als auch x_forwarded_for_ip null sind, setzen Sie ax_resolved_client_ip auf (not set).
5. Wenn ax_true_client_ip eine lokale IP-Adresse und x_forwarded_for_ip null ist, legen Sie ax_resolved_client_ip auf (not set) fest.

Die Betriebssystemversion des Geräts, das den Aufruf durchführt.

Es ist nützlich, dies als zweite "Drilldown"-Dimension mit der Betriebssystemfamilie (ax_ua_os_family) zu verwenden, um die Versionen der Betriebssysteme anzuzeigen.

Die IP-Adresse des aufrufenden Clients, die in der Ablaufvariablen proxy.client.ip gespeichert ist. Dies ist häufig die X-Forwarded-For-Adresse des eingehenden Aufrufs, bei dem es sich um den IP-Adress-Edge handelt, der vom letzten externen TCP-Handshake empfangen wurde. Dies kann der aufrufende Client oder ein Load Balancer sein. Wenn die IP-Adresse X-Forwarded-For Header enthält die letzte aufgeführte IP-Adresse.

Wenn Sie Routingprodukte wie Akamai verwenden, um die echten IP-Adressen von Clients zu erfassen, werden die Client-IP-Adressen im HTTP-Header True-Client-IP an Edge übergeben. Diese Dimension erfasst die echten Client-IPs aus diesem Header.

Um die ursprüngliche Client-IP-Adresse zu bestimmen, auf die über die Dimension ax_resolved_client_ip zugegriffen wird, verwendet Edge die Dimensionen ax_true_client_ip und x_forwarded_for_ip.

Der Ressourcenpfad (nicht die Domain) zum Zieldienst, mit Ausnahme der Abfrageparameter.

Das Apigee-Beispielziel http://mocktarget.apigee.net enthält beispielsweise mehrere Ressourcen, einschließlich /user, die eine Begrüßung zurückgeben. Unabhängig davon, wie Ihr API-Proxy http://mocktarget.apigee.net/user aufruft, lautet der request_path /user.

Der Ressourcenpfad (nicht die Domain) zum Zieldienst, mit Ausnahme der Abfrageparameter.

Das Apigee-Beispielziel http://mocktarget.apigee.net enthält beispielsweise mehrere Ressourcen, einschließlich /user?user={name}-Ressource und Abfrageparameter, um eine benutzerdefinierte Begrüßung an den angegebenen Namen zurückzugeben. Unabhängig davon, wie Ihr API-Proxy http://mocktarget.apigee.net/user?user=Dude aufruft, lautet der request_uri /user?user=Dude.

Der Name des User-Agents oder Software-Agents, der für den API-Aufruf verwendet wird. Beispiele:

• Ein Pixel XL, das über Chrome telefoniert: 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
• Ein iPad, das über Chrome anruft: 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 von einem Terminal: curl/7.51.0

Die Version des User-Agents.

Es ist nützlich, diese Option als zweite Drilldown-Dimension mit der User-Agent-Familie (ax_ua_agent_family) zu verwenden, um die Version der Agent-Familie abzurufen.

Der Ressourcenpfad (mit Ausnahme der Domain) zum Zieldienst ohne Abfrageparameter, der in den <TargetEndpoint> des Proxys definiert ist.

Angenommen, ein API-Proxy ruft das folgende Ziel auf:

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

In diesem Beispiel lautet der target_basepath /user.

Wenn das Ziel dies wäre:

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

Der target_basepath wäre null.

Wenn Sie im Trace-Tool das ACHS-Symbol am Ende des Ablaufdiagramms auswählen, wird die target.basepath Ablaufvariable der Dimension "target_basepath" zugeordnet.

Der Statuscode der HTTP-Antwort, der vom Zieldienst an den API-Proxy zurückgegeben wird, z. B. 200, 404, 503 usw.

Der Wert "null" bedeutet, dass die Anfrage den Zieldienst nie erreicht hat. Dies tritt auf, wenn die Antwort von der Antwort-Cache-Richtlinie bereitgestellt wird oder wenn bei der Anfrageverarbeitung ein Fehler auftritt.

Dies unterscheidet sich von der Dimension Antwortstatuscode (response_status_code).

Die vollständige URL des Zieldienstes, der im TargetEndpoint eines API-Proxys definiert ist.

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

In diesem Beispiel lautet target_url http://mocktarget.apigee.net/user?user=Dude.

Beachten Sie, dass die URL auch während der API-Proxy-Verarbeitung mit der target.url Ablaufvariablen überschrieben werden kann.

Bei Proxy-Verkettungen und bei der Verwendung von Skriptzielen (Node.js) ist "target_url" im aufrufenden Proxy null.

Die Liste der IP-Adressen im X-Forwarded-For-Header.

Um die ursprüngliche Client-IP-Adresse zu bestimmen, auf die über die Dimension ax_resolved_client_ip zugegriffen wird, verwendet Edge die Dimensionen ax_true_client_ip und x_forwarded_for_ip.

Basierend auf einem 24-Stunden-Format die zweistellige Stunde, in der API-Aufrufe getätigt wurden. Beispiel: API-Aufrufe, die in der Stunde zwischen 22:00 Uhr und 23:00 Uhr durchgeführt werden, wären ax_hour_of_day 22.

Der Zeitwert ist in UTC.