announcements管理者とデータアカウントおよびユーザーの管理データとAPIデータ辞書セキュリティとプライバシーライセンスこの機械翻訳は、参考として提供されています。英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。問題を作成するエラー追跡による停止への対応エラーは必ず発生します。可観測性ツールを使用したとしても、エラーの原因を見つけるのは思っているほど簡単ではありません。浸水した庭を考えてみましょう。ホースの近くで水が流れていることに気づきましたが、実際には浸水の原因は水道本管のどこかに亀裂が入っていることです。ホースの漏れが洪水の原因だと仮定した場合、ホースは固定されたものの、芝生は台無しになってしまうことになり、高くつく間違いです。エラー分析により問題の原因が特定されるため、フラッドが発生する前に問題を解決できます。チームが新しいデプロイメントを行ったり、上流でサービスに障害が発生したりした場合は、ソリューションを実装する前にさらに深く掘り下げる必要があります。エラー分析には仮定が入る余地はありません。シリーズでは、重大なエラーを解決する方法を示し、全体的なエラー数を減らす方法を説明します。このドキュメントでは、次の方法など、エラー受信トレイ機能を操作する方法について説明します。グループを選択してください前提条件アプリケーションのパフォーマンスを監視するには、アプリケーションの言語専用に作成されたエージェントを使用します。ガイド付きインストーラーに移動し、ガイドに従ってエージェントのインストールと構成を行います。one.newrelic.comに移動してアプリを選択します。データを収集できるようにします。このチュートリアルでは、最初の集計をまだ作成していない場合でも、アラートについてある程度理解していることを前提としています。サービスに関するデータをキャプチャしています。これには、アプリで発生したエラーに関するデータが含まれます。1エンドユーザーのことを考えるアラートは問題の存在を知らせます。それは芝生に水が溜まっていることです。アラートではすべてのコンテキストが提供されるわけではありません。そこでエラー受信箱が役に立ちます。サイト上のいくつかのアプリを担当していると想像してください。つのアラートを受け取りました。在庫の検索に関するものです。コンポーネントは正常に動作しています。チェックアウト機能の方が重要だと考えるかもしれませんが、その信念と可観測性の実践を区別することが重要です。ユーザーが何も報告していない場合でも適用されます。サービスが失敗していることに気づいたら、次の質問を自問してください。エンドユーザーは問題を抱えていますか?彼らの経験はどのように見えるべきでしょうか?彼らは現在どのような行動を経験していますか?2どのサービスがエラーを報告しているかを特定するこれが実際にどのように見えるか見てみましょう。つのサービスが警告を発していることがわかります。質問を自問すると、次のことがわかります。エンドユーザーは購入アクションに悩んでいます。サイトでは在庫のある商品のみを表示する必要があります。サイトにはすべての商品が表示されているため、顧客は在庫切れの商品を購入できます。インベントリにとって重要な依存関係であることが特定されました。ここからエラー分析を開始します。ポイントができたので、アプリに影響するエラーを調べることができます。Triageの下のErrorsタブをクリックします。ページでは、データがエラーのみのビューにフィルターされます。グループが報告されています。グループは、アプリ内で数十から数千の範囲で発生します。最初は粒度が足りないように見えますが、時系列は時間の経過とともに何が変化したかを示すのに十分な情報を提供します。これを詳しく説明します。始める必要があるかもしれません。時系列で見ると、山と谷は比較的一貫しています。