Automatisation de la surveillance du crawling - Comment garantir la qualité des données 24 heures sur 24

Créer un crawler représente 20% du projet. Les 80% restants concernent l'exploitation.

"Un jour, un crawler qui fonctionnait bien a soudainement commencé à renvoyer des données vides, et personne ne s'en est rendu compte." - Si vous avez déjà exploité un système de crawling, vous avez probablement vécu cette situation au moins une fois. Cet article répertorie les modèles silencieux de défaillance des crawlers, ainsi que des moyens de les détecter automatiquement et de les réparer.

Table des matières

• Les 5 modèles de défaillance silencieuse des crawlers
• 4 principaux indicateurs à surveiller
• Configuration de l'automatisation des alertes
• Stratégie de récupération automatique
• Exploitation directe vs service géré - Comparaison des coûts
• Conclusion

Les 5 modèles de défaillance silencieuse des crawlers

La défaillance la plus dangereuse d'un crawler est de renvoyer des données incorrectes sans erreur. Même si un code HTTP 200 est renvoyé, les données réelles peuvent être vides ou contenir des valeurs incorrectes.

1. Modification de la structure HTML

Lorsqu'un site cible est rénové ou qu'un test A/B est effectué, les sélecteurs CSS peuvent ne plus correspondre, entraînant un échec de l'extraction des données. Aucune erreur n'est signalée, mais le résultat est None ou une chaîne vide.

2. Renforcement du blocage des bots

Le blocage d'IP, les CAPTCHA, la protection Cloudflare, etc., peuvent être soudainement appliqués. Le code de réponse est 200, mais la page renvoyée est une page de blocage indiquant "l'accès est restreint".

3. Temps d'attente et erreurs réseau

La réponse du serveur cible peut ralentir ou échouer de manière intermittente à des moments spécifiques. Sans logique de nouvelle tentative, des données peuvent être manquantes.

4. Modification du schéma de données

Le champ de prix passe de price à salePrice, ou le format de date est modifié. Le crawler fonctionne normalement, mais des problèmes surviennent dans les étapes suivantes (chargement dans la base de données, analyse, etc.).

5. Modification de la pagination/scroll infini

Le bouton "page suivante" disparaît ou l'API de défilement infini est modifiée. La collecte se termine après la première page.

Le point commun de ces cinq modèles? Ils semblent normaux dans les journaux.

4 principaux indicateurs à surveiller

Pour détecter les défaillances des crawlers qui se font passer pour "normaux", une surveillance au niveau des données est nécessaire, pas seulement des journaux d'erreurs.

1. Taux de réussite

Suivre le taux de données valides réellement renvoyées, pas seulement les codes 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. Temps de réponse

Si le temps de réponse moyen augmente soudainement de 2 à 3 fois, c'est un signe de blocage en cours ou de problèmes sur le serveur cible.

3. Intégrité des données

Vérifier si tous les champs obligatoires sont remplis. Suivre le ratio des résultats avec le champ "prix", le ratio des résultats avec une "URL d'image", 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. Détection des modifications de schéma

Comparer régulièrement la structure des données collectées. Si de nouveaux champs apparaissent ou si le format des valeurs des champs existants change, une alerte est envoyée.

Configuration de l'automatisation des alertes

Même si vous surveillez les métriques, il n'est pas possible de garder un œil sur le tableau de bord 24 heures sur 24. L'automatisation des alertes est essentielle.

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)

Conseils de configuration des alertes :
- Alertes progressives : Taux de réussite inférieur à 90 % → alerte Slack, inférieur à 70 % → e-mail + PagerDuty
- Prévention des alertes intempestives : Alerte uniquement après 3 échecs consécutifs (ignorer les erreurs temporaires)
- Gestion de l'alerte fatigue : Maximum 1 alerte par heure pour le même problème
- Alerte de récupération : Envoyer une alerte de "récupération normale" une fois le problème résolu pour rassurer

Stratégie de récupération automatique

Les alertes ne suffisent pas. Les échecs courants peuvent être automatiquement récupérés.

1. Retentatives avec atténuation exponentielle (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. Rotation des proxies

En cas de détection de blocage d'IP, bascule automatique vers un autre proxy.

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. Stratégie de secours

En cas d'échec de la méthode principale de crawling, bascule vers une méthode alternative.
- Échec du sélecteur CSS → essai avec XPath
- Changement de l'API endpoint → bascule vers la version mobile de la page
- Blocage d'une plage IP spécifique → utilisation d'un proxy d'une autre région

La réalité ? La mise en place et la maintenance de tout cela nécessitent des ressources d'ingénierie considérables.

Exploitation directe vs service géré - Comparaison des coûts

Examinons honnêtement les coûts de la mise en place d'un système de surveillance/exploitation de crawling en interne.

Le plus grand coût de l'exploitation directe est le coût invisible. Le temps passé à réagir lorsque le crawler échoue la nuit, à comprendre les changements de structure du site et à ajuster les sélecteurs, à gérer les proxies. Ces heures s'accumulent et détournent des ressources qui pourraient être consacrées au développement du produit.

HashScraper prend en charge ce fardeau opérationnel. La surveillance, la gestion des pannes et le suivi des changements de site sont intégrés au service, permettant à l'équipe de développement de se concentrer uniquement sur l'utilisation des données de crawling.

Conclusion

La véritable bataille du système de crawling se déroule non pas lors de sa création, mais dans son exploitation quotidienne.

Un crawler sans surveillance est une bombe à retardement. Le fait qu'il fonctionne bien aujourd'hui ne garantit pas qu'il fonctionnera bien demain. Les sites cibles évoluent chaque jour, et le blocage des bots devient de plus en plus sophistiqué.

Que vous construisiez votre propre système de surveillance ou que vous utilisiez un service géré, une chose est essentielle : créez une structure qui vous permettra de savoir immédiatement si votre crawler est en panne.

Si vous êtes fatigué de l'exploitation du crawling, contactez HashScraper. En tant que service de crawling géré intégrant surveillance et maintenance, nous veillons à la qualité de vos données 24 heures sur 24.