ログを New Relic に転送すると、すべてのログ データが 1 か所で利用できるようになり、アプリケーションとプラットフォームのパフォーマンス データの両方をより詳細に可視化できます。ログを 1 か所にまとめて、ログ データで見つかったエラーや異常を収集、処理、調査、クエリ、およびアラートできます。
ホストの UI から、選択した期間のイベントのコンテキストにログが配置されます。強調表示された属性の詳細データにドリルダウンできます。
インフラストラクチャ エージェントはログ転送機能を有効にするため、ログの転送方法はインフラストラクチャ エージェントのインストール方法によって異なります。次の方法でインフラストラクチャ エージェントをインストールできます。
- ガイド付きインストール (ほとんどのユーザーに推奨)
- 手動インストール
- Linux ターボール
- インフラストラクチャ・エージェント・バージョン1.11.4以上
- 流暢なビット。インフラストラクチャエージェントは、すでに最新バージョンをインストールしています。特定のバージョンに更新またはダウングレードするには、FluentBitのインストール手順を参照してください。
- OpenSSL ライブラリ 1.1.0以上
- LinuxシステムでのARM64アーキテクチャ(AWS Gravitonアーキテクチャなど)の組み込みサポートがインフラストラクチャエージェント1.20.6に追加されました。
- Amazon Linux 2
- CentOS バージョン 7 以降
- Debian バージョン 9 (「ストレッチ」) 以降。バージョン 11 はサポートされていません。
- SUSE Linux Enterprise Server (SLES) バージョン 12
- Ubuntu バージョン 16.04.x、18.04.xおよび 20.04.x (LTS バージョン)
- Windows Server 2012、2016、2019、および 2022、およびそれらのサービス パック
- ウィンドウズ10
ガイド付きインストールによるログの自動転送
ガイド付きインストールを使用してインフラストラクチャ エージェントをインストールすると、インストール プロセス中にログ転送機能が自動的に構成されます。
インストールを開始するには、展開方法を選択します。
手動でインストールされたエージェントでログ転送を有効にする
インフラストラクチャ エージェントを手動でインストールするには、 チュートリアルに従ってパッケージ マネージャーをインストールするか、 MSI インストーラー(Windows) を確認してください。
手順 1.インフラストラクチャ エージェントを構成する
構成ファイルは、New Relic に表示するログ ソースをシステムに転送するように指示します。構成ファイルはいくつでも追加できます。インフラストラクチャ エージェントは、 .yml
ファイルを使用してロギングを構成します。UI の [データの追加]からインフラストラクチャ エージェントをインストールすると、ファイルlogging.yml
が自動的に作成されます。
ログ転送機能の新しい構成ファイルを追加するには、次のようにします。
ログフォワーダー構成フォルダーに移動します。
- Linux:
/etc/newrelic-infra/logging.d/
- ウィンドウズ:
C:\Program Files\New Relic\newrelic-infra\logging.d\
- Linux:
logging.yml
構成ファイルを作成し、必要なパラメーターを追加します。logging.d
ディレクトリには、参照または開始点として使用できるさまざまな.yml.example
ファイルがあります。
エージェントは、インフラストラクチャ監視サービスを再起動しなくても、新しい構成ファイルを自動的に処理します。これに対する唯一の例外は、カスタムFluentBit構成を構成する場合です。
ステップ 2. ログ転送パラメーターを設定する
ログ転送.yml
構成ファイルでname
およびログ ソース パラメータを設定する必要があります。まず、New Relic に転送するログのname
を定義します。
ログ ソースに何を使用するかは、ログのソースとなる場所によって異なります。ログ ソースに使用できるオプションは次のとおりです。
ログ ファイルへのパス。エージェントは、 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
重要
ワイルドカードを使用すると、ファイル記述子の数が大幅に増加し、Fluent Bitプロセスが開いたままになるのを監視します。これにより、ホストのファイル記述子の制限に達した場合にログの収集が妨げられる可能性があります。多数のファイルをテーリングするには、ファイル記述子の最大数を増やし、オペレーティングシステムで許可されているウォッチャーをinotifyする必要がある場合があります。ログファイルを増やす方法の詳細については、大量のログファイルをテーリングするときのエラーを参照してください。
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
- TCP / UDPネットワークソケット:
parser:
Syslogパーサー。デフォルトはrfc3164
です。メッセージに秒の小数部が含まれている場合は、rfc5424
を使用します。注:rfc3164
は現在SuSEでは機能しません。unix_permissions:
ドメインソケットのデフォルトは0644
です。これにより、エントリはルートとして実行されているプロセスに制限されます。0666
を使用して、自己責任で非ルートプロセスをリッスンできます。エージェントを特権モードで実行する場合、他のプロセスがソケットにログを書き込めるように、ポートとソケットは
0666
nri-agent
によって使用可能であるか、所有されている必要があります。logs:# TCP network socket- name: syslog-tcp-testsyslog:uri: tcp://0.0.0.0:5140 # Use the tcp://LISTEN_ADDRESS:PORT formatparser: rfc5424 # Default syslog parser is rfc3164# UDP network socket- name: syslog-udp-testsyslog:uri: udp://0.0.0.0:6140 # Use the udp://LISTEN_ADDRESS:PORT formatmax_line_kb: 35# Unix TCP domain socket- name: syslog-unix-tcp-testsyslog:uri: unix_tcp:///var/unix-tcp-socket-testunix_permissions: 0666 # Default is 0644. Change at your own risk# Unix UDP domain socket- name: syslog-unix-udp-testsyslog:uri: unix_udp:///var/unix-udp-socket-testparser: rfc5424
TCP接続を介して取得されたログ。
パラメーター:
uri:
着信データをリッスンするTCP/IPソケット。URI形式はtcp://LISTEN_ADDRESS:PORT
format:
データのフォーマット。json
またはnone
にすることができます。separator:
format: none
を使用する場合は、レコードを分割するための区切り文字列を定義できます(デフォルト:\n
)。logs:- name: tcp-simple-testtcp:uri: tcp://0.0.0.0:1234 # Use the tcp://LISTEN_ADDRESS:PORT formatformat: none # Raw text - this is default for 'tcp'separator: \t # String for separating raw text entriesmax_line_kb: 32- name: tcp-json-testtcp:uri: tcp://0.0.0.0:2345 # Use the tcp://LISTEN_ADDRESS:PORT formatformat: json
重要
インフラストラクチャエージェントv.1.24.3以降で使用可能
winevtlog Fluent Bitプラグインを使用して、新しいWindowsイベントログAPIを使用してWindowsログチャネルからイベントを収集します。
パラメーター:
channel:
チャネルログの名前はから収集されます。collect-eventids:
収集されてNewRelicに転送されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。exclude-eventids:
コレクションから除外されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。デフォルトでは、すべてのイベントは指定されたチャネルから収集されます。New Relicアカウントに不要なログが送信されないように、
collect-eventids
セクションとexclude-eventids
セクションを構成します。イベントIDまたは範囲を
collect-eventids
またはexclude-eventids
に追加して、特定のイベントを転送またはドロップします。同じイベントIDが両方のセクションに存在する場合、exclude-eventids
はcollect-eventids
よりも優先されます。例:
logs:# Winevtlog log ingestion with eventId filters.- name: windows-securitywinevtlog:channel: Securitycollect-eventids:- 4624- 4265- 4700-4800exclude-eventids:- 4735# entries for the application, system, powershell, and SCOM channels- name: windows-applicationwinevtlog:channel: Application- name: windows-systemwinevtlog:channel: System- name: windows-pshellwinevtlog:channel: Windows Powershell- name: scomwinevtlog:channel: Operations Manager# Entry for Windows Defender Logs- name: windows-defenderwinevtlog:channel: Microsoft-Windows-Windows Defender/Operational# Entry for Windows Clustering Logs- name: windows-clusteringwinevtlog:channel: Microsoft-Windows-FailoverClustering/Operational# Entry for IIS logs with logtype attribute for automatic parsing- name: iis-logfile: C:\inetpub\logs\LogFiles\w3svc.logattributes:logtype: iis_w3c
重要
Winlog は従来のイベント ログのみを収集できます。他のユーザーをキャプチャしようとすると、サイレント モードでアプリケーション ログが収集されます。
Windowsログチャネルからイベントを収集します。
パラメーター:
channel:
チャネルログの名前はから収集されます。カスタムチャネルでは機能しません。collect-eventids:
収集されてNewRelicに転送されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。exclude-eventids:
コレクションから除外されるWindowsイベントIDのリスト。イベントIDの範囲がサポートされています。デフォルトでは、すべてのイベントは指定されたチャネルから収集されます。New Relicアカウントに不要なログが送信されないように、
collect-eventids
セクションとexclude-eventids
セクションを構成します。イベントIDまたは範囲を
collect-eventids
またはexclude-eventids
に追加して、特定のイベントを転送またはドロップします。同じイベントIDが両方のセクションに存在する場合、exclude-eventids
はcollect-eventids
よりも優先されます。例:
logs:# Winlog log ingestion with eventId filters.- name: windows-securitywinlog:channel: Securitycollect-eventids:- 4624- 4265- 4700-4800exclude-eventids:- 4735# entries for the application, system, powershell, and SCOM channels- name: windows-applicationwinlog:channel: Application- name: windows-systemwinlog:channel: System- name: windows-pshellwinlog:channel: Windows Powershell- name: scomwinlog:channel: Operations Manager# Entry for Windows Defender Logs- name: windows-defenderwinlog:channel: Microsoft-Windows-Windows Defender/Operational# Entry for Windows Clustering Logs- name: windows-clusteringwinlog:channel: Microsoft-Windows-FailoverClustering/Operational# Entry for IIS logs with logtype attribute for automatic parsing- name: iis-logfile: C:\inetpub\logs\LogFiles\w3svc.logattributes:logtype: iis_w3c
ステップ 3. 主要な属性を定義する
これらの構成パラメータは必須ではありませんが、これらの構成をlogging.yml
ファイルに適用して、ログ転送を最大限に活用することをお勧めします。
キーと値のペアとして指定されたカスタム属性のリスト。ログとともに追加のデータを送信するために使用でき、その後クエリを実行できます。attributes
構成パラメーターは、任意のログソースで使用できます。
重要
attributes
構成パラメーターは、外部Fluent Bit構成を介して(たとえば、 fluentbit
構成パラメーターを使用して)転送されるログにカスタム属性を追加しません。このシナリオでは、 FluentBitドキュメントのrecord_modifier
オプションを参照する必要があります。
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
インフラストラクチャエージェントは、便宜上、ログ属性を自動的に挿入します。それらのいくつかはログレコードに挿入されますが、その他はログフォワーダーのセットアップ中に使用した構成パラメーターに依存します。
属性名 | 説明 |
---|---|
| 常に挿入されます。 インフラストラクチャエージェントは、New Relicによって割り当てられたエンティティGUIDを挿入して、実行されているホストを識別します。 注:キャプチャされたログがAPMを使用してインストルメント化されたアプリケーションに属している場合、 |
| 常に挿入されます。 ログのキャプチャに使用される基になるFluentBit入力プラグインタイプ。現在、その値は |
|
監視対象のファイルの絶対ファイルパス。 |
| 常に挿入されます。 インフラストラクチャエージェントを実行しているマシン/VM/コンテナのホスト名。 |
| 常に挿入されます。 ログのキャプチャに使用されるユーティリティを示します。この場合、それはインフラストラクチャエージェント自体であるため、この属性の値は常に |
レコードをフィルタリングするための正規表現。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
。
重要
インフラストラクチャエージェントでは、このドキュメントで説明されているように、 logging.d/
ディレクトリのYAMLファイルで単純なログ転送構成を定義することにより、最も一般的なユースケースのログを転送できます。これらのファイルは、適切な形式と適切な構成デフォルトでFluentBit構成ファイルに内部的に変換されます。New Relicは、生成された構成ファイルが正しく機能することを保証するため、これらの構成オプションの公式サポートを提供します。
それでも、サポートされている構成オプションでカバーされていないユースケースでは、 fluentbit
、 config_file
、およびparsers_file
オプションを使用して外部で生成されたFluentBit構成およびパーサーファイルを使用する可能性を提供します。
この場合、提供された構成は完全に任意であり、エージェントによって生成/検証されていないため、転送されたログの正しい動作を保証できないことに注意してください。したがって、New Relicは、これらのオプションで指定された外部構成を公式にサポートしていません。
サンプル構成ファイル
YAML形式のlogging.d/
構成ファイルの例を次に示します。その他の構成例については、インフラストラクチャエージェントリポジトリを参照してください。
# Remember to only use spaces for indentation
logs: # Example of 'file' source - name: file-with-attributes file: /var/log/test.log # Path to a single file or pattern attributes: # You can use custom attributes to enrich your data logtype: nginx team: The A Team pattern: Error # Regular expression to filter log entries
# Example of 'systemd' source (Linux only) - name: systemd-example systemd: cupsd
# Examples of 'syslog' source, one per protocol # 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
# Paths for Unix sockets are defined by combining protocol and path: # unix_udp:// + /path/socket - for example, unix_udp:///tmp/socket # 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
# Examples of 'tcp' source for formats 'none' and 'json' - 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 attributes: # You can add custom attributes to any source of logs tcpFormat: none someOtherAttribute: associatedValue 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 attributes: tcpFormat: json yetAnotherAttribute: 12345
# Example of Fluent Bit configuration import - name: fluentbit-import fluentbit: config_file: /path/to/fluentbit.config parsers_file: /path/to/fluentbit/parsers.conf
ステップ 4. ログデータを表示する
すべてが正しく構成され、データが収集されている場合は、次の場所にログと関連するテレメトリデータが表示されます。
- New Relic UI で選択したホストの概要ページ: one.newrelic.com > ExplorerまたはInfrastructure > Hosts > (エンティティを選択) > Logsに移動します。
- NewRelicのログUI
- NRQLクエリを実行するための新しいRelicツール。たとえば、次のようなクエリを実行できます。
SELECT * FROM Log
オンホスト統合のログを有効にする
インフラストラクチャエージェントをインストールすると、最も一般的なオンホスト統合の自動ログ解析と転送を1つのステップで有効にできます。この機能を有効にするには、 on-host-log.yml.example
ファイルの名前をon-host-log.yml
に変更します。完了すると、統合のログが自動的に解析され、NewRelicに送信されます。
このオプションは、サポートされているLinuxプラットフォームで使用できます。
オンホスト統合ログ転送機能を有効にするには:
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
Linuxtarballを使用してインストールされたエージェントでログ転送を有効にする
インフラストラクチャ監視用のカスタムLinuxインストールプロセスを使用すると、インストールプロセスのすべての側面を調整し、ファイルとフォルダーをマシンに配置できます。支援または手動のtarballインストールプロセスを選択した場合は、次の手順に従ってログフォワーダー機能を実装します。
- 次のディレクトリを作成します。
/var/db/newrelic-infra/newrelic-integrations/logging
/etc/newrelic-infra/logging.d
次のようなコマンドを実行して、New Relicのfluent-bit-package(RPM)をダウンロードしてインストールします。
bash$yum localinstall td-agent-bit-<some-version>.rpm`New Relicのfluentbitプラグインをダウンロードし、
/var/db/newrelic-infra/newrelic-integrations/logging/out_newrelic.so
として保存します。この Github リポジトリから
parsers.conf
ファイルをダウンロードまたはコピーし、/var/db/newrelic-infra/newrelic-integrations/logging/parsers.conf
として保存します。
Did this doc help with your installation?
トラブルシューティング
ログフォワーダーの構成で問題が発生した場合は、次のトラブルシューティングのヒントを試してください。
ログ管理機能を有効にしてもデータが表示されない場合は、標準のログトラブルシューティング手順に従ってください。
ログ転送機能では、エージェントがデータソースを読み取るためのアクセス許可を持っている必要があります。インフラストラクチャエージェントを特権モードまたは非特権モードで実行する場合は、転送するログファイル(およびそのパス内の中間ディレクトリ)が、 nri-agent
を実行しているユーザーが読み取れることを確認してください。
例:Linuxでのファイルアクセスの確認
nri-agent
ユーザーがファイル/var/log/restrictedLogs/logFile.log
を監視できるかどうかを確認しましょう。Linuxでは、 namei
コマンドを使用して簡単なチェックを行うことができます。
sudo -u nri-agent namei -ml /var/log/restrictedLogs/logFile.logf: /var/log/restrictedLogs/logFile.logdrwxr-xr-x root root /drwxr-xr-x root root vardrwxrwxr-x root syslog logdrwxr--r-- root root restrictedLogslogFile.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.logf: /var/log/restrictedLogs/logFile.logdrwxr-xr-x root root /drwxr-xr-x root root vardrwxrwxr-x root syslog logdrwxr-xr-x root root restrictedLogs-rw-r----- vagrant vagrant logFile.log
これで、ファイルはnri-agent
ユーザーに表示されます。nri-agent
ユーザーもファイルを読み取れるようにする必要があります。これを確認するには、次を使用します。
# sudo -u nri-agent head /var/log/restrictedLogs/logFile.loghead: 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
)。次のコマンドを実行して、証明書を確認できます。
# openssl s_client -connect log-api.newrelic.com:443 -servername log-api.newrelic.com
独自のログをNewRelicに送信するようにインフラストラクチャエージェントを設定できます。これは、ログ転送、エージェントに関する問題のトラブルシューティング、またはサポートに連絡するときに役立ちます。
重要
トレース ログは、大量のデータを非常に迅速に生成します。ディスク容量の消費とデータの取り込みを減らすために、ログの生成が終了したら、必ずlevel: info
(またはそれ以下) を設定してください。
インフラストラクチャエージェントのログをNewRelicに転送するには:
newrelic-infra.yml
ファイルを編集します。次の構成スニペットを追加して、New Relic へのログ転送を有効にします。
log:level: trace # Recommended: Helps with troubleshootingforward: true # Enables sending logs to New Relicformat: json # Recommended: Enable agent logging in JSON formatstdout: false # On Windows and systems that don't use `systemd` or where `journald` is inaccessibleエージェントを再起動して、新しい設定をロードします。
この設定では、エージェントがトラブルシューティングモードに設定されますが、ログフォワーダ( Fluent Bitに基づく)は非冗長モードで続行されます。
場合によっては、ログ フォワーダー自体に問題が発生することがあります。たとえば、Windows ログ イベントの送信時や特定のログ ファイルへのアクセス時に、特定のチャネルへのアクセスに問題が発生する場合があります。このような状況では、ログ フォワーダーの冗長モードを有効にすることもできます。
重要
トレース ログは、大量のデータを非常に迅速に生成します。ディスク容量の消費とデータの取り込みを減らすために、ログの生成が終了したら、必ずlevel: info
(またはそれ以下) を設定してください。
newrelic-infra.yml
ファイルを編集します。次の構成スニペットを追加して、Fluent Bit verbose ログを有効にします。
log:level: traceforward: true # Enables sending logs to New Relicformat: json # Recommended: Enable agent logging in JSON formatstdout: false # On Windows and systems that don't use `systemd` or where `journald` is inaccessibleinclude_filters:traces:- supervisor # Required to see verbose logs from Fluent Bitエージェントを再起動して、新しい設定をロードします。
重要
FluentBitのテールプラグインはネットワークドライブをサポートしていません。
2016より前のバージョンのLinuxの場合、OpenSSLライブラリを1.1.0に更新する必要がある場合があります(以上)。この問題があるかどうかを確認するには:
次のコマンドを実行して、
infra-agent
がFluentBitを開始したかどうかを確認します。ps -aux | grep td-agent-bit実行されていない場合は、
/var/db/newrelic-infra/newrelic-integrations/logging
に移動して実行します。./fluent-bit -i systemd -o stdout次のエラーが発生した場合は、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++再頒布可能パッケージをインストールします。
大量のファイルを追尾しようとすると、次のいずれかのエラーメッセージが表示されるのが一般的です。
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
ユーザーを使用して実行する必要があります。
プロセスごとのファイル記述子の量の現在のハード制限を確認してください。通常、この制限は非常に高く、変更する必要はありません。
ulimit -Hn次の行を
/etc/security/limits.conf
に追加します。Fluent Bitが機能する必要のある追加のファイル記述子を割り当てることができるように、ここでは10000
ではなく10100
の制限を指定しました。root soft nofile 10100 # replace root by nri-agent for non-root (privileged and unprivileged) installations再起動時に前の制限が適用されるように、次の行を
/etc/pam.d/common-session
に追加します。session required pam_limits.so次の行を
/etc/sysctl.conf
に追加して、ユーザーごとに許可されるinotifyウォッチャーの数を増やします。ここでは、10000
ではなく18192
の制限を指定して、root
ユーザーが引き続き8192
のinotifyウォッチ(デフォルト値)を使用できるようにしました。fs.inotify.max_user_watches=18192システムを再起動します。
次のコマンドを実行して、新しい制限が適用されていることを確認します。
ulimit -Sn # Should return 10100cat /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-updateyum list td-agent-bit --showduplicates
DEB:
sudo apt updateapt-cache showpkg td-agent-bit
特定のFluentBitバージョンにアップグレードするには、次のコマンドを実行します(次の例では、バージョン1.8.12
が使用されています)。
RPM:
# Remove command only required when downgrading to a previous versionsudo yum remove td-agent-bitsudo yum install td-agent-bit-1.8.12-1
DEB:
sudo apt install td-agent-bit=1.8.12
次は何ですか?
Logs UIを使用して、プラットフォーム全体のログデータを調べます。
- ログインコンテキスト機能を使用してログを転送することにより、アプリケーションとプラットフォームのパフォーマンスデータの両方をより深く把握できます。
- アラートを設定します。
- データをクエリし、ダッシュボードを作成します。
ログ転送を無効にする
ログ転送機能を無効にするには、 logging.d
ディレクトリに移動し、構成プロセス中に最初に追加された.yml
拡張子のファイルを削除します。
- Linux:
/etc/newrelic-infra/logging.d/
- ウィンドウズ:
C:\Program Files\New Relic\newrelic-infra\logging.d\