Per il nostro piccolo team di Incidente Support (solo 6 specialisti), due metriche sono assolutamente cruciali: e . speed of detection accuracy of diagnosis Riceviamo casi da milioni di utenti in tutto il mondo Quando arriva un caso utente, uno degli strumenti chiave su cui ci affidiamo – insieme ad altri – è . 48 countries Kibana A causa della natura multifattoriale del nostro sistema (microservizi, specifiche normative locali, esperimenti A/B e altro ancora), spesso finiamo per cercare un analizzando gli eventi relativi all'utente nei log. Acciaio in un haystack Anche per uno specialista esperto, questo richiede tempo per: 
 
 
 
 comprendere ciò che è realmente accaduto, separare il rumore dai problemi reali, collegare eventi tecnici con l'esperienza utente reale. In media, questo tipo di analisi , e in situazioni ambigue, può richiedere molto più tempo. at least 15 minutes per case Volevo che i log leggessero come un Non come un evento crudo. story E sì – questo è Ma piuttosto a . not a replacement for an engineer Acceleratore di pensiero L’idea Abbiamo costruito un’automazione in Combina diversi strumenti: n8n 
 
 
 
 Slack Kibana (via Clairvoyance) Il LLM (Large Language Model) E lo ha trasformato in un flusso di lavoro semplice e pratico per gli specialisti di supporto. Come funziona 
 
 
 
 
 
 
 
 
 
 È stato creato un canale Slack dedicato. Un specialista invia un UID utente nel canale - solo un numero. L'automazione cattura l'UID e invia una richiesta a Clairvoyance Kibana utilizzando filtri predefiniti. Tutti i log di attività degli utenti per le ultime 6 ore vengono recuperati. Se non vengono trovati log, un chiaro messaggio "nessuna attività trovata" viene pubblicato nel thread Slack. If logs exist, they are processed:
 
 
 
 
 
 
 empty entries are removed, duplicates are eliminated, data is structured and normalized, everything is bundled into a single dataset. Il pacchetto di log completo viene inviato a un LLM insieme a un prompt personalizzato su misura per le esigenze del nostro team. Il LLM analizza gli eventi e restituisce un riassunto leggibile dall'uomo (fino a 600 caratteri). La risposta viene ripubblicata nel thread Slack originale circa 2 minuti dopo la richiesta. Lo sviluppo iniziale di questo impianto si è , una grande parte dei quali è andata a configurare correttamente le credenziali (specialmente per Slack - lo coprirò più tardi). 30 hours Ci aspettiamo che con l'uso attivo, questa automazione salverà il team . up to 60 hours per month Che cosa risponde veramente il LLM? La risposta è sempre strutturata e risponde a domande molto specifiche: 
 
 
 
 
 
 Quali errori sono stati rilevati? Una sintesi di eventi positivi (normali) Come gli errori potrebbero avere influenzato il flusso di lavoro dell'utente Quando esattamente i problemi si sono verificati (timestamps) Quali azioni deve intraprendere lo specialista Di conseguenza, non vediamo solo Ma il reale : Cosa stava facendo l’utente, dove ha incontrato un problema e quanto fosse critico. HTTP 400 su Endpoint X context E sì – . no sensitive data is ever sent to the LLM Gli obiettivi fondamentali dell’automazione L’umanizzazione della lettura log Kibana è uno strumento potente, ma la lettura dei log con gli occhi è faticosa e cognitivamente costosa, specialmente quando gli eventi si diffondono nel tempo e in più servizi. Volevo che il risultato sembrasse un Non è un dump tecnico. clear explanation Ridurre il tempo di analisi Before automation: 
 
 15+ minuti per caso utente After automation: 
 
 1-2 minuti (invia UID → ottieni il riassunto) Questo è particolarmente importante durante i carichi di picco o gli incidenti di massa. Permette un'analisi più approfondita L’automazione non risparmia solo tempo, ci consente di: 
 
 
 
 
 rilevare più velocemente i problemi sistemici, identificare i modelli di errore ricorrenti tra gli utenti, migliorare le competenze degli specialisti evidenziando nuove aree problematiche, capire meglio come si comporta l'applicazione nell'uso reale. In definitiva, questo approccio riduce significativamente il tempo impiegato dagli sviluppatori per indagare su problemi descritti solo attraverso l'esperienza dell'utente. Per chi è questo strumento? In primo luogo: 
 
 
 
 il supporto degli specialisti, ingegneri che lavorano con incidenti di fronte agli utenti, Le squadre che hanno bisogno di capire rapidamente “cosa è andato storto” senza immergersi immediatamente in Kibana. Questa è la versione finale? No. Questo è un Attualmente in a , con un completo roll-out pianificato in anticipo . living tool Fase di prova silenziosa 2026 Durante il test: 
 
 
 
 La velocità è raffinata, differenti LLM e versioni di modello sono confrontati, La logica di filtrazione e i template di risposta sono migliorati. Anche adesso, l’automazione soddisfa già il suo obiettivo principale: . making logs understandable and saving time Struttura del pipeline Trigger Il pipeline inizia da un evento in un canale Slack dedicato ( ) di : Slack Trigger 
 
 
 Tipo di evento: nuovo messaggio pubblicato in canale Input: un UID utente inviato come testo semplice Preparazione dei dati I dati del messaggio vengono estratti e trasformati utilizzando Il formato JSON richiesto: Set nodes 
 
 
 Ramo superiore: UID (come un numero) Ramo inferiore: contesto del thread (ID del canale e timestamp del thread) Log Retrieval L'UID è passata a Kibana ( ) utilizzando il Indice di chiarezza. Elasticsearch / Get Many traces-main I log sono ricercati da In una finestra temporale definita. user_id Logica condizionale di verifica se sono stati trovati eventi: IF node 
 
 
 
 
 No events: 
 
 
 Data is merged with the thread context A predefined “NO EVENTS” message is posted to Slack 
 
 Events found: 
 
 
 Logs are aggregated, minimized, and normalized Data is sent to the LLM for analysis Rispondere alla consegna L'output LLM è fuso con il contesto del thread Slack e pubblicato come risposta nel thread originale. Dettagli Node Slack Trigger Richiede credenziali Slack preconfigurati e l'ID del canale (disponibile tramite di Slack) Dettagli canali aperti Impostare i nodi Utilizzato per estrarre e normalizzare i dati di input: 
 
 
 uid → parsato dal testo del messaggio come numero thread data:
 
 
 
 
 channel  → original message timestamp thread_ts Elasticsearch Node Richiede le credenziali Kibana e l'ID dell'indice (trovato in e) il Indice di gestione Impostazioni chiave : 
 
 
 Limite: 1000 elementi (valori più alti spesso causano tempi di uscita del gateway.) Query:
 
 
 
 
 
 
 time range:  now-6h filter by  user_id limited source fields last 1000 events Codice nodo (minimizzatore) Prepara i log per l'analisi LLM: 
 
 
 
 
 
 
 
 
 normalizza i campi (tempo, contenuto), maschera potenziali PII (telefone/e-mail – anche se non presenti, come protezione aggiuntiva), per i valori lunghi, rimuovere i campi vuoti, diversi tipi di eventi nel tempo, ripetere eventi simili, computa le statistiche di leggerezza (codici HTTP, endpoint), costruisce un prompt compatto con i primi 500 eventi aggregati e un limite di lunghezza rigoroso. Questo è fondamentale per evitare di inviare grandi carichi di guadagno costosi al LLM. Il nodo OpenAI (Message a Model) Richiede credenziali OpenAI e selezione del modello (attualmente durante il test). GPT-4.1-Mini Il progetto è progettato dalla prospettiva di un : second-line technical support specialist 
 
 
 
 
 
 
 prima classificare l’utente (autista / passeggero / corriere), - rispondere agli errori tecnici, se non esistono errori, analizzare lo stato aziendale (documenti, divieti, stato del profilo), seguire un modello di risposta rigoroso con limiti di carattere, congiunzione conclusioni a punti finali concreti e timestamp, analisi tecnica separata dall'impatto del flusso di lavoro rivolto all'utente. Questa struttura trasforma i log raw in . clear, actionable insights Esempio di output disponibile qui sotto: I pensieri finali Questa automazione non sostituisce gli ingegneri, ma li aiuta a pensare più velocemente.Convertendo i log crudi in narrazioni brevi e strutturate, il team riduce il carico cognitivo e accelera l'analisi degli incidenti senza perdere il contesto. Con strumenti come n8n e LLM moderni, anche piccoli team possono costruire strati di osservabilità pratici e amichevoli per gli esseri umani.

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

Questo audio è prodotto nella lingua originale della storia!

Come costruire un n8n Automation per leggere i log Kibana e analizzarli con un LLM

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

The Ultimate FAQ Guide to HackerNoon's Business Blogging

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

OpenAI Has Everything Under Control 😎

HackerNoon - A User Experience Analysis: Part 2

The Ultimate FAQ Guide to HackerNoon's Business Blogging

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

OpenAI Has Everything Under Control 😎

HackerNoon - A User Experience Analysis: Part 2

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps