Analytics web self-hosted: quale usare su un VPS?

Quale strumento di analisi web self-hosted conviene eseguire su un VPS?

L'analisi web self-hosted si basa su due famiglie di strumenti. Scegliere la famiglia sbagliata incide più della scelta del prodotto sbagliato. Una famiglia esegue un piccolo script nel browser del visitatore e memorizza i dati restituiti dallo script. L'altra legge il log degli accessi che il web server scrive già. Tutto il resto, incluso il database e la memoria necessaria, dipende da questa scelta.

La risposta breve per un server di piccole dimensioni. GoatCounter e Medama funzionano con 1 GB, perché ciascuno consiste in un processo che opera su un solo file. Umami aggiunge un container Postgres e offre una dashboard leggibile anche da chi non ha competenze tecniche. Plausible Community Edition e Rybbit usano entrambi ClickHouse; occorrono quindi almeno 2 GB di RAM. Matomo è il prodotto completo e richiede un server dimensionato in base al traffico. GoAccess non aggiunge nulla alla pagina, perché legge un log già esistente.

Tag script o log del server: cosa può vedere ciascuno

Un tag script misura i browser. La pagina viene caricata, lo script viene eseguito e invia una richiesta al collector. Tutto ciò che interrompe questa catena non è visibile: JavaScript disattivato, una filter list che blocca la richiesta, una richiesta al collector non riuscita oppure un crawler che non esegue gli script.

Un parser dei log misura le richieste. Il web server scrive una riga per ogni richiesta, indipendentemente dal fatto che sia stato installato o meno un componente aggiuntivo, quindi i dati sono già presenti su disco. Rileva ogni crawler e ogni accesso a un file che non contiene un tag script. Non può vedere cosa è accaduto nel browser. Non può inoltre vedere una pagina servita dalla cache del browser o da una CDN (content delivery network) davanti al server, perché quella richiesta non ha mai raggiunto il server.

I due numeri non coincideranno e nessuno dei due è necessariamente errato. Matomo può usare entrambi i metodi e documenta quali dati si perdono con l'importazione dei log rispetto al suo tracker JavaScript: risoluzione dello schermo e titoli delle pagine, eventi, content tracking, heatmap, registrazioni delle sessioni e analisi dei moduli. Questo è il costo del conteggio delle richieste invece dei browser.

Il traffico dei bot costituisce l'altra metà della differenza. I conteggi basati sui log includono i crawler, a meno che non vengano filtrati. In un sito ordinario, la quota dei crawler è abbastanza elevata da modificare le conclusioni. GoAccess e l'importazione dei log di Matomo filtrano entrambi i bot noti. Nessuno dei due può filtrare un crawler che falsifica il proprio user agent. Per questo è consigliabile combinare qualsiasi conteggio basato sui log con il blocco dei crawler AI sul server e leggere il log dopo il blocco, non prima.

GoAccess: analisi dei log già disponibili

Installalo dal repository ufficiale del progetto per Debian e Ubuntu, perché i pacchetti della distribuzione sono spesso indietro rispetto alle release.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Indirizzalo quindi al log e genera un report statico.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Il comando restituisce Permission denied per un utente normale, perché su Ubuntu il log di nginx appartiene a root e al gruppo adm. Aggiungiti a quel gruppo con sudo usermod -aG adm $USER, quindi esegui il logout e accedi nuovamente: l'appartenenza ai gruppi viene letta al login. Esegui id e verifica che adm compaia nell'elenco prima di riprovare.

Un report basato soltanto sul log attivo include solo gli eventi che logrotate non ha ancora spostato. Le richieste di ieri si trovano in access.log.1, mentre quelle precedenti sono compresse. Per ottenere una vista settimanale devi quindi leggere anche i file ruotati.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

È disponibile anche una modalità live, --real-time-html, che aggiorna la pagina tramite WebSocket. Questa modalità richiede una seconda porta e una regola proxy dedicata. Per la maggior parte dei siti è sufficiente un report orario generato da cron, con meno elementi da proteggere.

