Jetty

Jetty との統合により、セッションとスレッドの使用状況に関する指標が収集されます。この統合により、アクセスログとシステムログも収集されます。アクセスログは、リクエストの詳細に重点を置いた JSON ペイロードに解析されます。

Jetty の詳細については、Jetty のドキュメントをご覧ください。

前提条件

Jetty テレメトリーを収集するには、Ops エージェントをインストールする必要があります。

  • 指標の場合は、バージョン 2.17.0 以降をインストールします。
  • ログの場合は、バージョン 2.16.0 以降をインストールします。

この統合は、Jetty バージョン 9.4.x、10.x、11.x に対応しています。

Jetty インスタンスを構成する

この統合から指標を収集するには、Java Management Extensions（JMX）エンドポイントを公開する必要があります。

JMX エンドポイントを公開するには、JVM の起動時に com.sun.management.jmxremote.port システム プロパティを設定する必要があります。また、com.sun.management.jmxremote.rmi.port システム プロパティも同じポートに設定することをおすすめします。JMX エンドポイントをリモートで公開するには、java.rmi.server.hostname システム プロパティも設定する必要があります。

デフォルトでは、これらのプロパティは Jetty /etc/jetty-jmx.xml ファイルで設定されます。

コマンドライン引数を使用してシステム プロパティを設定するには、JVM の起動時にプロパティ名の前に -D を付けます。たとえば、com.sun.management.jmxremote.port をポート 1099 に設定するには、JVM の起動時に次のように指定します。

-Dcom.sun.management.jmxremote.port=1099

Jetty 用に Ops エージェントを構成する

Ops エージェントの構成のガイドに沿って、Jetty インスタンスからテレメトリーを収集するために必要な要素を追加し、エージェントを再起動します。

構成の例

次のコマンドは、Jetty のテレメトリーを収集して取り込む構成を作成します。

# Configures Ops Agent to collect telemetry from the app. You must restart the agent for the configuration to take effect.

set -e

# Check if the file exists
if [ ! -f /etc/google-cloud-ops-agent/config.yaml ]; then
  # Create the file if it doesn't exist.
  sudo mkdir -p /etc/google-cloud-ops-agent
  sudo touch /etc/google-cloud-ops-agent/config.yaml
fi

# Create a back up of the existing file so existing configurations are not lost.
sudo cp /etc/google-cloud-ops-agent/config.yaml /etc/google-cloud-ops-agent/config.yaml.bak

# Configure the Ops Agent.
sudo tee /etc/google-cloud-ops-agent/config.yaml > /dev/null << EOF
metrics:
  receivers:
    jetty_metrics:
      type: jetty
  service:
    pipelines:
      jetty_pipeline:
        receivers:
          - jetty_metrics
logging:
  receivers:
    jetty_access:
      type: jetty_access
  service:
    pipelines:
      jetty:
        receivers:
          - jetty_access
EOF

これらの変更を有効にするには、Ops エージェントを再起動する必要があります。

Linux

  1. エージェントを再起動するには、インスタンスで次のコマンドを実行します。
    sudo systemctl restart google-cloud-ops-agent
  2. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。
    sudo systemctl status "google-cloud-ops-agent*"

Windows

  1. RDP または同様のツールを使用してインスタンスに接続し、Windows にログインします。
  2. PowerShell アイコンを右クリックし、[管理者として実行] を選択して、管理者権限で PowerShell ターミナルを開きます。
  3. エージェントを再起動するには、次の PowerShell コマンドを実行します。
    Restart-Service google-cloud-ops-agent -Force
  4. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。
    Get-Service google-cloud-ops-agent*

ログの収集を構成する

Jetty からログを取り込むには、Jetty が生成するログのレシーバーを作成してから、新しいレシーバー用のパイプラインを作成する必要があります。

jetty_access ログのレシーバーを構成するには、次のフィールドを指定します。

