管理者設定 - システム アクティビティ ダッシュボード

[管理者] メニューの [システム アクティビティ] セクションには、Looker インスタンスの使用状況とパフォーマンス情報を表示する組み込みダッシュボードが表示されます。他のダッシュボードと同様に、指標と要素のダウンロード、スケジュール、アラート設定、ドリルダウンを行うことができます。システム アクティビティ ダッシュボードのデータは、12 時間ごとに更新されてキャッシュに保存されます。

MySQL バックエンドを使用したセルフホスト型 Looker デプロイでシステム アクティビティを有効にする前に、バックエンド データベースのユーザーが正しく設定されていることを確認してください。具体的には、システム アクティビティ機能を有効にする前に、grant all on looker_tmp.* to '<DB_username>'@'%'; への手順を行う必要があります。Looker バックエンド データベースを MySQL に移行するのドキュメント ページに記載されている手順をご覧ください。

メール送信先にコンテンツを配信する権限はモデルによって異なるため、システム アクティビティ ダッシュボードを電子メール送信先に送信またはスケジュールするには、ユーザーは自分の役割に指定されたモデル セットですべてのモデルを選択しておく必要があります。

システム アクティビティ ダッシュボードは、Looker インスタンスの基盤となるアプリケーション データベースに接続します。Look とダッシュボード、ユーザー情報、過去のクエリ情報、パフォーマンス統計など、インスタンスに関する情報が表示されます。System Activity データの粒度と保持には、システムの制約が適用されます。System Activity は大量のデータを収集して集計するよう設計されており、これを使用してビジネスログを補完できます。

このデータは、モニタリング活動や監査活動を補うために役立ちますが、現在のコンプライアンス戦略に代わるものではありません。

デフォルトでは、システム アクティビティ データは Looker インスタンスの内部データベースに保存されます。この構成では、Looker は最大 90 日間の履歴クエリデータとイベントデータを保存します。

ユーザーが実行するフィルタ内のテキストは、System Activity　でアクセスでき、System Activity　モデルを表示する権限を持つユーザーが表示できます。

対策:　System Activity　モデルの閲覧権限を持つユーザーを変更します。管理者はデフォルトでこのモデルにアクセスできます。管理者以外のユーザーに see_system_activity 権限が付与されている場合は、System Activity モデルへのアクセスが許可されます。

システム アクティビティ ダッシュボードと Explore では、同時に実行できるクエリの数が制限されています。この制限により、システム アクティビティ ダッシュボードの読み込み時間が長くなる可能性があります。

Chat チームのヒント: システム アクティビティの時間ベースのデータは、システム タイムゾーンを使用して保存されます。詳しくは、タイムゾーンの設定の使用のドキュメント ページをご覧ください。

System Activity ダッシュボード

システム アクティビティ ダッシュボードは次のとおりです。

ユーザー アクティビティ ダッシュボード

[ユーザー アクティビティ] ダッシュボードには、ユーザーと、Looker インスタンスの使用状況に関する情報が表示されます。

[User Activity] ダッシュボードには、次の情報を表示するタイルが含まれています。

  • Looker インスタンス上の合計ユーザー数
  • Looker インスタンス上の各タイプのユーザー数。以下が含まれます。
  • 過去 7 日間に Looker インスタンスで 1 つ以上のクエリを発行したユーザーの割合
  • 過去 90 日間のユーザー ログイン アクティビティのスナップショット
  • 過去 6 週間の各週のユーザー 1 人あたりの平均アクティビティ時間と平均クエリ数
  • 過去 7 日以内に 1 回以上クエリを発行したユーザーの数（クエリの送信元別）
  • 過去 7 日間に Looker インスタンスの使用に多くの時間を費やしたユーザーのリスト
  • 過去 7 日間に Looker インスタンスで最も新しいダッシュボードを作成したユーザーのリスト
  • これまで Looker インスタンスから最も多くの Git イベントをトリガーしたユーザーのリスト
  • 過去 90 日以内に Looker インスタンスにログインしていないユーザーのリスト
  • Looker の教育リソースとトレーニングリソースへのリンクを含むテキストタイル

コンテンツ アクティビティ ダッシュボード

[コンテンツ アクティビティ] ダッシュボードには、Looker インスタンス上で閲覧、スケジュール設定されているダッシュボード、Look、Explore に関する情報が表示されます。

