インフラストラクチャエージェントを使用してログを転送する

ログ ファイルへのパス。エージェントは、 tail -fシェルと同様の方法でログ ファイルの変更を追跡します。

例：

logs:
  - name: example-log
    file: /var/log/example.log # Path to a single log file
  - name: example-log-two
    file: /var/log/example-two.log # Path to another single log file

fileパラメータは、名前と拡張子に適用されるワイルドカードを使用して、特定のログファイルまたは複数のファイルを指すことができます。たとえば、 /logs/*.log 。ファイルパス内のディレクトリの代わりにワイルドカードを使用できます。これを使用して、別のディレクトリにあるファイルを調整できます。

例：

logs:
  - name: docker-logs
    file: /var/lib/docker/containers/*/*.log # Path to multiple folders and files

Linux環境でjournaldデーモンによって収集されたログメッセージを転送するには、 systemdパラメーターを使用します。この入力タイプでは、エージェントがルートモードで実行されている必要があります。

例：

logs:
  - name: systemd-example
    systemd: cupsd

Syslogデータソース。

パラメーター：

• uri: Syslogソケット。形式はプロトコルによって異なります。

  • TCP / UDPネットワークソケット： [tcp/udp]://LISTEN_ADDRESS:PORT
  • Unixドメインソケット： unix_[tcp/udp]:// + /socket/path

• parser: Syslogパーサー。デフォルトはrfc3164です。メッセージに秒の小数部が含まれている場合は、 rfc5424を使用します。注： rfc3164は現在SuSEでは機能しません。

• unix_permissions: ドメインソケットのデフォルトは0644です。これにより、エントリはルートとして実行されているプロセスに制限されます。0666を使用して、自己責任で非ルートプロセスをリッスンできます。

  エージェントを特権モードで実行する場合、他のプロセスがソケットにログを書き込めるように、ポートとソケットは0666 nri-agentによって使用可能であるか、所有されている必要があります。

  logs:
    # TCP network socket
    - name: syslog-tcp-test
      syslog:
        uri: tcp://0.0.0.0:5140 # Use the tcp://LISTEN_ADDRESS:PORT format
        parser: rfc5424 # Default syslog parser is rfc3164
    # UDP network socket
    - name: syslog-udp-test
      syslog:
        uri: udp://0.0.0.0:6140 # Use the udp://LISTEN_ADDRESS:PORT format
      max_line_kb: 35
    # Unix TCP domain socket
    - name: syslog-unix-tcp-test
      syslog:
        uri: unix_tcp:///var/unix-tcp-socket-test
        unix_permissions: 0666 # Default is 0644. Change at your own risk
    # Unix UDP domain socket
    - name: syslog-unix-udp-test
      syslog:
        uri: unix_udp:///var/unix-udp-socket-test
        parser: rfc5424

  コピー

TCP接続を介して取得されたログ。

パラメーター：

• uri: 着信データをリッスンするTCP/IPソケット。URI形式は tcp://LISTEN_ADDRESS:PORT

• format: データのフォーマット。jsonまたはnoneにすることができます。

• separator: format: noneを使用する場合は、レコードを分割するための区切り文字列を定義できます（デフォルト： \n ）。

  logs:
    - name: tcp-simple-test
      tcp:
        uri: tcp://0.0.0.0:1234 # Use the tcp://LISTEN_ADDRESS:PORT format
        format: none # Raw text - this is default for 'tcp'
        separator: \t # String for separating raw text entries
      max_line_kb: 32
    - name: tcp-json-test
      tcp:
        uri: tcp://0.0.0.0:2345 # Use the tcp://LISTEN_ADDRESS:PORT format
        format: json

  コピー

winevtlog Fluent Bitプラグインを使用して、新しいWindowsイベントログAPIを使用してWindowsログチャネルからイベントを収集します。

パラメーター：

• channel: チャネルログの名前はから収集されます。

• collect-eventids: 収集されてNewRelicに転送されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。

• exclude-eventids: コレクションから除外されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。