フィールド デフォルト 説明
exclude_paths include_paths の照合で除外するファイルシステム パスのパターンのリスト。
include_paths ["/opt/logs/*.request.log"] 各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスにはワイルドカード（*）を使用できます。
record_log_file_path false true に設定すると、ログレコードの取得元のファイルのパスが agent.googleapis.com/log_file_path ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
type この値は、jetty_access にする必要があります。
wildcard_refresh_interval 60s include_paths のワイルドカード ファイルのパスの更新間隔。期間を指定します（例: 30s、2m）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

ログの内容

logName は、構成で指定されたレシーバー ID から取得されます。LogEntry 内の詳細なフィールドは、次のとおりです。

jetty_access ログの LogEntry には次のフィールドが含まれます。

フィールド タイプ 説明
httpRequest オブジェクト HttpRequest を参照
severity 文字列（LogSeverity） ログエントリ レベル（変換済み）。

syslog ログの LogEntry には次のフィールドが含まれます。

フィールド タイプ 説明
jsonPayload.message 文字列 ログメッセージ

指標の収集を構成する

Jetty から指標を取り込むには、Jetty が生成する指標のレシーバーを作成してから、新しいレシーバー用のパイプラインを作成する必要があります。

このレシーバーでは、複数のエンドポイントのモニタリングなど、構成で複数のインスタンスを使用することはできません。このようなインスタンスはすべて同じ時系列に書き込まれるため、Cloud Monitoring ではインスタンスを区別できません。

jetty 指標のレシーバーを構成するには、次のフィールドを指定します。

フィールド デフォルト 説明
collect_jvm_metrics true サポートされている JVM 指標も収集するようにレシーバーを構成します。
collection_interval 60s 期間の値（例: 30s、5m）。
endpoint localhost:1099 JMX サービス URL、またはサービス URL の作成に使用されるホストとポート。この値は、service:jmx:<protocol>:<sap> または host:port の形式にする必要があります。host:port フォームの値は、service:jmx:rmi:///jndi/rmi://<host>:<port>/jmxrmi というサービス URL を作成するために使用されます。
password JMX が認証を要求するように構成されている場合、構成されたパスワード。
type 値は、jetty にする必要があります。
username JMX が認証を要求するように構成されている場合、構成されたユーザー名。

モニタリング対象

次の表に、Ops エージェントが Jetty インスタンスから収集する指標の一覧を示します。

指標タイプ
種類、タイプ
モニタリング対象リソース		 ラベル
workload.googleapis.com/jetty.select.count
CUMULATIVE、INT64
gce_instance 		 
workload.googleapis.com/jetty.session.count
CUMULATIVE、INT64
gce_instance 		resource
workload.googleapis.com/jetty.session.time.max
GAUGE、INT64
gce_instance 		resource
workload.googleapis.com/jetty.session.time.total
GAUGE、INT64
gce_instance 		resource
workload.googleapis.com/jetty.thread.count
GAUGE、INT64
gce_instance 		state
workload.googleapis.com/jetty.thread.queue.count
GAUGE、INT64
gce_instance 		 

構成を確認する

このセクションでは、Jetty レシーバーが正しく構成されていることを確認する方法について説明します。Ops エージェントがテレメトリーの収集を開始するまでに 1～2 分かかる場合があります。

Jetty ログが Cloud Logging に送信されていることを確認するには、次のようにします。

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

  2. エディタに次のクエリを入力し、[クエリを実行] をクリックします。
    resource.type="gce_instance"
(log_id("jetty_access") OR log_id("syslog"))

