アクティビティログを使用したビューの読み込み時間の監視

適用先: Tableau Advanced Management

ビューがユーザーにとって最適にレンダリングされるようにすることは、管理者の重要な仕事です。アクティビティログを使用すると、パフォーマンス上の懸念事項をリアルタイムで特定して、発生した問題に対処することで、サイトの円滑な運用を維持できます。

このトピックでは、管理者が vizql_http_request イベントタイプを使用して、ビューの読み込み時間を把握し、パフォーマンスのボトルネックをトラブルシューティングする方法について説明します。

前提条件

ビューの読み込み時間を監視するには、アクティビティログデータが構造化されていて、クエリ可能な形式である必要があります。続行する前に、次の前提条件が満たされていることを確認してください。

アクティビティログの構成: アクティビティログを設定して、ログファイルを AWS S3 バケットに書き込みます。
データのインポート: アクティビティログによって生成されたログファイルを Splunk や Amazon EventBridge などの監視ツールにインポートします。または、ログファイルを Snowflake や Google BigQuery などのクラウドデータウェアハウスにインポートすることもできます。目的は、クエリや分析を簡単に行える形式にすることです。

注: このトピックでは、アクティビティログデータをデータストアにインポートするプロセスは扱いません。詳細な手順については、「アクティビティログの設定」と、選択したデータプラットフォームのドキュメントを参照してください。

開始する

どこから始めればよいのでしょうか? ダッシュボードまたはビューの初期読み込み (「bootstrap セッション」イベントと呼ばれる) に焦点を合わせることで、ビューのパフォーマンスを監視できます。このイベントは通常、ビューのレンダリングに必要な時間の大部分をキャプチャし、読み込みにどれくらいかかったかを明確に示します。

bootstrap イベントを監視するには、次の手順に従います。

Splunk や Amazon EventBridge など、設定した監視ツールを開きます。
次の値でフィルタリングします。
1. eventType = vizql_http_request。
2. endpointName = bootstrapSession。
3. eventOutcome = success。
結果で、duration フィールドを見つけます。

vizql_http_request イベントの duration フィールドは、操作の完了にかかった時間をミリ秒単位で表します。これにより、Tableau ビューの初期読み込み時間を追跡して分析できるようになります。

ヒント: どこから始めればよいかわからない場合は、管理者インサイトスターターワークブックに含まれる [ダッシュボードの読み込み時間] ダッシュボードを使用します。このダッシュボードには、コンテンツの読み込み時間とパフォーマンス評価が表示されるので、問題のあるビューを特定するのに役立ちます。その後、アクティビティログを使用して、問題が発生しているユーザーをリアルタイムで確認したり、ワークブックのリビジョンがパフォーマンスにどのような影響を与えているかを把握したりできます。詳細については、「管理者インサイトを使用したカスタムビューの作成」を参照してください。

エラーを監視する

パフォーマンスに加えて、bootstrap セッションデータを使用して、ユーザーがコンテンツの表示中にエラーに遭遇したかどうかを確認できます。これらのエラーを確認するには、eventOutcome フィールドと eventOutcomeReason フィールド検索します。これらのフィールドは、監視アラートを設定して、調査の開始点を示すのに役立ちます。たとえば、ダッシュボードの表示中にユーザーからエラーが報告された場合、bootstrap セッションを見ると、ユーザー操作の履歴を確認できます。これにより、エラーの原因を特定し、問題がいつから発生し始めたかを把握できるようになります。この情報を知っておくことは、問題の根本原因をトラブルシューティングするために重要です。

eventOutcome: このフィールドには、各操作の成功または失敗のおおまかなカテゴリ (成功、失敗、client_error、internal_error) が記録されます。
eventOutcomeReason: このフィールドには、何が問題だったかについての詳細な情報が示され、多くの場合、エラーを説明する HTTP ステータスコードが記録されます。

エラーを監視するには、次の手順に従います。

Splunk や Amazon EventBridge など、設定した監視ツールを開きます。
次の値でフィルタリングします。
1. eventType = vizql_http_request。
2. endpointName = bootstrapSession。
3. eventOutcome != success。
結果で、eventOutcomeReason を確認し、エラーの詳細を把握します。

パフォーマンスに関する問題のトラブルシューティング

