これで、注意が必要な API または外部サービスが特定されました。このチュートリアルでは、問題を修復するために必要な手順を説明します。
API や外部サービスの問題に対する唯一の解決策はないことに注意してください。このチュートリアルのアイデアを出発点として利用し、何かを発見するたびにさらに掘り下げてください。
目的
このドキュメントでは、問題のある API または外部サービスの例として、前のチュートリアル ドキュメントで特定した外部サービスであるSms notificationを使用します。このドキュメントでは以下について説明します。
- メトリック チャートの異常を探す
- トレースを使用して根本原因を見つける
根本原因を特定して解決する
すでにマップ ビューを使用して問題のある外部サービスを特定しましたが、これを使用してさらに詳しく調べることができます。
メトリクスを使用して異常を特定する
マップ ビューで、問題のある API または外部サービスの上にマウスを置き、 Show entity preview [エンティティ プレビューの表示] を選択します。
これによりペインが開き、サービスの一般的な状態の概要が表示されます。問題を特定するためにこれらのメトリクスの一部をすでに使用しましたが、ここでさらに詳しく調べることが役立ちます。以下の点に注意してください。
チャートの急上昇。
明らかに高い応答率またはスループット。
応答率とスループットはほぼ同時に最高値と最低値に達します。
異常を特定した場合は、右上の時間ピッカーを使用して、表示している時間範囲を拡大します。これは、パターンではなく異常を識別するのに役立ちます。
上のスクリーンショットを見ると、スループットが予想より少し高いこと以外は、目立った点は何もないことがわかります。すぐに心配することは何もありません。
トレースを使用してコードレベルの問題を見つける
問題のある外部サービスにもう一度カーソルを置き、今度は View traces [トレースの表示]をクリックします。
これにより、そのサービスに関連するトレースに関するさまざまなグラフが表示されます。この場合、 Controller/Sinatra//purchase という単一のトレースがあり、ユーザーが購入ボタンをクリックしてから SMS 通知を送信する API 呼び出しに至るまで作成されたデータを追跡できます。
役立つと思う限り深くクリックしますが、チャート内の異常やエラーを見つけることに再度集中してください。たとえば、ユーザーの保存された電話番号を復号化する API 呼び出しに至るまでトレースを追跡できます。ここでエラーが発生すると、問題全体が明らかになる可能性があります。復号化呼び出しが失敗し、有効な電話番号が返されなかった場合、ユーザーは電話通知を受け取ることはありません。
これは、 Sms notification グラフにエラーが見られなかった理由も説明します。その API は正しく動作していましたが、さらに上流の API が実際には目的を果たさないデータを API に提供していました。
データを使用して論理エラーを特定する
すべての解決策がエラーや異常から直接得られるわけではありません。根本的な原因は、もっと日常的なものである可能性があります。
たとえば、 Sms notification API に関連するすべてのグラフを調査したとします。また、すべてのトレースを調べて、エラーや奇妙な異常を特定しませんでした。すべて問題なく動作しているように見えますが、顧客はまだ通知を受信していません。
Sms notification のスループット グラフを見たとき、突然、支払い処理業者が提供する購入の制限に達した可能性があることに気づきました。API はあなたの呼び出しを受け取りましたが、割り当てに達していたので、受け取ったリクエストに対して何も実行しませんでした。エラーも返されませんでした。
次は何ですか？
API の問題を修正し、システム マップ全体をトレースしたので、プラットフォームをさらに探索する準備が整いました。
- アプリの動作が遅いですか?「アプリが遅い」チュートリアルで、アプリの遅延を優先順位付けして診断する方法を学びましょう。
- ピーク需要の日が近づいている場合は、New Relic が 容量計画にどのように役立つかをご覧ください。
- 高品質のアラートを作成したいですか?アラート チュートリアルは、 アラート システムのセットアップに役立ちます。