表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

Looker のモニタリング

Looker アプリケーションのモニタリングは必須ではありませんが、セルフホスト型インスタンスに設定することは非常に重要です。サーバーでなんらかの問題が生じるまれなケースでは、インシデント発生時から適切なモニタリング情報をいただけない限り、Looker による問題解決のお手伝いが非常に困難または不可能になることが少なくありません。

アプリケーションのモニタリング

URL

Looker インスタンスが実行されていることを検証する方法は 2 つあります。

次のように、Looker インスタンスの URL に /alive を追加します。

https://instance_name.looker.com/alive

インスタンスがウェブリクエストに応答できる場合は、200 OK の HTTP ステータスコードが返されます。
次のように、Looker インスタンスの URL に /availability を追加します。

https://instance_name.looker.com/availability

この URL は、基盤となる複数のサブシステムについてより完全なチェックを実行し、問題がなければ 200 OK の HTTP ステータスコードも返します。

JMX

Looker を実行する Java 仮想マシンは、JMX を介してモニタリングできます。

多くのモニタリングアプリケーション（Zabbix や Nagios など）が JMX をサポートしています。詳細については、モニタリングアプリケーションのドキュメントをご覧ください。

Looker の起動スクリプトを編集する

JMX モニタリングを有効にするには、Looker の起動スクリプトを編集する必要があります。デフォルトでは、次の名前が付けられます。

/home/looker/looker/looker

Java の起動パラメータを探します。

java \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
  -Xms$JAVAMEM -Xmx$JAVAMEM \
  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
  -Xloggc:/tmp/gc.log  ${JAVAARGS} \
  -jar looker.jar start ${LOOKERARGS}

Looker 6.18 以降では、Looker JAR ファイルが、2 つの別個の JAR ファイル（Looker コア JAR ファイルと Looker 依存関係 JAR ファイル）に分割されています。起動の際は、コア JAR ファイルが依存関係 JAR ファイルを自動的に起動します。両方の JAR ファイルは同じディレクトリに配置し、コア JAR ファイルが依存関係 JAR ファイルを正常に見つけて起動できるようにする必要があります。

デフォルトでは、--no-daemonise 起動オプションは設定されていません。--no-daemonise オプションを設定していない場合は、-Xms$JAVAMEM で始まる行に続けてセクションを追加します。

  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.port=9910 \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.ssl=false \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.local.only=false \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
  -Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \

--no-daemonise 起動オプションを設定している場合は、-Xms$JAVAMEM で始まる行に続けてセクションを追加します。

  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9910 \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
  -Dcom.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \

`.lookerjmx` ディレクトリを作成する

次に、Looker ユーザーのホームディレクトリに .lookerjmx ディレクトリを作成し、権限を設定します。

sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx

JMX ファイルを作成する

任意のテキストエディタを使用して、新しいディレクトリに jmxremote.access という名前のファイルを作成し、次の内容を追加します（環境に合わせてカスタマイズできます）。

monitorRole   readonly
controlRole   readwrite \
              create javax.management.monitor.*,javax.management.timer.* \
              unregister

次に、同じディレクトリに、安全なパスワードを使用して、次の内容で、jmxremote.password という名前のファイルを作成します。

monitorRole   some_password_here
controlRole   some_password_here

権限を設定する

Looker ユーザー以外にパスワードファイルを読み取ることができるファイル権限がある場合は、Java（したがって Looker）が起動しないようにします。

chmod 400 jmxremote.*

Looker を再起動する

JMX を有効にするには、Looker を再起動する必要があります。「root ユーザーではなく Looker ユーザーとして」次のコマンドを実行してください。

cd ~/looker
./looker restart

指定したパスワードを使用して、ポート 9910 でリモート JMX モニタリングが構成された Looker インスタンスが作成されました。モニタリングサーバーがこのポートでネットワークにアクセスできるように、ファイアウォール設定かネットワーク ACL の変更が必要になる場合があります。

ホストのモニタリング

Looker アプリケーションを実行するすべてのホストでは、少なくとも以下のパフォーマンス指標を収集、グラフ化、アラートすることをおすすめします。

CPU 使用率: 負荷と CPU 使用率（パーセント）
Memory Utilization: 使用済の合計と使用されているスワップ
ディスク使用量

アラートのしきい値

適切なアラートのしきい値を設定するには、まずベースラインを設定します。通常の負荷で稼働する Looker インスタンスを使用してパフォーマンスデータを収集します。パフォーマンスグラフでピークを確認します。ベースラインを確立するために必要な時間は、ビジネスと Looker の使用パターンによって異なります。会社によっては、毎週、営業時間中に安定した反復可能なパターンで Looker を使用している場合があります。他の会社では、Looker を特定の期間（月末など）に、より頻繁に使用することがあります。

一般に、アラートは、対応する価値のあるイベントに対してのみ送信する必要があります。何もする必要がないときにアラートを送信すると、重要なアラートの価値が覆われてしまいます。

アラートの出発点として、次のしきい値を使用できます。次の値が 15 分以上になると、手動での操作が必要になる場合があります。

指標	警告	重大	コメント
CPU 負荷	2	4	シングルコアシステムでは、負荷が、通常 1 以下になります。高い負荷が持続すると、パフォーマンスが低下します。
CPU 使用率（%）	80	90	CPU の使用率が高いと、パフォーマンスが低下します。
メモリ使用率（%）	60	70	メモリ使用率が高い場合は、Java に割り当てられたメモリが多すぎる可能性があります。
ディスク使用率（%）	80	90	ディスクが一杯でないことを確認してください。

追加情報:

複数のコアがあるシステムでは、パフォーマンスを低下させることなく CPU の高負荷に対処できます。経験則として、持続する負荷はプロセッサコアの数を超えてはいけません。
システムがパフォーマンスを低下させる前の合計 CPU 時間の割合は、システムの CPU コア数によって変わります。つまり、シングルコアシステムで CPU の使用率が 80% になるとパフォーマンスが悪くなる可能性がありますが、16 コアのホストでは使用率が 95% でも使用できます。
高い CPU 使用率は、ホストハードウェアの更新や、より大きなインスタンスへのアップグレードによって解決できます。多数のスケジュールされた Look や長いクエリの派生テーブルは、削減または効率化することで、パフォーマンスを向上させることが可能な場合もあります。

次のステップ

モニタリングを設定したら、Looker のバックアップを設定できます。