トレースは、同じトレースIDを共有するスパンの集合体であり、アプリケーションとその構成サービスが処理する固有のトランザクションを表します。
各スパンには、そのスパンでキャプチャされた操作を表す名前と、その操作がどのサービス内で行われたかを表すサービス名があります。
さらにスパンは、その親として別のスパンを参照することができ、そのトランザクションを処理するために実行されたトレースでキャプチャされた処理の関係を定義します。
各スパンには、キャプチャされたメソッド、オペレーション、コードブロックに関する以下のような多くの情報が含まれています。例えば:
サービスマップの paymentservice をクリックし、paymentservice の下にあるbreakdownのドロップダウンフィルタから version を選択します。これにより、カスタムスパンタグの version でサービスマップがフィルタリングされます。
これで、サービスマップが以下のスクリーンショットのように更新され、paymentservice の異なるバージョンが表示されていることがわかります。
画面の右側にある Tag Spotlight をスクロールダウンし、ドロップダウンから Top Across All Indexed Tags を選択します。選択したら、下のスクリーンショットにあるように をクリックします。
タグスポットライトのページが表示されます。このページでは、アプリケーションの上位のタグと、それに対応するエラー率や秒間リクエスト数を確認できます。
version スパンタグでは、バージョン 350.10 のエラー率が100%であることがわかります。また、tenant.level スパンタグでは、3つのテナント（Gold、Silver、Bronze）すべてにエラーがあることがわかります。
タグスポットライトのページはインタラクティブに、目的のタグをクリックするだけでフィルタとしてタグを追加することができます。tenant.level の下の gold をクリックして、フィルターとして追加します。これを行うと、ページには tenant.level が gold のデータのみが表示されます。
タグスポットライトは、データを分析して傾向を見極めるのに非常に便利です。Gold Tenantでは、リクエストの総数のうち55件がエラーであることがわかります。（この数字はワークショップの実施時刻により異なります）
これをバージョンタグと関連付けると、バージョン 350.10 が55件、バージョン 350.9 が17件のリクエストに対応していることがわかります。つまり、バージョン 350.10 を経由したリクエストは、すべてエラー状態になったということになります。
paymentservice のバージョン 350.10 からのすべてのリクエストがエラーになるというこの理論をさらに検証するために、タグセレクタを使用して、フィルタを別のテナントに変更することができます。フィルターを gold テナントから silver テナントに変更します。
ここで、silver テナントのエラーのあるリクエスト数を見て、バージョン番号と相関させることで、同様の分析を行うことができます。silver テナントのエラー数は、バージョン 350.10 のリクエスト数と一致していることに注目してください。
タグスポットライトでは、秒間リクエスト数やエラー率だけでなく、サービスごとのレイテンシーも見ることができます。これを行うには、レイテンシーボタンを選択し、silver テナントタグを削除することで、すべての paymentservice のレイテンシーを確認することができます。
右端の Clear All の下にある X ボタンを押して、サービスマップに戻りましょう。
右上にある「Services by Error Rate」グラフのピンク色の線上をクリックします。選択すると、サンプルトレースのリストが表示されます。Initiating Operation ofが frontend: POST /cart/checkout であるサンプルトレースの1つをクリックしてください。
スパンとともに、選択したトレースの全体が表示されます。エラーが発生したスパンは、その横に赤い！マークが表示されます。グレーのボックスにx6などの数字が表示されている場合は、それをクリックするとpaymentservice スパンを展開することができます。
赤い！マークが表示されたpaymentservice スパンの一つをクリックすると展開され、関連するメタデータやエラーの詳細が表示されます。このエラーが401エラーによるものであることがわかります。また、「テナント」や「バージョン」などの有用な情報も表示されています。
エラーの原因が 無効なリクエスト であることがわかりましたが、正確なリクエストが何であるかはわかりません。ページの下部に、ログへのコンテキストリンクが表示されます。このリンクをクリックすると、このスパンに関連付けられているログが表示されます。
下の画像と同様の Log Observer ダッシュボードが表示されます。
フィルタを使用して、エラーログのみを表示できます。右上にあるERRORをクリックしてから、Add to filterをクリックします。
severityがERRORであるログエントリに絞り込まれます。
いずれかのエントリを選択して詳細を表示します。これで、開発者が誤って本番環境にプッシュした 無効なAPIトークン の使用によってエラーがどのように発生したかを確認できます。
おめでとうございます。これで、このAPMワークショップは完了です。