Qwen3 8B locale per analisi log con Grafana MCP

Un piccolo LLM locale puo supportare l'analisi dei log?

Questo Proof of Concept nasce per verificare se un LLM relativamente piccolo, eseguito completamente in locale, possa diventare uno strumento utile per interrogare log applicativi e velocizzare le prime fasi di troubleshooting.

Il punto non e' sostituire Grafana, Loki o l'operatore tecnico. L'obiettivo e' capire se il linguaggio naturale possa diventare un livello aggiuntivo di accesso ai dati di osservabilita, mantenendo il controllo sulle query e sui dati restituiti.

Domanda del PoC

Un modello locale puo interrogare autonomamente Loki tramite Grafana MCP e restituire informazioni utili per l'analisi di un problema operativo?

Scenario

Il flusso testato mette insieme un modello locale, un server MCP e una sorgente di log remota:

Utente
  |
  v
Qwen3 8B locale
  |
  v
Grafana MCP
  |
  v
Grafana Cloud / Loki

Grafana MCP e' configurato in modalita read-only. In questa fase sono stati utilizzati esclusivamente i tool dedicati a Loki, in modo da limitare il perimetro del test e osservare con maggiore chiarezza il comportamento del modello durante il tool calling.

Perimetro controllato

Il modello non modifica sistemi e non agisce sull'infrastruttura. Interroga strumenti read-only e restituisce un'interpretazione dei risultati.

Modello e ambiente

Il modello utilizzato e' Qwen3 8B in formato GGUF, con quantizzazione Q4_K_M.

Configurazione principale:

Model:        Qwen3 8B Q4_K_M
Context:      32768
Threads:      9
Batch:        1024
Ubatch:       512
Parallel:     1
KV cache K:   Q4
KV cache V:   Q4
Prompt cache: 512 MB
Thinking:     disabled

Il PoC e' stato eseguito sull'hardware disponibile al momento del test:

CPU:           Intel Core i5-9400H @ 2.50 GHz
RAM:           16 GB
GPU dedicata:  nessuna
Esecuzione:    CPU-only

Si tratta volutamente di una configurazione limitata. I valori prestazionali riportati rappresentano quindi una baseline dell'ambiente di test, non un benchmark generale del modello.

Problemi iniziali

Nei primi test il modello disponeva dei tool Loki, ma aveva troppa liberta nel decidere come usarli. Il risultato non era sempre affidabile.

In diverse situazioni il modello poteva:

• inventare valori delle label;
• confondere il nome di una label con il suo valore;
• usare job="..." senza averne verificato il valore reale;
• scegliere un tool statistico quando servivano le righe dei log;
• effettuare chiamate non necessarie;
• costruire LogQL non valida.

Un esempio reale prodotto durante il test:

{container="container"} |~ "0.0.0.0" | stdout | json | count_over_time()

Loki ha correttamente rifiutato la query:

syntax error: unexpected |

Il problema non era solo ottenere una risposta dal modello, ma fare in modo che il modello arrivasse alla risposta attraverso un percorso prevedibile, verificabile e coerente con le regole di Loki.

Limite osservato

Il tool calling non migliora automaticamente l'affidabilita. Se il modello non ha un workflow chiaro, puo costruire query scorrette o usare gli strumenti nel momento sbagliato.

Workflow guidato

Il comportamento e' migliorato introducendo nel prompt un workflow piu deterministico.

Per cercare i log di un'applicazione, il modello deve:

1. recuperare i valori reali della label container, se non sono gia conosciuti;
2. identificare il container richiesto;
3. usare quel valore nella query Loki;
4. specificare sempre un intervallo temporale;
5. limitare normalmente il risultato a poche righe.

Il flusso operativo diventa:

Richiesta utente
      |
      v
Il container e' conosciuto?
      |
      +-- no --> discovery delle label
      |
      v
Valore reale del container
      |
      v
Query Loki limitata
      |
      v
Interpretazione del risultato

Se il container e' gia presente nel contesto, la fase di discovery puo essere evitata.

Risultato