• use-ansi: winevtlog メッセージには ANSI エンコードを使用します。Windows Server 2016 以前のバージョンではデフォルトで ANSI エンコードを使用し、新しいバージョンでは UTF-8 を使用します。これらのデフォルトがユースケースに適合しない場合は、この構成パラメーターを使用してこの動作をオーバーライドできます。

  デフォルトでは、すべてのイベントは指定されたチャネルから収集されます。New Relicアカウントに不要なログが送信されないように、 collect-eventidsセクションとexclude-eventidsセクションを構成します。

  イベントIDまたは範囲をcollect-eventidsまたはexclude-eventidsに追加して、特定のイベントを転送またはドロップします。同じイベントIDが両方のセクションに存在する場合、 exclude-eventidsはcollect-eventidsよりも優先されます。

  例：

  logs:
    # Example winevtlog security log ingestion with eventId filters.
    - name: windows-security
      winevtlog:
        channel: Security
        collect-eventids:
          - 4624
          - 4265
          - 4700-4800
        exclude-eventids:
          - 4735
      attributes:
        logtype: windows_security
  
    # Example entries for the application and system channels
    - name: windows-application
      winevtlog:
        channel: Application
        attributes:
          logtype: windows_application
    - name: windows-system
      winevtlog:
        channel: System
        attributes:
          logtype: windows_system
  
    # Example/Optional entry for Windows Defender Logs
    #- name: windows-defender
    #  winevtlog:
    #    channel: Microsoft-Windows-Windows Defender/Operational
  
    # Example/Optional entry for Windows Clustering Logs
    #- name: windows-clustering
    #  winevtlog:
    #    channel: Microsoft-Windows-FailoverClustering/Operational

  コピー

Windowsログチャネルからイベントを収集します。

パラメーター：

• channel: チャネルログの名前はから収集されます。カスタムチャネルでは機能しません。

• collect-eventids: 収集されてNewRelicに転送されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。

• exclude-eventids: コレクションから除外されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。

• use-ansi: winlog メッセージに ANSI エンコードを使用します。Windows Server 2016 以前のバージョンではデフォルトで ANSI エンコードを使用し、新しいバージョンでは UTF-8 を使用します。これらのデフォルトがユースケースに適合しない場合は、この構成パラメーターを使用してこの動作をオーバーライドできます。

  デフォルトでは、すべてのイベントは指定されたチャネルから収集されます。New Relicアカウントに不要なログが送信されないように、 collect-eventidsセクションとexclude-eventidsセクションを構成します。

  イベントIDまたは範囲をcollect-eventidsまたはexclude-eventidsに追加して、特定のイベントを転送またはドロップします。同じイベントIDが両方のセクションに存在する場合、 exclude-eventidsはcollect-eventidsよりも優先されます。

  例：

  logs:
    # Example winlog security log ingestion with eventId filters.
    - name: windows-security
      winlog:
        channel: Security
        collect-eventids:
          - 4624
          - 4265
          - 4700-4800
        exclude-eventids:
          - 4735
      attributes:
        logtype: windows_security
  
    # Example entries for the application and system channels
    - name: windows-application
      winlog:
        channel: Application
        attributes:
          logtype: windows_application
    - name: windows-system
      winlog:
        channel: System
        attributes:
          logtype: windows_system
  
    # Example/Optional entry for Windows Defender Logs
    #- name: windows-defender
    #  winlog:
    #    channel: Microsoft-Windows-Windows Defender/Operational
  
    # Example/Optional entry for Windows Clustering Logs
    #- name: windows-clustering
    #  winlog:
    #    channel: Microsoft-Windows-FailoverClustering/Operational

  コピー

キーと値のペアとして指定されたカスタム属性のリスト。ログとともに追加のデータを送信するために使用でき、その後クエリを実行できます。attributes構成パラメーターは、任意のログソースで使用できます。

attributes構成パラメーターの一般的な使用法の1つは、 logtype属性を指定することです。この属性により、NewRelicのログ管理機能でサポートされている組み込みの解析ルールの1つを活用できます。

例：

logs:
  - name: example-file-attributes
    file: /var/log/example.log
    attributes:
      logtype: nginx
      region: example-us-02
      team: A-team
  - name: example-tcp-attributes
    tcp:
      uri: tcp://0.0.0.0:2345
      format: json
    attributes:
      logtype: nginx
      region: example-us-02
      team: B-team

インフラストラクチャエージェントは、便宜上、ログ属性を自動的に挿入します。それらのいくつかはログレコードに挿入されますが、その他はログフォワーダーのセットアップ中に使用した構成パラメーターに依存します。

