アプリケーションモニタリングの概要

Splunk AppDynamics の基本を理解したら、Splunk AppDynamics がアプリケーション環境をどのようにモデル化するかを学習できます。このモデルは、Splunk AppDynamics でパフォーマンス情報を整理して提示するためのフレームワークとして機能します。  

アプリケーションモデルの概要

典型的なアプリケーション環境は、アプリケーションのユーザの要求に応えるためにさまざまな形で相互作用する各種のコンポーネントで構成されます。

• アプリケーションサーバーで稼働するWebアプリケーション
• データベースおよびその他データ保存
• メッセージキューやキャッシュなどのリモートサービス

Splunk AppDynamics アプリエージェントは、最も一般的なアプリケーション フレームワークやサービスを自動検出します。アプリケーションの検出と構成のための組み込み設定を使用して、エージェントがアプリケーションのデータやメトリックを収集してフローマップを構築します。

フローマップは、アプリケーション コンポーネント間のデータのフローを理解しやすくするために、アプリケーションのコンポーネントを視覚的に表現します。たとえば、次のような単純な e-コマースアプリケーションのビジネス トランザクション フロー マップは、Web サービス、メッセージキュー、およびデータベース間のデータのフローを示します。

自動検出を使用して、Splunk AppDynamics の各種機能をすぐに試してみることができます。Splunk AppDynamics の理解が深まり、ご使用の環境に固有の領域を識別したら、アプリケーションモデルを精緻化することができます。

ビジネストランザクション

Splunk AppDynamics のモデルでは、ビジネストランザクションはリクエスト（ユーザーリクエストの場合が最も多い）に対するデータ処理フローを表します。実際には、以下のようなリクエストに応えるために、アプリケーション内のさまざまなコンポーネントが相互作用してサービスを提供します。

• e-コマースアプリケーションでの、ユーザのログイン、商品の検索、カートへの商品の追加
• コンテンツポータルでの、スポーツ、ビジネス、エンターテイメントニュースなどのコンテンツに対するユーザリクエスト
• 株取引アプリケーションの場合、株価の取得や株式の売買などのオペレーション

Splunk AppDynamics アプリエージェントは、ビジネストランザクションへのエントリポイントとしてアプリケーションへのリクエストを検出します。ユーザーログインなどの同様のリクエストは、同じビジネストランザクションの複数のインスタンスとして扱われます。エージェントはリクエストデータにタグを付け、リクエストが Web サーバーからデータベースやその他のインフラストラクチャ コンポーネントに渡される過程でその経路を追跡します。Splunk AppDynamics は、ビジネストランザクションを処理する各ティアのパフォーマンスメトリックを収集します。

ビジネストランザクションのパフォーマンスモニタリングの枠組みは Splunk AppDynamics によって提供されるため、開発者はユーザーの視点でアプリケーション コンポーネントのパフォーマンスに集中することができます。コンポーネントがすぐに利用可能な状態か、それともパフォーマンスの問題を抱えているかをすばやく識別できます。たとえば、ログイン、チェックアウト、または自分のデータの表示をユーザーが実行できるかどうか確認できます。ユーザへの応答時間や、問題が起きた場合の原因を確認できます。 

ビジネス アプリケーション

ビジネスアプリケーションとは、Splunk AppDynamics モデルにおけるトップレベルのコンテナです。ビジネスアプリケーションには一連の関連するサービスおよびビジネストランザクションが含まれます。

Splunk AppDynamics の小規模な展開の場合、環境を構築するには 1 つのビジネスアプリケーションで問題ありません。より大きなデプロイメントを行う場合には、環境モデルを複数のビジネスアプリケーションに分割することができます。

ビジネスアプリケーション管理の最良の方法は、ご使用の環境により異なります。しかし、コントローラUIでのロールベースのアクセス制御はビジネスアプリケーションによって決定されるため、ほとんどのケースでの最も重要な考慮事項は、組織の作業チームを反映するようにビジネスアプリケーションを構造化することです。

ノード

Splunk AppDynamics モデルにおけるノードは、アプリケーション環境でモニタリングの対象となるサーバーまたは JVM に対応します。ノードはモデル化される環境の最小単位です。エージェントのタイプに応じて、ノードは個々のアプリケーションサーバー、JVM、CLR、PHP アプリケーション、Apache Web サーバーに対応している場合があります。 

各ノードは Splunk AppDynamics モデル内で識別されます。エージェントを構成するときに、エージェントがコントローラにデータをレポートする際のノード、ティア、ビジネスアプリケーションの名前を指定します。 

ティア

ティアは Splunk AppDynamics モデルにおける 1 つの単位であり、1 つ以上のノードをグループ化したもので構成されます。ティアをどのように編成するかは、対象の環境の概念モデルによって異なります。

ティアは多くの場合、同じ冗長サーバのセットをグループ化するために使用されます。ただし、これは厳密な要件ではありません。同じノードかどうかにかかわらず、パフォーマンスメトリックを 1 つの単位として扱いたい任意のノードのセットを 1 つのティアにグループ化することができます。

