> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Jeu de données de démonstration distant
> Prise en main de ClickStack avec un jeu de données de démonstration distant
export const Image = ({img, alt, size}) => {
return
;
};
**Le guide suivant suppose que vous avez déployé Open Source ClickStack à l’aide des [instructions pour l’image tout-en-un](/fr/clickstack/getting-started/oss) ou de [Local Mode Only](/fr/clickstack/deployment/local-mode-only), et créé l’utilisateur initial. Vous pouvez aussi ignorer toute configuration locale et simplement vous connecter à notre démo ClickStack hébergée [play-clickstack.clickhouse.com](https://play-clickstack.clickhouse.com), qui utilise ce jeu de données.**
Ce guide s’appuie sur un jeu de données d’exemple hébergé sur le ClickHouse playground public [sql.clickhouse.com](https://sql.clickhouse.com), auquel vous pouvez vous connecter depuis votre déploiement local de ClickStack.
**Non pris en charge avec Managed ClickStack**
Les bases de données distantes ne sont pas prises en charge avec Managed ClickStack. Ce jeu de données n’est donc pas pris en charge.
Il contient environ 40 heures de données issues de la version ClickHouse de la démo officielle OpenTelemetry (OTel). Les données sont rejouées chaque nuit, avec des horodatages ajustés à la fenêtre temporelle actuelle, ce qui permet aux utilisateurs d’explorer le comportement du système à l’aide des logs, traces et métriques intégrés à HyperDX.
**Variations des données**
Comme le jeu de données est rejoué chaque jour à partir de minuit, les visualisations exactes peuvent varier selon le moment où vous explorez la démo.
## Scénario de démonstration
Dans cette démonstration, nous examinons un incident touchant un site e-commerce qui vend des télescopes et des accessoires associés.
L’équipe de support client a signalé que des utilisateurs rencontrent des difficultés à finaliser leurs paiements au moment du passage en caisse. Le problème a été remonté à l’équipe Site Reliability Engineering (SRE) pour enquête.
À l’aide d’HyperDX, l’équipe SRE analysera les logs, les traces et les métriques afin de diagnostiquer et de résoudre le problème, puis examinera les données de session pour vérifier si ses conclusions correspondent au comportement réel des utilisateurs.
## OpenTelemetry Demo
Cette démonstration utilise un [fork maintenu par ClickStack](https://github.com/ClickHouse/opentelemetry-demo) de la démo OpenTelemetry officielle.
### Architecture de la démonstration
La démonstration se compose de microservices écrits dans différents langages de programmation, qui communiquent entre eux via gRPC et HTTP, ainsi que d’un générateur de charge utilisant Locust pour simuler le trafic des utilisateurs. Le code source original de cette démonstration a été modifié pour utiliser l’[instrumentation ClickStack](/fr/clickstack/ingesting-data/sdks/index).
*Crédit : [https://opentelemetry.io/docs/demo/architecture/](https://opentelemetry.io/docs/demo/architecture/)*
Vous trouverez plus de détails sur cette démonstration dans :
* [la documentation d’OpenTelemetry](https://opentelemetry.io/docs/demo/)
* [le fork maintenu par ClickStack](https://github.com/ClickHouse/opentelemetry-demo)
## Étapes de la démo
**Nous avons instrumenté cette démo avec les [ClickStack SDKs](/fr/clickstack/ingesting-data/sdks/index), en déployant les services sur Kubernetes, dont les métriques et les logs ont également été collectés.**
### Se connecter au serveur de démonstration
**Mode local uniquement**
Cette étape peut être sautée si vous avez cliqué sur `Connect to Demo Server` lors du déploiement en mode local. Si vous utilisez ce mode, les sources seront préfixées par `Demo_`, par exemple `Demo_Logs`
Accédez à `Team Settings`, puis cliquez sur `Edit` pour `Local Connection` :
Renommez la connexion en `Demo`, puis renseignez le formulaire suivant avec les informations de connexion du serveur de démonstration :
* `Connection Name`: `Demo`
* `Host`: `https://sql-clickhouse.clickhouse.com`
* `Username`: `otel_demo`
* `Password`: laisser vide
### Modifier les sources
**Mode local uniquement**
Cette étape peut être ignorée si vous avez cliqué sur `Connect to Demo Server` lors du déploiement en mode local. Si vous utilisez ce mode, les sources porteront le préfixe `Demo_`, par exemple `Demo_Logs`
Remontez jusqu’à `Sources` et modifiez chacune des sources — `Logs`, `Traces`, `Metrics` et `Sessions` — pour utiliser la base de données `otel_v2`.
Il se peut que vous deviez recharger la page pour vous assurer que la liste complète des bases de données s’affiche dans chaque source.
### Ajuster la période
Ajustez la période pour afficher toutes les données du `1 day` précédent à l’aide du sélecteur de temps en haut à droite.
Vous remarquerez peut-être une légère différence dans le nombre d’erreurs sur le graphique à barres de l’aperçu, avec une légère augmentation du rouge sur plusieurs barres consécutives.
L’emplacement des barres variera selon le moment où vous interrogez le jeu de données.
### Filtrer pour n’afficher que les erreurs
Pour mettre en évidence les occurrences d’erreurs, utilisez le filtre `SeverityText` et sélectionnez `error` pour n’afficher que les entrées de niveau erreur.
L’erreur devrait être plus visible :
### Identifier les schémas d’erreur
Grâce à la fonctionnalité de clustering d’HyperDX, vous pouvez identifier automatiquement les erreurs et les regrouper en schémas significatifs. Cela accélère l’analyse lorsqu’il faut traiter de grands volumes de logs et de traces. Pour l’utiliser, sélectionnez `Event Patterns` dans le menu `Analysis Mode` du panneau de gauche.
Les clusters d’erreurs révèlent des problèmes liés à des échecs de paiement, notamment un schéma nommé `Failed to place order`. D’autres clusters indiquent également des problèmes de débit des cartes et des caches saturés.
Notez que ces clusters d’erreurs proviennent probablement de services différents.
### Explorer un motif d’erreur
Cliquez sur les clusters d’erreurs les plus évidents, qui correspondent au problème signalé concernant la possibilité pour les utilisateurs de finaliser des paiements : `Failed to place order`.
Cela affichera la liste de toutes les occurrences de cette erreur associées au service `frontend` :
Sélectionnez l’une des erreurs obtenues. Les métadonnées des logs s’afficheront en détail. En parcourant `Overview` et `Column Values`, on constate un problème de débit des cartes dû au cache :
`failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.`
### Explorer l’infrastructure
Nous avons identifié une erreur liée au cache qui est probablement à l’origine des échecs de paiement. Nous devons encore déterminer d’où vient ce problème dans notre architecture de microservices.
Compte tenu du problème de cache, il est logique d’examiner l’infrastructure sous-jacente — nous avons peut-être un problème de mémoire dans les pods concernés ? Dans ClickStack, les logs et les métriques sont unifiés et affichés dans leur contexte, ce qui facilite l’identification rapide de la cause racine.
Sélectionnez l’onglet `Infrastructure` pour afficher les métriques associées aux pods sous-jacents du service `frontend`, puis élargissez la plage temporelle à `1d` :
Le problème ne semble pas lié à l’infrastructure — aucune métrique n’a sensiblement changé sur cette période, ni avant ni après l’erreur. Fermez l’onglet Infrastructure.
### Explorer une trace
Dans ClickStack, les traces sont également corrélées automatiquement aux logs comme aux métriques. Explorons la trace liée au log sélectionné afin d’identifier le service responsable.
Sélectionnez `Trace` pour visualiser la trace associée. En faisant défiler la vue vers le bas, nous pouvons voir comment HyperDX visualise la trace distribuée à travers les microservices, en reliant les spans de chaque service. Un paiement implique clairement plusieurs microservices, notamment ceux qui gèrent le paiement et la conversion de devises.
En faisant défiler jusqu’en bas de la vue, nous pouvons voir que le service `payment` est à l’origine de l’erreur, qui se propage ensuite en remontant la chaîne d’appels.
### Recherche de traces
Nous avons établi que les utilisateurs ne parviennent pas à finaliser leurs achats en raison d’un problème de cache dans le service de paiement. Examinons plus en détail les traces de ce service pour voir si nous pouvons en apprendre davantage sur la cause profonde.
Accédez à la vue principale Search en sélectionnant `Search`. Sélectionnez `Traces` comme source de données et choisissez la vue `Results table`. **Assurez-vous que la période est toujours réglée sur le dernier jour.**
Cette vue affiche toutes les traces du dernier jour. Nous savons que le problème provient de notre service de paiement, alors appliquez le filtre `payment` à `ServiceName`.
Si nous appliquons le regroupement d’événements aux traces en sélectionnant `Event Patterns`, nous voyons immédiatement notre problème de cache avec le service `payment`.
### Explorer l’infrastructure d’une trace
Passez à la vue des résultats en cliquant sur `Results table`. Filtrez les erreurs à l’aide du filtre `StatusCode` et de la valeur `Error`.
Sélectionnez une erreur `Error: Visa cache full: cannot add new item.`, puis passez à l’onglet `Infrastructure` et élargissez la période à `1d`.
En corrélant les traces avec les métriques, on constate que la mémoire et le CPU ont augmenté pour le service `payment`, avant de retomber à `0` (ce que l’on peut attribuer à un redémarrage de pod), ce qui laisse penser que le problème de cache a entraîné des problèmes de ressources. On peut donc s’attendre à un impact sur les temps de traitement des paiements.
### Event Deltas pour une résolution plus rapide
Event Deltas aide à faire ressortir les anomalies en attribuant les changements de performances ou de taux d’erreur à des sous-ensembles de données spécifiques, ce qui permet d’identifier plus rapidement la cause racine.
Bien que nous sachions que le service `payment` a un problème de cache, entraînant une hausse de la consommation de ressources, nous n’avons pas encore complètement identifié la cause racine.
Revenez à la vue du tableau de résultats et sélectionnez la période contenant les erreurs afin de limiter les données. Veillez à sélectionner plusieurs heures avant les erreurs et, si possible, après celles-ci (le problème est peut-être toujours en cours) :
Supprimez le filtre sur les erreurs et sélectionnez `Event Deltas` dans le menu `Analysis Mode` à gauche.
Le panneau supérieur montre la distribution des durées, les couleurs indiquant la densité des événements (nombre de spans). Les sous-ensembles d’événements situés en dehors de la zone de concentration principale sont généralement ceux qui méritent d’être examinés.
Si nous sélectionnons les événements dont la durée est supérieure à `1ms` et appliquons le filtre `Filter by selection`, nous pouvons analyser les différences entre les événements "normaux" et le groupe à forte densité de spans d’une durée d’environ 0ms :
En effectuant l’analyse sur ce sous-ensemble de données, nous pouvons voir que les spans de "background" en dehors de la sélection correspondent majoritairement à des transactions Visa, associées à des réponses de 0ms en raison d’erreurs de cache.
### Utiliser des graphiques pour plus de contexte
Dans ClickStack, nous pouvons représenter sous forme de graphique n'importe quelle valeur numérique issue des logs, des traces ou des métriques afin d'obtenir plus de contexte.
Nous avons établi ce qui suit :
* Le problème se situe au niveau du service de paiement
* Un cache est saturé
* Cela a entraîné une hausse de la consommation de ressources
* Le problème a empêché les paiements Visa d'aboutir, ou du moins les a fortement ralentis.
Sélectionnez `Chart Explorer` dans le menu de gauche. Renseignez les valeurs suivantes pour représenter sous forme de graphique le temps nécessaire à l'aboutissement des paiements par type de carte :
* `Data Source`: `Traces`
* `Metric`: `Maximum`
* `SQL Column`: `Duration`
* `Where`: `ServiceName: payment`
* `Timespan`: `Last 1 day`
En cliquant sur `▶️`, vous verrez comment les performances des paiements se sont dégradées au fil du temps.
Si nous définissons `Group By` sur `SpanAttributes['app.payment.card_type']` (saisissez simplement `card` pour utiliser l'autocomplétion), nous pouvons voir comment les performances du service se sont dégradées pour les transactions Visa par rapport à Mastercard :
Notez qu'une fois l'erreur survenue, les réponses sont renvoyées en `0s`.
### Explorer davantage les métriques pour obtenir plus de contexte
Enfin, traçons la taille du cache comme métrique pour voir comment elle a évolué au fil du temps, afin d’obtenir davantage de contexte.
Renseignez les valeurs suivantes :
* `Data Source`: `Metrics`
* `Metric`: `Maximum`
* `SQL Column`: `visa_validation_cache.size (gauge)` (tapez simplement `cache` pour l’autocomplétion)
* `Where`: `ServiceName: payment`
* `Group By`: ``
Nous pouvons voir comment la taille du cache a augmenté sur une période de 4 à 5 heures (probablement après un déploiement logiciel) avant d’atteindre une taille maximale de `100,000`. Dans `Sample Matched Events`, nous pouvons constater que nos erreurs sont corrélées au moment où le cache atteint cette limite, après quoi il est enregistré avec une taille de `0`, les réponses étant elles aussi renvoyées en `0s`.
En résumé, en explorant les logs, les traces et enfin les métriques, nous avons conclu que :
* Le problème se situe au niveau du service de paiement
* Un changement dans le comportement du service, probablement dû à un déploiement, a entraîné une augmentation progressive d’un cache Visa sur une période de 4 à 5 heures, jusqu’à atteindre une taille maximale de `100,000`.
* Cela a entraîné une augmentation de la consommation de ressources à mesure que le cache grossissait, probablement en raison d’une implémentation peu efficace
* À mesure que le cache augmentait, les performances des paiements Visa se dégradaient
* Une fois la taille maximale atteinte, le cache a rejeté les paiements et a signalé une taille de `0`.
### Utilisation des sessions
Les sessions permettent de rejouer l’expérience utilisateur et d’obtenir une vue visuelle de la façon dont une erreur s’est produite du point de vue de l’utilisateur. Bien qu’elles ne servent généralement pas à diagnostiquer la cause profonde, elles sont précieuses pour confirmer les problèmes signalés au support client et peuvent constituer un point de départ pour une investigation plus approfondie.
Dans HyperDX, les sessions sont liées aux traces et aux logs, ce qui offre une vue complète de la cause sous-jacente.
Par exemple, si l’équipe de support fournit l’adresse e-mail d’un utilisateur ayant rencontré un problème de paiement, `Ronny.Windler@gmail.com`, il est souvent plus efficace de commencer par sa session plutôt que de rechercher directement dans les logs ou les traces.
Accédez à l’onglet `Client Sessions` dans le menu de gauche, puis assurez-vous que la source de données est définie sur `Sessions` et que la période est définie sur `Last 1 day` :
Recherchez `SpanAttributes.userEmail: Ronny.Windler` pour trouver la session de notre client. En sélectionnant la session, vous verrez à gauche les événements du navigateur et les spans associés à la session du client, tandis que l’expérience de navigation de l’utilisateur sera reconstituée à droite :
### Rejouer des sessions
Les sessions peuvent être rejouées en appuyant sur le bouton ▶️. Basculer entre `Highlighted` et `All Events` permet d’obtenir différents niveaux de granularité des spans, le premier mettant en évidence les événements clés et les erreurs.
Si nous faisons défiler jusqu’en bas des spans, nous pouvons voir une erreur `500` associée à `/api/checkout`. En sélectionnant le bouton ▶️ pour ce span précis, la relecture est déplacée à ce point de la session, ce qui nous permet de confirmer l’expérience du client : le paiement semble tout simplement ne pas fonctionner, sans qu’aucune erreur ne s’affiche.
En sélectionnant le span, nous pouvons confirmer que cela est dû à une erreur interne. En cliquant sur l’onglet `Trace` et en faisant défiler les spans associés, nous pouvons confirmer que le client a bien été victime de notre problème de cache.
Cette démo vous guide à travers un incident réel de paiements en échec dans une application d’e-commerce et montre comment ClickStack aide à en identifier les causes profondes grâce à une vue unifiée des logs, des traces, des métriques et des session replays - explorez nos [autres guides de prise en main](/fr/clickstack/example-datasets/index) pour approfondir des fonctionnalités spécifiques.