レコードをフィルタリングするための正規表現。tail 、 systemd 、 syslog 、およびtcp （形式noneの場合のみ）のソースでのみサポートされます。

このフィールドは、Unixシステムのgrep -Eと同じように機能します。たとえば、キャプチャされている特定のファイルについて、次を使用してWARNまたはERRORのいずれかを含むレコードをフィルタリングできます。

- name: only-records-with-warn-and-error
  file: /var/log/logFile.log
  pattern: WARN|ERROR

デフォルトでは、フィルタリングは適用されません。

ログエントリ/行の最大サイズ（KB単位）。ログエントリが制限を超えると、スキップされます。デフォルトは128です。

外部FluentBit構成およびパーサーファイル。定義されている場合、それらはインフラストラクチャエージェントによって生成された既存の構成ファイルおよびパーサーファイルとマージされます。

インフラストラクチャエージェントは、 logging.dディレクトリにある構成ファイルを処理し、適切な[INPUT] 、 [FILTER] 、および[OUTPUT]セクションを含むランタイムFluentBit構成ファイルを生成します。オプションで、 fluentbitオプションを介して外部Fluent Bit構成ファイルを提供した場合は、 @INCLUDEも宣言します。

ランタイム ファイルで[SERVICE]セクションが定義されていないため、すべてのデフォルトの Fluent Bit 構成値が残されています。外部の Fluent Bit 構成ファイルで独自の[SERVICE]セクションを定義し、 fluentbitオプションを介して含めることで、Fluent Bit のデフォルト設定をオーバーライドできます。

パラメーター：

config_file: 既存のFluentBit構成ファイルへのパス。ソースが重複していると、NewRelicのログUIにメッセージが重複することに注意してください。

parsers_file: 既存のFluentBitパーサーファイルへのパス。次のパーサー名が予約されています： rfc3164 、 rfc3164-local 、およびrfc5424 。

elasticsearch-log.yml.exampleファイルをelasticsearch-log.ymlにコピー（または名前変更）して、ElasticsearchJSON形式の自動ログ解析とNewRelicへの転送を有効にします。エージェントを再起動する必要はありません。

例：

$
sudo cp /etc/newrelic-infra/logging.d/elasticsearch-log.yml.example /etc/newrelic-infra/logging.d/elasticsearch-log.yml

mysql-log.yml.exampleファイルをmysql-log.ymlにコピー（または名前変更）して、MySQLエラーログの自動解析とNewRelicへの転送を有効にします。エージェントを再起動する必要はありません。

例：

$
sudo cp /etc/newrelic-infra/logging.d/mysql-log.yml.example /etc/newrelic-infra/logging.d/mysql-log.yml

nginx-log.yml.exampleファイルをnginx-log.ymlにコピー（または名前変更）して、自動NGINXアクセスとエラーログの解析およびNewRelicへの転送を有効にします。エージェントを再起動する必要はありません。

例：

$
sudo cp /etc/newrelic-infra/logging.d/nginx-log.yml.example /etc/newrelic-infra/logging.d/nginx-log.yml

rabbitmq-log.yml.exampleファイルをrabbitmq-log.ymlにコピー（または名前変更）して、Rabbitmqエラーログの自動解析とNewRelicへの転送を有効にします。エージェントを再起動する必要はありません。

例：

$
sudo cp /etc/newrelic-infra/logging.d/rabbitmq-log.yml.example /etc/newrelic-infra/logging.d/rabbitmq-log.yml

redis-log.yml.exampleファイルをredis-log.ymlにコピー（または名前変更）して、Redisエラーログの自動解析とNewRelicへの転送を有効にします。エージェントを再起動する必要はありません。

例：

$
sudo cp /etc/newrelic-infra/logging.d/redis-log.yml.example /etc/newrelic-infra/logging.d/redis-log.yml

ログ管理機能を有効にしてもデータが表示されない場合は、標準のログトラブルシューティング手順に従ってください。

ログ転送機能では、エージェントがデータソースを読み取るためのアクセス許可を持っている必要があります。インフラストラクチャエージェントを特権モードまたは非特権モードで実行する場合は、転送するログファイル（およびそのパス内の中間ディレクトリ）が、 nri-agentを実行しているユーザーが読み取れることを確認してください。

例：Linuxでのファイルアクセスの確認

