Variations des donnéesComme 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
OpenTelemetry Demo
Architecture de la démonstration
Étapes de la démo
Se connecter au serveur de démonstration
Mode local uniquementCette é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_LogsTeam 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:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: laisser vide
Modifier les sources
Mode local uniquementCette é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_LogsSources 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 du1 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 filtreSeverityText 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électionnezEvent 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’ongletInfrastructure 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électionnezTrace 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électionnantSearch. 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 surResults 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 servicepayment 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:TracesMetric:MaximumSQL Column:DurationWhere:ServiceName: paymentTimespan: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:MetricsMetric:MaximumSQL Column:visa_validation_cache.size (gauge)(tapez simplementcachepour l’autocomplétion)Where:ServiceName: paymentGroup By:<empty>
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 entreHighlighted 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.