ガイド：New Relic で Docker ログを各コンテナエンティティのログとして関連づける方法

New Relic ユーザーの皆さん、こんにちは！本投稿はユーザーグループのセミナーで同僚の開発者（Alexと呼びましょう）に相談された内容をもとにした記事で Docker アプリケーションのログ閲覧に関する話です。具体的には、インフラエージェント経由で Docker アプリケーションのログを転送すると New Relic Host UI 配下の エンティティ (Docker ホスト) の logs として見ることができますが、Container UI 配下のエンティティの logs には紐づかないため、見ることができないという問題を解決する手法の紹介です。これは Alex だけの課題ではなく、Docker と New Relic コミュニティの多くのユーザーに影響を与える一般的な問題だと思います。

どうすればログを適切な場所に紐づけることができるでしょうか？この現実の課題に触発されて、私はこのログとエンティティの紐付け問題の解決方法を思いつきました。ログ管理を実現するためのロードマップを New Relic と共有することにしました。読者の皆さん、デジタルコンパスを手に取りましょう。Docker ログが参照されるべき場所に紐付けられているかを確認しましょう。

核心的な問題：コンテナログはどこに保存されるのか？

まずはログの保存先について、どのような問題があるのかを細かくみてみましょう。コンテナ内でアプリケーションを実行している場合、特に Docker を使用している場合、ロギングは単に記録を残すだけではありません。重要なのは明確さとコンテキストです。（Docker用の New Relicインテグレーション が稼働している) New Relic infrastructureエージェント は、ホストとその上で実行されているコンテナのログを収集することができます。そして、複数のコンテナアプリケーションが稼働していても、すべてのログがひとまとめにされ、Infrastructure UI 配下のホスト にサーバーのログとともに表示されます。一見、問題はないように思いますが、実運用を考えれば、不便さがあります。特定のコンテナのログを見ようと思った際にホストの UI ページからそのコンテナログを探す、あるいは抽出する必要があります。

そして、コンテナ UI の Logs セクションには、この Docker ログは表示されません。

この状況はまるで、騒がしく混雑した部屋で、特定の会話を探そうとしている状況に似ています。重要な議論であろうと些細な議論であろうと、あらゆる議論は圧倒的な騒音にかき消されます。これが現在の Docker ログの紐付けの実態です。コンテナログがホストログのノイズに埋もれしまい、特定のコンテナの情報を効率よく探すことを困難にしています。

この誤った紐付けは、ビューを乱雑にするだけではありません。コンテナ固有の操作とホスト全体のアクティビティの間の境界が曖昧になるため、監視やトラブルシューティングも複雑になります。問題を迅速に診断し、効果的に拡張し、実際のコンテナのパフォーマンスを正確に把握するには、ホストログからコンテナログを分離して確認する必要があるはずです。

次のセクションでは、コンテナログ を New Relic で正しく紐付けするための再ルーティングを行う方法について説明します。

正確なログルーティングのための設定

当面の問題を理解したので、気を引き締めて解決策に取り組みましょう。次の 3ステップの操作を行うことで、コンテナログを Docker ホストおよびそれぞれのコンテナエンティティに関連付けることができます。

ステップ1：ロギング設定の調整

まずは各コンテナのログが取得されていることを確認しておきましょう。インフラエージェント経由での ログ転送設定 にて、/var/lib/docker/containers/ 配下のログを収集しているかを確認してください。 設定されていない場合、下記の内容を ログ設定ファイルに追記ください。

以下は、logging.yml にコピーして使用できるスニペットです。

- name: containers
    file: /var/lib/docker/containers/*/*.log

ステップ2：Docker でのコンテナのタグ付け

次に、「docker run」コマンドを使用して手動でコンテナを実行する際に、または Docker Compose 設定ファイル内でコンテナを実行する際に、コンテナをタグで認識できるようにする必要があります。以下の tag を追加することで、これを実現できます。

• Docker runコマンドの例

docker run --log-opt tag=""{{.Name}}"" -d log-generator

• docker-compose.ymlのDocker Composeの例

以下は、docker-compose.yml にコピーして使用できるスニペットです。

version: '3.9'
x-default-logging: &logging
  driver: "json-file"
  options:
    max-size: "5m"
    max-file: "2"
    tag: "{{.Name}}"

この設定により コンテナからの各ログエントリにコンテナの名前がタグとして含まれるようになり、New Relic が収集したログでの追跡が容易になります。

ステップ3：New Relic Logsでのログ解析ルールの設定

New Relic 環境でコンテナ タグが送信されることを確認したら、これらのログのパースと表示方法を調整します。ログ解析ルールを設定 を行うと、特定の属性に基づいてログを分類し、クエリを実行できます。設定方法は次のとおりです。

• Name：コンテナ名
• Field to parse：attrs.tag
• Filter logs based on NRQL:：attrs.tag is not null
• Parsing rule：%{NOTSPACE:containerName}

この解析ルールは、各ログエントリの attrs.tag フィールドからコンテナ名を抽出し、containerName という名前の属性を追加します。これにより、特定のコンテナごとにログをフィルタリングして分析できるようになります。

まとめ

上記の 3ステップで、コンテナのログをより効率的に閲覧できるようになります。その効果は問題に迅速に対応する能力が強化されるだけでなく、データドリブンの知見をチームに提供してくれるでしょう。そしてそれらの積み重ねはアプリケーションがスムーズかつ効率的に実行されるようにことに貢献するでしょう。

New Relic での Docker ログの合理化に関するガイドをまとめるにあたり、効果的なログ管理はオブザーバビリティパズルのピースのひとつにすぎないことを忘れないでください。統合された監視ツールの力をさらに説明するために、私は最近、OpenTelemetry のデモアプリケーションの強化に貢献しました。私のプルリクエスト（PR #1495 が受け入れられ、マージされ、Docker Composeでデモを実行する 際に役立つ新しいタグ付け機能の導入をすることができました。この追加により、コンテナのログを簡単に区別して正確に属性を特定できるようになりました。それは効果的な監視とトラブルシューティングの強化をもたらしてくれるでしょう。興味をお持ちいただけたら こちら で変更内容を確認し、それが設定にどのような利点をもたらすかをチェックしてください。

OpenTelemetry のデモアプリケーションに貢献することに加えて、New Relic ドキュメントの対応する各セクションを更新して、ログ管理の改善点を反映しました。この更新により、これまで説明してきた戦略と技術的な詳細がテストされるだけでなく、正式にガイダンスに統合されるため、これらの変更を簡単に実装してその恩恵を受けることができます。これらの更新を確認して、これらのプラクティスを理解いただくことで New Relic ツールを最大限に活用できるようになります。