GoatCounter: un binario Go e un file SQLite

GoatCounter viene distribuito come binario compilato staticamente, quindi non è necessario installare alcun runtime. Scaricare una build dalla pagina delle release ed eseguirla, oppure usare l'immagine.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Eseguito come binario, goatcounter serve è in ascolto sulla porta 8080 e crea il database SQLite in ./goatcounter-data/db.sqlite3. Creare il primo sito dalla riga di comando anziché tramite la procedura guidata web quando l'istanza si trova già dietro un proxy.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

Può gestire il proprio certificato con goatcounter serve -listen=:443 -tls=tls,rdr,acme, usando ACME (ambiente per la gestione automatica dei certificati). Questa soluzione è utile su un server che non esegue altri servizi. Se nginx o Caddy gestisce già la porta 443, lasciare GoatCounter sulla porta 8080 e inoltrarvi le richieste tramite proxy. Lo script di tracciamento occupa circa 3.5K, secondo la stima del progetto, ed è disponibile anche un pixel di tracciamento per le pagine che non usano JavaScript. Se SQLite diventa il limite su un sito con traffico elevato, lo stesso binario può usare Postgres con goatcounter serve -db 'postgresql+dbname=goatcounter'. I backup consistono nella copia di un file: questo è il principale vantaggio di questa architettura.

Medama: un singolo container che dichiara 256 MB

Medama è l'opzione più recente basata su un singolo binario. Per progettazione non usa cookie e il progetto dichiara un tracker inferiore a 1 KB, oltre a piccoli siti eseguiti su macchine virtuali con 256 MB di memoria. Sono dati dichiarati dal progetto, non valori misurati per questa guida.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

Il comando ufficiale pubblica la porta come 8080:8080. Il prefisso di loopback indicato sopra è intenzionale; la sezione sul reverse proxy spiega il motivo. Il primo accesso usa admin con la password CHANGE_ME_ON_FIRST_LOGIN; il nome di quella password corrisponde all'istruzione.

Una modalità di errore documentata può causare problemi. L'accesso funziona soltanto tramite HTTPS o su localhost. Se configuri il proxy prima del certificato, il modulo rifiuta una password corretta senza visualizzare il motivo. Completa prima la configurazione TLS (transport layer security), quindi accedi.

Umami: PostgreSQL e una dashboard riconoscibile

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Avvia l'applicazione sulla porta 3000 insieme a un container PostgreSQL. La documentazione indica PostgreSQL v12.14 come versione minima e Node.js 18.18 o successive se invece esegui la build dal codice sorgente. È disponibile un'immagine precompilata, docker.umami.is/umami-software/umami:postgresql-latest, che richiede DATABASE_URL configurata per puntare a un database già in esecuzione.

Il primo accesso usa admin con la password umami. Cambiala prima di puntare il DNS al server, perché l'istanza diventa raggiungibile da Internet non appena il record risolve e il proxy risponde. Per i dettagli di Compose, i file di ambiente e la policy di riavvio, consulta uno stack Docker Compose su un VPS invece di copiare uno stack che non hai letto.

L'installazione richiede un processo Node e PostgreSQL. È più pesante di un singolo binario, ma molto più leggera di qualsiasi soluzione che esegua ClickHouse.

Plausible Community Edition: ClickHouse determina il limite minimo di RAM

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

La versione v3.2.1 è quella corrente ad agosto 2026 e il comando clone la fissa intenzionalmente. Lo stack comprende tre componenti: l'applicazione, Postgres per gli account e le impostazioni e ClickHouse per i dati degli eventi. SECRET_KEY_BASE deve essere una stringa di almeno 64 byte, come quella prodotta dalla chiamata openssl.

