Метрики успішності проксі та затримки API

Які метрики показують успішність проксі та затримку для API-запитів

API-трафік здається простим, доки між вашим клієнтом і сервером не стає проксі. Запит може повернути 200, але все одно бути поганим результатом, якщо він прийшов занадто пізно для 5-секундного тайм-ауту або якщо проксі додав 900 мс до отримання першого байта. Питання не в тому, «чи спрацював проксі?». Питання в тому, чи спрацював він для того API-запиту, який ви насправді надіслали.

Ця різниця важлива в реальних системах із JSON-навантаженнями, заголовками автентифікації та жорсткими правилами повторних спроб. Виклик входу та масове отримання даних не ламаються однаково. Одне середнє значення дуже швидко приховує цю різницю.

1. Визначте результат API-запиту, який ви насправді вимірюєте

Почніть із нумерованої межі: успішність хопу через проксі, успішність HTTP-відповіді та бізнес-успіх. Успішний хоп через проксі означає, що з’єднання дісталося API через проксі. HTTP-успіх означає, що сервер повернув дійсну відповідь, навіть якщо це був 401 або 429. Бізнес-успіх означає, що API-виклик виконав потрібне вам завдання, наприклад створив запис, прочитав профіль або оновив токен.

Такий поділ рятує команди від суперечок через одну оманливу цифру. POST, який повертає 201, — це корисний API-успіх. GET, який повертає 200 з порожнім тілом, може бути невдачею для вашого робочого процесу. 200 — не завжди перемога.

Для звітності API позначайте кожен запит одним кодом результату ще до будь-якого підсумовування. Достатньо простого набору категорій: проксі не спрацював, HTTP не спрацював, корисне навантаження відхилено, придатна відповідь, завдання виконано. Категорії мають бути чіткими, бо «успішність» різні люди розуміють по-різному.

Якщо ваша команда також працює з браузерними сценаріями, терміни можуть швидко змішуватися. Короткий довідник на кшталт VPN і проксі-терміни допомагає новим співробітникам не плутати транспортні терміни з термінами рівня застосунку. Але звіт по API все одно має залишатися самодостатнім.

2. Розділяйте успішність за класом запиту та методом

Не зводьте GET, POST, PUT і автентифікаційні виклики в одну групу. GET-запити часто виглядають чистими, бо вони ідемпотентні та менші. POST і PUT можуть помилятися через структуру тіла, перевірки CSRF або серверну валідацію, яка взагалі не впливає на GET. Одне число цього не пояснить.

Поділ на рівні методу корисний навіть у невеликому API-клієнті. Кінцева точка для оновлення токена може успішно працювати 99 разів із 100, тоді як POST для масового оновлення може падати у 12% випадків, тому що проксі додає затримку, а сервер відхиляє застарілі сигнатури. Це різні проблеми, і для них потрібні різні графіки.

Також тримайте окремо виклики, пов’язані з автентифікацією. 401 під час входу, 403 під час обміну токена та 200 під час отримання даних не слід змішувати. Це поширена помилка, коли команди дивляться лише на успішність за ім’ям хоста.

Якщо ваша схема проксі залежить від обробки облікових даних, варто поєднати ці метрики з кращими практиками автентифікації проксі. Помилка автентифікації — це не затримка, але вона спотворить ті самі журнали запитів, якщо ви не позначите її уважно.

3. Використовуйте діапазони наскрізної затримки, а не лише одне середнє

Одна середня величина затримки зручна, але часто марна. Шлях через проксі зі середнім значенням 180 мс усе одно може давати викиди на 2,4 секунди, які ламають тайм-аут клієнта. p50, p95 і p99 показують різні речі, і для API-роботи потрібні всі три.

Використовуйте p50, щоб зрозуміти звичайний випадок. Використовуйте p95, щоб побачити, що відчуває більшість користувачів у завантажену годину. Використовуйте p99, щоб спіймати неприємний хвіст, який спричиняє повторні спроби, тайм-аути та злі тикети. Хвіст важливий, бо API-клієнти зазвичай ламаються на повільному краю, а не на середньому значенні.

Практичне правило таке: якщо розрив p95 між прямим трафіком і трафіком через проксі збільшується більш ніж на одну секунду, на проксі-шлях варто подивитися уважніше. Точний поріг залежить від тайм-ауту вашого API та бізнес-правил. Платіжний API менш терплячий, ніж API метаданих.

