AIOps su VPS: monitoraggio IA self-hosted open source

Datadog e New Relic addebitano per host, per GB, o entrambi. Per uno sviluppatore indipendente o un piccolo team che gestisce da uno a cinque VPS, questi costi si accumulano velocemente con scarso ritorno. Consulta la pagina prezzi di Datadog e la pagina prezzi di New Relic per le tariffe attuali.

L'alternativa: eseguire l'intero stack di monitoraggio, analisi dei log e risposta agli incidenti su un singolo VPS. Strumenti open source come SigNoz, Grafana+Loki e Ollama offrono osservabilità, rilevamento delle anomalie basato sull'IA e rimedio automatizzato. Costo totale: il prezzo del tuo VPS. Su Virtua Cloud, si parte da 24 EUR/mese per un server con 2 vCPU e 4 GB di RAM per l'osservabilità di base, o 48 EUR/mese per lo stack completo su un server con 4 vCPU e 8 GB di RAM.

Questo articolo mappa i cinque livelli di uno stack AIOps self-hosted. Non è un tutorial passo dopo passo. Ogni sezione spiega cosa fa il livello, consiglia gli strumenti e rimanda alla guida dedicata dove installi e configuri tutto.

Cos'è l'AIOps e perché è importante per gli operatori VPS?

AIOps significa usare l'IA e il machine learning per automatizzare monitoraggio, analisi dei log, rilevamento delle anomalie e risposta agli incidenti. Per gli operatori VPS, sostituisce il ciclo manuale di controllare le dashboard, leggere i log e riavviare i servizi. Invece di pagare piattaforme SaaS enterprise, esegui strumenti open source sulla stessa infrastruttura che già gestisci. I tuoi dati restano sul tuo server. I tuoi costi restano fissi.

La definizione enterprise di AIOps si concentra sulla correlazione di migliaia di alert attraverso centinaia di microservizi. Non è di questo che parla questa guida. Per gli operatori VPS che gestiscono da uno a cinque server, AIOps significa:

Raccogliere metriche, log e tracce in un unico posto invece di collegarsi via SSH a ogni server.
Eseguire un LLM locale per individuare pattern nei log che grep e le espressioni regolari non rilevano.
Automatizzare le risposte ai guasti comuni come un disco pieno, un processo crashato o un memory leak.
Ottenere feedback dell'IA sul codice prima che arrivi in produzione.

Lo stack ha cinque livelli. Non servono tutti. Inizia con l'osservabilità, aggiungi l'analisi IA quando il volume dei log rende dolorosa la revisione manuale, e procedi verso il self-healing man mano che acquisisci fiducia.

Quanto costa il monitoraggio self-hosted rispetto a Datadog?

Uno stack AIOps self-hosted su un VPS Virtua Cloud costa tra 24 e 96 EUR/mese a seconda di quanti livelli distribuisci. Questo è il costo totale: server, storage, banda e tutto il software. Le alternative commerciali come Datadog usano modelli di prezzo per host e per GB che scalano con la tua infrastruttura. I loro costi crescono quando aggiungi host, ingerisci più log o attivi il tracing APM.

Funzionalità	SaaS commerciale (Datadog, New Relic)	Self-Hosted (VPS Virtua Cloud)
Monitoraggio infrastruttura	Prezzo per host, a livelli per piano	Incluso (Prometheus + Grafana)
Gestione log	Tariffa per GB ingerito + indicizzazione per evento	Incluso (Loki o OpenObserve)
APM / Tracce	Tariffa aggiuntiva per host	Incluso (SigNoz o Tempo)
Analisi log con IA	Non disponibile o add-on separato	Incluso (Ollama + LLM locale)
Alerting	Incluso	Incluso (Alertmanager)
Conservazione dati	Limiti definiti dal fornitore (giorni a mesi)	Lo decidi tu. Il disco è il limite.
Localizzazione dati	US/EU (scegli la regione)	Il tuo VPS. La tua giurisdizione.
Modello di prezzo	Per host + per GB, cresce con l'uso	Costo VPS mensile fisso

Per i prezzi commerciali attuali, consulta i prezzi di Datadog e i prezzi di New Relic. I costi self-hosted dipendono solo dal piano VPS scelto.

