Aide de Tableau Cloud

Veiller à l’affichage optimal des vues pour les utilisateurs est une partie importante du travail d’administrateur. À l’aide du journal d’activité, vous pouvez identifier les problèmes de performances en temps réel et résoudre les problèmes qui surviennent afin d’assurer le bon fonctionnement du site.

Cette rubrique décrit comment les administrateurs peuvent utiliser le type d’événement vizql_http_request pour comprendre les temps de chargement des vues et résoudre les goulots d’étranglement des performances.

Conditions préalables

Pour surveiller les temps de chargement des vues, les données de votre journal d’activité doivent être dans un format structuré et interrogeable. Assurez-vous que ces conditions préalables sont remplies avant de continuer :

• Configuration du journal d’activité : Configurez le journal d’activité de manière à écrire les fichiers journaux dans votre compartiment AWS S3.

• Importation de données : Importez les fichiers journaux générés par le journal d’activité dans un outil de surveillance, tel que Splunk ou Amazon EventBridge. Vous pouvez également les importer dans un entrepôt de données cloud tel que Snowflake ou Google BigQuery. L’objectif est d’obtenir vos données dans un format que vous pouvez facilement interroger et analyser.

Remarque : le processus d’importation des données de votre journal d’activité dans un magasin de données n’est pas abordé dans cette rubrique. Pour obtenir des instructions détaillées, reportez-vous à la section Configurer le journal d’activité et à la documentation de la plate-forme de données choisie.

Prise en main

Par où commencer ? Vous pouvez surveiller les performances des vues en vous concentrant sur le chargement initial d’un tableau de bord ou d’une vue, ce que l’on appelle l’événement « session bootstrap ». Cet événement capture généralement le temps nécessaire au rendu de la vue, vous donnant ainsi une indication claire de la durée de chargement.

Pour surveiller les événements bootstrap :

1. Ouvrez l’outil de surveillance que vous avez configuré, tel que Splunk ou Amazon EventBridge.

2. Filtrez sur ces valeurs :

   1. eventType = vizql_http_request.

   2. endpointName = bootstrapSession.

   3. eventOutcome = success.

3. Dans les résultats, recherchez le champ duration.

Le champ de durée des événements vizql_http_request représente la durée de l’opération, en millisecondes. Vous pouvez ainsi suivre et analyser les temps de chargement initiaux de vos vues Tableau.

Conseil : Vous ne savez pas par où commencer ? Utilisez le tableau de bord « Temps de chargement des tableaux de bord » inclus dans le classeur Starter Admin Insights. Ce tableau de bord affiche les temps de chargement et les évaluations de performances du contenu, vous aidant à identifier les vues problématiques. Vous pouvez ensuite utiliser le journal d’activité pour voir quels utilisateurs rencontrent des problèmes en temps réel et comment les révisions des classeurs peuvent avoir un impact sur les performances. Pour plus d’informations, consultez Utiliser la Console Administrateur pour créer des vues personnalisées.

Surveillance en vue de détecter les erreurs

Outre les performances, vous pouvez utiliser les données de session bootstrap pour voir si les utilisateurs rencontrent des erreurs lors de l’affichage du contenu. Pour voir ces erreurs, recherchez les champs eventOutcome et eventOutcomeReason. Ces champs sont utiles pour configurer des alertes de surveillance et fournir un point de départ pour les enquêtes. Par exemple, si les utilisateurs signalent une erreur lors de l’affichage d’un tableau de bord, vous pouvez consulter la session bootstrap pour consulter l’historique des interactions utilisateur. Cela vous permet d’identifier ce qui a déclenché l’erreur et de déterminer quand le problème a commencé. Il est important de connaître ces informations pour résoudre la cause première des problèmes.

• eventOutcome : Ce champ enregistre la catégorie générale réussite/échec de chaque opération (réussite, échec, client_error ou internal_error).

• eventOutcomeReason : Ce champ fournit des informations plus détaillées sur l’événement, enregistrant souvent le code d’état HTTP qui décrit l’erreur.

Surveillance en vue de détecter les erreurs :

1. Ouvrez l’outil de surveillance que vous avez configuré, tel que Splunk ou Amazon EventBridge.

2. Filtrez sur ces valeurs :

   1. eventType = vizql_http_request.

   2. endpointName = bootstrapSession.

   3. eventOutcome != success.

3. Dans les résultats, consultez l’entrée eventOutcomeReason pour plus de détails sur l’erreur.

Résoudre les problèmes de performances

