Voor ons kleine Incident Support team (slechts 6 specialisten) zijn twee metricen absoluut cruciaal: en . speed of detection accuracy of diagnosis We ontvangen gevallen van miljoenen gebruikers over de hele wereld Wanneer er een gebruikerscase komt, is een van de kerntools waarop we vertrouwen – naast andere – . 48 countries Kibana Vanwege de multifactorale aard van ons systeem (microservices, lokale regelgevende specificaties, A/B-experimenten en meer), zoeken we vaak naar een door gebruikersgerelateerde gebeurtenissen in logs te analyseren. Naald in een haystack Zelfs voor een ervaren specialist kost dit tijd om: 
 
 
 
 begrijpen wat er daadwerkelijk is gebeurd, afzonderlijk geluid van echte problemen, verbinden van technische gebeurtenissen met de echte gebruikerservaring. Gemiddeld wordt dit soort analyse En in dubbelzinnige situaties kan het veel langer duren. at least 15 minutes per case Ik wilde logs lezen als een Niet als een raw event dump. story En ja - dit is Maar liever een . not a replacement for an engineer Denken accelerator Het idee Ik bouwde een automatisering in Dit combineert verschillende tools: n8n 
 
 
 
 Slack Kibana (via Clairvoyance) Een LLM (Large Language Model) En veranderde het in een eenvoudige, praktische workflow voor ondersteunende specialisten. Hoe het werkt 
 
 
 
 
 
 
 
 
 
 Er wordt een speciaal Slack kanaal gemaakt. Een specialist stuurt een gebruikers-UID naar het kanaal – alleen een nummer. De automatisering vangt de UID en stuurt een verzoek naar Clairvoyance Kibana met behulp van vooraf gedefinieerde filters. Alle gebruikersactiviteitslogboeken van de afgelopen 6 uur worden gehaald. Als er geen logs worden gevonden, wordt een duidelijk "geen activiteit gevonden" bericht geplaatst in de Slack thread. 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. Het volledige logpakket wordt naar een LLM verzonden, samen met een aangepaste prompt die is afgestemd op de behoeften van ons team. De LLM analyseert de gebeurtenissen en geeft een menselijk leesbare samenvatting (tot 600 tekens). Het antwoord wordt ongeveer 2 minuten na het verzoek teruggestuurd naar de oorspronkelijke Slack-trade. De oorspronkelijke ontwikkeling van deze pijpleiding werd , waarvan een groot deel ging in de juiste configuratie van credentials (vooral voor Slack - ik zal dat later bespreken). 30 hours We verwachten dat deze automatisering bij actief gebruik het team zal redden. . up to 60 hours per month Wat beantwoordt de LLM eigenlijk? Het antwoord is altijd gestructureerd en beantwoordt zeer specifieke vragen: 
 
 
 
 
 
 Welke fouten zijn ontdekt? Een samenvatting van positieve (normale) gebeurtenissen Hoe de fouten de werkstroom van de gebruiker kunnen hebben beïnvloed Wanneer precies de problemen plaatsvonden (timestamps) Welke acties moet de specialist volgen Hierdoor zien we niet alleen Maar echt : Wat de gebruiker deed, waar ze een probleem tegenkwamen en hoe kritisch het was. HTTP 400 op Endpoint X context En ja – . no sensitive data is ever sent to the LLM Kerndoelstellingen van de automatisering Humaniseer log lezen Kibana is een krachtig hulpmiddel, maar het lezen van logs met je ogen is vermoeiend en cognitief duur - vooral wanneer gebeurtenissen zich over de tijd en over meerdere diensten verspreiden. Ik wilde dat de output eruit zag als een Niet een technische dump. clear explanation Verminderde analyse tijd Before automation: 
 
 15+ minuten per gebruiker After automation: 
 
 1-2 minuten (zend UID → verkrijg samenvatting) Dit is vooral belangrijk tijdens piekbelasting of massale incidenten. Het mogelijk maken van een diepere analyse Automatisering bespaart niet alleen tijd – het stelt ons in staat om: 
 
 
 
 
 Systeemproblemen sneller opsporen het identificeren van terugkerende foutenpatronen tussen gebruikers, de vaardigheden van specialisten verbeteren door nieuwe probleemgebieden te benadrukken; beter begrijpen hoe de applicatie zich gedraagt in real-world gebruik. Uiteindelijk vermindert deze aanpak aanzienlijk de tijd die ontwikkelaars besteden aan het onderzoeken van problemen die alleen worden beschreven via gebruikerservaring. Voor wie is dit gereedschap? In de eerste plaats: 
 
 
 
 ondersteuning van specialisten, Ingenieurs die werken met gebruikersfacing incidenten, teams die snel moeten begrijpen “wat fout ging” zonder onmiddellijk in Kibana te duiken. Is dit de definitieve versie? Nee, dit is een Momenteel in een , met een volledige roll-out gepland voor vroeg . living tool Stille testfase 2026 Tijdens de test: 
 
 
 
 De snelheden zijn verfijnd, verschillende LLM's en modelversies worden vergeleken, Filtering logica en respons templates worden verbeterd. Zelfs nu voldoet de automatisering al aan zijn hoofddoel: . making logs understandable and saving time Pipeline structuur Trigger De pipeline begint vanaf een evenement in een toegewijd Slack-kanaal ( ) van : Slack Trigger 
 
 
 Event type: nieuw bericht geplaatst in kanaal Input: een gebruiker UID verzonden als eenvoudige tekst Data voorbereiding De berichtgegevens worden geëxtraheerd en omgezet met behulp van In het vereiste JSON-formaat: Set nodes 
 
 
 Hoogste tak: UID (als een getal) Lower branch: thread context (kanalen-ID en thread timestamp) Log Retrieval Het UID wordt doorgegeven aan Kibana ( ) het gebruik van de Indicator in de helderheid. Elasticsearch / Get Many traces-main Logs worden gezocht door binnen een bepaald tijdvenster. user_id Voorwaardelijke logica een controleert of er gebeurtenissen zijn gevonden: 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 Reactie Levering De LLM output wordt samengevoegd met de Slack thread context en geplaatst als een reactie in de oorspronkelijke thread. Node details De Slack Trigger vereist vooraf geconfigureerde Slack-credentials en de kanaal-ID (beschikbaar via In de Slack). Open kanaal details Set knooppunten Gebruikt om invoergegevens te extraheren en te normaliseren: 
 
 
 uid → geselecteerd uit berichttekst als een getal thread data:
 
 
 
 
 channel  → original message timestamp thread_ts Elasticsearch knooppunt Kibana credentials en de index-ID (gevonden in ) van Indexbeheer Belangrijke instellingen : 
 
 
 limiet: 1000 items(Hogere waarden veroorzaakten vaak gateway timeouts.) Query:
 
 
 
 
 
 
 time range:  now-6h filter by  user_id limited source fields last 1000 events De Code Node (Minimizer) Voorbereidt logs voor LLM analyse: 
 
 
 
 
 
 
 
 
 normaliseren van velden (tijd, inhoud), maskeert potentiële PII’s (telefoon/e-mail – zelfs als ze niet aanwezig zijn, als extra bescherming), langdurige waarden op te lossen, Verwijder lege velden, Soorten gebeurtenissen per tijd, vermenigvuldigen van soortgelijke gebeurtenissen, berekent lichtgewicht statistieken (HTTP-codes, eindpunten), bouwt een compacte prompt met de top 500 geaggregeerde gebeurtenissen en een strikte lengte limiet. Dit is van cruciaal belang om te voorkomen dat grote, token dure payloads naar de LLM worden verzonden. OpenAI Node (Bericht een model) vereist OpenAI-credentials en modelkeuze (momenteel tijdens het testen). GPT-4.1-Mini Het project is ontworpen vanuit het perspectief van een : second-line technical support specialist 
 
 
 
 
 
 
 eerst de gebruiker classificeren (chauffeur / passagier / koerier), de aandacht voor technische fouten, als er geen fouten zijn, analyseer de bedrijfsstatus (documenten, verboden, profielstatus), volgt een strikte respons sjabloon met karakterlimieten, conclusies te koppelen aan concrete eindpunten en timestamps, afzonderlijke technische analyse van de impact van gebruikersgerichte workflows. Deze structuur verandert rauwe logs in . clear, actionable insights Voorbeeld output hieronder beschikbaar: Laatste gedachten Door ruwe logs om te zetten in korte, gestructureerde verhalen, vermindert het team de cognitieve belasting en versnelt het incidentenanalyse zonder context te verliezen. Met tools zoals n8n en moderne LLM's kunnen zelfs kleine teams praktische, mensvriendelijke waarnemingslaagjes bouwen.

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

inDrive.Tech

Deze audio wordt geproduceerd in de originele taal van het verhaal!

Hoe een n8n-automatisering te bouwen om Kibana-logs te lezen en te analyseren met een LLM

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps