Por Philipp Kahr
Nota importante para los usuarios de Elasticsearch Service: Actualmente, los cambios de configuración de Kibana que se describen en este artículo están limitados a Cloud Console y no se pueden configurar sin la intervención manual de nuestro equipo de soporte. Nuestro equipo de ingeniería está trabajando arduamente para eliminar las restricciones en estas configuraciones para que todos nuestros usuarios puedan habilitar APM interno. Las implementaciones locales no se ven afectadas por este problema.
Identificar y solucionar consultas es una habilidad fundamental que debe dominar cualquier persona que use Elasticsearch como motor de búsqueda. Ya sea que se trate de comercio electrónico, observabilidad o una solución de búsqueda orientada al lugar de trabajo, la búsqueda lenta de Elasticsearch puede afectar negativamente la experiencia del usuario.
Para identificar las consultas lentas de Elasticsearch, puede usar el registro lento , que captura las consultas que se ejecutan en un cierto umbral. Obtener el umbral de registro lento correcto es un desafío en sí mismo. Por ejemplo, una consulta que tarda 500 milisegundos puede ser aceptable con carga completa, pero la misma consulta puede no ser aceptable con carga baja. El registro lento no diferencia y registra todo por encima de 500 ms. El registro lento hace bien su trabajo y puede capturar diferentes niveles de granularidad según los umbrales. En su lugar, el seguimiento puede analizar todas las consultas y determinar cuántas se encuentran dentro de un cierto umbral.
La supervisión del rendimiento de la aplicación (APM) ya no se limita a su aplicación. Usando la instrumentación en Elasticsearch, ahora podemos agregar Elasticsearch como un servicio completo en lugar de una dependencia de la pila de aplicaciones. De esta forma, podemos obtener una vista más granular del rendimiento que el registro lento.
Para los ejemplos a continuación, nuestro corpus de datos es OpenWebText , que proporciona alrededor de 40 GB de texto sin formato y alrededor de 8 millones de documentos individuales, que se ejecutan localmente en una Macbook M1 Max con 32 GB de RAM.
¡Empecemos!
La activación del rastreo en Elasticsearch se realiza a través de configuraciones estáticas (configuradas en elasticsearch.yml) y configuraciones dinámicas, que se pueden alternar en tiempo de ejecución mediante el comando PUT _cluster/settings, donde una de las configuraciones dinámicas es la frecuencia de muestreo. Ciertas configuraciones, como la frecuencia de muestreo, se pueden alternar en tiempo de ejecución. En elasticsearch.yml queremos configurar lo siguiente:
tracing.apm.enabled: true
tracing.apm.agent.server_url: "url of the APM server"El token secreto (o clave de API) debe estar en el almacén de claves de Elasticsearch. Use el siguiente comando elasticsearch-keystore add Tracing.apm.secret_token o Tracing.apm.api_key La herramienta de almacenamiento de claves debe encontrarse en <su directorio de instalación de elasticsearch>/bin/elasticsearch-keystore . Después de eso, debe reiniciar Elasticsearch. Puede encontrar más información sobre el seguimiento en nuestra documentación de seguimiento .
Una vez que APM está activo, podemos mirar la vista de APM en Kibana y ver que Elasticsearch captura automáticamente varios puntos finales de API REST. Aquí, nos centraremos en la llamada POST /{index}/_search para ver qué podemos obtener de ella.
Al inspeccionar la consulta simple directamente en el cuadro GET /{index}/_search, vemos el siguiente desglose en cascada. Esto contiene tramos internos que brindan una visión más profunda de lo que Elasticsearch está haciendo detrás de escena. Vemos la duración total de esta búsqueda (86 milisegundos).
Los metadatos que acompañan a la consulta incluyen información detallada sobre los encabezados HTTP, el agente de usuario, la ubicación del nodo de Elasticsearch (metadatos del proveedor de la nube, nombre de host, información del contenedor), cierta información del sistema y detalles de la URL. Utilizando información comercial básica, podemos crear un gráfico de lentes que represente la duración promedio de la operación y nos permita ver si hay una tendencia alcista o bajista.
nuestra aplicación de búsqueda
¡Qué bueno que ya no necesites usar slowlog! Puedo determinar la duración de la transacción y determinar cuántas búsquedas se responden en cualquier umbral. Sin embargo, hay un contratiempo: Elasticsearch no captura la consulta que se envía (cuál era exactamente la consulta), por lo que sabemos que la consulta lleva mucho tiempo, pero no sabemos cuál era la consulta.
Probemos una aplicación de búsqueda de muestra. En este ejemplo, usaremos una aplicación Flask simple con dos rutas: search_single y search_phrase que representarán consultas de coincidencia y frase_de coincidencia en Elasticsearch . Por ejemplo, podemos usar la siguiente consulta:
{
"query": {
"match": {
"content": "support"
}
}
}y
{
"query": {
"match_phrase": {
"content": "support protest"
}
}
}El siguiente código Flask implementa la ruta search_single. search_phrase es muy similar excepto que usa match_phrase en lugar de match.
@app.route("/search_single", methods=["GET"])
def search_single():
query = request.args.get("q", "")
if not query.strip():
return jsonify({"error": "No search query provided"}), 400
try:
result = es.search(
index=ES_INDEX, query={"match": {"content": query}}
)
hits = result["hits"]["hits"]
response = []
for hit in hits:
response.append(
{
"score": hit["_score"],
"content": hit["_source"]["content"],
}
)
return jsonify(response)Cuando esté listo, ahora puedo llamar a curl -XGET "http://localhost:5000/search_single?q='microphone'" para buscar el término "micrófono".
Principalmente agregamos APM a nuestra aplicación de búsqueda para la observación, pero nuestro agente APM captura las solicitudes salientes y las enriquece con información de metadatos. En nuestro caso, span.db.statement contiene consultas de Elasticsearch. En el siguiente ejemplo, alguien busca window.
unirlos
En mi servicio Flask, establecí el tamaño de la consulta en 5000, lo que significa que Elasticsearch debería proporcionarme hasta 5000 documentos coincidentes en una sola respuesta JSON. Este es un gran número, y la mayor parte del tiempo se dedica a recuperar tantos documentos del disco. Después de cambiarlo a los 100 documentos principales, puedo identificar rápidamente lo que sucede en el panel de control en comparación.
La visualización de transacciones en la vista APM y la activación de la función de laboratorio de ruta crítica crea una superposición que nos muestra dónde pasa el tiempo la aplicación.
Después de eso, creé un tablero con los campos transacción.duración.us, es_query_took, transacción.nombre. Los filtros generales de KQL incluyen service.name, procesador.event: transacción, transacción.nombre: POST /{index}/_search.
Sugerencia adicional: vaya a Administración de vistas > seleccione la vista que contiene el flujo de datos de APM > seleccione el campo transaction.duration.us > y cambie el formato a duración. Ahora lo representa automáticamente en una salida legible por humanos en lugar de microsegundos.
Usando la función de anotación de Lens, podemos ver en el medio Lens que cambiar a 100 documentos redujo bastante la transacción de búsqueda promedio. No solo eso, mire el número total de registros en la esquina superior derecha. Como podemos buscar más rápido, ¡tenemos un mayor rendimiento! Me gustan mucho los histogramas, así que creé un histograma en el medio de la fila superior con la duración de la transacción en el eje X y el número de registros en el eje Y. Además, APM proporciona métricas para que podamos determinar en cualquier momento cuánto uso de CPU% está ocurriendo junto con el montón de JVM, el uso que no es de montón, el recuento de subprocesos y mucha más información útil.
en conclusión
Esta publicación de blog le muestra lo importante que es usar Elasticsearch como una aplicación instrumentada e identificar cuellos de botella más fácilmente. Además, puede usar la duración de la transacción como una métrica para la detección de anomalías, realizar pruebas A/B de su aplicación y nunca más preguntarse si Elasticsearch se siente más rápido porque ahora tiene los datos para responder esa pregunta. Además, todos los metadatos recopilados del agente de usuario para la consulta pueden ayudarlo a solucionar problemas.
Los tableros y las vistas de datos se pueden importar desde aquí .
Advierta
sobre problemas con la duración de la transacción dentro de Elasticsearch. Este problema se solucionó en la próxima versión 8.9.1. Antes de eso, la transacción usa el reloj incorrecto, lo que altera la duración general.El lanzamiento y el momento de cualquier característica o funcionalidad descrita en este artículo quedan a criterio exclusivo de Elastic. Cualquier característica o funcionalidad que no esté disponible actualmente puede no entregarse a tiempo o en absoluto.