私たちの 時間が限られている場合、ツールはインシデントの解決に役立ちます。APM の概要ページを使用すると、アプリの潜在的な障害の概要を確認し、各サービスに関する重要な指標を取得できます。ここは、サービスの健全性をチェックし、より大きなコンテキスト内で問題を理解し、問題を解決するために必要な手順を実行するために最初にアクセスする場所です。
このドキュメントでは、New Relic の APM ツールを使用してサービス低下の根本原因を特定する方法の 架空の 例を説明します。 靴を販売する架空の電子商取引会社で働くという状況を検討します。あなたはチェックアウト チームのエンジニアリング マネージャーです。顧客からは、チェックアウトに時間がかかりすぎるとの苦情が寄せられている。
顧客はカートに靴を入れ、チェックアウトする時期が来たと判断したら、 Pay Now ボタンを押します。Checkout-service は、 Pay Now ボタンの機能を管理するエンティティです。
顧客が Pay Now ボタンをクリックできない理由を確認するには、APM を開いて Checkout-serviceを選択します。
サマリータイルで問題点を特定する
詳細に入る前に、まずページの上部にある概要タイルを確認することが重要です。これらのタイルは、システムの問題、脆弱性、展開の失敗を即座に警告します。ページ上部のタイルが空の状態を示している場合は、 Set up now をクリックして各タイルをアクティブにします。
課題
システム内の異常な動作を追跡する重要な方法は、アラートを使用することです。 Checkout-service のトランザクション エラー率が 10% を超える時期を知りたいとします。 アラート条件 を作成し、インシデントをトリガーするルールを設定します。1 つ以上のインシデントによって問題が発生します。このタイルには、サービスの問題が表示されます。
この例では、アラート条件がすでに設定されているため、概要タイルをスキャンすると、システムに 2 つの重大な問題があることがすぐにわかります。タイルをクリックすると、各重大な問題、それに含まれるインシデント、およびそれらに関連するエンティティの詳細が表示されます。
最後の展開
デプロイメント マーカーは、サービスに加えたすべての更新の結果を監視するのに役立ちます。このタイルには、最後の展開によって引き起こされたエラー率と応答時間の変化が表示されます。
デプロイメントの 15 分後から、このタイルにはデプロイメント前とデプロイ後に収集されたデータの比較が表示されます。45 分前に新機能を有効にした場合、このタイルには 45 分前と 45 分後の比較が表示されます。デプロイ後の最初の 3 時間は、このタイルには、有効化後の経過時間と有効化前の対応する時間との比較のみが表示されます。3 時間後、タイルでは標準の 3 時間の比較が使用されます。
カスタムの時間範囲の場合は、タイルをクリックしてメインの展開ページに移動し、そこで時間ピッカーを使用します。
この例では、 最後のデプロイメントにより エラー率が 27% 急増し、応答時間が 5% 増加しました。タイルをクリックすると、最後のデプロイメントと関連するエラー、ログ、アラート、傾向が表示されます。
サービスレベル
サービス レベルは、エンド ユーザーの観点からサービスのパフォーマンスを測定するために使用されます。サービス レベルのエラー バジェットを超えると、次のインシデント タイプが表示されます。
Non-compliant [非準拠とは]、 この期間のエラー バジェットをすべて消費したことを意味します。したがって、展開する必要がある場合は注意し、SL を改善するための作業を計画してください。
At risk 「危険にさらされ ている」とは、エラー バジェットがほぼ消費されているため、残りの期間はより慎重になる必要があることを意味します。
この例では、 サービス レベルがすでに構成されて おり、2 つのインスタンスでエラー バジェットを超えています。タイルをクリックして、どのエンティティが準拠していないのかを確認し、エラー バジェットをさらに詳しく調べます。
脆弱性
脆弱性管理は、すべてのソフトウェアの脆弱性を鳥瞰的に表示します。Java、.Net、Github dependabotなどの統合エージェントやサービスはそれぞれ、既知の脆弱性を自動的に New Relic に集めて追跡します。
ここでは、 脆弱性管理が 有効になっていて、監視対象サービスに対して 3 つの
Criticalと 9 つのHigh脆弱性が検出されたことがわかります。タイルをクリックすると、脆弱性の影響が表示されます。
主要な指標を確認する
Checkout-serviceに問題がありますか?どのシステムがどのように影響を受けるのでしょうか?
Apdex
サービスの故障を調査するときに最初に確認するのは、Apdex スコアです。Apdex スコアは、アプリケーションに対する全体的な顧客満足度を監視します。スコアでは、応答時間やスループットなどのパフォーマンスとエラー率の組み合わせが求められます。
Apdex は、Web アプリケーション/サービスの応答時間に対するユーザーの満足度を測定する業界標準です。0～1のスコアで表されます。スコアが 1 に近づくほど、アプリのパフォーマンスは向上します。満足のいくエクスペリエンスのデフォルト値は 0.5 秒ですが、[設定] で別の目標を設定できます。
Apdex スコアは通常、次の色で分けられます。
< 0.5 - グレー: アプリケーションのパフォーマンスがクリティカルを超えており、即時の対応が必要です。
0.5-0.7 - 赤: アプリケーションに重大なパフォーマンスの問題があり、直ちに対処する必要があります。
0.7-0.85 - オレンジ: アプリケーションはマイナスの方向に傾いているため、さらなる調査が必要です。
0.85-0.95 - 青: これは理想的な Apdex 範囲です。このスコアは、Apdex T がアプリケーションに合わせて完全に微調整されており、パフォーマンスが健全であることを意味します。
> 0.95 - 青: Apdex スコアがこの範囲にある場合は、Apdex T の設定が少し高すぎる可能性があり、アプリケーションのパフォーマンスを正確に把握できていないことを意味します。Apdex T を減らすことを検討する必要があります。
ヒント
Apdex スコアが 0 の場合は、リクエストがエラーで返されたことが原因である可能性があります。エラーのあるすべてのリクエストは、Apdex 上で自動的に 0 のスコアを付けられます。
この例では、APM で
Checkout-serviceエンティティを開いた後、Apdex スコアが低下し、0.6 で推移していることがわかります。チャートは赤です。これで、顧客の苦情が正しいことが確実にわかりました。スタックのどこかに問題があるのです。
スコアを理解する方法の詳細については、 「Apdex: ユーザー満足度の測定」を参照してください。
Webトランザクション
お客様からの報告に基づいて、アプリで
Pay nowボタンが失敗していることはわかっていますが、実際のエラーの原因はわかりません。Apdex をチェックしたところ、ユーザー満足度が低いことがわかりました。次のステップは、アプリの Web-transactions [Web トランザクション]を調査して、チェックアウト プロセスのどの部分が壊れているかを特定することです。
New Relic では、トランザクションはソフトウェア アプリケーションの 1 つの論理的な作業単位として定義されます。具体的には、その作業単位を構成する関数呼び出しとメソッド呼び出しを指します。APM の場合、Web トランザクションを指すことが多く、アプリケーションが Web リクエストを受信してから応答が送信されるまでに発生するアクティビティを表します。
Web トランザクション時間は 3 つの部分に分かれています。
青色のセグメント: すべてのトランザクション
黄色のセグメント: データベース操作
グリーンセグメント: 外部サービス
ヒント
非同期アプリケーションを監視しようとしている場合、応答時間 (濃い青色の線) は、個々のセグメント (トランザクション、データベース、外部) の応答時間よりも短くなる可能性があります。これは、非同期アプリケーションが複数のリクエストを同時に処理できるために発生する可能性があります。したがって、一部のリクエストがまだ「開いている」間に、トランザクションが「終了」する可能性があります。
トランザクションが遅いということは、何かが異常に動作していることを示す強力な指標である可能性があるため、グラフを見て、サービスの領域で通常よりも応答に時間がかかっているかどうかを確認してください。トランザクションが遅いと、チャート上でスパイクのように見えます。
デプロイメント マーカー ツール を使用して、顧客から
Pay Nowボタンの読み込みに時間がかかるという苦情が寄せられ始めた頃にチームが変更をリリースしたかどうかを確認することもできます。デプロイメント マーカーは、各チャートに灰色のピンとして表示されます。ピンの上にマウスを置くと概要情報が表示されます。また、マーカーをクリックすると展開を詳しく調べることができます。
スループット
Checkout-serviceの応答時間を確認しながら、スループットを調査することもできます。Throughput [スループットは] 、アプリケーションが処理する作業量を測定する方法です。スループットは、ホストとコンテナーの間で作業が均等に分散されているかどうかを理解するのに役立ちます。パフォーマンスの問題は、多くの場合、リソース不足の症状である可能性があります。この例では、スループットが通常よりもわずかに高いことがわかります。サービス低下時にスループットが非常に高い場合は、アプリケーションが処理できる量を超える作業を処理していることを示している可能性があります。
一方、スループットが低い場合は、アプリがあまり多くのリクエストを処理していないことを示している可能性があります。これは、単にあまり使用されていないことを意味している可能性があります。あるいは、アプリケーションを呼び出すサービスが壊れていてリクエストが処理されていないことを意味している可能性があります。
エラー
遅いトランザクションを特定し、スループットを分析したので、今度はエラーを見てみましょう。 Errors [エラー] グラフには、エラーが発生したトランザクションの割合が表示されます。
APM のコンテキストでは、エラーは
TransactionErrorおよびErrorTraceイベントを表します。この場合、ウェブ トランザクションの応答時間が急増したのとほぼ同時期に、
Web errorsの急増が見られます。また、チームがシステムに加えた変更を警告する展開マーカーも表示されます。この最近の展開を取り巻くパターンがわかりました。ユーザー満足度の低下、応答時間、スループット、エラーの増加です。
ドロップダウンを使用して、影響を受けるユーザーのビューに切り替えます。影響を受けるユーザーを追跡する方法については、 「エラー受信箱」を参照してください。
エラーの管理方法の詳細については、 「エラーの管理」を参照してください。
より大きな文脈で問題を特定する
スタックのどの部分に問題がありますか?問題は、サービスを呼び出すエンティティ、またはサービスによって呼び出されるエンティティの変更によって引き起こされましたか?
ログ
ログ グラフには、 ログ イン コンテキスト 機能を通じて報告されたアプリケーションのログの概要が表示されます。 Logs [ログ] をクリックすると、完全な ログ UIが表示されます。
この例では、主要な指標を調査した結果、 Web-transaction 時間に影響を与える最近のデプロイメントに問題があり、その結果エラーが急増し、ユーザー満足度が低下していることがわかりました。次に、これがサービスの他の部分にどのような影響を与えたかを知りたいと考えています。
コンテキスト内のログを使用すると、個々のログに、関連するエンティティまたはサービスのタグが付けられます。ログ グラフでは、 Log patterns (top 10) [ログ パターン (上位 10)] を選択して、一意の文字列識別子までが同一のログのグループを表示できます。
ログ パターンの仕組みの詳細については、 「ログ パターン」を参照してください。
ディストリビューティッド（分散）トレーシング
Distributed tracing insights [分散トレースの分析情報]グラフには、サービスの応答時間、エラー率、またはスループットの増加を引き起こす可能性がある上流と下流のエンティティが表示されます。
たとえば、サービスの応答時間の増加を調査したいが、その急増は外部呼び出しに関連しているとします。分散トレースがサービスの遅延の原因となったダウンストリーム エンティティを記録した場合は、このリストでそのパフォーマンスの変化を確認できます。View trace [トレースの表示]ボタンをクリックすると、パフォーマンスの変化を示す分散トレースが表示されます。
詳細については、分散トレースの洞察に関するドキュメントをご覧ください。
インフラストラクチャー
ここで、APM 概要ページの Infrastructure [インフラストラクチャ] セクションまで下にスクロールします。ここには、 Checkout Service アプリケーションに接続されている各ホストと、その応答時間、スループット、エラー率、CPU パーセンテージの記録をリストした表が表示されます。そしてメモリの割合。
この例では、同じ最近のデプロイメントに関して、応答時間の増加とエラー率の上昇を引き起こす CPU パーセンテージの変更があったかどうかを確認することをお勧めします。
インフラストラクチャ データを調査する方法の詳細については、 こちらのAPM 概要ページをご覧ください。