- ClickStack gestionado
- ClickStack Open Source
La siguiente guía asume que ha completado la Guía de introducción para Managed ClickStack y que tiene las credenciales de conexión anotadas.
1
Selecciona tu servicio
Selecciona el servicio con Managed ClickStack en la página principal de ClickHouse Cloud.
3
Descargar datos de ejemplo
Para cargar la UI con datos de ejemplo, descargue el siguiente archivo:Datos de ejemploEste archivo contiene logs, métricas y trazas de ejemplo de nuestra demo pública de OpenTelemetry, una sencilla tienda en línea con microservicios. Copia este archivo en el directorio que prefieras.
4
Cargar datos de ejemplo
Para cargar estos datos, simplemente los enviamos al endpoint HTTP del OTel collector de OpenTelemetry ya desplegado.Ejecute el siguiente comando para enviar los datos al OTel collector:Esto simula fuentes OTLP de logs, trazas y métricas que envían datos al OTel collector. En producción, estas fuentes pueden ser clientes en distintos lenguajes o incluso otras instancias de OTel collector.Al volver a la vista
Search, deberías ver que los datos han empezado a cargarse (ajusta el intervalo de tiempo a Last 1 hour si los datos no se muestran):La carga de datos tardará unos minutos. Espera a que termine antes de continuar con los siguientes pasos.5
Explorar sesiones
Supongamos que hemos recibido informes de que nuestros usuarios están teniendo problemas para pagar sus compras. Podemos ver su experiencia usando la función de session replay de HyperDX.Selecciona
Client Sessions en el menú de la izquierda.Esta vista nos permite ver las sesiones del front-end de nuestra tienda de comercio electrónico. Las sesiones permanecen como Anonymous hasta que los usuarios pasan por caja e intentan completar una compra.Ten en cuenta que algunas sesiones con correos electrónicos tienen un error asociado, lo que podría confirmar los informes de transacciones fallidas.Selecciona una traza con un fallo y un correo electrónico asociado. La vista siguiente nos permite reproducir la sesión del usuario y revisar el problema. Pulsa play para ver la sesión.La reproducción muestra al usuario navegando por el sitio y añadiendo artículos al carrito. Si quieres, puedes avanzar hasta un punto posterior de la sesión donde intenta completar el pago.El usuario no pudo realizar el pedido, sin que hubiera ningún error evidente. Desplázate hasta la parte inferior del panel izquierdo, que contiene los eventos de red y de consola del navegador del usuario. Verás que se produjo un error 500 al hacer una llamada a /api/checkout.Selecciona este error 500. Ni Overview ni Column Values indican el origen del problema, más allá de que el error es inesperado, lo que provoca un Internal Error.6
Explorar trazas
Ve a la pestaña
Trace para ver la traza distribuida completa.Desplázate por la traza hasta ver el origen del error: el span del servicio checkout. Selecciona el span del servicio Payment.Selecciona la pestaña Column Values y desplázate hacia abajo. Podemos ver que el problema está relacionado con una caché llena.Al volver hacia arriba en la traza, vemos que los logs están correlacionados con el span gracias a la configuración anterior. Esto aporta más contexto.Hemos comprobado que se está llenando una caché en el servicio Payment, lo que impide que los pagos se completen.7
Explorar logs
Para obtener más detalles, podemos volver a
Search:Selecciona Logs en las fuentes y aplica un filtro al servicio payment.Podemos ver que, aunque el problema es reciente, el número de pagos afectados es elevado. Además, parece que una caché relacionada con los pagos con Visa está causando problemas.8
Métricas del gráfico
Aunque claramente se ha introducido un error en el código, podemos usar métricas para confirmar el tamaño de la caché. Ve a la vista
Chart Explorer.Selecciona Metrics como fuente de datos. Completa el generador de gráficos para representar el Maximum de visa_validation_cache.size (Gauge) y pulsa el botón play. La caché fue aumentando claramente hasta alcanzar un tamaño máximo, tras lo cual se generaron errores.