Un pipeline de scraping rara vez falla con estruendo. El cron sigue disparando, el proceso sigue saliendo con cero, los logs están llenos de 200 OK, y todo parece sano justo hasta que alguien a tres equipos de distancia nota que los números de un informe se torcieron hace una semana. Para entonces has perdido días de datos y no puedes recolectar la mayoría de nuevo, porque las páginas ya avanzaron.
Esta es la pata de observabilidad de correr recolección a escala. Si Kubernetes te da la orquestación y la validación por respuesta pilla la página mala individual, la monitorización es la capa que vigila toda la flota a lo largo del tiempo y te dice que un destino se volvió contra ti antes de que la corrupción llegue a tu almacén. Aquí están las métricas que importan, cómo hacerles línea base, y cómo alertar sin ahogarte en ruido.
Los logs no son monitorización
Lo primero que aceptar es que los logs y los códigos de salida no te dicen casi nada sobre si el scraping funciona. Un proceso que sale con cero y loguea un 200 te ha dicho que hizo una petición y obtuvo una respuesta, no que obtuvo la respuesta correcta. Como se cubre en detectar contenido bloqueado o falso, una página de bloqueo, una cáscara recortada, y datos reales vuelven todos como 200. Monitorizar significa métricas: números emitidos por petición, agregados a lo largo del tiempo, desglosados por dimensión, y comparados contra una línea base. Esa es una disciplina distinta del logging, y es la que pilla el fallo silencioso.
Las métricas que importan
Emite estas por petición, etiquetadas por host de destino y por geo de salida, y agrégalas. Nada de esto necesita machine learning, solo contadores e histogramas.
Tasa de éxito. La métrica estrella, y la que todos definen mal. El éxito no es HTTP 200, es pasar la validación: la respuesta contenía el campo o elemento que una página real siempre tiene. Sigue el porcentaje de peticiones que pasan tu aserción de contenido, por host de destino. Una caída en un host mientras otros se mantienen estables es ese host cambiando su comportamiento hacia ti, y es el número más importante de tu panel.
Tasa de bloqueo. La proporción de respuestas que tu capa de detección marca como bloqueos suaves o desafíos. Este es tu aviso temprano de que un destino se puso más agresivo o tu reputación de pool resbaló. Una tasa de bloqueo que trepa es lo que precede a un baneo duro, así que vigila su pendiente, no solo su valor, y correlaciónala con la reputación de IP y los bloqueos que intentas evitar.
Percentiles de latencia. Sigue p50, p95 y p99, nunca la media, que esconde la cola lenta donde viven los verdaderos problemas. Un p95 que sube significa que un destino te está estrangulando, un pool se degrada, o una ruta está congestionada. Esta es la vista a nivel de flota de la misma señal detrás de los timeouts de petición y el ajuste de latencia.
Tasa de relleno de campos. Para cada campo que extraes, el porcentaje de registros donde de verdad se pobló. Este es tu canario de calidad de datos: un campo que estaba al 98 por ciento ayer y al 20 por ciento hoy no se volvió más raro, empezaste a recibir páginas recortadas o parciales. La tasa de relleno pilla degradación que la tasa de éxito puede perder.
Throughput frente a backlog. Peticiones y registros por minuto, vigilados contra la profundidad de tu cola de trabajo. Throughput subiendo con backlog encogiendo es sano. Throughput plano con backlog creciendo significa que te quedas atrás y necesitas escalar hacia fuera, la señal que alimenta el autoescalado por profundidad de cola.
Frescura. Cuán viejo es el registro más nuevo para cada fuente. Una fuente cuya frescura deja de avanzar ha dejado de producir en silencio, aunque toda otra métrica se vea bien. Esta es la que pilla un feed que murió sin dar error.
Coste por registro. Ancho de banda y gasto divididos por registros usables recolectados. Más allá de la eficiencia, este es un detector de anomalías: un salto repentino en bytes-por-registro suele significar que estás descargando páginas de bloqueo o basura inflada en lugar de datos, así que un problema de salud aparece primero como un pico de coste. También mantiene honesta la factura de ancho de banda.
Tasa de reintento y taxonomía de errores. Intentos por registro exitoso, desglosados por tipo de fallo: timeout, 429, connection reset, DNS, bloqueo detectado. La forma de tus errores es un diagnóstico. Un pico de 429 significa que empujas un destino demasiado fuerte; un pico de connection resets apunta a la capa de red o proxy; un pico de bloqueos detectados apunta a la reputación. Un solo conteo agregado de errores te dice que algo va mal; la taxonomía te dice qué.
Línea base por destino, alerta por desviación
El error que vuelve inútil la monitorización es alertar sobre umbrales absolutos. Una tasa de bloqueo del 3 por ciento es perfectamente normal para un sitio y una alarma de cinco campanas para otro. Un p95 de dos segundos está bien para una página pesada y es terrible para una API ligera. Los umbrales absolutos o pierden problemas reales o gritan lobo constantemente, y la fatiga de alertas significa que la única página real acaba siendo ignorada.
Haz línea base de cada métrica por host de destino, luego alerta sobre la desviación de esa línea base: una caída sostenida en la tasa de éxito, una tasa de bloqueo que trepa más rápido que su banda normal, un p95 que se duplicó contra la semana pasada. La tasa de cambio y la desviación por destino pillan las cosas que importan y se quedan calladas cuando un sitio es simplemente distinto de otro. Alerta sobre desviación sostenida en lugar de un solo minuto malo, y reserva avisar a un humano para lo que de verdad lo necesita, todo lo demás puede ser un panel o un resumen.
# Emite por respuesta; agrega en una serie temporal, dimensionada por host + geo.def record(metrics, host, geo, resp, validation): tags = {"host": host, "geo": geo} metrics.incr("requests", tags) metrics.incr("success" if validation.ok else "failure", tags) if validation.blocked: metrics.incr("blocked", tags) # tasa de bloqueo = blocked / requests metrics.observe("latency_ms", resp.elapsed_ms, tags) # histograma -> p50/p95/p99 metrics.observe("bytes", resp.size, tags) # -> coste/bytes por registro for field, present in validation.fields.items(): metrics.incr(f"field.{field}." + ("filled" if present else "empty"), tags)Canarios y la dimensión del proxy
Dos cosas afilan todo lo anterior. Primero, corre canarios: obtén una página cuyo contenido correcto ya conoces, según un horario y por geo, y afirma que sigue coincidiendo. Un canario pasa de sano a roto en el instante en que un destino cambia, sin esperar a que un lento declive de las métricas agregadas se vuelva obvio, y hacerlo por geo pilla un sitio que bloquea las IP de salida de un país mientras deja otro intacto.
Segundo, dimensiona cada métrica por geo de salida y pool, no solo por destino. Los problemas frecuentemente son localizados: las IP de un país reciben desafíos mientras el resto pasa sin problema, o un segmento de un pool se degrada. Sin el desglose por geo y pool, eso aparece como una caída suave y confusa en la media global en lugar de la señal nítida y accionable que de verdad es. Como la calidad del pool es un indicador adelantado de la tasa de bloqueo, vigilar el éxito y la tasa de bloqueo por pool te dice sobre un pool residencial degradándose antes de que arrastre toda la corrida, y te da la opción de mover la carga o hacer failover antes de que los usuarios lo noten.
En resumen
Un pipeline de scraping que no se monitoriza es un pipeline que falla en silencio y caro. Instrumenta el éxito como validación-pasada en lugar de HTTP 200, y sigue tasa de bloqueo, percentiles de latencia, tasa de relleno de campos, throughput frente a backlog, frescura, coste por registro, y una taxonomía de errores adecuada, cada uno desglosado por host de destino y geo de salida. Haz línea base de cada métrica por destino y alerta sobre la desviación de esa línea base, no sobre números absolutos, para pillar las roturas reales sin ahogarte en falsas. Añade canarios para un aviso temprano instantáneo. Haz eso y el fallo silencioso deja de ser silencioso: te enteras en el pipeline, en minutos, en lugar de en un informe aguas abajo, en semanas.
Como la tasa de bloqueo y la latencia ambas se remontan a la calidad de las IP por las que sales, un pool residencial limpio es lo que mantiene esas métricas sanas de entrada, y el precio por GB vuelve el coste-por-registro que ahora vigilas algo que de verdad puedes optimizar.