nri-agentユーザーがファイル/var/log/restrictedLogs/logFile.logを監視できるかどうかを確認しましょう。Linuxでは、 nameiコマンドを使用して簡単なチェックを行うことができます。

$
sudo -u nri-agent namei -ml /var/log/restrictedLogs/logFile.log
$
f: /var/log/restrictedLogs/logFile.log
$
drwxr-xr-x root root /
$
drwxr-xr-x root root var
$
drwxrwxr-x root syslog log
$
drwxr--r-- root root restrictedLogs
$
logFile.log - No such file or directory

ファイルがnri-agentユーザーに表示されないため、このコマンドは失敗しました。前の出力を調べることにより、 restrictedLogsディレクトリにothersの実行フラグがないことを検出できます。

これを修正するには、次を実行します。

$
sudo chmod 755 /var/log/restrictedLogs

次に、ファイルアクセスを再度確認します。

$
# sudo -u nri-agent namei -ml /var/log/restrictedLogs/logFile.log
$
f: /var/log/restrictedLogs/logFile.log
$
drwxr-xr-x root root /
$
drwxr-xr-x root root var
$
drwxrwxr-x root syslog log
$
drwxr-xr-x root root restrictedLogs
$
-rw-r----- vagrant vagrant logFile.log

これで、ファイルはnri-agentユーザーに表示されます。nri-agentユーザーもファイルを読み取れるようにする必要があります。これを確認するには、次を使用します。

$
# sudo -u nri-agent head /var/log/restrictedLogs/logFile.log
$
head: cannot open '/var/log/restrictedLogs/logFile.log' for reading: Permission denied

この例では、ファイルにothersグループ（ vagrantおよびvagrantユーザーグループ以外のユーザー）の読み取り権限がありません。othersに読み取り権限を付与することでこれを修正できますが、アプリケーションは再起動時にこれらの権限を変更する可能性があります。

これを回避するには、 nri-agentユーザーをvagrantユーザーグループに追加することをお勧めします。

ログ転送機能には、エージェントがデータソースを読み取る権限を持っている必要があります。インフラストラクチャエージェントを特権モードまたは非特権モードで実行する場合：

• Unixドメインソケットファイルを使用している場合は、nri-agentユーザーがこれらのファイルにアクセスできること（前のセクションを参照してください）と、他のユーザーが読み取りおよび書き込み権限（666）を持っていることを確認してください。 nri-agentよりも多くのユーザーが書き込み可能です。

• IPソケットを使用している場合は、使用しているポートがシステムで予約されているポートではないことを確認してください（たとえば、ポート80など）。

  ログ管理を有効にしてもデータが表示されない場合は、標準のログ管理のトラブルシューティング手順に従ってください。

インフラストラクチャ エージェントの構成ガイドラインで説明されているように、 proxyパラメータは HTTP または HTTPS のいずれかを使用し、https://user:password@hostname:port の形式にする必要があります。エージェントは HTTP または HTTPS なしでパラメーターを解析できますが、ログ フォワーダーはできません。エージェントの詳細ログに次のようなエラーが表示されます。

[ERROR] building HTTP transport: parse \"hostname:port\":
first path segment in URL cannot contain colon

この問題を解決するには、 newrelic-infra.ymlファイルをチェックし、 proxyパラメータがこのフォームに準拠していることを確認してください。

証明書を指定するためにcaBundleFileまたはcaBundleDirを使用している場合は、OSごとに以下のルールに従うことをお勧めします。

Linux HTTPプロキシの場合、証明書を設定する必要はありません。プラグインはシステム証明書をロードし、NewRelicはログをロギングエンドポイントに送信します。ただし、 caBundleFileまたはcaBundleDirパラメータのいずれかを使用して、プロキシ自己署名証明書（PEMファイル）を指定できます。

ウィンドウズ

• HTTPプロキシの場合、証明書を設定する必要はありません。プラグインはシステム証明書をロードします。

• HTTPSの場合、次のいずれかの方法で構成できます。

• プロキシ証明書をシステムプールにインポートする（推奨）MMCツールを使用して、プロキシ自己署名証明書（PEMファイル）をインポートします。このリンクを参照し、ステップ2で、 Intermediate Certification AuthoritiesではなくTrusted Root Certification Authoritiesにインポートしてください。

