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

アプリやホストの問題のトラブルシューティングを行うときは、すべてのNewRelicツールをすぐに使用できます。ただし、UI全体で多くのコンテキスト切り替えを行ったり、利用可能な豊富な情報に圧倒されたりすることは望ましくありません。

APMエージェントは、関連する属性をアプリケーションログデータに自動的に追加できます。これにより、コンテキストでのログの使用が非常に簡単になります。アプリケーションは、エージェントを使用してログデータを直接NewRelicに転送することもできます。

ログは、それらが属するアプリケーション、トランザクション、またはエラーのコンテキストでより価値があります。ログインコンテキスト機能を使用すると、アプリケーションからのログ、分散トレース、およびエラーをAPMで直接表示できるため、トラブルシューティングの方法が変わります。

コンテキストでの自動ログの機能の詳細をご覧ください。この例では、エンジニアリングチームがアプリの応答時間の低下とエラー率の上昇をトラブルシューティングするために、これをどのように使用したかを説明しています。

スタートガイド

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

1. New Relicアカウントをまだお持ちでない場合は、New Relicアカウントを新たに作成します。永久無料です。
2. アプリとホストでサポートされているエージェントバージョンに更新します。
3. エージェントのログを有効にし、構成ファイルにいくつかの小さな更新を加えます。

それでおしまい！ NewRelicのコンテキストでAPMログを使用してアプリケーションのトラブルシューティングを開始します。

• one.newrelic.comのエクスプローラーUI
• EU地域のエクスプローラーUI： one.eu.newrelic.com

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

最新のAPMエージェントは、サードパーティソフトウェアをインストールまたは保守することなく、コンテキストの自動追加とログの転送をサポートしています。ログには、 span.id 、 trace.id 、 hostname 、 entity.guid 、 entity.nameなどの属性が自動的に含まれます。このメタデータは、ログをトレース、スパン、インフラストラクチャデータ、およびその他のテレメトリにリンクし、トラブルシューティングを容易にします。

すべての言語またはロギングフレームワークがまだサポートされているわけではありません。以下は、現在サポートされている環境であり、言語固有のドキュメントへのリンクがあります。

• エージェントv7.6.0以降のコンテキストプロシージャにJavaがログインします
• .NETは、エージェントv9.7.0.0以降のコンテキストプロシージャにログインします
• Rubyは、エージェントv8.6.0以降のコンテキストプロシージャにログインします

APMエージェントがコンテキストソリューションの自動ログをまだサポートしていない場合は、コンテキストソリューションの手動ログを引き続き使用し、インフラストラクチャエージェントまたはサポートされているサードパーティのフォワーダーを介してログを転送できます。

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

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

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

ログの重複を防ぐ

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

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

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

摂取制限を管理する

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

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

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

UIでデータ制限を確認するには：New Relic UIのアカウントドロップダウンから、[データの管理]>[制限]をクリックします。または、使用状況を表示するには、[使用状況の表示]をクリックします。

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

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

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

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

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

コピー

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

これは、問題の根本原因を突き止めるためにコンテキストでAPMログを使用する詳細な使用例です。

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

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

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

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

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

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

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

同じUIページで、ログチャートをクリックして、NewRelicExplorerでエンティティのログの概要ビューを確認できるようにします。このビューには、インストルメント化されたログが収集されたとき、およびそれらのログの重大度レベルがError以下のときが表示されます。また、ログパターンのリストと、すべてのログの何パーセントが各パターンに適合するかを示します。

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

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

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

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

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

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

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

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

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

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

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

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