Referenz zu Analysemesswerten, -dimensionen und -filtern

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Dieses Thema dient als Referenz für Analysemesswerte, Dimensionen und Filter. Weitere Informationen zur Verwendung finden Sie in der Übersicht über API Analytics.

In diesem Thema werden die Namen für Metriken und Dimensionen aufgeführt, wie sie in der Benutzeroberfläche angezeigt werden und in API-Aufrufen verwendet werden müssen.

Messwerte

Nachfolgend sind die API-Messwerte aufgeführt, die Sie in benutzerdefinierten Berichten und Verwaltungs-API-Aufrufen abrufen können.

Name der benutzerdefinierten Berichte Name, der in der Verwaltungs-API verwendet werden soll Funktionen Beschreibung
Durchschnittliche Transaktionen pro Sekunde tps

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

Cache-Treffer cache_hit Summe

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

API-Syntax: sum(cache_hit)

Anzahl der L1-Cache-Elemente ax_cache_l1_count avg, min, max

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)

Verstöße gegen Richtlinien policy_error Summe

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)

Proxy-Fehler is_error Summe

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)

Anfrageverarbeitungslatenz request_processing_latency avg, min, max

Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden dass Edge eingehende Anfragen verarbeitet. Die Zeit beginnt, wenn die Anfrage Edge und endet, wenn Edge die Anforderung 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)

Größe der Anfrage request_size sum, avg, min, max

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

API-Syntax: avg(request_size)

Antwort-Cache ausgeführt ax_cache_executed Summe

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)

Antwortverarbeitungslatenz response_processing_latency avg, min, max

Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden dass Edge 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)

Antwortgröße response_size sum, avg, min, max

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

API-Syntax: max(response_size)

Targeting-Fehler target_error Summe

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

API-Syntax: sum(target_error)

Zielantwortzeit target_response_time sum, avg, min, max

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 weiterleitet. an den Zieldienst und endet, wenn Edge die Antwort erhält.

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)

Gesamtantwortzeit total_response_time sum, avg, min, max

Die Zeit (Summe, Durchschnitt, Minimum oder Maximum) in milliseconds von dem Zeitpunkt, an dem Edge eine Anfrage von einem Client empfängt, bis zum Edge sendet die Antwort an den Client zurück. 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)

Traffic message_count Summe

Die Gesamtzahl der von Edge im angegebenen Zeitraum verarbeiteten API-Aufrufe.

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)

Dimensionen

Mit Dimensionen können Sie Messwerte in sinnvollen Gruppierungen anzeigen. Beispielsweise ist es möglich, sich die Gesamtzahl der Zugriffe anzeigen zu lassen, wenn Sie sie für jede Entwickler-App oder jeden API-Proxy aufrufen.

Im Folgenden sind die Dimensionen aufgeführt, die Apigee standardmäßig bietet. Darüber hinaus können Sie eigene Dimensionen erstellen, wie unter API-Nachrichteninhalt mit benutzerdefinierten Analysen analysieren beschrieben.

Name der benutzerdefinierten Berichte Name, der in der Verwaltungs-API verwendet werden soll Beschreibung
Apigee-Entitäten
Access Token (Zugriffstoken) access_token Das OAuth-Zugriffstoken des Endnutzers der Anwendung.
API-Produkt API-Produkt

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 Das Wichtigste zuerst: 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)"?.

Cache-Schlüssel ax_cache_key

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.

Cache-Name ax_cache_name

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.

Quelle für Cache ax_cache_source

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.

Client-ID client_id

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, mit denen Generieren von OAuth-Tokens, wenn die Apps in Edge registriert werden. Weitere Informationen finden Sie unter Das Wichtigste zuerst: 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)"?.

Entwickler-App developer_app

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. Für 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)"?.

E-Mail-Adresse des Entwicklers developer_email

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 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)"?.

Entwickler-ID Entwickler

Die eindeutige von Edge generierte Entwickler-ID in Form von org_name@@@org_name

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)"?.

Umgebung Umgebung Die Edge-Umgebung, in der die API-Proxys bereitgestellt werden. Beispiel: "test" oder "prod".
Fehlercode bei Fehler ax_edge_execution_fault_code

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

Ablaufname bei Fehler ax_execution_fault
  _flow_name

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 zu verwenden ist, ax_Execution_ unabhängig_flow_name lautet. ohne Zeilenumbruch.

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

Ablaufressource flow_resource Nur Apigee. Sehen Sie diesen Community-Post, wenn Sie neugierig sind.
Ablaufstatus bei Fehler ax_execution_fault
  _flow_state

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 zu verwenden ist, ax_Execution_ unabhängig_flow_state, ohne Zeilenumbruch.

Gateway-Ablauf-ID gateway_flow_id Wenn API-Aufrufe durch Edge bewegt werden, erhält jeder Aufruf seine eigene Gateway-Fluss-ID. Beispiel: rrt329ea-12575-114653952-1. Die Gateway-Ablauf-ID ist nützlich, um Messwerte in Situationen mit hohem TPS zu unterscheiden, in denen andere Dimensionen wie Organisation, Umgebung und Zeitstempel bei den Aufrufen identisch sind.
Organisation Organisation Die Edge-Organisation, in der die API-Proxys bereitgestellt werden.
Richtlinienname bei Fehler ax_execution_fault
  _policy_name

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_Execution_ unabhängig_policy_name lautet. ohne Zeilenumbruch.

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.

