エージェントのタイプ

エージェントタイプ定義は、Agent Controlが特定のエージェントを識別、ダウンロード、設定、および実行する方法を記述するYAMLファイルです。宣言された変数は、フリートからサブエージェントをデプロイまたは更新する際にFleet Controlがオペレーターに公開する設定スキーマも形成します。すべての定義は、metadata、variables、deploymentの3つの主要なセクションと、ファイルが記述されているスキーマ言語のバージョンを示すトップレベルのprotocol_versionフィールドで構成されています。

メタデータ

メタデータセクションはエージェントタイプを識別します：そのname、namespace、version、ターゲットplatform（hostまたはkubernetes）、およびoperating_system（ホストベースのタイプに必須）。Agent Controlはこれらのフィールドを使用して定義を一意にアドレス指定し、正しいデプロイメントエンジンにディスパッチします。

変数

variablesセクションでは、オペレーターがサブエージェントを設定に追加する際に設定できる構成可能な入力を宣言します。各変数には、type（string、bool、またはyamlなど）、オプションのdefault、および受け入れ可能な値のオプションのvariantsリストがあります。変数は、${nr-var:variable_name}を使用してデプロイメントセクション全体で参照されます。

デプロイメント

デプロイメントセクションでは、Agent Controlがターゲットプラットフォームにエージェントをインストールして実行する方法について説明します。これはいくつかのサブセクションで構成されています：

• packages：エージェントの起動前にダウンロードするOCIアーティファクト — 通常はエージェントのバイナリまたはインテグレーションパッケージです。
• executables: Agent Controlが開始、モニター、再起動するプロセスのリスト。このセクションを持たないエージェントタイプは、管理対象のインテグレーション（OHI）として扱われます：Agent Controlはそのアーティファクトを処理しますが、実行は別のエージェントに委任します。
• health：Agent Controlがエージェントの正常性を判断する方法 — プロセスの存在、HTTPエンドポイントのチェック、またはその両方を使用します。
• filesystem：設定ファイルや証明書など、エージェントを起動する前にAgent Controlがホストに書き込む個々のファイルまたはディレクトリ。
• shared_filesystem: 同じAgent Controlインスタンスによって管理される他のエージェントがアクセスできる共有ドロップゾーンに書き込まれるエントリです。OHIエージェントタイプが設定とバイナリをinfrastructureエージェントに渡すために使用されます。

完全なスキーマリファレンスと利用可能なすべてのフィールドについては、エージェントタイプスキーマリファレンスをご覧ください。

エージェントタイプの定義を取得

Agent Controlは、定義のメタデータセクションで宣言されたnamespace、name、およびversionによって識別されるリモートOCIレジストリからエージェントタイプ定義を取得します。

デフォルトでは、Agent Controlはnewrelic/agent-control-agent-typesリポジトリを使用してdocker.ioからプルします。

Agent Controlは、各定義をプルする前に、New Relicの公開鍵に対して署名検証を行います。

このレジストリは、エージェントパッケージと同じ方法でミラーリングできます。

リンクされたエージェントのタイプ

一方のエージェントのタイプが共有ファイルシステムにアーティファクト（設定、バイナリ、またはその他のファイル）を書き込み、もう一方が同じパスから読み取るように設定されている場合、2つのエージェントのタイプはリンクされています。ライターにはexecutablesセクションがない場合があり、Agent Controlはそのアーティファクトを管理しますが、そのためのプロセスを開始することはありません。代わりに、リーダーエージェントには、共有ファイルシステムの既知のパスからバイナリと設定を検出して実行する組み込みロジックがあり、事実上、ライターに代わってアドオンを実行します。

共有ファイルシステムのルートは次のとおりです：

同じAgent Controlインスタンスによって管理されるすべてのエージェントは、このルートを共有します。サブディレクトリ名は、リンクされたエージェントタイプ間の規則によって選択されます。

オンホストインテグレーション（OHI）

オンホストインテグレーション（OHI）は、Agent Controlにおけるリンクされたエージェントの主な例です；他のエージェントにはAgent Controlによって開始されるプロセスがありますが、OHIエージェントには独自のプロセスがなく、Agent Controlがそれらを開始することはありません。これらにより、Agent ControlはNew Relic Infrastructureインテグレーションの完全なライフサイクルを管理し、ダウンロード、設定、アップグレード、およびアンインストールを行う一方で、その実行をinfrastructureエージェントに委任します。infrastructureエージェントは、共有ファイルシステムからインテグレーションバイナリを検出して実行します。

infrastructureエージェントとOHIエージェントの関係

1. OHIエージェントのタイプがインストールされると、Agent ControlはOCI経由でインテグレーションのバイナリをダウンロードし、共有ファイルシステムに2つのエントリを書き込みます：

   • infra-agent-ohi-configs/配下の設定ファイル（例：nri-redis.yaml）
   • infra-agent-ohi-binaries/の下にあるインテグレーションバイナリ（例：nri-redis）

2. infrastructureエージェントのサブエージェントは、これらの共有ディレクトリを指す環境変数で設定されます：

   変数	共有ファイルシステムパス	目的
   NRIA_PLUGIN_DIR	…/infra-agent-ohi-configs	インテグレーション設定の検出
   NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR	…/infra-agent-ohi-binaries	インテグレーションのバイナリの検出
   NRIA_SAFE_BIN_DIR	…/infra-agent-ohi-binaries	許可されたバイナリの実行パス

3. infrastructureエージェントは、次のスキャンサイクルで設定とバイナリを取得し、インテグレーションの実行を開始します。

   shared-filesystem/
   ├── infra-agent-ohi-configs/      # Integration YAML configs (read by NRIA_PLUGIN_DIR)
   │   ├── nri-redis.yaml
   │   └── nri-mysql.yaml
   └── infra-agent-ohi-binaries/     # Integration binaries (read by NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR)
       ├── nri-redis
       └── nri-mysql

   コピー

サポートされているエージェントの種類

現在のサポート

以下の表は、Agent Controlがサポートするエージェントのタイプと、環境ごとの可用性を示しています。

エージェントタイプごとの必要な権限

以下の表は、各エージェントタイプに必要な主要な権限と、それが適用される環境を示しています。

ホストでのFluent Bitの設定

ホストでは、Fluent Bitは独自のトップレベルのエージェントタイプとしてデプロイされません（上記のサポートテーブルを参照してください）。代わりに、ログ転送が有効になっている場合、Fluent Bitはスタンドアロンでインストールされた場合と同じように、New Relic infrastructureエージェント自体によって生成および管理されます。Agent Controlは、infrastructureエージェント、そのデータ、およびFluent Bitのバイナリとプラグインがディスク上のどこに配置されるかのみを変更します。

ログ転送自体の設定方法（logging.d/*.ymlの構文、入力、フィルター、属性など）については、以下をご覧ください：

• ログ管理の有効化
• Fluent Bitを使用したログの転送

設定の配置場所

Agent Control固有の唯一の詳細は、ログ転送ファイルの配置場所です：これらは、infrastructureエージェントの設定のconfig_loggingフィールドを介して、ログソースごとに1つのエントリとして、サブエージェントのlogging.dフォルダーに配置されます。これをサブエージェントの設定（たとえば、そのlocal_config.yaml）で直接設定し、それをAgent Controlに送信します：

config_logging:
  syslog.yaml: |
    logs:
      - name: syslog
        file: /var/log/syslog
        attributes:
          logtype: linux_syslog
  app.yaml: |
    logs:
      - name: app-log
        file: /var/log/app.log
        attributes:
          service: api
          env: production

Fluent Bitの配置場所と更新方法