Wenn Proxys in der Produktion verwendet werden – zum Parsen, zur Automatisierung von SMM-Konten oder für großangelegtes Multi-Account-Management – kommt irgendwann der Moment, an dem „es scheint zu funktionieren“ nicht mehr als ausreichende Antwort gilt. Es sind Zahlen erforderlich: wie viele Anfragen mit einem Fehler abgebrochen werden, wie sehr die Latenz nach dem Wechsel des IP-Pools gestiegen ist, ob das Traffic-Limit des Anbieters ausgeschöpft ist. Wir analysieren 7 Metriken, die in Prometheus gesammelt und in Grafana visualisiert werden sollten, um Probleme früher zu erkennen, als sie von Nutzern oder gesperrten Konten wahrgenommen werden.
Warum Proxys in der Produktion überwachen?
Proxys sind keine statische Infrastruktur wie ein Server mit einer festen IP. Es handelt sich um einen ständig wechselnden Pool von Adressen, dessen Verhalten von dem Anbieter, der Last, der Region und sogar der Tageszeit abhängt. Ohne Überwachung erfahren Sie von einem Problem erst, wenn der Parser von Wildberries oder Ozon keine Daten mehr liefert, das Facebook Ads-Konto gesperrt wird oder das Instagram-Automatisierungsskript mit Captchas überflutet wird.
Die Aufgabe der Überwachung besteht darin, das subjektive „irgendetwas stimmt nicht“ in konkrete Zahlen umzuwandeln: Der Anteil der Fehler ist in der letzten Stunde von 2 % auf 15 % gestiegen, die durchschnittliche Latenz hat sich verdreifacht, der Traffic eines Proxys hat das Limit überschritten. Dies ermöglicht es, zu reagieren, bevor das Problem kritisch wird – den Pool automatisch umzuschalten, den Anbieter zu wechseln oder die Anfragefrequenz zu reduzieren.
Zur Erfassung der Metriken verwenden wir die Kombination aus Prometheus (Speicherung von Zeitreihen) + Grafana (Visualisierung und Alarme). Dies ist der Standard-Stack in DevOps, der sich leicht mit jeder Programmiersprache integrieren lässt – Python, Node.js, Go. Im Folgenden finden Sie Beispiele in Python mit der Bibliothek prometheus_client, aber das Prinzip ist universell.
Metrik 1: Erfolgsquote – Anteil erfolgreicher Anfragen
Dies ist eine grundlegende Metrik, die als erste auf Probleme mit dem Proxy-Pool hinweist. Sie wird als Verhältnis der Anfragen mit dem Antwortcode 200-299 zur Gesamtzahl der Anfragen über einen bestimmten Zeitraum berechnet. Ein Rückgang der Erfolgsquote unter 90 % bedeutet in der Regel, dass ein Teil der IP im Pool von der Zielwebsite gesperrt wurde oder der Anbieter instabile Adressen bereitstellt.
Beispiel für Instrumentierung in Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Gesamtanzahl der Anfragen über den Proxy',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # Endpoint für Prometheus-Scrape
PromQL-Abfrage zur Berechnung der Erfolgsquote in den letzten 5 Minuten:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Wenn Sie gleichzeitig mit mehreren Proxy-Typen arbeiten – zum Beispiel residential Proxys für soziale Netzwerke und Datacenter-Proxys für das Parsen – macht es Sinn, die Erfolgsquote nach dem Label proxy_pool zu unterteilen, um zu sehen, welcher Pool tatsächlich degradiert.
Metrik 2: Latenz – Antwortverzögerung
Die Latenz zeigt, wie schnell der Proxy eine Antwort liefert. Ein plötzlicher Anstieg der Latenz geht oft einem Rückgang der Erfolgsquote voraus – der Anbieter ist überlastet oder die IP steht kurz vor der Sperrung und der Zielserver beginnt absichtlich, die Antworten zu verlangsamen. Für die Latenz ist es wichtig, nicht nur den Durchschnittswert zu erfassen, sondern auch die Perzentile – p50, p95, p99, da der Durchschnitt die extremen Verzögerungen verbirgt, die die Arbeit tatsächlich stören.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Dauer der Anfrage über den Proxy',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
PromQL für p95 Latenz:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Für Aufgaben, bei denen Geschwindigkeit entscheidend ist – zum Beispiel bei der Automatisierung von TikTok Ads, wo jede Sekunde Ladezeit das Risiko eines Timeouts im Anti-Detect-Browser erhöht – sollte ein Alarm für p95 über 3-4 Sekunden gesetzt werden.
Metrik 3: Fehlerquote nach Fehlerarten
Eine einfache Erfolgs-/Fehlerbewertung reicht nicht für die Diagnose. Fehler müssen nach Typen unterteilt werden: 407 (Proxy Authentication Required) bedeutet ein Problem mit der Authentifizierung, 429 (Too Many Requests) – Überschreitung des Anfrage-Limits, Timeouts – ein Netzwerkproblem, 403 – Sperrung durch den Anti-Bot-Schutz der Zielwebsite. Jeder Fehler Typ erfordert eine unterschiedliche Reaktion.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Proxyfehler nach Typ',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
Tabelle typischer Fehler und deren Ursachen:
| Code/Typ | Wahrscheinliche Ursache | Was zu überprüfen ist |
|---|---|---|
| 407 | Falsche Anmeldedaten oder abgelaufene Sitzung | Login/Passwort des Proxys, Format der Verbindungszeichenfolge |
| 429 | Anfrage-Limit für IP überschritten | Anfragefrequenz, Poolgröße |
| 403 | Anti-Bot-Schutz der Zielwebsite | User-Agent, Fingerabdruck, Proxy-Typ |
| timeout | Überlastung des Anbieters oder des Netzwerks | Last auf dem Pool, Timeout-Einstellungen des Clients |
Metrik 4: Rotationsgeschwindigkeit und Lebensdauer von IPs
Wenn Sie rotierende Proxys verwenden, ist es wichtig zu wissen, wie oft sich die IP ändert und wie viele Anfragen durchlaufen, bevor die Adresse „verbraucht“ (von der Zielwebsite gesperrt) wird. Diese Metrik ist besonders kritisch für das Multi-Account-Management – zum Beispiel beim Farmen von Facebook Ads-Konten über Dolphin Anty oder AdsPower, wo ein vorzeitiger IP-Wechsel die Sitzung unterbrechen und eine Sicherheitsüberprüfung auslösen kann.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Lebensdauer der IP bis zur Rotation',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Wie viele Anfragen bis zur Sperrung der IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Für mobile Proxys verhält sich diese Metrik anders als für residential Proxys – die Rotation durch den Wechsel der Basisstation des Anbieters liefert „sauberere“ IPs mit geringerer Wahrscheinlichkeit einer Sperrung. Wenn Ihre Aufgabe die SMM-Automatisierung mit hoher Sensibilität für Sperrungen ist, sollten Sie die Lebensdauer von IPs zwischen mobilen Proxys und residential Proxys anhand realer Daten aus Ihrem Dashboard vergleichen, anstatt sich auf allgemeine Empfehlungen zu verlassen.
Metrik 5: Bandbreite – Trafficverbrauch
Die meisten Tarife für Proxys werden nach dem Trafficvolumen und nicht nach der Anzahl der Anfragen berechnet. Ohne Überwachung ist es leicht, den Moment zu verpassen, wenn das Limit fast erreicht ist – insbesondere wenn die Aufgabe das Laden von Bildern oder Videos umfasst, zum Beispiel beim Parsen von Produktkarten auf Wildberries mit einer großen Anzahl von Fotos.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Verbrauchter Traffic über den Proxy',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
Im Grafana-Dashboard ist es nützlich, nicht den absoluten Trafficwert, sondern die Geschwindigkeit des Verbrauchs (rate) darzustellen – das hilft, vorherzusagen, wann das Limit erreicht sein wird, und im Voraus zu planen, ob zusätzliche Kapazitäten benötigt werden oder auf einen anderen Pool gewechselt werden muss.
Metrik 6: Geo-Verteilung und Übereinstimmung mit der Region
Für Vermarkter, die Werbung aus verschiedenen Ländern testen, und für Arbitrageure, die mit Geo-Targeting in Google Ads oder TikTok Ads arbeiten, ist es entscheidend, dass die IP tatsächlich mit der angegebenen Region übereinstimmt. Ein Fehler bei der Geolokalisierung kann dazu führen, dass Werbung nicht der richtigen Zielgruppe angezeigt wird oder das Konto wegen Nichtübereinstimmung der Geo-Einstellungen gesperrt wird.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Fälle von Nichtübereinstimmung zwischen angegebenem und tatsächlichem Geo',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
Es wird empfohlen, die Geo-Überprüfung nicht bei jeder Anfrage durchzuführen (das ist teuer in Bezug auf Traffic und Zeit), sondern periodisch – einmal pro Stunde an einer Stichprobe von IPs aus dem Pool, die statistische Sicherheit bietet.
Metrik 7: Gleichzeitige Verbindungen – parallele Sitzungen
Die Anzahl der gleichzeitigen Verbindungen über den Proxy zeigt die tatsächliche Belastung des Pools an. Wenn die parallelen Sitzungen die Anzahl der IPs im Pool überschreiten, die ohne Degradierung verarbeitet werden können, führt dies direkt zu einem Anstieg der Latenz und der Fehlerquote aus den vorherigen Punkten. Diese Metrik ist besonders wichtig beim Skalieren – wenn eine SMM-Agentur die Anzahl der gleichzeitig aktiven Kundenkonten von 10 auf 50 erhöht.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Aktuelle aktive Verbindungen über den Proxy',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
Die Zuordnung dieser Metrik zur Fehlerquote auf einem Grafana-Diagramm zeigt schnell die Korrelation: Sobald die Anzahl der parallelen Sitzungen einen bestimmten Schwellenwert überschreitet, beginnen die Fehler nicht-linear zu steigen.
Einrichten des Dashboards in Grafana: Schritt für Schritt
Nachdem die Metriken instrumentiert sind und Prometheus sie erfasst, müssen die Daten in Grafana visualisiert werden. Die Schritte sind:
- Fügen Sie Prometheus als Datenquelle hinzu: Konfiguration → Datenquellen → Datenquelle hinzufügen → Prometheus, geben Sie die URL Ihres Prometheus-Servers an (normalerweise
http://localhost:9090). - Erstellen Sie ein neues Dashboard: Erstellen → Dashboard → Neues Panel hinzufügen.
- Für das Panel Erfolgsquote verwenden Sie die PromQL-Abfrage aus dem Abschnitt zur Metrik 1, Visualisierungstyp – Gauge oder Zeitreihe.
- Für die Latenz erstellen Sie ein Panel mit dem Typ Heatmap, um die Verteilung von p50/p95/p99 über die Zeit zu sehen.
- Für die Fehlerquote erstellen Sie ein gestapeltes Balkendiagramm mit Aufschlüsselung nach dem Label
error_type– das zeigt anschaulich, welcher Fehler Typ dominiert. - Fügen Sie eine Dashboard-Variable (Dashboard-Einstellungen → Variablen) für
proxy_poolhinzu, um zwischen Pools zu wechseln, ohne separate Dashboards zu erstellen. - Speichern Sie das Dashboard und richten Sie eine automatische Aktualisierung alle 30 Sekunden für die nahezu Echtzeit-Überwachung ein.
Das fertige JSON-Dashboard kann über Teilen → Exportieren → In Datei speichern exportiert und für verschiedene Proxy-Pools – residential, mobile und Datacenter – wiederverwendet werden, indem nur der Wert der Variablen geändert wird.
Alarme: Wann ist es Zeit zu handeln?
Ein Dashboard ist nutzlos, wenn niemand es im Moment eines Vorfalls betrachtet. Daher ist es entscheidend, Alarme in Grafana (Alarmierung → Alarmregeln) mit den folgenden Schwellenwerten einzurichten, die für die meisten Produktionsszenarien geeignet sind:
| Metrik | Alarmgrenze | Aktion |
|---|---|---|
| Erfolgsquote | unter 85 % in 5 Minuten | Pool überprüfen, auf Backup umschalten |
| p95 Latenz | über 5 Sekunden | Parallelität reduzieren, Anbieter überprüfen |
| Rate 429 | über 10 % der Anfragen | Anfragefrequenz reduzieren, IP-Pool erhöhen |
| Bandbreitenrate | Prognose für das Erreichen des Limits in 24 Stunden | Traffic nachkaufen oder Anfragen optimieren |
Alarme sollten besser über Telegram oder Slack über Webhooks gesendet werden – dies gewährleistet eine sofortige Reaktion und nicht eine tägliche Überprüfung des Dashboards.
Fazit
Sieben Metriken – Erfolgsquote, Latenz, Fehlerquote nach Typen, Lebensdauer von IPs, Traffic, Geo-Übereinstimmung und Konkurrenzfähigkeit der Verbindungen – bieten ein vollständiges Bild der Gesundheit der Proxy-Infrastruktur in der Produktion. Die Kombination aus Prometheus + Grafana ermöglicht es nicht nur, Probleme nachträglich zu erfassen, sondern auch Trends zu erkennen und zu reagieren, bevor die Degradierung des Pools zu Kontosperrungen oder einem Stop des Parsens führt.
Die Wahl des Proxy-Typs beeinflusst direkt, welche Metriken Priorität haben: Für Aufgaben mit hoher Sensibilität für Sperrungen, wie Multi-Account-Management in Instagram oder TikTok, sollte in erster Linie die Lebensdauer der IP und die Erfolgsquote überwacht werden, wobei residential Proxys für maximale Ähnlichkeit mit dem echten Nutzertraffic verwendet werden. Für Aufgaben, bei denen Geschwindigkeit und Volumen wichtig sind – massives Parsen von Ozon, Avito oder Yandex.Market – stehen Latenz und Bandbreite im Vordergrund, und hier arbeiten oft Datacenter-Proxys aufgrund ihrer höheren Bandbreite effektiver.