I requisiti indicati da Plausible richiedono almeno 2 GB di RAM, in modo che ClickHouse e l'applicazione non vengano terminati dall'out of memory killer, e una CPU che supporti SSE 4.2 o NEON, necessario per ClickHouse. Conviene verificare il secondo requisito prima dell'acquisto. È una delle differenze pratiche da considerare nella scelta tra un VPS ARM e uno x86. ClickHouse utilizza inoltre tutta la memoria che ritiene disponibile. Su un server condiviso, quindi, impostare un limite come descritto in come limitare la memoria dei container in Compose.

BASE_URL deve corrispondere esattamente all'URL pubblico. In caso contrario, l'accesso sembra riuscire, ma l'applicazione reindirizza all'host errato. Il cookie di sessione viene scritto per un dominio diverso da quello utilizzato dal browser e si torna al modulo di accesso senza messaggi di errore.

Il file Compose fornito non pubblica alcuna porta, perché presuppone la presenza di un proxy in front-end. Aggiungere un override che pubblichi la porta applicativa predefinita soltanto sull'interfaccia loopback.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo: il prodotto completo e il server richiesto

Matomo funziona con PHP e MySQL o MariaDB. Per questo rientra nel classico stack web, non in uno stack basato su container. È inoltre l'unico strumento qui considerato che pubblica indicazioni sull'hardware in base al volume di traffico.

