De laadtijden van weergaven monitoren met behulp van het activiteitenlogboek

Ervoor zorgen dat weergaven optimaal worden weergegeven voor gebruikers is een belangrijk onderdeel van het werk van een beheerder. Met het activiteitenlogboek kunt u tegenvallende prestaties in real time identificeren en problemen oplossen die de kop opsteken, zodat de site soepel blijft functioneren.

In dit onderwerp wordt beschreven hoe beheerders met het gebeurtenistype vizql_http_request inzicht kunnen krijgen in de laadtijden van weergaven en knelpunten qua prestaties kunnen oplossen.

Vereisten

Om de laadtijden van weergaven te kunnen monitoren, moeten de data in uw activiteitenlogboek een gestructureerde indeling hebben waarop query's kunnen worden uitgevoerd. Zorg ervoor dat aan de volgende vereisten wordt voldaan voordat u verdergaat:

  • Configuratie van het activiteitenlogboek: stel het activiteitenlogboek in op het schrijven van logbestanden naar uw AWS S3-bucket.

  • Data importeren: importeer de logbestanden die door het activiteitenlogboek zijn gegenereerd in een monitortool, zoals Splunk of Amazon EventBridge. U kunt ze ook importeren in een clouddatawarehouse zoals Snowflake of Google BigQuery. Het doel is om uw data in een indeling te krijgen die u eenvoudig kunt analyseren en waarop u eenvoudig query's kunt uitvoeren.

Opmerking: het proces voor het importeren van de data in uw activiteitenlogboek naar een datastore wordt in dit onderwerp niet behandeld. Raadpleeg Activiteitenlogboek instellen en de documentatie voor uw gekozen dataplatform voor gedetailleerde instructies.

Aan de slag

Waar moeten we beginnen? U kunt de prestaties van een weergave monitoren door u te concentreren op de eerste keer dat een dashboard of weergave wordt geladen, ook wel de 'bootstrapsessie'-gebeurtenis genoemd. Deze gebeurtenis registreert doorgaans het grootste deel van de tijd die nodig is om de weergave te renderen, zodat u een duidelijk beeld krijgt van hoe lang het laden heeft geduurd.

Bootstrap-gebeurtenissen monitoren:

  1. Open de monitortool die u hebt ingesteld, zoals Splunk of Amazon EventBridge.

  2. Filter op de volgende waarden:

    1. eventType = vizql_http_request.

    2. endpointName = bootstrapSession.

    3. eventOutcome = success.

  3. Zoek in de resultaten naar het veld duration.

Het veld Duur voor vizql_http_request-gebeurtenissen geeft aan hoe lang het heeft geduurd om de bewerking te voltooien, uitgedrukt in milliseconden. Zo kunt u de initiële laadtijden van uw Tableau-weergaven volgen en analyseren.

Tip: Weet u niet waar u moet beginnen? Gebruik het dashboard 'Laadtijden van dashboard' in de werkmap Beheerdersinzichten-startpakket. Op dit dashboard worden de laadtijden en prestatiebeoordelingen voor inhoud weergegeven, zodat u problematische weergaven kunt identificeren. Vervolgens kunt u in het activiteitenlogboek in real time zien welke gebruikers problemen ondervinden en welke invloed werkboekrevisies op de prestaties hebben. Zie Beheerdersinzichten gebruiken om aangepaste weergaven te maken voor meer informatie.

Monitoren op fouten

Naast de prestaties kunt u data van de bootstrapsessie ook gebruiken om te zien of gebruikers fouten tegenkomen tijdens het bekijken van inhoud. Zoek naar de velden eventOutcome en eventOutcomeReason om deze fouten te zien. Deze velden zijn handig voor het instellen van monitorwaarschuwingen en fungeren tevens als startpunt voor onderzoeken. Als gebruikers bijvoorbeeld een fout melden bij het weergeven van een dashboard, kunt u de bootstrapsessie raadplegen om historische gebruikersinteracties te bekijken. Zo kunt u achterhalen wat de fout heeft veroorzaakt en wanneer het probleem is begonnen. Deze informatie is belangrijk om de oorzaak van het probleem te kunnen achterhalen.

  • eventOutcome: in dit veld wordt de algemene categorie voor het slagen of mislukken van elke bewerking vastgelegd (success, failure, client_error of internal_errorr).

  • eventOutcomeReason: in dit veld vindt u meer gedetailleerde informatie over wat er is misgegaan. Vaak wordt ook de HTTP-statuscode vastgelegd die de fout beschrijft.

Monitoren op fouten:

  1. Open de monitortool die u hebt ingesteld, zoals Splunk of Amazon EventBridge.

  2. Filter op de volgende waarden:

    1. eventType = vizql_http_request.

    2. endpointName = bootstrapSession.

    3. eventOutcome != success.

  3. Zie eventOutcomeReason in de resultaten voor meer informatie over de fout.

Prestatieproblemen oplossen

