Wie man die Gesundheit von Residential Proxys im großen Maßstab überwacht

Ein kleiner Scraping-Job funktioniert entweder oder er funktioniert nicht, und man merkt es schnell. Ein großer befindet sich niemals in einem der beiden Zustände. Zu jedem Zeitpunkt schlägt ein Teil des Traffics fehl, und die operativ nützliche Frage ist nicht „funktioniert der Proxy”, sondern „welcher Teil davon hat sich verschlechtert, und liegt es an uns, am Anbieter oder am Ziel.”

Eine nützliche Antwort zu erhalten bedeutet, entlang der Dimensionen zu instrumentieren, die unabhängig voneinander ausfallen können, was nicht dasselbe ist wie mehr Metriken hinzuzufügen. Hier ist, was zu messen ist, wie man sondiert, ohne Bandbreite zu verschwenden, und wie man die drei Fehlerquellen unterscheidet.

Health ist pro Route, nicht pro Proxy

Die erste Korrektur: Auf einem gepoolten Gateway hat man keine Proxys zu überwachen. Man wählt die Exit-Adressen nie selbst aus, man behält sie nicht, und eine Adresse, die einmal fehlgeschlagen ist, ist keine Entität, die man über die Zeit verfolgen kann. Was man verfolgen kann, ist eine Route, das heißt eine Kombination der Dinge, die man kontrolliert: Ziel, Land und, wo relevant, Stadt oder ASN.

Die Einheit der Health ist also die Route. amazon-de, serp-us-chicago, marketplace-jp. Jede hat ihre eigene Erfolgsrate, ihr eigenes Latenzprofil und ihre eigene Fehlermischung, und jede kann sich verschlechtern, während die anderen einwandfrei bleiben. Eine einzelne globale „Proxy-Health”-Zahl mittelt genau das Signal weg, das man braucht: fünfundneunzig Prozent insgesamt können zwanzig Routen mit neunundneunzig Prozent und eine Route mit null Prozent sein, und nur die zweite Ablesung sagt einem, dass man etwas tun muss.

Session-Health als zweite, kurzlebigere Einheit hinzufügen. Eine Sticky Session, die anfängt, Challenges zu ziehen, sollte ausgemustert und ersetzt statt wiederverwendet werden, und diese Entscheidung gehört in dieselbe Komponente, die Sessions vergibt, wie in building a proxy manager beschrieben.

Zuerst passiv: jede echte Anfrage ist ein Health-Check

Das günstigste Monitoring ist der Traffic, den man bereits sendet. Jede Produktionsanfrage erzeugt ein Ergebnis, und wenn man es gegen ihre Route protokolliert, erhält man kontinuierliche Health-Daten ohne zusätzliche Bandbreitenkosten.

Das entscheidende Detail ist, was als Erfolg zählt. Nicht ein 200er. Eine Challenge-Seite, ein generisches oder leeres Ergebnis, ein abgeschnittenes Listing oder eine Weiterleitung auf eine Landingpage geben alle 200 zurück und bedeuten alle, dass die Erfassung fehlgeschlagen ist, sodass ein Monitor, der Statuscodes zählt, Gesundheit melden wird, während sich der Datensatz verschlechtert. Den Body gegen eine ziel-spezifische Erwartung validieren, bevor man das Ergebnis protokolliert, das ist die Disziplin aus detecting blocked or fake content. Diese eine Änderung ist es, die ein Health-Dashboard, das Probleme erkennt, von einem unterscheidet, das die eigene Voreingenommenheit bestätigt.

Mindestens pro Anfrage protokollieren: Route, validiertes Ergebnis, Latenz, Bytes und eine Fehlerklasse, falls fehlgeschlagen. Das reicht, um alles Folgende zu berechnen.

Fehler klassifizieren, denn die Klasse ist die Diagnose

Fehler zu zählen sagt einem, dass etwas nicht stimmt. Sie zu klassifizieren sagt einem, was. Fünf Klassen decken fast alles ab, und jede verweist auf etwas anderes.

