当社のツールは、時間が限られている場合にインシデントの解決に役立ちます。 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 - Gray:** アプリケーションのパフォーマンスが極めて危険な状態であるため、すぐに対処する必要があります。
0.5-0.7 - Red: アプリケーションに重大なパフォーマンスの問題があり、すぐに対処する必要があります。
0.7-0.85 -Orange: アプリケーションは悪い方向に進んでいるため、さらに調査する必要があります。
0.85-0.95 - Blue: これは理想的な Apdex 範囲です。 このスコアは、アプリケーションに合わせて Apdex T を完璧に微調整し、パフォーマンスが良好であることを意味します。
> 0.95 - Blue: Apdex スコアがこの範囲内にある場合、Apdex T が少し高く設定されすぎていて、アプリケーションのパフォーマンスを正確に把握できていない可能性があります。 Apdex T を減らすことを検討する必要があります。
ヒント
Apdex スコアが 0 の場合は、リクエストがエラーで返されたことが原因である可能性があります。エラーのあるすべてのリクエストは、Apdex 上で自動的に 0 のスコアを付けられます。
この例では、APM で
Checkout-serviceエンティティを開いた後、Apdex スコアが低下し、0.6 で推移していることがわかります。チャートは赤です。これで、顧客の苦情が正しいことが確実にわかりました。スタックのどこかに問題があるのです。
スコアを理解する方法の詳細については、 「Apdex: ユーザー満足度の測定」を参照してください。
Webトランザクション
お客様からの報告に基づいて、アプリで
Pay nowボタンが失敗していることはわかっていますが、実際のエラーの原因はわかりません。Apdex をチェックしたところ、ユーザー満足度が低いことがわかりました。次のステップは、アプリのWeb-transactionsを調査して、チェックアウト プロセスのどの部分が壊れているかを判断することです。
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)を選択すると、一意の文字列識別子まで同一のログのグループを表示できます。
ログ パターンの仕組みの詳細については、 「ログ パターン」を参照してください。
ディストリビューティッド（分散）トレーシング
Distributed tracing insightsチャートには、サービスのレスポンス時間、エラー率、またはスループットの増加を引き起こす可能性のあるアップストリームおよびダウンストリーム トラフィックが表示されます。
たとえば、サービスのレスポンス時間の増加を調査したいが、その急増は外部呼び出しに関連しているとします。 ディストリビューティッド（分散）トレーシングが、サービスのレイテンシの原因となったダウンストリーム エンタープライズを記録した場合、このリストでパフォーマンスの変化を確認できます。 View traceボタンをクリックすると、パフォーマンスの変化を示す分散トレーシングが表示されます。
詳細については、分散トレースの洞察に関するドキュメントをご覧ください。
インフラストラクチャー
次に、APM 概要ページのInfrastructureセクションまで下にスクロールします。 ここでは、 Checkout Serviceアプリケーションに接続されている各ホストと、そのレスポンス時間、最大値、エラー率、CPU パーセンテージの記録を一覧表示するテーブルが表示されます。 およびメモリの割合。
この例では、同じ最近のデプロイメントに関して、応答時間の増加とエラー率の上昇を引き起こす CPU パーセンテージの変更があったかどうかを確認することをお勧めします。
インフラストラクチャ データを調査する方法の詳細については、 こちらのAPM 概要ページをご覧ください。