Come programmare e monitorare i web scraper come software di produzione
Programmare un scraper è il 20% facile. Tenerlo in vita — cogliere il giorno in cui restituisce silenziosamente righe vuote o un tasso di blocco crescente — è il vero lavoro. Ecco come eseguire i scraper come software di produzione.
Far eseguire un scraper secondo un programma richiede circa cinque righe di codice. Tenerlo a produrre dati corretti per mesi — attraverso cambiamenti di layout, nuovi controlli di accesso e tassi di blocco crescenti — è la vera ingegneria. Un scraper programmato è software di produzione, e il fallimento che dovresti temere non è un crash rumoroso ma uno silenzioso: un'esecuzione che restituisce 200 OK e righe vuote mentre tutti a valle presumono che i dati siano freschi. Questa guida copre programmazione, SLA di freschezza, controlli di qualità, rilevamento delle variazioni e avvisi.
Programmazione: locale, poi cloud
Per una singola macchina, le opzioni più pulite sono la libreria Python schedule per un timing intuitivo in-process, o cron di sistema su macOS e Linux (Task Scheduler su Windows). schedule si legge quasi come l'inglese:
import schedule, time
from my_scraper import run_job
schedule.every().day.at("06:30").do(run_job) # daily pull
schedule.every(10).minutes.do(run_job) # or a tight loop
while True:
schedule.run_pending()
time.sleep(1)Il problema con la programmazione in-process è che muore con il processo. Per qualsiasi cosa importante, passa a un programmatore che sopravvive ai riavvii. Cron è il più semplice; un runner CI gratuito come GitHub Actions è il più portabile, poiché controlla la versione del scraper e del programma insieme:
# crontab -e : run the scraper every day at 06:30, log output
30 6 * * * cd /srv/scraper && /usr/bin/python run.py >> /var/log/scraper.log 2>&1# .github/workflows/scrape.yml (GitHub Actions, free minutes)
name: daily-scrape
on:
schedule:
- cron: '30 6 * * *' # 06:30 UTC daily
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt
- run: python run.py
env:
PROXY_URL: ${{ secrets.PROXY_URL }} # USER:PASS@gate.quantumproxies.io:PORTI runner cloud (GitHub Actions, funzioni gestite, programmatori ospitati) ti offrono anche tentativi e log gratuiti. Qualunque cosa tu scelga, conserva le credenziali proxy in un archivio segreto, non nel repository.
Il vero problema è la variazione, non la programmazione
I scraper scritti contro selettori HTML specifici sono quasi impossibili da mantenere in vita indefinitamente, perché il target cambia sotto di loro. I siti ristrutturano il loro markup, aggiungono controlli di accesso, stringono i limiti di velocità o aggiornano robots.txt, e qualsiasi di questi può trasformare un scraper funzionante in uno che non restituisce nulla — di solito senza generare un errore. Questo è il motivo per cui il monitoraggio è più importante della programmazione: il programmatore esegue il lavoro, ma solo il monitoraggio ti dice che il lavoro ha smesso di produrre dati. Un scraper che continua a restituire risultati vuoti dopo un cambiamento di layout è il caso classico di una pagina che si rende diversamente da quanto ti aspetti.
Rendi la variazione rilevabile, non solo sopravvivibile. Registra il conteggio delle righe e il tasso di riempimento di ogni campo ad ogni esecuzione e conserva quella storia — un semplice grafico di record per esecuzione trasforma un cambiamento di layout silenzioso in un evidente precipizio. Abbinalo a un canarino: esegui lo scraping di una pagina nota di cui hai codificato l'output corretto, e fallisci rumorosamente nel momento in cui il parser restituisce qualcosa di diverso. Rilevare la variazione su una singola pagina canarino è molto più economico che scoprirla una settimana dopo, quando i dati errati si sono già diffusi in ogni report e modello a valle.
Imposta un SLA di freschezza
Decidi quanto vecchi possono essere i tuoi dati e fai rispettare la regola. Se un modello o una dashboard a valle necessita di dati non più vecchi di 24 ore, quello è un SLA di freschezza — e ha bisogno di un avviso, non di una speranza. Timestamp ogni record al momento della raccolta, traccia l'età della riga più recente per fonte, e invia un avviso quando l'ultima estrazione riuscita supera la tua soglia. I dati stantii sono veleno silenzioso proprio perché nulla si rompe; i numeri semplicemente smettono di muoversi. Un modello di monitoraggio continuo — controlla per i cambiamenti e cattura solo ciò che si è mosso — supera il riscraping di tutto alla cieca ed è molto più gentile con il tuo budget di blocco.
I controlli di qualità catturano ciò che i crash non fanno
La guardia più preziosa in una pipeline di scraping è un controllo di validazione che blocca un'esecuzione quando l'output si discosta dalla norma. Imposta soglie esplicite: un conteggio minimo di record per esecuzione (un lavoro che di solito restituisce ~2.000 righe ma ne restituisce 400 è un fallimento infrastrutturale), una quota massima di pagine vuote (diciamo 3%), e regole di adempimento per colonna (titolo e prezzo 100%, un campo opzionale come sconto solo 5%). Blocca in caso di violazione invece di scrivere dati errati a valle:
def quality_gate(rows, min_rows=2000, max_empty=0.03):
empty = sum(1 for r in rows if not r.get("title"))
if len(rows) < min_rows:
raise RuntimeError(f"too few rows: {len(rows)} < {min_rows}")
if empty / max(len(rows), 1) > max_empty:
raise RuntimeError(f"empty pages {empty/len(rows):.0%} over {max_empty:.0%}")
if any(r.get("price") in (None, "") for r in rows):
raise RuntimeError("price column not 100% filled")
return rows # only clean runs reach storage and alerts
Avvisa sul tasso di blocco, non solo sugli errori
Un scraper che improvvisamente viene bloccato spesso esce ancora pulito — restituisce solo risultati più scarsi e più sottili. Traccia il rapporto tra risposte bloccate o sfidate (403, 429, pagine CAPTCHA) e richieste totali, e avvisa quando supera una soglia. Un tasso di blocco crescente è il segnale più precoce che i tuoi IP o impronte digitali vengono segnalati, e ti consente di reagire prima che il set di dati si degradi. La soluzione duratura per il tasso di blocco è a monte: instrada tramite IP residenziali rotanti e lascia che un Scraper API gestisca il rendering, la rotazione e i tentativi in modo che un cambiamento di target non affami silenziosamente la tua pipeline. Quando i 429 si insinuano, la nostra guida al limite di velocità copre il backoff e il pacing.
Mantieni i scraper programmati sbloccati con lo Scraper API
Webhooks e consegna
Chiudi il ciclo con notifiche push invece di polling. Un webhook che si attiva nel momento in cui un'esecuzione termina — con stato, conteggio dei record e id del lavoro — consente ai sistemi a valle di reagire immediatamente e ti dà un battito cardiaco su cui puoi avvisare se manca. Consegna l'output validato all'archiviazione cloud (S3, GCS, un magazzino) piuttosto che a file locali, in modo che un'esecuzione che supera il controllo di qualità fluisca direttamente nell'analisi. Per le code e i tentativi sotto una flotta di lavori programmati, consulta la nostra guida su architettura di scraping su larga scala.
Domande frequenti
Come programmo un web scraper?
Per una singola macchina, usa la libreria Python schedule o cron di sistema; per qualsiasi cosa duratura, usa un programmatore che sopravvive ai riavvii, come cron su un server o un runner CI gratuito come GitHub Actions con un trigger cron. I runner cloud ti offrono anche tentativi e log. Conserva le credenziali proxy in un archivio segreto e controlla la versione del scraper insieme al suo programma.
Come faccio a sapere se il mio scraper programmato si è rotto?
Non fare affidamento sui crash — uno scraper rotto spesso esce pulito con dati vuoti o parziali. Aggiungi un controllo di qualità che verifichi il conteggio minimo di record, la quota di pagine vuote e l'adempimento per colonna, e avvisa quando una qualsiasi soglia viene violata. Traccia anche il tasso di blocco e la freschezza dei dati, poiché uno scraper può restituire silenziosamente risultati stantii o bloccati mentre sembra avere successo.
Perché i scraper programmati smettono di funzionare?
Il target cambia: i siti ristrutturano il loro HTML, aggiungono controlli di accesso, stringono i limiti di velocità o aggiornano robots.txt, e i scraper basati su selettori si rompono contro la nuova pagina. I fallimenti di rete e i tassi di blocco crescenti si aggiungono a questo. Questo è il motivo per cui il monitoraggio — SLA di freschezza, controlli di qualità e avvisi sul tasso di blocco — è più importante del programma stesso; la programmazione esegue il lavoro, il monitoraggio dimostra che funziona ancora.
Cos'è un SLA di freschezza dei dati?
Un SLA di freschezza è l'età massima che i tuoi dati possono raggiungere prima di essere considerati stantii — ad esempio, nessun record più vecchio di 24 ore. Fai rispettare questo timestamping ogni record al momento della raccolta, tracciando la riga più recente per fonte, e avvisando quando l'ultima estrazione riuscita supera il limite. Cattura il fallimento silenzioso dove uno scraper smette di aggiornarsi senza generare errori.
Programma con un programmatore che sopravvive ai riavvii, poi dedica il tuo sforzo dove i fallimenti si nascondono realmente: SLA di freschezza, controlli di qualità, rilevamento delle variazioni e avvisi sul tasso di blocco. Esegui la raccolta su un'infrastruttura che assorbe i cambiamenti di target, e i tuoi scraper si comportano come il software di produzione che sono.