De nombreux facteurs peuvent contribuer aux problèmes de performance, ce qui les rend difficiles à étudier. Cependant, vous pouvez adopter quelques approches qui simplifieront le processus. Cette section présente une vue d’ensemble des manières courantes de résoudre les problèmes de performances d’un classeur à l’aide de la session bootstrap. Pour commencer, déterminez si le problème est limité à un classeur ou à quelques-uns. Suivez ensuite les instructions fournies dans la section associée..

Résoudre les problèmes liés à un seul classeur

Utilisez ces étapes si le problème de performances concerne un seul classeur.

1. Identifier les révisions du classeur :

   Vérifiez si le problème de performances a été introduit avec une nouvelle révision du classeur. Vous pouvez le faire en examinant l’attribut workbookRevision dans la session bootstrap. Ce processus peut nécessiter de comparer les visites de l’utilisateur aux versions précédentes du classeur.

   Si une nouvelle révision est à l’origine du problème de performances, contactez le propriétaire du classeur et collaborez avec lui pour améliorer la conception.

2. Rechercher des problèmes spécifiques à un utilisateur :

   Si le problème de performances n’est pas spécifique à une révision de classeur, déterminez s’il affecte seulement certains utilisateurs. Vous pouvez le faire en examinant les attributs requestUri et actorUserLuid dans la session bootstrap. L’attribut requestUri fournit l’URL du classeur ou de la vue consulté(e), et l’attribut actorUserLuid indique l’utilisateur qui accède à la vue. L’utilisation des deux attributs peut vous aider à distinguer des sessions utilisateur individuelles.

   Si le problème est spécifique à l’utilisateur, recherchez les similitudes entre les utilisateurs. Il peut par exemple être dû à une vue personnalisée à laquelle ces utilisateurs accèdent ou à la manière dont ils interagissent avec la vue. Vous devrez analyser l’attribut requestURI pour identifier les vues spécifiques.

3. Vérifier la sécurité au niveau des lignes :

   Si certains utilisateurs rencontrent des problèmes de performances et que les vues personnalisées n’en sont pas la cause, le problème peut être lié à la sécurité au niveau des lignes (RLS) implémentée dans le classeur. La sécurité au niveau des lignes peut avoir un impact significatif sur les performances, en particulier si les règles de sécurité sont complexes ou si l’ensemble de données est volumineux. Pour plus d’informations, consultez Présentation des options de sécurité au niveau des lignes dans Tableau.

Résoudre les problèmes liés à un sous-ensemble de classeurs

Utilisez ces étapes si le problème de performances concerne un sous-ensemble de classeurs.

1. Identifier les sources de données communes :

   Recherchez les points communs dans les sources de données utilisées par les classeurs concernés.

   Si les classeurs concernés utilisent des connexions en direct à un serveur de base de données ou à un entrepôt de données cloud, il est possible que le problème de performances provienne de la connexion en direct.

   Si les classeurs concernés utilisent des extraits de données, vérifiez s’ils ont été mis à jour récemment. Vous pouvez utiliser le type d’événement hist_publish_datasource dans le journal d’activité ou la source de données Événements TS dans la Console Administrateur pour identifier les changements récents.

2. Vérifier les performances de la source de données :

   Pour les connexions en direct, surveillez les performances du serveur de base de données ou de l’entrepôt de données cloud. Recherchez les changements ou problèmes récents côté serveur. Cette étape est effectuée en dehors de Tableau.

   Pour les sources de données extraites, passez en revue le processus d’extraction et toutes les mises à jour récentes. Assurez-vous que l’extraction est optimisée et que les données ne sont pas excessivement volumineuses ou complexes. Pour plus d’informations, consultez Créer des extraits sur le Web.

Considérations importantes

L’utilisation du journal d’activité pour surveiller les temps de chargement des vues est un excellent moyen de garder le contrôle des performances des tableaux de bord et de l’engagement des utilisateurs. Toutefois, toutes les opérations de rendu de tableau de bord ou de vue ne génèrent pas un événement de session bootstrap. Voici quelques scénarios dans lesquels un événement de session bootstrap ne sera pas nécessaire :

• Tableaux de bord mis en cache : En cas de récupération du tableau de bord ou de la vue à partir d’un cache précédent.

• Changement d’onglet : Si un utilisateur change d’onglet dans le même classeur et que le contenu du nouvel onglet est chargé ou mis en cache.

En utilisant le type d’événement bootstrapSession et en vous concentrant sur les événements vizql_http_request, vous pouvez obtenir des informations précieuses sur les performances des vues et résoudre les problèmes de manière proactive.