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
1
Conectarse al servidor de demostración
Modo solo localEste paso puede omitirse si hiciste clic en
Connect to Demo Server al desplegar en Local Mode. Si usas este modo, las fuentes tendrán el prefijo Demo_, por ejemplo, Demo_Logsconfiguración del equipo y haz clic en Edit para Local Connection:Cambia el nombre de la conexión a Demo y completa el siguiente formulario con estos datos de conexión del servidor de demostración:Connection Name:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: Déjalo vacío
2
Modifica las fuentes
Modo exclusivamente localPuedes omitir este paso si hiciste clic en
Connect to Demo Server al desplegar en Local Mode. 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 aparezca la lista completa de bases de datos.
3
Ajustar el intervalo de tiempo
Ajuste el tiempo para mostrar todos los datos del
1 day anterior con el selector de tiempo de la esquina superior derecha.Puede notar una pequeña diferencia en el número de errores en el gráfico de barras de resumen, con un ligero aumento del color rojo en varias barras consecutivas.La posición de las barras variará según cuándo consulte el conjunto de datos.
4
Filtrar para ver solo errores
Para resaltar los errores, use el filtro
SeverityText y seleccione error para mostrar solo las entradas de nivel de error.El error debería verse más claramente:5
Identifique patrones de error
Con la función Clustering de HyperDX, puedes identificar errores automáticamente y agruparlos en patrones significativos. Esto acelera el análisis al trabajar con grandes volúmenes de logs y trazas. Para usarla, selecciona
Event Patterns en el menú Analysis Mode del panel izquierdo.Las agrupaciones de errores revelan problemas relacionados con pagos fallidos, entre ellos un patrón llamado Failed to place order. Otras agrupaciones también indican problemas al cobrar tarjetas y cachés saturadas.Ten en cuenta que estas agrupaciones de errores probablemente se originan en diferentes servicios.6
Explora un patrón de error
Haz clic en los clústeres de errores más evidentes que se correlacionan con nuestro issue reportado de que los usuarios pueden completar pagos:
Failed to place order.Esto mostrará una lista de todas las ocurrencias de este error asociadas con el 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, todo apunta a un issue con el cargo a las tarjetas debido a la caché:failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.7
Explora la infraestructura
Hemos identificado un error relacionado con la caché que probablemente esté causando fallos en los pagos. Aún necesitamos identificar dónde se origina este problema en nuestra arquitectura de microservicios.Dado el problema de la caché, tiene sentido investigar la infraestructura subyacente; quizá tengamos 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 identificar rápidamente la causa raíz.Selecciona la pestaña
Infrastructure 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 durante ese período, ni antes ni después del error. Cierra la pestaña Infrastructure.8
Explorar una traza
En ClickStack, las traces también se correlacionan automáticamente tanto con los logs como con las métricas. Exploremos la trace vinculada al log seleccionado para identificar el servicio responsable.Selecciona
Trace para visualizar la trace asociada. Al desplazarnos hacia abajo por la vista siguiente, podemos ver cómo HyperDX visualiza la trace distribuida a través de los microservicios, conectando los spans de cada servicio. Un pago claramente implica 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á provocando el error, que a su vez se propaga de vuelta por la cadena de llamadas.9
Buscar trazas
Hemos comprobado que los usuarios no pueden completar las compras debido a un problema de caché en el servicio de pagos. Examinemos las trazas de este servicio con más detalle para ver si podemos identificar mejor la causa raíz.Cambia a la vista principal de Búsqueda seleccionando
Búsqueda. Cambia la fuente de datos a Traces y selecciona la vista Results table. Asegúrate de que el intervalo de tiempo siga cubriendo 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 a ServiceName.Si agrupamos los eventos de las trazas seleccionando Event Patterns, podemos ver de inmediato el problema de caché en el servicio payment.10
Explore la infraestructura asociada a una traza
Cambia a la vista de resultados haciendo clic en
Results 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 trazas con métricas, podemos ver que la memoria y la CPU aumentaron en el servicio payment antes de caer a 0 (podemos atribuirlo al reinicio de un pod de Kubernetes), lo que sugiere que el problema de caché provocó problemas de recursos. Es de esperar que esto haya afectado a los tiempos de finalización de los pagos.11
Event deltas para resolver más rápido
Event Deltas ayudan 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 servicio
payment tiene un problema de caché que provoca un aumento del 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 varias horas antes de los errores y, si es posible, también después (el problema puede seguir ocurriendo):Quita el filtro de errores y selecciona Event Deltas en el menú Analysis Mode de la izquierda.El panel superior muestra la distribución de 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 vale 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 alta densidad de spans con una duración de ~0ms:Con el análisis realizado sobre el subconjunto de datos, podemos ver que los spans de “Fondo” fuera de la selección son en su mayoría transacciones de Visa, asociadas a respuestas de 0ms debido a errores de caché.12
Usar gráficos para tener más contexto
En ClickStack, podemos graficar cualquier valor numérico de logs, trazas o métricas para obtener más contexto.Hemos determinado lo siguiente:
Selecciona
Al hacer clic en
- El problema está en el servicio de pagos
- Una caché está llena
- Esto provocó un aumento en el consumo de recursos
- El problema impidió que los pagos con Visa se completaran, o al menos hizo que tardaran mucho en completarse.
Selecciona
Chart Explorer en el menú de la izquierda. Completa los siguientes valores para graficar, por tipo de tarjeta, 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 fue empeorando el rendimiento de los pagos con el tiempo.Si configuramos Group By como SpanAttributes['app.payment.card_type'] (solo tienes que escribir card para usar el autocompletado), podemos ver cómo el rendimiento del servicio empeoró en las transacciones de Visa en comparación con Mastercard:Ten en cuenta que, una vez que se produce el error, las respuestas pasan a devolverse en 0s.13
Más contexto para explorar métricas
Por último, representemos el tamaño de la caché como una métrica para ver cómo evolucionó a lo largo del tiempo y obtener así 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 los Sample Matched Events podemos ver que nuestros errores se correlacionan con el momento en que la caché alcanza este límite y, a partir de ahí, se registra con un tamaño de 0, mientras que las respuestas también pasan a devolverse en 0s.En resumen, al explorar logs, trazas y, por último, métricas, hemos llegado a las siguientes conclusiones:- 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 h, 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 degradó
- Al alcanzar el tamaño máximo, la caché rechazó pagos e informó que su tamaño era
0.
14
Uso de 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 usan para diagnosticar la causa raíz, son valiosas 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 traces 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 en lugar de buscar directamente en los logs o traces.Ve a la pestaña Client Sessions desde el menú de la izquierda y asegúrate de que la fuente de datos esté configurada como Sessions y el período de tiempo como Last 1 day:Busca SpanAttributes.userEmail: Ronny.Windler para encontrar la sesión de nuestro cliente. Al seleccionar la sesión, a la izquierda se mostrarán los eventos del navegador y los spans asociados a la sesión del cliente, mientras que a la derecha se volverá a mostrar la experiencia del usuario en el navegador:15
Reproducción de sesiones
Las sesiones se pueden reproducir pulsando el botón ▶️. Alternar entre
Highlighted y All Events permite ver distintos niveles de granularidad de los spans; la primera opción destaca 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 no funciona y no se muestra ningún error.Al seleccionar el span, podemos confirmar que se debió a 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é.