Ridurre lo spazio decisionale del modello ha migliorato sensibilmente l'affidabilita del tool calling. Per un modello piccolo, un workflow ben definito puo essere importante quanto la capacita del modello stesso.

Prestazioni osservate

Una prima richiesta con circa 2.730 token ha prodotto questi valori:

Prompt processing: 2730 token
Processing speed:   11.73 token/s

Generation:         128 token
Generation speed:   3.60 token/s

Tempo totale:       ~4 min 28 sec

Successivamente la conversazione, tra richieste e risultati MCP, e' cresciuta fino a circa 8.781 token.

In questa situazione:

Nuovi token:        689
Processing speed:   4.03 token/s

Generation:         98 token
Generation speed:   2.11 token/s

Nuova inferenza:    ~3 min 37 sec

Il sistema riusciva comunque a riutilizzare gran parte del contesto precedente.

Durante differenti chiamate sono stati osservati valori come:

LCP similarity: 0.921
f_keep:         1.000

e successivamente:

LCP similarity: 0.984
f_keep:         0.988

Quasi tutto il prefisso gia elaborato poteva quindi essere riutilizzato. Questo pero evidenzia un altro aspetto importante: la cache riduce il lavoro ripetuto, ma non elimina il costo dei nuovi dati restituiti dai tool.

Con un contesto piu grande, anche poche centinaia di nuovi token possono diventare costosi su una CPU di questa classe.

Elaborare i dati dove si trovano

Per un utilizzo reale, il modello non dovrebbe ricevere grandi quantita di log grezzi quando l'operazione puo essere svolta direttamente da Loki.

Se l'obiettivo e' sapere quante volte compare un evento, non ha senso trasferire centinaia o migliaia di righe al modello e chiedergli di contarle. Il conteggio puo essere delegato a LogQL:

sum(
  count_over_time(
    {container="container-test"} |~ "FILTRO" [6h]
  )
)

Il modello riceve solo il risultato dell'aggregazione.

Lo stesso principio vale per filtri, finestre temporali e riduzione del dataset:

Loki
 |
 | filtra / aggrega
 v
Risultato ridotto
 |
 v
LLM
 |
 v
Interpretazione operativa

In questo scenario l'LLM non diventa il motore che elabora tutti i dati. Diventa il livello che interpreta la richiesta, usa gli strumenti disponibili e aiuta l'operatore a raggiungere piu velocemente l'informazione utile.

Considerazioni operative

Il test ha dimostrato che un Qwen3 8B quantizzato puo essere eseguito localmente con 16 GB di RAM e senza GPU dedicata, utilizzando Grafana MCP per interrogare Loki.

Il modello e' riuscito a:

• effettuare discovery delle label;
• recuperare righe di log;
• applicare filtri;
• delegare aggregazioni a Loki;
• sintetizzare il risultato in linguaggio naturale.

Sono pero emersi tre elementi determinanti:

• Affidabilita: il tool calling di un modello piccolo richiede istruzioni e workflow precisi.
• Contesto: grandi quantita di dati restituiti dagli strumenti aumentano rapidamente il costo dell'inferenza.
• Hardware: la configurazione CPU-only introduce latenze incompatibili con un utilizzo operativo frequente.

Lettura corretta del risultato

Il limite principale osservato non e' il workflow, ma l'ambiente di esecuzione. Su hardware piu adatto, lo stesso approccio puo diventare molto piu praticabile.

Prossimi passi

Il prossimo passo sara ripetere gli stessi test su hardware piu performante e successivamente estendere il workflow alla correlazione tra log Loki e metriche Prometheus.

L'obiettivo e' valutare se un assistente locale, collegato a strumenti read-only e guidato da workflow controllati, possa ridurre il tempo necessario per:

• cercare informazioni nei log;
• effettuare una prima analisi;
• identificare pattern ricorrenti;
• arrivare piu rapidamente alla causa probabile di un problema.

Con query controllate, gestione attenta del contesto e hardware adeguato, un approccio di questo tipo puo diventare un supporto concreto per troubleshooting, osservabilita e analisi operativa assistita da AI.