La colonna self-hosted assume un singolo piano vCS-8 (4 vCPU, 8 GB di RAM, 160 GB SSD) che esegue lo stack di osservabilità completo via Docker Compose. Se hai bisogno solo di metriche e log di base, un vCS-4 (2 vCPU, 4 GB di RAM) a 24 EUR/mese gestisce Grafana + Loki + Prometheus per carichi di lavoro ridotti.

Per i team che vogliono anche il livello di analisi IA (Ollama con un modello da 3-7 miliardi di parametri), il VPS da 8 GB è il minimo. Ollama con Gemma 2 (2B) funziona con circa 2 GB di RAM, lasciando margine sufficiente per SigNoz o Grafana a fianco.

Quali strumenti di osservabilità open source funzionano meglio su un VPS?

Il livello di osservabilità raccoglie metriche, log e tracce dalle tue applicazioni e dalla tua infrastruttura. Tre stack open source dominano questo spazio: SigNoz, OpenObserve e Grafana + Loki. Ognuno fa compromessi diversi tra funzionalità, uso delle risorse e complessità.

Strumento	Ideale per	Log	Metriche	Tracce	Backend	RAM min	Complessità
SigNoz	Sostituzione APM completa di Datadog	Sì	Sì	Sì	ClickHouse	4 GB	Media
OpenObserve	Aggregazione log leggera	Sì	Sì	Sì	Nativo (Rust)	~1 GB	Bassa
Grafana + Loki + Prometheus	Ecosistema consolidato, estensibilità	Sì (Loki)	Sì (Prometheus)	Via Tempo	Multiplo	2-4 GB	Più alta

Tutti e tre supportano OpenTelemetry per la strumentazione. Questo significa che puoi strumentare la tua applicazione una volta sola e cambiare backend in seguito senza modificare il codice applicativo.

Quando scegliere SigNoz invece di OpenObserve?

Scegli SigNoz quando hai bisogno di un monitoraggio delle prestazioni applicative completo: tracce distribuite, mappe dei servizi, tracciamento degli errori e log correlati. SigNoz usa ClickHouse come motore di storage, che gestisce bene i dati ad alta cardinalità ma richiede più RAM. Un deployment Docker Compose necessita di almeno 4 GB di RAM dedicati a SigNoz, con 8 GB consigliati per carichi di produzione che includono ClickHouse.

Scegli OpenObserve quando la tua esigenza principale è l'aggregazione e la ricerca dei log. OpenObserve viene distribuito come un singolo binario scritto in Rust. Si avvia con meno di 1 GB di RAM in una configurazione Docker Compose di base. Dichiara costi di storage 140 volte inferiori rispetto a Elasticsearch grazie alla compressione colonnare. Se sei un indie hacker che gestisce una singola applicazione e vuole una ricerca log veloce senza l'overhead di ClickHouse, OpenObserve è il percorso più leggero.

Entrambi gli strumenti hanno interfacce web per query e dashboard. SigNoz offre un'esperienza più completa, simile a Datadog. OpenObserve è più snello e più veloce da distribuire.

Grafana + Loki è ancora la scelta migliore nel 2026?

Grafana + Loki resta l'opzione più flessibile. Non è la più semplice da configurare, ma vince per ampiezza dell'ecosistema. Esistono migliaia di dashboard della community per ogni servizio immaginabile. Gli exporter Prometheus coprono database, web server, metriche hardware e metriche applicative personalizzate. Loki gestisce l'aggregazione dei log con un linguaggio di query LogQL che rispecchia PromQL.

Il compromesso: più componenti mobili. Uno stack Grafana minimale significa eseguire Grafana (UI), Prometheus (metriche) e Loki (log) come container separati. Aggiungi Promtail o Alloy come agente di raccolta log. Sono quattro container prima di aggiungere la tua applicazione. Su un VPS da 4 GB, questo stack ci sta ma lascia poco margine.

Scegli Grafana + Loki quando conosci già l'ecosistema, hai bisogno di personalizzazione avanzata o vuoi integrare strumenti che supportano solo l'esportazione di metriche Prometheus.

Come si aggiunge l'analisi dei log con IA allo stack di monitoraggio?

