Variaciones en los datosComo el conjunto de datos se vuelve a reproducir cada día desde la medianoche, las visualizaciones exactas pueden variar según el momento en que explores la demo.
Escenario de Demo
Demo de OpenTelemetry
Arquitectura de la demo
Pasos de la demo
Conéctese al servidor de demostración
Modo solo localEste paso puede omitirse si hizo clic en
Connect to Demo Server al desplegar en el modo local. Si usa este modo, las fuentes tendrán el prefijo Demo_, por ejemplo, Demo_LogsTeam Settings y haga clic en Edit en la Local Connection:Cambie el nombre de la conexión a Demo y complete el siguiente formulario con los datos de conexión del servidor de demostración:Connection Name:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: Déjelo vacío
Modifica las fuentes
Modo solo localPuedes omitir este paso si hiciste clic en
Connect to Demo Server al desplegar en modo local. Si usas este modo, las fuentes tendrán el prefijo Demo_; por ejemplo, Demo_LogsSources y modifica cada una de las fuentes (Logs, Traces, Metrics y Sessions) para que usen la base de datos otel_v2.Puede que tengas que recargar la página para asegurarte de que en cada fuente se muestre la lista completa de bases de datos.
Ajuste del intervalo de tiempo
Ajuste el intervalo para mostrar todos los datos del1 day anterior usando el selector de tiempo de la esquina superior derecha.Puede ver una pequeña diferencia en el número de errores en el gráfico de barras de la vista general, con un pequeño aumento en rojo en varias barras consecutivas.La ubicación de las barras variará en función de cuándo consulte el conjunto de datos.
Filtrar errores
Para resaltar los errores, usa el filtroSeverityText y selecciona error para mostrar solo las entradas con nivel de error.El error debería verse más claramente:Identifica los patrones de error
Con la función Clustering de HyperDX, puedes identificar automáticamente los errores y agruparlos en patrones significativos. Esto agiliza el análisis al trabajar con grandes volúmenes de logs y trazas. Para usarla, seleccionaEvent Patterns en el menú Analysis Mode del panel izquierdo.Los clústeres de errores revelan problemas relacionados con pagos fallidos, incluido un patrón llamado Failed to place order. Otros clústeres también indican problemas al cobrar tarjetas y cachés saturadas.Ten en cuenta que estos clústeres de errores probablemente se originan en distintos servicios.Explora un patrón de error
Haz clic en los clústeres de errores más evidentes que se correlacionan con el problema reportado de que los usuarios pueden completar pagos:Failed to place order.Esto mostrará una lista de todas las ocurrencias de este error asociadas al servicio frontend:Selecciona cualquiera de los errores resultantes. Los metadatos de los logs se mostrarán en detalle. Al revisar tanto Overview como Column Values, se aprecia un problema con el cobro de las tarjetas debido a una caché:failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.Explora la infraestructura
Hemos identificado un error relacionado con la caché que probablemente esté causando fallos en los pagos. Aún tenemos que identificar en qué punto se origina este problema dentro de nuestra arquitectura de microservicios.Dado el problema con la caché, tiene sentido investigar la infraestructura subyacente: ¿podría haber un problema de memoria en los pods asociados? En ClickStack, los logs y las métricas están unificados y se muestran en contexto, lo que facilita detectar rápidamente la causa raíz.Selecciona la pestañaInfrastructure para ver las métricas asociadas a los pods subyacentes del servicio frontend y amplía el intervalo de tiempo a 1d:El problema no parece estar relacionado con la infraestructura: ninguna métrica ha cambiado de forma apreciable en ese período, ni antes ni después del error. Cierra la pestaña Infrastructure.Explorar una traza
En ClickStack, las trazas también se correlacionan automáticamente tanto con los logs como con las métricas. Exploremos la traza vinculada al log seleccionado para identificar el servicio responsable.SeleccionaTrace para visualizar la traza asociada. Al desplazarnos hacia abajo en la vista siguiente, podemos ver cómo HyperDX visualiza la traza distribuida a través de los microservicios, conectando los spans de cada servicio. Un pago implica claramente varios microservicios, incluidos los que realizan el checkout y las conversiones de divisas.Al desplazarnos hasta la parte inferior de la vista, podemos ver que el servicio payment está causando el error, que a su vez se propaga por la cadena de llamadas.Búsqueda de trazas
Hemos determinado que los usuarios no consiguen completar las compras debido a un problema de caché en el servicio de pagos. Exploremos las trazas de este servicio con más detalle para ver si podemos obtener más información sobre la causa raíz.Cambia a la vista principal deSearch seleccionando Search. Cambia la fuente de datos a Traces y selecciona la vista Results table. Asegúrate de que el intervalo de tiempo siga configurado en el último día.Esta vista muestra todas las trazas del último día. Sabemos que el problema se origina en nuestro servicio de pagos, así que aplica el filtro payment en ServiceName.Si aplicamos la agrupación de eventos a las trazas seleccionando Event Patterns, podremos ver de inmediato el problema de caché en el servicio payment.Explora la infraestructura de una traza
Cambia a la vista de resultados haciendo clic enResults table. Filtra los errores con el filtro StatusCode y el valor Error.Selecciona el error Error: Visa cache full: cannot add new item., cambia a la pestaña Infrastructure y amplía el intervalo de tiempo a 1d.Al correlacionar las trazas con las métricas, podemos ver que el uso de memoria y CPU aumentó en el servicio payment antes de caer a 0 (algo que podemos atribuir al reinicio de un pod de Kubernetes), lo que sugiere que el problema de caché provocó problemas de recursos. Es razonable esperar que esto haya afectado a los tiempos de finalización de los pagos.Event deltas para una resolución más rápida
Event Deltas ayuda a detectar anomalías al atribuir cambios en el rendimiento o en las tasas de error a subconjuntos específicos de datos, lo que facilita identificar rápidamente la causa raíz.Aunque sabemos que el serviciopayment tiene un problema de caché que está provocando un aumento en el consumo de recursos, todavía no hemos identificado por completo la causa raíz.Vuelve a la vista de la tabla de resultados y selecciona el periodo de tiempo que contiene los errores para limitar los datos. Asegúrate de seleccionar también varias horas anteriores a los errores y, si es posible, posteriores (puede que el problema siga ocurriendo):Elimina el filtro de errores y selecciona Event Deltas en el menú izquierdo Analysis Mode.El panel superior muestra la distribución de los tiempos, con colores que indican la densidad de eventos (número de spans). El subconjunto de eventos fuera de la concentración principal suele ser el que merece la pena investigar.Si seleccionamos los eventos con una duración superior a 1ms y aplicamos el filtro Filter by selection, podemos analizar las diferencias entre los eventos “normales” y el grupo de spans de alta densidad con una duración de ~0ms:Con el análisis realizado sobre el subconjunto de datos, podemos ver que los spans de “background” fuera de la selección son en su mayoría transacciones de Visa, asociadas a respuestas de 0ms debido a errores de caché.Uso de gráficos para obtener más contexto
En ClickStack, podemos crear gráficos con cualquier valor numérico de logs, traces o metrics para tener más contexto.Hemos establecido lo siguiente:- El problema está en el servicio de pagos
- La caché está llena
- Esto provocó un aumento en el consumo de recursos
- El problema impidió que se completaran los pagos con Visa, o al menos hizo que tardaran mucho en completarse.
Selecciona
Chart Explorer en el menú de la izquierda. Completa los siguientes valores para graficar el tiempo que tardan en completarse los pagos:Data Source:TracesMetric:MaximumSQL Column:DurationWhere:ServiceName: paymentTimespan:Last 1 day
Al hacer clic en
▶️, se mostrará cómo el rendimiento de los pagos fue degradándose con el tiempo.Si configuramos Group By como SpanAttributes['app.payment.card_type'] (solo escribe card para autocompletar), podremos ver cómo se degradó el rendimiento del servicio para las transacciones de Visa frente a Mastercard:Ten en cuenta que, una vez que se produce el error, las respuestas vuelven en 0s.Explorar métricas para obtener más contexto
Por último, grafiquemos el tamaño de la caché como una métrica para ver cómo evolucionó con el tiempo y así obtener más contexto.Completa los siguientes valores:Data Source:MetricsMetric:MaximumSQL Column:visa_validation_cache.size (gauge)(solo escribecachepara el autocompletado)Where:ServiceName: paymentGroup By:<empty>
100,000. En Sample Matched Events podemos ver que nuestros errores se correlacionan con el momento en que la caché alcanza este límite y, después de eso, queda registrada con un tamaño de 0, con respuestas que también vuelven en 0s.En resumen, al explorar logs, trazas y, por último, métricas, hemos concluido:- El problema está en el servicio de pagos
- Un cambio en el comportamiento del servicio, probablemente debido a un despliegue, provocó un aumento gradual de una caché de Visa durante un período de 4-5 horas, hasta alcanzar un tamaño máximo de
100,000. - Esto provocó un aumento en el consumo de recursos a medida que la caché crecía, probablemente debido a una implementación deficiente
- A medida que la caché crecía, el rendimiento de los pagos con Visa se degradaba
- Al alcanzar el tamaño máximo, la caché rechazó pagos y reportó un tamaño de
0.
Uso de las sesiones
Las sesiones nos permiten reproducir la experiencia del usuario y ofrecen un registro visual de cómo se produjo un error desde su perspectiva. Aunque normalmente no se utilizan para diagnosticar la causa raíz, son muy útiles para confirmar problemas reportados al equipo de soporte y pueden servir como punto de partida para una investigación más profunda.En HyperDX, las sesiones están vinculadas a trazas y logs, lo que proporciona una visión completa de la causa subyacente.Por ejemplo, si el equipo de soporte proporciona el correo electrónico de un usuario que tuvo un problema con un pago,Ronny.Windler@gmail.com, a menudo es más eficaz empezar por su sesión que buscar directamente en logs o trazas.Ve a la pestaña Client Sessions en el menú de la izquierda y asegúrate de que la fuente de datos esté configurada como Sessions y de que el período de tiempo esté establecido en Last 1 day:Busca SpanAttributes.userEmail: Ronny.Windler para encontrar la sesión de nuestro cliente. Al seleccionar la sesión, verás a la izquierda los eventos del navegador y los spans asociados a la sesión del cliente, mientras que a la derecha se volverá a representar la experiencia del usuario en el navegador:Reproducción de sesiones
Las sesiones pueden reproducirse pulsando el botón ▶️. Cambiar entreHighlighted y All Events permite ajustar el nivel de granularidad de los spans; la primera opción resalta los eventos clave y los errores.Si nos desplazamos hasta la parte inferior de los spans, podemos ver un error 500 asociado a /api/checkout. Al seleccionar el botón ▶️ de este span concreto, la reproducción salta a ese punto de la sesión, lo que nos permite confirmar la experiencia del cliente: el pago simplemente parece no funcionar y no se muestra ningún error.Al seleccionar el span, podemos confirmar que la causa fue un error interno. Al hacer clic en la pestaña Trace y desplazarnos por los spans conectados, podemos confirmar que el cliente efectivamente fue víctima de nuestro problema de caché.