Monitoreo de las vistas del dashboard de Kibana con flujos de trabajo de Elastic

Kibana registra cuántas veces se visualiza cada dashboard, pero esos datos no se muestran de forma nativa en ningún dashboard integrado. En este artículo, usaremos los flujos de trabajo de Elastic para recopilar automáticamente esos datos cada 30 minutos e indexarlos en Elasticsearch, para poder crear nuestras propias analíticas sobre ellos.

Los flujos de trabajo de Elastic son un motor de automatización integrado dentro de Kibana que te permite definir procesos multipaso usando una configuración sencilla de YAML. Cada flujo de trabajo puede activarse según una programación o un evento, o como una herramienta en Elastic Agent Builder, y cada paso puede llamar a las API de Kibana, consultar Elasticsearch o transformar datos.

Usaremos los recuentos de vistas del dashboard como ejemplo concreto, pero el mismo patrón aplica a cualquier métrica expuesta a través de la API de objetos guardados de Kibana.

Requisitos previos

• Elastic Cloud o un clúster autogestionado ejecutando la versión 9.3
• Flujos de trabajo activados (Configuración avanzada)

Antes de crear cualquier cosa, entendamos qué datos tenemos. Kibana almacena la mayor parte de su configuración y metadatos como objetos guardados en un índice interno dedicado. Una de las cosas que Kibana rastrea de esta manera es el número de vistas del dashboard, mediante un tipo especial de objeto guardado llamado contadores de uso. Puedes consultarlas directamente desde las Herramientas de desarrollo:

La respuesta tiene el siguiente aspecto:

El campo counterName es el ID del dashboard y count es el recuento acumulado de vistas para ese dashboard en ese día específico. Kibana crea un objeto de contador por dashboard al día; puedes ver el sufijo de fecha en el ID del objeto (...viewed:server:20260310). El conteo aumenta a lo largo del día a medida que los usuarios abren el dashboard.

En lugar de replicar este modelo de documento diario en nuestro índice, crearemos un documento por cada ejecución del flujo de trabajo. Cada documento registra cuántas vistas había acumulado ese dashboard durante el día en el momento de la captura.

Paso 2: Crear el índice de destino

Necesitamos un índice para almacenar las snapshots de la vista del dashboard. El siguiente comando lo crea con mapeos explícitos para que podamos agregar y visualizar más tarde. Ejecuta esto en herramientas de desarrollo:

Usarkeyword mapeos para ID y nombres permite agregaciones. Usar integer para view_count es un valor predeterminado seguro, ya que Kibana restablece el contador diariamente, por lo que alcanzar el límite de 32 bits (más de 2 mil millones de vistas en un solo día) no es una preocupación realista. Todavía admite operaciones numéricas, como max, avg y min, entre otras.

Paso 3: Crear el flujo de trabajo

Ve a Stack Management > Flujos de trabajo > Nuevo flujo de trabajo, y pega la siguiente configuración YAML del flujo de trabajo:

En la próxima sección, hagamos un desglose del flujo de trabajo paso a paso.

Cómo funciona el flujo de trabajo

Desencadenantes

El flujo de trabajo se ejecuta mediante un desencadenante programado cada 30 minutos. Esto nos proporciona datos temporales sin saturar la API.

fetch_dashboard_views

Usakibana.request para llamar a la API de objetos guardados de Kibana. No hace falta configurar la autenticación: el motor de flujos de trabajo añade automáticamente los encabezados correctos según el contexto de ejecución.

index_each_dashboard (foreach)

Itera sobre la matrizsaved_objects devuelta por el paso anterior. El elemento actual en cada iteración está disponible como foreach.item. Dentro del bucle, ejecutamos dos pasos anidados para cada dashboard.

1. fetch_dashboard_name:

Resuelve el título legible para los humanos del dashboard al llamar a GET /api/saved_objects/dashboard/{id}. Agregamos on-failure: continue: true para que, si un dashboard se eliminó pero aún tiene contadores de vistas, el bucle continúe en lugar de fallar toda la ejecución.

2. index_doc:

Indexa cada documento usando POST /dashboard-views/_doc (sin un ID explícito), lo que permite que Elasticsearch genere automáticamente los ID. Esto crea un nuevo documento en cada ejecución, lo que crea un historial del número de vistas a lo largo del tiempo en lugar de sobreescribir el snapshot anterior.

Dos cosas que vale la pena destacar:

• El campo captured_at usa el filtro de fecha para formatear la marca de tiempo como ISO 8601. Sin ella, el valor sale como un texto de fechas en JavaScript, como Tue Mar 10 2026 05:03:47 GMT+0000, que Elasticsearch no asigna como fecha.
• El view_count usa la sintaxis ${{ }} con | plus: 0 para preservar el tipo numérico. Usar {{ }} lo mostraría como un texto, lo que impediría realizar operaciones matemáticas en el dashboard.

La UI te permite depurar fácilmente cada uno de los pasos del flujo de trabajo.

Paso 4: Crea el dashboard de estadísticas

Una vez que el flujo de trabajo se haya ejecutado varias veces y se hayan recopilado los datos, crea un nuevo dashboard en Kibana usando la Data view de vistas del dashboard.

Algunos paneles para empezar:

• Los dashboards más vistos: Usa un Gráfico de barras con dashboard_name en el eje X y last_value(view_count) en el eje Y. Aquí se muestra el número actual de vistas diarias por dashboard.
• Vistas a lo largo del tiempo: usa un gráfico de líneas con captured_at en el eje X y last_value(view_count) en el eje Y, desglosado por dashboard_name. Dado que cada ejecución agrega un nuevo documento, usa el último valor para obtener el recuento máximo por cubetas de tiempo en lugar de sumar duplicados.
• Snapshot actual: usa una tabla de datos con el captured_at más reciente para mostrar los recuentos de vistas más recientes en todos los dashboards.

Dado que cada flujo de trabajo crea un nuevo documento, puedes filtrar por intervalo de tiempo para analizar la actividad en períodos específicos, comparar semana a semana o configurar alertas cuando un dashboard caiga por debajo de un umbral de visitas.

Conclusión

Elastic Flujos de trabajo es una buena opción para este tipo de recopilación periódica de datos porque tanto el origen (API de Kibana) como el destino (Elasticsearch) son nativos, lo que significa cero gestión de credenciales. El motor de flujo de trabajo maneja la autenticación automáticamente para los pasos kibana.request y elasticsearch.request, por lo que lo único que escribes es la lógica.

Recursos

• Flujos de trabajo de Elastic
• API de Kibana