Come integrare Elasticsearch con LLM Ollama

Come integrare Elasticsearch con LLM Ollama

Come integrare Elasticsearch con LLM Ollama

Guida tecnica per sviluppatori e AI Engineer: dall’integrazione base ai workflow agentici autonomi per log analysis, event classification e alert intelligenti.

INDICE DEI CONTENUTI – Come integrare Elasticsearch con LLM Ollama

1. Perché integrare Elasticsearch con un LLM locale
2. Cos’è Ollama e come funziona
3. Setup dell’ambiente: Elasticsearch + Ollama
4. Collegare Ollama a Elasticsearch tramite l’Inference API
5. Costruire un’applicazione RAG con Playground
6. Workflow agentici autonomi: architettura e componenti
7. Analisi dei log in tempo reale con LLM
8. Classificazione degli eventi e generazione di alert intelligenti
9. Azioni automatiche: dalla detection alla remediation
10. Conclusioni e formazione continua

1. Perché integrare Elasticsearch con un LLM locale – Come integrare Elasticsearch con LLM Ollama

Chi lavora ogni giorno con Elasticsearch sa bene che il motore di ricerca e analisi di Elastic è già di per sé uno strumento potentissimo per indicizzare, cercare e aggregare grandi volumi di dati. Ma cosa succede quando vogliamo che quella mole di dati venga non solo trovata, ma compresa, classificata e agita in modo autonomo?

Elasticsearch permette agli utenti di connettersi a LLM tramite la Open Inference API, supportando provider come Amazon Bedrock, Cohere, Google AI, Azure AI Studio, HuggingFace e, appunto, Ollama. L’integrazione con un modello linguistico apre scenari radicalmente nuovi: query in linguaggio naturale, analisi semantica dei log, classificazione automatica degli eventi, generazione di alert contestuali e attivazione di risposte automatiche.

Il vantaggio strategico di usare Ollama rispetto a provider cloud è chiaro: Ollama è uno strumento che permette di scaricare ed eseguire modelli LLM sulla propria infrastruttura, che sia una macchina locale o un server aziendale, senza costi per token e con pieno controllo su risorse e dati sensibili.

Per team che trattano log applicativi, dati di sicurezza o informazioni riservate, questa è una scelta non solo economica ma spesso obbligata da policy di compliance e data governance.

2. Cos’è Ollama e come funziona

Ollama è un framework che permette di scaricare e accedere a modelli localmente tramite una CLI. Con semplici comandi è possibile scaricare, interrogare e avviare un server con il modello che si vuole consumare dalle proprie applicazioni.

Costruito sopra llama.cpp, Ollama offre un ottimo throughput in token al secondo con gestione intelligente della memoria e accelerazione GPU efficiente per NVIDIA (CUDA), Apple Silicon (Metal) e AMD (ROCm).

Un dettaglio fondamentale dal punto di vista architetturale: poiché l’API di Ollama è compatibile con l’API di OpenAI, è possibile integrare facilmente il modello di inferenza e creare applicazioni RAG usando Playground di Elasticsearch. Questo significa che qualsiasi stack che oggi usa OpenAI può migrare su Ollama con modifiche minime al codice.

I modelli supportati includono Llama 3.2, Mistral, Qwen2.5, DeepSeek R1 e decine di altri. Il tool calling è disponibile tramite l’API di Ollama e funziona con modelli specificamente addestrati per il function calling come Mistral, Llama 3.1, Llama 3.2 e Qwen2.5.

3. Setup dell’ambiente: Elasticsearch + Ollama – Come integrare Elasticsearch con LLM Ollama

Il modo più rapido per avere Elasticsearch e Kibana in locale è usare lo script elastic-start-local. Questo avvia entrambi i servizi in Docker con una sola riga di comando.

Per Ollama, l’installazione è disponibile per Linux, macOS e Windows. Dopo l’installazione, si scarica e si avvia il modello scelto:

# Avvia il modello llama3.2
ollama run llama3.2

Una volta in esecuzione, Ollama abilita un endpoint API sulla porta 11434 di default. Per verificare che funzioni:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "What is the capital of France?",
  "stream": false
}'

Se si lavora in un ambiente in cui Elasticsearch è remoto (es. Elastic Cloud) e Ollama gira in locale, è necessario esporre l’endpoint locale tramite un tunnel come ngrok:

ngrok http 11434

Il comando restituisce un link pubblico che funziona finché ngrok e il server Ollama sono in esecuzione localmente. Nella sezione “Forwarding” si trova l’URL generato da ngrok da salvare per i passi successivi.

4. Collegare Ollama a Elasticsearch tramite l’Inference API

Il cuore dell’integrazione è la Elasticsearch Inference API. Essa consente di registrare un endpoint di inferenza che il cluster Elasticsearch utilizzerà per comunicare con il modello LLM.

