Если прокси используются в продакшене — для парсинга, автоматизации SMM-аккаунтов или масштабного мультиаккаунтинга — рано или поздно наступает момент, когда «вроде работает» перестаёт быть достаточным ответом. Нужны цифры: сколько запросов падает с ошибкой, насколько выросла задержка после смены пула IP, не исчерпан ли лимит трафика у провайдера. Разбираем 7 метрик, которые стоит собирать в Prometheus и визуализировать в Grafana, чтобы видеть проблемы раньше, чем их увидят пользователи или заблокированные аккаунты.
Зачем вообще мониторить прокси в продакшене
Прокси — это не статичная инфраструктура вроде сервера с фиксированным IP. Это постоянно меняющийся пул адресов, поведение которого зависит от провайдера, нагрузки, региона и даже времени суток. Без мониторинга вы узнаёте о проблеме только тогда, когда парсер Wildberries или Ozon перестаёт отдавать данные, рекламный кабинет Facebook Ads блокирует аккаунт, или скрипт автоматизации Instagram начинает сыпать капчами.
Задача мониторинга — превратить субъективное «что-то не так» в конкретные цифры: доля ошибок выросла с 2% до 15% за последний час, средняя задержка увеличилась в три раза, трафик по одному прокси превысил лимит. Это позволяет реагировать до того, как проблема станет критичной — автоматически переключить пул, заменить провайдера или снизить частоту запросов.
Для сбора метрик используем связку Prometheus (хранение временных рядов) + Grafana (визуализация и алерты). Это стандартный стек в DevOps, который легко интегрируется с любым языком — Python, Node.js, Go. Ниже — примеры на Python с библиотекой prometheus_client, но принцип универсален.
Метрика 1: Success Rate — доля успешных запросов
Это базовая метрика, которая первой сигнализирует о проблемах с прокси-пулом. Считается как отношение запросов с кодом ответа 200-299 к общему числу запросов за период времени. Падение success rate ниже 90% обычно означает, что часть IP в пуле забанена целевым сайтом или провайдер отдаёт нестабильные адреса.
Пример инструментирования на Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Всего запросов через прокси',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # эндпоинт для Prometheus scrape
PromQL-запрос для расчёта success rate за последние 5 минут:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Если вы работаете с несколькими типами прокси одновременно — например, резидентными прокси для соцсетей и прокси дата-центров для парсинга — имеет смысл разбивать success rate по лейблу proxy_pool, чтобы видеть, какой именно пул деградирует.
Метрика 2: Latency — задержка ответа
Задержка показывает, насколько быстро прокси отдаёт ответ. Резкий рост latency часто предшествует падению success rate — провайдер перегружен, или IP уже близок к блокировке и целевой сервер начинает намеренно тормозить ответы. Для latency важно собирать не только среднее значение, но и перцентили — p50, p95, p99, так как среднее скрывает хвостовые задержки, которые реально мешают работе.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Длительность запроса через прокси',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
PromQL для p95 latency:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Для задач, где скорость критична — например, при автоматизации TikTok Ads, где каждая секунда на загрузку страницы увеличивает риск таймаута в антидетект-браузере — стоит выставить алерт на p95 выше 3-4 секунд.
Метрика 3: Error Rate по типам ошибок
Простого success/failure недостаточно для диагностики. Нужно разделять ошибки по типам: 407 (Proxy Authentication Required) означает проблему с авторизацией, 429 (Too Many Requests) — превышение лимита запросов, таймауты — проблему сети, 403 — блокировку по антибот-защите целевого сайта. Каждый тип ошибки требует разной реакции.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Ошибки прокси по типу',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
Таблица типичных ошибок и их причин:
| Код/тип | Вероятная причина | Что проверить |
|---|---|---|
| 407 | Неверные креды или истёкшая сессия | Логин/пароль прокси, формат строки подключения |
| 429 | Превышен лимит запросов на IP | Частоту запросов, размер пула |
| 403 | Антибот-защита целевого сайта | User-Agent, fingerprint, тип прокси |
| timeout | Перегрузка провайдера или сети | Нагрузку на пул, таймаут-настройки клиента |
Метрика 4: Скорость ротации и живучесть IP
Если вы используете ротирующиеся прокси, важно знать, как часто меняется IP и сколько запросов успевает пройти до того, как адрес «сгорает» (банится целевым сайтом). Эта метрика особенно критична для мультиаккаунтинга — например, при фарме Facebook Ads аккаунтов через Dolphin Anty или AdsPower, где преждевременная смена IP может оборвать сессию и триггернуть проверку безопасности.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Время жизни IP до ротации',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Сколько запросов прошло до бана IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Для мобильных прокси эта метрика ведёт себя иначе, чем для резидентных — ротация через смену базовой станции оператора даёт более «чистые» IP с меньшей вероятностью бана. Если ваша задача — именно SMM-автоматизация с высокой чувствительностью к банам, стоит сравнить показатели живучести IP между мобильными прокси и резидентными на реальных данных из вашего дашборда, а не полагаться на общие рекомендации.
Метрика 5: Bandwidth — потребление трафика
Большинство тарифов на прокси считаются по объёму трафика, а не по количеству запросов. Без мониторинга легко упустить момент, когда лимит почти исчерпан — особенно если задача включает загрузку изображений или видео, например при парсинге карточек товаров Wildberries с большим количеством фотографий.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Потреблённый трафик через прокси',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
На дашборде Grafana полезно строить не абсолютное значение трафика, а скорость его расхода (rate) — это помогает прогнозировать, когда закончится лимит, и заранее планировать докупку или переключение на другой пул.
Метрика 6: Geo-распределение и соответствие региону
Для маркетологов, тестирующих рекламу из разных стран, и для арбитражников, работающих с гео-таргетингом в Google Ads или TikTok Ads, критично, чтобы IP реально соответствовал заявленному региону. Ошибка геолокации может привести к показу рекламы не той аудитории или блокировке аккаунта за несоответствие гео-настроек.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Случаи несовпадения заявленного и фактического гео',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
Рекомендуется проверять гео не на каждом запросе (это дорого по трафику и времени), а периодически — раз в час на выборке IP из пула, достаточной для статистической уверенности.
Метрика 7: Concurrent Connections — параллельные сессии
Количество одновременных соединений через прокси показывает реальную нагрузку на пул. Если параллельных сессий больше, чем IP в пуле способны обработать без деградации, это напрямую приводит к росту latency и error rate из предыдущих пунктов. Эта метрика особенно важна при масштабировании — когда SMM-агентство увеличивает число одновременно работающих аккаунтов клиентов с 10 до 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Текущие активные соединения через прокси',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
Сопоставление этой метрики с error rate на одном графике в Grafana быстро покажет корреляцию: как только число параллельных сессий превышает определённый порог, ошибки начинают расти нелинейно.
Настройка дашборда в Grafana: пошагово
После того как метрики инструментированы и Prometheus их собирает, нужно визуализировать данные в Grafana. Порядок действий:
- Добавьте Prometheus как источник данных: Configuration → Data Sources → Add data source → Prometheus, укажите URL вашего Prometheus-сервера (обычно
http://localhost:9090). - Создайте новый дашборд: Create → Dashboard → Add new panel.
- Для панели Success Rate используйте PromQL-запрос из раздела про метрику 1, тип визуализации — Gauge или Time series.
- Для Latency создайте панель с типом Heatmap, чтобы видеть распределение p50/p95/p99 во времени.
- Для Error Rate постройте Stacked Bar Chart с разбивкой по лейблу
error_type— это наглядно покажет, какой тип ошибок доминирует. - Добавьте переменную дашборда (Dashboard Settings → Variables) для
proxy_pool, чтобы переключаться между пулами без создания отдельных дашбордов. - Сохраните дашборд и настройте автообновление каждые 30 секунд для near-real-time мониторинга.
Готовый JSON дашборда можно экспортировать через Share → Export → Save to file и переиспользовать для разных пулов прокси — резидентных, мобильных и дата-центровых, меняя только значение переменной.
Алерты: когда пора действовать
Дашборд бесполезен, если на него никто не смотрит в момент инцидента. Поэтому критично настроить алерты в Grafana (Alerting → Alert rules) со следующими пороговыми значениями, подобранными под большинство продакшен-сценариев:
| Метрика | Порог алерта | Действие |
|---|---|---|
| Success Rate | ниже 85% за 5 минут | Проверить пул, переключить на резервный |
| p95 Latency | выше 5 секунд | Снизить параллелизм, проверить провайдера |
| Rate 429 | выше 10% запросов | Снизить частоту запросов, увеличить пул IP |
| Bandwidth rate | прогноз исчерпания лимита за 24ч | Докупить трафик или оптимизировать запросы |
Алерты лучше направлять в Telegram или Slack через webhook — это обеспечивает мгновенную реакцию, а не проверку дашборда раз в день.
Заключение
Семь метрик — success rate, latency, error rate по типам, живучесть IP, трафик, гео-соответствие и конкурентность соединений — дают полную картину здоровья прокси-инфраструктуры в продакшене. Связка Prometheus + Grafana позволяет не просто фиксировать проблему постфактум, а видеть тренды и реагировать до того, как деградация пула приведёт к банам аккаунтов или остановке парсинга.
Выбор типа прокси напрямую влияет на то, какие метрики будут в приоритете: для задач с высокой чувствительностью к банам, таких как мультиаккаунтинг в Instagram или TikTok, стоит в первую очередь мониторить живучесть IP и success rate, используя резидентные прокси для максимальной схожести с реальным трафиком пользователей. Для задач, где важна скорость и объём — массовый парсинг Ozon, Авито или Яндекс.Маркет — на первый план выходят latency и bandwidth, и здесь часто эффективнее работают прокси дата-центров за счёт более высокой пропускной способности.