Se i proxy sono utilizzati in produzione - per il parsing, l'automazione degli account SMM o il multi-accounting su larga scala - prima o poi arriva il momento in cui "sembra funzionare" non è più una risposta sufficiente. Servono numeri: quante richieste falliscono con errore, quanto è aumentata la latenza dopo il cambio del pool di IP, se il limite di traffico del provider è esaurito. Analizziamo 7 metriche che vale la pena raccogliere in Prometheus e visualizzare in Grafana, per vedere i problemi prima che li vedano gli utenti o gli account bloccati.
Perché monitorare i proxy in produzione
I proxy non sono un'infrastruttura statica come un server con un IP fisso. Si tratta di un pool di indirizzi in continua evoluzione, il cui comportamento dipende dal provider, dal carico, dalla regione e persino dall'ora del giorno. Senza monitoraggio, si scopre un problema solo quando il parser di Wildberries o Ozon smette di restituire dati, l'account pubblicitario di Facebook Ads blocca l'account, o lo script di automazione di Instagram inizia a mostrare captcha.
L'obiettivo del monitoraggio è trasformare il soggettivo "qualcosa non va" in numeri concreti: la percentuale di errori è aumentata dal 2% al 15% nell'ultima ora, la latenza media è triplicata, il traffico su un proxy ha superato il limite. Questo consente di reagire prima che il problema diventi critico - passando automaticamente a un altro pool, cambiando provider o riducendo la frequenza delle richieste.
Per raccogliere le metriche utilizziamo la combinazione Prometheus (archiviazione di serie temporali) + Grafana (visualizzazione e allerta). Questo è uno stack standard in DevOps, facilmente integrabile con qualsiasi linguaggio - Python, Node.js, Go. Di seguito sono riportati esempi in Python con la libreria prometheus_client, ma il principio è universale.
Metrica 1: Tasso di Successo — percentuale di richieste riuscite
Questa è una metrica di base che segnala per prima i problemi con il pool di proxy. Si calcola come il rapporto tra le richieste con codice di risposta 200-299 e il numero totale di richieste in un determinato periodo di tempo. Una diminuzione del tasso di successo al di sotto del 90% di solito significa che parte degli IP nel pool è stata bloccata dal sito target o che il provider sta restituendo indirizzi instabili.
Esempio di strumentazione in Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Totale richieste tramite 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 per Prometheus scrape
Query PromQL per calcolare il tasso di successo negli ultimi 5 minuti:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Se stai lavorando con più tipi di proxy contemporaneamente - ad esempio, proxy residenziali per i social media e proxy di data center per il parsing - ha senso suddividere il tasso di successo per l'etichetta proxy_pool, per vedere quale pool sta degradando.
Metrica 2: Latenza — ritardo nella risposta
La latenza mostra quanto velocemente il proxy restituisce una risposta. Un aumento improvviso della latenza spesso precede una diminuzione del tasso di successo - il provider è sovraccarico, o l'IP è già vicino al blocco e il server target inizia a rallentare intenzionalmente le risposte. Per la latenza è importante raccogliere non solo il valore medio, ma anche i percentili - p50, p95, p99, poiché la media nasconde i ritardi estremi che realmente ostacolano il lavoro.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Durata della richiesta tramite 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 per p95 latenza:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Per compiti in cui la velocità è critica - ad esempio, nell'automazione di TikTok Ads, dove ogni secondo di caricamento della pagina aumenta il rischio di timeout nel browser anti-detect - è consigliabile impostare un allerta su p95 superiore a 3-4 secondi.
Metrica 3: Tasso di Errore per tipi di errore
Un semplice successo/fallimento non è sufficiente per la diagnosi. È necessario separare gli errori per tipo: 407 (Proxy Authentication Required) indica un problema di autorizzazione, 429 (Too Many Requests) - superamento del limite di richieste, timeout - problema di rete, 403 - blocco per protezione anti-bot del sito target. Ogni tipo di errore richiede una reazione diversa.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Errori proxy per tipo',
['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"
Tabella degli errori tipici e delle loro cause:
| Codice/tipo | Probabile causa | Cosa controllare |
|---|---|---|
| 407 | Credenziali errate o sessione scaduta | Login/password del proxy, formato della stringa di connessione |
| 429 | Superato il limite di richieste per IP | Frequenza delle richieste, dimensione del pool |
| 403 | Protezione anti-bot del sito target | User-Agent, fingerprint, tipo di proxy |
| timeout | Sovraccarico del provider o della rete | Carico sul pool, impostazioni di timeout del client |
Metrica 4: Velocità di rotazione e longevità degli IP
Se utilizzi proxy rotanti, è importante sapere quanto spesso cambia l'IP e quante richieste riescono a passare prima che l'indirizzo "bruci" (venga bloccato dal sito target). Questa metrica è particolarmente critica per il multi-accounting - ad esempio, nel farming di account Facebook Ads tramite Dolphin Anty o AdsPower, dove un cambio prematuro di IP può interrompere la sessione e attivare un controllo di sicurezza.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Tempo di vita dell\'IP prima della rotazione',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Quante richieste sono passate prima del ban dell\'IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Per i proxy mobili, questa metrica si comporta in modo diverso rispetto a quella residenziale - la rotazione tramite cambio della stazione base dell'operatore fornisce IP più "puliti" con minore probabilità di ban. Se il tuo obiettivo è l'automazione SMM con alta sensibilità ai ban, è consigliabile confrontare i dati sulla longevità degli IP tra proxy mobili e residenziali utilizzando dati reali dal tuo dashboard, piuttosto che fare affidamento su raccomandazioni generali.
Metrica 5: Larghezza di banda — consumo di traffico
La maggior parte delle tariffe per i proxy è calcolata in base al volume di traffico, non al numero di richieste. Senza monitoraggio, è facile perdere il momento in cui il limite è quasi esaurito - soprattutto se il compito include il caricamento di immagini o video, ad esempio durante il parsing delle schede prodotto di Wildberries con un gran numero di fotografie.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Traffico consumato tramite 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)
Nel dashboard di Grafana è utile costruire non il valore assoluto del traffico, ma la velocità di consumo (rate) - questo aiuta a prevedere quando il limite finirà e pianificare in anticipo l'acquisto o il passaggio a un altro pool.
Metrica 6: Geo-distribuzione e corrispondenza regionale
Per i marketer che testano pubblicità da diversi paesi e per gli arbitraggisti che lavorano con geo-targeting in Google Ads o TikTok Ads, è critico che l'IP corrisponda realmente alla regione dichiarata. Un errore di geolocalizzazione può portare a mostrare pubblicità al pubblico sbagliato o al blocco dell'account per non conformità alle impostazioni geografiche.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Casi di non corrispondenza tra geo dichiarato e reale',
['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()
È consigliabile verificare la geolocalizzazione non ad ogni richiesta (questo è costoso in termini di traffico e tempo), ma periodicamente - una volta all'ora su un campione di IP dal pool, sufficiente per una confidenza statistica.
Metrica 7: Connessioni Concomitanti — sessioni parallele
Il numero di connessioni simultanee tramite proxy mostra il carico reale sul pool. Se le sessioni parallele superano il numero di IP nel pool che possono essere gestiti senza degradazione, ciò porta direttamente a un aumento della latenza e del tasso di errore dei punti precedenti. Questa metrica è particolarmente importante durante la scalabilità - quando un'agenzia SMM aumenta il numero di account clienti attivi da 10 a 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Connessioni attive correnti tramite 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()
Confrontare questa metrica con il tasso di errore su un unico grafico in Grafana mostrerà rapidamente la correlazione: non appena il numero di sessioni parallele supera una certa soglia, gli errori iniziano a crescere in modo non lineare.
Configurazione del dashboard in Grafana: passo dopo passo
Dopo che le metriche sono state strumentate e Prometheus le raccoglie, è necessario visualizzare i dati in Grafana. Ordine delle operazioni:
- Aggiungi Prometheus come fonte di dati: Configurazione → Fonti di dati → Aggiungi fonte di dati → Prometheus, specifica l'URL del tuo server Prometheus (di solito
http://localhost:9090). - Crea un nuovo dashboard: Crea → Dashboard → Aggiungi nuovo pannello.
- Per il pannello Tasso di Successo utilizza la query PromQL della sezione sulla metrica 1, tipo di visualizzazione - Gauge o Serie temporali.
- Per la Latenza crea un pannello con tipo Heatmap, per vedere la distribuzione di p50/p95/p99 nel tempo.
- Per il Tasso di Errore costruisci un Grafico a Barre Impilate con suddivisione per l'etichetta
error_type- questo mostrerà chiaramente quale tipo di errore domina. - Aggiungi una variabile del dashboard (Impostazioni Dashboard → Variabili) per
proxy_pool, per passare tra i pool senza creare dashboard separati. - Salva il dashboard e imposta l'aggiornamento automatico ogni 30 secondi per un monitoraggio quasi in tempo reale.
Il JSON del dashboard pronto può essere esportato tramite Condividi → Esporta → Salva su file e riutilizzato per diversi pool di proxy - residenziali, mobili e di data center, cambiando solo il valore della variabile.
Allerta: quando è il momento di agire
Il dashboard è inutile se nessuno lo guarda al momento dell'incidente. Pertanto, è fondamentale impostare allerta in Grafana (Allerta → Regole di allerta) con i seguenti valori soglia, scelti per la maggior parte degli scenari di produzione:
| Metodologia | Soglia di allerta | Azione |
|---|---|---|
| Tasso di Successo | sotto il 85% per 5 minuti | Controllare il pool, passare a quello di riserva |
| p95 Latenza | superiore a 5 secondi | Ridurre il parallelismo, controllare il provider |
| Tasso 429 | superiore al 10% delle richieste | Ridurre la frequenza delle richieste, aumentare il pool di IP |
| Tasso di larghezza di banda | previsione di esaurimento del limite in 24 ore | Acquistare traffico o ottimizzare le richieste |
È meglio indirizzare le allerta su Telegram o Slack tramite webhook - questo assicura una reazione immediata, piuttosto che controllare il dashboard una volta al giorno.
Conclusione
Sette metriche - tasso di successo, latenza, tasso di errore per tipi, longevità degli IP, traffico, corrispondenza geo e concorrenza delle connessioni - forniscono un quadro completo della salute dell'infrastruttura proxy in produzione. La combinazione Prometheus + Grafana consente non solo di registrare il problema post-fatto, ma di vedere le tendenze e reagire prima che la degradazione del pool porti a ban degli account o all'interruzione del parsing.
La scelta del tipo di proxy influisce direttamente su quali metriche saranno prioritarie: per compiti con alta sensibilità ai ban, come il multi-accounting su Instagram o TikTok, è consigliabile monitorare prima di tutto la longevità degli IP e il tasso di successo, utilizzando proxy residenziali per la massima somiglianza con il traffico reale degli utenti. Per compiti in cui la velocità e il volume sono importanti - parsing massivo di Ozon, Avito o Yandex.Market - la latenza e la larghezza di banda diventano cruciali, e qui spesso funzionano meglio proxy di data center grazie a una maggiore capacità di throughput.