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

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

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

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

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

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

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

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

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

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

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

始めましょう

設定する コンテキスト内のログ:

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

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

APMエージェントのAPI

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

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 エージェントを除いて、

  ログ転送は完全なログを送信しません。 ログ転送の詳細について学習します。

• 起動ログは、エージェントがロードされるまで利用できません。

• Kubernetes を使用している場合は、Kubernetes API からではなく、インストルメンテーションを介してログを装飾することに注意してください。これは、ファイルシステムへの書き込みログとは別のものです。ログがホストに触れたり、API を呼び出すことができる場所に存在したりすることはありません。

• アプリケーションから例外がスローされた場合、現在、Java または .NET エージェントのコンテキストで関連するログにスタック トレースは表示されません。回避策として、ドロップ フィルタ ルールを変更できます。

• Fluentd は、ログを生成したエンティティからprocessIDを追加できますが、APM ログはそれを確認できません。また、Kubernetes では API を呼び出してメタデータを追加しますが、このデータはアプリケーション内から見ることはできません。エンティティ メタデータが必要な場合は、コンテキストで自動ログを使用することをお勧めしますが、アプリケーションからログを送信しないでください。代わりに、引き続き Fluentd、Fluent Bit、または別のソリューションを使用してログ ファイルを転送してください。

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

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

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

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

ログ転送の詳細

すべてのために エージェント (Node.js を除く) の場合、ログ転送オプションはログ全体を転送しません。 ログ転送で送信される内容の詳細については、以下のコラプスを参照してください。

{
    "v": x,
    "level": x,
    "name": "x",
    "hostname": "x",
    "pid": x,
    "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 構成ドキュメントを参照してください (たとえば、 このlogging_metrics PHP の構成オプション)。

次のクエリに示すように、ロギング指標は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エージェントによって収集されるログの量を一時的に増やして、より詳細なログを提供します。ただし、上限を数日間実行したままにすると、不要なデータが送信され、請求額が増える可能性があります。

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

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

UI でデータ制限を確認するには:ユーザー メニューから、[データの管理] > [制限] をクリックします。または、使用状況を表示するには、[使用状況を表示] をクリックします。

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

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

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

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

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

コピー

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

使用の詳細なユースケースは次のとおりです 状況に応じてログを記録し、問題の根本原因を突き止めます。

シナリオ例：オンコールエンジニアは、アプリの応答時間の短さとエラー率の上昇に関するNewRelicアラート通知を受け取ります。エラーと遅延の増加の背後にある根本的な原因を発見する必要があるため、問題のあるホストを負荷分散からローテーションするか、最新のリリースをロールバックするかを決定できます。

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

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

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

問題に関連するものをどのようにすばやく判断できますか？

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

どのエンティティが関連していますか？

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

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

ログパターンUIでは、まれなエラーメッセージが頻繁に発生し始め、リストに表示されるようになりました。これにより、エンジニアは、ノイズの多いステータスの更新ではなく、問題のあるログに集中できます。

彼らはどのパターンに焦点を当てるべきですか？

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

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

エンジニアは、ログ レコードに含まれるすべての値を確認する必要があるため、 [ログの詳細] ビューをクリックします。 これは、ログ自体が意味のあるものであることを検証するのに役立ちます。また、アプリが実行されている Kubernetes 環境にさらにドリルダウンするか、分散トレースまたは ログ レコードに関連するエラー。

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

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

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

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

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

トラブルシューティングチームはまた、このアプリにフィルターされたログパターンページを指すようにRunbookを更新し、Runbook をアラート条件に追加します。次回、この状況に似たアラートを受け取ったときに、学習したこれらのレッスンを使用して、トラブルシューティングを迅速に行うことができます。