Guía de solución de problemas: cómo resolver 6 problemas comunes en la carga de Kibana Discover

Discover es la UI de Kibana®núcleo de Elastic® para buscar, filtrar e inspeccionar datos (temporales). Visualizaciones se utilizan para agregaciones/resúmenes de datos. La UI de Discover es resistente a las respuestas de grandes volúmenes de datos de Elasticsearch®, pero a veces puede experimentar problemas debido al tamaño de la respuesta (sin comprimir), mapping explosion y los límites del navegador.
A continuación, resumiremos los problemas históricos más comunes, incluyendo cargas lentas, tiempos de espera agotados y errores, y proporcionaremos una guía secuencial de solución de problemas para resolverlos. Nota: Las API de este artículo están escritas para la v8.6, pero el flujo general de solución de problemas se aplica a versiones anteriores y posteriores.

Después de establecer y cargar una sesión de usuario, Kibana cargará Discover mediante la URI base /app/discover (o su URI específica relacionada de Kibana Space). Para cargar esta página, la página del navegador solicitará secuencialmente tres API al servidor de Kibana (y a través de Kibana al servidor de Elasticsearch que aparece a continuación, según sea necesario).
Problema común 1: errores de página al cargar
Si la página de Kibana da error al cargar, abre la pestaña de red del navegador para confirmar qué solicitud secuencial falla. Puedes compartir tus hallazgos exportando un log HAR.
1. Cargar Data view
La página del navegador solicitará el Saved Objects endpoint de Kibana para el Data View seleccionado actualmente (el código sigue apuntando a `type:index-pattern`, ya que este objeto se llamaba “patrón de índice” en versiones anteriores, pero se renombró en la v8.0 para mayor claridad).
POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]Esta búsqueda de la API de Kibana se reenvía a la API de Elasticsearch bajo el Alias .kibana que respalda al objeto guardado. No estoy seguro sobre la traducción de la búsqueda, pero sería algo como:
GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
"match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}Nota: Los Saved Objects se buscan por el id del Data view y no por el título o el nombre. Si exportas/importas o copias Saved Objects entre Kibana Spaces o clústeres de Elasticsearch, es posible que tengas un error de visualización/dashboard/Discover porque tu id subyacente cambió durante la importación (consulta el módulo de importación de Saved Object para evitarlo). Para demostrar la diferencia entre estos campos:

Problema común 2: Data view faltante
Si esto te afecta, durante la carga de la página, esperarás un módulo de advertencia/error en la parte inferior derecha similar a: "DATA_VIEW_ID" no es un ID de Data view configurado
Este error se informa en el contexto del Kibana Space actual y no califica si el Data view existe o no en un Space diferente.
2. Cargar campos
A continuación, la UI de Kibana cargará una compilación de los campos relacionados de los índices de respaldo.
API. Primero, realizará una solicitud de API:
GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_scoreEsta API se volverá a activar cada vez que el usuario seleccione un Data view en la parte superior izquierda. En el back end, Kibana devuelve índices de la campo Caps API de Elasticsearch.
Problema común 3: explosión de mapping
El tiempo de respuesta de esta API se ve afectado drásticamente por la explosión de mapping, que puede diagnosticarse parcialmente mediante el tamaño de respuesta comprimido/sin comprimir de esta API. Por lo general, esto se relacionará con cuántos mappings de índice variables se cargan, pero también puede ser el resultado de exceder los límites de mapping. Por lo general, esto devuelve un valor (muy) inferior a 3 s, pero definitivamente deberías considerar ≥10 s como lento.
Problema común 4: conflictos de campo
Históricamente, han ocurrido errores debido a conflictos de nombres de campo entre índices. Querrías corregir los mappings de índice subyacentes, pero también puedes aplicar un campo de tiempo de ejecución como una anulación temporal para corregir el tipo de mapping de los índices erróneos.
JS. Una vez que los resultados de la API regresan, si el panel izquierdo (que muestra los “Campos seleccionados” y los “Campos disponibles”) está abierto, el JavaScript del navegador realizará analíticas de resumen sobre estos campos. Si es lento, esto aparecerá en la pestaña Red del navegador como si la solicitud de la API hubiera terminado, pero la siguiente solicitud (3) no hubiera comenzado a intentarlo durante varios segundos. Los usuarios normalmente solo lo notan a partir de ≥10 s.

