アプリケーションのパースペクティブ
アプリケーション・パースペクティブは、Instana の固有のコア機能です。 詳細については、「 Core Concept（コアコンセプト） > Application Perspectives（アプリケーションの視点） 」を参照してください。
アプリケーション・パースペクティブの操作
アプリケーション・パースペクティブ (AP) は、マイクロサービス環境のモニター、アラート、および分析を行うための強力なツールです。 各APは、次の図に示すように、 ゴールデン・シグナルの機能豊富なモニタリング・ダッシュボードを自動生成します。 チームが組織化されるため、彼らは興味のあるサービスに集中し、気が散ることはない。 アラート、エラー、およびログは、トラブルシューティングに集中できるように特定の AP にスコープ設定されます。 セキュリティーの観点から見ると、組織は AP を使用して、インフラストラクチャーおよびサービスに対する可視性を制限できます。
アプリケーション・パースペクティブでは、次のような方法で、ニーズに応じて可視性を「ちょうど良い」サイズに動的にスコープ設定できるようにすることで、これを実現しています。
- サービスのサブセットとその依存関係を指定することによって
- ゾーン別またはクラスタ別
- 技術別
- ビジネス・トランザクションまたはユーザージャーニー別
- 展開エンジン別
- バージョン別またはリリース別
- または任意の組み合わせ
APは、" 分割統治 "という実証済みの問題解決アルゴリズムを適用するのに役立つ
お薦めの本は以下のブログを参照のこと：
アプリケーション・パースペクティブの作成
アプリケーション・パースペクティブは、Instana の固有の機能です。 新規ユーザーは、AP 作成ウィザードを使用して、単純で頻繁に使用されるタイプの AP を簡単に作成できます。 Instana に精通、熟達している場合、あるいは高度な AP を作成する必要がある場合には、拡張画面を使用できます。 データを失うことなく、この2つのモードを簡単に切り替えることができる。
収集されたトレース情報を表示するアプリケーション パースペクティブを作成するには、次のいずれかの手順を実行します：
- Instana UI のサイドバーで [Applications] をクリックし、[ +ADD ] > [ New Application Perspective] をクリックします。
- Instana ランディングページの [アプリケーション] ウィンドウから [ 新規アプリケーション パースペクティブ ] をクリックします。
ウィザードによるAP作成の簡素化
AP 作成ウィザードは、対話式の簡略な AP 作成方法です。 以下の 3 つのステップがあります。
- 一般的なユース・ケースからブループリントを選択します。
- 組み込むサービスまたはエンドポイントを識別するタグと値を選択して、アプリケーションのモデルを指定します。
- 最終的な詳細を入力して、作成を完了します。
次にこれらの各ステップについて、関連するスクリーン・ショットとともに簡潔に説明します。 アドバンス・ モードへの切り替えボタンを選択すれば、いつでもアドバンス・モードに切り替えることができます。
ステップ 1: ブループリントの選択
最初のステップの画面を以下に示す。 APの作成は、いずれかの設計図を選択することから始まる：
- サービスまたはエンドポイント: AP を構成する最も簡単な方法は、サービスまたはエンドポイントのコレクションを直接選択することです。
- 重要なユーザージャーニー ：前述のブループリントと似ていますが、SLI / SLO 機能で使用するためのデフォルトが設定されています。 このブループリントは、より緊密に SLI/SLO と統合するために、将来の拡張が予定されています。
- 環境または地域 ：環境（たとえば、
agent.zoneタグによって記述されるプロダクションまたはステージング）または地域（たとえば、米国東部）に基づいてサービスを選択する。 - 重要な顧客またはテナント ：カスタムタグまたは HTTP パラメータ情報を使用して、重要な顧客またはテナントのためにAPを構築することができます。
- Kubernetes またはコンテナ ：APを形成するサービスの集合を指定するプラットフォーム指向の方法。
- リクエスト属性 ：リクエスト属性(例えば、 HTTP ヘッダー、クエリーパラメータ)に基づくAP。
- テクノロジー ：テクノロジー（例： MySQL, すべてのデータベース）またはアプリケーション名に基づくサービスのグループ。
- カスタムタグ ： SDKを介して独自のメタデータをカスタムタグとして追加することができ、カスタムタグのデータはサービスまたはエンドポイントのコレクションを指定します。
設計図を選択すると、レシピカードが更新され、モデルに関する情報とAP作成のヒントが表示される。 「次へ」を選択して、2 番目のステップに進みます。
ステップ 2: アプリケーション・パースペクティブの指定
2 番目のステップには、AP を形成するデータ・ソースを指定するための 2 つの基準があります。 最初の基準は、タグ選択メニューとクエリービルダーである。 2つ目の基準は、含まれるダウンストリーム・サービスの選択である。 条件を選択または更新すると、プレビュー・ウィンドウに直近1時間のデータに基づいて選択されたサービスが表示されます。 これにより、更新を行い、すぐに効果を確認することで、インタラクティブにセレクションを微調整することができる。 この2つの基準については、多くの説明が必要だ。
クエリ・ビルダーは、『 Unbounded Analytics 』で紹介されているものと似ている。 各ブループリントには、キュレートされた一連のメニューと、各メニューに固有の関連タグがあります。 これにより、タグの選択が簡素化されます。 いくつかのフィルターを使用して、アプリケーション・パースペクティブを指定できます。 プレビュー・ウィンドウには、フィルターに一致するすべてのサービスが一覧表示されます。
ダウンストリーム・サービスは、APの一部として収集される追加情報を決定するため、プレビュー・ウィンドウを更新するもう1つの基準である。 以下の 3 つのオプションがあります。
- ダウンストリーム・サービスはありません ：フィルターから選択されたサービスのみが含まれる（ コアセットと呼ばれる）。 これは、サービスを不透明なものとして扱う場合に役立ちます。 例えば、サードパーティのAPIを表すサービスがそうだ。
- 直接のダウンストリームのデータベースおよびメッセージング・サービス: フィルターからのサービスのコア・セットを含み、さらにコア・セットが直接対話するデータベースおよびメッセージング・サービスを含めるようにこのコア・セットを拡張します。 これは、一連のサービスとその直接の依存関係（例えば、複数のマイクロサービスを担当する開発チーム）を監視したい場合に便利です。
- すべてのダウンストリームのサービス: サービスのコア・セットのエンドツーエンドの依存関係チェーン全体を形成するすべてのサービスが容易かつ自動的に組み込まれます。 これは、AP をトラブルシューティングに使用する場合に便利です。
一度に選択できるのは、これらのオプションのうち 1 つだけです。
下図は、 Kubernetes ネームスペースに基づいてAPを作成する例である。 「すべてのダウンストリームのサービス」が選択されているため、この AP は、クライアントの体験をモニターするための不透明なビューと、トラブルシューティングのためのエンドツーエンド・ビューの両方を提供できます。
Instana ユーザーが Contributor ロールを持つグループのメンバーである場合、新しい AP は Contribution フィルタの定義済みの範囲内でのみ作成できます。 貢献度フィルターの設定の詳細については、 アプリケーションを参照してください。 Instana ユーザーがコントリビューターロールを持つ複数のグループのメンバーである場合、[ コントリビューションフィルタの選択 ] リストが表示されます。 リストからフィルターを選択します。
「次へ」をクリックして、3 番目のステップに進みます。
ステップ 3: 最終的な詳細の指定
APの名前が追加され、デフォルトのダッシュボードビューが選択されている。 デフォルトのダッシュボード・ビューは、簡単なメニュー選択によっていつでも変更できます。 プレビュー・ウィンドウの情報も引き継がれ、選択されたサービスが表示される。 これを図にすると以下のようになる。
「サービスまたはエンドポイント」ブループリントの使用に関するヒント
「サービスまたはエンドポイント」ブループリントを使用して複数の項目を選択できます。ここで取り上げる価値のある機能がいくつかあります。
以下の図では、ユーザーは「サービス」メニュー項目から3つの異なるサービスを選択している。 これらのサービスは、 AND 演算子の代わりにブール演算子（ OR ）で結合されるため、すべてのサービスがAPに含まれる。
複数のエンドポイントを選択するには、まずサービスを選択し、次にそのサービスの複数のエンドポイントを選択します。 以下の図では、カート・サービスで3つのエンドポイントが選択されている。
拡張 AP 作成
拡張 AP 作成ビューでは、1 つの AP に必要なすべてのデータを単一画面で入力します。 このビュー内のステップは以下のとおりです。
- アプリケーション・パースペクティブの名前を入力します。
- タグを使用してアプリケーション・パースペクティブを定義するには、［ フィルタの追加 ］をクリックします。
タグを連結するには、 AND または OR のどちらかの演算子を選択し、括弧を使用する。 AND 、 OR の接続詞を括弧なしで混在して使用する場合、 AND の接続詞が最優先され、最初に評価される。 例えば、タグ A AND タグ B OR タグ C AND タグ D のタグ定義は、 (tag A
AND tag B) OR (tag C AND tag D) として解釈され、処理されます。
アプリケーション内で開始されるデータベースやメッセージング・サービスへの呼び出しを含め、フィルタに一致する各呼び出しは、このアプリケーション・パースペクティブに関連付けられる。
また、フィルターを適用して呼び出しのソースまたは宛先に従ってグループ化するオプションもあります。
- 指定したタグに一致するもののうち、ダウンストリームに含まれるようになったすべてのサービスを含めるには、「すべてのダウンストリーム・サービスを含める」を選択します。 フィルタリングされたサービスのみを考慮する場合は、「ダウンストリーム・サービスなし」を選択します。 選択したサービスと直接通信するデータベースまたはメッセージング・サービスを AP に含める場合は、「直接のダウンストリームのデータベースおよびメッセージング・サービス」を選択します。
- 以下のデフォルトのダッシュボード・ビューを選択します。
インバウンド呼び出し: インバウンド呼び出しは、アプリケーションの外部から開始され、宛先サービスが選択されたアプリケーション・パースペクティブの一部である呼び出しです。
すべての呼び出し: アプリケーション・パースペクティブ・バウンダリーでの呼び出しだけでなく、アプリケーション・パースペクティブ内で発生する呼び出しも含めた結果とメトリック。
デフォルトでは、「サマリー」タブなどの各種ダッシュボードには、「インバウンド呼び出し」の数のみが表示されます。 インバウンド呼び出しかすべての呼び出しかを選択する機能がダッシュボードで使用可能な場合には、パースペクティブを「すべての呼び出し」に切り替えることができます。 アプリケーション・パースペクティブ内でサービスおよびエンドポイントを選択した場合、バウンダリーの設定が継承されます。
拡張モードまたは簡易モードへの切り替え
ボタンを使えば、いつでも簡単なウィザード・モードから上級者モードに切り替えることができる。 ステップ2の例では、上級者モードを選択すると、以下のような画面が表示される。 以前に入力したすべてのデータは、このビューに繰り越される。 逆もまた真なりで、"シンプル・モード "を選択しても、このデータは失われない。
Instana ユーザーが Contributor ロールを持つグループのメンバーである場合、新しい AP は Contribution フィルタの定義済みの範囲内でのみ作成できます。 貢献度フィルターの設定の詳細については、 アプリケーションを参照してください。 Instana ユーザーがコントリビューターロールを持つ複数のグループのメンバーである場合、[ コントリビューションフィルタの選択 ] リストが表示されます。 リストからフィルターを選択します。
アプリケーション・パースペクティブの更新
既存のアプリケーション・パースペクティブを更新または削除できます。 アプリケーションのパースペクティブが更新されると、新しいコンフィギュレーションは、変更後の新しい着信コールにのみ適用されることに注意してください。 変更前のアプリケーションに含まれていた呼び出しやサービスは影響を受けません。
- サイドバーで「アプリケーション」をクリックしてから、アプリケーション・パースペクティブを選択します。
- Configuration タブを選択する。
アプリケーションの視点の限界
アプリケーションのパースペクティブは、サービスを整理し、監視するための強力な方法を提供します。 ただし、以下の制限に注意すること：
1コールあたりの最大アプリケーション・パースペクティブ
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" を使用する。
アプリケーションのパースペクティブ構成を定期的に見直し、適切なスコープが設定され、過度に広範になっていないことを確認する。 誤った設定や広範な視点は、パフォーマンスの問題を引き起こし、モニタリング結果を混乱させる可能性がある。