サービスリマッピングルール

概要

トレーサー構成を変更したりコードを再デプロイしたりすることなく、Datadog 全体でサービスの表示方法を更新します。サービスリマッピングルールを使用すると、Datadog UI からインフラストラクチャータグに基づいてサービスの名前変更、マージ、分割、または新しいサービスの作成を行うことができます。推論されたサービス、データストア、キューなど、他のエンティティタイプのリマッピングルールを作成することもできます。

各組織に最大 100 個のリマッピングルールを含めることができます。

前提条件

リマッピングルールを作成、編集、削除するには、APM サービスリマッピング書き込み権限 (apm_service_renaming_write) が必要です。Datadog のロールベースのアクセス制御の詳細については、権限を参照してください。

トレーサーバージョンの要件

サービスリマッピングルールは、サポートされているトレーサーバージョンでインスツルメントされたサービスに対してのみ作成できます。サービスが古いトレーサーバージョンから報告されている場合は、そのサービスのリマッピングルールを作成する前に SDK をアップグレードしてください。

注: これは、インスツルメントされたサービスにのみ適用されます。推論されたサービス、データストア、またはキューをリマップするためのトレーサーバージョンの要件はありません。

言語サポートされる最小トレーサーバージョン
C++すべてのバージョンをサポート
Dotnet3.4.0
Go1.55.0
Java1.20.0
JavaScript3.37.0-3.x または 4.16.0
PHP0.94.1
Python1.19.0
Ruby1.15.0

サービスリマッピングルールを作成する

ステップ 1: リマッピングアクションとターゲットエンティティを選択する

  1. Datadog で、[APM] > [Catalog] (カタログ) > [Manage] (管理) > [Service Remapping] (サービスリマッピング) の順に移動します。[Add Service Rule] (サービスのルールを追加) をクリックして、インスツルメントされたサービスをリマップします。推論されたサービス、データストア、またはキューをリマップするには、[Inferred Entity Rules] (推論されたエンティティのルール) タブを選択して [Add Inferred Entity Rule] (推論されたエンティティのルールを追加) をクリックします。

    または、[APM] > [Catalog] に移動し、サービスをクリックしてサービスサイドパネルを開きます。そこから、[Service Page] (サービス詳細画面) > [Service Remapping] (サービスリマッピング) をクリックします。

    [Service Remapping] オプションを含む [Service Page] ドロップダウンメニューが表示されている、サービスのサイドパネル

  2. 新しいリマッピングルールに対して実行するリマッピングアクションを選択します。

    • 単一のエンティティの分割または名前変更や、複数のエンティティのマージまたは名前変更を行うには、[Remap services] (サービスのリマップ) を選択します。
    • インフラストラクチャータグに基づいてサービスを識別するには、[Correlate telemetry] (テレメトリの相関付け) を選択します。

  3. 検索バーを使用して、リマップするエンティティを選択します。

    • 1 つ以上のエンティティを選択できますが、すべて同じタイプ (サービス、推論されたサービス、データストア、またはキュー) である必要があります。表示名のメタデータではなく、service タグまたは peer.service タグに基づいてサービスを選択します。
    • エンティティを選択すると、バックグラウンドでスパンクエリが構築されます。クエリを編集するには、[Build Advanced Query] (高度なクエリを構築) を選択します。
    • サービスをインフラストラクチャータグと相関付ける場合は、_1 つ_のサービスのみを選択できます。テレメトリを相関付けるインフラストラクチャータグを選択します。選択したサービスと同じインフラストラクチャータグを持つすべてのテレメトリが、単一の統合されたサービス名にリマップされます。

ステップ 2: 新しいエンティティ名を指定する

テキストボックスに、選択したエンティティの一意の名前を入力します。または、{{tagName}} 構文でタグ値を使用して、エンティティのタグに基づいてリマップします。入力すると、新しいサービス名のプレビューが表示されます。

  1. タグ値が特定のパターンに従っている場合は、正規表現を適用して、名前に必要な部分のみを抽出します。 注: プレビューは網羅的ではありません。複数の値を持つタグに基づいてサービスをリマップする場合は、スパン数が最も多い値のみがプレビューに表示されます。

ステップ 3: ルールに名前を付けて確認する

  1. オプションで、後で識別できるようにリマッピングルールにわかりやすい名前を付けます。
  2. リマッピングルールを確認して保存します。ルールを保存した後、有効になるまでに約 1 分かかる場合があります。

リマッピングルールの動作

リマッピングルールは、サービスのリマッピングでは service タグ、推論されたサービス、データストア、キューのリマッピングでは peer.service タグを上書きすることで機能します。サービスは取り込み時にリマップされます。リマッピングルールが作成されても、サービス名を指定する既存の構成は変更されません。サービスリマッピングルールは、他のすべてのサービス名の構成よりも優先されます。

リマッピングルールは、APM、ログ、メトリクス、USM、DSM、DJM、DBM、プロファイリング、NPM、Live Processes、Live Containers、Kubernetes、およびイベント全体に適用されます。

  • **履歴データ:**リマッピングルールによる変更は、ルールがアクティブな間に取り込まれたテレメトリにのみ影響します。過去のデータは遡及的に更新されません。ルールを削除または変更すると、新しいデータへの適用は停止されますが、以前に取り込まれたデータの名前は元に戻りません。
  • ルールの順序: サービスリマッピングルールは順番に適用されます。ルールリストの先頭にあるルールが最初に適用されます。サービスは、最初にキャプチャされたルールによってのみリマップされます (同じサービスに複数のルールは適用されません)。
  • 正規表現: 正規表現を使用して新しいサービス名を定義できますが、キャプチャグループ内で貪欲な量指定子を使用することはできません。
  • ログサービスリマッパー: サービスリマッピングルールは、ログパイプラインの前に適用されます。ログサービスリマッパーとリマッピングルールの両方がサービスに適用される場合、リマッピングルールが優先されます。
  • ダッシュボードとモニター: 古いサービス名を参照する既存のクエリは、自動的に更新されません。手動で確認して更新してください。 インテグレーションオーバーライドとカスタムオーバーライド: インテグレーションオーバーライドまたはカスタムオーバーライドがリマッピングルールのスコープ内にある場合、それらもリマップされます。最適な APM エクスペリエンスを得るには、インテグレーションオーバーライドを削除してください。
  • サービス命名階層: サービス名は、優先度の高い順に以下の階層によって決定されます。
    1. サービスリマッピングルール
    2. コード内で定義されたサービス (tracer.Start(WithService(xx)))
    3. システムプロパティで定義されたサービス (-Ddd.service={})
    4. 環境変数で定義されたサービス (DD_SERVICE)
    5. 構成ファイルで定義されたサービス (application_monitoring.yaml)

参考資料

役立つドキュメント、リンク、記事:

サービスリマッピングを使用してサービスデータを包括的に接続するブログ more more