> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Dataset de demostración remoto
> Primeros pasos con ClickStack y un dataset de demostración remoto
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
**La siguiente guía asume que has implementado Open Source ClickStack siguiendo las [instrucciones para la imagen todo en uno](/docs/es/clickstack/getting-started/oss) o [Local Mode Only](/docs/es/clickstack/deployment/local-mode-only), y que ya has completado la creación inicial del usuario. Como alternativa, puedes omitir toda la configuración local y conectarte directamente a nuestra demo alojada de ClickStack en [play-clickstack.clickhouse.com](https://play-clickstack.clickhouse.com), que utiliza este conjunto de datos.**
Esta guía utiliza un conjunto de datos de muestra alojado en el ClickHouse playground público en [sql.clickhouse.com](https://sql.clickhouse.com), al que puedes conectarte desde tu implementación local de ClickStack.
**No compatible con Managed ClickStack**
Las bases de datos remotas no son compatibles cuando se usa Managed ClickStack. Por lo tanto, este conjunto de datos tampoco es compatible.
Contiene aproximadamente 40 horas de datos capturados de la versión para ClickHouse de la demo oficial de OpenTelemetry (OTel). Los datos se reproducen cada noche con las marcas de tiempo ajustadas a la ventana temporal actual, lo que permite a los usuarios explorar el comportamiento del sistema mediante los logs, las trazas y las métricas integrados en HyperDX.
**Variaciones en los datos**
Como 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
En esta demo, investigamos un incidente relacionado con un sitio web de comercio electrónico que vende telescopios y accesorios.
El equipo de atención al cliente ha informado de que los usuarios están teniendo problemas para completar los pagos al finalizar la compra. El problema se ha escalado al equipo de Site Reliability Engineering (SRE) para investigarlo.
Con HyperDX, el equipo de SRE analizará logs, trazas y métricas para diagnosticar y resolver el problema, y después revisará los datos de la sesión para confirmar si sus conclusiones coinciden con el comportamiento real de los usuarios.
## Demo de OpenTelemetry
Esta demo usa un [fork de la demo oficial de OpenTelemetry mantenido por ClickStack](https://github.com/ClickHouse/opentelemetry-demo).
### Arquitectura de la demo
La demo se compone de microservicios escritos en distintos lenguajes de programación que se comunican entre sí mediante gRPC y HTTP, además de un generador de carga que usa Locust para simular tráfico de usuarios. El código fuente original de esta demo se ha modificado para usar la [instrumentación de ClickStack](/docs/es/clickstack/ingesting-data/sdks/index).
*Crédito: [https://opentelemetry.io/docs/demo/architecture/](https://opentelemetry.io/docs/demo/architecture/)*
Puedes encontrar más detalles sobre la demo en:
* [Documentación de OpenTelemetry](https://opentelemetry.io/docs/demo/)
* [fork mantenido por ClickStack](https://github.com/ClickHouse/opentelemetry-demo)
## Pasos de la demo
**Hemos instrumentado esta demo con [SDKs de ClickStack](/docs/es/clickstack/ingesting-data/sdks/index), con los servicios desplegados en Kubernetes, de los que también se han recopilado métricas y logs.**
**Modo solo local**
Este 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_Logs`
Ve a `configuració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`: `Demo`
* `Host`: `https://sql-clickhouse.clickhouse.com`
* `Username`: `otel_demo`
* `Password`: Déjalo vacío
**Modo exclusivamente local**
Puedes 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_Logs`
Desplázate hacia arriba hasta `Sources` 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.
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.
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:
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.
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.`
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.
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.
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`.
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.
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é.
En ClickStack, podemos graficar cualquier valor numérico de logs, trazas o métricas para obtener más contexto.
Hemos determinado lo siguiente:
* 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`: `Traces`
* `Metric`: `Maximum`
* `SQL Column`: `Duration`
* `Where`: `ServiceName: payment`
* `Timespan`: `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`.
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`: `Metrics`
* `Metric`: `Maximum`
* `SQL Column`: `visa_validation_cache.size (gauge)` (solo escribe `cache` para el autocompletado)
* `Where`: `ServiceName: payment`
* `Group By`: ``
Podemos ver cómo el tamaño de la caché aumentó durante un período de 4-5 h (probablemente después de un despliegue de software) antes de alcanzar un tamaño máximo de `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`.
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:
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é.