Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

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

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

ホストのモニタリング

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

CPU 使用率: 負荷と CPU 使用率
メモリ使用率: 合計使用済みとスワップ使用
ディスク使用量

アラートのしきい値

適切なアラートのしきい値を設定するには、まずベースラインを確立します。通常の負荷の下で 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 のバックアップを設定します。