Esegui un LLM locale tramite Ollama per analizzare i log senza inviare dati a nessuna API esterna. Ollama serve modelli come Gemma 2 (2B), Llama 3.2 (3B) o Qwen 2.5 (7B) attraverso un'API HTTP locale. Uno script o un cron job alimenta il modello con frammenti di log e gli chiede di identificare anomalie, riassumere pattern di errore o suggerire cause radice. Nessun costo API. Nessun dato che lascia il tuo server.

È qui che l'AIOps self-hosted diverge dal monitoraggio tradizionale. Grafana e Prometheus ti dicono cosa è successo. Un LLM locale ti aiuta a capire perché.

Cosa fa il livello di analisi IA:

Rilevamento anomalie: fornisci al modello le ultime 1.000 righe di log con un prompt come "identifica pattern insoliti o errori in questi log". Il modello segnala le voci che deviano dai pattern normali.
Riepilogo errori: quando un incidente genera centinaia di righe di log, il LLM le condensa in un riepilogo leggibile con la causa radice probabile.
Riconoscimento di pattern: nel tempo, emergono pattern di errore ricorrenti. Il LLM può raggruppare errori correlati e identificare problemi ricorrenti che non farebbero scattare alert basati su soglie.

Dimensionamento dei modelli per VPS:

Modello	Parametri	Uso RAM	Velocità (token/sec, CPU)	Ideale per
Gemma 2 (2B)	2,6 Mld	~2 GB	~15-20	Triage rapido dei log su VPS con poca RAM
Llama 3.2 (3B)	3,2 Mld	~2,5 GB	~10-15	Analisi e velocità bilanciate
Qwen 2.5 (7B)	7 Mld	~5 GB	~5-8	Analisi approfondita, richiede VPS da 8 GB+

Su un VPS con 4 vCPU senza GPU, l'inferenza è solo su CPU. Un modello da 2-3 miliardi produce analisi dei log utile in 5-15 secondi per query. Abbastanza veloce per analisi a lotti ogni pochi minuti, non per streaming in tempo reale.

Non è magia. I modelli piccoli allucinano. Perdono contesto. A volte segnalano voci di log normali come sospette. Tratta l'analisi dei log con LLM come un assistente di triage, non come un oracolo. Verifica sempre i suoi suggerimenti confrontandoli con log e metriche reali.

Cos'è un VPS auto-riparante e come funziona?

Un VPS auto-riparante rileva e rimedia automaticamente i guasti comuni senza intervento umano. L'architettura di base: Prometheus monitora le metriche, Alertmanager lancia alert quando le soglie vengono superate, e un ricevitore webhook esegue script di rimedio. Aggiungere un LLM a questo ciclo permette di gestire guasti che non corrispondono a regole predefinite.

La pipeline di self-healing:

Prometheus raccoglie metriche ogni 15 secondi (CPU, memoria, disco, stato dei processi, tassi di errore HTTP).
Le regole di alerting definiscono condizioni: uso del disco sopra il 90%, un servizio che non risponde da 60 secondi, uso della memoria costantemente sopra il 95%.
Alertmanager riceve l'alert e lo instrada verso un endpoint webhook.
Il gestore del rimedio riceve il webhook. Per condizioni note (disco pieno, servizio crashato), esegue uno script predefinito. Per condizioni sconosciute, chiama il LLM locale via Ollama con il contesto dell'alert e i log recenti, chiedendo una diagnosi e un suggerimento di rimedio.
Esecuzione (opzionale): per rimedi noti ad alta confidenza (riavviare un servizio, svuotare i file temporanei, ruotare i log), il gestore esegue automaticamente. Per azioni suggerite dal LLM, invia il suggerimento al tuo canale di notifica per l'approvazione umana.

Rimedi automatizzati comuni:

Disco pieno: svuotare /tmp, ruotare i log vecchi, pulire le immagini Docker con docker system prune.
Servizio crashato: systemctl restart <service>, poi verificare che sia sano. Se crasha di nuovo entro 5 minuti, escalare a un umano.
Pressione sulla memoria: identificare il maggiore consumatore di memoria, riavviarlo se supera la sua baseline prevista.
Scadenza del certificato: attivare un rinnovo Certbot quando il certificato ha meno di 7 giorni rimanenti.

