Kibana reduce el tiempo de carga del dashboard hasta en un 25 %: esta es la estrategia de sondeo que hay detrás
Descubre cómo Kibana usa el sondeo continuo y la detección de HTTP/2 en el navegador para reducir los tiempos de carga del dashboard hasta en un 25 %, con una transición automática a HTTP/1 en caso de que no sea posible.
Los dashboards de Kibana y Discover ahora se cargan hasta un 25 % más rápido gracias al sondeo continuo. En lugar de esperar entre comprobaciones periódicas, Kibana ahora mantiene abiertas las conexiones HTTP y entrega los resultados de las búsquedas de Elasticsearch en el momento en que están listos. En HTTP/2+ (el valor predeterminado de Kibana desde la versión 9.0), esto se activa automáticamente sin necesidad de configuración. En HTTP/1, Kibana recurre al sondeo tradicional para evitar el agotamiento del grupo de conexiones.
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.
Estrategia de sondeo tradicional
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.
El lado oscuro de las encuestas tradicionales
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.
Cronograma de retroceso del intervalo de 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.
Tiempo perdido por duración de la búsqueda
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?
Sondeo continuo: una solución al tiempo perdido
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?
El sondeo continuo provoca una disminución del rendimiento en los clientes conectados a través de HTTP/1
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.
Diferencia en el mapping HTTP-TCP entre HTTP/1 y HTTP/2+
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.
El protocolo puede diferir para cada salto de red
Si basáramos nuestra optimización en el protocolo del servidor, podríamos equivocarnos de dos maneras diferentes.
Aplica sondeos continuos cuando no deberíamos y degrada la experiencia.
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.
new PerformanceObserver((list) => {
const entries = list.getEntries();
const entry = entries.find(({ name }) => name.includes('/internal/search/'));
if (entry) {
this.protocolSupportsMultiplexing = ['h2', 'h3'].includes(entry.nextHopProtocol);
}
});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).
Tiempos de carga del dashboard por duración de búsqueda
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).
Preguntas frecuentes
¿Cómo mejora el sondeo continuo la carga del dashboard en Kibana?
La velocidad de carga del dashboard depende de la rapidez con la que Kibana pueda recuperar los resultados de búsquedas de Elasticsearch. El sondeo tradicional verifica periódicamente la finalización, lo que puede provocar retrasos en la obtención de resultados. Con HTTP/2+, Kibana activa automáticamente el sondeo continuo, lo que elimina los retrasos al mantener las conexiones abiertas y ofrece los resultados de inmediato en cuanto están listos.
¿Qué es el sondeo continuo y cómo mejora el rendimiento de Kibana?
El sondeo continuo invierte el patrón tradicional al mantener abiertas las conexiones HTTP mientras se esperan los resultados de las búsquedas de Elasticsearch, en lugar de esperar entre las comprobaciones periódicas. Esto elimina el tiempo perdido y ofrece resultados tan pronto como estén listos, acelerando los Dashboards y Discover.
¿Funciona el sondeo continuo en conexiones HTTP/1?
No. El sondeo continuo solo se aplica en conexiones HTTP/2+ donde la multiplexación evita que las solicitudes de larga duración bloqueen otro tráfico. Kibana detecta automáticamente el protocolo usando la API PerformanceObserver del navegador y aplica el sondeo tradicional en HTTP/1 para evitar degradar el rendimiento.
¿Cuánto más rápido son los dashboards de Kibana con sondeo continuo?
Las pruebas de laboratorio muestran que los tiempos de carga del dashboard mejoran hasta en un 25 % dependiendo de la duración de la búsqueda. Las búsquedas más largas ven mayores ahorros de tiempo absolutos, mientras que las búsquedas muy cortas ven una diferencia mínima.
¿Cómo detecta Kibana si debe usar sondeos continuos o tradicionales?
Kibana usa la API PerformanceObserver del navegador para detectar el protocolo HTTP de la primera búsqueda. Si el protocolo es HTTP/2 o HTTP/3 (que admiten multiplexación), los sondeos continuos están habilitados. Si se detecta HTTP/1, se usa el sondeo tradicional para prevenir que se agote el grupo de conexiones.
¿El sondeo continuo puede causar problemas con el proxy o el equilibrador de carga de mi red?
El sondeo continuo se basa en multiplexación HTTP/2+ para evitar el agotamiento del grupo de conexiones del navegador. Si tu proxy rebaja las conexiones a HTTP/1 entre el proxy y el navegador, Kibana detectará esto y utilizará el sondeo tradicional en su lugar. La optimización se aplica condicionalmente en función de lo que el navegador realmente soporta.
Estoy viendo tiempos de espera agotados. ¿Qué debo hacer?
Si tu proxy usa HTTP/2+ pero aplica un tiempo de espera inferior a 30 segundos, verás tiempos de espera de búsqueda. Para solucionarlo, aumenta el tiempo de espera de tu proxy o configura data.search.asyncSearch.pollLength en tu kibana.yml a algo más bajo que tu tiempo de espera.
