インフラストラクチャ監視エージェントを使用して、ログをNewRelicに転送できます。これにより、すべてのログデータを1つの場所で利用できるようになり、アプリケーションとプラットフォームのパフォーマンスデータの両方をより詳細に把握できるようになります。
ログをNewRelicに転送すると、ログデータを収集、処理、探索、クエリ、アラートするための拡張ログ管理機能が提供されます。アプリとホストのコンテキストでのログが問題の根本原因を見つけるのにどのように役立つかを確認するには、この短いビデオ(約3:40分):
基本的なプロセス ガイド付きインストールプロセスを使用して、ログ管理とインフラストラクチャ監視をすばやく簡単に一緒にインストールできます。ガイド付きインストールプロセスの仕組みと、New Relicに表示されるログデータの使用方法については、YouTubeでこのNerdlogビデオをご覧ください(14:46分)。
インフラストラクチャ監視エージェントを介してログを転送するには:
まだ作成していない場合は、NewRelicアカウントを作成します 。それは永遠に無料です。 ログの構成に必要なシステム要件 を確認します。 インフラストラクチャエージェント、バージョン1.11.4以降がインストールされ ていることを確認してください。(UIでガイド付きインストールを使用する場合は、次の手順をスキップしてください。)インフラストラクチャエージェントのlogging.d
ディレクトリにlogging.yml
構成ファイル を作成します。 ログソースとその他のパラメータを設定 します。 トラフィックを生成して数分待ってから、アカウントのデータを確認してください 。 ログUIでログデータ を調べ、インフラストラクチャエージェントによって自動的に挿入されたログ属性を利用します。 ホストのUIのログの例を次に示します。選択した期間のイベントのコンテキストでログを表示し、強調表示された属性の詳細データにドリルダウンできます。さらに詳細なデータを調べるには、クエリを実行するか、[ログで開く]を クリックします。
これは、イベントに関連するコンテキストでのホストのログの例です。
オンホスト統合のログを有効にする インフラストラクチャエージェントをインストールすると、最も一般的なオンホスト統合の自動ログ解析と転送を1つのステップで有効にできます。この機能を有効にするには、 on-host-log.yml.example
ファイルの名前をon-host-log.yml
に変更します。完了すると、統合のログが自動的に解析され、NewRelicに送信されます。
このオプションは、サポートされているLinuxプラットフォーム で使用できます。
オンホスト統合ログ転送機能を有効にするには:
Elasticsearchログ 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ログ 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ログ 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ログ 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ログ 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
システム要求 インフラストラクチャエージェントのログフォワーダーを使用するには、次の要件を満たしていることを確認してください。
インフラストラクチャエージェントバージョン1.11.4以降。 流暢なビット 。インフラストラクチャエージェントは、すでに最新バージョンをインストールしています。特定のバージョンに更新またはダウングレードするには、FluentBitのインストール 手順を参照してください。OpenSSLライブラリ1.1.0バージョン1.16.4以降のインフラストラクチャエージェントには、またはそれ以上が必要です。 LinuxシステムでのARM64アーキテクチャ(AWS Gravitonアーキテクチャなど)の組み込みサポートがインフラストラクチャエージェント1.20.6 に追加されました。 ログ転送機能は、次のオペレーティングシステムと互換性があります。
オペレーティング·システム
サポートされているバージョン
Amazon Linux
Amazon Linux 2
CentOS
バージョン7以降
Debian
バージョン9(「ストレッチ」)以降
例外: バージョン11はサポートされていません。
Red Hat Enterprise Linux(RHEL)
バージョン7以降
SUSE Linux Enterprise Server(SLES)
バージョン12
Ubuntu
バージョン16.04.x、18.04.xおよび20.04.x(LTSバージョン)
ウィンドウズ
Windows Server 2012、2016、2019、2022、およびそれらのサービスパック。
ウィンドウズ10
インフラストラクチャエージェントをインストールします バージョン1.11.4以降、インフラストラクチャエージェントはログをNewRelicに転送できます。エージェントをインストールして実行する には、 パッケージマネージャー (Linux)またはMSIインストーラー (Windows)を使用します。
重要 LinuxtarballまたはWindowsZIPインストールを使用してインフラストラクチャエージェントが実装されている場合、ログ転送機能は含まれていません。
次のリンクを使用するには、NewRelicアカウントにログインしていることを確認してください。
New Relicアカウントをまだお持ちでない場合、または手順を手動で実行する場合は、 チュートリアルを参照してパッケージマネージャーをインストールして ください。
Linuxtarballを使用してインストールされたエージェントでログ転送を有効にする インフラストラクチャ監視用のカスタムLinuxインストールプロセスを使用すると、インストールプロセスのすべての側面を調整し、ファイルとフォルダーをマシンに配置できます。支援 または手動 のtarballインストールプロセスを選択した場合は、次の手順に従ってログフォワーダー機能を実装します。
次のディレクトリを作成します。 /var/db/newrelic-infra/newrelic-integrations/logging
/etc/newrelic-infra/logging.d
次のようなコマンドを実行して、New Relicのfluent-bit-package(RPM) をダウンロードしてインストールします。
$ 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
として保存します。
構成ファイルは、転送されるログソースを記述します。インフラストラクチャエージェントは、 .yml
ファイルを使用してログを構成します。必要な数の構成ファイルを追加できます。
ログ転送機能の新しい構成ファイルを追加するには、次のようにします。
ログフォワーダー構成フォルダーに移動します。
Linux: /etc/newrelic-infra/logging.d/
ウィンドウズ: C:\Program Files\New Relic\newrelic-infra\logging.d\
logging.yml
構成ファイルを作成し、必要なパラメーターを追加します。logging.d
ディレクトリには、参照または開始点として使用できるさまざまな.yml.example
ファイルがあります。
ヒント UIの[データの追加]を使用 してインフラストラクチャエージェントをインストールすると、ファイルlogging.yml
が自動的に作成されます。
エージェントは、インフラストラクチャ監視サービスを再起動しなくても、新しい構成ファイルを自動的に処理します。これに対する唯一の例外は、カスタムFluentBit構成を構成する場合です。
ログ転送パラメータ インフラストラクチャログ転送.yml
構成は、次のパラメーターをサポートします。
名前(必須) まず、NewRelicに転送する1つまたは複数のログのname
を定義します。
ログソース(必須)ログソースに何を使用するかは、ログの転送元によって異なります。利用可能なオプションは次のとおりです。
ファイル 1つまたは複数のログファイルへのパス。エージェントは、 tail -f shell
と同様の方法でログファイルの変更を追跡します。
例:
file: /var/log/example.log # Path to a single log file
file: /var/log/example-two.log # Path to another single log file
file
パラメータは、名前と拡張子に適用されるワイルドカードを使用して、特定のログファイルまたは複数のファイルを指すことができます。たとえば、 /logs/*.log
。ファイルパス内のディレクトリの代わりにワイルドカードを使用できます。これを使用して、別のディレクトリにあるファイルを調整できます。
例:
file: /var/lib/docker/containers/*/*.log # Path to multiple folders and files
重要 ワイルドカードを使用すると、ファイル記述子の数が大幅に増加し、Fluent Bitプロセスが開いたままになるのを監視します。これにより、ホストのファイル記述子の制限に達した場合にログの収集が妨げられる可能性があります。多数のファイルをテーリングするには、ファイル記述子の最大数を増やし、オペレーティングシステムで許可されているウォッチャーをinotifyする必要がある場合があります。ログファイルを増やす方法の詳細については、大量のログファイルをテーリングするときのエラーを 参照してください。
systemd Linux環境でjournald
デーモンによって収集されたログメッセージを転送するには、 systemd
パラメーターを使用します。この入力タイプでは、エージェントがルートモード で実行されている必要があります。
例:
syslog 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
によって使用可能であるか、所有されている必要があります。
uri: tcp://0.0.0.0:5140 # Use the tcp://LISTEN_ADDRESS:PORT format
parser: rfc5424 # Default syslog parser is rfc3164
uri: udp://0.0.0.0:6140 # Use the udp://LISTEN_ADDRESS:PORT format
- name: syslog-unix-tcp-test
uri: unix_tcp:///var/unix-tcp-socket-test
unix_permissions: 0666 # Default is 0644. Change at your own risk
- name: syslog-unix-udp-test
uri: unix_udp:///var/unix-udp-socket-test
tcp TCP接続を介して取得されたログ。
パラメーター:
uri:
着信データをリッスンするTCP/IPソケット。URI形式は tcp://LISTEN_ADDRESS:PORT
format:
データのフォーマット。json
またはnone
にすることができます。
separator:
format: none
を使用する場合は、レコードを分割するための区切り文字列を定義できます(デフォルト: \n
)。
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
uri: tcp://0.0.0.0:2345 # Use the tcp://LISTEN_ADDRESS:PORT format
winevtlog 重要 インフラストラクチャエージェント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
よりも優先されます。
例:
# Winevtlog log ingestion with eventId filters.
# entries for the application, system, powershell, and SCOM channels
- name: windows-application
channel: Windows Powershell
channel: Operations Manager
# Entry for Windows Defender Logs
channel: Microsoft-Windows-Windows Defender/Operational
# Entry for Windows Clustering Logs
- name: windows-clustering
channel: Microsoft-Windows-FailoverClustering/Operational
# Entry for IIS logs with logtype attribute for automatic parsing
file: C:\inetpub\logs\LogFiles\w3svc.log
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
よりも優先されます。
例:
# Winlog log ingestion with eventId filters.
# entries for the application, system, powershell, and SCOM channels
- name: windows-application
channel: Windows Powershell
channel: Operations Manager
# Entry for Windows Defender Logs
channel: Microsoft-Windows-Windows Defender/Operational
# Entry for Windows Clustering Logs
- name: windows-clustering
channel: Microsoft-Windows-FailoverClustering/Operational
# Entry for IIS logs with logtype attribute for automatic parsing
file: C:\inetpub\logs\LogFiles\w3svc.log
オプション構成 次の構成パラメーターは必須ではありませんが、それでも推奨されます。
属性 キーと値のペアとして指定されたカスタム属性のリスト。ログとともに追加のデータを送信するために使用でき、その後クエリを実行できます。attributes
構成パラメーターは、任意のログソースで使用できます。
重要 attributes
構成パラメーターは、外部Fluent Bit構成を介して(たとえば、 fluentbit
構成パラメーターを使用して)転送されるログにカスタム属性を追加しません。このシナリオでは、 FluentBitドキュメント のrecord_modifier
オプションを参照する必要があります。
attributes
構成パラメーターの一般的な使用法の1つは、 logtype
属性を指定することです。この属性により、NewRelicのログ管理機能でサポートされている組み込みの解析ルール の1つを活用できます。
例:
- name: example-file-attributes
file: /var/log/example.log
- name: example-tcp-attributes
インフラストラクチャエージェントによって自動的に挿入される属性 インフラストラクチャエージェントは、便宜上、ログ属性を自動的に挿入します。それらのいくつかはログレコードに挿入されますが、その他はログフォワーダーのセットアップ中に使用した構成パラメーターに依存します。
属性名
説明
entity.guids
常に挿入されます。
インフラストラクチャエージェントは、New Relicによって割り当てられたエンティティGUID を挿入して、実行されているホストを識別します。entity.guids
フィールドで使用できます。
注:キャプチャされたログがAPMを使用してインストルメント化されたアプリケーションに属している場合、 entity.guids
フィールドには、インフラストラクチャのエンティティGUIDとAPMのGUIDの両方が、パイプ(|)区切り文字で区切られて含まれます。
fb.input
常に挿入されます。
ログのキャプチャに使用される基になるFluentBit入力プラグインタイプ 。現在、その値はtail
、 systemd
、 winlog
、 syslog
、およびtcp
です。
filePath
file
入力タイプを使用するときに挿入されます。
監視対象のファイルの絶対ファイルパス。
hostname
常に挿入されます。
インフラストラクチャエージェントを実行しているマシン/VM/コンテナのホスト名。
plugin.type
常に挿入されます。
ログのキャプチャに使用されるユーティリティを示します。この場合、それはインフラストラクチャエージェント自体であるため、この属性の値は常にnri-agent
です。
パターン レコードをフィルタリングするための正規表現。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
デフォルトでは、フィルタリングは適用されません。
max_line_kb ログエントリ/行の最大サイズ(KB単位)。ログエントリが制限を超えると、スキップされます。デフォルトは128
です。
fluentbit 外部FluentBit 構成およびパーサーファイル。定義されている場合、それらはインフラストラクチャエージェントによって生成された既存の構成ファイルおよびパーサーファイルとマージされます。
インフラストラクチャエージェントは、 logging.d
ディレクトリにある構成ファイルを処理し、適切な[INPUT]
、 [FILTER]
、および[OUTPUT]
セクションを含むランタイムFluentBit構成ファイルを生成します。オプションで、 fluentbit
オプションを介して外部Fluent Bit構成ファイルを提供した場合は、 @INCLUDE
も宣言します。
ランタイムファイルは[SERVICE]
セクション を定義せず、すべてのデフォルトのFluentBit構成値を残します。外部のFluentBit構成ファイルで独自の[SERVICE]
セクションを定義し、 fluentbit
オプションを使用してそれを含めることにより、FluentBitのデフォルト設定をオーバーライドできます。
パラメーター:
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/
構成ファイルの例を次に示します。その他の構成例については、インフラストラクチャエージェントリポジトリを参照してください 。
logging.d / sample.yaml # 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
ログデータを表示する すべてが正しく構成され、データが収集されている場合は、次の場所にログと関連するテレメトリデータが表示されます。
トラブルシューティング ログフォワーダーの構成で問題が発生した場合は、次のトラブルシューティングのヒントを試してください。
ファイルをテーリングするときにデータが表示されない ログ転送機能では、エージェントがデータソースを読み取るためのアクセス許可を持っている必要があります。インフラストラクチャエージェントを特権モードまたは非特権モード で実行する場合は、転送するログファイル(およびそのパス内の中間ディレクトリ)が、 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
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
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
ユーザーグループに追加することをお勧めします。
Syslogソケットを介してキャプチャするときにデータが表示されない ログ転送機能には、エージェントがデータソースを読み取る権限を持っている必要があります。インフラストラクチャエージェントを特権モードまたは非特権モード で実行する場合:
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に送信する 独自のログをNewRelicに送信するようにインフラストラクチャエージェントを設定できます。これは、ログ転送、エージェントに関する問題のトラブルシューティング、またはサポート に連絡するときに役立ちます。
インフラストラクチャエージェントのログをNewRelicに転送するには:
newrelic-infra.yml
ファイルを編集します。
verbose: 3
を追加して、トラブルシューティングモードでエージェントロギングを有効にします。
Windowsおよびsystemd
を使用しないシステム、またはjournald
にアクセスできないシステムでは、 verbose:3
によりエージェントがディスクにログを書き込みます。これを防ぐには、 verbose:0
に戻します。
(推奨): JSON形式のエージェントロギングをlog_format: json
に有効にします。
エージェントを再起動して 、新しい設定をロードします。
この設定では、エージェントがトラブルシューティングモードに設定されますが、ログフォワーダ( Fluent Bit に基づく)は非冗長モードで続行されます。
ログフォワーダー自体に問題が発生する場合があります。たとえば、Windowsログイベントを送信するとき、または特定のログファイルにアクセスするときに、特定のチャネルへのアクセスに問題が発生する可能性があります。このような状況では、ログフォワーダーの冗長モードを有効にすることもできます。
verbose
を0
以外の値に設定します。
構成オプションを追加します: trace: ["log.fw"]
。
注意 [ fluentbit
]オプションを使用しているかどうかを確認してください。verbose: 3
と trace: ["log.fw"]
を設定するときは、外部のFluentBit構成ファイルでstdout
を指す[OUTPUT]
セクションを定義しないようにしてください。
FluentBitがインフラエージェントで開始しない 重要 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でのランタイムエラー Windowsでログ転送を有効にすると、次のエラーメッセージのいずれかが表示される場合があります。
The code execution cannot proceed because VCRUNTIME140.dll was not found.
また
error="exit status 3221225781" process=log-forwarder
これは、DLLが見つからないことが原因です。
この問題を解決するには、必要に応じてMicrosoft VisualC++再頒布 可能パッケージをインストールします。
大量のログファイルをテーリングするときのエラー(Linux) 大量のファイルを追尾しようとすると、次のいずれかのエラーメッセージが表示されるのが一般的です。
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
ユーザーを使用して実行する必要があります。
プロセスごとのファイル記述子の量の現在のハード制限を確認してください。通常、この制限は非常に高く、変更する必要はありません。
次の行を/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 10100
cat /proc/sys/fs/inotify/max_user_watches # Should return 18192
開いているファイルの制限を増やす 方法、またはinotifyウォッチを増やす 方法の詳細をご覧ください。
特定のFluentBitバージョンをインストールする(Linux) バージョン1.19.0 (またはSLES 12.5の場合はバージョン1.20.3)より前は、LinuxインフラストラクチャエージェントにFluentBit バイナリがバンドルされていました。このバージョン以降、FluentBitは個別のrecommended
パッケージ依存関係として含まれるようになりました。
これは、Fluent Bitをエージェントとは別にインストール、更新、またはダウングレードできることを意味します。便宜上、インフラストラクチャが存在する同じリポジトリにいくつかのFluent Bitパッケージが含まれているため、FluentBitをアップグレードするために追加のリポジトリをインストールする必要はありません。
エージェントは、最初にインストールしたときに、利用可能な最新バージョンを使用してFluentBitを自動的にインストールすることに注意してください。最初のインストール後、Linuxパッケージで通常行うようにFluentBitをアップグレードできます。
次のコマンドを実行して、使用可能なFluentBitバージョンを一覧表示できます。
RPM:
yum list td-agent-bit --showduplicates
DEB:
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
次は何ですか? Logs UI を使用して、プラットフォーム全体のログデータを調べます。
ログ転送を無効にする ログ転送機能を無効にするには、 logging.d
ディレクトリに移動し、構成 プロセス中に最初に追加された.yml
拡張子のファイルを削除します。
Linux: /etc/newrelic-infra/logging.d/
ウィンドウズ: C:\Program Files\New Relic\newrelic-infra\logging.d\