[コンテンツ アクティビティ] ダッシュボードには、次のデータが含まれるタイルが表示されます。

  • 削除されていないダッシュボードの数
  • 削除されていない Look の数
  • スケジュールされたプランの数
  • 過去 30 日間にクエリされたダッシュボードの割合
  • 過去 30 日間にクエリされた Look の割合
  • 過去 7 日間の 1 日ごとにスケジュールされたジョブ数
  • 過去 30 日間に発行された Explore クエリの数
  • Looker UI での閲覧回数、埋め込みでの閲覧回数、API での閲覧回数、コンテンツがお気に入りにされた回数、スケジュール ジョブでの配信回数で並べ替えが可能な過去 30 日間にアクセスされたすべてのダッシュボードと Looks のリスト
  • Explore の実行回数と Explore を実行したユーザー数を示す過去 30 日間に作成された Explore のリスト。
  • Looker UI、埋め込み、API を通しての過去 90 日間のコンテンツの閲覧回数と、過去 90 日間にコンテンツがお気に入りに登録された回数、およびスケジュールされたジョブで配信された回数を表示する過去 30 日間にアクセスされていないダッシュボードと Looks のリスト。
  • Explore が最後に実行されてからの期間、過去 90 日間に実行された回数、Explore が最後に実行された日付、Explore が最初に実行された日付が表示される過去 90 日間に作成され、過去 30 日間にクエリされていない Explore のリスト

データベース パフォーマンス ダッシュボード

[データベース パフォーマンス] ダッシュボードには、クエリと PDT の合計ランタイムと平均ランタイムなど、Looker インスタンス上のコンテンツと PDT のパフォーマンスに関する情報と、クエリエラーと PDT ビルドの失敗数が表示されます。

データベースのパフォーマンス ダッシュボードには、次のデータが含まれるタイルが表示されます。

  • キャッシュから返されたクエリの割合
  • 過去 30 日間に実行された全クエリ（クエリソース別にグループ化）。クエリのランタイムが階層に集計され、各ランタイムの階層が全クエリの割合として表示される
  • 過去 7 日間で実行されたクエリ数を示す、上位 15 人のユーザーのテーブル
  • 過去 7 日間で実行されたクエリ数を示す、上位 10 件のクエリソースのテーブル
  • その日の 1 時間ごとに実行されたクエリの数、アクティブ ユーザー数、Looker キャッシュから返されたクエリの割合
  • その日の 1 時間ごとにスケジュールされたジョブとスケジュールされた計画の数
  • その日の 1 時間ごとの各接続の PDT ビルドの数
  • 過去 7 日間の各 Explore の平均ランタイム（ランタイムが長い順）
  • 過去 7 日間の各 Look の平均ランタイム（ランタイムが長い順）
  • 過去 7 日間の各ダッシュボードの平均ランタイム（ランタイムが長い順）
  • トリガーの失敗、作成の失敗、成功したビルドの数を示す、過去 7 日間にビルドされた各 PDT のリスト
  • 過去 7 日間の各 PDT の平均ビルド時間（平均ビルド時間が長い順）

インスタンス パフォーマンス ダッシュボード

インスタンスのパフォーマンス ダッシュボードには、スケジューラやパフォーマンス集約的コンテンツの負荷とパフォーマンスに関する情報が表示されます。

[インスタンスのパフォーマンス] ダッシュボードには、次のデータが含まれるタイルが表示されます。

  • 各曜日、各時間帯のスケジュールされたジョブの数と平均待ち時間をヒートマップで表示し、どの時間帯、どの曜日がスケジューラーに最も大きな影響を与えるかを表示します。
  • すべての日の平均ランタイムが標準偏差の 1.5 倍を超える日のクエリの数とクエリの平均ランタイム（スケジューラに特に大きな影響を与える日を示します）
  • 各 Explore のスケジュールされたジョブの数
  • 自動更新が有効なすべてのダッシュボードのリストと、ダッシュボード上のテキスト以外のタイルの数
  • 過去 14 日間で最も頻繁にスケジュールされたコンテンツ（各コンテンツが 1 日に何回スケジュールされたかを示します）
  • すべての結果オプションでダウンロードまたはスケジュールされたクエリのリスト
  • 各ダッシュボードの Look タイル、Lookless タイル、Merge Query タイル、合計タイル、生成された合計クエリ、および合計クエリ タイルの数が表示される 25 個を超えるタイルを含むダッシュボードのリスト
  • Looker の最適化に関するベストプラクティスページとドキュメントページへのリンクを含むテキストタイル

