> ## 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.
# Logs, traces et métriques d’exemple
> Premiers pas avec ClickStack et un jeu de données d’exemple comprenant des logs, des sessions, des traces et des métriques
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return
;
};
Ce guide présente à la fois ClickStack Open Source et Managed ClickStack à l’aide d’un jeu de données d’exemple.
Le guide suivant suppose que vous avez suivi le [guide de démarrage pour Managed ClickStack](/docs/fr/clickstack/deployment/managed) et que vous avez [noté les identifiants de connexion](/docs/fr/clickstack/getting-started/managed#next-steps).
Sélectionnez le service Managed ClickStack sur la page d’accueil principale de ClickHouse Cloud.
Sélectionnez `ClickStack` dans le menu de gauche pour accéder à la ClickStack UI, où vous serez automatiquement authentifié.
Pour alimenter l’UI avec des données d’exemple, téléchargez le fichier suivant :
[Données d’exemple](https://storage.googleapis.com/hyperdx/sample.tar.gz)
```shell theme={null}
# curl
curl -O https://storage.googleapis.com/hyperdx/sample.tar.gz
# or
# wget https://storage.googleapis.com/hyperdx/sample.tar.gz
```
Ce fichier contient des exemples de logs, de métriques et de traces issus de notre [OpenTelemetry demo](https://github.com/ClickHouse/opentelemetry-demo), une simple boutique en ligne à microservices accessible au public. Copiez ce fichier dans le répertoire de votre choix.
Pour charger ces données, il suffit de les envoyer au point de terminaison HTTP du collector OpenTelemetry (OTel) déployé.
Exécutez la commande suivante pour envoyer les données au collector OTel :
```shell theme={null}
for filename in $(tar -tf sample.tar.gz); do
endpoint="http://localhost:4318/v1/${filename%.json}"
echo "loading ${filename%.json}"
tar -xOf sample.tar.gz "$filename" | while read -r line; do
printf '%s\n' "$line" | curl -s -o /dev/null -X POST "$endpoint" \
-H "Content-Type: application/json" \
-H "authorization: ${CLICKSTACK_API_KEY}" \
--data-binary @-
done
done
```
Cela simule des sources OTLP de logs, de traces et de métriques qui envoient des données à l’OTel collector. En production, ces sources peuvent être des clients pour différents langages, voire d’autres OTel collectors.
De retour dans la vue `Search`, vous devriez voir que les données ont commencé à se charger (ajustez la période sur `Last 1 hour` si les données ne s'affichent pas) :
Le chargement des données prendra quelques minutes. Attendez qu’il soit terminé avant de passer aux étapes suivantes.
Supposons que nous recevions des signalements indiquant que nos utilisateurs rencontrent des problèmes au moment de payer leurs achats. Nous pouvons consulter leur expérience à l’aide des fonctionnalités de session replay d’HyperDX.
Sélectionnez `Client Sessions` dans le menu de gauche.
Cette vue permet de voir les sessions front-end de notre boutique e-commerce. Les sessions restent anonymes jusqu’à ce que les utilisateurs passent en caisse et tentent de finaliser un achat.
Notez que certaines sessions associées à des adresses e-mail comportent une erreur, ce qui peut confirmer les signalements d’échec de transaction.
Sélectionnez une trace présentant un échec et associée à une adresse e-mail. La vue suivante permet de rejouer la session de l’utilisateur et d’examiner son problème. Appuyez sur play pour visionner la session.
La relecture montre l’utilisateur naviguant sur le site et ajoutant des articles à son panier. N’hésitez pas à avancer plus loin dans la session, jusqu’au moment où il tente de finaliser le paiement.
Les erreurs sont annotées en rouge sur la chronologie.
L’utilisateur n’a pas pu passer la commande, sans erreur évidente. Faites défiler jusqu’en bas du panneau de gauche, qui contient les événements réseau et console du navigateur de l’utilisateur. Vous remarquerez qu’une erreur 500 a été renvoyée lors d’un appel à `/api/checkout`.
Sélectionnez cette erreur `500`. Ni l’`Overview` ni les `Column Values` n’indiquent la source du problème, si ce n’est que l’erreur est inattendue et provoque une `Internal Error`.
Accédez à l’onglet `Trace` pour afficher la trace distribuée complète.
Faites défiler la trace vers le bas pour voir l’origine de l’erreur : le span du service `checkout`. Sélectionnez le span du service `Payment`.
Sélectionnez l’onglet `Column Values`, puis faites défiler vers le bas. Nous pouvons voir que le problème est lié à un cache saturé.
En remontant puis en revenant à la trace, nous pouvons voir que les logs sont corrélés au span grâce à notre configuration précédente. Ils fournissent un contexte supplémentaire.
Nous avons établi qu’un cache se remplit dans le service de paiement, ce qui empêche les paiements d’aboutir.
Pour plus de détails, revenons à `Search` :
Sélectionnez `Logs` parmi les sources et appliquez un filtre au service `payment`.
On voit que, même si le problème est récent, le nombre de paiements affectés est élevé. De plus, un cache lié aux paiements Visa semble être à l’origine du problème.
Bien qu'une erreur ait clairement été introduite dans le code, nous pouvons utiliser les métriques pour confirmer la taille du cache. Accédez à la vue `Chart Explorer`.
Sélectionnez `Metrics` comme source de données. Configurez le chart builder pour tracer le `Maximum` de `visa_validation_cache.size (Gauge)`, puis appuyez sur le bouton play. Le cache augmentait clairement jusqu'à atteindre une taille maximale, après quoi des erreurs se sont produites.
L'exemple suivant suppose que vous avez démarré Open Source ClickStack en suivant les [instructions relatives à l'image tout-en-un](/docs/fr/clickstack/getting-started/oss) et que vous vous êtes connecté à l'[instance ClickHouse locale](/docs/fr/clickstack/getting-started/oss#complete-connection-credentials).
Rendez-vous sur [http://localhost:8080](http://localhost:8080) pour accéder à ClickStack UI.
Accédez à [`Team Settings`](http://localhost:8080/team) et copiez la `Ingestion API Key` dans la section `API Keys`. Cette clé API garantit la sécurité de l’ingestion des données via le collecteur OpenTelemetry.
Pour alimenter l’UI avec des données d’exemple, téléchargez le fichier suivant :
[Données d’exemple](https://storage.googleapis.com/hyperdx/sample.tar.gz)
```shell theme={null}
# curl
curl -O https://storage.googleapis.com/hyperdx/sample.tar.gz
# or
# wget https://storage.googleapis.com/hyperdx/sample.tar.gz
```
Ce fichier contient des exemples de logs, de métriques et de traces issus de notre [OpenTelemetry demo](https://github.com/ClickHouse/opentelemetry-demo), une simple boutique en ligne à microservices accessible au public. Copiez ce fichier dans le répertoire de votre choix.
Pour charger ces données, il suffit de les envoyer au point de terminaison HTTP du collector OpenTelemetry (OTel) déployé.
Commencez par exporter la clé API copiée ci-dessus.
```shell theme={null}
# export API key
export CLICKSTACK_API_KEY=
```
Exécutez la commande suivante pour envoyer les données à l’OTel collector :
```shell theme={null}
for filename in $(tar -tf sample.tar.gz); do
endpoint="http://localhost:4318/v1/${filename%.json}"
echo "loading ${filename%.json}"
tar -xOf sample.tar.gz "$filename" | while read -r line; do
printf '%s\n' "$line" | curl -s -o /dev/null -X POST "$endpoint" \
-H "Content-Type: application/json" \
-H "authorization: ${CLICKSTACK_API_KEY}" \
--data-binary @-
done
done
```
Cela simule des sources OTLP de logs, de traces et de métriques qui envoient des données à l’OTel collector. En production, ces sources peuvent être des clients pour différents langages, voire d’autres OTel collectors.
De retour dans la vue `Search`, vous devriez voir que les données ont commencé à se charger (ajustez la période sur `Last 1 hour` si les données ne s'affichent pas) :
Le chargement des données prendra quelques minutes. Attendez qu’il soit terminé avant de passer aux étapes suivantes.
Supposons que nous recevions des signalements indiquant que nos utilisateurs rencontrent des problèmes au moment de payer leurs achats. Nous pouvons consulter leur expérience à l’aide des fonctionnalités de session replay d’HyperDX.
Sélectionnez [`Client Sessions`](http://localhost:8080/sessions?from=1747312320000\&to=1747312920000\&sessionSource=l1324572572) dans le menu de gauche.
Cette vue permet de voir les sessions front-end de notre boutique e-commerce. Les sessions restent anonymes jusqu’à ce que les utilisateurs passent en caisse et tentent de finaliser un achat.
Notez que certaines sessions associées à des adresses e-mail comportent une erreur, ce qui peut confirmer les signalements d’échec de transaction.
Sélectionnez une trace présentant un échec et associée à une adresse e-mail. La vue suivante permet de rejouer la session de l’utilisateur et d’examiner son problème. Appuyez sur play pour visionner la session.
La relecture montre l’utilisateur naviguant sur le site et ajoutant des articles à son panier. N’hésitez pas à avancer plus loin dans la session, jusqu’au moment où il tente de finaliser le paiement.
Les erreurs sont annotées en rouge sur la chronologie.
L’utilisateur n’a pas pu passer la commande, sans erreur évidente. Faites défiler jusqu’en bas du panneau de gauche, qui contient les événements réseau et console du navigateur de l’utilisateur. Vous remarquerez qu’une erreur 500 a été renvoyée lors d’un appel à `/api/checkout`.
Sélectionnez cette erreur `500`. Ni l’`Overview` ni les `Column Values` n’indiquent la source du problème, si ce n’est que l’erreur est inattendue et provoque une `Internal Error`.
Accédez à l’onglet `Trace` pour afficher la trace distribuée complète.
Faites défiler la trace vers le bas pour voir l’origine de l’erreur : le span du service `checkout`. Sélectionnez le span du service `Payment`.
Sélectionnez l’onglet `Column Values`, puis faites défiler vers le bas. Nous pouvons voir que le problème est lié à un cache saturé.
En remontant puis en revenant à la trace, nous pouvons voir que les logs sont corrélés au span grâce à notre configuration précédente. Ils fournissent un contexte supplémentaire.
Nous avons établi qu’un cache se remplit dans le service de paiement, ce qui empêche les paiements d’aboutir.
Pour plus de détails, nous pouvons revenir à la vue [`Search`](http://localhost:8080/search) :
Sélectionnez `Logs` dans les sources et appliquez un filtre sur le service `payment`.
Nous pouvons constater que, bien que le problème soit récent, le nombre de paiements affectés est élevé. De plus, un cache lié aux paiements Visa semble être à l’origine du problème.
Bien qu'une erreur ait clairement été introduite dans le code, nous pouvons utiliser les métriques pour confirmer la taille du cache. Accédez à la vue `Chart Explorer`.
Sélectionnez `Metrics` comme source de données. Configurez le chart builder pour tracer le `Maximum` de `visa_validation_cache.size (Gauge)`, puis appuyez sur le bouton play. Le cache augmentait clairement jusqu'à atteindre une taille maximale, après quoi des erreurs se sont produites.