Медіана затримки теж може обманювати через замовчування. Пул проксі зі змішаними виходами може показувати приємний p50 і все одно не витримувати пікове навантаження. Саме тому діапазони затримки кращі за одну лінію на дашборді.

4. Вимірюйте додану проксі затримку на межі клієнта

Щоб ізолювати вартість проксі, вимірюйте на межі клієнта — до хопу через проксі та після повернення відповіді. Якщо ваша HTTP-бібліотека підтримує таймінгові хуки, окремо фіксуйте DNS, з’єднання, TLS, перший байт і загальний час. Це дає чисту цифру доданої проксі-затримки замість розмитого припущення.

Корисне порівняння — через проксі проти напряму, з тим самим endpoint, методом, payload і тайм-аутом. Якщо прямий GET /v1/profile займає 240 мс, а версія через проксі — 510 мс, проксі додав приблизно 270 мс на цьому шляху. Це конкретна різниця, а не теорія.

Не змішуйте в цю цифру час обробки на сервері, якщо в цьому немає потреби. Якщо сам API має змінну поведінку, вам потрібен контрольний прогін із прямого клієнта або стабільний еталонний маршрут. Інакше в повільній роботі API звинуватять проксі.

Деякі команди зберігають коротку примітку щодо таймінгу в код-рев’ю або runbook: запустити таймер перед відправкою запиту, зупинити після повного читання тіла, записати маршрут проксі. Цього трикрокового звичаю достатньо для більшості API-клієнтів. І він також скорочує суперечки.

5. Відокремлюйте вартість першого запиту від продуктивності повторно використаного з’єднання

Повторне використання з’єднання змінює форму проксі-затримки. Перший запит часто оплачує налаштування TCP, TLS, автентифікацію проксі, а інколи й DNS. Наступні запити на тому самому з’єднанні можуть бути значно швидшими. Якщо змішати їх у середнє, перший запит покарає решту.

Для API-клієнтів, які тримають з’єднання відкритими, розділяйте «холодні» та «теплі» запити. «Холодний» означає нове з’єднання або нову сесію. «Теплий» означає, що з’єднання вже існує, а рукостискання з проксі завершено. Цей поділ особливо важливий для клієнтів, які виконують 20 або більше викликів за один прогін.

Проксі може виглядати повільним на запиті 1 і нормальним на запиті 2. Це не означає, що проксі поганий. Це може означати, що вартість рукостискання висока, але стабільний трафік прийнятний. Яке число вам важливе, залежить від того, чи виконує ваше завдання один виклик, чи 1 000.

Тут доречна примітка про тип проксі. Якщо ваш стек використовує SOCKS5 для одних маршрутів і HTTP для інших, поведінка з’єднання може відрізнятися настільки, що їх варто порівнювати напряму. Просте порівняння на кшталт проксі SOCKS5 проти HTTP-проксі стосується не лише веб-скрапінгу; воно також допомагає, коли ви обираєте транспорт для API-сесій.

6. Сегментуйте метрики за чутливістю endpoint і розміром payload

Не кожна API-кінцева точка однаково реагує на проксі. Невеликі GET-запити часто проходять легко. Великі тіла POST, підписані запити або кінцеві точки з жорстким контролем часу можуть помилятися частіше. Розділяйте числа за сімействами endpoint, а не лише за хостом.

Розмір payload варто відстежувати, бо він змінює і затримку, і частоту збоїв. JSON-об’єкт на 2 КБ може пройти з першого разу, тоді як завантаження на 2 МБ натрапить на тайм-аут або ліміт буфера проксі. Великі payload також можуть посилювати ціну повторних спроб. Одна додаткова повторна спроба для великого запиту коштує дорого.

Заголовки теж мають значення. Деякі API чутливі до кількості заголовків, їхнього порядку або довгих токенів автентифікації. Якщо проксі переписує заголовки або видаляє поле, помилка може з’явитися лише на одному маршруті. Саме тому вам потрібні метрики на рівні endpoint, а не одне середнє по всьому сайту.

Коли потрібно пояснити, чому один маршрут повільніший, допомагає деталізація маршруту. Відстежуйте назву маршруту, клас payload і код відповіді разом. Метриці без цих трьох міток довіряти важко.