Proxy apiproxy Der Computername (nicht der Anzeigename) eines API-Proxys.
Proxy-Basispfad proxy_basepath

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.

Suffix des Proxy-Pfads proxy_pathsuffix

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.

Proxy-Revision apiproxy_revision Die Revisionsnummer des API-Proxys, der API-Aufrufe verarbeitet hat. Dies bedeutet nicht unbedingt die neueste Revision eines API-Proxys. Wenn ein API-Proxy 10 Revisionen hat, kann die 8. Revision derzeit bereitgestellt werden. Außerdem können für eine API mehrere Versionen solange die Versionen unterschiedliche Basispfade haben, wie unter Proxys in der UI bereitstellen beschrieben.
Aufgelöste Client-IP-Adresse ax_resolved_client_ip

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 mit Routingprodukten wie Akamai die tatsächlichen IP-Adressen von Clients erfassen, Die Client-IP-Adresse wird im HTTP-Header True-Client-IP an Edge übergeben, der wird dann zum Festlegen der Dimension ax_true_client_ip verwendet.

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 einrichten, legen Sie für ax_resolved_client_ip den Wert erste lokale IP-Adresse in x_forwarded_for_ip.
  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 ist ist null, legen Sie für ax_resolved_client_ip den Wert (not set) fest.
Antwort-Statuscode response_status_code Der HTTP-Antwortstatuscode, der von Apigee zum Client weitergeleitet wird, z. B. 200, 404, 503 usw. In Edge kann der Antwortstatuscode des Ziels überschrieben werden mit wie Assign Message und Hear Fault, Daher kann sich diese Dimension vom Zielantwortcode (target_response_code) unterscheiden.
Virtueller Host virtual_host Der Name des virtuellen Hosts des an den API-Aufruf gesendet wurde. Zum Beispiel haben Unternehmen Virtuelle Hosts standardmäßig: default (http) und secure (https).
Eingehend/Client
IP-Adresse des Clients client_ip IP-Adresse des Systems, das den Router erreicht, z. B. der ursprüngliche Client (proxy_client_ip) oder ein Load-Balancer. Wenn die IP-Adresse X-Forwarded-For Header enthält die letzte aufgeführte IP-Adresse.
Gerätekategorie ax_ua_device_category Der Gerätetyp, von dem aus der API-Aufruf durchgeführt wurde, z. B. "Tablet" oder "Smartphone".
OS Family ax_ua_os_family Die Betriebssystemfamilie des anrufenden Geräts, z. B. "Android" oder "iOS".
Version des Betriebssystems ax_ua_os_version

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.

Proxy-Client-IP proxy_client_ip

Die IP-Adresse des aufrufenden Clients, die in der Ablaufvariablen proxy.client.ip gespeichert ist. Das ist oft die X-Forwarded-For-Adresse des eingehenden Anrufs, Dies ist der vom letzten externen TCP-Handshake empfangene IP-Adress-Edge. 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.

Weitergeleitete Client-IP-Adresse ax_true_client_ip

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

Zum Ermitteln der ursprünglichen IP-Adresse des Clients, auf den über ax_resolved_client_ip zugegriffen wird Dimension verwendet, verwendet Edge die ax_true_client_ip- und x_forwarded_for_ip Dimensionen.

Anfragepfad request_path

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.

Anfrage-URI request_uri

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.

Verb anfordern request_verb Das HTTP-Anforderungs-Verb in den API-Anforderungen, z. B. GET, POST, PUT, DELETE.
User-Agent useragent

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
User-Agent-Familie. ax_ua_agent_family Die Familie des User-Agents, z. B. "Chrome Mobile" oder "cURL".
User-Agent-Typ ax_ua_agent_type Der User-Agent-Typ, z. B. "Browser", "Mobiler Browser", "Bibliothek" usw.
User-Agent-Version ax_ua_agent_version

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.

Ausgehend/Ziel
Zielbasispfad target_basepath

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.

Zielhost target_host Der Host des Zieldienstes. Wenn ein API-Proxy beispielsweise http://mocktarget.apigee.net/help aufruft, ist der target_host mocktarget.apigee.net.
Ziel-IP-Adresse target_ip Die IP-Adresse des Zieldienstes, die die Antwort an den API-Proxy zurückgibt.
Zielantwortcode target_response_code

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).

Ziel-URL target_url

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.

In Proxy Verkettungen und bei Verwendung von Script Zielen (Node.js) auf, ist "target_url" im aufrufenden Proxy null.

X Forwarded For x_forwarded_for_ip

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

Zum Ermitteln der ursprünglichen IP-Adresse des Clients, auf den über ax_resolved_client_ip zugegriffen wird Dimension verwendet, verwendet Edge die ax_true_client_ip- und x_forwarded_for_ip Dimensionen.