唯一の制限として、1 つのティア内のすべてのノードが同じタイプである必要があります。.NET ノードと Java ノードのように、タイプの異なるエージェントを 1 つのティアに混在させることはできません。 

ビジネスアプリケーションにおけるトラフィックは、フローマップではパフォーマンスメトリックの注釈が付いた線で示されるように、ティア間を流れます。

Splunk AppDynamics モデルでは：

• 単一のティア内でノード間が作用しあうことはありません
• アプリケーションエージェントのノードは2つ以上のティアに属することができません

エンティティ

エンティティは、アプリケーション、ティア、ノード、ビジネストランザクションなど、Splunk AppDynamics がモニターする任意のオブジェクトです。通常、エンティティには、メトリック、イベント、および正常性ステータスが関連付けられています。 

タグ

タグとは、アプリケーション、階層、ノード、合成ページ、サーバーなどのエンティティに関連付けられている、キーと値のペアです。タグは、Splunk AppDynamics コントローラ UI でアプリケーションリソースを見つけるために役立つメタデータとして機能します。適切なカスタムタグを使用してエンティティに関連する問題にタグ付けすることで、エンティティに関連する問題の平均検出時間（MTTD）を短縮できます。

カスタムタグは、CMDB からインポートするか（同期ユーティリティを使用）、Custom Tagging API を使用して API ソースからインポートします。[Application] ダッシュボードと [ Tiers & Nodes ] ダッシュボードの右側のペインにカスタムタグが表示されます。

カスタムタグを使用してエンティティをフィルタリングするには、エンティティページに移動してから、[Tag Filter] をクリックしてリストからタグを選択します。選択したタグフィルタ条件に一致するエンティティのリストが表示されます。

たとえば、所有者名でエンティティを検索する場合は、[Tag Filter] 内の [owner] タグを使用して、選択した owner タグに一致するエンティティを表示することができます。タグは、エンティティの選択を絞り込むために役立ちます。

カスタムタグを使用したエンティティのフィルタリング

エンティティをフィルタリングするには、次の手順を実行します。

1. エンティティページ（[Application]、[Tiers & Nodes]）に移動します。
2. [Filters] > [Tag Filter] をクリックします。
   Custom Tagging API を介してインポートされたすべてのキーが表示されます。
   
3. エンティティをフィルタリングするために必要なタグを選択します。
   
4. （オプション）特定のタグが定義されていないエンティティをフィルタリングするには、特定のタグフィルタの値として [Untagged] を選択します。

エンティティリストのタグの表示

1. [View Options.] をクリックします
   
   
2. [Configure what columns to show] > [Tags] で、タグを選択します。
   選択したタグの列と、設定されたタグ値が表示されます。

履歴およびライブエンティティデータ

コントローラには、アプリケーション、階層、ノード、およびビジネストランザクションの 4 つのエンティティタイプについて「ライブ」または「履歴」ステータスを 365 日以上追跡するエンティティ活性モジュールがあります。 

• Historical:最も古い時刻（最新のコントローラ再起動の 1 年前）から最新のコントローラ再起動時刻まで
• Live:最新のコントローラ再起動時刻から現在の時刻まで

エンティティのアンカーメトリック

エンティティにはアンカーメトリックと呼ばれる特別なメトリックがあり、エンティティの活性を判断するために使用されます。次の表に、各エンティティのアンカーメトリックを示します。

活性状態

エンティティの活性は、階層にロールアップされるため、関連エンティティに影響します。次の表のエンティティタイプがライブである場合、右側の列で関連エンティティの活性を確認できます。

コントローラによるライブエンティティの表示方法

選択した時間範囲のエンティティ活性状態に基づいて、コントローラは次の場所でエンティティをカウントして表示するかどうかを決定します。

• フローマップ
• [Tier] および [Node] リストページ。これは、[Performance Data] チェックボックスによっても決まります。フローマップでライブエンティティデータを参照してください。
• Metric Browserのメトリックツリー
• カスタム ダッシュボード
• トポロジに関連する Splunk AppDynamics REST API。例：アプリケーションモデル API。

バックエンド

バックエンドとは、Splunk AppDynamics エージェントによってインストゥルメント化されないが、ビジネス トランザクション インスタンスの処理には参加するコンポーネントのことです。バックエンドは Web サーバー、データベース、メッセージキュー、またはその他のサービスです。

エージェントは、インストゥルメント化コード（終了コール）からサービスへの呼び出しを認識します。サービスがインストゥルメント化されず、コールのトランザクションコンテキストを継続できない場合、エージェントは当該サービスがバックエンドコンポーネントであると判断します。エージェントはトランザクションコンテキストをバックエンドの応答で認識し、トランザクションをその時点からフォローします。

パフォーマンス情報はバックエンドコールに利用可能です。バックエンドによって処理されるトランザクションの一部について詳細なトランザクション分析を行うには、データベース、Web サービス、またはその他のアプリケーションをインストゥルメント化する必要があります。

その他の Splunk AppDynamics モジュールとの統合

