New Relic には APM や Infrastructure, OpenTelemetry のエンティティとログを紐付ける Logs in Context という機能を提供しています。
中でも APM には APM Agent が導入されているアプリケーションのログを APM Agent 自身が Logs in Context に対応した形で New Relic に転送してくれる機能を提供しています。
https://docs.newrelic.com/docs/logs/logs-context/get-started-logs-context/#apm-logs-defined
しかしログ転送の選択肢として fluentbit や firelens を使ってログフォワーダーからログを転送しているケースもあるでしょう。
その際に APM からログを転送するべきなのか、フォワーダーから転送するべきなのかの選択肢に迷ってしまうケースも有るかと思いますのでどのように選択するかの方法を本記事では提供したいと思います。
APM Agent からのログを転送するパターン
まず APM Agent からアプリケーションログを転送するパターンが New Relic Logs in Context の機能を1番簡単に利用することができます。
皆様が開発しているアプリケーションのロガーのバージョンなどが対応していれば何もソースコードなどを弄ることなく Logs in Context の機能を利用することが可能になっています。
このパターンを使うケースとしては手軽に Logs in Context の機能を利用したいケースの場合に当てはまります。
対応しているロガーやバージョンについてはドキュメントをご確認ください。
Go、 Java、 .NET、 Node.js、 PHP、 Python、 Ruby の各種 APM Agent で対応しています。
https://docs.newrelic.com/docs/logs/logs-context/get-started-logs-context/#agents
ログフォワーダーからの転送を選択するパターン
前述した APM Agent からのログ自動転送はとても強力で便利な機能ですがいくつかの制約をもっています。
1. ログ全体を転送するわけではない
Node.js を除いた APM Agent からのログ転送はログ全体を転送するわけではないことをご注意ください。
以下のようなログがあったとします。
{
"v": x,
"level": x,
"name": "x",
"hostname": "x",
"pid": x,
"timestamp": "x",
"message": "x",
"bunches": "of custom stuff"
}
このようなログは以下のような形で New Relic に転送されます。
{
"timestamp": "x",
"message": "x",
"span.id": "x",
"trace.id": "x",
"hostname": "x",
"entity.guid": "x",
"entity.name": "x",
}
このような形でログを装飾して転送するので当初設定していたフィールドなどが転送されず、お客様からはログが欠損しているのではないのかという形でログが転送されます。
この現象を防ぐためには以下のような選択肢を取ることができます。
1. APMエージェントが特定のログデータを含むように設定する。
※例として Java の設定例を共有します。お使いの言語の Agent に同様の設定があるかドキュメントをご確認ください。
2. ログ装飾はそのままに、APMエージェントのログ転送を無効化し、代わりに独自のログ転送ソリューションを使用する。
https://docs.newrelic.com/docs/logs/logs-context/get-started-logs-context/#forwarding-details
2. 転送量の制限
また、 APM Agent からログ転送をする際には転送する行数に対して分間あたりの制限があります。
Java Agent の例では 10000 がデフォルト値になっておりアプリケーションが展開されているホスト数またはコンテナ数に応じた数がログの転送量になります。
この値は max_samples_stored という値で管理されておりその値を増やすことで APM Agent から転送する量を増やすことができますがメモリへの負荷が高まりますのでアプリケーションへの負荷が問題にならない程度に収めることを考慮する必要があります。
https://docs.newrelic.com/docs/logs/logs-context/java-configure-logs-context-all/#1-agent
既存のログ転送ソリューションを持っている場合
また注意点として APM Agent から転送されるログは直接 APM Agent から転送されるものになるのでログフォワーダーを介して転送がされません。ですので両方を転送する場合に二重にデータが転送されてしまうという問題が発生します。
このケースではログの加工のみを APM Agent に任せてログ転送はフォワーダーに任せることをおすすめします。
以下が Java Agent の例になります。
application_logging:
enabled: true
local_decorating:
enabled: true
forwarding:
enabled: falseまとめ
以上がLogs in Context を利用する際のログ転送パターンについての選択について考慮すべきポイントになります。
APM Agent からログ転送を直接することは手軽に New Relic の機能を利用できるので強力な機能になっておりますが本番環境運用時には上記の内容を考慮したうえでどの選択肢をとるのかを選択して頂ければと思います。
次のステップ
また New Relic には月間100GBまでの転送量であればほぼ全ての機能を１ユーザーまでであれば無料で利用が可能になっています。まだ New Relic の Logs in Context を試したことが無い方は無料でその強力な機能をお試しください。
https://newrelic.com/jp/sign-up-japan
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
