Si los proxies se utilizan en producción — para scraping, automatización de cuentas SMM o multi-cuentas a gran escala — tarde o temprano llega el momento en que "parece que funciona" deja de ser una respuesta suficiente. Se necesitan cifras: cuántas solicitudes fallan con error, cuánto ha aumentado la latencia después de cambiar el grupo de IP, si se ha agotado el límite de tráfico del proveedor. Analizamos 7 métricas que vale la pena recopilar en Prometheus y visualizar en Grafana para ver problemas antes de que los vean los usuarios o las cuentas bloqueadas.
¿Por qué monitorear proxies en producción?
Los proxies no son una infraestructura estática como un servidor con una IP fija. Es un grupo de direcciones en constante cambio, cuyo comportamiento depende del proveedor, la carga, la región e incluso la hora del día. Sin monitoreo, solo te enteras del problema cuando el scraper de Wildberries o Ozon deja de devolver datos, la cuenta publicitaria de Facebook Ads bloquea la cuenta, o el script de automatización de Instagram comienza a arrojar captchas.
La tarea del monitoreo es convertir el subjetivo "algo no está bien" en cifras concretas: la proporción de errores ha aumentado del 2% al 15% en la última hora, la latencia promedio se ha triplicado, el tráfico a través de un proxy ha superado el límite. Esto permite reaccionar antes de que el problema se vuelva crítico: cambiar automáticamente el grupo, reemplazar al proveedor o reducir la frecuencia de las solicitudes.
Para la recopilación de métricas, utilizamos la combinación de Prometheus (almacenamiento de series temporales) + Grafana (visualización y alertas). Este es un stack estándar en DevOps que se integra fácilmente con cualquier lenguaje — Python, Node.js, Go. A continuación, se presentan ejemplos en Python con la biblioteca prometheus_client, pero el principio es universal.
Métrica 1: Tasa de Éxito — proporción de solicitudes exitosas
Esta es una métrica básica que primero señala problemas con el grupo de proxies. Se calcula como la relación de solicitudes con código de respuesta 200-299 al número total de solicitudes durante un período de tiempo. Una caída en la tasa de éxito por debajo del 90% generalmente significa que parte de las IP en el grupo han sido bloqueadas por el sitio objetivo o que el proveedor está entregando direcciones inestables.
Ejemplo de instrumentación en Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Total de solicitudes a través del proxy',
['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) # endpoint para Prometheus scrape
Consulta PromQL para calcular la tasa de éxito en los últimos 5 minutos:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Si trabajas con varios tipos de proxies al mismo tiempo — por ejemplo, proxies residenciales para redes sociales y proxies de centros de datos para scraping — tiene sentido desglosar la tasa de éxito por la etiqueta proxy_pool, para ver qué grupo específico está degradándose.
Métrica 2: Latencia — tiempo de respuesta
La latencia muestra cuán rápido el proxy devuelve una respuesta. Un aumento brusco en la latencia a menudo precede a la caída de la tasa de éxito — el proveedor está sobrecargado, o la IP ya está cerca del bloqueo y el servidor objetivo comienza a ralentizar intencionadamente las respuestas. Para la latencia, es importante recopilar no solo el valor promedio, sino también los percentiles — p50, p95, p99, ya que el promedio oculta las latencias extremas que realmente interfieren con el trabajo.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Duración de la solicitud a través del proxy',
['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 para p95 de latencia:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Para tareas donde la velocidad es crítica — por ejemplo, en la automatización de TikTok Ads, donde cada segundo de carga de página aumenta el riesgo de tiempo de espera en un navegador anti-detección — es recomendable establecer una alerta en p95 por encima de 3-4 segundos.
Métrica 3: Tasa de Error por tipos de errores
Simplemente tener éxito/fallo no es suficiente para el diagnóstico. Es necesario dividir los errores por tipos: 407 (Proxy Authentication Required) significa un problema de autorización, 429 (Too Many Requests) — superación del límite de solicitudes, timeouts — un problema de red, 403 — bloqueo por protección anti-bot del sitio objetivo. Cada tipo de error requiere una reacción diferente.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Errores de proxy por tipo',
['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"
Tabla de errores típicos y sus causas:
| Código/tipo | Causa probable | Qué verificar |
|---|---|---|
| 407 | Credenciales incorrectas o sesión expirada | Usuario/contraseña del proxy, formato de la cadena de conexión |
| 429 | Límite de solicitudes superado en la IP | Frecuencia de solicitudes, tamaño del grupo |
| 403 | Protección anti-bot del sitio objetivo | User-Agent, huella digital, tipo de proxy |
| timeout | Sobrecarga del proveedor o de la red | Carga en el grupo, configuraciones de timeout del cliente |
Métrica 4: Velocidad de rotación y longevidad de IP
Si utilizas proxies rotativos, es importante saber con qué frecuencia cambia la IP y cuántas solicitudes pueden pasar antes de que la dirección "se queme" (sea bloqueada por el sitio objetivo). Esta métrica es especialmente crítica para el multi-cuentas — por ejemplo, al crear cuentas de Facebook Ads a través de Dolphin Anty o AdsPower, donde un cambio prematuro de IP puede interrumpir la sesión y activar una verificación de seguridad.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Tiempo de vida de la IP antes de la rotación',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Cuántas solicitudes pasaron antes del bloqueo de la IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Para proxies móviles, esta métrica se comporta de manera diferente que para los residenciales — la rotación a través del cambio de la estación base del operador proporciona IP "más limpias" con menor probabilidad de bloqueo. Si tu tarea es precisamente la automatización SMM con alta sensibilidad a los bloqueos, vale la pena comparar los indicadores de longevidad de IP entre proxies móviles y residenciales con datos reales de tu panel, en lugar de confiar en recomendaciones generales.
Métrica 5: Ancho de banda — consumo de tráfico
La mayoría de los planes de proxies se calculan por el volumen de tráfico, no por la cantidad de solicitudes. Sin monitoreo, es fácil perder el momento en que el límite está casi agotado — especialmente si la tarea incluye la carga de imágenes o videos, por ejemplo, al hacer scraping de tarjetas de productos de Wildberries con muchas fotografías.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Tráfico consumido a través del proxy',
['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)
En el panel de Grafana, es útil construir no el valor absoluto del tráfico, sino la velocidad de su consumo (rate) — esto ayuda a predecir cuándo se agotará el límite y planificar con anticipación la compra adicional o el cambio a otro grupo.
Métrica 6: Geo-distribución y conformidad regional
Para los especialistas en marketing que prueban anuncios de diferentes países y para los arbitrajistas que trabajan con geo-targeting en Google Ads o TikTok Ads, es crítico que la IP realmente corresponda a la región declarada. Un error de geolocalización puede llevar a mostrar anuncios a la audiencia equivocada o al bloqueo de la cuenta por incumplimiento de las configuraciones geográficas.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Casos de discrepancia entre geo declarado y real',
['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()
Se recomienda verificar la geolocalización no en cada solicitud (esto es costoso en términos de tráfico y tiempo), sino periódicamente — una vez por hora en una muestra de IP del grupo, suficiente para una confianza estadística.
Métrica 7: Conexiones Concurrentes — sesiones paralelas
El número de conexiones simultáneas a través del proxy muestra la carga real en el grupo. Si hay más sesiones paralelas de las que las IP en el grupo pueden manejar sin degradación, esto lleva directamente a un aumento en la latencia y la tasa de error de los puntos anteriores. Esta métrica es especialmente importante al escalar — cuando una agencia SMM aumenta el número de cuentas de clientes que funcionan simultáneamente de 10 a 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Conexiones activas actuales a través del proxy',
['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()
Correlacionar esta métrica con la tasa de error en un solo gráfico en Grafana mostrará rápidamente la correlación: tan pronto como el número de sesiones paralelas supera un umbral determinado, los errores comienzan a aumentar de manera no lineal.
Configuración del panel en Grafana: paso a paso
Después de que las métricas están instrumentadas y Prometheus las recopila, es necesario visualizar los datos en Grafana. El orden de acciones es:
- Agrega Prometheus como fuente de datos: Configuración → Fuentes de Datos → Agregar fuente de datos → Prometheus, especifica la URL de tu servidor Prometheus (generalmente
http://localhost:9090). - Crea un nuevo panel: Crear → Panel → Agregar nuevo panel.
- Para el panel de Tasa de Éxito, utiliza la consulta PromQL de la sección sobre la métrica 1, tipo de visualización — Gauge o Series de Tiempo.
- Para Latencia, crea un panel con tipo Heatmap, para ver la distribución de p50/p95/p99 a lo largo del tiempo.
- Para Tasa de Error, construye un Gráfico de Barras Apiladas desglosado por la etiqueta
error_type— esto mostrará visualmente qué tipo de errores domina. - Agrega una variable de panel (Configuración del Panel → Variables) para
proxy_pool, para alternar entre grupos sin crear paneles separados. - Guarda el panel y configura la auto-actualización cada 30 segundos para un monitoreo casi en tiempo real.
El JSON del panel listo se puede exportar a través de Compartir → Exportar → Guardar en archivo y reutilizar para diferentes grupos de proxies — residenciales, móviles y de centros de datos, cambiando solo el valor de la variable.
Alertas: cuándo es hora de actuar
El panel es inútil si nadie lo mira en el momento del incidente. Por lo tanto, es crítico configurar alertas en Grafana (Alertas → Reglas de alerta) con los siguientes umbrales, seleccionados para la mayoría de los escenarios de producción:
| Métrica | Umbral de alerta | Acción |
|---|---|---|
| Tasa de Éxito | por debajo del 85% durante 5 minutos | Verificar el grupo, cambiar a uno de respaldo |
| p95 Latencia | por encima de 5 segundos | Reducir el paralelismo, verificar al proveedor |
| Tasa 429 | por encima del 10% de solicitudes | Reducir la frecuencia de solicitudes, aumentar el grupo de IP |
| Tasa de Ancho de Banda | pronóstico de agotamiento del límite en 24h | Comprar más tráfico o optimizar solicitudes |
Es mejor dirigir las alertas a Telegram o Slack a través de webhook — esto asegura una reacción instantánea, en lugar de revisar el panel una vez al día.
Conclusión
Siete métricas — tasa de éxito, latencia, tasa de error por tipos, longevidad de IP, tráfico, conformidad geográfica y concurrencia de conexiones — proporcionan una imagen completa de la salud de la infraestructura de proxies en producción. La combinación de Prometheus + Grafana permite no solo registrar el problema post-facto, sino ver tendencias y reaccionar antes de que la degradación del grupo conduzca a bloqueos de cuentas o detenciones del scraping.
La elección del tipo de proxy afecta directamente qué métricas serán prioritarias: para tareas con alta sensibilidad a bloqueos, como el multi-cuentas en Instagram o TikTok, es recomendable monitorear primero la longevidad de IP y la tasa de éxito, utilizando proxies residenciales para una máxima similitud con el tráfico real de los usuarios. Para tareas donde la velocidad y el volumen son importantes — scraping masivo de Ozon, Avito o Yandex.Market — la latencia y el ancho de banda son primordiales, y aquí a menudo funcionan mejor los proxies de centros de datos debido a su mayor capacidad de procesamiento.