パフォーマンスに関する推奨事項ダッシュボード

[パフォーマンスに関する推奨事項] ダッシュボードには、Looker インスタンスのパフォーマンスを向上させる機会が表示されます。

[パフォーマンスに関する推奨事項] ダッシュボードには、次の情報を表示するタイルが含まれています。

以下のセクションでは、タイルの詳細について説明します。

ダッシュボードに関する推奨事項

[ダッシュボードに関する推奨事項] タイルには、Looker インスタンスまたはデータベースのいずれかでパフォーマンスの低下を引き起こす可能性のあるダッシュボードが表示されます。このタイルには、高パフォーマンスの Looker ダッシュボードを作成する際の考慮事項のベスト プラクティスのページの推奨事項が表示されます。これらの推奨事項をダッシュボードレベルで適用して、パフォーマンスを向上させることができます。次のような警告が表示されることがあります。

警告 推奨事項
The number of queries generated by this dashboard is <X>, which is higher than recommended (<25). クエリ タイルの数を減らすか、別のダッシュボードを作成します。
The number of merge queries generated by this dashboard is <X>, which is higher than recommended (<=4). マージ結果のタイルの数を減らします。
The auto-refresh interval of this dashboard is <X>, which is lower than recommended (>=15 min). データベースの過負荷を避けるため、自動更新設定の間隔を増やすか無効にします。

Explore の推奨事項

[レコメンデーションを見る] タイルは、Looker インスタンスまたはデータベースのパフォーマンスを損なう可能性のある Explore を表示します。

このタイルは、各 Explore のクエリのパフォーマンス指標の平均値を、正常なインスタンスのパフォーマンスのベンチマークと比較します。各 Explore の横に記載されている深刻度は、その Explore の指標がこれらのベンチマークをどの程度上回っているかを示します。

どの指標がベンチマークを超えたかに基づいて、このタイルは、パフォーマンスを改善するための的を絞ったトラブルシューティング戦略を提供します。次に、表示される可能性がある警告と推奨事項を示します。

クエリのステップ 警告 推奨事項
Model Init: Computed The average model init: computed time is <X>, which is above the recommended benchmark. LookML モデルの include パラメータから不要なビューを削除します。LookML の本番環境コードは頻繁に変更されないようにします。理想的には、ユーザーが多くのクエリを実行していないときに変更します。
Explore Init: From Cache The average explore init: from cache (marshalled cache load) time is <X>, which is above the recommended benchmark. カスタム フィールドと表計算を可能な限り LookML に移行します。
Explore Init: Computed The average explore init: computed time is <X>, which is above the recommended benchmark. LookML explore ファイルから不要な結合を削除します。fields LookML パラメータを使用して、不要なフィールドを Explore から除外します。LookML の本番環境コードは頻繁に変更されないようにします。理想的には、ユーザーが多くのクエリを実行していないときに変更します。
Prepare The average prepare time is <X>, which is above the recommended benchmark. 新しい LookML ランタイムの機能を有効にして準備時間を短縮します。カスタム フィールドと表計算を可能な限り LookML に移行します。
Acquire Connection The average connection acquisition time is <X>, which is above the recommended benchmark. 接続設定パネルで最大接続数を構成します。トラフィックのピーク時にで同時実行するために必要なクエリの最大数以上の制限を設定します。
Execute Main Query The average main query execution time is <X>, which is above the recommended benchmark. ウィンドウ関数、CTE、日付フィールドの結合条件、大きな結合チェーンなど、複雑な SQL ロジックは避けてください。複雑な SQL ロジックを永続的な派生テーブル（PDT）に入れてクエリの時間を短縮します。可能であれば、集約テーブルの自動認識を使用します。
Postprocessing The average postprocessing time is <X>, which is above the recommended benchmark. テーブル計算を簡素化し、可能であれば LookML に移動します。複雑なピボット、並べ替え、値の書式を削除します。
Stream to Cache The average stream to cache time is <X>, which is above the recommended benchmark. テーブル計算を簡素化し、可能であれば LookML に移動します。複雑なピボット、並べ替え、値の書式を削除します。

