Automatización del monitoreo del web scraping: Cómo mantener la calidad de los datos las 24 horas

Crear un rastreador es el 20% de un proyecto. El otro 80% es operación.

"Un día, un rastreador que funcionaba bien de repente comenzó a devolver datos vacíos y nadie lo sabía." - Si has operado un sistema de web scraping, probablemente hayas experimentado esto al menos una vez. En este artículo, se resumen los patrones en los que los rastreadores fallan silenciosamente y cómo detectarlos y recuperarlos automáticamente.

Tabla de contenido

• 5 patrones en los que los rastreadores fallan silenciosamente
• 4 métricas clave a monitorear
• Configuración de notificaciones automáticas
• Estrategia de recuperación automática
• Operación directa vs servicio gestionado - Comparación de costos
• Conclusión

5 patrones en los que los rastreadores fallan silenciosamente

La falla más peligrosa de un rastreador es devolver datos incorrectos sin errores. Puede recibir un código HTTP 200, pero los datos reales pueden estar vacíos o contener valores incorrectos.

1. Cambio en la estructura HTML

Cuando el sitio objetivo se renueva o realiza pruebas A/B, los selectores CSS pueden no coincidir y la extracción de datos falla. No se produce un error, pero el resultado es None o una cadena vacía.

2. Refuerzo del bloqueo de bots

Se aplican bloqueos de IP, CAPTCHA, protección de Cloudflare, etc. El código de respuesta es 200, pero se devuelve una página de bloqueo como "El acceso está restringido".

3. Tiempo de espera y errores de red

La respuesta del servidor objetivo se vuelve lenta o falla intermitentemente en ciertos momentos. Sin lógica de reintento, se pierden datos.

4. Cambio en el esquema de datos

El campo de precio cambia de price a salePrice, o el formato de la fecha se modifica. El rastreador funciona correctamente, pero surgen problemas en las etapas posteriores (carga en la base de datos, análisis, etc.).

5. Cambio en la paginación/desplazamiento infinito

El botón "Siguiente página" desaparece o cambia el punto final de la API de desplazamiento infinito. La situación termina después de recopilar solo la primera página.

¿La similitud entre estos cinco patrones? Aparentan estar bien si solo se observan los registros.

4 métricas clave a monitorear

Para detectar cuando un rastreador falla "fingiendo estar bien", se necesita un monitoreo a nivel de datos en lugar de simplemente registros de errores.

1. Tasa de éxito (Success Rate)

Rastrea la proporción de datos válidos realmente devueltos en lugar de simplemente un HTTP 200.

# 성공률 모니터링 예시
from datetime import datetime

def monitor_crawl_success(results):
    total = len(results)
    valid = sum(1 for r in results if r.get("title") and r.get("price"))
    success_rate = valid / total * 100 if total > 0 else 0

    # 성공률이 임계값 이하면 알림
    if success_rate < 90:
        send_alert(
            level="warning" if success_rate >= 70 else "critical",
            message=f"크롤링 성공률 저하: {success_rate:.1f}% ({valid}/{total})",
            timestamp=datetime.now().isoformat()
        )

    return {"success_rate": success_rate, "total": total, "valid": valid}

2. Tiempo de respuesta

Si el tiempo promedio de respuesta aumenta repentinamente 2-3 veces, es una señal de que se está bloqueando o hay un problema en el servidor objetivo.

3. Integridad de los datos

Verifica si se completan todos los campos obligatorios. Rastrea la proporción de resultados con el campo "precio", la proporción con "URL de imagen", etc.

def check_data_completeness(results, required_fields):
    """필수 필드 완전성 체크"""
    if not results:
        return {field: 0.0 for field in required_fields}

    completeness = {}
    for field in required_fields:
        filled = sum(1 for r in results if r.get(field))
        completeness[field] = filled / len(results) * 100

    # 특정 필드 완전성이 급격히 떨어지면 스키마 변경 의심
    for field, rate in completeness.items():
        if rate < 80:
            send_alert(
                level="warning",
                message=f"필드 '{field}' 완전성 {rate:.1f}%로 하락 — 스키마 변경 확인 필요"
            )

    return completeness

4. Detección de cambios en el esquema

Compara periódicamente la estructura de los datos recopilados. Envía una notificación si aparecen nuevos campos o si cambia el formato de los valores de los campos existentes.

Configuración de notificaciones automáticas

