インフラエージェント経由のログ転送に関するトラブルシューティング

インフラエージェントのインストール後、ログ転送が行われない場合に確認すべき項目をまとめます。

本記事では、インフラエージェント経由でのログ転送（Fluent Bit）利用時のトラブルシューティングについて記載します。
インフラエージェントのデータ自体が収集できていない場合は、インフラエージェントに関するトラブルシューティングをご参照ください。

[インフラエージェントに関するトラブルシューティング]
https://docs.newrelic.com/jp/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/no-data-appears-infrastructure/

また、インフラエージェントを経由しない Fluent Bit / Fluentd プラグイン、その他の方法によるログ転送については、各公式ドキュメントをご参照ください。

なお、以下の内容は Linux および Windows での一般的なコマンドを利用例としておりますが、すべての OS バージョンで動作を確認しているわけではありませんので、あらかじめご了承ください。

step 1. fluent-bit プロセスが起動しているかを確認

インフラエージェントは有効なログ転送設定ファイル（.yml ファイル）を認識すると、Fluent Bit プロセスを起動させます。
ps コマンドなどで fluent-bit プロセスが起動しているかをまずは確認してみましょう。
fluent-bit プロセスが起動していない場合は、次ステップの設定ファイルの有無や内容の確認に進んでください。
fluent-bit プロセスが起動している場合は、後半のログエンドポイントへのデータ送信の確認に進んでください。

• Linux での プロセス存在確認コマンド例 (ps コマンド) (プロセスが存在する場合の出力例)

$ ps auxww | grep [f]luent-bit
root        1085  0.0  1.9 807668 35872 ?        Sl   14:50   0:00 /opt/fluent-bit/bin/fluent-bit -c /tmp/fb/nr_fb_config3797089803 -e /var/db/newrelic-infra/newrelic-integrations/logging/out_newrelic.so -R /var/db/newrelic-infra/newrelic-integrations/logging/parsers.conf

• Windows での プロセス存在確認コマンド例 (Get-Process コマンドレット) (プロセスが存在する場合の出力例)

> Get-Process -Name "fluent-bit" | Format-List Name, Path

Name : fluent-bit
Path : C:\Program Files\New Relic\newrelic-infra\newrelic-integrations\logging\fluent-bit.exe

step 2. 有効なログ転送ファイルが存在するかを確認

有効な ログ転送設定ファイルとは、ログ設定ディレクトリ配下にある拡張子 .yml または .yaml のファイルを指します。
Windows の場合、拡張子が表示されない設定になっていることもあるため、念のためコマンドラインから確認することをお勧めします。

また、有効な設定ファイルが存在しない場合、Fluent Bit プロセスは起動しません。
設定ファイルが正しく作成されると （インフラエージェントサービスの再起動は不要で）インフラエージェントが設定ファイルを自動検出し、fluent-bit プロセスを起動します。

デフォルトのログ設定ディレクトリ：

• Linux: /etc/newrelic-infra/logging.d/
• Windows: C:\Program Files\New Relic\newrelic-infra\logging.d\

※ logging_configs_dir 変数などで独自のパスを指定している場合は、そのディレクトリ配下を確認してください。

• Linux での 確認例

$ ls -l /etc/newrelic-infra/logging.d/
total 24
-rw-r--r--. 1 root root    0 Feb 16 05:31 discovered.yml
-rw-r--r--. 1 root root 1638 Feb 11 18:20 file.yml.example
-rw-r--r--. 1 root root 1174 Feb 11 18:20 fluentbit.yml.example
-rw-r--r--. 1 root root  432 Feb 16 05:31 logging.yml
-rw-r--r--. 1 root root 2763 Feb 11 18:20 syslog.yml.example
-rw-r--r--. 1 root root  931 Feb 11 18:20 systemd.yml.example
-rw-r--r--. 1 root root 1098 Feb 11 18:20 tcp.yml.example

• Windows での 確認例