この項では、その他の Splunk AppDynamics SaaS製品が Application Monitoring と連携して、アプリケーションの正常性とユーザー体験を完全かつ全面的に可視化するしくみについて説明します。

Application MonitoringとInfrastructure Visibility 

Infrastructure Visibilityは、アプリケーションの実行基盤であるハードウェアとネットワークをエンドツーエンドで可視化します。Infrastructure Visibilityを使用して、サーバーの障害、JVMのクラッシュ、ハードウェアリソースの使用率など、アプリケーションのパフォーマンスに影響を及ぼす問題を識別し、トラブルシューティングを行うことができます。Infrastructure Visibilityの機能には3つのクラスがあります。

• マシンエージェント を使用して、基本的なハードウェアメトリックを収集します。アプリエージェントのライセンスを 1 つ購入するごとに、マシンエージェントのライセンスが 1 つ付属します。このマシンエージェントは、アプリエージェントがインストールされているマシンと同じマシンにしかデプロイできません。マシンエージェントで提供される機能は次のとおりです。
  • サーバーのOSからの基本的なハードウェアメトリック（例：CPU使用率、メモリ使用量、ディスクおよびネットワークI/O）
  • 拡張機能からコントローラに渡されるカスタムメトリック
  • ランブックの手順を自動化するための修復スクリプトを実行する。オプションで、スクリプトが開始される前に人間による承認を義務付けるように修復アクションを構成できます。
  • JVM Crash Guardを実行してJVMクラッシュをモニタリングし、オプションで修復スクリプトを実行する
• サーバーの可視性ライセンスを持っている場合は、マシンエージェントで次の追加機能が提供されます。
  • マシンの可用性、ディスク/CPU/仮想メモリ使用量、プロセスページフォールトなどの拡張ハードウェアメトリック
  • Dockerコンテナ内で動作するアプリケーションノードをモニタリングし、アプリケーションのパフォーマンスに影響を及ぼすコンテナの問題を識別する
  • Tier Metric Correlator によって階層の全ノードの負荷とパフォーマンスの異常を識別する
  • 内部または外部のHTTPおよびHTTPSサービスをモニタリングする
  • 特定のサーバーグループに正常性ルールを適用できるようにサーバーをグループ化する
  • モニタリング対象のサーバーハードウェアメトリックに基づいて、特定の条件が満たされたか超過したときにトリガーするアラートを定義する

• Network Visibility では、トラフィックフロー、ネットワークパケット、TCP 接続、および TCP ポートがモニタされます。ネットワークエージェントはアプリサーバーエージェントのAPMインテリジェンスを利用して、各アプリケーションが使用するTCP接続を識別します。ネットワークの可視性には以下の機能が含まれます。

  • ドロップ/再送信されたパケット、TCPウィンドウサイズ（有限/ゼロ）、接続セットアップ/ティアダウンの問題、長いラウンドトリップ時間、パフォーマンスに影響するその他の問題に関する詳細なメトリック
  • ティア、ノード、ネットワークリンクのKPI（重要パフォーマンス指標）をハイライトするネットワークダッシュボード
  • ティア、ノード、ネットワークリンクのダッシュボードを右クリックして、トランザクションの異常値からネットワークの根本原因にクイックドリルダウンが可能
  • TCP接続とアプリケーションフローの自動マッピング
  • TCP接続を分割する中間ロードバランサの自動検出
  • 個々の接続の高度な診断情報を収集するための診断モード

Application MonitoringとBrowser Real User Monitoring

End-User MonitoringをApplication Performance Managementに追加すると、ビジネストランザクションのパフォーマンスを、それらのトランザクションのユーザーエクスペリエンスと相関させることができます。詳細については、「ブラウザRUM用のビジネストランザクションの相関」を参照してください。

ブラウザアプリケーションにサービスを提供するアプリケーション上でアプリサーバーエージェントを実行する場合、ブラウザ上で実行されるコードに JavaScript エージェントをインジェクトするために、アプリサーバーエージェントをさらに構成することができます。インジェクションを構成するための設定にはApplications Configurationページからアクセスします。「JavaScriptエージェントの自動インジェクション」および「補助インジェクション」を参照してください。  

Application MonitoringとDatabase Visibility

Application Monitoringでは、インストゥルメント化されたノードによって呼び出されたデータベースはリモートサービスと見なされます。アプリケーションノードとデータベース間の相互作用に関しては多くの情報が得られますが、データベースサーバーの観点からの情報は得られません。Database VisibilityをApplication Monitoringと併用すると、アプリケーションフローマップから直接、詳細なデータベースパフォーマンス情報にドリルダウンできます。「アプリケーションモニタリングビューからデータベースの可視性にアクセスする」を参照してください。 

Application MonitoringとAnalytics

アプリケーションコードをたどっても問題の原因を解明する十分な手がかりを得られない場合、Splunk AppDynamics は特定のビジネストランザクションリクエストと相関する可能性があるトランザクションログを可視化します。ログの相関性の可視化には、Transaction AnalyticsとLog Analytics両方のライセンスが必要になります。「ビジネストランザクションとログの相関性」を参照してください。