Metriken
Die Seite Metrics (Seitenleiste > Metrics) bietet dir eine tiefere analytische Ansicht deiner Nutzung. Sie enthält ein Panel, Usage, das deinen Traffic in Gruppen unterteilt und die Gesamtsummen für den gesamten Zeitraum über einer Zeilenseite anzeigt.
Für Übersichtskarten und Zeitverlaufsdiagramme nutze die Seite Dashboard Overview.
Product
Die Seite öffnet sich mit einer Product-Auswahl: API für die Requests, die du an die API-Endpoints sendest, Proxy für die Tunnel, die deine eigenen Tools über proxy.foura.ai öffnen. Jedes Produkt hat sein eigenes Usage-Panel mit eigenen Ansichten, Scopes und Spalten, da ein Tunnel keinen Request-Count und keine Credits hat. Die Auswahl wird gespeichert und ist per Deep-Link als #metrics/proxy erreichbar.
Filters
Über dem Panel: Product, Endpoints (nur API), Owner, dann Key (API) oder Proxy user (Proxy), danach Period. Owner und Period sind dieselben Steuerelemente wie auf Overview und teilen ihren Status, sodass ein Wechsel zwischen den beiden Seiten nie ändert, was du gerade betrachtest.
Owner-Filter
Everything, Personal oder eine deiner Organisationen. Er erscheint erst, sobald du mindestens einer Organisation angehörst. Die Auswahl eines Owners baut auch die Dropdowns für Key und Proxy user neu auf, sodass ein Credential des vorherigen Owners den Wechsel nicht überstehen und stillschweigend leere Ergebnisse liefern kann.
Key- und Proxy-User-Filter
Grenze die Seite auf ein einzelnes Credential ein. Es erscheinen nur Credentials, auf die du Zugriff hast: deine eigenen sowie die von Organisationen, denen du angehörst.
Period
Acht Buttons, 30M, 3H, 12H, 24H, 7D, 30D, 90D und 1Y, plus Custom für einen Kalendermonat, die letzten 6 Monate, den gesamten Zeitraum oder ein genaues Datumspaar.
Endpoints
Wähle beim API-Produkt Single, Proxy Finder, Browser oder Auto, um die Karten und die Tabelle auf einen Endpoint einzugrenzen. Ein Auto-Aufruf zählt einmal, unter Auto. Der Concurrency-Scope ist nicht verfügbar, solange ein Endpoint ausgewählt ist.
Das Usage-Panel
Das Panel beantwortet zwei Fragen gleichzeitig. Karten über der Tabelle beschreiben den gesamten Zeitraum: wie viele Gruppen er enthält und die Gesamtsummen über alle hinweg. Die Tabelle darunter ist eine Seite dieser Gruppen, sortiert nach der von dir gewählten Spalte.
Beide beziehen sich nie auf unterschiedlichen Traffic: Die Karten nutzen dasselbe Zeitfenster und dieselben Filter wie die Zeilen. Die Gruppenanzahl wird vollständig ausgeschrieben und nicht gerundet, da eine exakte Zahl die Frage beantwortet, wie viele Domains wir diesen Monat erreicht haben, und eine gerundete nicht.
Wenn du die Ansicht, den Scope oder den Zeitraum änderst, beginnt der Datensatz wieder auf der ersten Seite. Seite 4 der Domains ist nicht Seite 4 der Client-IPs.
Klicke auf einen Spaltenkopf, um zu sortieren. Die Sortierung springt wieder auf die größten Werte zuerst zurück, wenn du die Ansicht wechselst oder die Seite neu lädst. Klicke mit Strg oder Cmd auf einen Spaltenkopf, um sie zurückzusetzen.
Usage, API-Produkt
Drei Ansichten:
| Ansicht | Gruppiert Daten nach |
|---|---|
| API Key | Jedem Key, auf den du Zugriff hast |
| Client IP | Quelladressen, die die Requests senden |
| Domain | Ziel-Domains in deinen Requests |
Scope-Chips auf der rechten Seite ändern die Spalten und die Karten:
| Scope | Was angezeigt wird |
|---|---|
| Bandbreite | Request-Anzahl, Bytes In, Bytes Out und der Premium-Anteil dieser Bytes (Traffic über einen Premium-Exit, in den Gesamtwerten enthalten statt addiert) |
| Antwortzeit | Request-Anzahl, min, durchschnittliche und max Latenz |
| Gleichzeitigkeit | Request-Anzahl plus Anzahl gleichzeitiger Requests (nur API-Key-Ansicht) |
| Ergebnisse | Request-Anzahl plus Aufschlüsselung nach Ergebnis mit dem Ergebnis-Donut |
| Budget | Request-Anzahl und verbrauchte Credits, inklusive jedes Ergebnisses. Wähle einen Endpoint in der Endpoints-Zeile, um ihn einzeln zu sehen |
Der Budget-Scope liest die Credits-Metrik, die die API bei jedem Request meldet (siehe Response Headers). Diese Summen sind die rein gemessenen Ausgaben. Die Abrechnung zählt nur das Ergebnis success auf deinen Plan an, und die Overview-Credits-Karte zeigt beides nebeneinander.
Ergebnis-Donut
Unter dem Scope Ergebnisse zeigt ein Donut im Panel die Erfolgs- und Fehleraufteilung für den ausgewählten Zeitraum. Fahre über ein Segment, um die genaue Request-Anzahl und den Prozentsatz zu sehen. Er wird nur unter diesem Scope dargestellt, da ein Gesamtbild über einer Tabelle mit anderem Fokus verwirren würde.
Nutzung, Proxy-Produkt
Fünf Ansichten:
| Ansicht | Gruppiert Daten nach |
|---|---|
| Proxy-Benutzer | Jedem Proxy-Benutzer, auf den du Zugriff hast |
| Ziel | Dem Host, den jeder Tunnel erreicht hat |
| Exit-Land | Dem Land, aus dem der Tunnel ausgetreten ist |
| Client-IP | Der Adresse, von der die Verbindung kam |
| Ergebnis | Ergebnis und dessen Grund |
Vier Scopes:
| Scope | Spalten |
|---|---|
| Traffic | Tunnel, Bytes In, Bytes Out, Premium |
| Setup | Tunnel, Setup Min, Setup Avg, Setup Max, Duration Avg, Duration Max |
| Ergebnisse | Tunnel plus eine Spalte pro Ergebnis mit dem Ergebnis-Donut |
| Budget | Tunnel, Standard, Premium, Gesamt |
Setup ist die Wartezeit vor der Tunnelübergabe. Duration gibt an, wie lange er danach geöffnet blieb. Premium ist der Teil des Traffics, der über das Premium-Netzwerk lief, bereits im Gesamtwert enthalten und nicht dazu addiert.
Kein Scope hat eine Credits-Spalte oder eine Request-Anzahl. Der Inhalt eines CONNECT ist dein eigener verschlüsselter Traffic, daher zählt der Port nur Tunnel sowie Bytes und sonst nichts.
Ergebnistypen
Jeder API-Request wird genau einem Ergebnis zugeordnet. Nur success wird abgerechnet.
| Outcome | Layer | Bedeutung |
|---|---|---|
success |
n/a | Der Request lieferte eine gueltige Response. Ohne validate-Regeln bedeutet das HTTP 200. Mit validate-Regeln jede Response, die deine Regeln akzeptiert haben, unabhaengig vom Status. |
application_error |
target | Das Ziel gab HTTP 200 zurueck, aber der Body enthielt ein Fehlerfeld. |
application_fail |
target | Das Ziel gab einen Nicht-2xx-Code zurueck, den deine validate-Regeln nicht akzeptiert haben, oder gar keine Response. |
client_error |
caller | Dein Request wurde abgelehnt, bevor er FourA verlassen hat: ungueltige Parameter, ein fehlerhafter Proxy-Wert oder eine URL, die zu einer privaten oder reservierten Adresse aufloest. |
rate_limit |
FourA | Der Request wurde durch dein RPM- oder Concurrency-Limit abgelehnt. Siehe Rate Limits. |
service_error |
FourA | Die Engine antwortete mit einem Serverfehler oder mit einem Body, der nicht geparst werden konnte. |
service_fail |
FourA | Ein Netzwerkfehler: Timeout, Connection Refused, DNS-Fehler, Client-Disconnect. |
Die Spalte Layer zeigt, wer verantwortlich ist. target steht fuer die aufgerufene Website, caller bedeutet, dass dein Request fehlerhaft war, FourA bedeutet, dass wir ihn nicht verarbeiten konnten.
Wenn du validate.status.accept verwendest, um bestimmte Nicht-200-Codes zu erlauben (zum Beispiel [200, 403]), werden diese als success statt application_fail zurueckgegeben. Die Klassifizierung folgt dem Ergebnis der Engine anhand deiner Regeln, nicht dem reinen HTTP-Code.
Ein Tunnel ueber den Proxy-Port wird in dasselbe Vokabular eingeteilt, abzuglich der beiden target-Outcomes: Die Antwort eines Tunnels ist dein eigener verschluesselter Traffic, sodass FourA nie sieht, ob die Website dahinter erfolgreich war. Die vollstaendige Taxonomie und ihre Zuordnung zur Abrechnung findest du unter Request Outcomes.
Verwandte Themen
- Dashboard Overview: Summary-Karten, Timeline-Diagramme, Period und Detail (Detail gibt es nur in Overview)
- Request Outcomes: Die Outcome-Werte im Detail erklaert, fuer Requests und Tunnels
- Response Headers: Woher Credits stammen
- Proxy Port: Das Produkt, ueber das die Proxy-Ansichten berichten
- Organizations: Was der Owner-Filter abdeckt
- API Errors: Wie Fehler uebertragen werden