Auth-Fehler bedeuten Zugangsdaten oder ein fehlerhaftes Targeting-Flag, was ein Konfigurationsproblem auf der eigenen Seite ist und sich bei einem erneuten Versuch nicht lösen wird, gemäß fixing 407 and credential errors. No-Match-Fehler, bei denen das Gateway zu diesem Zeitpunkt keine Adresse hat, die dem Filter entspricht, bedeuten, dass das Targeting zu eng ist, statt dass etwas kaputt ist; von Stadt auf Land erweitern und es klärt sich. Rate-Signale, das heißt 429 und Verwandte, bedeuten, dass das Tempo für dieses Ziel zu aggressiv ist, was ein Throttling-Problem ist. Block-Signale, das heißt Challenges und anhaltende 403er, bedeuten, dass das Ziel die Identität abgelehnt hat, also die Session ausmustern und überlegen, ob die eigenen Header oder der Fingerprint die eigentliche Ursache sind. Transport-Fehler, das heißt Timeouts und Connection Resets, sind die uneindeutige Klasse und eine eigene Untersuchung wert, da die Gründe, warum Anfragen ein Timeout haben, Ziel-Langsamkeit, eine ungesunde Route und die eigene, zu hohe Nebenläufigkeit umfassen.

Die Mischung ist wichtiger als die Gesamtzahl. Eine Route mit achtzig Prozent Erfolg, die aus Rate-Signalen besteht, braucht langsameres Tempo; dieselbe Route mit achtzig Prozent, die aus Block-Signalen besteht, braucht eine andere Identitätsstrategie; besteht sie aus No-Match-Fehlern, braucht sie breiteres Targeting. Gleiche Zahl, drei unterschiedliche Lösungen.

Aktive Sonden, sparsam eingesetzt

Passives Monitoring hat einen blinden Fleck: Es deckt nur Routen ab, die man gerade nutzt, sodass eine Route, die um 03:00 Uhr geplant ist, um 22:00 Uhr keine Warnung gibt, dass sie kaputt ist. Eine kleine Menge aktiver Sonden schließt diese Lücke, aber sie kosten Bandbreite, also günstig und zweckgebunden halten.

Zwei Arten sind es wert, ausgeführt zu werden. Eine Konnektivitäts- und Geo-Sonde pro Land, die einen kleinen Endpunkt anspricht, der die Adresse und ihren Standort zurückgibt, bestätigt, dass das Gateway erreichbar ist und dass das angefragte Land auch das erhaltene Land ist. Leicht halten, da dies die Sonde ist, die am häufigsten ausgeführt wird. Ein Target-Canary pro wichtigem Ziel, der eine bekannt stabile Seite abruft und validiert, sagt einem, ob dieses spezifische Ziel normal antwortet, was die Prüfung ist, die ein Zielproblem von einem Proxy-Problem unterscheidet.

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__}

Geo-Sonden in langsamem Takt über die tatsächlich genutzten Länder ausführen und Canaries in einem Takt, der dem entspricht, wie teuer ein stiller Ausfall wäre. Bei wiederholtem, nicht bei einmaligem Fehlschlagen einer Sonde alarmieren, da ein einzelner Fehlschlag bei einem rotierenden Pool normales Rauschen ist.

Die drei Fehlerquellen unterscheiden

Das ist die Frage, die während eines Incidents tatsächlich gestellt wird, und die Antwort kommt aus dem Vergleich von Signalen, nicht aus einer einzelnen Metrik.

Die eigene Seite zeigt sich als Fehler über viele nicht zusammenhängende Ziele gleichzeitig, meist genau dann beginnend, wenn etwas deployed wurde. Auth-Fehler überall, ein Anstieg von Transport-Fehlern aus einem Worker-Pool oder ein Anstieg von No-Match-Fehlern, nachdem jemand einen Filter verschärft hat, weisen alle nach innen. Das Erkennungsmerkmal ist die Breite: eigene Bugs respektieren selten Zielgrenzen.

Der Anbieter zeigt sich als Fehler über viele Ziele, aber beschränkt auf die Netzwerkschicht: fehlschlagende Konnektivitätssonden, Geo-Sonden, die das falsche Land zurückgeben, steigende Transport-Fehler, während Target-Canaries, die durchkommen, weiterhin gültige Seiten zurückgeben. Hier verdient auch eine öffentliche Statusseite ihren Platz, da die Korrelation des eigenen Einbruchs mit der Incident-Historie des Anbieters die Frage sofort beantwortet, und die Abstufung, die regelt, was einem zusteht, findet sich in proxy SLAs and uptime guarantees.

