サービス

1. サイドバーから、 「アプリケーション」 をクリックし、 「サービス」 タブを選択します。
2. 「サービスの構成」 をクリックします
3. 「カスタム・サービス・ルールの追加」をクリックします。
4. ドロップダウン・リストからタグを選択します。

事前定義されたルールと同様に、カスタムサービスルールも、各コールに対して優先順位の低いものから順に適用されます。 コールのサービス名は、一致するルールの中で優先順位が最も高いものに基づいて割り当てられます。

カスタム・サービス・ルールを使用する理由の 1 つは、インフラストラクチャー・コンポーネントの既存のメタ情報を使用することです。 例えば、このラベルからサービスをマップするために、 com.acme.service-name:myserviceなどのドメイン固有の情報で Docker コンテナーにラベルを付ける場合は、 docker.label タグと com.acme.service-name タグを選択します。 ラベル com.acme.service-name を持つコンテナーを渡すすべての呼び出しは、その値によって名前が指定されるサービス (例えば、 myservice) に関連付けられます。 カスタム・サービス・マッピングを作成するために使用できるタグは複数あります。

サービス・マッピングに複数のキーを追加することもできます。 複数のタグはダッシュで連結されます。 すべてのキーが一致する必要があることに注意してください。例えば、ホスト・ゾーンに基づいてステージング・サービスを分離する場合は、 host.zone + docker.label:com.acme.service-nameという 2 つのキーを追加できます。 これにより、サービスには、ホスト・ゾーンの値と docker ラベルを連結した名前が付けられます。 これにより、2 つのサービス (例えば、 prod-myservice と dev-myservice) が分離されます。

特殊なタグ service.default_nameを使用することにより、カスタム・サービス・ルールを使用して、より多くのタグを持つサービス・デフォルト・ルールを拡張することもできます。 例えば、自動的に作成されたサービスをホスト・ゾーンごとに分割するには、タグ service.default_name および host.zoneを使用してカスタム・サービス・ルールを作成します。

サービスに関連付けられているすべての呼び出しのサービス名を設定できます。 サービス名は、 Instana トレーサーによって監視されているプロセスに対してのみ設定できます。

サービスからのすべての着信呼び出しおよび発信呼び出しのサービス名を設定するには、プロセスで INSTANA_SERVICE_NAME 環境変数を設定します。

サービス名を設定しても、プロセスの名前は変更されません。 プロセスの名前を変更するには、 INSTANA_PROCESS_NAME 環境変数を使用します。

コード内の構成を使用して、以下のトレーサーのグローバル・サービス名を設定できます。

• Go
• Node.js
• PHP
• Haskell

Instana で認識される環境変数に関する詳細については、 「環境変数」 を参照してください。

呼び出しごとにサービス名を設定できます。 呼び出しのサービス名を変更すると、ターゲットの入り口スパンまたは出口スパンのソース・サービスまたは宛先サービスが変更されます。

呼び出しのサービス名を変更するには、ターゲット・スパンにカスタム・タグ (custom.tags.service) を追加します。 以下のいずれかのターゲット・トレーサー SDK を選択します。

• Java
• .NET
• Python
• Ruby
• PHP
• Go
• Node.js
• Haskell

setTagOpenTelemtry または OpenTracing でサービス名を設定するには、関数を使用します。

例: span.setTag('service', 'my-service')

呼び出しで X-Instana-Service HTTP ヘッダーを設定すると、宛先 (HTTP 要求を受信するサービス) にヘッダーで指定された値のタグが付けられます。

Instana によってモニターされていないサービスへの呼び出しは、呼び出しタグを使用してサービスにマップされます。

例えば、 www.google.com などのサード・パーティー API への HTTP 呼び出しは、HTTP host ヘッダー (call.http.host タグ) に基づいてサービス www.google.com にマップされます。 www.google.fr または www.google.de への呼び出しは、HTTP の host ヘッダーが異なるため、異なるサービスにマップされます。

以下の手動サービス構成を追加することで、異なるドメインへのすべての呼び出しを「Google」という名前のサービスにマップできます。

