داده‌های مصرف
چهار رفتاری که در یکپارچهسازیها بیشترین خطا را ایجاد میکنند: مقادیر اندازهگیرینشده، فیلدهایی که بسته به نوع خالی‌اند، شمارش اتصال‌ها و محدودیت ترافیکی که به اندازه‌گیری وابسته نیست.
این رفتارها خرابی نیستند؛ نشان می‌دهند داده بسته به نوع سرویس و بک‌اند چگونه تولید می‌شود.
اندازه‌گیری نشد، نه صفر
اگر بک‌اند در دسترس نباشد، شمارنده‌ها null برمی‌گردند، نه 0. فیلد usage.available را بررسی کنید؛ اگر مقادیر null را مانند صفر نمایش دهید، به مشتری گفته‌اید «اصلاً مصرف نکرده‌ای».
const { usage } = (await res.json()).data;
const label = usage.available ? `${usage.gb_used} GB` : "فعلاً قابل اندازه‌گیری نیست";فیلدهایی که بسته به نوع همیشه خالی‌اند
خرابی نیست؛ آن بک‌اند این داده را تولید نمی‌کند.
| فیلد | ISP / Datacenter / Gaming | Mobile / Residential |
|---|---|---|
success_count | ✓ | null |
error_count | ✓ | null |
active_connections | null | ✓ |
source | logs | proxy_controller |
در خانواده ISP، درخواست = اتصال
در ISP، Datacenter و Gaming، فیلدهای total_requests، success_count، error_count و requests در تاریخچه مصرف،اتصال‌ها را می‌شمارند؛ یک اتصال keep-alive می‌تواند چند درخواست HTTP را حمل کند. bytes_in داده دانلودشده و bytes_out داده آپلودشده است.
gb_limit مستقل از اندازه‌گیری است
حتی اگر available برابر false باشد، gb_limit ممکن است مقدار داشته باشد؛ محدودیت از پایگاه داده خوانده می‌شود.
تاریخچه مصرف
GET /orders/{id}/usage-history یک سری روزانه برمی‌گرداند. در خانواده ISP، requests اتصال‌هایی را می‌شمارد که در آن روز بسته شده‌اند و درMobile/Residential درخواست‌های آن روز را. اگر meta.available برابر false باشد، یک منبع خوانده نشده است و روزهای ناقص به معنای مصرف صفر نیستند؛ اگر هیچ چیز خوانده نشود، 503 service_unavailable برمی‌گردد.