Tutorial: llm CLI di Simon Willison per triage log via pipe Unix

MSP & System Integrator

MSP e system integrator che gestiscono flotte Linux e cercano strumenti semplici e componibili per il triage di log e la sintesi di output.

Scopri →

Note preliminari

Contenuto fornito “as-is”. Prima di usare llm in produzione:

• Provate su log di test o in sandbox.
• Non inserite secrets nei prompt. llm spedisce lo stdin al provider configurato.
• Redazione preventiva: log applicativi possono contenere email utenti, IP sorgente, token di sessione, path con nomi cliente. Filtrate prima di pipare.
• Per ambienti con dati regolati usate solo un plugin che punta a modello locale (Ollama, llamafile) — non endpoint cloud.
• llm conserva una cronologia locale in SQLite (~/.config/io.datasette.llm/logs.db su Linux; ~/Library/Application Support/io.datasette.llm/logs.db su macOS): trattatela come materiale sensibile.

Cosa è llm

llm è una CLI Python pubblicata da Simon Willison con v0.1 il 1 aprile 2023 (llm.datasette.io). Il progetto è Apache 2.0, e segue una filosofia da Unix tool: un comando che legge stdin, applica un prompt, scrive su stdout. La parte interessante per chi amministra sistemi è il sistema di plugin: lo stesso llm può parlare con modelli OpenAI, Anthropic, Mistral, Gemini, Ollama locale (via il plugin llm-ollama di Sergey Alexandrov, v0.1.0 del 20 gennaio 2024), llamafile, modelli Hugging Face — a seconda del plugin installato.

Il risultato è un tool componibile con pipe classiche (|, xargs, tee) e con il resto dell’arsenale shell. Nessuna UI, nessun tracking, nessun lock-in di provider.

Caso d’uso: triage rapido di journalctl su un cluster

Scenario: un MSP ha 20 host Linux sotto gestione. Arriva la segnalazione che “alcuni servizi sono instabili”. Vogliamo uno script che per ciascun host raccolga gli ultimi errori di systemd, chieda al modello un riassunto, e salvi un report.

1. Installazione

# Opzione 1 — pipx, in user space:
pipx install llm

# Opzione 2 — virtualenv dedicato:
python3 -m venv ~/.venvs/llm
source ~/.venvs/llm/bin/activate
pip install llm

llm --version

2. Plugin locale (Ollama) per evitare cloud

llm install llm-ollama
# Ollama già in esecuzione:
ollama pull mistral:7b  # o altro modello di taglia adeguata
llm models default "Ollama: mistral:7b"

# Test con prompt banale:
echo "ciao" | llm

Da questo momento, qualsiasi invocazione di llm senza parametri di provider va al modello locale. Nessun traffico esterno.

3. Pipeline di triage per singolo host

Raccogliamo gli ultimi errori systemd, redigiamo hostname ed email, passiamo al modello:

HOST=srv-web-03
ssh "$HOST" "journalctl -p err -S '24 hours ago' --no-pager" \
  | sed -E "s/$HOST/[HOST]/g; s/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/[EMAIL]/g" \
  | llm -s "Analizza questi log systemd. Raggruppa per unit, identifica i top 3 problemi ricorrenti, suggerisci verifiche diagnostiche concrete. Non inventare nulla che non sia nei log." \
  > "reports/$HOST-$(date +%F).md"

Note:

• -s (--system) imposta la system prompt; il corpo dei log passa come user prompt via stdin.
• Il sed redige hostname ed email prima che i dati arrivino al modello. Estendete con altre regex per le vostre convenzioni (es. [CLIENT-xxx]).
• L’output va in reports/, un file per host: versionabile in git privato, diff-abile nel tempo.

4. Batch su più host in parallelo

mkdir -p reports
cat hosts.txt | xargs -P 4 -I {} bash -c '
HOST="$1"
ssh "$HOST" "journalctl -p err -S '\''24 hours ago'\'' --no-pager" \
  | sed -E "s/$HOST/[HOST]/g; s/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/[EMAIL]/g" \
  | llm -s "Analizza questi log systemd..." \
  > "reports/$HOST-$(date +%F).md"
' _ {}

Con -P 4 limitate il parallelismo a 4 SSH contemporanei, evitando di saturare il modello locale. Adattate la concorrenza al carico che Ollama regge sul vostro hardware.

5. Archivio interrogabile

llm logs restituisce tutti i prompt/risposte passati:

llm logs -n 10
llm logs list -q "nginx"   # cerca nella cronologia

La cronologia è in SQLite: per un MSP è un log operatore da backuppare e ruotare come gli altri log. E, come gli altri, contiene contenuti sensibili: la directory ~/.config/io.datasette.llm/ va protetta con permessi restrittivi.

Limiti e avvertenze

• La redazione regex è fragile: un filtro basato su sed non copre ogni forma di PII. Per ambienti con dati personali serviva una redazione strutturata (es. con presidio o equivalenti) prima di passare al modello — e comunque uso locale.
• Il modello locale può essere lento: un 7B su CPU risponde in secondi; su flotta ampia l’effetto collo di bottiglia è reale. Dimensionate con GPU o usate modelli più piccoli per il triage.
• Prompt iniettabili nei log: se un log contiene testo che “sembra” un’istruzione, il modello può interpretarlo. È una forma di prompt injection documentata. Non affidatevi al solo riassunto per decidere azioni critiche.
• Non sostituisce tool di SIEM o osservabilità: llm aiuta a leggere velocemente, non è uno strumento di detection. Integratelo in un processo, non come unico canale di allerta.

Link: llm.datasette.io — github.com/simonw/llm — github.com/taketwo/llm-ollama

Stefano Noferi — Founder e CEO/CTO di noze
Tech Entrepreneur — AI Governance & Security Architect