{
    "tagFilterExpression": {
        "type": "TAG_FILTER",
        "name": "call.http.host",
        "value": "www.google.",
        "operator": "STARTS_WITH",
        "entity": "NOT_APPLICABLE"
    },
    "unmonitoredServiceName": "Google",
    "description": "Map calls to different google domains to Google service",
    "enabled": true
}
 

Instana によってデータベースやメッセージングシステムが監視されている場合、そのデータベースやメッセージングシステムへの呼び出しは、インフラストラクチャタグに基づいてサービスにマッピングする必要があります（例： MySQL@3306 on demo-host） インフラの連携のおかげで。 ただし、場合によってはプロキシーまたはロード・バランサーの存在により、Instana がそのコンポーネントをモニターまたはインスツルメントせず、要求のルーティング方法がわからないため、インフラストラクチャー相関が機能しないことがあります。 結果として、コールはコール・タグに基づいてサービスにマップされます (例: call.database.schema、 call.database.connection または call.messaging.address) は、宛先サービスがモニターされていないかのようになります。

この場合、呼び出しがないインフラストラクチャー・エンティティーから作成された別のサービスが検出されます。 次の手動サービス構成を使用して、呼び出しを目的の既存サービスにマップできます。

{
    "tagFilterExpression": {
        "type": "TAG_FILTER",
        "name": "call.database.connection",
        "value": "jdbc:mysql://10.128.0.1:3306",
        "operator": "CONTAINS",
        "entity": "NOT_APPLICABLE"
    },
    "existingServiceId": "a880d1875389b78b49b19387ef7ab815b313764f", // service id of "MySQL@3306 on demo-host" service, can be found in the "serviceId" url parameter of the service dashboard
    "description": "Link calls to MySQL@3306 on demo-host service",
    "enabled": true
}
 

サービス・フロー・マップには、現在、20 秒以内に終了する短期実行同期トレースについてのみ正確なデータが表示されます。 それ以外のすべての場合、サービス・フロー・マップに不正確なデータが表示される可能性があります。

リストされているサービスがないのは、エージェントが APM モードで実行されていない、あるいはエージェントがインストールされていないことによってレースが収集されていないか、エージェントはインストールされているが、選択した時間フレームにトレースが収集されなかった場合です。

エージェントがインストールされ、実行されているかどうかを確認するには、 「インフラストラクチャー」 をクリックして、エージェントが存在する可能性があるインフラストラクチャー・マップ上のすべてのホストを表示するか、 「詳細」 > 「エージェント」 をクリックして、インストールされているエージェントのリストを表示します。 エージェントが一覧に表示されていない場合は、 エージェントのインストール方法またはアプリケーション・パースペクティブの作成方法に関するドキュメントを参照してください。

サービス・マッピングは、インフラストラクチャー・データに依存します。 ただし、一部のシナリオでは、インフラストラクチャー・データを使用してトレース・データをエンリッチすることができません。 たとえば、 Instana エージェントや監視対象のプロセスが起動された直後は、トレースデータが十分に蓄積されていない可能性があります。 モニター対象アプリケーションが完全にインスツルメントされるまで、およびトレーサーとセンサーがデータの収集を開始するまで、しばらく時間がかかります。 すべてのセンサーがアクティブになる前に最初のいくつかのトレースが収集された場合、これらのトレースの一部またはすべてのインフラストラクチャー・データが欠落している可能性があります。 このような場合、使用されるサービス名はより一般的なものになります。例えば、` SpringBoot `というアプリケーション名ではなく、` HTTP `というホスト名になります。

Instana エージェントや監視対象プロセスの再起動に伴うサービスマッピングの問題を回避するために、「レジリエントマッピング」と呼ばれるメカニズムが使用されます。 Resilient マッピングは、呼び出しを正しいサービスにマップするためのインフラストラクチャー・データが使用できない場合に有効になります。 レジリエント・マッピングは、過去のマッピング結果のキャッシュを利用して、呼び出しを適切なサービスに割り当てることができます。 ただし、これにより、キャッシュに古いインフラストラクチャー・データが含まれている場合など、予期しないサービス名が発生する可能性があります。 回復力のあるキャッシュが更新されると、予期されるサービスが自動的に戻されます。