Un trabajo de scraping pequeño funciona o no funciona, y lo descubres rápido. Uno grande nunca está en ninguno de los dos estados. En todo momento una fracción de tu tráfico está fallando, y la pregunta operativamente útil no es “¿funciona el proxy?” sino “qué parte de esto se ha degradado, y es cosa nuestra, del proveedor o del destino.”
Conseguir una respuesta útil significa instrumentar a lo largo de las dimensiones que pueden fallar de forma independiente, lo cual no es lo mismo que añadir más métricas. A continuación se explica qué medir, cómo sondear sin desperdiciar ancho de banda, y cómo distinguir las tres fuentes de fallo.
La salud es por ruta, no por proxy
La primera corrección: en una gateway agrupada no tienes proxies que monitorizar. Nunca elegiste las direcciones de salida, no las conservas, y una dirección que falló una vez no es una entidad que puedas seguir en el tiempo. Lo que sí puedes seguir es una ruta, es decir, una combinación de las cosas que controlas: destino, país y, cuando corresponda, ciudad o ASN.
Así que la unidad de salud es la ruta. amazon-de, serp-us-chicago, marketplace-jp. Cada una tiene su propia tasa de éxito, perfil de latencia y mezcla de fallos, y cada una puede degradarse mientras las demás siguen perfectas. Un único número global de “salud del proxy” promedia exactamente la señal que necesitas: un noventa y cinco por ciento global puede ser veinte rutas al noventa y nueve por ciento y una ruta al cero por ciento, y solo la segunda lectura te dice que hagas algo.
Añade la salud de sesión como una segunda unidad, de vida más corta. Una sesión persistente que empieza a recibir desafíos debería retirarse y sustituirse en lugar de reutilizarse, y esa decisión pertenece al mismo componente que reparte las sesiones, tal como se describe en construir un gestor de proxies.
Pasivo primero: cada petición real es una comprobación de salud
La monitorización más económica es el tráfico que ya estás enviando. Cada petición de producción produce un resultado, y si lo registras contra su ruta obtienes datos de salud continuos sin coste adicional de ancho de banda.
El detalle crítico es qué cuenta como éxito. No un 200. Una página de desafío, un resultado genérico o vacío, un listado truncado, o una redirección a una landing page devuelven todos un 200 y todos significan que tu recolección falló, así que un monitor que cuenta códigos de estado informará de salud mientras el conjunto de datos se degrada. Valida el cuerpo contra una expectativa por destino antes de registrar el resultado, que es la disciplina descrita en detectar contenido bloqueado o falso. Este único cambio es lo que separa un panel de salud que detecta problemas de uno que confirma tu sesgo.
Registra como mínimo, por petición: ruta, resultado validado, latencia, bytes y una clase de fallo si falló. Eso es suficiente para calcular todo lo que sigue.
Clasifica los fallos, porque la clase es el diagnóstico
Contar fallos te dice que algo va mal. Clasificarlos te dice qué. Cinco clases cubren casi todo, y cada una apunta a un sitio distinto.
Los fallos de autenticación significan credenciales o una marca de segmentación mal formada, lo cual es un problema de configuración de tu lado y no se resolverá al reintentar, según corregir errores 407 y de credenciales. Los fallos de no coincidencia, en los que la gateway no tiene ninguna dirección que cumpla tu filtro en ese momento, significan que tu segmentación es demasiado estrecha en lugar de que algo esté roto; amplía de ciudad a país y se resuelve. Las señales de límite de tasa, es decir, 429 y similares, significan que tu ritmo es demasiado agresivo para ese destino, lo cual es un problema de limitación. Las señales de bloqueo, es decir, desafíos y 403 persistentes, significan que el destino rechazó la identidad, así que retira la sesión y considera si tus cabeceras o tu huella digital son la causa real. Los fallos de transporte, es decir, tiempos de espera agotados y reinicios de conexión, son la clase ambigua y merecen su propia investigación, ya que las razones por las que las peticiones agotan el tiempo de espera incluyen lentitud del destino, una ruta poco saludable y tu propia concurrencia siendo demasiado alta.
La mezcla importa más que el total. Una ruta al ochenta por ciento de éxito compuesta de señales de límite de tasa necesita un ritmo más lento; la misma ruta al ochenta por ciento compuesta de señales de bloqueo necesita una estrategia de identidad distinta; compuesta de errores de no coincidencia necesita una segmentación más amplia. El mismo número, tres soluciones distintas.
Sondas activas, usadas con moderación
La monitorización pasiva tiene un punto ciego: solo cubre las rutas que estás usando actualmente, así que una ruta programada para ejecutarse a las 03:00 no te da ningún aviso a las 22:00 de que se ha roto. Un pequeño conjunto de sondas activas cubre ese hueco, pero cuestan ancho de banda, así que mantenlas económicas y con propósito.
Vale la pena ejecutar dos tipos. Una sonda de conectividad y geolocalización por país, que golpea un pequeño endpoint que devuelve la dirección y su ubicación, confirma que la gateway es alcanzable y que el país que solicitas es el país que obtienes. Mantenla ligera, ya que es la sonda que ejecutarás con más frecuencia. Un canario de destino por cada destino importante, que obtiene una página conocida como estable y la valida, te dice si ese destino concreto está respondiendo con normalidad, que es la comprobación que distingue un problema del destino de un problema del proxy.
import requests
def geo_probe(country):
proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
try:
r = requests.get("https://ipinfo.io/json",
proxies={"http": proxy, "https": proxy}, timeout=15)
d = r.json()
return {"ok": d.get("country","").lower() == country,
"got": d.get("country"), "org": d.get("org")}
except Exception as e:
return {"ok": False, "error": type(e).__name__}Ejecuta las sondas de geolocalización con una cadencia lenta a través de los países que realmente usas, y los canarios con una cadencia acorde a cuánto te costaría un fallo silencioso. Alerta cuando una sonda falle repetidamente en lugar de una sola vez, ya que un único fallo en un pool rotativo es ruido normal.
Distinguir las tres fuentes de fallo
Esta es la pregunta que de verdad se plantea durante un incidente, y la respuesta viene de comparar señales en lugar de una única métrica.
Tu lado se manifiesta como fallos en muchos destinos no relacionados a la vez, normalmente empezando justo cuando se ha desplegado algo. Fallos de autenticación en todas partes, un pico de errores de transporte de un solo pool de workers, o un aumento de errores de no coincidencia después de que alguien haya ajustado un filtro apuntan hacia dentro. La pista es la amplitud: tus propios errores raramente respetan los límites del destino.
El proveedor se manifiesta como fallos en muchos destinos pero confinados a la capa de red: sondas de conectividad fallando, sondas de geolocalización devolviendo el país equivocado, errores de transporte en aumento mientras los canarios de destino que sí logran pasar siguen devolviendo páginas válidas. Aquí es también donde una página de estado pública se ganan su lugar, ya que correlacionar tu propia caída con el historial de incidentes del proveedor responde la pregunta de inmediato, y la clasificación por niveles que rige lo que se te debe está en SLA y garantías de tiempo de actividad de proxies.
El destino se manifiesta como fallos confinados a un solo destino mientras el resto de rutas se mantienen sanas, y el canario de ese destino falla mientras sus sondas de geolocalización pasan. Si falla desde todas las regiones simultáneamente, es probable que el sitio esté teniendo sus propios problemas; si falla desde una sola región, estás ante un bloqueo específico de geolocalización o un problema de borde regional.
Instrumenta de modo que esas comparaciones sean una sola consulta en lugar de una tarde entera: las mismas clases de fallo y resultados, etiquetados con ruta, región y worker, son suficientes.
Sobre qué alertar
Los paneles son para investigar, las alertas son para despertar a alguien. Mantén el conjunto de alertas pequeño y haz que cada una sea accionable.
Alerta cuando la tasa de éxito validada de una ruta caiga por debajo de su propia línea base móvil, no un umbral global, porque una ruta que normalmente funciona al setenta por ciento contra un destino hostil está sana al setenta por ciento y rota al cuarenta por ciento. Alerta ante un cambio en la mezcla de fallos, ya que una ruta que mantiene su tasa de éxito mientras las señales de bloqueo sustituyen a las señales de límite de tasa ha cambiado de carácter de una forma que predice problemas. Alerta ante un aumento en la proporción de reintentos, que sube antes de que la tasa de éxito baje y es por tanto el aviso más temprano que obtendrás. Alerta sobre la cobertura, es decir, una ruta programada que produce sustancialmente menos registros que su propio historial reciente, lo cual detecta una reducción silenciosa que la tasa de éxito no puede ver. Y alerta cuando una sonda falle repetidamente para una región de la que dependes.
Exige una desviación sostenida en lugar de un único intervalo, y compara contra una línea base móvil. Las definiciones de las métricas subyacentes están en KPIs de proxies, y la instrumentación a nivel de pipeline está en monitorizar un pipeline de web scraping.
Haz que el sistema actúe en consecuencia
Una monitorización que solo produce gráficos deja a un humano en el bucle para problemas que debería manejar una máquina. Las mismas señales deberían impulsar un comportamiento automático: retirar una sesión que acumula señales de bloqueo, abrir un circuit breaker en una ruta cuya tasa de éxito colapsa para dejar de alimentar un destino que no está respondiendo, desplazar trabajo a otra región cuando una se degrada, según failover en pipelines multirregión, y reducir el ritmo automáticamente cuando aparecen señales de límite de tasa. Los humanos deberían recibir alertas para cosas que requieren juicio, no para cosas que requieren una regla.
La conclusión
A gran escala, la salud no es una propiedad del proxy, es una propiedad de cada ruta que ejecutas, así que instrumenta por destino y región y deja que la salud de sesión sea su propia señal de vida corta. Juzga cada resultado sobre un cuerpo validado en lugar de un código de estado, porque esa es la diferencia entre monitorizar y autoengañarse. Clasifica los fallos, ya que la mezcla te dice si debes reducir el ritmo, cambiar de identidad, ampliar la segmentación o corregir tu propia configuración. Añade una capa ligera de sondas de geolocalización y canarios de destino para cubrir rutas que no están ejecutándose en ese momento y para separar los problemas del proveedor de los problemas del destino. Después alerta sobre la desviación sostenida respecto a la línea base propia de cada ruta, sobre los cambios en la mezcla de fallos y sobre la proporción de reintentos, y conecta las mismas señales a la retirada automática, la reducción de ritmo y el failover para que el sistema arregle lo que pueda antes de que nadie tenga que despertarse.
La capa subyacente son los proxies residenciales, donde la segmentación por país y ciudad y el control de sesión se expresan por petición, lo cual es lo que convierte la salud a nivel de ruta en una cuestión de etiquetar tus propias peticiones en lugar de un proyecto de integración, con precios por GB de modo que una estrategia de sondeo ligera cuesta casi nada frente a la propia recolección.