エラーおよび破損コンテンツ ダッシュボード

[エラーおよび破損したコンテンツ] ダッシュボードには、クエリエラーを発生させるダッシュボード、Look、スケジュール、PDT が、各クエリソースのエラー数とともに表示されます。

このダッシュボードには、クエリの実行時に発生するエラーのみが表示されます。たとえば、LookML フィールドをビューから削除すると、そのフィールドを使用する Look とダッシュボードには警告が表示されますが、[エラーおよび破損したコンテンツ] ダッシュボードには警告は表示されません。Content Validator を使用して、Look とダッシュボードで LookML リファレンスの問題を確認します。

[エラーおよび破損したコンテンツ] ダッシュボードには、次のデータが含まれるタイルが表示されます。

  • エラーが発生しているダッシュボードのリスト（指定したエラー、各ダッシュボード クエリの発行者、各ダッシュボードを使用してクエリを実行したユーザーの数など）
  • スケジュールされたジョブのうち、エラーが発生しているもののリスト（指定したエラーと各スケジュールの作成者など）
  • エラーが発生している Look のリスト（指定したエラーと各 Look クエリの発行者など）
  • エラーが発生している PDT のリスト（エラー ログ エントリを作成した PDT アクション、PDTアクションに関連するデータ、PDT がキャンセルされたエラーを作成した回数、PDT がトリガー値エラーを作成した回数など）
  • 過去 10 日間の各クエリソースからのエラー数

ダッシュボードの診断

[ダッシュボードの診断] ダッシュボードでは、個々のダッシュボードのパフォーマンスを向上させる機会が明らかにされます。

任意のダッシュボードからダッシュボードの操作 その他メニューをクリックしダッシュボードのパフォーマンスの概要を選択することで、ダッシュボードの診断ダッシュボードにアクセスできます。

[Query Runtime by Hour] や [Query Runtime by Tile] などの一部のタイルでは、クエリのランタイムがクエリのステージごとに分割されます。クエリの段階は次のとおりです。

  • キュー内: クエリが Looker キュー内にある時間（秒単位）。Looker は、接続の1 つのノードあたりの接続数上限に達した場合、またはユーザーあたりの上限（デフォルト値は 15 個の同時クエリ）に達した場合に、クエリをキューに入れます。
  • クエリの初期化: Looker がソース LookML からクエリを作成し、データベースに接続するためにかかった時間（秒単位）。このステージが長時間かかる場合は、LookML モデルの複雑さやデータベース接続がクエリの実行時間に影響していることを示している可能性があります。
  • クエリの実行: クエリがデータベースで実行されている間、Looker がクエリ結果の待機に費やした時間（秒単位）。これには、メインのクエリと、合計の計算や PDT の構築など、必要な追加のクエリが含まれます。これは、ダッシュボードのランタイムが長くなる最も一般的な原因であり、クエリのパフォーマンスを最適化することで改善できます。
  • 結果の処理: Looker が結果のフォーマット、表計算の計算、結果セットのキャッシュに費やした時間（秒単位）。

[ダッシュボードの診断] ダッシュボードには、次の情報を表示するタイルが含まれています。

  • ダッシュボードのタイトル
  • 選択した期間にこのダッシュボードを実行したユーザーの数
  • 選択した期間内でのこのダッシュボードの実行回数
  • このダッシュボードのクエリのうち、キャッシュから実行された割合
    • キャッシュの割合が低い場合は、キャッシュ戦略を使用してデータベースの負荷を軽減します。
  • タイルごとの平均クエリ時間
  • このダッシュボードを最も頻繁に実行したユーザー
  • 1 時間あたりの平均クエリ時間
    • このタイルでスパイクが見られる場合は、複数のスケジュール済みプランが同時に送信されていないことを確認してください。
  • 統合された結果クエリが 1 つ以上あるタイルの数
  • ダッシュボードでの統合された結果クエリの数
  • ダッシュボードに関する推奨事項: このダッシュボードのパフォーマンスを改善できる可能性のある問題と推奨事項のリスト（パフォーマンス向上のため）