Cómo Kibana obtiene datos al cargar un dashboard

Cuando se abre un dashboard, la mayoría de los paneles (internamente, los llamamos insertables) inician una o más búsquedas de Elasticsearch. Sin embargo, en lugar de la simple llamada y respuesta de una búsqueda síncrona (sinc), usamos el poder de la búsqueda asíncrona (asinc) (docs).

Con la búsqueda asincrónica, los resultados de las consultas se mantienen disponibles en Elasticsearch fuera de cualquier solicitud HTTP en particular. Esto es importante porque

• hace que la carga de datos sea resistente a la turbulencia de la red

• impulsa nuestra función de búsqueda en segundo plano, que permite a los usuarios seguir trabajando en otras cosas en Kibana mientras esperan a que se cargue un dashboard o una sesión de Discover que tarda mucho en cargarse

Tras enviar la búsqueda inicial, Kibana monitorea la búsqueda para detectar cuándo está completa y recuperar el conjunto de resultados.

Cómo el sondeo tradicional afecta los tiempos de carga del dashboard de Kibana

En el sondeo tradicional, Kibana envía una búsqueda, cierra la conexión inicial y luego verifica periódicamente en Elasticsearch si la búsqueda ha finalizado.

Le damos a Elasticsearch un corto período de tiempo después del envío de la búsqueda para que simplemente complete la búsqueda y devuelva los resultados. Si la búsqueda se completa tan rápidamente, equivale a una simple llamada y respuesta. Pero para búsquedas más largas, la conexión inicial se cierra y Kibana comienza a verificar periódicamente la búsqueda para completarla. Esto se llama sondeo.

Desventajas en el rendimiento del sondeo tradicional

Si observamos la figura anterior, tal vez ya puedas ver el inconveniente de rendimiento de este enfoque: lo más probable es que la búsqueda termine durante uno de los intervalos de suspensión de Kibana, lo que lleva a perder tiempo.

En el peor de los casos (cuando una búsqueda se completa al comienzo de un período de inactividad) se desperdiciará toda la duración del intervalo de sondeo.

El impacto de una estrategia de retroceso

Aplicar una estrategia de retroceso, es una práctica estándar al realizar sondeos. Esto significa que cuanto más larga sea la duración de la búsqueda, con menos frecuencia realizamos el sondeo.

Sin embargo, esto también significa que el tiempo potencial perdido escala con la duración de la búsqueda.

Cómo los intervalos de sondeo generan patrones de latencia en forma de diente de sierra

Al unir estos factores, nuestro tiempo perdido se convierte en una función escalonada en diente de sierra.

Aquí, los picos representan los peores escenarios posibles y los valles, los mejores. Esto muestra que el sondeo tradicional nos puede costar desde nada hasta el tiempo completo del intervalo de sondeo, dependiendo de cuánto dure la búsqueda (y las condiciones de la red).

Sondeos continuos: cómo Kibana elimina el tiempo de espera

El problema con los sondeos tradicionales es la falta fundamental de coordinación entre Kibana y Elasticsearch. Idealmente, Kibana sabe inmediatamente cuándo hay resultados disponibles. Entonces, ¿qué pasaría si invirtiéramos el patrón de sondeo para que casi todo el tiempo se dedique a revisar Elasticsearch y no se pierda nada?

Con esta combinación de sondeos largos y sin más períodos de inactividad, los resultados se entregan no bien están listos.

Degradación de HTTP/1

La teoría es sólida. Entonces, ¿por qué este despliegue de Kibana parece tan degradado cuando activamos el sondeo continuo?

La clave es que este despliegue se está ejecutando sobre HTTP/1. En HTTP/1, las solicitudes HTTP se mapean 1:1 a conexiones TCP. Así que varias solicitudes de sondeo de larga duración están acaparando el límite de conexiones del navegador, lo que provoca que otras peticiones se pongan en cola.

En cambio, en HTTP/2+, las solicitudes de red pueden compartir conexiones TCP mediante multiplexación, así que no nos encontramos con este problema.

Entonces, en HTTP/2+ el sondeo continuo es una virtud, pero en HTTP/1 se convierte en un vicio.

HTTP/1

HTTP/2+

Conexiones TCP

Uno por solicitud HTTP

Multiplexado (muchas solicitudes comparten conexiones)

Comportamiento del sondeo continuo

Degradación del rendimiento (agotamiento del grupo de conexiones)

Beneficio completo (resultados entregados inmediatamente)

Cómo Kibana detecta el protocolo HTTP para un sondeo óptimo

HTTP/2 es el protocolo recomendado y es el predeterminado de Kibana desde la versión 9.0, así que sería una pena no enviar esta mejora de rendimiento. Por otro lado, la experiencia de HTTP/1 está tan degradada que no es aceptable arriesgarse a usarla en ningún despliegue local que aún no haya actualizado su protocolo. La respuesta es clara: necesitamos detectar qué protocolo está en uso y aplicar la estrategia de sondeo óptima.

Ciertamente es posible que el servidor de Kibana sepa de qué protocolo está hablando. Pero hay un problema: el factor limitante es el grupo de conexiones del navegador. Eso significa que lo que realmente importa es lo que el navegador está diciendo.

Debido a los proxies, no siempre son los mismos.

Si basáramos nuestra optimización en el protocolo del servidor, podríamos equivocarnos de dos maneras diferentes.

1. Aplica sondeos continuos cuando no deberíamos y degrada la experiencia.

2. Si no aplicamos el sondeo continuo cuando deberíamos, nos perdemos la optimización.

Afortunadamente, los navegadores modernos proporcionan una manera de detectar el protocolo del último salto de red de cualquier solicitud completada mediante el uso de un PerformanceObserver. Así que nos fijamos en el protocolo de la primera búsqueda enviada y optimizamos en función de eso.

Resultados de laboratorio: sondeo continuo frente a sondeo tradicional en Kibana

Para validar el sondeo continuo, creamos dashboards con retardos de búsqueda que iban de 1 a 23 segundos y medimos los tiempos de carga con y sin la optimización activada. Luego cargamos los dashboards con y sin sondeo continuo para medir las ganancias (nos divertimos mucho con race-for-the-prize).

El patrón reproduce nuestro diagrama de diente de sierra original. Para algunas duraciones de búsqueda, las ganancias son pequeñas, mientras que para otras ascienden a varios segundos.

Conclusión

Esta optimización reemplaza con éxito la latencia inherente al sondeo tradicional con una estrategia de sondeo continuo más eficiente. El reto principal fue implementar esta optimización condicionalmente para evitar la degradación del rendimiento en despliegues HTTP/1. Lo solucionamos usando el PerformanceObserver del navegador para detectar de forma confiable el protocolo en uso en el salto final de red.

Las pruebas de laboratorio validan la teoría, muestran que el sondeo continuo arroja resultados tan pronto como están listos. En promedio, esto conduce a una mejora significativa en la experiencia del usuario, lo que hace que los datos se carguen hasta un 25 % más rápido.

Este trabajo es el último paso en nuestro compromiso por reducir el tiempo que tardan nuestros usuarios en obtener información útil. Al hacer de Kibana un proxy más transparente para los datos de Elasticsearch, superamos los límites del rendimiento dentro de nuestra esfera de influencia. Más próximamente.

(en 2025, Thomas Neirynk ofreció una excelente visión general de los métodos y la motivación detrás de la mejora del rendimiento del dashboard de Kibana. Esta es una actualización sobre esa iniciativa).