コンポーネントのサイジングに関する考慮事項

このページでは、Splunk AppDynamics の展開準備をサポートするため、プライベートクラウドまたはパブリッククラウドにホストされているコントローラおよびその他のコンポーネントに関するハードウェアおよびソフトウェアの要件について説明します。

注

コンポーネントごとにメモリを準備する必要があります。
インストールまたはアップグレードする前に、コントローラとさまざまなオペレーティングシステムおよびその他のオンプレミスコンポーネントとの互換性を確認します。「オペレーティングシステムおよびコンポーネントとのコントローラの互換性」を参照してください。

ネットワークに関する考慮事項

ご使用のネットワークまたはホストマシンには、Splunk AppDynamics On-Premises のプラットフォームに対応するよう調整が必要になる、組み込みのファイアウォールルールが存在する可能性があります。また、システムで使用するポートでのネットワークトラフィックを許可しなければならない可能性があります。詳細については、「ポート設定」を参照してください。

各エージェントで予想される帯域幅の消費量については、「アプリサーバーエージェントのインストール」でアプリエージェントの要件のドキュメントを参照してください。

システムユーザーアカウント

すべてのプラットフォームコンポーネントは、単一のユーザーアカウントでインストールするか、そのオペレーティングシステム上で同等の権限を持つアカウントでインストールします。ユーザーには、インストールディレクトリへの書き込み権限が必要です。

次のセクションの左側のペインでコンポーネントを選択して、そのコンポーネントの要件の詳細を表示します。

This page has not yet been translated to Japanese.

CPUとメモリスペースの要件

Enterprise Console ホストがコントローラホストと共有される場合、Enterprise Console には追加メモリ要件がないため、コントローラホストの要件を満たすのに十分なスペースが企業コントローラに必要になります。

ただし、Enterprise Console ホストがコントローラホストと共有されない場合は、追加のメモリとディスク容量が Enterprise Console に必要となります。

追加のスペース要件については、「コントローラホストの準備」を参照してください。

This page has not yet been translated to Japanese.

イベントサービスに対するコントローラのサイズ指定

イベントサービスは EUM、データベースモニタリング、分析で使用されるファイルベースのストレージ機能です。データベースモニタリングは、デフォルトでコントローラに埋め込まれているイベントサービスインスタンスを使用します。必要なディスク容量は、アクティブになっているデータベースの数とモニタリングされているデータベースの数によって異なります。

冗長性やパフォーマンスの最適性を考慮し、イベントサービスは別のマシンで実行する必要があります。

エンドユーザーモニタリング（EUM）の考慮事項

エンドユーザーモニタリング（EUM）により、収集されるメトリックの数は増えます。そのため、EUMを使用するインストールでは、小コントローラプロファイルがサポートされていません。EUM に対しては、20 以上の高トラフィック BRUM または MRUM エージェントを実行する中プロファイルを、大プロファイルに近い指定でサイズ指定する必要があります。

EUM は以下のようなメトリックに影響します。

Web RUM は、1 分間あたりの個別のメトリックデータポイント数を最大 22000 増やすことができます。
モバイル RUM を使用すると、アクセスが多いアプリケーションに対して、インストゥルメント化されたアプリケーションあたり、15K ～ 25K 個の範囲で 1 分間あたりの個別のメトリックデータポイント数を増やすことができます。実際の数は、アプリケーションが受け取るネットワークリクエストの数によって異なります。
EUM のモニタリングはメモリを大量に消費するため、メトリックキャッシュにより多くの容量が割り当てられることがあります。

コントローラのデータベースに保存されている個別の EUM メトリック名の数は、保存された個別のデータポイントの種類より多くなることがあります。たとえば、ユーザー全員が iOS 5 から移行したとしても、iOS 5 のメトリックのメトリック名はデータベース内に残ることがあります。メトリック名はリソースの利用に影響することはありませんが、アプリケーションごとのメトリック名の数に関するコントローラのデフォルト制限に関して、カウントされます。名前のデフォルト制限はブラウザ RUM で 200,000 個、モバイル RUM で 100,000 個となります。

データベースモニタリングの考慮事項

次のガイドラインは、データベースエージェントをモニタリングしているコントローラをホストするマシンに必要な追加のディスクやRAMを判断する時に役立ちます。非常に大規模なインストールについては、Splunk AppDynamics の担当者と連携して追加の指示を受けてください。

オンプレミスのインストールでは、コントローラとイベントサービスを実行するマシンが追加の考慮事項を満たす必要があります。データ保持期間は 10 日間です。

1 ～ 10 コレクタ：2 GB RAM、シングル CPU
10 ～ 20 コレクタ：4 GB RAM、2 CPU
20以上のコレクタ：8 GB RAM、4 CPU