Jetty 指標が Cloud Monitoring に送信されていることを確認するには、次のようにします。

  1. Google Cloud コンソールで、[ Metrics Explorer] のページに移動します。

    [Metrics Explorer] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

  2. クエリビルダー ペインのツールバーで、[MQL] または [PROMQL] という名前のボタンを選択します。
  3. [言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定と同じツールバーにあります。
  4. エディタに次のクエリを入力し、[クエリを実行] をクリックします。
    {"workload.googleapis.com/jetty.select.count", monitored_resource="gce_instance"}

ダッシュボードを表示する

Jetty 指標を表示するには、グラフまたはダッシュボードが構成されている必要があります。Jetty インテグレーションには、1 つ以上のダッシュボードが含まれています。インテグレーションを構成して Ops エージェントが指標データの収集を開始すると、ダッシュボードは自動的にインストールされます。

インテグレーションをインストールすることなく、ダッシュボードの静的プレビューを表示することもできます。

インストールされているダッシュボードを表示する手順は次のとおりです。

  1. Google Cloud コンソールで [ダッシュボード] ページに移動します。

    [ダッシュボード] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

  2. [ダッシュボード リスト] タブを選択し、[統合] カテゴリを選択します。
  3. 表示するダッシュボードの名前をクリックします。

インテグレーションを構成してもダッシュボードがインストールされていない場合は、Ops エージェントが実行されていることを確認します。ダッシュボードにグラフの指標データがない場合、ダッシュボードのインストールは失敗します。Ops エージェントが指標の収集を開始した後に、ダッシュボードがインストールされます。

ダッシュボードの静的プレビューを表示する手順は次のとおりです。

  1. Google Cloud コンソールで [インテグレーション] ページに移動します。

    [インテグレーション] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

  2. [デプロイメント プラットフォーム] フィルタの [Compute Engine] をクリックします。
  3. Jetty のエントリを見つけて [詳細を表示] をクリックします。
  4. [ダッシュボード] タブを選択すると、静的プレビューが表示されます。ダッシュボードがインストールされている場合は、[ダッシュボードを表示] をクリックして移動できます。

Cloud Monitoring のダッシュボードについて詳しくは、ダッシュボードとグラフをご覧ください。

[インテグレーション] ページの使用方法については、インテグレーションを管理するをご覧ください。

アラート ポリシーをインストールする

アラート ポリシーは、指定した条件が成立した際に通知するように Cloud Monitoring に指示します。Jetty インテグレーションには、使用する 1 つ以上のアラート ポリシーが含まれています。これらのアラート ポリシーは、Monitoring の [インテグレーション] ページで表示してインストールできます。

使用可能なアラート ポリシーの説明を表示してインストールする手順は次のとおりです。

  1. Google Cloud コンソールで [インテグレーション] ページに移動します。

    [インテグレーション] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

  2. Jetty のエントリを見つけて [詳細を表示] をクリックします。
  3. [アラート] タブを選択します。このタブには、利用可能なアラート ポリシーの説明と、それらをインストールするためのインターフェースが表示されます。
  4. アラート ポリシーをインストールします。アラート ポリシーでは、アラートがトリガーされた通知の送信先を特定する必要があるため、インストール環境の情報が必要になります。アラート ポリシーをインストールする手順は次のとおりです。
    1. 利用可能なアラート ポリシーのリストから、インストールするアラート ポリシーを選択します。

    2. [通知の構成] セクションで、1 つ以上の通知チャンネルを選択します。通知チャンネルの使用を無効にすることもできますが、無効にすると、アラート ポリシーは通知なく起動します。Monitoring でステータスを確認できますが、通知は受信しません。

      通知チャンネルの詳細については、通知チャンネルを管理するをご覧ください。

    3. [ポリシーの作成] をクリックします。

Cloud Monitoring のアラート ポリシーの詳細については、アラートの概要をご覧ください。

[インテグレーション] ページの使用方法については、インテグレーションを管理するをご覧ください。

次のステップ

Ansible を使用して Ops エージェントをインストールし、サードパーティ アプリケーションを構成してサンプル ダッシュボードをインストールする方法についてのチュートリアルは、Ops エージェントをインストールして、サードパーティ アプリケーションのトラブルシューティングを行うの動画をご覧ください。