Looker のモニタリング

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

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

URL

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

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

   https://instance_name.looker.com/alive

   インスタンスがウェブ リクエストに応答できる場合は、200 OK の HTTP ステータス コードが返されます。

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

次のステップ

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