重要
2024 年 8 月 26 日以降、パブリックまたはプライベートな場所でレガシー ランタイムを使用して新しいモニターを作成することはできなくなります。
2024 年 10 月 22 日をもって、コンテナー化された プライベートミニオン (1 分間あたりの呼出し回数) とそれがサポートする レガシー合成バージョンのサポートは終了します。 プライベートロケーションモニターのパフォーマンス低下を回避するために、 推奨される移行手順を確認してください。
このドキュメントでは、コンテナ化された プライベートミニオン (CPM)を構成する手順について説明します。
CPMをカスタマイズするには以下の方法があります。
- 環境変数を使用して、コンテナ化されたプライベートミニオンを構成します。
- スクリプトAPI または スクリプトbrowser モニターの カスタム モジュール を設定します。
- 永久データ保存 で打ち上げデータを保存します。
お客様はCPMファイルを変更することはできず、お客様が行った変更についてニューレリックは責任を負いません。
環境変数を使用した設定
環境変数により、お客様の環境や機能のニーズに合わせてCPMの構成を微調整することができます。
ボリュームのマウントに関するガイドライン
すべてのディレクトリとファイルmustには、読み取り/書き込み権限を持つグループ所有権が3729として割り当てられます。 これにより、 uid: 1000とgid: 3729を使用するランナーがマウントされたすべてのボリュームにアクセスできるようになります。 ただし、ミニオンはルート ( uid: 0 ) として実行することも、 [2000, 4000]の範囲内の任意のuidを使用して実行することもできます。 詳細については、「Kubernetes または Docker で非 root として実行する」を参照してください。
Docker
- ディレクトリは、内で
-v引数を指定することにより、ボリュームとしてコンテナにマウントされます。docker run - 例えば、
docker run ... -v /path/to/src:/path/to/dest:rw
Kubernetes
kubectl cpを使用して、永続ボリューム ( PV ) にディレクトリを追加できます。 ただし、ファイルのアクセス許可が適切に設定されている限り、別のアプローチもサポートされます。- たとえば、
kubectl cp /path/to/src <POD_NAME>:/path/to/destは指定されたポッドの各PVにディレクトリを追加します - 各PVには、ディレクトリのコピーが個別に存在する必要があります。例えば、 n Minion のレプリカを持つクラスターでは、 n PV が必要で、それぞれがディレクトリのコピーを持つ必要があります。
- ディレクトリとファイルは、ミニオンの起動前に追加する必要があります。そうしないと、更新を検出するためにミニオンを再起動する必要があります。
カスタムノードモジュール
カスタム ノード モジュールは、1分間あたりの呼発信回数に限定されます。 これにより、ノード モジュールの任意のセットを提供し、それらを外形監視のスクリプト モニターで使用できるようになります。
モジュールをセットアップするには
npm の公式ガイドラインに従って、ディレクトリのルートに
package.jsonを含むディレクトリを作成します。dependenciesフィールドに含まれるものはすべて、開始時に CPM によってインストールされ、そのプライベート ミニオンでモニターを実行するときに使用できるようになります。必要に応じて、ルート レベル
package.jsonを Node.js バージョン固有のディレクトリでオーバーライドできます。これにより、ランタイムのNode.js バージョンが依存関係と互換性がなくなった場合に、モニター ランタイムごとにスクリプトを更新できます。以下の例を参照してください。カスタムモジュールディレクトリと
package.jsonを作成したら、DockerとKubernetesのCPMに適用できます。"... Initialization of Custom Modules ..."のCPMログを調べて、モジュールが正しくインストールされているかどうか、またはエラーが発生していないかどうかを確認します。 npmインストールログが表示されます。
これで、このプライベートな場所に送信するモニターのスクリプトに"require('async');"を追加できます。
変化 package.json
ローカル モジュールやホスト モジュールとともにNode.js モジュールを使用することもできます。 CPM で使用されるカスタム モジュールを変更するには、を変更して CPM を再起動します。package.jsonを変更して 1分間あたりの呼出回数を再起動します。 再起動時に設定の変更を検出し、クリーンアップして再インストールします。
注意
ローカルモジュール： package.jsonには任意のローカルモジュールを含めることができますが、これらのモジュールは、カスタムモジュールディレクトリの下のツリー内に存在する必要があります。ツリーの外部に保存されている場合、初期化プロセスは失敗し、CPMの起動後にDockerログにエラーメッセージが表示されます。
データの永久保存
CPMはステートレスアプリケーションであり、デフォルトでは以前のリクエストまたはセッションからの情報を保持しません。ただし、永続的なデータストレージを有効にすることで、起動間でデータを保持できます。たとえば、ミニオンがそれ自体を識別する方法（たとえば、 Minion_ID ）を永続的に設定し、それを使用して、そのデータを、それを生成した正確なミニオンに関連付けることができます。
Dockerに恒久的なデータ保存を設定するには
ディレクトリを作成します。
CPMを起動し、ディレクトリを
/var/lib/newrelic/syntheticsにマウントします。例：
bash$docker run ... -v /example-permanent-dir:/var/lib/newrelic/synthetics:rw ...
Kubernetesに恒久的なデータストレージを設定すること。
CPMを起動し、インストール中にコマンドラインまたはYAMLファイルのいずれかで
persistence.permanentData構成値の値を設定します。この値は、データを保存するMinionの永続ボリュームのサブパスを指定する必要があります。例：
bash$helm install ... --set persistence.permanentData=PERMANENT_DATA_SUBPATH ...
スクリプトによるモニターのためのユーザー定義の環境変数
コンテナ化されたプライベートミニオンを使用すると、スクリプト化されたモニターで使用する環境変数を構成できます。これらの変数はCPMでローカルにホストされ、 $env.USER_DEFINED_VARIABLESを介してアクセスできます。ユーザー定義変数を設定するには、JSONファイルをマウントする方法と、起動時に環境変数をCPMに提供する方法の2つがあります。両方が提供されている場合、CPMは環境から提供された値のみを使用します。
スクリプトからユーザー定義の環境変数にアクセスする
構成されたユーザー定義の環境変数を参照するには、予約済みの$env.USER_DEFINED_VARIABLESに続けて、ドット表記の特定の変数の名前を使用します。
例えば、 $env.USER_DEFINED_VARIABLES.MY_VARIABLE
注意
ユーザー定義の環境変数はログからサニタイズされません。機密情報については、 セキュアな認証情報 機能の使用を検討してください。