Nutzungsdaten
Die vier Verhaltensweisen, die in Integrationen am häufigsten zu Fehlern führen: nicht messbare Werte, typabhängig leere Felder, die Zählung von Verbindungen und ein Traffic-Limit, das nicht von der Messung abhängt.
Diese Verhaltensweisen sind keine Störungen; sie spiegeln wider, wie die Daten je nach Diensttyp und Backend entstehen.
Nicht gemessen heißt nicht 0
Ist das Backend nicht erreichbar, liefern die Zähler null, nicht 0. Prüfen Sie das Feld usage.available; wer null-Werte als 0 anzeigt, vermittelt dem Kunden, er habe „nichts verbraucht“.
const { usage } = (await res.json()).data;
const label = usage.available ? `${usage.gb_used} GB` : "Derzeit nicht messbar";Felder, die je nach Typ immer leer sind
Keine Störung; das jeweilige Backend erzeugt diese Daten nicht.
| Feld | ISP / Datacenter / Gaming | Mobile / Residential |
|---|---|---|
success_count | ✓ | null |
error_count | ✓ | null |
active_connections | null | ✓ |
source | logs | proxy_controller |
In der ISP-Familie gilt: Anfrage = Verbindung
Bei ISP, Datacenter und Gaming zählen total_requests, success_count, error_count und requests im Nutzungsverlauf Verbindungen; eine einzelne Keep-Alive-Verbindung kann mehrere HTTP-Anfragen transportieren. bytes_in sind heruntergeladene, bytes_out hochgeladene Daten.
gb_limit ist unabhängig von der Messung
Auch wenn available false ist, kann gb_limit gefüllt sein; das Limit wird aus der Datenbank gelesen.
Nutzungsverlauf
GET /orders/{id}/usage-history liefert eine Tagesreihe. In der ISP-Familie zählt requests die an diesem Tag geschlossenen Verbindungen, bei Mobile/Residential die Anfragen des Tages. Ist meta.available false, konnte eine Quelle nicht gelesen werden, und fehlende Tage bedeuten keine Nullnutzung; kann gar nichts gelesen werden, kommt503 service_unavailable zurück.