サポートされている環境については、「データベースの可視性がサポートされる環境」を参照してください。

Splunk AppDynamics Infrastructure Visibility を使用すると、アプリケーションを実行しているハードウェアのパフォーマンスをエンドツーエンドで可視化できます。Infrastructure Visibility を使用して、サーバーの障害、JVM のクラッシュ、ネットワークパケット損失など、アプリケーションのパフォーマンスに影響を与える可能性のある問題を特定し、トラブルシュートします。次のページで、さまざまな Infrastructure Visibility のコンポーネントの要件について説明しています。

Elastic Network Interface（ENI）

ENI 番号は、2018 年 2 月 28 日に更新されました。

AWS の場合、各コントローラホストの ENI をプロビジョニングし、ENI の MAC アドレスにライセンスをリンクします。ENI の詳細については、AWS のドキュメントを参照してください。

このドキュメントには、Amazon Web Services と Microsoft のドキュメントへの参照が含まれています。Splunk AppDynamics はいかなる権利も所有しておらず、そのようなサードパーティのドキュメントの正確性または完全性について責任を負いません。

サイズ指定に関するその他の考慮事項

大プロファイルのインストールは、ネットワークアタッチトストレージを使用する仮想マシンまたはシステムではサポートされていません。
RAM の推奨事項では、オペレーティングシステムプロセスのための容量を残しています。ただし、メモリ使用量の大きい他のアプリケーションを同じマシンで実行していないことが想定されています。小またはデモプロファイルのコントローラの場合は Enterprise Console をコントローラと同じホストで実行できますが、中より大きいプロファイルまたは高可用性デプロイの場合は、これが推奨されません。Enterprise Console がコントローラと同じホストにある場合は、「Enterprise Consoleの要件」を参照してください。
サイズ指定表のディスクサイズ指定は、メトリックのおよその消費容量を示しています。各メトリックで、1 分あたり約 7 MB となっています。
マザーボードのソケットは 2 つ以内にする必要があります。
.NET 環境のサイズ指定に関する情報は、「.NET 環境におけるノードカウントの計算」を参照してください。
エージェントカウントには、EUMまたはデータベースの可視性に関する追加の要件は反映されていません。詳細は、以下のセクションを参照してください。

.NET環境におけるノードカウントの計算

.NET エージェントは、IIS サーバーで監視されるアプリケーションの構成によってノードを動的に作成します。IISサーバーは、監視される各IISアプリケーションのインスタンスを複数作成できます。各インスタンスに、.NET エージェントがノードを作成します。たとえば、IISアプリケーションが5つのインスタンスを持っている場合、.NETエージェントは各インスタンスに1つずつ、つまり5ノード作成します。

特定のIISアプリケーションのインスタンスの最大数は、次の図で示されているように、アプリケーションプール用に構成されるワーカープロセスの数によって決まります。

IIS diagram

図は、3つのアプリケーションプールを示しています。AppPool-1、AppPool-2、AppPool-3は次のような特徴を持っています。

AppPool-1 と AppPool-3 のワーカープロセス（Web ガーデン）は最大 2 つで、含まれるアプリケーションはそれぞれ 2 つ（AppA、AppB）と 1 つ（AppF）です。
AppPool-2 はワーカープロセスが 1 つで、3 つのアプリケーションがあります。

各AppPoolのノード数を特定するには、アプリケーションの数と最大ワーカープロセス数を乗算します。これらと、Windows サービスのノードまたはスタンドアロンアプリケーションプロセスを合計します。

この例では、9 つの AppPool ノードが作成されます。Windows サービスに対するノードを追加すると、合計 10 ノードになります。計算は以下のとおりです。

AppPool-1: 2 (applications) * 2 (max number of worker processes)  = 4
AppPool-2: 3 (applications) * 1 (max number of worker processes)  = 3
AppPool-3: 1 (application) * 2 (max number of worker processes)   = 2
Windows Service or standalone application process                 = 1
------
Total:                                                            = 10

BASH

特定の.NETアプリケーション/AppPoolのために起動されるCLRの数を確認する方法：

IIS マネージャを開き、その AppPool に割り当てられたアプリケーション数を表示する。
AppPool が Web ガーデンとして実行されるよう構成されているか確認する。これは、前の例で説明されているように、この AppPool から来ている .NET ノードの数の乗数となる。

また、「View Applications in an Application Pool (IIS 7)」も参照してください。

非同期コールモニタリングの考慮事項

小プロファイルは、大規模な非同期モニタリングを使用するインストールに対応していません。40 以上のエージェントを実行する中プロファイルでは、大規模な非同期モニタリングが追加される場合、大プロファイルに近い構成へのアップグレードが必要になる可能性があります。

非同期コールのモニタリングにより、1 分あたりのメトリック数が最大 23000 に増加します。

Download PDF