Logs in Context を利用する際のログ転送パターンの選択肢

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 の機能を利用できるので強力な機能になっておりますが本番環境運用時には上記の内容を考慮したうえでどの選択肢をとるのかを選択して頂ければと思います。

Next steps

また New Relic には月間100GBまでの転送量であればほぼ全ての機能を１ユーザーまでであれば無料で利用が可能になっています。まだ New Relic の Logs in Context を試したことが無い方は無料でその強力な機能をお試しください。

https://newrelic.com/jp/sign-up-japan

By 大平譲, Solutions Consultant

New Relic株式会社 Solution Consultant。B to B SaaS の企業で SRE のポジションで Software Engineer として従事してから現職。Kubernetes を使ったコンテナ環境の基盤構築や Terraform を使用した IaC などが得意領域。

The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.

780+ integrations to start monitoring your stack for free.

See All Integrations

In this article