> dir "C:\Program Files\New Relic\newrelic-infra\logging.d"


    Directory: C:\Program Files\New Relic\newrelic-infra\logging.d


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         2/11/2026   6:15 PM           1703 file.yml.example
-a----         2/11/2026   6:15 PM           1201 fluentbit.yml.example
-a----         2/16/2026   1:58 AM           1118 logs.yml
-a----         2/11/2026   6:15 PM           1129 tcp.yml.example
-a----         2/11/2026   6:15 PM           1546 winlog.yml.example

step 3. すべての有効なログ転送ファイルに文法エラーがないかを確認

ログ転送設定ファイルは YAML 形式で記述する必要があります。
YAML の書式では、行頭のスペース (空白) の数 で階層を表現するため、行頭のスペースの数に注意が必要です。

また、有効な設定ファイルのうち、1つでも 文法エラーがあると Fluent Bit プロセスは起動しません。 すべての設定ファイルをチェックしてください。

YAML 文法は、複雑な場合もあるため、チェッカーサイトを使用するなどで機械的なチェックを行うことを推奨します。ただ、オンラインサイトを利用する場合は、漏洩につながる可能性があるので、シークレット情報の記載がある場合は、必ずマスクするようにしてください。

[yaml チェックサイトの例 ((YAML Lint)]
https://www.yamllint.com/

また、文法エラーがある場合は、デフォルトのログレベルでも以下のようなエラーログが出力されます。

level=error msg="could not parse YAML file"
component=integrations.Supervisor.Loader
error="yaml: line 3: mapping values are not allowed in this context"
file="C:\\Program Files\\New Relic\\newrelic-infra\\logging.d\\mylogs.yml" process=log-forwarder

level=error msg="cannot build supervisor executor
component=integrations.Supervisor
error="failed to load log configs" process=log-forwarder

step 4. ログ転送に必要なパッケージ、関連ライブラリがインストールされているかを確認

ログ転送では、fluent-bit パッケージや newrelic の fluent-bit プラグインなどの関連ファイルが利用されます。
関連パッケージやファイルが存在しているかを確認しておきましょう。
また、Linux tarball でインストールされている場合は、ログ転送を利用するには、別途追加でパッケージや設定ファイルを取得、配置する必要があります。

詳細は公式ドキュメントを参照してください。
[Linux tarballを使用してインストールされたエージェントでログ転送を有効にする]
https://docs.newrelic.com/jp/docs/logs/forward-logs/forward-your-logs-using-infrastructure-agent/#tarball-install

コマンドでの確認例:

$ rpm -qa fluent-bit
fluent-bit-4.2.2-1.x86_64

$ ls -l /var/db/newrelic-infra/newrelic-integrations/logging/out_newrelic.so
-rw-r--r--. 1 root root 9777160 Feb 11 18:21 /var/db/newrelic-infra/newrelic-integrations/logging/out_newrelic.so

$ ls -l  /var/db/newrelic-infra/newrelic-integrations/logging/parsers.conf
-rw-r--r--. 1 root root 909 Feb 11 18:20 /var/db/newrelic-infra/newrelic-integrations/logging/parsers.conf

(fluent-bit の依存パッケージは Distribution によって異なる場合があるため、未記載とします)

必要なファイルやパッケージが未導入の場合、ドキュメント記載の手順にしたがって、セットアップを完了させてください。
ここまでの確認で、fluent-bit プロセスが起動していない場合は、ログを取得し、確認しましょう。(後述のデバッグレベルログの出力を確認へ)

step 5. ログ API エンドポイントにデータを送信できるかを確認

fluent-bit プロセスは起動しているが、ログデータが転送されない、という場合は、ネットワーク的な要因が問題の可能性があります。
アクセス制限を行っているような場合は、ログ API エンドポイントにポストアクセスができるかを実際にデータを送信して確認してみましょう。

[Log API を使用してログ データを送信します]
https://docs.newrelic.com/jp/docs/logs/log-api/introduction-log-api/

また、プロキシを利用している場合は、必要に応じてコマンドオプションを追加ください。
コマンド実行ユーザーに環境変数などでプロキシが設定されている場合もあるため、ご注意ください。

下記コマンド例の ”ライセンスキー” には、newrelic-infra.yml に記載された license_key の値を使用ください。
また、リージョンが US 以外の場合、利用リージョンの url を指定ください。

• Linux (curl コマンド) でのデータ送信例:

$ INSERT_KEY=”ライセンスキー”
$ url=”https://log-api.newrelic.com/log/v1”
$ curl -X POST $url \
  -H "Content-Type: application/json" \
  -H "Api-Key: $INSERT_KEY" \
  -d @- <<EOS
{
  "message": "this is log test message",
  "hostname": "`hostname`"
}
EOS

• Windows (Invoke-RestMethod コマンドレット) でのデータ送信例:

> $insert_key = "ライセンスキー"
> $url = "https://log-api.newrelic.com/log/v1"
> $body = @{ message = "this is log test message"; hostname = (hostname) } | ConvertTo-Json
> $headers = @{"ContentType" = "application/json"; "Api-Key" = "$insert_key"}
> Invoke-RestMethod -Uri $url -Method Post -Body $body -Headers $headers

上記のコマンドで、ログ転送が成功した場合は 下記の NRQL にて確認いただけます。

SELECT message, hostname, * FROM Log WHERE message like 'this is log test message'

※ UTF-8 以外の文字コード (Shift-JIS など) の場合、文字化けしてしまう場合があります。
インフラエージェント経由のログ転送の場合は、文字コードを変換して送信する機能がないため、fluentd プラグインなどを利用した回避を検討ください。

[fluentdを用いたNew RelicプラットフォームへのShift_JISログの連携方法]
https://newrelic.com/jp/blog/log/log-management-for-shift-jis-logs-with-fluentd

[fluentd を用いた Windows イベントログ連携]
https://newrelic.com/jp/blog/observability/log-management-for-shift-jis-eventlog-with-fluentd

step 6. デバッグレベルログの出力を確認

原因が特定できない場合は newrelic-infra.yml を編集して デバッグレベル (またトレースレベル) のログを取得し、エラーの有無などを確認してみましょう。
newrelic-infra.yml に log: 以下を追記し、インフラエージェントサービスを再起動ください。
file に指定したパスにログが出力されます。

• Linux

log:
  file: '/var/log/newrelic-infra/newrelic-infra.debug.log'
  level: debug
  stdout: false

(ログに関して指定されていない場合、デフォルトでは、標準出力 (RHEL の場合は、多くの場合 /var/log/messages) に info レベルで出力されます。)

• Windows

log:
  file: 'C:\Program Files\New Relic\newrelic-infra\newrelic-infra.debug.log'
  level: debug
  stdout: false

(ログに関して指定されていない場合、デフォルトでは、下記のパスに info レベルで出力されます。
C:\%ProgramData%\New Relic\newrelic-infra\newrelic-infra.log)

また、debug, trace ログ出力は、出力量が多く、肥大化しやすいため
数分 (2, 3 分) 程度の実行後に newrelic-infra.yml を再編集 (またはデフォルトの info レベルに設定)、サービスの再起動を実施いただき、元の設定に戻してください。

その他. ドキュメント記載の事例を確認

ドキュメントにも一般的なトラブルシューティングが記載されており、一部重複しますが、合わせてご確認ください。

[infrastructureエージェントを用いたログの転送 > トラブルシューティング]
https://docs.newrelic.com/jp/docs/logs/forward-logs/forward-your-logs-using-infrastructure-agent/#troubleshoot

対象ログファイルパスに * (アスタリスク) が使用されており、追記ファイルが多い場合などの事例や openssl のバージョンが古い場合の事例などが記載されていますので、本ブログポストの内容で解決できなかった場合は、ドキュメントの内容も確認してみてください。