New Relic APMのLogs in Contextを使うことで、APMで観測しているアプリケーションのエラーや分散トレーシングからトラブルシューティングや原因調査で必要なログにピンポイントで辿り着けるようになります！
本記事ではLogs in Contextがどのような機能かご紹介します。
どんな機能？
Logs in Contextは主要なプログラミング言語毎に用意されているNew Relic APM エージェントをアプリケーションに導入することで利用できる機能になります。
例えば以下のケースでログを調査する際に、Logs in Contextは非常に効果を発揮します。
- ログだけでは分かりにくいアプリケーションのエラーや性能問題をメトリクスやトレースとログを紐づけることで、原因特定と解決を迅速化できる
- 分散サービスの障害時に一つのエラーに対して、複数のログを分散サービスのシステムを横断して確認できるようになる
- 開発している機能が正しく動いていることをトランザクションのデータと共にログとあわせて確認できる
- 大量にあるログから調査に必要なログを抽出する作業が不要で、エラーやパフォーマンス劣化のコンテキストデータから必要なログにピンポイントでたどり着くことができる
例：分散サービスでエラーが発生した際に分散トレーシングの画面でシステムを横断した複数のログを確認
例：アプリケーションで発生しているエラーに関連するログを確認
どうやって設定するの？
Logs in Contextは以下どちらかの方式を選択することができます。
APMエージェント経由でログを送る方法
既に使っているログフォワーダーから送る
APMエージェント経由でログを送る場合
APMエージェントのデフォルトの設定でLogs in Contextは有効になっており、サポートしているロガーを使用してる場合、自動でトランザクションやエラーなどのコンテキストデータに関連するログが自動で紐づくことになります。サポートしてないロガーを使っている場合は、手動計装することでAPMが取得するコンテキストデータにログを紐づけることも可能です。
言語毎のロガーのサポート状況は以下でご確認ください。
既に使っているログフォワーダーから送る場合
例えば、fluentbitやAWS Firelenseなどを使って、既にNew Relicにログを転送している場合、APMエージェントからのログ転送は無効にして、トランザクションなどのコンテキストデータだけログに紐づけるという設定を入れることができます。例えば、Javaエージェントの場合はエージェントの設定ファイルで以下のように設定を入れます。
application_logging:
enabled: true
local_decorating:
enabled: true
forwarding:
enabled: false
言語毎の設定方法は以下公式ドキュメントをご確認ください。
APMエージェント経由でログ転送するか、ログフォワーダー経由でログ転送するか選択する際に考慮すべきポイントが何点かあり、以下公式ブログで紹介してますので、ご確認ください。
New Relic APM エージェントのLogs in Contextを利用することで、原因調査やトラブルシューティングのときに必要なログをピンポイントに取り出すことができるようになります。ぜひ、ご活用ください。
その他
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！