Ongrid è un progetto open source pensato per un problema molto concreto delle piccole e medie imprese digitali, delle agenzie web e dei piccoli team SaaS: il numero di servizi da tenere in piedi cresce, mentre il tempo per guardarli resta lo stesso. Quando un sito cliente rallenta alle 23:00 o un container va in crash-loop dopo un deploy, servono ore per correlare dashboard, log e avvisi sparsi.
Cos'è Ongrid in una frase
Ongrid è una piattaforma di AIOps self-hosted con un agente SRE integrato che correla metriche, log, trace e topologia dell'infrastruttura, avvia auto-indagini sugli alert, formula ipotesi di causa radice fino al livello del codice e opera tramite ChatOps ed esecuzione remota tracciata.
Il repository di riferimento è ongridio/ongrid, distribuito secondo quanto riportato dalle API GitHub con licenza AGPL-3.0, da verificare sul file LICENSE prima di qualsiasi uso produttivo. Il progetto si presenta come sistema operativo per le operations assistite da intelligenza artificiale, non come semplice dashboard di monitoraggio: l'osservabilità è il punto di partenza, l'indagine guidata dall'agente è la funzione caratterizzante.
Per il pubblico italiano è utile inquadrarlo così: non sostituisce gli strumenti che già mostrano grafici e avvisi, ma aggiunge uno strato che li legge insieme, li collega all'inventario dei servizi e propone un percorso di diagnosi in linguaggio naturale, consultabile da Slack, Telegram o Lark.
A cosa serve: dai monitoraggi sparsi all'indagine guidata
Il caso d'uso primario è la gestione di infrastrutture medio-piccole ma composite: qualche decina di servizi tra siti WordPress e Next.js, API in Python o Node.js, database PostgreSQL, code di lavoro, reverse proxy, istanze cloud e cluster Kubernetes per i casi più strutturati. È il profilo tipico di un'agenzia che gestisce i progetti dei clienti, di un'e-commerce in crescita o di una PMI che ha internalizzato uno o due sviluppatori e un sistemista part-time.
In questo contesto Ongrid serve a tre scopi pratici. Il primo è ridurre il tempo di triage: invece di aprire separatamente Grafana per le metriche, Loki per i log e Tempo per le trace, l'agente li interroga in modo correlato a partire da un alert e restituisce una timeline unica con servizi coinvolti, deploy recenti ed errori concomitanti.
Il secondo è standardizzare la reperibilità. La ChatOps consente di ricevere l'avviso, chiedere un approfondimento in chat e autorizzare verifiche di sola lettura senza dover aprire VPN, SSH e cinque pannelli diversi dal portatile. Per un founder non tecnico significa poter seguire un incidente con un linguaggio comprensibile, per un tecnico significa avere comandi e contesto già pronti.
Il terzo è la gestione del ciclo di vita su Kubernetes per chi lo usa: deploy, rollout, scaling e verifiche di base assistite, sempre con tracciamento delle azioni. Non si tratta di hosting automatico, ma di operazioni ripetitive rese conversazionali e registrate.
Va chiarito cosa Ongrid non è: non è un sistema di fatturazione, non è un CRM, non è una piattaforma di knowledge management e non è un sostituto del backup, del WAF o delle policy di sicurezza. Resta uno strumento operations-centrico, utile se esiste già una base di osservabilità da valorizzare.
Come funziona: architettura, integrazioni e flusso di lavoro
L'architettura dichiarata dagli autori combina componenti Go e TypeScript e si appoggia allo stack di osservabilità più diffuso in ambito cloud-native: Prometheus per le metriche, Loki per i log, Tempo per le trace distribuite e Grafana per la visualizzazione. Questa scelta è rilevante perché evita formati proprietari: chi ha già questi strumenti può collegarli, chi non li ha deve prima metterli in piedi, con i relativi costi operativi.
Il flusso tipico può essere descritto in cinque fasi. Nella prima, Ongrid ingerisce o interroga i segnali e costruisce una mappa della topologia: quali servizi parlano con quali, dove girano, quali versioni sono in deploy. Nella seconda, un alert fa scattare un'indagine automatica, definita auto-investigate: l'agente raccoglie metriche anomale, log di errore e trace lente nella finestra temporale dell'incidente.
Nella terza fase avviene la correlazione: picchi di latenza, saturazione CPU o memoria, errori 5xx, restart dei pod e deploy recenti vengono allineati temporalmente per distinguere sintomi e possibili cause. Nella quarta, il sistema propone una root cause analysis fino al livello di riga di codice quando sono disponibili i riferimenti tra trace, repository e versione rilasciata, indicando file, commit o query sospette.
Nella quinta fase entra in gioco l'operatore umano via ChatOps o interfaccia web: può chiedere chiarimenti, avviare controlli aggiuntivi in sola lettura o autorizzare azioni di remediation circoscritte su host remoti. Un elemento distintivo citato nella documentazione è l'accesso remoto tramite tunnel inverso con approccio simile a browser-SSH, pensato per raggiungere ambienti dietro NAT senza esporre porte, con sessioni registrate per audit.
Sul fronte dell'intelligenza artificiale Ongrid adotta il modello bring your own model: non include un modello proprietario, ma consente di collegare fornitori esterni tra cui Anthropic, OpenAI, DeepSeek, Gemini e Kimi. Questo implica traffico di metadati e log verso API esterne a consumo, con costi a token e valutazioni privacy da fare caso per caso, soprattutto se nei log transitano dati personali o credenziali. Per installazioni di test gli autori forniscono script di installazione da usare su macchine usa-e-getta, mai direttamente in produzione senza isolamento e credenziali dedicate.
Perché conta per founder, PMI e agenzie italiane
Per una PMI italiana il vero costo degli incidenti non è solo il fermo, ma la dispersione: il fornitore esterno che chiede i log, lo sviluppatore che non ha accesso al cluster, il titolare che vuole sapere quando il gestionale torna online. Un sistema che produce un resoconto unico, con causa probabile e azioni suggerite, riduce riunioni, telefonate e tempi di ripristino.
Il secondo motivo è la reperibilità sostenibile. Molte agenzie garantiscono ai clienti tempi di intervento senza avere un team di guardia h24. L'auto-indagine non risolve da sola, ma prepara il terreno: al risveglio il tecnico trova timeline, grafici rilevanti e prime ipotesi invece di una casella di avvisi grezzi. Per incidenti semplici come saturazione disco, certificato scaduto o deploy difettoso con rollback chiaro, il guadagno è immediato.
Il terzo motivo è la tracciabilità, sempre più richiesta da clienti enterprise, bandi e normative. Avere esecuzione remota registrata, comandi auditati e report di indagine conservabili aiuta a dimostrare diligenza operativa, utile anche in percorsi verso ISO 27001, NIS2 o DORA dove la gestione degli incidenti deve essere documentata. Ongrid non certifica da solo, ma fornisce materiale probatorio ordinato.
Il quarto motivo è didattico: per piccoli team che stanno passando da un hosting tradizionale a container e microservizi, osservare come l'agente correla segnali è un modo per apprendere pratiche SRE senza assumere subito una figura dedicata. Resta però uno strumento per tecnici: richiede comprensione di metriche, log, rete e Kubernetes per essere valutato criticamente ed evitare di accettare diagnosi errate.
Limiti, licenza, costi e dove trovarlo
Il primo limite è la maturità. I riferimenti a versioni 0.x indicano un progetto giovane e in rapida evoluzione, dove API, installazione e qualità della diagnosi possono cambiare. Prima di affidargli ambienti critici servono prove su sistemi di test con alert sintetici, misura dei falsi positivi e verifica che la causa proposta sia davvero azionabile e non generica.
Il secondo limite è operativo: per funzionare bene richiede Prometheus, Loki, Tempo e Grafana configurati correttamente, più un cluster o un parco server ben strumentato. Se l'osservabilità di base è assente o rumorosa, l'agente erediterà rumore e lacune. L'adozione va quindi preventivata come progetto, non come installazione in un pomeriggio.
Il terzo nodo è licenza e modello economico. La licenza indicata AGPL-3.0 è copyleft forte: consente self-hosting ma impone obblighi significativi in caso di modifica e messa a disposizione via rete, da valutare con un legale soprattutto per agenzie che vorrebbero rivenderlo come servizio. A questo si aggiungono i costi dei modelli linguistici esterni, che vanno contingentati con budget e limiti di spesa per evitare sorprese in caso di tempeste di alert.
Il quarto nodo è sicurezza e privacy. Dare a un agente accesso a log, metriche ed esecuzione remota significa ampliare la superficie di attacco. Buone pratiche minime includono istanza dedicata, segreti separati, permessi in sola lettura come default, approvazione umana per ogni azione in scrittura, retention breve dei log con dati sensibili e informativa sul trasferimento verso provider di modelli extra-UE.
Il codice e la documentazione sono consultabili pubblicamente all'indirizzo https://github.com/ongridio/ongrid, dove verificare README, esempi di configurazione, connettori ChatOps supportati e stato delle release. Il consiglio operativo per una PMI è procedere per gradi: laboratorio isolato, collegamento a un Prometheus di test, bot di chat dedicato, una sola applicazione non critica e checklist di valutazione di un mese prima di decidere se estendere, mantenere solo l'osservabilità classica o abbandonare.