APMはコンテキストにログインします

New Relic にログを報告するには、いくつかの方法があります。 APM エージェントの使用は、特に他のログ管理ツールを使用する必要がないという利点を重視する小規模なチームやDevOpsチームにとって、一般的な方法の 1 つです。

APMはコンテキストにログインします

APMエージェントにはlogs in contextと呼ばれる機能があります。 この機能の利点の詳細については、 「コンテキスト内のログ」を参照してください。

APM エージェントの場合、コンテキスト内のログ機能はいくつかのことを行います。

• 重要な New Relic メタデータ ( span.id 、 trace.id 、 hostname 、 entity.guid 、 entity.nameなど) でアプリ ログを装飾し、さまざまな New Relic UI エクスペリエンスでログ データを表示できるようにします。
• ログを New Relic に直接転送するため、サードパーティのツールは必要ありません。
• somelog メトリクスをレポートします。 これらは、APM Summary UI ページのLogsグラフに表示されます。

現在の APM エージェント バージョンでは、これらの機能がデフォルトで有効になっています。

APM エージェント構成を介して、この機能のすべての側面を制御できます。これらの 1 つまたは複数を無効にする理由については、 「制限事項」を参照してください。 たとえば、APM エージェントに New Relic メタデータを追加させたい場合は、ログ装飾機能を使用すると同時に、ログ転送を無効にし、代わりに別のログ エージェント (たとえば、当社のインフラストラクチャ エージェント、または 3 番目のログ エージェント) を使用できます。パーティー ログ エージェント)。

実装の詳細と構成手順はエージェントごとに異なります (エージェントの詳細を参照)。

状況に応じたログの力について詳しくは、こちらの使用例をご覧ください。この例では、エンジニアリング チームがコンテキスト内のログを使用して、アプリの応答時間の遅さとエラー率の上昇をトラブルシューティングする方法を説明しています。

コンテキスト内のログがアプリとホストの問題の根本原因を見つけるのにどのように役立つかを確認するには、次の短いビデオ（約3:40分）をご覧ください。

始めましょう

コンテキストでAPMログを設定するには:

1. New Relicアカウントをまだお持ちでない場合は、New Relicアカウントを新たに作成します。永久無料です。
2. APM エージェントをインストールし、APMエージェントのバージョンが最新であることを確認します。
3. APM エージェントの最新バージョンでは、ログ イン コンテキスト (メタデータの追加と転送) がデフォルトで有効になっています。ログを正しく機能させるために、エージェント構成ファイルを更新する必要がある場合があります。詳細については、エージェントのログを有効にする を参照してください。

それでおしまい！APM UI に移動し、関連するログ データを探して、コンテキスト内の APM ログを使用してアプリケーションのトラブルシューティングを開始します。

APMエージェントのAPI

ロギング フレームワークが既存のログ イン コンテキスト ソリューションで利用できない場合は、 API 呼び出しを使用してロギング ライブラリを構成し、ログに注釈を付けることができます。

APMエージェントログの構成

最新の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 エージェントを除き、 APMログ転送では完全なログは送信されません。 ログ転送の詳細については、こちらをご覧ください。
• 起動ログは、エージェントがロードされるまで利用できません。
• Kubernetes を使用している場合は、Kubernetes API からではなく、インストルメンテーションを介してログを装飾することに注意してください。これは、ファイルシステムへの書き込みログとは別のものです。ログがホストに触れたり、API を呼び出すことができる場所に存在したりすることはありません。
• アプリケーションから例外がスローされた場合、現在、Java または .NET エージェントのコンテキストで関連するログにスタック トレースは表示されません。回避策として、ドロップ フィルタ ルールを変更できます。
• Fluentd は、ログを生成したエンティティからprocessIDを追加できますが、APM ログはそれを確認できません。また、Kubernetes では API を呼び出してメタデータを追加しますが、このデータはアプリケーション内から見ることはできません。エンティティ メタデータが必要な場合は、コンテキストで自動ログを使用することをお勧めしますが、アプリケーションからログを送信しないでください。代わりに、引き続き Fluentd、Fluent Bit、または別のソリューションを使用してログ ファイルを転送してください。

デフォルト設定を調整する必要がある場合は、「自動ログを無効にする」を参照してください。

データのプライバシーを確保する

ログ取り込みパイプラインは、クレジットカード、社会保障番号、国民IDなどを自動的にマスクします。詳細については、ログ管理に関するセキュリティドキュメントを参照してください。

難読化機能を使用して、ログ内の機密データをマスクまたはハッシュするカスタムルールを作成することもできます。これは、機密データへのアクセスを制限することが非現実的または不可能な場合、または一部のデータをNewRelicによって保存してはならない場合に重要です。詳細については、難読化のドキュメントをお読みください。

ログ転送の詳細

すべてのAPMエージェント (Node.js を除く) では、ログ転送オプションによってログ全体が転送されるわけではありません。 ログ転送で送信される内容の詳細については、以下の折りたたみ機能を参照してください。

{
  "v": "x",
  "level": "x",
  "name": "x",
  "hostname": "x",
  "pid": 01,
  "timestamp": "x",
  "message": "x",
  "bunches": "of custom stuff"
}

{
  "timestamp": "x",
  "message": "x",
  "span.id": "x",
  "trace.id": "x",
  "hostname": "x",
  "entity.guid": "x",
  "entity.name": "x"
}

より多くのログが必要な場合は、次のオプションがあります。

• 特定のログ データを含めるように APM エージェントを構成します。
• ログの装飾はそのままにして、APM エージェントのログ転送を無効にし、代わりに独自のログ転送ソリューションを使用してください。

これらのオプションの詳細については、エージェント固有のログイン コンテキスト ドキュメントを参照してください。