Esempio di creazione dell’endpoint con chiamata REST:

PUT _inference/completion/ollama_llama3
{
  "service": "openai",
  "service_settings": {
    "api_key": "ignored",
    "url": "https://your-ngrok-endpoint.ngrok-free.app/v1",
    "model_id": "llama3.2"
  }
}

Poiché Ollama espone un’API compatibile OpenAI, si usa il service type openai puntando all’URL di Ollama (locale o tunnelizzato). Il campo api_key è richiesto sintatticamente ma non verificato da Ollama.

Per il campo di embedding semantico, si può affiancare ELSER (Elastic Learned Sparse EncodeR), il modello di embedding nativo di Elastic, per indicizzare documenti con rappresentazioni vettoriali dense. Il mapping dell’indice diventa:

PUT /logs_index
{
  "mappings": {
    "properties": {
      "message": { "type": "text" },
      "semantic_field": {
        "type": "semantic_text",
        "inference_id": "elser_embeddings"
      }
    }
  }
}

5. Costruire un’applicazione RAG con Playground

In questo modo si può creare un’applicazione RAG con una chat che usa un LLM in esecuzione sulla propria infrastruttura a costo zero, mantenendo il controllo su risorse e informazioni sensibili e accedendo a una varietà di modelli per diversi task.

Da Kibana, navigare in Playground e collegare il connettore LLM creato. Selezionare gli indici Elasticsearch da usare come base documentale. A questo punto il sistema esegue automaticamente:

1. Embedding della query utente
2. Ricerca ibrida (keyword + vettoriale) sull’indice
3. Costruzione del contesto per il prompt
4. Invio al modello Ollama con la risposta finale

Un caso d’uso concreto: una knowledge base di runbook operativi indicizzata in Elasticsearch. L’operatore chiede in linguaggio naturale “Come risolvo l’errore 503 sul servizio pagamenti?” e il sistema recupera automaticamente il documento pertinente e genera una risposta contestuale.

6. Workflow agentici autonomi: architettura e componenti

Siamo al cuore della guida. L’architettura di un agente oggi richiede di collegare più pezzi disparati: un LLM, un vector database, un metadata store, sistemi separati per logging e tracing, e un modo per valutare se tutto funziona. Questo non è solo complesso, è costoso e soggetto a errori.

Elastic risponde con Agent Builder ed Elastic Workflows. Questa nuova struttura fornisce un framework con tutti i building block essenziali per creare AI Agent basati su Elasticsearch: un insieme aperto di primitive, protocolli standard e accesso sicuro ai dati.

Gli agenti sono ottimali per il ragionamento, l’esplorazione e il giudizio, specialmente quando l’informazione è incompleta o in evoluzione. I workflow sono ottimali per eseguire procedure consolidate che coinvolgono più step, sistemi esterni e azioni che cambiano lo stato.

Un workflow agentico è definito in YAML e si integra nativamente con Agent Builder:

trigger:
  type: index_pattern
  index: "logs-*"
  schedule: "*/1 * * * *"

steps:
  - name: fetch_recent_errors
    type: elasticsearch.search
    body:
      query:
        bool:
          filter:
            - term: { level: "ERROR" }
            - range:
                "@timestamp":
                  gte: "now-1m"

  - name: analyze_with_llm
    type: ai.agent
    agent_id: "log_classifier_agent"
    input: "{{ steps.fetch_recent_errors.hits }}"

  - name: trigger_alert
    type: connector.webhook
    condition: "{{ steps.analyze_with_llm.severity == 'CRITICAL' }}"
    url: "https://alerting-system/api/alert"

7. Analisi dei log in tempo reale con LLM

L’AI Assistant di Elastic per Observability e Search aiuta a: decodificare messaggi di errore interpretando stack trace e log di errore per individuare le cause radice, identificare bottleneck di performance, generare report con sommari di alert e timeline degli incidenti.

In pratica, i log vengono indicizzati in Elasticsearch (tipicamente tramite Elastic Agent o Logstash/Filebeat) in indici della forma logs-*. Un agente configurato con Ollama interroga periodicamente questi indici usando query ES|QL:

FROM logs-*
| WHERE @timestamp > NOW() - 5 MINUTES
| WHERE log.level == "ERROR"
| STATS count = COUNT(*) BY service.name, error.message
| SORT count DESC
| LIMIT 20

Il risultato viene passato all’LLM con un prompt di sistema che contestualizza l’analisi:

system_prompt = """
Sei un esperto di operations e SRE. Analizza i seguenti log di errore
e classifica la severità (INFO/WARNING/CRITICAL), identifica pattern
ricorrenti e suggerisci le cause probabili.
Rispondi in JSON con i campi: severity, pattern, root_cause, action.
"""

8. Classificazione degli eventi e generazione di alert intelligenti

