Come l'Assistente On-Call di Ongrid Indaga sugli Incidenti Direttamente nei Messaggeri

Immagina uno scenario on-call tipico. Alle tre di notte scatta un allarme: i tempi di risposta delle API sono aumentati di cinque volte. Apri il portatile ancora assonnato, sbirci attraverso una dozzina di dashboard in Grafana, poi ti connetti via SSH ai nodi attraverso un bastion host e cerchi freneticamente nei log. Trovare la causa radice richiede mezz'ora, quando il problema era solo un pod andato in crash o una transazione bloccata.

Gli autori del progetto open-source Ongrid hanno deciso di delegare questa routine a una combinazione di agenti AI specializzati e uno stack di observability già pronto.

Cosa può fare il sistema

Ongrid funziona come ingegnere on-call autonomo. Si connette a messaggeri come Telegram o Slack, ascolta gli alert in entrata e inizia immediatamente a indagare.

Il sistema è basato su un'architettura con coordinatore e specialisti ristretti. Quando arriva un alert, l'agente principale crea un worker per l'analisi della causa radice. Questo worker interroga agenti per database, reti o SRE, raccoglie metriche, log e trace, costruisce una mappa delle dipendenze e consegna un report pronto nella chat puntando alla riga di codice specifica o al servizio difettoso.

Sicurezza e controllo degli accessi

Il peggior incubo di ogni sysadmin quando sente "un agente in produzione" è l'allucinazione del modello che esegue un comando pericoloso e manda giù il database. Gli sviluppatori di Ongrid hanno affrontato questo problema in modo pragmatico.

Prima di tutto, le utility dell'host e la sandbox bash funzionano in modalità read-only per impostazione predefinita. L'agente può eseguire comandi diagnostici, controllare lo stato dei processi o ispezionare gli stati dei socket, ma non riavvierà silenziosamente il server.

In secondo luogo, tutte le azioni potenzialmente distruttive sono protette da un apposito gateway di approvazione. Prima di applicare una correzione, il bot richiederà l'approvazione dall'ingegnere on-call nella chat o nell'interfaccia web.

Terzo, gli host non necessitano di alcuna porta in entrata aperta. Un leggero Edge agent viene installato sui server target, che stabilisce una connessione in uscita verso il server Ongrid stesso. L'accesso SSH tramite terminale web funziona su un tunnel inverso, senza inoltrare la porta 22 verso l'esterno e senza armeggiare con le chiavi sui bastion host. Ogni invocazione viene registrata a fini di audit.

Osservabilità, topologia e Kubernetes

All'interno della scatola, è già configurato uno stack pre-impostato di Prometheus, Loki, Tempo e Grafana. La differenza è che l'agente stesso scrive le query su di essi, correlando i timestamp degli eventi con le trace OpenTelemetry.

La gestione dei cluster Kubernetes è stata aggiunta recentemente al progetto. L'agente connette i cluster tramite Edge, traccia gli eventi dei workload, aiuta a gestire gli upgrade e proietta i pod su una mappa topologica condivisa.

La mappa topologica aiuta a valutare il blast radius di un incidente. Se un switch di rete o un database va giù, il sistema visualizza tutti i servizi dipendenti, filtrando i falsi positivi.

Base di conoscenza ed espansione delle competenze

Qualsiasi LLM è inutile senza contesto sulla tua infrastruttura. Ongrid include un vault della conoscenza dove puoi caricare runbook, postmortem passati e repository di codice. La ricerca vettoriale basata su Qdrant trova le istruzioni rilevanti e le fornisce all'agente durante l'analisi degli incidenti.

Se gli strumenti standard non sono sufficienti, puoi aggiungerne altri tramite MCP (Model Context Protocol) o costruire il tuo scenario nell'editor visuale di workflow.

I report generati e le dashboard vengono salvati nel centro degli artifact, dove sono facili da condividere con il team durante i postmortem.

Sotto il cofano e stack dei modelli

Il backend della piattaforma è scritto in Go, e il frontend è costruito con React e TypeScript. La soluzione può essere distribuita interamente sui tuoi server sotto licenza AGPLv3.

Per quanto riguarda i modelli linguistici, il progetto non è legato a un singolo vendor. Puoi usare Claude di Anthropic, OpenAI, DeepSeek, Gemini, o istanze locali, cambiando il routing dei modelli al volo a seconda della complessità del task.

Come distribuire sul tuo server

L'installazione su Ubuntu, Debian o Rocky Linux viene eseguita con uno script già pronto:

# Для архитектуры AMD64
wget https://github.com/ongridio/ongrid/releases/download/v0.12.0/ongrid-v0.12.0-linux-amd64.tar.xz
tar -xf ongrid-v0.12.0-linux-amd64.tar.xz && cd ongrid-v0.12.0-linux-amd64
sudo ./install.sh

Per ARM64, basta sostituire il nome dell'archivio con la release corrispondente. Lo script avvierà il componente server e l'interfaccia web, dopodiché devi solo configurare la connessione al messaggero e installare l'Edge agent sugli host.

Chi dovrebbe provarlo

Ongrid è utile per team operativi piccoli e medi dove non c'è un NOC attivo 24 ore su 24, e gli sviluppatori si alternano nell'on-call. Attenua la prima ondata di panico durante un incidente fornendo immediatamente log e localizzando il problema fino a un riepilogo chiaro.

Il progetto è ancora giovane (circa 700 stelle su GitHub), ma architetturalmente sembra maturo grazie alla sua attenzione alla sicurezza e all'uso di standard di telemetria aperti.