Crawling Monitoring Automation — Wie man die Datenqualität rund um die Uhr sicherstellt

Das Erstellen eines Crawlers macht 20% des Projekts aus. Die restlichen 80% sind Betrieb.

"Ein gut funktionierender Crawler begann eines Tages plötzlich leere Daten auszuspucken, und niemand wusste davon." — Jeder, der ein Crawling-System betrieben hat, hat das wahrscheinlich schon einmal erlebt. In diesem Artikel werden Muster aufgezeigt, wie Crawler leise scheitern, und wie man diese automatisch erkennen und wiederherstellen kann.

Inhaltsverzeichnis

• 5 Muster, in denen Crawler leise scheitern
• 4 Schlüsselkennzahlen, die überwacht werden müssen
• Automatische Benachrichtigungseinstellungen
• Automatische Wiederherstellungsstrategie
• Eigenbetrieb vs. Managed Services — Kostenvergleich
• Abschluss

5 Muster, in denen Crawler leise scheitern

Das gefährlichste Versagen eines Crawlers ist, falsche Daten ohne Fehler zurückzugeben. Es kann vorkommen, dass ein HTTP 200 zurückgegeben wird, aber die tatsächlichen Daten entweder leer sind oder falsche Werte enthalten.

1. Änderung der HTML-Struktur

Wenn die Zielwebsite überarbeitet wird oder A/B-Tests durchführt, schlägt das Extrahieren von Daten fehl, da die CSS-Selektoren nicht übereinstimmen. Es tritt kein Fehler auf, aber das Ergebnis ist None oder ein leerer String.

2. Verschärfung der Bot-Blockierung

IP-Blockierung, CAPTCHA, Cloudflare-Schutz usw. werden plötzlich angewendet. Der Antwortcode ist 200, aber die zurückgegebene Seite lautet "Zugriff eingeschränkt".

3. Zeitüberschreitung & Netzwerkfehler

Die Antwort des Zielservers verzögert sich oder es treten zu bestimmten Zeiten intermittierende Fehler auf. Ohne Wiederholungslogik gehen Daten verloren.

4. Änderung des Datenschemas

Das Preisfeld ändert sich von price zu salePrice oder das Datumsformat wird geändert. Der Crawler funktioniert normal, aber es treten Probleme in nachgelagerten Pipelines (Datenbankbeladung, Analyse usw.) auf.

5. Änderung der Paginierung/Endloses Scrollen

Die "Nächste Seite" Schaltfläche verschwindet oder der Endpunkt der Endlos-Scroll-API ändert sich. Es kann vorkommen, dass nur die erste Seite gesammelt wird und dann endet.

Das gemeinsame Merkmal dieser fünf Muster? Sie sehen im Log wie normal aus.

4 Schlüsselkennzahlen, die überwacht werden müssen

Um das Scheitern von Crawlern, die vorgeben "normal" zu sein, zu erkennen, ist nicht nur ein einfaches Fehlerprotokoll erforderlich, sondern auch Überwachung auf Datenebene.

1. Erfolgsquote

Es wird nicht nur ein einfaches HTTP 200 verfolgt, sondern auch der Prozentsatz der tatsächlich zurückgegebenen gültigen Daten.

# 성공률 모니터링 예시
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. Antwortzeit

Wenn die durchschnittliche Antwortzeit plötzlich um das 2- bis 3-fache steigt, ist dies ein Zeichen dafür, dass eine Blockierung beginnt oder Probleme mit dem Zielserver bestehen.

3. Datenintegrität

Es wird überprüft, ob alle erforderlichen Felder ausgefüllt sind. Es wird verfolgt, wie viele Ergebnisse das "Preis"-Feld haben, wie viele das "Bild-URL"-Feld haben usw.

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. Erkennung von Schemaänderungen

Die Struktur der gesammelten Daten wird regelmäßig verglichen. Es wird eine Benachrichtigung gesendet, wenn neue Felder hinzugefügt werden oder sich der Wert eines vorhandenen Feldes ändert.

Automatische Benachrichtigungseinstellungen

Auch wenn die Überwachungskennzahlen überwacht werden, kann niemand rund um die Uhr auf das Dashboard schauen. Automatische Benachrichtigungen sind unerlässlich.

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)

Tipps für die Benachrichtigungseinstellungen:
- Stufenweise Benachrichtigung: Erfolgsquote unter 90% → Slack-Warnung, unter 70% → E-Mail + PagerDuty
- Flattern-Prävention: Nur bei 3 aufeinanderfolgenden Fehlern benachrichtigen (vorübergehliche Fehler ignorieren)
- Benachrichtigungsmüdigkeit verwalten: Für dasselbe Problem nur einmal pro Stunde benachrichtigen
- Wiederherstellungsbenachrichtigung: Bei Problembehebung auch eine "normale Wiederherstellung" senden, um beruhigt zu sein

Automatische Wiederherstellungsstrategie

Benachrichtigungen allein reichen nicht aus. Häufige Fehlermuster können automatisch behoben werden.

1. Exponentielles Backoff-Retry

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. Proxy-Rotation

Bei Erkennung einer IP-Blockierung wird automatisch auf einen anderen Proxy umgeschaltet.

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. Fallback-Strategie

Wenn die Haupt-Crawling-Methode fehlschlägt, wird auf alternative Wege umgeschaltet.
- CSS-Selektorfehler → Versuch mit XPath
- Änderung des API-Endpunkts → Wechsel zur mobilen Version der Seite
- Blockierung bestimmter IP-Bereiche → Verwendung eines Proxys aus einer anderen Region

Die Realität? All dies selbst aufzubauen und zu warten erfordert erhebliche Engineering-Ressourcen.

Eigenbetrieb vs. Managed Services — Kostenvergleich

Lassen Sie uns ehrlich die Kosten für den Aufbau eines Crawling-Monitoring/Betriebssystems direkt vergleichen.

Die größten Kosten beim Eigenbetrieb sind die versteckten Kosten. Die Zeit, die aufgewendet wird, um auf einen fehlerhaften Crawler zu reagieren, die Zeit, die für das Verstehen von Website-Strukturänderungen und das Anpassen von Selektoren benötigt wird, die Zeit, die für das Verwalten von Proxies benötigt wird. Wenn sich diese Zeiten addieren, gehen Ressourcen verloren, die in die Produktentwicklung investiert werden sollten.

HashScraper übernimmt diese Betriebslast. Überwachung, Fehlerbehebung und Website-Änderungsnachverfolgung sind in den Service integriert, sodass das Entwicklungsteam sich auf die Nutzung von Crawling-Daten konzentrieren kann.

Abschluss

Das Crawling-System ist nicht nur beim Erstellen, sondern vor allem beim täglichen Betrieb eine echte Herausforderung.

Ein Crawler ohne Überwachung ist eine Zeitbombe. Nur weil er heute gut funktioniert, bedeutet das nicht, dass er morgen auch gut funktioniert. Die Zielwebsite ändert sich täglich, und die Bot-Blockierung wird immer ausgefeilter.

Egal, ob Sie ein Überwachungssystem selbst aufbauen oder einen Managed Service nutzen, das Wichtigste ist: Stellen Sie sicher, dass Sie sofort informiert werden, wenn der Crawler ausfällt.

Wenn Sie vom Betrieb des Crawlings müde sind, wenden Sie sich an HashScraper. Als Managed Crawling-Service mit integrierter Überwachung und Wartung überwachen wir die Datenqualität rund um die Uhr.