Il workflow viene triggerato automaticamente e cicla su ogni entità coinvolta. Invoca un agente di triage che non si limita a copiare i dati, ma ragiona sulla catena di attacco, la confronta con il framework MITRE ATT&CK, correla i log correlati e genera un sommario di investigazione leggibile da un analista Tier 2.

Per la classificazione degli eventi di log, si addestra l’LLM tramite few-shot prompting:

few_shot_examples = """
Evento: "Connection refused to DB on port 5432 after 3 retries"
Classificazione: {"category": "database", "severity": "CRITICAL", "action": "escalate"}

Evento: "User login failed: invalid credentials"
Classificazione: {"category": "security", "severity": "WARNING", "action": "monitor"}

Evento: "Cache miss ratio exceeded 80% threshold"
Classificazione: {"category": "performance", "severity": "WARNING", "action": "investigate"}
"""

Il workflow agente di Attack Discovery, dato l’insieme di alert Elastic Security in un determinato intervallo di tempo, trova automaticamente se si sono verificati attacchi, quali host o utenti sono stati compromessi e quali alert hanno contribuito alla conclusione.

9. Azioni automatiche: dalla detection alla remediation

Il Model Context Protocol (MCP) è lo standard che consente all’agente di connettersi a sistemi esterni in modo sicuro. Invece di dare all’agente accesso raw alla shell, gli si fornisce un “Tool” chiamato cleanup_disk, che ha un comando specifico associato nel sistema esterno.

L’architettura completa di un sistema self-healing segue il ciclo: Sense → Think → Act → Verify:

Sense: Elastic Agent raccoglie telemetria (log, metriche, trace) in tempo reale.

Think: L’agente Ollama analizza i dati, correla gli eventi e determina la severità.

Act: Quando è il momento di contenere una minaccia, la velocità è critica ma lo è anche la sicurezza: non si vuole che un LLM “allucinasse” una chiamata API a un firewall. L’agente identifica l’host dall’investigazione, crea un piano per invocare il workflow di isolamento, lo presenta all’operatore per conferma e poi il workflow deterministico esegue il comando esatto.

Verify: Elastic misura il risultato tramite SLO e metriche di performance.

Esempio di tool definition per un’azione automatica via Python:

import requests

def trigger_remediation_workflow(host_id: str, action: str):
    payload = {
        "workflow_id": "host_remediation_v2",
        "parameters": {
            "host": host_id,
            "action": action,
            "triggered_by": "ollama_agent",
            "timestamp": "now"
        }
    }
    response = requests.post(
        "https://kibana-instance:5601/api/workflows/execute",
        json=payload,
        headers={"kbn-xsrf": "true"}
    )
    return response.json()

10. Conclusioni e formazione continua

L’integrazione tra Elasticsearch e Ollama non è solo un esercizio tecnico: è una risposta concreta all’esigenza di costruire sistemi osservabili, intelligenti e capaci di agire in autonomia su scale operative che l’intervento umano diretto non può più reggere. Log analizzati in millisecondi, eventi classificati semanticamente, alert che raccontano una storia invece di un codice di errore, azioni di remediation eseguite in sicurezza: tutto questo è possibile oggi, con strumenti open source, on-premise, senza dipendenze da API cloud esterne.

Ma c’è una verità scomoda che ogni CTO e responsabile IT deve tenere a mente: il mondo dell’intelligenza artificiale e le tecnologie moderne si muovono a una velocità spaventosa. Ciò che oggi è “tech preview” domani è GA. Ciò che oggi è un vantaggio competitivo domani è uno standard di mercato. Le architetture agentiche, i modelli locali, i protocolli MCP, i framework come LangGraph e LlamaIndex evolvono ogni settimana. Non tenere il passo significa accumulare debito tecnologico che diventa sempre più costoso da colmare.

La formazione continua del team IT è l’unica soluzione per restare al passo.

Per questo motivo, se stai cercando percorsi formativi strutturati e aggiornati per il tuo team, Innovaformazione offre corsi professionali attivati su richiesta, con calendario da concordare e modalità online in classe virtuale, pensati per sviluppatori, AI engineer e professionisti IT.

Puoi esplorare il catalogo completo dei Corsi di AI Generativa — che include percorsi su LLM, RAG, agenti AI, prompt engineering e molto altro al link QUI .

Per chi lavora con lo stack Elastic, è disponibile anche il corso Elasticsearch – ELK Stack

È inoltre possibile accedere ai fondi Fondimpresa per la formazione gratuita dei dipendenti, abbattendo completamente i costi formativi per le aziende aderenti.

📩 Per informazioni e preventivi:

• info@innovaformazione.net
• 📞 TEL 347 101 2275 — Dario Carrassi

Per altri articoli tecnici consigliamo di navigare sul nostro blog QUI.

(fonte) (fonte) (fonte)