Inizia in modo conservativo. Automatizza solo i rimedi che hai eseguito manualmente decine di volte e che comprendi perfettamente. Lascia che il LLM suggerisca azioni per situazioni sconosciute, ma tieni un umano nel ciclo per l'esecuzione.

Per un approccio no-code all'instradamento degli alert e ai workflow di rimedio, n8n può fungere da livello di orchestrazione tra Alertmanager e i tuoi script di rimedio.

Come si integra l'IA nella tua pipeline CI/CD?

La revisione del codice con IA rileva bug, problemi di sicurezza e problemi di prestazioni prima che il codice raggiunga il tuo server. I workflow di GitHub Actions possono inviare i diff delle pull request a Claude o Gemini per l'analisi, pubblicare commenti di revisione e bloccare i merge quando vengono trovati problemi critici. Questo gira nella tua pipeline CI/CD senza modifiche al tuo VPS.

Cosa rileva la revisione del codice con IA che i linter non trovano:

Errori di logica e casi limite che l'analisi statica non può rilevare.
Vulnerabilità di sicurezza nel contesto (un linter segnala le funzioni pericolose, ma un LLM capisce perché il codice circostante le rende sfruttabili).
Regressioni di prestazioni: "questa query dentro un ciclo interrogherà il database N volte".
Lacune nella documentazione: gestione degli errori mancante, nomi di variabili poco chiari, effetti collaterali non documentati.

Questo livello è diverso dagli altri perché tipicamente gira nella tua piattaforma CI (GitHub Actions, GitLab CI), non sul tuo VPS. Tuttavia, se vuoi mantenere tutto self-hosted, puoi eseguire un CI runner sul tuo VPS e instradare le richieste di revisione del codice alla tua istanza locale di Ollama. Il compromesso: revisioni più lente con modelli più piccoli contro revisioni più veloci e accurate con API cloud.

Cos'è l'osservabilità LLM e perché ne hai bisogno?

L'osservabilità LLM traccia le prestazioni dei tuoi strumenti IA: uso dei token, latenza, tassi di errore, costi e qualità dell'output. Se esegui una qualsiasi funzionalità alimentata da LLM (chatbot, assistente al codice, analizzatore di log, generatore di contenuti), Langfuse ti dà visibilità su ogni chiamata. È il livello "monitorare i monitor" del tuo stack AIOps.

Langfuse è una piattaforma open source per l'ingegneria LLM. Self-hosted, funziona con due container (web + worker) con PostgreSQL e opzionalmente ClickHouse per l'analitica. Fornisce:

Tracing: vedere ogni chiamata LLM con input, output, latenza e conteggio token. Esplorare i workflow degli agent multi-step per trovare dove vengono spesi tempo e token.
Valutazione: dare un punteggio agli output con LLM-as-a-judge, feedback umano o metriche personalizzate. Monitorare la qualità nel tempo.
Tracciamento dei costi: calcolare la spesa reale per chiamata LLM, per utente, per funzionalità. Confrontare le prestazioni dei modelli a diversi livelli di prezzo.
Gestione dei prompt: versionare e fare test A/B sui prompt. Fare rollback quando un nuovo prompt degrada la qualità dell'output.

Se esegui Ollama per l'analisi dei log (livello 2 di questo stack), Langfuse traccia ogni richiesta di analisi. Vedi quali query sui log producono risultati utili, quali creano difficoltà al modello e come cambia la latenza quando cambi modello.

Langfuse si integra con OpenTelemetry, LangChain, LlamaIndex e l'SDK OpenAI (con cui Ollama è compatibile). La strumentazione di solito richiede poche righe di codice.

Hai bisogno di questo livello quando il tuo utilizzo degli LLM va oltre la sperimentazione. Una volta che dipendi dagli output dell'IA per l'alerting o il rimedio, devi sapere quando il modello inizia a produrre risultati inutili.

Di quali risorse VPS hai bisogno per uno stack AIOps completo?

Le risorse dipendono da quali livelli distribuisci. Ecco tre configurazioni mappate ai piani VPS di Virtua Cloud:

Configurazione	Livelli	Piano VPS	CPU	RAM	Disco	EUR/mese
Starter	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 GB	80 GB	24
Standard	SigNoz + Ollama (modello 3B)	vCS-8	4 vCPU	8 GB	160 GB	48
Stack completo	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