ログメトリクス

APMエージェントを設定すると、 APM Summary ページにログ メトリックのグラフが自動的に表示されます。

このグラフはログの数を示しています。 ログ転送を無効にしていない場合は、グラフのリンクをクリックすると、ログ自体が表示されます。 ログ転送を無効にした場合でも、このグラフには、ログ転送が有効になっている場合に検査できる可能性のあるログが表示されます。

次のクエリに示すように、ロギング指標は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設定ドキュメントを参照してください (たとえば、 PHP のこの logging_metrics 構成オプション)。

ログの重複を防ぐ

コンテキスト機能でログを使用すると、データの取り込みが増加します。アカウントの料金モデルによっては、これが取り込み制限と請求に影響を与える可能性があります。

重複したログの送信を回避する方法の詳細については、アップグレード ガイドを参照してください。

詳細については、手順に従って特定のログフォワーダーを無効にしてください。

摂取制限を管理する

Example: エンジニアリング チームはアプリの問題をトラブルシューティングしているため、より詳細なログを提供するために、APM エージェントによって収集されるログの量を一時的に増やします。 ただし、より高い制限を数日間実行したままにすると、不要なデータが送信され、請求額が増加する可能性があります。

予期しない事態を回避するために、 NRQLクエリを使用してアラート条件を作成し、取り込み制限を追跡することをお勧めします。例えば：

UIでデータ制限と使用状況を表示する

UI でデータ制限を確認するには:ユーザー メニューからManage your data > Limitsをクリックします。 または、使用状況を表示するには、 View your usageをクリックします。

NRQLクエリ：推定コストの例

コスト関連のクエリを参照してください。

NRQLアラート：使用しきい値の例

使用量がギガバイトのデータの固定月間しきい値を超えたときにアラートを作成するには、次のNRQLクエリをアラート条件に追加します。

FROM NrMTDConsumption SELECT latest(GigabytesIngested) WHERE productLine = 'DataPlatform'

コピー

例：コンテキストでのログの力

ここでは、問題の根本原因を特定するためにコンテキスト内でAPMログを使用する詳細な使用例を示します。

Example scenario: オンコールのエンジニアは、アプリの応答時間の低下とエラー率の上昇に関するNew Relic一括通知を受け取ります。 問題のあるホストを負荷分散から外すか、最新のリリースをロールバックするかを決定できるように、エラーとレイテンシの増加の背後にある根本原因を発見する必要があります。

トラブルシューティングを開始するには、NewRelicUIに移動します。

エラーはいつどこで始まりましたか？

エンジニアがアプリのAPM Summaryページを見ると、応答時間の向上につながるさらに多くのエラー ログが表示されます。 彼らは、ログから問題の根本原因を明らかにできるかどうかを確認したいと考えています。

How can they quickly decide what's related to the problem?

彼らはログ収集を設定していません。ただし、アプリのJavaエージェントは最近更新され、コンテキストにAPMログが含まれるようになったため、アプリはログとリンクメタデータを自動的に受信するようになりました。 UIに表示されるメトリックは、ログの重大度によるカウントをファセットします。 （これは、Javaエージェントの組み込みのログ装飾機能によって設定されます。）

What entities are related?

同じ UI ページで、 Logsグラフをクリックすると、 Log summaryビューを確認できます。 このビューには、インストゥルメントされたログが収集されたとき、およびそれらのログの重大度レベルがError以上であったときが表示されます。 また、ログ パターンのリストと、各パターンに一致するすべてのログの割合も表示されます。

ログにはどのようなパターンが現れますか？

Log patterns UIで、まれなエラーメッセージが頻繁に発生するようになり、リストに表示されるようになりました。 これにより、エンジニアは煩わしいステータス更新すべてではなく、問題のあるログに集中することができます。

What patterns should they focus on?

エンジニアは興味深いログパターンに気づき、このパターンに一致するログのみを表示したいと考えています。彼らはそれをクリックして、表示されているログにフィルターとしてパターンの値を追加します。これにより、焦点が狭くなります。

ログの詳細で何が明らかになりますか？

エンジニアはログ レコードに含まれるすべての値を確認したいため、 Log detailsビューをクリックします。 これにより、ログ自体が意味のあるものであるかどうかを検証できます。 また、アプリが実行されているKubernetes環境にさらにドリルダウンしたり、ディストリビューティッド（分散）トレーシングやログ レコードに関連するエラーに直接アクセスしたりすることもできます。APM

エンジニアは、完全なスタックト レースを確認できるAPMエラーを調べることにしました。 Errors inbox UI からログを確認することもできます。

トラブルシューティングに役立つ追加のテストデータは何ですか？

トラブルシューティングチームは原因を特定するためにテストを実行していますが、テストトランザクションのすべてのログが収集されているわけではありません。 Javaエージェントの構成ファイルのデフォルトのログコレクション（ application_logging:forwarding:max_samples_stored:では1分あたり約10,000ログ）は、サービスに問題があることを検証するのに役立ちました。しかし今、彼らはより詳細なトラブルシューティングのためにサンプリングをより高い数に上げる必要があります。

問題が解決しました。それで？

トラブルシューティングチームは、問題が最近導入された変更に起因すると判断したため、そのコードをロールバックします。リソースを節約し、費用を取り込むために、構成ファイルでapplication_logging:forwarding:max_samples_stored:のログ収集を拒否しますが、問題が再発する場合に備えてログサンプリングを実行し続けます。

また、トラブルシューティング チームは、このアプリにフィルタされたLog patternsページを指すようにランブックを更新し、 そのランブックをアラート条件に追加します。 次回、この状況と同様の状況を受け取った場合、これらの教訓を活用して、より迅速なトラブルシューティングを行うことができます。