Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
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.
- Sie sehen die Namen der Benutzeroberfläche, wenn Sie benutzerdefinierte Berichte erstellen und verwalten.
- Verwenden Sie die API-spezifischen Namen, wenn Messwerte abrufen, Bericht erstellen Definition oder Bericht aktualisieren Definition.
Messwerte
Im Folgenden finden Sie die API-Messdaten, die Sie in benutzerdefinierten Berichten und Apigee API-Aufrufen abrufen können.
| Messwert | Name, der in der Apigee API verwendet werden soll | Funktionen | Beschreibung |
|---|---|---|---|
| Durchschnittliche Transaktionen pro Sekunde | tps |
Keine |
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: |
| Cache-Treffer | cache_hit |
Summe |
Anzahl erfolgreicher API-Anfragen, die API-Syntax: |
| Anzahl der L1-Cache-Elemente | ax_cache_l1_count |
avg, min, max |
Anzahl der Elemente im L1-Cache (im Arbeitsspeicher) pro Transaktion über einen bestimmten Zeitraum. Wenn Sie beispielsweise API-Syntax: |
| Verstöße gegen Richtlinien | policy_error |
Summe |
Die Gesamtzahl der Richtlinienfehler im angegebenen Zeitraum. Richtlinienfehler treten normalerweise konstruktionsbedingt auf. Die Ein Richtlinienfehler wird nur in der Analyse protokolliert, wenn der Fehler zum Ausfall des API-Proxys führt.
Beispiel: Wenn das Die Dimension „Richtlinienname bei Fehler“ ( Ein Zielfehler (z. B. API-Syntax: |
| 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. Die Proxy-Dimension ( API-Syntax: |
| Anfrageverarbeitungslatenz | request_processing_latency |
avg, min, max |
Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden, die Apigee zur Verarbeitung eingehender Anfragen benötigt. Die Zeit beginnt, wenn die Anforderung Apigee erreicht, und endet, wenn Apigee 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: |
| Größe der Anfrage | request_size |
sum, avg, min, max |
Die Größe der von Apigee empfangenen Anforderungsnutzlast in Byte. API-Syntax: |
| Antwort-Cache ausgeführt | ax_cache_executed |
Summe |
Gibt an, wie oft eine Da die Die Ausführung des Antwort-Caches ist jedoch 0, wenn das Klicken Sie im Debugging-Tool auf das Symbol API-Syntax: |
| Antwortverarbeitungslatenz | response_processing_latency |
avg, min, max |
Die Zeit (Durchschnitt, Minimum oder Maximum) in Millisekunden, die Apigee zur Verarbeitung von API-Antworten Apigee 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: |
| Größe der Antwort | response_size |
sum, avg, min, max |
Die Größe der an den Client zurückgegebenen Antwortnutzlast in Byte. API-Syntax: |
| Zielfehler | target_error |
Summe |
Gesamtzahl der API-Syntax: |
| Zielantwortzeit | target_response_time |
sum, avg, min, max |
Die Zeit (Summe, Durchschnitt, Minimum oder Maximum) in Millisekunden, in der der Zielserver auf einen Anruf antwortet. Diese Metrik gibt an, wie die Zielserver arbeiten. Die Zeit beginnt, wenn Apigee eine Anfrage an den Zieldienst weiterleitet, und endet, wenn Apigee die Antwort empfängt. Wenn ein API-Aufruf eine Antwort aus dem Cache zurückgibt (z. B. mit der Richtlinie API-Syntax: |
| Gesamtantwortzeit | total_response_time |
sum, avg, min, max |
Der Zeitraum (Summe, Durchschnitt, Minimum oder Maximum) in Millisekunden, nachdem Apigee eine Anfrage von einem Client empfangen hat und bis Apigee die Antwort an den Client zurück sendet. 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: |
| Traffic | message_count |
Summe |
Die Gesamtzahl der von Apigee 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: |
| Monetarisierung | |||
| Gebühren | fees |
sum, avg, min, max |
Betrag, der für die Einrichtungsgebühr, wiederkehrende Gebühren oder die Vorauszahlungen steht. API-Syntax: |
| Umsatzanteil des Entwicklers | x_apigee_mintng_dev_share |
sum, avg, min, max |
Anteil des Entwicklers am Umsatz einer Transaktion. Apigee berechnet den Anteil des Entwicklers nur, wenn Sie die Umgebungsvariable in Ihrem Tarif aktiviert haben. Der Anteil des Entwicklers wird mit der folgenden Formel berechnet: x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)
Der Wert des Anteilprozentsatzes wird aus Ihrem Tarif abgerufen. API-Syntax: |
| Monetarisierungspreis | x_apigee_mintng_price |
sum, avg, min, max |
Gesamtumsatz einer Transaktion.
Der Umsatz einer Transaktion wird auf den Wert der Monetarisierungsvariable API-Syntax: |
| API-Preismultiplikator | x_apigee_mintng_price_multiplier |
sum, avg, min, max |
Der Faktor (Multiplikator), mit dem die Kosten pro Transaktion multipliziert werden. Die Kosten pro Transaktion werden in den nutzungsbasierten Gebühren des Tarifs angegeben. API-Syntax: |
| Monetarisierungsraten | x_apigee_mintng_rate |
sum, avg, min, max |
Preis für eine Transaktion. Der für eine Transaktion berechnete Preis wird mithilfe der folgenden Formel berechnet: x_apigee_mintng_rate = (consumption-based pricing rate) * perUnitPriceMultiplier value
Der Wert des nutzungsbasierten Preises wird aus Ihrem Tarif abgerufen und der API-Syntax: |
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.
| Dimension | Name, der in der Apigee API verwendet werden soll | Beschreibung |
|---|---|---|
| Access Token (Zugriffstoken) | access_token |
Das OAuth-Zugriffstoken des Endnutzers der Anwendung. |
| API-Produkt | api_product |
|
| Cache-Schlüssel | ax_cache_key |
Schlüssel mit dem Wert Wenn Sie im Debugging-Tool eine |
| Cache-Name | ax_cache_name |
Name des Caches, der die Schlüssel/Werte enthält, die von der Wenn Sie im Debugging-Tool eine |
| Quelle für Cache | ax_cache_source |
Cache-Ebene (L1-In-Mem ory- oder L2-Datenbank), aus der Wenn Sie im Debugging-Tool die 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, die zum Generieren von OAuth-Token verwendet werden können, wenn die Apps in Apigee registriert werden. Weitere Informationen finden Sie unter Wie erstelle ich vollständige Analysedaten?. Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert |
| Entwickler-App | developer_app |
Die von Apigee registrierte Entwickleranwendung, 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 Wie erstelle ich vollständige Analysedaten?. Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert |
| E-Mail-Adresse des Entwicklers | developer_email |
|
| Entwickler-ID | developer |
Eindeutige von Apigee generierte Entwickler-ID im Format 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 Wie erstelle ich vollständige Analysedaten?. Wenn die oben genannten Kriterien nicht erfüllt werden, wird der Wert |
| Umgebung | environment |
Die Apigee-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 |
| Ablaufname bei Fehler | ax_execution_fault |
Der benannte Ablauf in einem API-Proxy, der einen Fehler ausgelöst hat. Beispiel: Beachten Sie, dass der vollständige Name, der in der Apigee API verwendet werden soll, Wenn keine Fehler aufgetreten sind, wird der Wert |
| Ablaufressource | flow_resource |
Nur Apigee. Weitere Informationen finden Sie unter So verwenden Sie die Dimension "Ressourcenfluss" in Analytics. |
| Ablaufstatus bei Fehler | ax_execution_fault |
Der Name des API-Proxy-Ablaufs gibt an, dass Fehler ausgelöst wurden, z. B. Beachten Sie, dass der vollständige Name, der in der Apigee API verwendet werden soll, |
| Gateway-Ablauf-ID | gateway_flow_id |
Wenn sich API-Aufrufe durch Apigee bewegen, erhält jeder Aufruf eine eigene Gateway-Ablauf-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 | organization |
Die Apigee-Organisation, in der die API-Proxys bereitgestellt werden. |
| Richtlinienname bei Fehler | ax_execution_fault |
Name der Richtlinie, die einen Fehler verursachte und zum Fehlschlagen des API-Aufrufs führte. Beachten Sie, dass der vollständige Name, der in der Apigee API verwendet werden soll, Wenn eine Richtlinie einen Fehler ausgibt, aber das Richtlinienstammattribut |
| Proxy | apiproxy |
Der Computername (nicht der Anzeigename) eines API-Proxys. |
| Proxy-Basispfad | proxy_basepath |
BasePath, der auf dem API-Proxy-ProxyEndpoint konfiguriert wurde. Der Basispfad enthält nicht die Domain und den Portteil der API-Proxy-URL. Wenn der Basis-URL eines API-Proxys beispielsweise Der Wert wird auch in der Ablaufvariablen |
| Proxy-Bereitstellungstyp | proxy_deployment_type |
Der API-Proxytyp für bereitgestellte Proxys. Wenn Sie einen Proxytyp angeben, werden die Ergebnisse auf diesen Proxytyp beschränkt. Mögliche Werte sind |
| Suffix des Proxy-Pfads | proxy_pathsuffix |
Ressourcenpfad zum API-Proxy-Basispfad hinzugefügt. Wenn die Basis-URL eines API-Proxys beispielsweise Wenn kein Der Wert wird auch in der Ablaufvariablen |
| 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 kann eine API mehrere Revisionen bereitgestellt haben, solange die Revisionen unterschiedliche Basispfade haben, wie unter Proxys bereitstellen beschrieben. |
| Aufgelöste Client-IP-Adresse | ax_resolved_client_ip |
Ausgangs-IP-Adresse des Clients. Der Wert der Dimension Wenn Sie Routing-Produkte wie Akamai verwenden, um die echten IP-Adressen von Clients zu erfassen, wird die Client-IP im HTTP-Header Der Wert der Dimension
|
| Antwort-Statuscode | response_status_code |
HTTP-Antwortstatuscode, der von Apigee zum Client weitergeleitet wird, z. B. 200, 404, 503 usw. In Apigee kann der Antwortstatuscode des Ziels mit Richtlinien wie AssignMessage-Richtlinie und RaiseFault-Richtlinie überschrieben werden. Aus diesem Grund kann diese Dimension vom Zielantwortcode (target_response_code) abweichen. |
| Virtueller Host | virtual_host |
Der Name des virtuellen Hosts, für den der API-Aufruf durchgeführt wurde, Weitere Informationen finden Sie unter Umgebungen und Umgebungsgruppen. |
| 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 |
Typ des Geräts, von dem aus der API-Aufruf durchgeführt wurde, z. B. Tablet oder Smartphone. |
| OS Family | ax_ua_os_family |
Betriebssystemfamilie des Geräts, das den Aufruf durchführt, 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, diese Option als zweite Aufschlüsselungsdimension mit der Betriebssystemfamilie (ax_ua_os_family) zu verwenden, um die Versionen der Betriebssysteme anzuzeigen. |
| Proxy-Client-IP | proxy_client_ip |
IP-Adresse des aufrufenden Clients, die in die Ablaufvariable |
| Weitergeleitete Client-IP-Adresse | ax_true_client_ip |
Wenn Sie Routingprodukte wie Akamai verwenden, um die wahren IP-Adressen von Clients zu erfassen, werden die Client-IPs im HTTP-Header Zur Ermittlung der ursprünglichen Client-IP-Adresse, auf die über die Dimension |
| Anfragepfad | request_path |
Der Ressourcenpfad (nicht die Domain) zum Zieldienst, mit Ausnahme der Abfrageparameter. Das Apigee-Beispielziel |
| Anfrage-URI | request_uri |
Der Ressourcenpfad (nicht die Domain) zum Zieldienst, mit Ausnahme der Abfrageparameter. Das Apigee-Beispielziel |
| Verb anfordern | request_verb |
Das HTTP-Anforderungs-Verb in den API-Anforderungen, z. B. GET, POST, PUT, DELETE. |
| User-Agent | useragent |
Name des User-Agents oder Software-Agents, der für den API-Aufruf verwendet wird. Beispiele:
|
| User-Agent-Familie. | ax_ua_agent_family |
Familie des User-Agents, z. B. Chrome Mobile oder curl |
| User-Agent-Typ | ax_ua_agent_type |
Der Useragent-Typ, z. B. Browser, Mobile Browser, Library usw. |
| User-Agent-Version | ax_ua_agent_version |
Version des User-Agents. Es ist nützlich, diese Option als zweite Aufschlüsselungsdimension mit der User-Agent-Familie (ax_ua_agent_family) zu verwenden, um die Version der Agent-Familie abzurufen. |
| Ausgehend/Ziel | ||
| Ziel | target |
Zielendpunkt, der die Anfrage bearbeitet hat. z. B. default |
| Zielbasispfad | target_basepath |
Der Ressourcenpfad (mit Ausnahme der Domain) zum Zieldienst ohne Abfrageparameter, der in den 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 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 Debugging-Tool das AX-Symbol am Ende des Ablaufdiagramms auswählen, wird die |
| gRPC-Dienstname | x_apigee_grpc_service_name |
Gilt nur, wenn der Zieldienst gRPC ist. Der gRPC-Dienstname. Informationen zu gRPC-Proxys finden Sie unter gRPC API-Proxys erstellen. |
| gRPC-Status | x_apigee_grpc_status |
Gilt nur, wenn der Zieldienst gRPC ist. Der gRPC-Anfragestatus. Informationen zu gRPC-Proxys finden Sie unter gRPC API-Proxys erstellen. |
| Zielhost | target_host |
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 |
HTTP-Antwortstatuscode, der vom Zieldienst an den API-Proxy zurückgegeben wird, z. B. Der Wert Dies unterscheidet sich von der Dimension Antwortstatuscode (response_status_code). |
| gRPC-RPC-Name | x_apigee_grpc_rpc_name |
Gilt nur, wenn der Zieldienst gRPC ist. Der RPC-Name. Informationen zu gRPC-Proxys finden Sie unter gRPC API-Proxys erstellen. |
| 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 Beachten Sie, dass die URL auch während der API-Proxy-Verarbeitung mit der Bei der Proxy-Verkettung ist die Ziel-URL im aufrufenden Proxy null. |
| X-Forwarded-For IP | x_forwarded_for_ip |
Die Liste der IP-Adressen im Zur Ermittlung der ursprünglichen Client-IP-Adresse, auf die über die Dimension |
| X-Forwarded-For Proto | x_forwarded_proto |
Protokoll, mit dem der Client eine Verbindung zum Router hergestellt hat. Gültige Werte sind |
| Zeit | ||
| Wochentag | ax_day_of_week |
Die aus zwei 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. |
| Zeitzone | ax_geo_timezone |
Allgemeine Namen der Zeitzonen, aus denen die API-Aufrufe durchgeführt wurden, z. B. America/New_York und Europe/Dublin. |
| Woche des Monats | ax_week_of_month |
Numerische Woche des Monats. Für API-Aufrufe, die in der 3. Woche eines Monats durchgeführt werden, ist der ax_week_of_month beispielsweise 3. |
| Standort | ||
| Stadt | 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 Landes, von dem aus die API-Aufrufe getätigt 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 die USA. |
| Region | ax_geo_region |
Codierter Code für die geografische Region, z. B. STATE-COUNTRY. Beispiel: WA-US für Washington-USA. |
| Region | ax_dn_region |
Name des Apigee-Rechenzentrums, in dem API-Proxys bereitgestellt werden, z. B. us-east-1. |
| Monetarisierung | ||
| Erstellt | created |
Derzeit in Apigee-Organisationen verfügbar, nicht in Apigee Hybrid-Organisationen. Unix-Zeitstempel, wenn der Gebührenzeitplan für den Anwendungsentwickler und das API-Produkt hinzugefügt wurde. |
| Gebührentyp | fees_type |
Art der Gebühr. Dabei kann es sich um eine Einrichtungsgebühr, eine wiederkehrende Gebühr oder eine Vorauszahlung handeln. Dieser Wert wird nur ausgefüllt, wenn Sie den Messwert Fees ausgewählt haben. |
| Währung des Umsatzes | x_apigee_mintng_currency |
|
| Tarifpaket-ID | x_apigee_mintng_rate_plan_id |
Derzeit in Apigee-Organisationen verfügbar, nicht in Apigee Hybrid-Organisationen. Der Monetarisierungstarif für den Anwendungsentwickler. |
| Transaktionserfolg | x_apigee_mintng_tx_success |
Der Monetarisierungsstatus der Transaktion wird auf den Wert der Monetarisierungsvariable transactionSuccess festgelegt, die in Ihrer DataCapture-Richtlinie erfasst wird. |
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 mit Namen zurück, die 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)
Gibt Messwerte für API-Aufrufe zurück, die nicht zu Fehlern in null-Antworten geführt haben:
filter=(response_status_code isnot null)
Folgende Operatoren können Sie zum Erstellen von Berichtsfiltern verwenden.
| Operator | Beschreibung |
|---|---|
in |
In Liste aufnehmen |
notin |
Von Liste ausschließen |
is |
Verwenden Sie response_status_code is null, um nach Antworten mit dem Statuscode null zu filtern. |
isnot |
Verwenden Sie response_status_code isnot null, um nach Antworten zu filtern, deren Statuscode nicht null ist. |
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 der AND-Logik, um mehr als einen Filterausdruck einzubeziehen. Der Filter enthält Daten, die alle Bedingungen erfüllen. |
or |
Ermöglicht die Verwendung der OR-Logik, um verschiedene mögliche Filterausdrücke auszuwerten. Der Filter enthält Daten, die mindestens eine der Bedingungen erfüllen. |