Starter gestisce metriche e aggregazione log per da una a tre piccole applicazioni. Dashboard e alert senza analisi IA.

Standard aggiunge l'analisi dei log con IA. SigNoz occupa circa 4 GB e Ollama con un modello 3B usa circa 2,5 GB. La RAM rimanente va al sistema operativo e alle tue applicazioni monitorate. È il punto ottimale per uno sviluppatore indipendente o un piccolo team.

Stack completo esegue tutti i livelli descritti in questa guida. Un modello da 7 miliardi di parametri produce un'analisi migliore di un modello 3B ma richiede più RAM. Langfuse aggiunge circa 1 GB. Questa configurazione è per team che eseguono funzionalità alimentate da LLM in produzione e hanno bisogno di osservabilità totale sulla loro infrastruttura e sulla loro IA.

Tutte le configurazioni eseguono tutto tramite Docker Compose. Gli articoli dedicati coprono i file docker-compose.yml esatti per ogni strumento.

Una nota sull'uso del disco: i dati di osservabilità crescono in fretta. SigNoz con ClickHouse comprime bene (aspettati una compressione 5-10x sui log), ma prevedi da 1 a 5 GB di nuovi dati al giorno a seconda della verbosità dei tuoi log. Imposta le policy di conservazione fin dal primo giorno. Un disco da 160 GB ti dà circa da uno a tre mesi di dati a tassi di ingestione moderati.

Quando esegui il tuo stack di monitoraggio su un VPS europeo, i tuoi dati di osservabilità non lasciano mai la giurisdizione. Metriche, log e tracce contengono spesso dati personali: indirizzi IP, ID utente, percorsi delle richieste, messaggi di errore con contesto utente. Inviare quei dati a una piattaforma SaaS basata negli Stati Uniti introduce un rischio di trasferimento GDPR, anche quando il provider offre una regione EU.

Con uno stack self-hosted su un VPS Virtua Cloud in Francia o Germania, controlli:

Dove sono archiviati i dati. Su disco, nel tuo VPS, in un data center europeo.
Chi può accedervi. Nessun dipendente del fornitore, nessun sub-processore, nessun accordo di trattamento dati con terze parti da auditare.
Per quanto tempo vengono conservati. Tu imposti la policy di conservazione. Nessun minimo imposto dal fornitore né calendari di cancellazione dati.

Questa non è un'opinione legale. Consulta il tuo responsabile della protezione dei dati per la tua situazione specifica. Ma dal punto di vista tecnico, il monitoraggio self-hosted elimina un'intera categoria di domande sul trasferimento dei dati.

Da dove dovresti iniziare?

Il tuo punto di partenza dipende dalla tua esperienza e dal problema che stai risolvendo adesso.

Se sei nuovo al monitoraggio dei server (indie hacker, primo VPS):

Inizia con SigNoz. Ti dà metriche, log e tracce in un unico strumento con interfaccia web. Un file Docker Compose, uno strumento da imparare.
Una volta a tuo agio con la lettura delle dashboard, aggiungi Ollama per l'analisi dei log con IA.
Non automatizzare ancora il rimedio. Prima comprendi il comportamento normale del tuo server.

Se usi già Prometheus o Grafana (professionisti DevOps):

Aggiungi Loki per l'aggregazione dei log se non l'hai ancora fatto.
Integra Ollama per il triage dei log assistito dall'IA accanto alle tue regole di alerting esistenti.
Costruisci workflow di self-healing con i webhook di Alertmanager.
Aggiungi Langfuse quando inizi ad affidarti agli output del LLM per le decisioni operative.

Se vuoi lo stack completo dal primo giorno (sviluppatori IA):

Distribuisci un VPS vCS-8 o vCS-16 su Virtua Cloud.
Configura SigNoz per l'osservabilità.
Esegui Ollama con un modello 7B per l'analisi dei log e il rilevamento delle anomalie.
Collega Alertmanager ai tuoi script di rimedio.
Distribuisci Langfuse per monitorare il tuo livello LLM.
Aggiungi la revisione del codice con IA alla tua pipeline CI/CD.

Ogni articolo dedicato in questo cluster tematico è un tutorial indipendente. Puoi seguirli in qualsiasi ordine. Lo stack è modulare: ogni livello funziona in modo indipendente e apporta valore da solo.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.