Aide de Tableau Cloud

Assurer un rendu optimal des vues pour les utilisateurs fait partie des responsabilités clés d’un administrateur. Grâce au journal d’activité, vous pouvez identifier en temps réel les problèmes de performances et résoudre les incidents pour 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 durées de chargement des vues et résoudre les goulots d’étranglement des performances.

Conditions préalables

Pour surveiller les durées de chargement des vues, les données de votre journal d’activité doivent être dans un format structuré et sélectionnable. 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 des 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 dans le nuage tel que Snowflake ou Google BigQuery. L’objectif est d’obtenir vos données dans une mise en forme facile à interroger et à analyser.

Remarque : cette rubrique ne traite pas du processus d’importation des données de votre journal d’activité dans un magasin de données. Pour obtenir des instructions détaillées, consultez la section Configurer le fichier journal d’activité et la documentation de la plateforme de données choisie.

Prise en main

Par où devons-nous commencer? Vous pouvez surveiller les performances des vues en analysant le chargement initial d’un tableau de bord ou d’une vue, appelé l’événement « session d’amorçage ». Cet événement capture généralement la majeure partie du temps nécessaire au rendu de la vue, vous donnant une indication claire de la durée de chargement.

Pour surveiller les événements d’amorçage :

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

2. Filtrez les valeurs ci-après :

   1. eventType = vizql_http_request.

   2. endpointName = bootstrapSession.

   3. eventOutcome = success.

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

Le champ de durée des événements vizql_http_request représente la durée totale de l’opération, en millisecondes. Cela vous aide à suivre et à analyser les durées de chargement initiaux de vos vues Tableau.

Conseil : vous ne savez pas par où commencer? Utilisez le tableau de bord « Durées de chargement du tableau de bord » inclus dans le classeur du Starter Admin Insights. Ce tableau de bord affiche les durées 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 en temps réel quels utilisateurs rencontrent des problèmes et évaluer l’impact des révisions des classeurs sur les performances. Pour plus d’informations, consultez Utiliser Admin Insights pour créer des vues personnalisées.

Surveiller les erreurs

Outre les performances, vous pouvez utiliser les données de la session d’amorçage pour voir si les utilisateurs rencontrent des erreurs lors de la consultation 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 d’amorçage pour retracer l’historique des interactions utilisateur. Cela vous permet aide à identifier qui a déclenché l’erreur et à déterminer à quel moment le problème est apparu. 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 de réussite ou d’échec de chaque opération (réussite, échec, client_error ou internal_error).

• eventOutcomeReason : ce champ fournit des détails sur l’erreur survenue, incluant souvent le code d’état HTTP qui décrit l’erreur.

Pour surveiller les erreurs :

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

2. Filtrez les valeurs ci-après :

   1. eventType = vizql_http_request.

   2. endpointName = bootstrapSession.

   3. eventOutcome != success.

3. Dans la section Résultats, consultez le champ eventOutcomeReason pour obtenir 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 rend leur diagnostic complexe. Cependant, vous pouvez adopter certaines approches pour simplifier le processus. Cette section présente une vue d’ensemble des façons courantes de résoudre les problèmes de performances d’un classeur à l’aide de la session d’amorçage. Pour commencer, déterminez si le problème concerne un classeur spécifique ou plusieurs. Suivez ensuite les instructions dans la section concernée.

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

Procédez comme suit 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 provient d’une révision récente du classeur. Pour ce faire, analysez l’attribut workbookRevision dans la session d’amorçage. Ce processus peut nécessiter de comparer les visites de l’utilisateur avec les versions antérieures 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 optimiser sa conception.

2. Vérifier les problèmes spécifiques à l’utilisateur :

   Si le problème de performances n’est pas lié à une révision de classeur, déterminez s’il affecte seulement certains utilisateurs. Pour ce faire, examinez les attributs requestUri et actorUserLuid dans la session d’amorçage. L’attribut requestUri fournit l’URL du classeur ou de la vue consulté, et l’attribut actorUserLuid indique l’utilisateur qui accède à la vue. L’utilisation combinée de ces attributs permet de différencier les sessions utilisateur individuelles.

   Si le problème est spécifique à un utilisateur, recherchez les similitudes entre les utilisateurs. Par exemple, il pourrait provenir d’une vue personnalisée que ces utilisateurs consultent ou à leurs interactions particulières avec cette vue. Vous devrez analyser l’attribut requestURI pour identifier des vues spécifiques.

3. Examiner la sécurité au niveau des lignes :

   Si certains utilisateurs rencontrent des problèmes de performances qui ne sont pas causés par les vues personnalisées, 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 sensiblement affecter les performances, surtout 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

Procédez comme suit si le problème de performances concerne un sous-ensemble de classeurs.

1. Identifier les sources de données communes :

   Recherchez les points communs entre 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 dans le nuage, 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 Admin Insights pour identifier les modifications récentes.

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 dans le nuage. Vérifiez si des modifications récentes ou des problèmes récents sont survenus côté serveur. Cette étape est effectuée en dehors de Tableau.

   Pour les sources de données de l’extrait, examinez le processus d’extraction et toute mise à jour récente. Vérifiez que l’extraction est optimisée et que les données ne sont pas trop volumineuses ou trop 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 durées de chargement des vues est un excellent moyen de suivre les performances du tableau de bord et l’engagement des utilisateurs. Toutefois, les opérations de rendu de tableau de bord ou de vue ne génèrent pas nécessairement un événement de session d’amorçage. Voici des scénarios où un événement de session de démarrage ne sera pas nécessaire :

• Tableaux de bord mis en cache : si le tableau de bord ou la vue est récupéré depuis 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 en cache.

En utilisant le type d’événement bootstrapSession et en analysant les événements vizql_http_request, vous pouvez obtenir des connaissances précieuses sur les performances des vues et résoudre proactivement les problèmes.