7. Відстежуйте пари «збій — затримка» під час повторних спроб і rate limiting

Повторні спроби можуть зробити поганий проксі кращим, ніж він є. Якщо перший виклик отримує 429, другий успішний, а третій уже не потрібен, ваш сирий показник успішності може виглядати нормально. Справжня історія — у парі: спершу збій, потім успіх і час, витрачений на очікування між ними.

Записуйте кількість повторних спроб, затримку backoff і фінальний результат для кожного класу запитів. Це дає різницю між «зрештою успішно» та «успішно без проблем». Для API-роботи під rate limiting саме друге число робить систему передбачуваною.

Слідкуйте за патернами 429 і 5xx разом. 429 може означати, що проксі-маршрут упирається в спільний ліміт. 502 або 504 можуть означати, що шлях нестабільний. Якщо частота повторних спроб зростає одночасно з p95 затримки, проксі та API можуть підсилювати проблеми одне одного.

Тут же стає операційно корисною точна фраза з назви: які метрики показують успішність проксі та затримку для API-запитів, не відповість одна плитка на дашборді. Вам потрібні журнал повторних спроб, діапазон затримки та код помилки в одному рядку. Три колонки кращі за один графік.

Для команд, які керують багатьма виходами, посібник з ротації проксі для веб-скрапінгу теж може бути корисним, бо політики ротації впливають на поведінку повторних спроб навіть поза скрапінгом. Те саме стосується й зміни маршрутів: якщо ви ротуватимете занадто агресивно, можна приховати поганий шлях замість того, щоб його виміряти.

8. Побудуйте легку оціночну картку вибору проксі для API-робочих процесів

Оціночній картці не потрібно 20 полів. П’яти чи шести метрик достатньо, якщо це правильні метрики: успішність хопу через проксі, успішність HTTP, p95 затримки, p99 затримки, вартість першого запиту та скоригована на повторні спроби успішність завершення. Цього списку достатньо, щоб прочитати його на одному екрані.

Оцінюйте кожен пул проксі на одному API-робочому процесі. Якщо робочий процес — оновлення токена, вимірюйте оновлення токена. Якщо це масовий пошук профілів, вимірюйте масовий пошук профілів. Постачальник, який виграє на дрібних GET, може сильно програвати на підписаних POST.

Для кожного пулу використовуйте просту примітку «прохід/провал»: вкладається в тайм-аут, перевищує тайм-аут, стабільний на теплих з’єднаннях або нестабільний під час повторних спроб. Ці позначки прості — саме тому вони працюють. Химерні назви зазвичай лише ховають деталі.

Якщо ваша команда ще обирає між постачальниками, поряд із метриками може лежати примітка про вартість. Стаття скільки коштує проксі допоможе порівняти гроші із затримкою, бо дешевий проксі, який додає 800 мс, на практиці може виявитися дорогим варіантом. Ціна не повинна бути важливішою за успішність запиту.

Проста таблиця звіту для тестів API через проксі

Що тримати на тій самій сторінці, що й метрики

Тримайте поруч із цифрами метод запиту, endpoint, розмір payload, маршрут проксі та тайм-аут. Без цих п’яти полів графік успішності перетворюється на ворожіння. З ними ви можете пояснити, чому один маршрут повільний, а інший — ні.

API-трафік винагороджує нудну дисципліну. Вимірюйте перший запит окремо. Порівнюйте GET і POST окремо. Стежте за p95, а не лише за середнім. Цього достатньо, щоб більшість команд зробили чистіший вибір проксі.

І ще одна практична деталь: якщо маршрут ламається лише тоді, коли є заголовки автентифікації, записуйте це як збій на рівні конкретного маршруту, а не як загальну помилку проксі. Різниця невелика, але вона економить години потім.

Коротко: як мислити про метрики проксі для API

Коли вам потрібні метрики успішності проксі для API, не зупиняйтеся на одному відсотку успіху. Розділяйте транспорт, HTTP і бізнес-результат. Далі дивіться на те, як виміряти затримку API через проксі, на межі клієнта, з тим самим endpoint і тим самим payload. І обов’язково відстежуйте p95 p99 затримка API через проксі, щоб побачити не лише середній шлях, а й повільний хвіст, який найчастіше ламає робочий процес.