ログを New Relic に報告するには、いくつかの方法があります。APM エージェントを使用することは、特に他のログ管理ツールを使用する必要がないという利点を重視する小規模なチームや DevOps チームにとって、一般的な方法の 1 つです。
ヒント
ログがたくさんありますか? それらを最適化および管理する方法については、チュートリアルをご覧ください。
APMはコンテキストにログインします
私たちの エージェントには、 ログ イン コンテキストと呼ばれる機能があります。 この機能の利点の詳細については、 コンテキスト内のログを参照してください。
APM エージェントの場合、コンテキスト内のログ機能はいくつかのことを行います。
- 重要な New Relic メタデータ (
span.id
、trace.id
、hostname
、entity.guid
、entity.name
など) でアプリ ログを装飾し、さまざまな New Relic UI エクスペリエンスでログ データを表示できるようにします。 - ログを New Relic に直接転送するため、サードパーティのツールは必要ありません。
- いくつかの ログ メトリックを報告します。 これらは、APM サマリ UI ページの ログ チャートに表示されます。
現在の APM エージェント バージョンでは、これらの機能がデフォルトで有効になっています。
APM エージェント構成を介して、この機能のすべての側面を制御できます。これらの 1 つまたは複数を無効にする理由については、 「制限事項」を参照してください。 たとえば、APM エージェントに New Relic メタデータを追加させたい場合は、ログ装飾機能を使用すると同時に、ログ転送を無効にし、代わりに別のログ エージェント (たとえば、当社のインフラストラクチャ エージェント、または 3 番目のログ エージェント) を使用できます。パーティー ログ エージェント)。
実装の詳細と構成手順はエージェントごとに異なります (エージェントの詳細を参照)。
状況に応じたログの力について詳しくは、こちらの使用例をご覧ください。この例では、エンジニアリング チームがコンテキスト内のログを使用して、アプリの応答時間の遅さとエラー率の上昇をトラブルシューティングする方法を説明しています。
コンテキスト内のログがアプリとホストの問題の根本原因を見つけるのにどのように役立つかを確認するには、次の短いビデオ(約3:40分)をご覧ください。
始めましょう
設定する コンテキスト内のログ:
- New Relicアカウントをまだお持ちでない場合は、New Relicアカウントを新たに作成します。永久無料です。
- APM エージェントをインストールし、APMエージェントのバージョンが最新であることを確認します。
- APM エージェントの最新バージョンでは、ログ イン コンテキスト (メタデータの追加と転送) がデフォルトで有効になっています。ログを正しく機能させるために、エージェント構成ファイルを更新する必要がある場合があります。詳細については、エージェントのログを有効にする を参照してください。
それでおしまい!APM UI に移動し、関連するログ データを探して、コンテキスト内の APM ログを使用してアプリケーションのトラブルシューティングを開始します。
New RelicのAPMサマリーページから、ログ、トレース、エラーにドリルダウンします。
APMエージェントのAPI
ロギング フレームワークが既存のログ イン コンテキスト ソリューションで利用できない場合は、 API 呼び出しを使用してロギング ライブラリを構成し、ログに注釈を付けることができます。
APMエージェントログの構成
最新の エージェントでは、コンテキスト内のログ (ログ装飾とログ転送) がデフォルトで有効になっています。 コンテキスト内のログとログ転送をサポートする APM エージェントに関する情報は次のとおりです。
- エージェントv3.17.0以降のコンテキストプロシージャにログを記録する
- エージェントv7.6.0以降のコンテキストプロシージャにJavaがログインします
- .NETは、エージェントv9.8.0以降のコンテキストプロシージャにログインします
- Node.jsは、エージェントv8.11.0以降のコンテキストプロシージャにログインします
- エージェントv10.1.0 以降のコンテキスト プロシージャでの PHP ログ
- Pythonは、エージェントv7.12.0.176のコンテキストプロシージャにログインします
- Rubyは、エージェントv8.6.0以降のコンテキストプロシージャにログインします
APM ログ転送を使用できない、または使用したくない場合は、別のソリューションを使用してログを転送できます。
制限
APM ログ イン コンテキスト機能は、デフォルトで有効になっています。これは、セキュリティ、コンプライアンス、課金、またはシステム パフォーマンスに悪影響を及ぼす可能性があります。
その他の既知の制限事項を次に示します。
Node.js エージェントを除いて、
ログ転送は完全なログを送信しません。 ログ転送の詳細について学習します。
起動ログは、エージェントがロードされるまで利用できません。
Kubernetes を使用している場合は、Kubernetes API からではなく、インストルメンテーションを介してログを装飾することに注意してください。これは、ファイルシステムへの書き込みログとは別のものです。ログがホストに触れたり、API を呼び出すことができる場所に存在したりすることはありません。
アプリケーションから例外がスローされた場合、現在、Java または .NET エージェントのコンテキストで関連するログにスタック トレースは表示されません。回避策として、ドロップ フィルタ ルールを変更できます。
Fluentd は、ログを生成したエンティティから
processID
を追加できますが、APM ログはそれを確認できません。また、Kubernetes では API を呼び出してメタデータを追加しますが、このデータはアプリケーション内から見ることはできません。エンティティ メタデータが必要な場合は、コンテキストで自動ログを使用することをお勧めしますが、アプリケーションからログを送信しないでください。代わりに、引き続き Fluentd、Fluent Bit、または別のソリューションを使用してログ ファイルを転送してください。
デフォルト設定を調整する必要がある場合は、「自動ログを無効にする」を参照してください。
データのプライバシーを確保する
注意
New Relicに送信するログデータはユーザーが管理するため、組織のセキュリティガイドラインに従って、個人識別情報(PII)、保護された健康情報(PHI)、またはその他の機密データの送信をマスク、難読化、または防止してください。
ログ取り込みパイプラインは、クレジットカード、社会保障番号、国民IDなどを自動的にマスクします。詳細については、ログ管理に関するセキュリティドキュメントを参照してください。
難読化機能を使用して、ログ内の機密データをマスクまたはハッシュするカスタムルールを作成することもできます。これは、機密データへのアクセスを制限することが非現実的または不可能な場合、または一部のデータをNewRelicによって保存してはならない場合に重要です。詳細については、難読化のドキュメントをお読みください。
ログ転送の詳細
すべてのために エージェント (Node.js を除く) の場合、ログ転送オプションはログ全体を転送しません。 ログ転送で送信される内容の詳細については、以下のコラプスを参照してください。
より多くのログが必要な場合は、次のオプションがあります。
- 特定のログ データを含めるように APM エージェントを構成します。
- ログの装飾はそのままにして、APM エージェントのログ転送を無効にし、代わりに独自のログ転送ソリューションを使用してください。
これらのオプションの詳細については、エージェント固有のログイン コンテキスト ドキュメントを参照してください。
ログメトリクス
によって報告されるロギング メトリック エージェントは、APM サマリ ページの ログ チャートに表示されます。 これらの指標は ログ転送機能と は別のものであり、アカウント レベルで無効にすることはできません。 ロギング メトリックを無効にするには、専用の APM 構成ドキュメントを参照してください (たとえば、 このlogging_metrics
PHP の構成オプション)。
次のクエリに示すように、ロギング指標はapm.service.logging.lines
属性を介して報告されます。
SELECT count(apm.service.logging.lines) FROM Metric WHERE (entity.guid = 'AN_ENTITY_GUID') LIMIT MAX SINCE 60 seconds AGO TIMESERIES
ログの重複を防ぐ
コンテキスト機能でログを使用すると、データの取り込みが増加します。アカウントの料金モデルによっては、これが取り込み制限と請求に影響を与える可能性があります。
注意
APMエージェントを使用してアプリケーションから直接ログを送信する場合は、それらのアプリケーションから現在ログを収集しているログ転送ソリューションを無効にするか、変更する必要があります。そうしないと、重複したログが送信され、二重請求が発生します。
重複ログの送信を回避する方法の詳細については、アップグレードガイドを確認してください。
詳細については、手順に従って特定のログフォワーダーを無効にしてください。
摂取制限を管理する
例:エンジニアリングチームがアプリの問題のトラブルシューティングを行っているため、APMエージェントによって収集されるログの量を一時的に増やして、より詳細なログを提供します。ただし、上限を数日間実行したままにすると、不要なデータが送信され、請求額が増える可能性があります。
予期しない事態を回避するために、 NRQLクエリを使用してアラート条件を作成し、取り込み制限を追跡することをお勧めします。例えば:
例:コンテキストでのログの力
使用の詳細なユースケースは次のとおりです 状況に応じてログを記録し、問題の根本原因を突き止めます。
シナリオ例:オンコールエンジニアは、アプリの応答時間の短さとエラー率の上昇に関するNewRelicアラート通知を受け取ります。エラーと遅延の増加の背後にある根本的な原因を発見する必要があるため、問題のあるホストを負荷分散からローテーションするか、最新のリリースをロールバックするかを決定できます。
トラブルシューティングを開始するには、NewRelicUIに移動します。