Para nuestro pequeño equipo de Soporte de Incidentes (sólo 6 especialistas), dos métricas son absolutamente críticas: y . speed of detection accuracy of diagnosis Recibimos casos de millones de usuarios en todo el mundo Cuando se introduce un caso de usuario, una de las herramientas básicas en las que confiamos, junto con otras, es . 48 countries Kibana Debido a la naturaleza multifactorial de nuestro sistema (microservicios, especificidades regulatorias locales, experimentos A/B, y más), a menudo terminamos buscando una solución. mediante el análisis de eventos relacionados con el usuario en los registros. Agujero en un hayestack Incluso para un especialista experimentado, esto toma tiempo para: 
 
 
 
 comprender lo que realmente sucedió, separar el ruido de los problemas reales, conectar eventos técnicos con la experiencia real del usuario. En general, este tipo de análisis requiere , y en situaciones ambiguas, puede tardar mucho más tiempo. at least 15 minutes per case Quería que los libros se leyeran como un No, no es como un evento crudo. story Y sí, esto es Pero más bien a . not a replacement for an engineer Acelerador de pensamiento La idea Hemos construido una automatización en Combina varias herramientas: n8n 
 
 
 
 Slack Kibana (a través de clarividencia) LLM (Gran Modelo de Lenguaje) Y lo convirtió en un flujo de trabajo simple y práctico para los especialistas en soporte. Cómo funciona 
 
 
 
 
 
 
 
 
 
 Se crea un canal dedicado de Slack. Un especialista envía un UID de usuario al canal, sólo un número. La automatización captura el UID y envía una solicitud a Clairvoyance Kibana usando filtros predefinidos. Todos los registros de actividad de los usuarios de las últimas 6 horas se recuperan. Si no se encuentran registros, se publica un claro mensaje "no se encontró actividad" en el hilo 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. El paquete de registro completo se envía a un LLM junto con una solicitud personalizada adaptada a las necesidades de nuestro equipo. El LLM analiza los eventos y devuelve un resumen legible por el hombre (hasta 600 caracteres). La respuesta se publica de nuevo en el hilo original de Slack aproximadamente 2 minutos después de la solicitud. El desarrollo inicial de este gasoducto tuvo , una gran parte de la cual fue en la configuración adecuada de credenciales (especialmente para Slack - lo cubriré más adelante). 30 hours Esperamos que con el uso activo, esta automatización salve al equipo . up to 60 hours per month ¿Qué Realmente Responde El LLM? La respuesta es siempre estructurada y responde a preguntas muy específicas: 
 
 
 
 
 
 ¿Qué errores se detectaron? Un resumen de los eventos positivos (normales) Cómo los errores podrían haber afectado el flujo de trabajo del usuario Cuando exactamente ocurrieron los problemas (timestamps) Qué acciones debe tomar el especialista Como resultado, no solo vemos Pero el real : Qué estaba haciendo el usuario, dónde encontraron un problema y cuán crítico era. “HTTP 400 en Endpoint X” context Y sí - . no sensitive data is ever sent to the LLM Objetivos básicos de la automatización Humanizar la lectura de registros Kibana es una herramienta poderosa, pero leer los registros con los ojos es fatigante y cognitivamente costoso, especialmente cuando los eventos se propagan a lo largo del tiempo y a través de múltiples servicios. Yo quería que el resultado se vea como un No es un desperdicio técnico. clear explanation Reducir el tiempo de análisis Before automation: 
 
 15 minutos por caso de usuario After automation: 
 
 1–2 minutos (enviar UID → obtener resumen) Esto es especialmente importante durante las cargas de pico o los incidentes masivos. Permite un análisis más profundo La automatización no solo nos ahorra tiempo, sino que nos permite: 
 
 
 
 
 detectar problemas de sistema más rápidamente, Identificar patrones de error recurrentes entre los usuarios, mejorar las capacidades de los especialistas destacando nuevas áreas problemáticas, entender mejor cómo se comporta la aplicación en el uso del mundo real. En última instancia, este enfoque reduce significativamente el tiempo que los desarrolladores pasan investigando problemas descritos únicamente a través de la experiencia del usuario. ¿Para quién es esta herramienta? En primer lugar: 
 
 
 
 Apoyo de especialistas, Ingenieros que trabajan con incidentes de usuario, equipos que necesitan comprender rápidamente “lo que salió mal” sin sumergirse inmediatamente en Kibana. ¿Es esta la versión final? No. Este es un Actualmente en A , con un despliegue completo planificado para temprano . living tool Fase de prueba silenciosa 2026 Durante la prueba: 
 
 
 
 se refinan rápidamente, diferentes LLMs y versiones de modelos son comparados, La lógica de filtración y los modelos de respuesta se han mejorado. Incluso ahora, la automatización ya cumple su objetivo principal: . making logs understandable and saving time Estructura del gasoducto Trigger La tubería comienza desde un evento en un canal dedicado Slack ( ) de : Slack Trigger 
 
 
 Tipo de evento: Nuevo mensaje publicado en el canal Introducción: un UID de usuario enviado como texto simple Preparación de datos Los datos del mensaje se extraen y transforman utilizando En el formato JSON requerido: Set nodes 
 
 
 Rango superior: UID (como un número) Filial inferior: contexto de thread (ID de canal y timestamp de thread) Registro de Retrieval La UID se pasa a Kibana ( ) Utilizando el Índice de clarividencia. Elasticsearch / Get Many traces-main Los registros son buscados por dentro de una ventana de tiempo definida. user_id Lógica condicional y Comprobar si se han encontrado incidentes: 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 Respuesta Entrega La salida de LLM se fusionó con el contexto de thread Slack y se publicó como una respuesta en el thread original. Detalles del nodo Slack Trigger Requiere credenciales Slack preconfiguradas y el ID de canal (disponible a través de En el Slack. Canales abiertos Detalles Coloque los nodos Usado para extraer y normalizar los datos de entrada: 
 
 
 uid → parsado de texto de mensaje como un número thread data:
 
 
 
 
 channel  → original message timestamp thread_ts ElasticSearch Node Requiere las credenciales de Kibana y el ID de índice (en ) de Gestión de índices Claves de configuración: 
 
 
 límite: 1000 elementos(Valores más altos a menudo causaron temporales de la puerta de entrada.) Query:
 
 
 
 
 
 
 time range:  now-6h filter by  user_id limited source fields last 1000 events Código de Nodo (Minimizador) Prepara los registros para el análisis LLM: 
 
 
 
 
 
 
 
 
 normalizan los campos (tiempo, contenido), mascarar posibles PII (teléfono / correo electrónico - incluso si no está presente, como protección adicional), de los valores largos, elimina los campos vacíos, tipos de eventos por tiempo, duplicar eventos similares, Calcula estadísticas ligeras (códigos HTTP, puntos finales), Construye un prompt compacto con los primeros 500 eventos agregados y un límite de longitud estricto. Esto es crucial para evitar enviar cargas de pago grandes y caras de token al LLM. OpenAI Node (Mensaje a modelo) Requiere credenciales de OpenAI y selección de modelos (actualmente durante la prueba). GPT-4.1-Mini El proyecto está diseñado desde la perspectiva de un : second-line technical support specialist 
 
 
 
 
 
 
 clasificar primero al usuario (conductor / pasajero / corredor), en caso de errores técnicos, si no existen errores, analizar el estado de la empresa (documentos, prohibiciones, estado de perfil), Siga un modelo de respuesta estricto con límites de caracteres, enlazar conclusiones a puntos finales concretos y timestamps, Análisis técnico separado del impacto del flujo de trabajo orientado al usuario. Esta estructura convierte los logos crudos en . clear, actionable insights Ejemplo de salida disponible abajo: Pensamientos finales Esta automatización no reemplaza a los ingenieros, sino que les ayuda a pensar más rápido.Al convertir los registros crudos en narraciones breves y estructuradas, el equipo reduce la carga cognitiva y acelera el análisis de incidentes sin perder el contexto. Con herramientas como n8n y LLMs modernos, incluso los pequeños equipos pueden construir capas de observabilidad prácticas y humanas.

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

inDrive.Tech

Este audio es producido en el idioma original de la historia!

Cómo construir una automatización n8n para leer los registros de Kibana y analizarlos con un LLM

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Telegram: el puente de Crypto Island hacia el continente

Una breve introducción a la teoría del cerebro de Boltzmann

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Telegram: el puente de Crypto Island hacia el continente

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps