アプリケーション・パースペクティブの作成と使用

AP 作成ウィザードは、対話式の簡略な AP 作成方法です。 以下の 3 つのステップがあります。

1. 一般的なユース・ケースからブループリントを選択します。
2. 組み込むサービスまたはエンドポイントを識別するタグと値を選択して、アプリケーションのモデルを指定します。
3. 最終的な詳細を入力して、作成を完了します。

次にこれらの各ステップについて、関連するスクリーン・ショットとともに簡潔に説明します。 「詳細モードに切り替える」 ボタンを選択すれば、いつでも詳細モードに切り替えることができます。

最初のステップの画面を以下に示します。 APの作成は、まずブループリントの中から1つを選択することから始まります：

• サービスまたはエンドポイント: AP を構成する最も簡単な方法は、サービスまたはエンドポイントのコレクションを直接選択することです。
• 重要なユーザージャーニー ：前述のブループリントと同様ですが、SLI/SLO機能で使用するためのデフォルト設定が含まれています。 このブループリントは、より緊密に SLI/SLO と統合するために、将来の拡張が予定されています。
• 環境またはリージョン ：環境（たとえば、` agent.zone tag` で指定される本番環境やステージング環境など）またはリージョン（たとえば、US East）に基づいてサービスを選択します。
• 重要な顧客またはテナント ：カスタムタグや HTTP パラメータの情報を利用することで、重要な顧客やテナント向けのAPを構築することができます。
• Kubernetes またはコンテナ ：APを構成する一連のサービスを指定するための、プラットフォーム指向のアプローチ。
• リクエスト属性 ：リクエスト属性（ HTTP ヘッダーやクエリパラメータなど）に基づくAP。
• テクノロジー ：特定のテクノロジー（例： MySQL,、すべてのデータベース）またはアプリケーション名に基づいたサービスのグループ。
• カスタムタグ ： SDK を使用して独自のメタデータをカスタムタグとして追加できます。このカスタムタグのデータは、サービスやエンドポイントの集合を指定します。

設計図を選択すると、レシピカードが更新され、モデルの情報やAP作成のヒントが表示されます。 「次へ」を選択して、2 番目のステップに進みます。

2 番目のステップには、AP を形成するデータ・ソースを指定するための 2 つの基準があります。 最初の基準は、タグ選択メニューとクエリビルダーです。 2つ目の基準は、組み込む下流サービスの選定です。 条件の選択または更新を行うと、プレビューウィンドウには過去1時間のデータに基づいて選択されたサービスが表示されます。 これにより、変更を加えるとすぐにその効果を確認しながら、選択範囲をインタラクティブに微調整することができます。 この2つの基準については、詳しく説明する必要があります。

クエリビルダーは、『Unbounded Analytics』 で紹介されているものと似ています。 各ブループリントには、キュレートされた一連のメニューと、各メニューに固有の関連タグがあります。 これにより、タグの選択が簡素化されます。 いくつかのフィルターを使用して、アプリケーション・パースペクティブを指定できます。 プレビューウィンドウには、フィルタ条件に一致するすべてのサービスが表示されます。

下流サービスは、プレビューウィンドウを更新するためのもう一つの基準となります。これは、APの一環としてどのような追加情報が収集されるかを決定するからです。 以下の 3 つのオプションがあります。

• 下流のサービスは含まない ：フィルタに一致するサービスのみを含める（ コアセット ）。 依存するサービスは一切含めないでください。 このアプローチは、サードパーティのAPIや外部システムとの連携などを表すサービスなど、サービスをブラックボックスとして扱う場合に有用です。
• 直下流のデータベースおよびメッセージングサービス ：コアセットを含め、さらにコアセットが直接連携するデータベースおよびメッセージングサービスまでを範囲に含める。 各サービスとその直下のデータストアやメッセージングシステムは表示されますが、それ以上の依存関係は表示されません。 このオプションは、サービスがデータを永続化したりメッセージを交換したりする仕組みを把握する必要がある場合に使用します。たとえば、マイクロサービスのグループとその直接的なインフラストラクチャ依存関係を管理する場合などが挙げられます。
• すべての下流サービス ：コアセットのエンドツーエンドの依存関係チェーン全体を含める。 このシステムは、あらゆるレベルで関連するすべてのダウンストリームサービスを自動的に検出し、追加します。 サービス、データベース、メッセージングシステム間をリクエストがどのように流れるかを、全体像として把握できます。 アプリケーションのトポロジー全体を包括的に把握する必要がある場合、特に根本原因の分析や複雑なサービス間の相互作用に関するトラブルシューティングを行う際に、このオプションをご利用ください。 「すべての下流サービス」 を選択すると、範囲がフィルタリングされたコアセットを超えて拡大され、すべての下流の依存関係が含まれるようになります。

一度に選択できるのは、これらのオプションのうち 1 つだけです。

以下の図は、 Kubernetes 名前空間に基づいて AP を作成する例です。 「すべてのダウンストリームのサービス」が選択されているため、この AP は、クライアントの体験をモニターするための不透明なビューと、トラブルシューティングのためのエンドツーエンド・ビューの両方を提供できます。

Instana のユーザーが「Contributor」ロールを有するグループのメンバーである場合、新しいAPは「Contribution」フィルターで定義された範囲内でのみ作成できます。 コントリビューション・フィルターの設定について詳しくは、 アプリケーションを参照してください。 Instana のユーザーが、「Contributor」ロールを持つ複数のグループのメンバーである場合、 「投稿のフィルタ一覧」が表示されます。 リストからフィルターを選択します。

