APM の用語と概念

概要

APM UI には、アプリケーションのパフォーマンスをトラブルシューティングし、これを製品全体で関連付けるための多くのツールが用意されています。これにより、分散されたシステムの問題を見つけて解決することができます。

スパン や インデックス化 など、APM の重要な用語の定義や説明については、主な用語集を参照してください。

コンセプト	説明
サービス	サービスは、最新のマイクロサービスアーキテクチャの構成要素です。サービスは、アプリケーションを構築する目的で、エンドポイント、クエリ、またはジョブを広くグループ化します。
リソース	リソースは、顧客アプリケーションの特定のドメインを表します。通常、これはインスツルメントされたウェブエンドポイント、データベースクエリ、またはバックグラウンドジョブです。
モニター	APM メトリクスモニターは、通常のメトリクスモニターと同様に機能しますが、APM 専用に調整されたコントロールを備えています。このモニターを使用して、ヒット、エラー、さまざまなレイテンシー測定に関するサービスレベルでアラートを受信します。
トレース	トレースは、アプリケーションがリクエストを処理するのにかかった時間とこのリクエストのステータスを追跡するために使用されます。各トレースは、1 つ以上のスパンで構成されます。
Trace Context Propagation	The method of passing trace identifiers between services, enabling a Datadog to stitch together individual spans into a complete distributed trace.
Retention Filters	Retention Filter は Datadog UI 内に設定されたタグベースのコントロールで、15 日間にわたって Datadog でインデックスするスパンの種類を決定します。
Ingestion Controls	Ingestion controls は Datadog に最大 100% のトレースを送信し、 15 分間の Live Search および分析を行う際に使用されます。
インスツルメンテーション	インスツルメンテーションとは、可観測性データをキャプチャしてレポートするために、アプリケーションにコードを追加するプロセスです。

サービス

アプリケーションのインスツルメンテーションを行った後、サービスカタログが APM データのメインランディングページになります。

サービスは、最新のマイクロサービスアーキテクチャの構成要素です。サービスは、インスタンスをスケーリングする目的で、エンドポイント、クエリ、またはジョブを広くグループ化します。以下はその例です。

URL エンドポイントのグループは、API サービスの下でグループ化できます。
1 つのデータベースサービス内でグループ化された DB クエリのグループ。
crond サービスで構成された定期的なジョブのグループ。

以下のスクリーンショットは、e コマースサイトビルダー向けのマイクロサービス分散システムです。web-store、ad-server、payment-db、auth-service はすべて、APM のサービスとして表されます。

すべてのサービスはサービスカタログにあり、サービスマップに視覚的に表示されます。各サービスには独自のサービス詳細画面があり、スループット、レイテンシー、エラー率などのトレースメトリクスを表示および検査できます。これらのメトリクスを使用して、ダッシュボードウィジェットの作成、モニターの作成、およびサービスに属する Web エンドポイントやデータベースクエリなどのすべてのリソースのパフォーマンスの確認を行います。

サービス詳細画面に期待していた HTTP エンドポイントが表示されませんか？APM では、エンドポイントはサービス名以上でサービスに接続されます。また、トレースのエントリポイントスパンの `span.name` を使用して行われます。たとえば、上記のウェブストアサービスでは、`web.request` がエントリポイントスパンです。詳細についてはこちらをご覧ください。

リソース

リソースは、顧客アプリケーションの特定のドメインを表します。通常は、インスツルメントされたウェブエンドポイント、データベースクエリ、またはバックグラウンドジョブです。ウェブサービスの場合、これらのリソースは、静的なスパン名 web.request でグループ化された動的なウェブエンドポイントの場合があります。データベースサービスでは、スパン名が db.query のデータベースクエリになります。例えば web-store サービスは、チェックアウト、カートの更新、アイテムの追加などを処理する Web エンドポイントというインスツルメンテーションを自動的に行うリソースを持ちます。リソース名には HTTP メソッドと HTTP ルートを指定することができます。

各リソースには、特定のエンドポイントにスコープされたトレースメトリクスを持つ独自のリソースページがあります。トレースメトリクスは、他の Datadog メトリクスと同様に、ダッシュボードにエクスポートしたり、モニターを作成するために使用することができます。リソースページには、すべてのトレースのスパン、リクエストの分散型トレーシング、およびこのエンドポイントへのリクエストを示すトレースの集計を表示するスパン要約ウィジェットもあります。

Trace

トレースは、アプリケーションがリクエストを処理するのにかかった時間とこのリクエストのステータスを追跡するために使用されます。各トレースは、1 つ以上のスパンで構成されます。リクエストの存続期間中、サービス全体の分散呼び出し（HTTP ヘッダーを介して trace-id が挿入/抽出されるため）、自動的にインスツルメントされたライブラリ、OpenTracing などのオープンソースツールを使用した手動インスツルメンテーションをフレームグラフビューで見ることができます。トレースビューページで、各トレースは、ログをトレースに接続する、タグをスパンに追加する、ランタイムメトリクスを収集するなど、プラットフォームの他の部分に接続する情報を収集します。

Trace context propagation

Trace context propagation is the method of passing trace identifiers between services in a distributed system. It enables Datadog to stitch together individual spans from different services into a single distributed trace. Trace context propagation works by injecting identifiers, such as the trace ID and parent span ID, into HTTP headers as the request flows through the system. The downstream service then extracts these identifiers and continues the trace. This allows the Datadog to reconstruct the full path of a request across multiple services.

For more information, see the propagating the trace context for your application’s language.