Aunque se estén monitoreando las métricas, no es posible que alguien esté mirando el tablero las 24 horas. La automatización de las notificaciones es esencial.

import requests
import smtplib
from email.mime.text import MIMEText

def send_slack_alert(webhook_url, message, level="warning"):
    """Slack 웹훅으로 알림 전송"""
    emoji = "" if level == "warning" else ""
    payload = {
        "text": f"{emoji} *크롤링 모니터링 알림*\n{message}",
        "username": "Crawl Monitor",
    }
    requests.post(webhook_url, json=payload)

def send_email_alert(to_email, subject, body):
    """이메일 알림 전송"""
    msg = MIMEText(body)
    msg["Subject"] = f"[크롤링 알림] {subject}"
    msg["From"] = "monitor@your-domain.com"
    msg["To"] = to_email

    with smtplib.SMTP("smtp.gmail.com", 587) as server:
        server.starttls()
        server.login("your-email", "app-password")
        server.send_message(msg)

Consejos para la configuración de notificaciones:
- Notificaciones escalonadas: Tasa de éxito inferior al 90% → Alerta en Slack, inferior al 70% → Correo electrónico + PagerDuty
- Prevención de fluctuaciones: Solo notificar después de 3 fallos consecutivos (ignorar errores temporales)
- Gestión de la fatiga de las notificaciones: Solo una notificación por hora para el mismo problema
- Notificación de recuperación: Enviar una notificación de "recuperación normal" cuando se resuelva el problema para tranquilidad.

Estrategia de recuperación automática

Las notificaciones por sí solas no son suficientes. Los patrones comunes de falla se pueden recuperar automáticamente.

1. Reintentos con retroceso exponencial (Exponential Backoff)

import time
import random

def crawl_with_retry(url, max_retries=3):
    """지수 백오프 재시도 — 일시적 오류 자동 복구"""
    for attempt in range(max_retries):
        try:
            result = crawl_page(url)
            if result and result.get("data"):
                return result
        except Exception:
            pass

        # 재시도 간격: 1초 → 2초 → 4초 (+ 랜덤 지터)
        wait = (2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)

    return None  # 재시도 모두 실패 → 알림으로 넘김

2. Rotación de proxy

Cambiar automáticamente a otro proxy cuando se detecta un bloqueo de IP.

def crawl_with_proxy_rotation(url, proxies):
    """프록시 로테이션 — IP 차단 시 자동 전환"""
    for proxy in proxies:
        try:
            response = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
            if response.status_code == 200 and not is_block_page(response.text):
                return response
        except requests.RequestException:
            continue

    send_alert(level="critical", message=f"모든 프록시에서 {url} 차단됨")
    return None

3. Estrategia de respaldo

Si falla el método principal de web scraping, cambiar a una ruta alternativa.
- Falla en el selector CSS → Intentar con XPath
- Cambio en el punto final de la API → Cambiar a la versión móvil de la página
- Bloqueo de cierto rango de IP → Usar un proxy de otra región

En la realidad, se requieren recursos de ingeniería significativos para construir y mantener todo esto.

Operación directa vs servicio gestionado - Comparación de costos

Veamos honestamente los costos de construir un sistema de monitoreo/operación de web scraping directamente.

El mayor costo de la operación directa son los costos invisibles. El tiempo dedicado a responder cuando el rastreador falla en la madrugada, a comprender los cambios en la estructura del sitio y ajustar los selectores, a gestionar los proxies. Estas horas restan recursos que podrían dedicarse al desarrollo del producto.

HashScraper asume esta carga operativa. Con monitoreo, recuperación de fallos y seguimiento de cambios en el sitio integrados en el servicio, el equipo de desarrollo puede centrarse únicamente en utilizar los datos del web scraping.

Conclusión

El sistema de web scraping es una verdadera batalla no en el momento de la creación, sino en la operación diaria.

Un rastreador sin monitoreo es una bomba de tiempo. El hecho de que funcione bien hoy no garantiza que funcione bien mañana. Los sitios objetivo cambian constantemente y los bloqueos de bots se vuelven más sofisticados.

Ya sea construyendo un sistema de monitoreo propio o utilizando un servicio gestionado, hay un principio fundamental: crea una estructura que te permita saber de inmediato cuando el rastreador falle.

Si estás cansado de la operación de web scraping, consulta HashScraper. Como servicio de web scraping gestionado con monitoreo y mantenimiento integrados, cuidaremos la calidad de tus datos las 24 horas.