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

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

Example:

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 。ファイルパス内のディレクトリの代わりにワイルドカードを使用できます。これを使用して、別のディレクトリにあるファイルを調整できます。

Example:

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

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

Example:

logs:
  - name: systemd-example
    systemd: cupsd

Syslogデータソース。

Parameters:

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

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

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

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

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

  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接続を介して取得されたログ。

Parameters:

• 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ログチャネルからイベントを収集します。

Parameters:

• channel: ログが収集されるチャネルの名前。

• collect-eventids: 収集され、New Relic に転送される 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よりも優先されます。

  Example:

  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ログチャネルからイベントを収集します。

Parameters:

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

• collect-eventids: 収集され、New Relic に転送される 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よりも優先されます。

  Example:

  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属性を指定することです。 この属性により、New Relic のログ管理機能でサポートされる組み込みの解析ルールの1 つを利用できるようになります。

Example:

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 のデフォルト設定をオーバーライドできます。

Parameters:

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

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

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

Example:

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

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

Example:

$
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 アクセスとエラー ログの解析と New Relic への転送を有効にします。エージェントを再起動する必要はありません。

Example:

$
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 エラー ログの自動解析と New Relic への転送を有効にします。エージェントを再起動する必要はありません。

Example:

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

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

Example:

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

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

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

Example: Check file access under 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プロキシの場合は、証明書を設定する必要はありません。 プラグインはシステム証明書をロードし、New Relic はログをロギングエンドポイントに送信します。 ただし、 caBundleFileまたはcaBundleDirのいずれかを使用して、プロキシの自己署名証明書 (PEM ファイル) を指定できます。

Windows

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

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

  • (推奨) プロキシ証明書をシステム プールにインポートします。 MMC ツールを使用して、プロキシ自己署名証明書 (PEM ファイル) をインポートします。 このリンクを参照し、 Step 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 の詳細ログを有効にします。

   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 fluent-bit

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

   bash

   コピー

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

3. 次のエラーが発生した場合:

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

   コピー

   OpenSSL を 1.1.0 に更新してください。以上。

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つを返します。

  ログの転送に使用する基盤テクノロジーであるFluent Bit は、1 つのファイル記述子を開き、転送するように設定した各ファイルに対して inotify ウォッチを設定します。 さらに、このセクションの執筆時点では、Fluent Bit は通常の動作に 32 個のファイル記述子の追加セットを使用し、シャットダウン時に別の追加のファイル記述子を使用します。 したがって、 to capture a large amount of files you need to ensure that both the file descriptor and inotify watch limits are slightly greater than the amount of log files you wish to tail 。

  次の手順は、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 fluent-bit --showduplicates

DEB：

$
sudo apt update
$
apt-cache showpkg fluent-bit

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

RPM：

$
# Remove command only required when downgrading to a previous version
$
sudo yum remove fluent-bit
$
sudo yum install fluent-bit-2.2.2-1

DEB：

$
sudo apt install fluent-bit=2.2.2

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 を使用するように構成されます。