• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

APIの問題に対応する

ほとんどすべてのアプリケーションとサービスは、API やその他の外部サービスを呼び出します。サイト上で buy ボタンを押すという単純な操作で数十の API 呼び出しが行われる場合、必ず問題が発生します。問題のある API 呼び出しは、在庫に関する小さな事故から、サイトが支払い処理業者と通信できないという危険な状況に至るまで、あらゆる事態を引き起こす可能性があります。

これらのエラーの分析には時間がかかります。購入トランザクションの呼び出しが失敗したために、サイトが購入の処理に失敗していませんか?それとも、支払い処理業者への認証呼び出しでしょうか?おそらく、それは外部 API の問題ではなく、内部インベントリ API の問題である可能性があります。それは API エラーですか、それとも独自のアプリケーション内のエラーですか?New Relic を使用すると、手動で行う場合に比べてほんのわずかな時間でこれらの問題を解決できます。

目的

このチュートリアル シリーズでは、問題のある API インタラクションを特定する方法と、New Relic プラットフォームを使用してそれらを解決する方法を説明します。このドキュメントでは以下について説明します。

  • New Relic をアプリケーションと統合して監視するデータを送信する
  • 外部サービス UI を使用した問題のある API の特定

New Relicの統合

何かを監視または解決するには、使用するデータを収集するエージェントをインストールする必要があります。

APMエージェントのインストール

アプリケーションのパフォーマンスを監視するには、アプリケーションの言語専用に作成されたエージェントを使用します。ロゴをクリックすると New Relic プラットフォームに移動し、ガイドに従ってエージェントのインストールと構成を行います。

Go agent
Java agent
.NET agent
Node.js agent
PHP agent
Python agent
Ruby agent

エージェントをインストールしたら、 one.newrelic.com にアクセスしてアプリを選択します。まだ多くのデータが表示されていない場合は、しばらく離れて、エージェントがアプリケーションの実行中にリアルタイム データを収集できるようにします。

追加セットアップ

特定の構成では追加のセットアップが必要になる場合があります。詳細については 、外部サービスのセットアップに関するドキュメント をご覧ください。

上記のドキュメントの追加手順を完了したら、one.newrelic.com > (アプリを選択) > 外部サービス に移動します。API と外部サービスに関するデータが流入しているのが確認できるはずです。

問題のある API を特定する

アプリケーションが API やその他の外部サービスとどのように対話するかを追跡できるようになりました。その情報を使用して、問題の原因となっている API または外部サービスを特定してみましょう。

根本原因を考える

問題のある API またはサービスを探している場合は、おそらくすでに解決できる問題を抱えているでしょう。場合によっては、ユーザーが購入できなかったり、サイトにログインできなかったりする可能性があります。

アプリケーションは数十または数百の API を呼び出す場合があります。次の手順を続行する間、根本的な問題に留意してください。購入に関して問題があることがわかっている場合は、購入および取引関連の API に焦点を当てる必要があります。ログインの問題の場合は、ユーザー データベースまたは外部認証サービスへの呼び出しに焦点を当てることができます。

マップによるトリアージ

あなたがウェブストアを運営していて、荷物が到着したときに通知が来なかったという苦情のメールをユーザーから受け取ったとします。SMS 通知と電子メール通知の両方を受信しているはずなので、これは奇妙だと思われます。

配信プロセス全体を処理するサービスを実装しました。External services [外部サービス] ページに移動し、 Maps [マップ]をクリックします。

これにより、独自のすべてのサービスと外部サービスまたは API との関係が表示されます。この場合、優先順位付けが必要なサービスは Deliveryです。これは、 Order-Composer という別のサービスによって呼び出され、右に示すように、他の 4 つのサービスと API を呼び出します。

異常を特定する

マップ ビューには、スループットと応答時間を追跡するのに役立つグラフがいくつか表示されますが、サービスとそのサービスが呼び出すサービスとの間の線の太さと色によって、それらのメトリクスも視覚的に表現されます。

Delivery サービスとその依存関係の間の線は、 Sms notificationを指している線を除いて、すべてかなり似ているように見えます。実際、SMS サービスの上にマウスを置くと、スループットが他の依存関係よりもはるかに高いことがわかります。

これで、ユーザーの不満の原因として考えられるのは Sms notification であると特定されました。疑わしい人物を特定したので、根本的な問題を解決できます。

次のステップ

メトリック チャート、システム マップ、トレースを使用して API の問題を解決します。

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.