Er zijn veel factoren die kunnen bijdragen aan prestatieproblemen en dat maakt het zo lastig om ze te onderzoeken. Er zijn echter een paar manieren om het proces te vereenvoudigen. In dit gedeelte vindt u een overzicht van veelvoorkomende manieren om problemen met de prestaties van werkmappen op te lossen met behulp van de bootstrapsessie. Bepaal om te beginnen of het probleem zich beperkt tot één werkmap of dat het meerdere werkmappen betreft. Volg vervolgens de instructies in het desbetreffende gedeelte.

Problemen met één werkmap oplossen

Gebruik deze stappen als het prestatieprobleem zich voordoet bij één werkmap.

  1. Identificeer werkmaprevisies:

    Controleer of het prestatieprobleem is ontstaan door een nieuwe revisie van de werkmap. U kunt dit doen door het kenmerk workbookRevision in de bootstrapsessie te controleren. Voor dit proces kan het nodig zijn om gebruikersbezoeken te vergelijken met eerdere versies van de werkmap.

    Als een nieuwe revisie de prestatieproblemen veroorzaakt, neem dan contact op met de eigenaar van de werkmap en probeer samen het ontwerp te verbeteren.

  2. Controleer op gebruikerspecifieke problemen:

    Als het prestatieprobleem niet specifiek is voor een werkmaprevisie, bepaal dan of het alleen bepaalde gebruikers treft. U kunt dit doen door de kenmerken requestUri en actorUserLuid in de bootstrapsessie te controleren. Het kenmerk requestUri verschaft de URL van de werkmap of weergave die wordt geopend en het kenmerk actorUserLuid geeft de gebruiker toegang tot de weergave. Door beide te gebruiken, kunt u onderscheid maken tussen sessies van verschillende gebruikers.

    Als het probleem gebruikerspecifiek is, kijk dan of er overeenkomsten zijn tussen gebruikers. Het kan bijvoorbeeld komen door een aangepaste weergave die deze gebruikers openen of door bepaalde manieren waarop ze met de weergave omgaan. U dient het kenmerk requestURI te parseren om de specifieke weergaven te identificeren.

  3. Beveiliging op rijniveau controleren:

    Als bepaalde gebruikers prestatieproblemen ervaren en aangepaste weergaven daar niet de oorzaak van zijn, kan het probleem te maken hebben met de beveiliging op rijniveau die in de werkmap is geïmplementeerd. Beveiliging op rijniveau kan een aanzienlijke impact hebben op de prestaties, vooral als de beveiligingsregels complex zijn of als de dataset groot is. Zie Overzicht van beveiligingsopties op rijniveau in Tableau voor meer informatie.

Problemen met een subset werkmappen oplossen

Gebruik deze stappen als het prestatieprobleem zich voordoet bij een subset van werkmappen.

  1. Identificeer gemeenschappelijke databronnen:

    Zoek naar overeenkomsten in de databronnen die door de betrokken werkmappen worden gebruikt.

    Als de betrokken werkmappen gebruikmaken van liveverbindingen met een databaseserver of clouddatawarehouse, kan het prestatieprobleem te wijten zijn aan de liveverbinding.

    Als de betreffende werkmappen data-extracten gebruiken, controleer dan of er recent updates zijn aangebracht. U kunt het gebeurtenistype hist_publish_datasource in het activiteitenlogboek of de databron TS-gebeurtenissen in Beheerdersinzichten gebruiken om recente wijzigingen te identificeren.

  2. Controleer de prestaties van de databron:

    Monitor bij liveverbindingen de prestaties van de databaseserver of clouddatawarehouse. Controleer of er recent wijzigingen zijn aangebracht en of er problemen zijn aan de serverkant. Deze stap wordt buiten Tableau uitgevoerd.

    Controleer in het geval van geëxtraheerde databronnen het extractieproces en eventuele recente updates. Zorg ervoor dat het extract geoptimaliseerd is en dat de data niet te groot of te complex zijn. Zie Extracten maken op internet voor meer informatie.

Belangrijke overwegingen

Het activiteitenlogboek gebruiken om de laadtijden van weergaven te monitoren, is een goede manier om op de hoogte te blijven van de dashboardprestaties en de betrokkenheid van gebruikers. Niet elke renderingbewerking voor een dashboard of weergave genereert echter een bootstrapsessie-gebeurtenis. Hier zijn enkele scenario's waarin een bootstrapsessie-gebeurtenis niet nodig is:

  • Gecachte dashboards: als het dashboard of de weergave wordt opgehaald uit een eerdere cache.

  • Tabblad wisselen: als een gebruiker binnen dezelfde werkmap tussen tabbladen schakelt en de inhoud voor het nieuwe tabblad wordt geladen of in de cache wordt opgeslagen.

Door gebruik te maken van het gebeurtenistype vizql_http_request en u te richten op bootstrapSession-gebeurtenissen kunt u waardevolle inzichten krijgen in de weergaveprestaties en problemen proactief aanpakken.

Bedankt voor uw feedback.De feedback is verzonden. Dank u wel.