• caBundleFileおよびcaBundleDirパラメーターの使用Windowsでは、システム証明書プールからの証明書とcaBundleFile caBundleDirパラメーターで指定された証明書の両方をロードすることはできません。したがって、 caBundleFileまたはcaBundleDirを使用している場合は、次の証明書が同じPEMファイル（ caBundleFileを使用している場合）または同じディレクトリ（ caBundleDirを使用している場合）に配置されていることを確認してください。

• プロキシ証明書 ( HTTPSプロキシであるため)。

• ロギング エンドポイント証明書 (例:https://log-api.newrelic.com/log/v1 )。

• インフラストラクチャ エージェント証明書 (例:https://infra-api.newrelic.com )。

  次のコマンドを実行して、証明書を確認できます。

  bash

  コピー

  $
  # openssl s_client -connect log-api.newrelic.com:443 -servername log-api.newrelic.com

独自のログをNewRelicに送信するようにインフラストラクチャエージェントを設定できます。これは、ログ転送、エージェントに関する問題のトラブルシューティング、またはサポートに連絡するときに役立ちます。

インフラストラクチャエージェントのログをNewRelicに転送するには：

1. newrelic-infra.ymlファイルを編集します。

2. 次の構成スニペットを追加して、New Relic へのログ転送を有効にします。

   log:
     level: trace # Recommended: Helps with troubleshooting
     forward: true # Enables sending logs to New Relic
     format: json # Recommended: Enable agent logging in JSON format
     stdout: false # On Windows and systems that don't use `systemd` or where `journald` is inaccessible

   コピー

3. エージェントを再起動して、新しい設定をロードします。

   この設定では、エージェントがトラブルシューティングモードに設定されますが、ログフォワーダ（ Fluent Bitに基づく）は非冗長モードで続行されます。

場合によっては、ログ フォワーダー自体に問題が発生することがあります。たとえば、Windows ログ イベントの送信時や特定のログ ファイルへのアクセス時に、特定のチャネルへのアクセスに問題が発生する場合があります。このような状況では、ログ フォワーダーの冗長モードを有効にすることもできます。

1. newrelic-infra.ymlファイルを編集します。

2. 次の構成スニペットを追加して、Fluent Bit verbose ログを有効にします。

   log:
     level: trace
     forward: true # Enables sending logs to New Relic
     format: json # Recommended: Enable agent logging in JSON format
     stdout: false # On Windows and systems that don't use `systemd` or where `journald` is inaccessible
     include_filters:
       traces:
         - supervisor # Required to see verbose logs from Fluent Bit

   コピー

3. エージェントを再起動して、新しい設定をロードします。

2016より前のバージョンのLinuxの場合、OpenSSLライブラリを1.1.0に更新する必要がある場合があります（以上）。この問題があるかどうかを確認するには：

1. 次のコマンドを実行して、 infra-agentがFluentBitを開始したかどうかを確認します。

   bash

   コピー

   $
   ps -aux | grep td-agent-bit

2. 実行されていない場合は、 /var/db/newrelic-infra/newrelic-integrations/loggingに移動して実行します。

   bash

   コピー

   $
   ./fluent-bit -i systemd -o stdout

3. 次のエラーが発生した場合は、OpenSSLを1.1.0に更新してください以上：

   error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

   コピー

Windowsでログ転送を有効にすると、次のエラーメッセージのいずれかが表示される場合があります。

The code execution cannot proceed because VCRUNTIME140.dll was not found.

また

error="exit status 3221225781" process=log-forwarder

これは、DLLが見つからないことが原因です。

この問題を解決するには、必要に応じてMicrosoft VisualC++再頒布可能パッケージをインストールします。

• x64
• x86

大量のファイルを追尾しようとすると、次のいずれかのエラーメッセージが表示されるのが一般的です。

• Too many open files

• The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource

  オペレーティングシステムは、割り当て可能なファイル記述子の最大量（通常はデフォルトで1024）と、割り当て可能なinotifyウォッチの最大量（通常はデフォルトで8192）を定義します。これらの制限を超えようとするプロセスは失敗し、上記のエラーの1つを返します。

  ログの転送に使用する基盤となるテクノロジーであるFluentBitは、1つのファイル記述子を開き、転送するように構成したファイルごとにinotifyウォッチを設定します。さらに、このセクションの執筆時点では、Fluent Bitは通常の操作に32個のファイル記述子の追加セットを使用し、シャットダウン時に別の追加ファイル記述子を使用します。したがって、大量のファイルをキャプチャするには、ファイル記述子とinotifyの監視制限の両方が、調整するログファイルの量よりもわずかに大きいことを確認する必要があります。

  次の手順は、10,000個のログファイルを追跡する場合にこれらの制限を増やす方法をまとめたものです。また、インフラストラクチャエージェントがroot 実行モードでインストールされていることを前提としているため、 rootユーザーを使用して実行する必要があります。

1. プロセスごとのファイル記述子の量の現在のハード制限を確認してください。通常、この制限は非常に高く、変更する必要はありません。

   bash

   コピー

   $
   ulimit -Hn

2. 次の行を/etc/security/limits.confに追加します。Fluent Bitが機能する必要のある追加のファイル記述子を割り当てることができるように、ここでは10000ではなく10100の制限を指定しました。

   bash

   コピー

   $
   root    soft    nofile  10100  # replace root by nri-agent for non-root (privileged and unprivileged) installations

3. 再起動時に前の制限が適用されるように、次の行を/etc/pam.d/common-sessionに追加します。

   bash

   コピー

   $
   session required pam_limits.so

4. 次の行を/etc/sysctl.confに追加して、ユーザーごとに許可されるinotifyウォッチャーの数を増やします。ここでは、 10000ではなく18192の制限を指定して、 rootユーザーが引き続き8192のinotifyウォッチ（デフォルト値）を使用できるようにしました。

   bash

   コピー

   $
   fs.inotify.max_user_watches=18192

5. システムを再起動します。

6. 次のコマンドを実行して、新しい制限が適用されていることを確認します。

   bash

   コピー

   $
   ulimit -Sn                                    # Should return 10100
   $
   cat /proc/sys/fs/inotify/max_user_watches     # Should return 18192

   開いているファイルの制限を増やす方法、またはinotifyウォッチを増やす方法の詳細をご覧ください。

バージョン1.19.0 （またはSLES 12.5の場合はバージョン1.20.3）より前は、LinuxインフラストラクチャエージェントにFluentBitバイナリがバンドルされていました。このバージョン以降、FluentBitは個別のrecommendedパッケージ依存関係として含まれるようになりました。

これは、Fluent Bitをエージェントとは別にインストール、更新、またはダウングレードできることを意味します。便宜上、インフラストラクチャが存在する同じリポジトリにいくつかのFluent Bitパッケージが含まれているため、FluentBitをアップグレードするために追加のリポジトリをインストールする必要はありません。

エージェントは、最初にインストールしたときに、利用可能な最新バージョンを使用してFluentBitを自動的にインストールすることに注意してください。最初のインストール後、Linuxパッケージで通常行うようにFluentBitをアップグレードできます。

次のコマンドを実行して、使用可能なFluentBitバージョンを一覧表示できます。

RPM：

$
sudo yum check-update
$
yum list td-agent-bit --showduplicates

DEB：

$
sudo apt update
$
apt-cache showpkg td-agent-bit

特定のFluentBitバージョンにアップグレードするには、次のコマンドを実行します（次の例では、バージョン1.8.12が使用されています）。

RPM：

$
# Remove command only required when downgrading to a previous version
$
sudo yum remove td-agent-bit
$
sudo yum install td-agent-bit-1.8.12-1

DEB：

$
sudo apt install td-agent-bit=1.8.12

td-agent-bit は次のディストリビューションでは使用できないため、ロールバックできないことに注意してください。

• CentOS 9 ストリーム (Rocky Linux および AlmaLinux を含む)

• レッドハット9

• Ubuntu 22.04.x

• オープン スース (SLES) 15.4

• Amazon Linux 2023

  td-agent-bit に戻したい場合は、以下の手順に従ってください。

1. 任意のテキスト エディタを使用してファイル /etc/newrelic-infra.yml を開きます。

2. ファイルの最後に次の行を追加します: fluent_bit_exe_path: /opt/td-agent-bit/bin/td-agent-bit。

3. 変更を保存します。

4. コマンド sudo systemctl restart newrelic-infraを実行して、インフラストラクチャ エージェントを再起動します。

   これらの手順を完了すると、インフラストラクチャ エージェントは、fluent-bit の代わりに td-agent-bit を使用するように構成されます。