「次へ」をクリックして、3 番目のステップに進みます。

3 番目の最終ステップは以下のように表示されます。ここでは、AP の名前が追加され、デフォルトのダッシュボード・ビューが選択されています。 デフォルトのダッシュボード・ビューは、簡単なメニュー選択によっていつでも変更できます。 プレビューウィンドウの情報も反映され、選択されたサービスが表示されます。 これは、以下の図に示されています。

「サービスまたはエンドポイント」ブループリントを使用して複数の項目を選択できます。ここで取り上げる価値のある機能がいくつかあります。

次の図では、ユーザーが 「サービス 」メニューから3つの異なるサービスを選択しています。 これらのサービスは「 OR ∪」演算子ではなく「 AND ∪」演算子で結合されているため、すべてのサービスがAPに含まれます。

複数のエンドポイントを選択するには、まずサービスを選択し、その後、そのサービスの複数のエンドポイントを選択します。 以下の図では、カート・サービスで 3 つのエンドポイントが選択されています。

いつでも、このボタンをクリックして、シンプルなウィザードモードから詳細モードに切り替えることができます。 ステップ2の例では、詳細モードを選択すると、次のような画面が表示されます。 以前に入力したデータはすべて、この画面に引き継がれます。 その逆も同様です。「シンプルモード」を選択しても、このデータは失われません。

Instana のユーザーが「Contributor」ロールを有するグループのメンバーである場合、新しいAPは「Contribution」フィルターで定義された範囲内でのみ作成できます。 コントリビューション・フィルターの設定について詳しくは、 アプリケーションを参照してください。 Instana のユーザーが、「Contributor」ロールを持つ複数のグループのメンバーである場合、 「投稿のフィルタ一覧」が表示されます。 リストからフィルターを選択します。

既存のアプリケーション・パースペクティブを更新または削除できます。 アプリケーション・パースペクティブが更新されると、新しい構成は、変更後の新しい着信呼び出しにのみ適用されることに注意してください。 変更前のアプリケーションに含まれていた呼び出しやサービスは影響を受けません。

1. サイドバーで「アプリケーション」をクリックしてから、アプリケーション・パースペクティブを選択します。
2. [設定 ] タブを選択します。

1回の公募につき、最大50件の申請案を受け付けます。 この制限は、「送信元アプリケーション」と「受信先アプリケーション」にそれぞれ適用されます。 したがって、1つの呼び出しに対して、最大50の送信元アプリケーションのパースペクティブと50の宛先アプリケーションのパースペクティブを関連付けることができます。 呼び出しがこの制限を超えた場合、各タイプについて最初の50個のアプリケーション・パースペクティブのみが、その呼び出しに関連付けられます。

あるコールが多数のアプリケーション・パースペクティブに関連付けられている場合、通常はアプリケーションの設定ミスによる問題を示しています。 タグフィルタ式において、意図せず論理 AND 演算子 OR を使用してしまうのは、よくある設定ミスです。

たとえば、フィルターを使用してアプリケーション・ service.name = "service-a" OR agent.zone = "prod"パースペクティブを作成すると、どのゾーンにおける service-a へのすべての呼び出し、および ゾーン prod 内のあらゆるサービスへのすべての呼び出しが一致します。 この設定では、意図せず、想定よりもはるかに多くのサービスが含まれてしまう可能性があります。

特定の prod ゾーンで実行されている service-a のみを監視したい場合は、 を使用するのがより的確 service.name = "service-a" AND agent.zone = "prod"な方法です。

アプリケーションのパースペクティブ設定を定期的に見直し、範囲が適切に設定されており、過度に広すぎないことを確認してください。 設定ミスや視野が広すぎることは、パフォーマンスの問題や、監視結果の混乱を招く可能性があります。

アプリケーションのビューに、Analyticsの対応するフィルターと同じ呼び出しが表示されない場合、その違いはタグフィルターの大文字と小文字の区別によるものです。 既存のアプリケーション定義との下位互換性を確保するため、アプリケーション設定におけるタグフィルターの適用では、Call Analyticsとは異なる大文字小文字の区別が適用されます。

• コール分析：大文字小文字を区別しないフィルター

  「 コール分析 」ビューでは、IDおよび一部のキーバリューデータのキー部分を除き、ほとんどのフィルター は大文字と小文字を区別しません。

• アプリケーションの観点：大文字と小文字を区別するフィルタ

  アプリケーションの観点からは、ほとんどのフィルター は大文字と小文字を区別します。 フィルタ値は、実際の値と大文字小文字まで完全に一致する必要があります。 ケースの大文字小文字が一致しない場合、その呼び出しは対象外となります。

例： HTTP のパスが の呼び出しを追跡する場合、 を HTTP > Call Http Path = v1/myappv1/myApp フィルター条件として設定すると（小文字 a）、これらの呼び出しが 「Calls Analytics 」ビューに表示されます。 しかし、このタグフィルターを使用してアプリケーション・パースペクティブを定義すると、同じ呼び出しはアプリケーションに含まれなくなります。 これらをアプリケーションに組み込むには、実際の値とまったく同じ大文字小文字の区別 HTTP > Call Http Path = v1/myApp （大文字 A）でフィルターを定義する必要があります。