Zeit
Wochentag ax_day_of_week Die aus drei Buchstaben bestehende Wochentag-Abkürzung, an der die API-Aufrufe vorgenommen wurden. Beispiel: Mo, Di, Mi.
Monat ax_month_of_year Der numerische Monat, in dem die API-Aufrufe ausgeführt wurden. Beispiel: "03" für März.
Tageszeit ax_hour_of_day

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.

Time Zone ax_geo_timezone Die allgemeinen Namen der Zeitzonen, aus denen die API aufgerufen wurde, z. B. America/New_York und Europe/Dublin.
Woche des Monats ax_week_of_month Die numerische Woche des Monats. Für API-Aufrufe, die in der 3. Woche eines Monats durchgeführt werden, ist ax_week_of_month beispielsweise 3.
Standorte
Ort ax_geo_city Die Stadt, von der aus die API-Aufrufe ausgeführt wurden.
Kontinent ax_geo_continent Der aus zwei Buchstaben bestehende Code des Kontinents, von dem aus die API-Aufrufe ausgeführt wurden. Zum Beispiel NA für Nordamerika.
Land ax_geo_country Der aus zwei Buchstaben bestehende Code des Landes, von dem aus die API-Aufrufe getätigt wurden. Zum Beispiel US für USA.
Region ax_geo_region Der mit Bindestrich versehene Code für die geografische Region, z. B. STATE-COUNTRY. Zum Beispiel WA-US für Washington-USA.
Region ax_dn_region Der Name des Apigee-Rechenzentrums, in dem API-Proxys bereitgestellt werden, z. B. us-east-1.
Monetarisierung
Nachricht zur Ignorieren der Transaktion minütlich x_apigee_mint_tx_ignoreMessage Flag, das angibt, ob Nachrichten im Zusammenhang mit der Monetarisierung ignoriert werden sollen. Für alle Monetarisierungsorganisationen auf false gesetzt.
Mint-Transaktionsstatus x_apigee_mint_tx_status Status einer Monetarisierungsanfrage, z. B. "Erfolg", "Fehler", "Ungültig" oder "Keine"

Filter

Mit Filtern können Sie die Ergebnisse auf Messwerte mit bestimmten Merkmalen beschränken. Im Folgenden finden Sie einige Beispielfilter. Verwenden Sie bei der Definition von Filtern Namen im Messwert- und Dimensions-API-Stil.

Gibt Messwerte für API-Proxys mit den Namensbüchern oder der Musik zurück:

filter=(apiproxy in 'books','music')

Gibt Messwerte für API-Proxys zurück, deren Namen mit "m" beginnen:

filter=(apiproxy like 'm%')

Gibt Messwerte für API-Proxys mit Namen zurück, die nicht mit "m" beginnen:

filter=(apiproxy not like 'm%')

Gibt Messwerte für API-Aufrufe mit Antwortstatuscodes zwischen 400 und 599 zurück:

filter=(response_status_code ge 400 and response_status_code le 599)

Gibt Messwerte für API-Aufrufe mit dem Antwortstatuscode 200 und dem Zielantwortcode 404 zurück:

filter=(response_status_code eq 200 and target_response_code eq 404)

Gibt Messwerte für API-Aufrufe mit dem Antwortstatuscode 500 zurück:

filter=(response_status_code eq 500)

Gibt Messwerte für API-Aufrufe zurück, die nicht zu Fehlern geführt haben:

filter=(is_error eq 0)

Folgende Operatoren können Sie zum Erstellen von Berichtsfiltern verwenden.

Operator Beschreibung
in In Liste aufnehmen
notin Von Liste ausschließen
eq Gleich, ==
ne Ungleich, !=
gt Größer als, >
lt Kleiner als, <
ge Größer als oder gleich, >=
le Kleiner als oder gleich, <=
like Gibt "true" zurück, wenn das Zeichenfolgenmuster mit dem angegebenen Muster übereinstimmt.
not like Gibt "false" zurück, wenn das Zeichenfolgenmuster mit dem angegebenen Muster übereinstimmt.
similar to Gibt "true" oder "false" zurück, je nachdem, ob das Muster mit der angegebenen Zeichenfolge übereinstimmt. Es ist mit like vergleichbar, es sei denn, es interpretiert das Muster mithilfe der Definition eines regulären Ausdrucks des SQL-Standards.
not similar to Gibt "false" oder "true" zurück, je nachdem, ob das Muster mit dem angegebenen String übereinstimmt. Es ist ähnlich wie not like, allerdings wird das Muster mit der Definition eines regulären Ausdrucks durch den SQL-Standard interpretiert.
and Ermöglicht die Verwendung von "und"-Logik, um mehr als einen Filterausdruck einzubeziehen. Der Filter enthält Daten, die alle Bedingungen erfüllen.
or Ermöglicht die Verwendung von 'oder' Logik, um verschiedene mögliche Filterausdrücke auszuwerten. Der Filter enthält Daten, die mindestens eine der Bedingungen erfüllen.