パフォーマンスの問題には多くの要因があるため、問題の調査が困難になる場合があります。ただし、いくつかのアプローチを使用してプロセスを簡略化することができます。このセクションでは、bootstrap セッションを使用してワークブックのパフォーマンスをトラブルシューティングする一般的な方法の概要を説明します。まず、問題が 1 つまたは少数のワークブックに限定されているかどうかを判別します。次に、関連するセクションの手順に従います。

1 つのワークブックのトラブルシューティング

単一のワークブックにパフォーマンス上の問題がある場合は、次の手順に従います。

ワークブックのリビジョンを特定します。
パフォーマンスの問題がワークブックの新しいリビジョンで発生したかどうかを確認します。これを行うには、bootstrap セッションで workbookRevision 属性を確認します。このプロセスでは、ワークブックの以前のバージョンへのユーザーのアクセスと比較する必要がある場合があります。
新しいリビジョンがパフォーマンスの問題を引き起こしている場合は、ワークブック所有者に連絡し、協力して設計を改善します。
ユーザー固有の問題を確認します。
パフォーマンスの問題がワークブックのリビジョンに固有のものではない場合は、特定のユーザーのみに影響するかどうかを判断します。これを行うには、bootstrap セッションの requestUri 属性と actorUserLuid 属性を確認します。requestUri 属性は、アクセスされるワークブックまたはビューの URL を示し、actorUserLuid 属性は、ビューにアクセスするユーザーを示します。両方を使用すると、個々のユーザーセッションを区別しやすくなります。
問題がユーザー固有のものである場合は、ユーザー間での類似点を探します。たとえば、問題は、それらのユーザーがアクセスしているカスタマイズされたビューや、ビューの特定の操作方法に起因する場合があります。requestURI 属性を解析して、特定のビューを識別する必要があります。
行レベルのセキュリティを確認します。
一部のユーザーがパフォーマンスの問題を抱えていて、その原因がカスタムビューではない場合、問題は、ワークブックに実装されている行レベルセキュリティ (RLS) に関連している可能性があります。特にセキュリティルールが複雑な場合やデータセットが大きい場合、RLS がパフォーマンスに大きな影響を与える可能性があります。詳細については、「Tableau の行レベルのセキュリティオプションの概要」を参照してください。

ワークブックのサブセットのトラブルシューティング

ワークブックのサブセットにパフォーマンスの問題がある場合は、次の手順に従います。

共通のデータソースを特定します。
影響を受けるワークブックが使用しているデータソースの共通点を探します。
影響を受けるワークブックがデータベースサーバーまたはクラウドデータウェアハウスへのライブ接続を使用している場合、パフォーマンスの問題は、ライブ接続にある可能性があります。
影響を受けるワークブックがデータ抽出を使用している場合は、ワークブックが最近更新されたかどうかを確認します。アクティビティログの hist_publish_datasource イベントタイプまたは管理者インサイトの TS イベントデータソースを使用して、最近の変更を特定できます。
データソースのパフォーマンスを確認します。
ライブ接続の場合、データベースサーバーまたはクラウドデータウェアハウスのパフォーマンスを監視します。サーバー側で最近の変更や問題がないか確認します。このステップは Tableau の外部で実行します。
抽出データソースの場合、抽出プロセスと最近の更新を確認します。抽出が最適化されていて、データが過度に大きくないことや複雑でないことを確認してください。詳細については、「Web 上での抽出の作成」を参照してください。

重要な考慮事項

アクティビティログを使用してビューの読み込み時間を監視することは、ダッシュボードのパフォーマンスとユーザーエンゲージメントを最適に維持する優れた方法です。ただし、すべてのダッシュボードまたはビューのレンダリング操作で bootstrap セッションイベントが生成されるわけではありません。bootstrap セッションイベントが不要なシナリオを次に示します。

キャッシュされたダッシュボード: ダッシュボードまたはビューが以前のキャッシュから取得された場合。
タブの切り替え: ユーザーが同じワークブック内でタブを切り替え、新しいタブのコンテンツが読み込まれるかキャッシュされた場合。

vizql_http_request イベントタイプを使用して、bootstrapSession イベントに注目することで、ビューのパフォーマンスに関する重要なインサイトを獲得し、先を見越して問題に対処することができます。

一番上に戻る

フィードバックをお送りいただき、ありがとうございます。

フィードバックは正常に送信されました。ありがとうございます!

Tableau Cloud ヘルプ