Este tiempo de compilación de JavaScript se diagnostica a través de la pestaña Performance de las DevTools del navegador (p. ej., Chrome, Firefox, Edge; también se puede exportar un equivalente tipo HAR para compartir).
3. Cargar búsqueda
Por último, la página del navegador realizará una solicitud de búsqueda de API. Esta solicitud de búsqueda de API pasa por el servidor de Kibana, pero (debería) tardar casi la misma cantidad de tiempo que realizar la solicitud de API de Elasticsearch directamente.
API. Este URI tiene como valor predeterminado:
POST /internal/bsearch {REQUEST_BODY_HERE}Pero si la configuración avanzada courier:batchSearches está configurada como false (<v8.0), entonces esto solicitará en su lugar la siguiente API:
POST /internal/_msearch {REQUEST_BODY_HERE}
Esperamos una diferencia entre el "tiempo de búsqueda" (el tiempo que Elasticsearch considera que toma la búsqueda) y el tiempo reportado por Kibana, pero querremos verificar si este último tiene órdenes de magnitud de diferencia con respecto al primero, lo que indicaría, por ejemplo, carga en el servidor de Kibana, que la compresión HTTP está desactivada o un problema general de renderizado.
Si queremos investigar nuestra búsqueda más a fondo para aislar la carga del servidor de Kibana de un problema de renderizado general, navegaremos a Inspect > Request > Open in Console (también conocido como DevTools). Visualmente:

Luego ejecutaremos esta solicitud de búsqueda de API tanto en DevTools como por separado mediante cURL de la API de Elasticsearch, observando las diferencias generales en el tiempo de respuesta entre Discover, DevTools y la API de Elasticsearch.
Problema común 5: si la búsqueda es lenta en la API de Elasticsearch
Si Elasticsearch también es tan lento como los otros dos, podemos sospechar de una búsqueda/filtro no optimizado en nuestra vista original de Discover. Si no se aplican filtros/búsquedas (o si se reproduce sin ninguno aplicado), confirmaremos el rendimiento general de Elasticsearch mediante CAT Node, CAT Threadpools (especialmente hilos de búsqueda) y CAT Tasks (para tareas de larga duración). Si no se encuentra ningún problema en todo el cluster, compararemos las duraciones de la respuesta de búsqueda entre los diferentes Data view seleccionados en Discover y luego compararemos el Query Profiling relacionado con estas búsquedas (después de inyectar profile: true en el cuerpo de nuestra solicitud de búsqueda).
JS. Después de que los resultados de la API regresan, el JavaScript del navegador entra en acción para cargar 1) el resumen de la tabla de visualización (la tabla "Documents" en la parte inferior central donde puedes activar o desactivar la vista de columnas) o 2) "campo Statistics" (en beta, actívalo en Advanced Settings mediante Discover:showFieldStatistics).
Problema común 6: tiempo de renderizado afectado por la explosión de mapping
Mapping Explosions pueden generar un conjunto de resultados grande, lo que en el pasado ha causado regresiones de rendimiento en el navegador (p. ej., kibana#144673). Mapping Explosion puede mostrar errores específicos del navegador, como el error de Chrome: maximum call stack size exceeded, que se reproduce en modo incógnito, no ocurre en Firefox/Safari y, a veces, solo se resuelve actualizando Chrome. Si, sin embargo, encuentras un proceso de renderizado muy lento sin errores después de que se haya devuelto el resultado, es hora de grabar un Performance Profile del navegador para analizar qué está causando la lentitud en el renderizado. ¡Nuestro equipo estará encantado de ayudar a revisar la salida a través de Kibana GitHub, Elastic Discuss o abriendo un caso de soporte!
Impacto en cascada
(Para ayudar con la búsqueda rápida en la página: #devToolsAuto.) Mientras solucionas posibles explosiones de mapping, DevTools puede responder más lento que Discover y la carga del icono superior izquierdo cuando no se esperan solicitudes debido a la URI.
GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
Estas solicitudes pueden ralentizar 1) el navegador local, lo que provoca bloqueos de página o banners de “¿esperar a la página?”, y 2) el servidor de Kibana, dependiendo de la frecuencia y el costo de procesamiento. Este cambio es específico para el usuario que inició sesión.
Conclusión
Discover es una forma sencilla de inspeccionar los datos de múltiples índices dentro de tus clusters. Hay algunas configuraciones y ajustes que pueden hacer que esta UI cargue más lento de lo necesario. Esta guía analizó el impacto de estos diversos problemas; sin embargo, una buena higiene de datos puede evitarlos todos. Para obtener más consejos sobre higiene de datos, consulta nuestra documentación de Elasticsearch.
El momento del lanzamiento de cualquiera de las características o funcionalidades descritas en esta publicación queda a exclusivo criterio de Elastic. Es posible que algunas características o funcionalidades que no estén disponibles en este momento no se lancen a tiempo o no se lancen en absoluto.