[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Questi sono i requisiti minimi pubblicati da Matomo ad agosto 2026, non misurazioni eseguite per questa guida. Fino a 100,000 visualizzazioni di pagina al mese richiede 2 core CPU, 2 GB di RAM e 50 GB di SSD. Un solo server ospita sia l'applicazione sia il database. A 1M/month servono 8 GB di RAM e 250 GB di spazio su disco. A 10M/month Matomo raccomanda due server. L'ultima riga mostra i requisiti del server database: 16 GB di RAM e 400 GB di spazio su disco. Confrontate questi valori dello spazio su disco con le opzioni basate su un singolo binario, dove l'intero dataset è contenuto in un unico file SQLite.

L'archiviazione è l'aspetto che sorprende molti utenti. Per impostazione predefinita, Matomo genera i report quando qualcuno apre la dashboard. Con la crescita dei dati, la dashboard diventa quindi più lenta e alla fine va in timeout. La soluzione documentata consiste nel disattivare nelle impostazioni generali l'archiviazione attivata dal browser e nell'eseguire invece l'archiver tramite cron, usando l'utente proprietario dei file Matomo e dalla directory di Matomo.

php console core:archive --url=https://analytics.example.com

Matomo conserva inoltre le tabelle dei log grezzi accanto alle tabelle dei report elaborati e può eliminare secondo una pianificazione i dati grezzi e i report meno recenti. Attivate questa funzione durante l'installazione, non quando il disco è già pieno. Matomo può importare anche i log di accesso del server. È quindi l'unico prodotto qui considerato che copre entrambe le famiglie contemporaneamente.

Rybbit e gli stack più recenti

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit è un progetto recente con una dashboard moderna. Lo script di configurazione crea il file di ambiente e avvia lo stack con Docker Compose. Utilizza ClickHouse e include Caddy come server web, che occupa la porta 443 e richiede un certificato per il dominio specificato. Su un server in cui nginx usa già la porta 443, lo script non riuscirà ad associarsi alla porta. In questo caso, usa la procedura Compose manuale del progetto e configura Rybbit dietro il proxy esistente. La documentazione indica almeno 2 GB di RAM, test eseguiti su Ubuntu 24 LTS e, sui sistemi ARM, ARMv8.2-A o versioni successive a causa di ClickHouse.

Per qualsiasi progetto giovane esiste un limite da considerare: le funzionalità vengono aggiunte rapidamente e altrettanto rapidamente possono arrivare modifiche incompatibili. Fissa un tag, leggi le note di rilascio prima di eseguire il pull e crea prima un backup del database.

Conservazione e crescita dello spazio su disco: misurale sul tuo server

La crescita dello spazio su disco dipende da ciò che lo strumento memorizza per ogni evento. GoatCounter aggrega gli accessi in contatori, quindi il relativo file cresce soprattutto in base al numero di pagine distinte e di giorni, più che al volume grezzo. Umami e Matomo memorizzano una riga per ogni evento, mentre Matomo aggiunge le tabelle dei report elaborati a quelle grezze. ClickHouse memorizza gli eventi per colonne e li comprime in modo aggressivo. Per questo Plausible gestisce volumi che metterebbero sotto pressione un database basato su righe.

Questa guida non pubblica una stima in megabyte per milione di visualizzazioni di pagina, perché non è stata misurata sul tuo traffico. Rilevala direttamente. Adatta i nomi del servizio e dell'utente al tuo file Compose.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Annota il valore, attendi una settimana, annotalo di nuovo e dividi la differenza per le visualizzazioni di pagina riportate dalla dashboard per quella settimana. Questo valore riflette il tuo sito e il filtraggio dei bot, quindi è più utile di qualsiasi media pubblicata. Imposta poi un limite di conservazione, finché il valore è ancora contenuto. Un disco pieno arresta tutti i servizi sul VPS, non soltanto il sistema di analisi. Questo è il motivo principale per tenere il volume del database in un percorso che df -h monitorerà. Il rischio è maggiore su un server che contiene già qualcosa di voluminoso, perché un server fotografico self-hosted esaurirà lo spazio su disco molto prima che un database di analisi si avvicini al limite.

Comportamento dietro un reverse proxy su un sottodominio

Posiziona il collector su un sottodominio del sito che misura, ad esempio stats.example.com. In questo modo la richiesta del collector è first-party e non viene interessata dalle regole del browser che bloccano le richieste di terze parti.

Associare l'applicazione all'interfaccia di loopback quando si pubblica la porta del container. Docker inserisce le proprie regole firewall prima di quelle di ufw, quindi un container pubblicato come -p 3000:3000 è raggiungibile da Internet anche se ufw status indica che la porta è negata. Testare il servizio da un'altra macchina con curl http://SERVER_IP:3000: si otterrà il dashboard. Se viene pubblicato come -p 127.0.0.1:3000:3000, lo stesso test restituisce Connection refused e soltanto il proxy può raggiungerlo. Questa pratica non serve solo a nascondere un dashboard: è fondamentale per eseguire un servizio onion sullo stesso host, perché un servizio che continua a rispondere sull'interfaccia pubblica è l'elemento che consente di ricondurre l'indirizzo nascosto al proprio IP. L'endpoint del collector deve restare raggiungibile da Internet, ma il dashboard no. Se si preferisce consultarlo tramite una rete privata invece di pubblicare un secondo sottodominio, pubblicare la rete del VPS sulla propria tailnet con un subnet router consente di farlo senza aprire una porta.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Gli header di inoltro sono indispensabili in questo caso. Senza X-Forwarded-For, ogni visita risulta provenire da 127.0.0.1, quindi il report per paese è vuoto e i visitatori unici tendono a ridursi a uno. Ogni progetto decide quale header considerare attendibile e con quale impostazione, quindi consulta una volta la relativa documentazione del proxy invece di procedere per supposizioni. Caddy imposta autonomamente questi header e un Caddyfile per lo stesso scopo richiede due righe.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Se non hai ancora scelto un proxy, il confronto tra nginx, Caddy e Traefik spiega quale soluzione è più adatta a un singolo host con alcuni sottodomini.

Ti serve ancora un banner per i cookie se esegui il servizio in self-hosting?

Il self-hosting cambia chi conserva i dati. Non cambia ciò che la legge stabilisce sui dati. Tieni distinti due aspetti. La regola sul consenso prevista dalla normativa ePrivacy riguarda la memorizzazione o la lettura di qualsiasi dato sul dispositivo del visitatore; quindi, uno strumento che non imposta cookie e non scrive nell'archiviazione locale non rientra in questo specifico requisito. Il GDPR riguarda il trattamento dei dati personali e un indirizzo IP è un dato personale. Devi quindi avere una base giuridica, definire un periodo di conservazione e fornire una risposta quando qualcuno chiede quali dati conservi su di lui.

Plausible, Umami, GoatCounter e Medama non impostano cookie per impostazione predefinita. I dati derivati da ciascun progetto sono invece diversi e possono cambiare tra una versione e l'altra. Consulta quindi la documentazione sulla privacy del progetto, non un riepilogo. Matomo include l'anonimizzazione degli indirizzi IP e un endpoint per negare il consenso, che devi abilitare nell'interfaccia di amministrazione.

Le autorità di controllo arrivano a conclusioni diverse nei vari Paesi. La CNIL francese, per esempio, pubblica le condizioni in presenza delle quali la misurazione dell'audience può essere esentata dal consenso. Questa sezione è un riepilogo informativo e non costituisce consulenza legale. Per un sito reale con utenti reali, consulta un avvocato nella tua giurisdizione.

Un aspetto spesso trascurato è che anche un log degli accessi costituisce un dato personale. GoAccess non aggiunge alcuno script alla pagina, ma tratta comunque gli indirizzi IP. Le analisi basate sui log non sono quindi automaticamente escluse dalle regole. Spostare un servizio sul proprio server trasferisce l'esposizione invece di eliminarla. Per lo stesso motivo, cosa nasconde realmente un'istanza self-hosted di SearXNG si limita ai motori di ricerca, mentre le query finiscono comunque nei tuoi log.

Blocco degli annunci e motivo per cui i numeri diminuiranno

Le liste di filtri effettuano il confronto sull'hostname e sul pattern dell'URL. Un prodotto di analisi ospitato è facile da identificare, perché tutti lo caricano dallo stesso hostname noto. Spostare il collector su un sottodominio proprio rimuove quell'hostname dalla richiesta, mentre servire lo script da un percorso scelto da voi rimuove il nome file noto. Entrambe le modifiche cambiano gli elementi su cui una lista deve effettuare il confronto.

Questo articolo non dichiara un tasso di rilevamento, perché non ne ha misurato uno. La percentuale di visitatori che blocca una determinata configurazione dipende dal pubblico; il pubblico degli sviluppatori blocca molto più spesso rispetto a un pubblico generico. Misurate invece il vostro scostamento. Nella stessa settimana, contate con GoAccess le richieste delle pagine HTML nel log degli accessi e confrontatele con le visualizzazioni di pagina riportate dallo strumento basato sullo script. La differenza corrisponde, sul vostro sito, alle visite bloccate più le pagine servite dalla cache.

I totali cambieranno il giorno in cui passerete da un prodotto ospitato; una parte di questa variazione non dipenderà dal blocco. I prodotti non concordano sulla definizione di visualizzazione di pagina, sul fatto che un cambio di route all'interno di una single-page application conti come una visualizzazione e sul momento in cui termina una sessione. Confrontate le tendenze nell'arco di più settimane prima di concludere che il traffico è diminuito.

Quale soluzione per quale sito

• Un sito personale o un blog con circa 50.000 visualizzazioni di pagina al mese: GoatCounter o Medama, su un VPS da 1 GB, con backup costituiti da una copia dei file.
• Un sito in cui non è possibile aggiungere uno script, oppure con un pubblico che blocca intensivamente gli script: GoAccess sui log esistenti, eseguito secondo una pianificazione.
• Un sito di una piccola azienda il cui dashboard viene consultato da altre persone: Umami, con il relativo container Postgres.
• Un sito per cui servono obiettivi e funnel, su un server con almeno 2 GB di RAM: Plausible Community Edition oppure Rybbit, se si preferisce un dashboard più moderno accettando che il progetto sia meno maturo.
• Molti siti, molti account utente oppure la necessità di conservare i dati grezzi secondo una propria policy di retention: Matomo, dimensionato in base alle indicazioni pubblicate sopra.

Iniziate con lo strumento più semplice che risponde alla domanda effettiva. Passare da GoatCounter a Plausible in un secondo momento richiede un sottodominio e comporta una parte di cronologia. Passare da Matomo a un'altra soluzione richiede una migrazione che probabilmente non sarà piacevole. Se state ancora decidendo cos'altro eseguire sullo stesso server, la panoramica più ampia sul self-hosting descrive le soluzioni compatibili, mentre se vi serve davvero il tracing a livello di richiesta di un'applicazione anziché il conteggio dei visitatori, un servizio di observability self-hosted è lo strumento adatto.

FAQ

L'uso di analytics in self-hosting elimina la necessità di un banner per i cookie?

No, e si tratta di due questioni separate. La regola sul consenso prevista dalla direttiva ePrivacy riguarda la memorizzazione o la lettura di informazioni sul dispositivo del visitatore. Pertanto, uno strumento che non imposta cookie e non scrive dati nello storage locale non rientra in quello specifico requisito. Il GDPR è una norma diversa e riguarda il trattamento dei dati personali. Un indirizzo IP è un dato personale, quindi servono comunque una base giuridica e un limite di conservazione, anche senza cookie. Con il self-hosting i dati vengono trasferiti sul proprio server, e la responsabilità del trattamento ricade su di voi. Consultate le indicazioni dell'autorità di controllo competente e chiedete il parere di un legale per il vostro caso.

Quanta RAM richiede l'analytics in self-hosting su un VPS?

La risorsa determinante è il datastore, non la dashboard. GoatCounter e Medama vengono eseguiti come un unico processo e usano un unico file. La documentazione di Medama indica che i siti di piccole dimensioni funzionano su macchine con 256 MB. Umami aggiunge un container Postgres accanto a un'applicazione Node. Plausible Community Edition e Rybbit usano entrambi ClickHouse, e per entrambi i progetti il requisito minimo dichiarato è 2 GB. Le indicazioni ufficiali di Matomo partono da 2 core CPU e 2 GB di RAM per un massimo di 100,000 visualizzazioni di pagina al mese.

Perché i numeri del mio analytics in self-hosting sono inferiori a quelli dello strumento che ho sostituito?

Le cause sono due, ed entrambe sono reali. I filtri bloccano alcune richieste al collector, quindi ogni strumento basato su script perde una parte delle visite. Inoltre, i prodotti contano in modo diverso: la definizione di visualizzazione di pagina e il momento in cui termina una sessione variano da uno strumento all'altro. Confrontate una settimana di richieste HTML al vostro access log con la stessa settimana di visualizzazioni di pagina basate su script. La differenza comprende le visite bloccate e le pagine servite dalla cache, misurate sul vostro sito invece di essere ricavate da una percentuale pubblicata da terzi.

Posso eseguire Plausible o Rybbit su un VPS ARM?

Entrambi usano ClickHouse, che richiede SSE 4.2 su x86 oppure NEON su ARM. I requisiti di Plausible lo specificano esattamente, mentre la documentazione di Rybbit indica che i sistemi ARM richiedono ARMv8.2-A o versioni successive. I core dei server ARM attuali soddisfano questo requisito, quelli più vecchi no. Il problema si manifesta quando ClickHouse rifiuta di avviarsi con un errore relativo al set di istruzioni, non nei log dell'applicazione. Su una macchina ARM di piccole dimensioni, gli strumenti che usano un singolo file evitano il problema, perché nessuno di essi esegue ClickHouse.

Devo analizzare i log del server invece di usare uno script di tracking?

Usate l'analisi dei log quando non potete aggiungere uno script, quando il vostro pubblico utilizza molti strumenti di blocco oppure quando volete un conteggio che includa i crawler. GoAccess legge un log che il server scrive già, quindi non aggiunge peso alle pagine e non richiede un database. In questo modo rinunciate a tutto ciò che avviene nel browser e non rilevate le pagine servite da una CDN o dalla cache del browser, perché la richiesta non ha mai raggiunto il server. Molti siti usano entrambe le soluzioni e le considerano due misurazioni distinte.