Das Ziel zeigt sich als Fehler, die auf ein Ziel beschränkt sind, während jede andere Route gesund bleibt, und die Canary für dieses Ziel schlägt fehl, während dessen Geo-Sonden bestehen. Schlägt es aus jeder Region gleichzeitig fehl, hat die Seite wahrscheinlich eigene Probleme; schlägt es nur aus einer Region fehl, hat man es mit einer geo-spezifischen Sperre oder einem regionalen Edge-Problem zu tun.

So instrumentieren, dass diese Vergleiche eine einzelne Abfrage sind statt eines Nachmittags: dieselben Fehlerklassen und Ergebnisse, getaggt mit Route, Region und Worker, reicht aus.

Worauf man alarmieren sollte

Dashboards sind zum Untersuchen da, Alerts sind dafür da, jemanden zu wecken. Das Alert-Set klein halten und jeden einzelnen umsetzbar machen.

Alarmieren, wenn die validierte Erfolgsrate einer Route unter ihre eigene rollierende Baseline fällt, nicht unter einen globalen Schwellenwert, denn eine Route, die normalerweise mit siebzig Prozent gegen ein feindliches Ziel läuft, ist bei siebzig Prozent gesund und bei vierzig Prozent kaputt. Alarmieren bei einer Verschiebung in der Fehlermischung, denn eine Route, die ihre Erfolgsrate hält, während Block-Signale Rate-Signale ersetzen, hat ihren Charakter auf eine Weise verändert, die Ärger vorhersagt. Alarmieren bei steigender Retry-Quote, die vor dem Sinken der Erfolgsrate ansteigt und daher die früheste Warnung ist, die man erhält. Alarmieren bei Coverage, das heißt eine geplante Route, die deutlich weniger Datensätze produziert als ihre eigene jüngste Historie, was stilles Schrumpfen erfasst, das die Erfolgsrate nicht sehen kann. Und alarmieren, wenn eine Sonde für eine Region, auf die man angewiesen ist, wiederholt fehlschlägt.

Anhaltende Abweichung verlangen statt eines einzelnen Intervalls, und gegen eine rollierende Baseline vergleichen. Die Metrikdefinitionen dahinter stehen in proxy KPIs, und die Pipeline-Ebene-Instrumentierung in monitoring a web scraping pipeline.

Das System danach handeln lassen

Monitoring, das nur Grafiken erzeugt, lässt einen Menschen in der Schleife für Probleme, die eine Maschine handhaben sollte. Dieselben Signale sollten automatisches Verhalten steuern: eine Session ausmustern, die Block-Signale ansammelt, einen Circuit Breaker auf einer Route öffnen, deren Erfolgsrate einbricht, damit man aufhört, ein Ziel zu füttern, das nicht antwortet, Arbeit in eine andere Region verschieben, wenn eine sich verschlechtert, gemäß failover in multi-region pipelines, und automatisch zurückfahren, wenn Rate-Signale auftreten. Menschen sollten für Dinge alarmiert werden, die Urteilsvermögen brauchen, nicht für Dinge, die eine Regel brauchen.

Fazit

Im großen Maßstab ist Health keine Eigenschaft des Proxys, sondern eine Eigenschaft jeder Route, die man betreibt, also pro Ziel und Region instrumentieren und Session-Health ein eigenes, kurzlebiges Signal sein lassen. Jedes Ergebnis anhand eines validierten Bodys beurteilen statt anhand eines Statuscodes, denn das ist der Unterschied zwischen Monitoring und Selbsttäuschung. Fehler klassifizieren, da die Mischung einem sagt, ob man langsamer werden, die Identität ändern, das Targeting erweitern oder die eigene Konfiguration reparieren muss. Eine dünne Schicht aus Geo-Sonden und Target-Canaries hinzufügen, um Routen abzudecken, die gerade nicht laufen, und um Anbieterprobleme von Zielproblemen zu trennen. Dann auf anhaltende Abweichung von der eigenen Baseline jeder Route, auf Verschiebungen der Fehlermischung und auf die Retry-Quote alarmieren, und dieselben Signale in automatische Ausmusterung, Backoff und Failover einspeisen, damit das System behebt, was es kann, bevor jemand geweckt wird.

Die darunterliegende Schicht sind residential proxies, bei denen Land- und Stadt-Targeting sowie Session-Kontrolle pro Anfrage ausgedrückt werden, was Route-Level-Health zu einer Frage des Taggens der eigenen Anfragen macht statt zu einem Integrationsprojekt, mit per-GB pricing, sodass eine schlanke Sondenstrategie im Vergleich zur Erfassung selbst fast nichts kostet.