Workload Optimization Manager 3.5.0 ターゲット設定ガイド

このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。このマニュアルに記載されている表現、情報、および推奨事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。このマニュアルに記載されている製品の使用は、すべてユーザー側の責任となります。

対象製品のソフトウェア ライセンスと限定保証は、製品に添付された『Information Packet』に記載されています。添付されていない場合には、代理店にご連絡ください。

Cisco が採用している TCP ヘッダー圧縮機能は、UNIX オペレーティング システムの UCB（University of California, Berkeley）のパブリック ドメイン バージョンとして、UCB が開発したプログラムを採用したものです。All rights reserved. Copyright © 1981, Regents of the University of California.

ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコおよび上記代理店は、商品性、特定目的適合、および非侵害の保証、もしくは取り引き、使用、または商慣行から発生する保証を含み、これらに限定することなく、明示または暗黙のすべての保証を放棄します。

いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものとします。

このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアルの中の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際の IP アドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。

この文書の印刷されたハード コピーおよび複製されたソフト コピーは、すべて管理対象外と見なされます。最新版については、現在のオンライン バージョンを参照してください。

シスコは世界各国 200 箇所にオフィスを開設しています。各オフィスの住所、電話番号、FAX 番号は当社の Web サイト（www.cisco.com/go/offices）をご覧ください。

Cisco および Cisco ロゴは、Cisco Systems, Inc. またはその関連会社の米国およびその他の国における登録商標または商標です。シスコの商標の一覧については、https://www.cisco.com/c/en/us/about/legal/trademarks.html をご覧ください。記載されているサードパーティの商標は、それぞれの所有者に帰属します。「パートナー」という用語の使用は Cisco と他社との間のパートナーシップ関係を意味するものではありません。（1721R）

© 2018-2022 Cisco Systems, Inc. All rights reserved.

iv

Cisco www.cisco.com

ターゲットの設定

ターゲットは、仮想環境で管理を実行するサービスです。Workload Optimization Manager は、ターゲットを使用してワークロードをモニタリングし、環境内でアクションを実行します。[ターゲット設定（Target Configuration）] では、Workload Optimization Manager がこれらのサービスとの接続に使用するポートを指定します。Workload Optimization Manager は、ターゲットとして設定する特定のサービスにアクセスできるネットワークにインストールする必要があります。

各ターゲットについて、Workload Optimization Manager は、公開する管理プロトコル（REST API、SMI-S、XML、またはその他の管理トランスポート）経由でサービスと通信します。Workload Optimization Manager は、この通信を使用して、管理エンティティの検出、リソース使用率の監視、アクションの実行を行います。

注：

Workload Optimization Manager は、同じターゲットの重複インスタンスをサポートしていません。ターゲットを構成するときは、環境内の同じアドレスに 2 つ以上のターゲットを構成しないでください。たとえば、2 つの異なるターゲットを同じ AWS アカウントに構成したり、2 つのターゲットを同じ vCenter Server インスタンスに構成したりしてはなりません。

重複するターゲットを構成すると、「Analysis Exception occurred...」というエラーが発生してアクションの実行に失敗する可能性があります。

この問題を解決するには、重複するターゲットを特定し、アドレスごとにターゲットが 1 つだけになるまでそれらを削除します。

Workload Optimization Manager のターゲットとして、次のテクノロジーのインスタンスを割り当てることができます。

■      アプリケーションとデータベース

–      Apache Tomcat 7.x、8.x および 8.5. x

–      AppDynamics 4.1+

–      AppInsights

–      Dynatrace 1.1+

–      IBM WebSphere Application Server 8.5+

–      Instana、リリース 209 以降

–      JBoss Application Server 6.3+

–      JVM 6.0 +

–      Microsoft SQL Server 2012、2014、2016、2017、および 2019

–      MySQL 5.6.x および 5.7.x

–      NewRelic

–      Oracle 11g R2、12c、18c、および 19c

–      Oracle WebLogic 12c

■      クラウドネイティブ

–      準拠した k8s ディストリビューション（Rancher、Tanzu、オープンソースなど）を含む Kubernetes

–      クラウドでホストされる k8s サービス（AKS、EKS、GKE、IBM、Cisco IKS、ROKS、ROSA など）

–      OpenShift 3.11 以降（OCP 4.x）

■      ファブリックとネットワーク

–      Cisco UCS Manager 3.1+

–      HPE OneView 3.00.04

■      ゲスト OS プロセス

–      SNMP

–      WMI：Windows バージョン 8 / 8.1、10、2008 R2、2012 / 2012 R2、2016、2019 および 7

■      ハイパーコンバージド

–      Cisco Hyperflex 3.5

–      Nutanix Community Edition

–      VMware vSAN

■      ハイパーバイザ

–      Citrix XenServer 5.6. x および 6.x

–      Microsoft Hyper-V 2008 R2、Hyper-V 2012/2012 R2、Hyper-V 2016、Hyper-V 2019

–      VMware vCenter 6.0、6.5、6.7、および 7.0+

■      オーケストレータ

–      Action Script

–      Flexera One

–      ServiceNow

■      プライベート クラウド

–      Microsoft System Center 2012/2012 R2 Virtual Machine Manager、System Center 2016 Virtual Machine Manager、および System Center Virtual Machine Manager 2019

■      パブリック クラウド

–      Amazon AWS

–      Amazon AWS Billing

–      Google Cloud Platform（GCP）

–      Google Cloud Platform（GCP）課金情報

–      Microsoft Azure Service Principal

–      Microsoft Azure Billing

–      Microsoft Enterprise Agreement

■      ストレージ

–      EMC ScaleIO 2.x および 3.x

–      SMI-S 8.1 + を使用した EMC VMAX

–      仮想ボリュームと LUN の 1:1 マッピングを搭載した EMC VPLEX ローカルアーキテクチャ

–      EMC XtremIO XMS 4.0 +

–      Spectrum Virtualize 8.3.1.2 またはそれ以降（8.4.2.0 またはそれ以降を推奨）で実行する IBM FlashSystem

–      ONTAP 8.0+ を使用した NetApp Cluster Mode（AFF および SolidFire を除く）

–      Pure Storage F-シリーズおよび M-シリーズアレイ

■      Virtual Desktop Infrastructure

–      VMware Horizon

トランスポート層のセキュリティ要件

Workload Optimization Manager では、ターゲットとのセキュアな通信を確立するために Transport Layer Security（TLS）バージョン 1.2 が必要です。ほとんどのターゲットでは、TLS 1.2 が有効になっていることが必要です。ただし、一部のターゲットでは TLS が有効になっていない場合や、以前のバージョンが有効になっている場合があります。この場合、Workload Optimization Manager がターゲット サービスに接続しようとすると、ハンドシェイク エラーが表示されます。[ターゲット設定（Target Configuration）] ビューに移動すると、そのようなターゲットの検証失敗ステータスが表示されます。

TLS のサポートが原因でターゲットの検証が失敗した場合は、次のような文字列により検証エラーが表示されることがあります。

■      適切なプロトコルがありません（No appropriate protocol）

このエラーを修正するには、ターゲット テクノロジーがサポートする TLS の最新バージョンを有効にしてください。これで問題が解決しない場合は、シスコ テクニカル サポートにお問い合わせください。

■      証明書がアルゴリズムの制約に準拠していません（Certificates does not conform to algorithm constraints）

このエラーを修正するには、ターゲット テクノロジーのマニュアルを参照して、ターゲット サーバで 2048 以上の長さの証明書キーを生成する手順に従ってください。これで問題が解決しない場合は、シスコ テクニカル サポートにお問い合わせください。

ターゲットの編集と削除

Workload Optimization Manager のインストールで管理するターゲット サービスが、[ターゲット設定（Target Configuration）] リストに表示されます。このリストのエントリは、追加、削除、編集できます。ターゲットサービスのアカウントは、実行する Workload Optimization Manager のアクティビティをサポートできる権限を持つように設定する必要があります。たとえば、次のリストは、Workload Optimization Manager が実行できるアクティビティに対応する、vCenter の権限を示しています。

■      読み取り専用—Workload Optimization Manager のモニタリングとシミュレーション（what-if シナリオ）のみを有効にします。

■      VCenter 管理者—Workload Optimization Manager のモニタリング、シミュレーション（what-if シナリオ）、および自動化機能を有効にします。

■      データストアの参照の有効化—アカウントに対してこのプロパティを有効にすると、Workload Optimization Manager に、ストレージ管理機能を有効にするために必要な権限が付与されます。

ターゲットの追加

ターゲット サービスを追加するには、[ターゲット構成（Target Configuration）] ボタンをクリックし、必要な情報を入力し、[適用（Apply）] をクリックしてそれらのターゲットを検証し、新しく検出を開始します。

注：

ターゲットを追加するときは、同じターゲットに重複するエントリを追加しないようにしてください。

入力する一般的な情報は次のとおりです。

■      [Target Type]—サポートされているテクノロジーから選択します。

テクノロジーを選択したら、そのテクノロジーに固有のターゲット タイプを選択します。たとえば、クラウド管理の場合、AWS を選択できます。

■      [Hostname or IP address]—追加するターゲットサービスのアドレスです。

■      [User Name]—ターゲットサービスの有効なアカウントユーザー名です。

■      [Password]—ターゲット サービス アカウントのパスワードです。

ターゲットの削除

ターゲットを削除するには、リストでエントリを選択し、[削除（Delete）] をクリックします。

アプリケーションおよびデータベース ターゲット

アプリケーションおよびデータベースターゲットは、管理サーバーによって制御される特定のアプリケーションサーバーのドメインをサポートします。このような管理対象ドメインでは、管理サーバーをターゲットとして追加します。すると、Workload Optimization Manager が管理対象アプリケーションサーバーを検出します。

注：

アプリケーション環境を管理するときに、Workload Optimization Manager は、接続されたアプリケーション コンポーネントを検出して、エンティティのサプライチェーンにそれらをつなぎ合わせます。IP アドレスではなく名前で行われる接続の場合、Workload Optimization Manager は DNS 呼び出しを実行して、これらの名前を IP アドレスに解決します。これは、繰り返される検出サイクル中に発生する可能性があります。

サプライ チェーン

アプリケーションおよびデータベース  ターゲットは、ビジネス  アプリケーション、ビジネス  トランザクション、サービス、アプリケーション コンポーネント、アプリケーション  サーバー、およびデータベース  サーバーのエンティティをサプライチェーンに追加します。関連するターゲットページに移動すると、これらのエンティティがターゲットの名称にどのように対応しているかを確認できます。

Cisco AppDynamics

Workload Optimization Manager は、AppDynamics インスタンスをターゲットとしてWorkload Optimization Manager に追加することで、AppDynamics によってモニタされるアプリケーション インフラストラクチャのワークロード管理をサポートします。

Workload Optimization Manager と AppDynamics の統合により、アプリケーションから物理ハードウェアまで、環境のフルスタック ビューを提供します。Workload Optimization Manager は、AppDynamics から取得した情報を使用し、個々のアプリケーションの要求を十分に把握した上で、パフォーマンスを保証し、効率を向上させるための推奨事項とアクションを実行できます。

デフォルト設定では、AppDynamics ターゲットは、プロキシが使用されている場合はデフォルトの収集期間内に最大 1100 個の AppDynamics ノードを収集し、プロキシが不要な場合は最大 5000 ノードを収集します。大規模な AppDynamics 環境では、完全なデータを収集するのに 1 サイクル以上かかるものと見込まれます。

注：

Kubernetes 環境の場合、Workload Optimization Manager は、NewRelic、AppDynamics、Instana、および Dynatrace のコンテナー化されたアプリケーション コンポーネントをサプライチェーンに結合して、アプリケーションの統一されたビューを提供します。詳細については、「クラウド ネイティブ ターゲット」（53  ページ）を参照してください。

前提条件

■      有効な AppDynamics ユーザーアカウント。

すべてのタイプのアプリケーション インスタンスで、サービス アカウントには読み取り専用ユーザー  ロールが必要です。モニタリング データベース インスタンスの場合、このユーザーには DB モニタリング ユーザー  ロールも必要です。

注:

これらの役割が利用可能な新しいバージョンの AppDynamics では、代わりにそれらを使用する必要があります。

–      アプリケーションとダッシュボードビューア

–      DB モニタリング ユーザー

–      サーバーモニタリング

カスタムロールを使用するには、そのロールに、アプリケーションとデータベースの両方に対するサーバーの可視性 の表示権限があることを確認してください。

AppDynamics データベース サーバ

AppDynamicsは、データベース サーバもモニタリングします。データベース サーバを環境の残りの部分に正しく接続するには、次の手順を実行する必要があります。

■      拡張メトリック収集を有効にします。

Hyper-V ホストの場合は、データベースをホストするターゲット VM に Hyper-V 統合サービスをインストールする必要があります。詳細については、次の統合サービス TechNet の記事を参照してください。

https://technet.microsoft.com/en-us/library/dn798297%28v=ws.11%29.aspx

VMware ホストの場合は、ターゲット VM に VMware ツールをインストールする必要があります。

■      AppDynamics のデータベース名が、Workload Optimization Manager インスタンスによって IP アドレスに解決可能であることを確認します。

DNS または Workload Optimization Manager インスタンスのファイル /etc/resolv.conf   の変更が必要になる場合があります。

エンティティ マッピング

新しいターゲットを検証した後、Workload Optimization Manager は接続されたエンティティを検出します。次の表は、ターゲットと Workload Optimization Manager の間のエンティティマッピングについて示しています。

AppDynamics ターゲットの追加

注:

AppDynamics と Workload Optimization Manager の両方を使用して特定のアプリケーションまたはデータベース サーバをモニタすることは可能ですが、エンティティがマーケットで重複しているように見えるため、これは避ける必要があります。

アプリケーションが AppDynamics によってモニタリング されている場合は、別の Workload Optimization Manager のアプリケーション ターゲットとして追加しないでください。

AppDynamics インスタンスをターゲットとして追加するには、次のように指定します。

■      [Hostname] または [IP Address]

AppDynamics コントローラインスタンスのホスト名または IP アドレス。

■      ポート

AppDynamics コントローラへの接続で使用するポート。デフォルトでは、これはポート 80（HTTP）と 443（HTTPS）に設定されています。

注：SaaS ベースの AppDynamics インスタンスの場合、ポート 443 を使用する必要があります。

■      [Username] または [API Client Name@Account]

必要なロールを持つユーザー名とアカウントID。形式は「ユーザー名@テナント」とする必要があり、ユーザーは「読み取り専用ユーザー」および「DB モニタリング ユーザー」権限を持っている必要があります。このユーザー名は、AppDynamics の「License > Account」ページで確認できます。oAuth 認証の場合、ユーザー名は API クライアントとして定義されたユーザーとする必要があります。

注：

ユーザー名とパスワードには、次の特殊文字を含めることはできません。

\ / " [ ] : |< > + =;, ? *, ' タブスペース @

■      [Password] または [Client Secret]

AppDynamics インスタンスへの接続に使用するアカウントのパスワード。oAuth の場合、これはクライアントの秘密鍵になります。

注：

ユーザー名とパスワードには、次の特殊文字を含めることはできません。

\ / " [ ] : |< > + =;, ? *, ' タブスペース @

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

■      [Secure Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由で接続します。必要な証明書がホストで使用できるように設定されていることを確認します。

■      [Use API Client (OAuth)]

オンにすると、ターゲット接続に対して Open Authorization (OAuth) トークンベースの認証が有効になります。

■      Proxy Host

このターゲットが使用するプロキシのアドレス。プロキシ経由で AppDynamics インスタンスに接続する場合にのみ、プロキシ情報を入力します。

■      Proxy Port

上記で指定したプロキシで使用するポート。デフォルトでは 8080 です。

■      [Proxy Username]

上記で指定したプロキシで使用するユーザー名。

■      [Proxy Password]

上記で指定したプロキシで使用するパスワード。

■      [Secure Proxy Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由でプロキシに接続します。API クライアント ユーザーの作成に関する詳細については、「AppDynamics マニュアル」を参照してください。

アクション

注:

Workload Optimization Manager が推奨する特定のアクションは、Workload Optimization Manager が検出するプロセスによって異なります。

他のアプリケーション コンポーネントの場合、Workload Optimization Manager は、アプリケーションで検出できるリソースに基づいてアクションを推奨する場合があります。たとえば、Node.js® アプリケーションは CPU 使用率を報告するため、Workload Optimization Manager はそのアプリケーションタイプの vCPU サイズ変更アクションを生成して、ユーザーインターフェイスに表示できます。

Workload Optimization Managerは、AppDynamics サプライチェーンのアクションを次のように推奨します。

注：

さまざまなタイプのデータベースサーバーに対して、AppDynamics ターゲットはさまざまなメトリックを返します。これは、Workload Optimization Manager のアクションに次のように影響します。

■      MySQL：

MySQL データベース サーバーの場合、分析では、DB メモリ、接続、またはトランザクションログのサイズ変更アクションは生成されません。ターゲットは、DB キャッシュ ヒット率、DB メモリ、接続、またはトランザクション ログを検出しません。

■      Microsoft SQL Server：

Microsoft SQL データベースサーバーの場合、分析は DB メモリまたは接続のサイズ変更アクションを生成しません。ターゲットは、DB メモリまたは接続を検出しません。

■      MongoDB：

MongoDB データベースサーバーの場合、分析は DB メモリまたはトランザクションログのサイズ変更アクションを生成しません。ターゲットは、DB キャッシュヒット率、DB メモリ、トランザクション、またはトランザクションログを検出しません。

■      Oracle：

Oracle データベースサーバーの場合、分析では、DB メモリ、接続、またはトランザクションログのサイズ変更アクションは生成されません。ターゲットは、DB メモリ、接続、またはトランザクションログを検出しません。

モニタ対象リソース

注:

このターゲットが実際にモニタリングするリソースは、アプリケーションのタイプによって異なります。エンティティごとの次のメトリックのリストには、表示される可能性のあるすべてのリソースが含まれています。

特定の VM について、表示されるリソースは、VM の検出方法と、このターゲットによって検出されたアプリケーションに VM がリソースを提供するかどうかによって異なります。

■      VM がこのターゲットを介して検出されたアプリケーションをホストしている場合、このターゲットを介して検出された VM メトリックが表示されます。

■      VM が別のターゲットを介して検出され、このターゲットを介して検出されたアプリケーションをホストしていない場合、その別のターゲットを介して検出された VM メトリックが表示されます。

■      VM がこのターゲットを介して検出されたが、このターゲットを介して検出されたアプリケーションをホストしていない場合、Workload Optimization Manager は VM のメトリックを表示しません。

Workload Optimization Managerは、AppDynamics サプライチェーンの次のリソースをモニタリングします。

Application Insights

Workload Optimization Manager は、アプリケーションからホスティングサーバーまで、環境をフルスタックで表示する Workload Optimization Manager 統合を介して、Application Insights がモニタリングするアプリケーション インフラストラクチャのワークロード管理をサポートします。Workload Optimization Manager は、Application Insights から取得した情報を使用し、個々のアプリケーションの要求を十分に把握した上で、パフォーマンスを保証し、効率を向上させるための推奨事項とアクションを実行できます。

前提条件

■      Microsoft Azure（135 ページ ）ターゲットで説明したものと同じアクセス許可を持つ、有効な Application Insights ユーザーアカウント。

エンティティ マッピング

新しいターゲットを検証した後、Workload Optimization Manager は接続されたエンティティを検出します。次の表は、ターゲットと Workload Optimization Manager の間のエンティティマッピングについて示しています。

Application Insights ターゲットの追加

注：

アプリケーションが Application Insights または Azure によって監視されている場合は、別の Workload Optimization Manager のアプリケーションターゲットとして追加しないでください。

Application Insights をターゲットとして追加するには、次の項目を指定します。

■      [Unique Target Description]

Workload Optimization Manager UI に表示されるユーザーが作成した名前。

■      テナント名

Application Insights に関連付けられた Azure サブスクリプションに関連するテナント。

■      Azure サブスクリプション ID

Application Insights に関連付けられた Azure ターゲットへのアクセス権を持つ Azure サブスクリプションの ID。

■      Client ID

Workload Optimization Manager が Azure サブスクリプションのリソースにアクセスできるようにするアプリケーション登録のクライアント ID。

■      [Client Secret Key]

アプリケーション登録の秘密鍵。

■      [Offer ID]

Azure サブスクリプションに関連する Azure オファー ID（該当する場合）。

■      [Enrollment Number]

Azure EA アカウントの場合、Azure サブスクリプションに関連付けられた登録番号。

■      Proxy Host

このターゲットが使用するプロキシのアドレス。プロキシ経由で AppDynamics インスタンスに接続する場合にのみ、プロキシ情報を入力します。

■      Proxy Port

上記で指定したプロキシで使用するポート。デフォルトでは 8080 です。

■      [Proxy Username]

上記で指定したプロキシで使用するユーザー名。

■      [Proxy Password]

上記で指定したプロキシで使用するパスワード。

■      [Secure Proxy Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由でプロキシに接続します。

Application Insights アプリケーションの Workload Optimization Manager 環境への統合

Application Insights によってモニタリングされる各アプリケーションには、複数の関連付けられたアプリケーションが含まれる場合があります。これらのアプリケーションのそれぞれを異なるホスティングサーバーに展開できます。同様に、ホスティングサーバーは、複数のアプリケーションの複数のグループまたは部分的なグループをホストできます。

Application Insights からメトリックを正確に結合するには、ホスティングサーバーのホスト名または IP アドレスが Application Insights インスタンスを通じて検出可能である必要があります。ほとんどのモニタリング対象のアプリケーション インスタンスでは、これは自動で行われます。ホスティングサーバーを検出できない場合は、アプリケーションの Azure タグを指定して、IP アドレスまたはホスト名を示すことができます。

Azure タグは次のような name : value の形式で指定できます。

CWOM-Host-Name : RoleInstance=hostname;RoleInstance=hostname;RoleInstance=hostname;

前の例では、RoleInstance  はアプリケーション インスタンスの名前であり、hostname  はホスティング サーバです。例：CWOM-Host-Name : cluster-app-a=120.120.120.10;cluster-app- b=120.120.120.11;cluster-app- c=120.120.120.12;.

注：これらのタグを指定すると、Application Insights API を介して検出された値が置き換えられます。

アクション

注:

Workload Optimization Manager が推奨する特定のアクションは、Workload Optimization Manager が検出するプロセスによって異なります。

他のアプリケーション コンポーネントの場合、Workload Optimization Manager は、アプリケーションで検出できるリソースに基づいてアクションを推奨する場合があります。たとえば、Node.js® アプリケーションは CPU 使用率を報告するため、Workload Optimization Manager はそのアプリケーションタイプの vCPU サイズ変更アクションを生成して、ユーザーインターフェイスに表示できます。

モニタ対象リソース

注:

実際にモニタされるリソースは、アプリケーションのタイプによって異なります。このリストには、表示されるすべてのリソースが含まれます。Workload Optimization Manager は、Application Insights サプライチェーンの次のリソースをモニタリング します。

New Relic

Workload Optimization Manager は、アプリケーション インスタンスからホストまで、New Relic がモニタリングするアプリケーション インフラストラクチャのワークロード管理をサポートします。Workload Optimization Manager は、New Relic から取得した情報を使用し、個々のアプリケーションに必要なものに対応するために、パフォーマンスを保証し、効率を向上させるための推奨事項の提示とアクションの実行が可能です。Kubernetes 環境の場合、Workload Optimization Manager は、コンテナ化されたアプリケーション コンポーネントをサプライチェーンに結合して、アプリケーションの統一されたビューを提供します。

注：

Kubernetes 環境の場合、Workload Optimization Manager は、NewRelic、AppDynamics、Instana、および Dynatrace のコンテナー化されたアプリケーション コンポーネントをサプライチェーンに結合して、アプリケーションの統一されたビューを提供します。詳細については、「クラウド ネイティブ ターゲット」（53  ページ）を参照してください。

前提条件

■      APM とインフラストラクチャのモニタリングの両方を含む有効な New Relic ユーザーアカウント。

エンティティ マッピング

新しいターゲットを検証した後、Workload Optimization Manager は接続されたエンティティを検出します。次の表は、ターゲットと Workload Optimization Manager の間のエンティティマッピングについて示しています。

VM エンティティの場合

サポートされるアプリケーション

Workload Optimization Manager は、New Relic ターゲットを介して次のアプリケーションタイプ（および関連するコモディティ）を検出します。

サポートされるデータベース

Workload Optimization Manager は、次のデータベースタイプとコモディティをサポートしています。

注：データベース コモディティは、Workload Optimization Manager への接続に使用される New Relic アカウントに New Relic Infrastructure Pro  のサブスクリプションがある場合にのみ公開されます。

New Relic ターゲットの追加

注：

アプリケーションが New Relic によってモニタリングされている場合は、別の Workload Optimization Manager のアプリケーションターゲットとして追加しないでください。

New Relic をターゲットとして追加するには、次を指定します。

■      アカウント ID（Account ID）

New Relic アカウント ID。

■      [REST API Key]

New Relic プラットフォームが提供する REST API キー。詳細については、「New Relic API キー」を参照してください。

■      [GraphQL API Key]

GraphQL サービスによって提供される GraphQL API キー。これは、上記の REST API キーとは異なります。 詳細については、「Generate a new API key in the GraphiQL Explorer」を参照してください。

■      [EU Region]

オンにすると、Workload Optimization Manager は EU API エンドポイントを使用します。

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

■      [Proxy Host]（任意）プロキシホストの IP。

■      [Proxy Port]（任意）

プロキシに必要なポート。

■      [Proxy Username]（任意）

プロキシに必要なユーザー名。

■      [Proxy Password]（任意）

プロキシに必要なパスワード。

■      [Secure Proxy Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由でプロキシに接続します。

アクション

注:

Workload Optimization Manager が推奨する特定のアクションは、Workload Optimization Manager が検出するプロセスによって異なります。

他のアプリケーション コンポーネントの場合、Workload Optimization Manager は、アプリケーションで検出できるリソースに基づいてアクションを推奨する場合があります。たとえば、Node.js® アプリケーションは CPU 使用率を報告するため、Workload Optimization Manager はそのアプリケーションタイプの vCPU サイズ変更アクションを生成して、ユーザーインターフェイスに表示できます。

Workload Optimization Manager は、次のように New Relic サプライチェーンのアクションを推奨します。

モニタ対象リソース

注:

このターゲットが実際にモニタリングするリソースは、アプリケーションのタイプによって異なります。エンティティごとの次のメトリックのリストには、表示される可能性のあるすべてのリソースが含まれています。

特定の VM について、表示されるリソースは、VM の検出方法と、このターゲットによって検出されたアプリケーションに VM がリソースを提供するかどうかによって異なります。

■      VM がこのターゲットを介して検出されたアプリケーションをホストしている場合、このターゲットを介して検出された VM メトリックが表示されます。

■      VM が別のターゲットを介して検出され、このターゲットを介して検出されたアプリケーションをホストしていない場合、その別のターゲットを介して検出された VM メトリックが表示されます。

■      VM がこのターゲットを介して検出されたが、このターゲットを介して検出されたアプリケーションをホストしていない場合、Workload Optimization Manager は VM のメトリックを表示しません。

Workload Optimization Manager は、New Relic サプライチェーンの次のリソースをモニタリングします。

Dynatrace

Workload Optimization Manager は、Dynatrace プラットフォームによって管理されるアプリケーションの検出をサポートします。Workload Optimization Manager は、VM アクションの計算に、これらのアプリケーションについて検出された情報を含めます。

注：

Kubernetes 環境の場合、Workload Optimization Manager は、NewRelic、AppDynamics、Instana、および Dynatrace のコンテナー化されたアプリケーション コンポーネントをサプライチェーンに結合して、アプリケーションの統一されたビューを提供します。詳細については、「クラウド ネイティブ ターゲット」（53  ページ）を参照してください。

前提条件

■      Dynatrace サーバーインスタンス

このインスタンスは、環境で実行中のアプリケーションをモニタリングするように設定する必要があります。

Workload Optimization Manager は、SaaS とオンプレミス両方の Dynatrace サーバーのインストールをサポートします。

■      Dynatrace によって管理されるアプリケーションをホストしている管理対象 VM。

Workload Optimization Manager が Dynatrace を介してアプリケーションを検出するには、アプリケーションが環境内の VM で実行されている必要があります。また、これらの VM は、ハイパーバイザやパブリック クラウド ターゲットなどの Workload Optimization Manager ターゲットで管理する必要があります。

■      適切なスコープを持つ API アクセストークン

Workload Optimization Manager は Dynatrace API へのコールを認証するために API トークンを使用します。次の範囲で汎用トークンを使用します。

注：

Workload Optimization Manager 3.4.2 より以前のバージョンから、3.4.2 またはそれ以降のバージョンにアップデートする場合、既存の Dynatrace ターゲットごとに新しい API ターゲットを生成する必要があります。トークンをターゲット構成に入力し、そのターゲットを検証する必要があります。

エンティティ マッピング

新しいターゲットを検証した後、Workload Optimization Manager は接続されたエンティティを検出します。Workload Optimization Manager がサプライチェーンに表示するエンティティ名は、Dynatrace がユーザーインターフェイスに表示するエンティティ名とは異なります。以下に例を示します。

Dynatrace ターゲットの追加

注:

特定のアプリケーションまたはデータベース  サーバーを、Dynatrace と Workload Optimization Manager の両方で管理することができます。このような設定は、Workload Optimization Manager がマーケットで重複するエンティティを生成する可能性があるため、避けるべきです。

Dynamictrace サーバーを介してアプリケーションを管理し、Workload Optimization Manager ターゲットとしてその Dynamictrace サーバーを設定する場合は、Workload Optimization Manager 側でそのアプリケーションを別のアプリケーションターゲットとして追加していないことを確認してください。

ターゲットとして Dynatrace サーバー インスタンスを追加するには、次を指定します。

■      [Hostname] または [IP Address]

DynaTrace のオンプレミスインストールの場合、ホスト名または IP とエンドポイントをスラッシュで区切って指定します。たとえば、

10.10.10.10/e/b70e3eb2-e82b-4c13-a5a4-560d9865841r.

SaaS インストールの場合、パスに {IP_ADDRESS}/e/ ステートメントを含めず に URL を指定します。たとえば、

ayz12745.live.dynatrace.com

■      [API Token]

Workload Optimization Manager が Dynatrace API へのコールを認証するために使用するトークン。このトークンには、Dynatrace API V1 および V2 を介してGETメソッドを実行する権限が必要です。次の範囲で汎用トークンを使用します。

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

■      Proxy Host

このターゲットが使用するプロキシのアドレス。プロキシ経由で Dynatrace サーバに接続する場合は、プロキシ情報のみを入力します。

■      Proxy Port

上記で指定したプロキシで使用するポート。デフォルトでは 8080 です。

■      [Proxy Username]

上記で指定したプロキシにログインするためのアカウントのユーザー名。

■      [Proxy Password]

上記で指定したプロキシで使用するパスワード。

■      [Secure Proxy Connection]

プロキシとの安全な接続を使用するかどうかを指定します。オンにすると、Workload Optimization Manager は HTTPS を介してプロキシに接続します。

アクション

モニタ対象リソース

注:

Workload Optimization Manager がアプリケーションについて検出するリソースのサブセットは、アプリケーションのタイプによって異なります。次のエンティティごとのメトリックのリストには、Workload Optimization Manager が Dynatrace アプリケーションのために検出できるリソースの完全なセットが含まれます。

データベース サーバー アプリケーションの場合、Workload Optimization Manager は MySQL および MSSQL データベースのメトリックのみを検出します。

特定の VM について、表示されるリソースは、VM の検出方法と、このターゲットによって検出されたアプリケーションに VM がリソースを提供するかどうかによって異なります。

■      VM がこのターゲットを介して検出されたアプリケーションをホストしている場合、このターゲットを介して検出された VM メトリックが表示されます。

■      VM が別のターゲットを介して検出され、このターゲットを介して検出されたアプリケーションをホストしていない場合、その別のターゲットを介して検出された VM メトリックが表示されます。

■      VM がこのターゲットを介して検出されたが、このターゲットを介して検出されたアプリケーションをホストしていない場合、Workload Optimization Manager は VM のメトリックを表示しません。

Workload Optimization Manager は、Dynatrace サプライ チェーンの次のリソースをモニタリングします。

MySQL

MySQL データベースを管理するために、Workload Optimization Manager は、定義された範囲内の 1 つ以上のデータベース サーバに接続できます。

前提条件

■      ユーザー権限が MySQL サーバーで有効になっている。「MySQL でのユーザー権限の有効化」（27  ページ）を参照してください。

MySQL データベース ターゲットの追加

特定の範囲内で一致するすべてのターゲットを追加できます。データベース サーバをターゲットとして追加するには、次のように指定します。

■      [Target ID]

Workload Optimization Manager UI に表示される名前

■      ユーザ名

Workload Optimization Manager がターゲットへの接続に使用するアカウントのユーザー名。

■      パスワード

Workload Optimization Manager がターゲットへの接続に使用するアカウントのパスワード。

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      Port Number

MySQL リモートポート。空白の場合、Workload Optimization Manager は MySQL のデフォルトポートである 3306 を使用します。

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

収集されたメトリックの精度を高めるために、このオプションはデフォルトでオフになっています。

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

アクション

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

MySQL Server でのユーザー権限の有効化

MySQL Server で適切なユーザー権限を有効にするには、次の手順に従います。

1.      MySQL Server の設定ファイルを編集します。

ユーザー権限を付与するために、MySQL サーバーの .conf  ファイルを編集する必要があります。サーバでセキュア シェル セッションを開き、ファイルを編集します。MySQL を実行しているプラットフォームに応じて、ファイルを別の場所に配置します。

■      Debian Linux：

/etc/mysql/my.cnf

■      Red Hat Linux（Fedora or Centos）：

/etc/my.cnf

■      FreeBSD Linux：

/var/db/mysql/my.cnf にファイルを作成する必要があります。

エディタでファイルを開き、[mysqld] セクションを見つけます。次に、次の変更を行います。

■      次の行をコメントアウト：

スキップネットワーキング

この行をコメント アウトすると、TCP/Is 経由のリモート接続が有効になります。

■      MySQL Server アドレス をバインドする構成ファイルで、次の行を追加します。

bind-address=<MySQL_IP_Address>

■      トランザクションメトリックの収集の有効化 設定ファイルで、次の行を追加します。

innodb_monitor_enable = trx_rw_commits, trx_nl_ro_commits, trx_ro_commits, trx_rollbacks

たとえば、MySQL Server にアドレス 123.45.66.77 がある場合、IP アドレスをバインドし、トランザクション メトリックを有効にすると、.conf ファイルのセクションは次のようになります。

mysqld

user                  = mysql

pid-file              = /var/run/mysqld/mysqld.pid

# MySQL バージョン 5.6 以降の場合、次の行のコメントを外します

innodb_monitor_enable = trx_rw_commits, trx_nl_ro_commits, trx_ro_commits, trx_rollbacks

....

完了したら、.conf  ファイルを保存します。

注： 一部の MySQL インストールでは、複数の構成ファイルが使用されます。行った設定で目的の効果が得られない場合は、別の設定ファイルで値が上書きされていないことを確認してください。

2.      応答時間メトリックの収集を有効にします。

次のコマンドを実行して、MySQL Server にログインします。

$mysql -u root -p mysql

次に、次の SQL コマンドを実行します。

UPDATE performance_schema.setup_instruments SET ENABLED = ‘YES' WHERE NAME LIKE ’statement/sql%'; UPDATE performance_schema.setup_instruments SET TIMED = ‘YES' WHERE NAME LIKE ’statement/sql%';

注：

MySQL Server を再起動するたびにこれらの変更を有効にするには、これらのステートメントをファイルに追加し、--init-file  オプションを使用してサーバを起動します。たとえば、ファイル MyInit.txt に名前を付ける場合は、次のオプションで、MySQL Server を起動します。

--init-file=MyInit.txt

3.      Workload Optimization Manager サーバーにデータベースへのリモート アクセスを許可します。

まだ MySQL Server にログインしていない場合は、次のコマンドを実行します。

$mysql -u root -p mysql

次に、次のコマンドを実行します。

ユーザーの名前が  USER_NAME  、パスワードが PWD_STRING であると仮定します。次に、Workload Optimization Manager の IP アドレスが 10.10.123.45 であると仮定します。次のコマンドは、Workload Optimization Manager が指定したユーザーアカウントで接続した場合に、その Workload Optimization Manager に権限を付与します。

GRANT SELECT ON performance_schema.* TO 'USER_NAME'@'10.10.123.45' IDENTIFIED BY 'PWD_STRING'; GRANT PROCESS ON *.* TO 'USER_NAME'@'10.10.123.45' IDENTIFIED BY 'PWD_STRING'; FLUSH PRIVILEGES;

FLUSH PRIVILEGES  コマンドを実行すると、MySQL は再起動時にこれらの設定を保持します。これらの SQL コマンドの実行が終了したら、MySQL からログアウトします。

Oracle

Oracle データベースに接続するには、次の手順を実行します。

■      動的パフォーマンスビューを Oracle データベースに追加する

■      Workload Optimization Manager がログオンに使用できるデータベースのサービスアカウントを設定する

■      データベースのサービス名とポートを検索する

前提条件

■      特定のユーザーアカウントを介してWorkload Optimization Manager へのアクセスを許可するユーザー権限。Oracleでの サービス ユーザーアカウントの作成（33  ページ）を参照してください。

■      動的パフォーマンスビュー（V$）を有効にする必要があります。以下の「動的パフォーマンス ビューの追加」を参照してください。

■      ファイアウォールを介した、Workload Optimization Manager ターゲット接続用に指定した Oracle データベースポートへのアクセス

動的パフォーマンス ビューの追加

Workload Optimization Manager は、Oracle データベースからデータを収集するために動的パフォーマンス ビュー（V$ と呼ばれる）を使用します。VS  はデフォルトでは有効になっていません。V$ を有効にするために必要なテーブルとビューを構築するには、スクリプトを実行する必要があります。一部の環境では、DBA のみがこのスクリプトを実行する権限を持ちます。

V$ を有効にするには、次の手順に従います。

■      システム ユーザーまたは sysdba  ロールを持つユーザーとして、データベース ホストでセキュア シェル セッション（ssh）を開きます。

■      シェルセッションで、次のコマンドを入力します：

sqlplus /nolog connect /as sysdba

CREATE USER My_Username IDENTIFIED BY My_Password container=all; GRANT CONNECT TO My_Username container=all;

GRANT sysdba TO My_Username container=all;

注：

セキュリティまたはその他の慣例により、このユーザーに SYSDBA を割り当てることが禁止されている場合は、次のコマンドを使用してすべての V$ ビューへのアクセスを提供できます。

GRANT select any dictionary TO My_Username;

これにより、My_Username  という名前のユーザーアカウントが作成され、V$ 動的パフォーマンスビューにアクセスするためのフル権限が与えられます。

Workload Optimization Manager への Oracle データベースの追加

個々のデータベース サーバーをターゲットとして追加することも、特定の範囲内で一致するすべてのターゲットを追加することもできます。データベースサーバーをターゲットとして追加するには、次のように指定します。

■      ターゲット名（Target Name）

Workload Optimization Manager ユーザーインターフェイスに表示されるターゲット名。

■      [ユーザー名/パスワード（Username/Password）]

データベース  サーバーの有効なクライアントログイン情報。Workload Optimization Manager がアクションを実行するには、アカウントに管理者権限が必要です。また、Workload Optimization Manager サーバからのリモート アクセスを含む、このユーザー アカウントに対するユーザー権限を有効にする必要があります。

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

注：

範囲内のすべてのデータベースサーバーは、同じサービス名、ログイン情報、およびポートを共有する必要があります。これらのいずれかの値が異なるデータベースについては、それらの値を使用して別のターゲットを作成する必要があります。

■      Oracle Port

データベースに接続するポート。このポートを介したアクセスを許可するには、データベース サーバでファイアウォールを開く必要があります。詳細については、以下の「サービス名とポートの検索」を参照してください。

■      Oracle Service Name

接続するデータベースのサービス名。

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

収集されたメトリックの精度を高めるために、このオプションはデフォルトでオフになっています。

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

サービス名とポートの検索

Oracle ターゲットを指定するには、接続するサービス名とポートを指定する必要があります。データベースのサービス名を見つけるには、次の手順を実行します。

■      システム ユーザーまたは sysdba  ロールを持つユーザーとして、データベース ホストでセキュア シェル セッション（ssh）を開きます。

■      シェル セッションで、コマンド lsnrctl status を入力します。

文字列 PROTOCOL=tcp   を含む行を見つけ、ポート番号をメモします。

■      シェルセッションで、次のコマンドを入力します：

sqlplus /nolog connect /as sysdba

SELECT SYS_CONTEXT('userenv', 'db_name') FROM dual;

 これらのコマンドの結果として表示されるサービス名をメモします。

アクション

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

Oracle でのサービス ユーザーアカウントの作成

Oracle データベースからデータを収集するには、Workload Optimization Manager に、V$   動的パフォーマンスビューにアクセスする権限を持つサービスアカウントが必要です。このアカウントを作成するには、次の手順を実行します。

■      システム ユーザーまたは sysdba  ロールを持つユーザーとして、データベース ホストでセキュア シェル セッション（ssh）を開きます。

■      シェルセッションで、次のコマンドを入力します：

sqlplus /nolog connect /as sysdba

CREATE USER My_Username IDENTIFIED BY My_Password container=all; GRANT CONNECT TO My_Username container=all;

GRANT sysdba TO My_Username container=all;

これにより、My_Username という名前のユーザーアカウントが作成され、V$  動的パフォーマンスビューにアクセスするためのフル権限が与えられます。

注:

上記の例では、架空のユーザー名を使用しています。Oracle 12C の標準に準拠するために、ユーザー名にはプレフィックス c## が含まれるている必要があります。

一部の企業は、sysdba アクセスのあるアカウントを許可していません。Oracle のマニュアルに従って、sysdba を使用することを推奨します。ただし、Oracle DBA スタッフと連携して、Workload Optimization Manager に必要な次のビューへの読み取りアクセスを提供できます。

■      V$INSTANCE

■      V$LOG

■      V$LOGFILE

■      V$PARAMETER

■      V$PGASTAT

■      V$RESOURCE_LIMIT

■      V$SGASTAT

■      V$SYS_TIME_MODEL

■      V$SYSMETRIC

■      V$SYSSTAT

SQL Server

Workload Optimization Manager は、このターゲットの次のバージョンをサポートしています。

Microsoft SQL Server 2012、2014、2016、2017、および 2019

注:

SQL Server クラスタは、このバージョンの Workload Optimization Manager ではサポートされていません。

前提条件

■      ユーザーアカウントにデータベースの Connect SQL  および View Server State  を含む SQL 権限がある

■      次のサービスが実行され、有効に設定されている必要があります：

–      Net.Tcp リスナーアダプタ

–      Net.Tcp ポート共有サービス

■      Workload Optimization Manager の検出に使用されるポートで TCP/IP が有効になっている

■      動的ポート検出を有効にするには、ポートが SQL ブラウザサービスで使用されている

サービス ユーザー アカウントの作成

Workload Optimization Manager がサービス ログインに使用するユーザー アカウントには、次のものが含まれている必要があります。

■      アカウントは、次のプロパティとともに、SQL Server オブジェクトエクスプローラ内のセキュリティフォルダに存在する必要があります。

–      SQL サーバー認証が有効

–      パスワードポリシーの適用が無効

■      アカウントのセキュリティプロパティには、以下が含まれている必要があります。

–      SQL 経由でデータベースに接続する権限

–      サーバーの状態を表示する権限

Workload Optimization Manager への SQL Server データベースの追加

SQL Server ターゲットを追加するには、特定のスコープ内で一致するすべてのデータベースを追加します。データベース サーバをターゲットとして追加するには、次のように指定します。

■      Target Name

Workload Optimization Manager UI に表示される名前

■      ユーザ名

アカウントのユーザー名。このユーザー名に AD ドメインを含めることはできません

■      ADドメイン

Workload Optimization Manager が認証用のユーザー名とともに使用する Active Directory ドメイン。ローカル アカウントの場合は空白のままにします。

■      パスワード

アカウントのパスワード。このユーザー名に AD ドメインを含めることはできません

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      ブラウジングサービスポート

ブラウジング サービスとの通信に使用されるポート。Workload Optimization Manager は、スコープ内の各 VM で実行されている各インスタンスの SQLServer ポートを取得します。

■      SQLServer ポート

SQL リモート ポート。参照サービス ポートが指定されていない場合、または検出中に参照サービスが使用できない場合、Workload Optimization Manager はこのポートを使用します。

注:

Workload Optimization Manager は、最初に SQL ブラウジング サービスに指定されたポートに接続します。接続に失敗すると、Workload Optimization Manager は、SQLServer ポートを使用して接続します。

■      [Collect Virtual Machine Metrics]

このターゲットから仮想マシンのメトリックを収集するかどうかを指定します。[仮想マシンのメトリックの収集（Collect Virtual Machine Metrics）] がオンになっている場合、Workload Optimization Manager は、このターゲットから収集する仮想マシン（VM）のメトリックを使用し、関連するインフラストラクチャ ターゲットから任意に収集できる仮想マシン データは使用しません。

収集されたメトリックの精度を高めるために、このオプションはデフォルトでオフになっています。

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

アクション

Workload Optimization Manager は、次のようにアプリケーション サプライ チェーンのアクションを推奨します。

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

JBoss

Workload Optimization Manager は、次の操作モードで実行されている JBoss ターゲットへの接続をサポートしています。

■      管理対象ドメイン

単一のドメイン コントローラ プロセスが中央管理コントロール ポイントとして機能する、ドメイン内の一連の JBoss サーバー。この場合、ドメイン コントローラをホストするVMがターゲットになります。ドメインコントローラは、 JBossマシン上の host.xml  ファイルの domain-controller エントリを使用して設定します。

■      スタンドアロン

単一の JBoss サーバー。サーバーをホストする VM がターゲットです。

前提条件

■      ターゲット VM が、操作モードに応じて、ドメインコントローラまたはスタンドアロンとして適切に設定されていること。

■      Workload Optimization Manager が、VM または VM で展開されているコンテナで実行されている JBoss サーバーを検出すること。JBoss サーバーのターゲットを設定するには、最初にハイパーバイザターゲットを介してホスト VM を検出する必要があります。

ハイパーバイザターゲットの詳細については、「ハイパーバイザターゲット」（84 ページ ）を参照してください。

■      Workload Optimization Manager は、アプリケーション サーバーのスレッド リソースをモニタリングして、スレッド プール  キャパシティの使用率を追跡します。JBoss でスレッドをモニタリングするには、各 JBoss サーバーがその設定ファイルでスレッド プールを定義する必要があります。スレッドプールを指定する手順については、JBoss のドキュメントを参照してください。

■      JBoss が、ユーザーアカウントの一連のアクセス許可を指定する方法として、ロールベース アクセス コントロール（RBAC）をサポートすること。

JBoss はデフォルトで RBAC を無効にします。RBAC を有効にすると、Workload Optimization Manager は、JBoss サーバーを検出するために、ターゲット JBoss アカウントのモニター ロールが必要です。

JBoss ターゲットの追加

個々の JBoss サーバーをターゲットとして追加することも、特定の範囲内で一致するすべてのターゲットを追加することもできます。サーバをターゲットとして追加するには、次のように指定します。

■      Target Name

Workload Optimization Manager のユーザーインターフェイスに表示される名前

■      ユーザ名

必要な権限のあるロールを持つ JBoss アカウントのユーザー名。

■      パスワード

使用する JBoss アカウントのパスワード。

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合される JBoss サーバーのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングに遅延が発生する可能性があります。多数の VM をターゲットに設定する場合は、それらを複数のターゲットの小さなグループに分割することをお勧めします。

■      [JBoss Webservice port]

JBoss サーバーへの接続用のポート。HTTP アクセスのデフォルトポートは 9990 です。

■      [Full Validation]

オンにすると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべての JBoss サーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内の JBoss サーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

■      [Secure Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由で JBoss サーバーに接続します。必要な証明書がホストで使用できるように設定されていることを確認します。

■      [Proxy Information]

プロキシ経由で JBoss インスタンスに接続する場合にのみ、プロキシ情報を指定します。

–      Proxy Host

このターゲットが使用するプロキシのアドレス。プロキシ経由で AppDynamics インスタンスに接続する場合にのみ、プロキシ情報を入力します。

–      Proxy Port

上記で指定したプロキシで使用するポート。デフォルトでは 8080 です。

–      [Proxy Username]

上記で指定したプロキシで使用するユーザー名。

–      [Proxy Password]

上記で指定したプロキシで使用するパスワード。

–      [Secure Proxy Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由でプロキシに接続します。

[Application Component Names]

Workload Optimization Manager は、検出された JBoss サーバーをユーザー インターフェイスに表示します。これらの名前は、スタンドアロンか管理対象ドメインかを示します。

名前は 3 つのセクションに分かれています。

■      ドメインコントローラ名または「STANDALONE」

■      サーバー名

■      JBoss サーバーをホストする VM の名前または IP アドレス たとえば、以下です。

STANDALONE:acm-jboss73 [ACM-JBoss7.3-171.47]

アクション

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

Apache Tomcat

Workload Optimization Manager は、個々の Tomcat ターゲットへの接続をサポートしています。Workload Optimization Manager は、リモート JMX アクセスを介してリモート クライアントとして Tomcat プロセスに接続します。ターゲット設定には、JMX/RMI レジストリで使用されるポートが含まれます。

前提条件

■      Tomcat サーバーの有効な JMX ユーザーアカウント。

Tomcat セキュリティが有効な場合、これは readonly  ロールを持つ Tomcat JMX ユーザーである必要があります。

■      Tomcat は JVM バージョン 7 または 8 で実行する必要があります。

■      VMware 環境の場合、Tomcat サーバーをホストする VM に VMware ツールをインストールする必要があります。Hyper-V 環境では、Hyper-V 統合サービスをインストールする必要があります。

これにより、Tomcat サーバーをホストする VM が IP アドレスを取得できるようになります。

■      リモート JMX アクセスが、ファイアウォールに対して開かれたポートを介して有効であること。

■      検出されたインフラストラクチャ。

Workload Optimization Manager は、VM またはコンテナで実行されている Tomcat サーバを検出します。ホスティング VM またはコンテナは、Workload Optimization Manager のインベントリにすでに存在している必要があります。

VM で実行されているサーバーのターゲットを設定するには、最初にハイパーバイザ ターゲットを介してホスト VM を検出する必要があります。コンテナで実行されているサーバーのターゲットを設定するには、Tomcat アプリケーションのコンテナ検出を設定しておく必要があります。

–      コンテナ ターゲットの詳細については、Kubernetes プラットフォーム ターゲット（53  ページ）を参照してください

–      ハイパーバイザ ターゲットの詳細については、「ハイパーバイザ ターゲット」（84  ページ）を参照してください。

JMX リモート アクセスの設定

Workload Optimization Manager は、JMX リモート アクセスを介して Tomcat サーバーをモニタリングおよび制御します。JMX リモート ポートを設定する必要があります。

ファイアウォールを使用するには、RMI サーバ ポートも設定する必要があります。RMI ポートを設定しない場合、JMX は任意のエフェメラル ポートを設定しますので、このポートがファイアウォールに対して開いていることは保証できません。

Linux プラットフォームで JMX リモート ポートを設定するには、次の 2 つの方法があります。

■      ポートをシステムプロパティとして指定する

システムプロパティ、com.sun.management.jmxremote.port を使用してポートを設定できます。次に例を示します。

com.sun.management.jmxremote.port=8050

このプロパティを設定する一般的な方法は、CATALINA_OPTS   システム変数で宣言することです。これは

setenv.sh  スクリプトで設定できます。次に例を示します。

CATALINA_OPTS="$CATALINA_OPTS

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.port=8050" export CATALINA_OPTS

これによりJMX リモート ポートが設定されますが、RMIサーバー ポートは設定されません。Tomcat の起動では、RMIサーバーのエフェメラルポートが指定されます。

■      ポートを JMX リモート ライフサイクル リスナーで指定する

このリスナー コンポーネントは、JMX / RMI サーバーで使用されるポートを修正します。リスナーを設定するときは、JMX リモート ポートとRMIサーバー ポートの両方を指定します。これは、ファイアウォールを使用する場合に推奨される方法です。詳細については、Apache Tomcat のマニュアルを参照してください。

Windows の場合、Tomcat をサービスとしてインストールするのが一般的です。JMX リモート ポートを設定するには、次の 2 つの方法があります。

■      setenv.bat 経由

CATALINA_OPTS  環境変数にプロパティを追加します。

set "CATALINA_OPTS=%CATALINA_OPTS% -Dcom.sun.management.jmxremote.port=8050"

■      Tomcat 設定ユーティリティ（tomcat7w または tomcat8w）を使用する 次のコマンドを使用してポートを設定します。

-Dcom.sun.management.jmxremote.port=8050"

すでに実行中の Tomcat に設定されている JMX ポートを検出するには、次の場所を確認します。

■      Linux プラットフォームの場合は、設定ファイルを確認します。

–      setenv.sh ：ポートを CATALINA_OPTS  環境変数に追加して設定した場合

–      $CATALINA_HOME/conf/server.xml ：このファイルで JMX リモート ライフサイクル リスナーを設定した場合

■      Windows プラットフォームの場合、次の場所を確認します。

–      setenv.bat ：ポートを CATALINA_OPTS  環境変数に追加して設定した場合

–      Windowsレジストリ：Tomcat 設定ユーティリティを使用して Tomcat  を Windows サービスとしてインストールした場合

Tomcat ターゲットの追加

個々の Tomcat サーバーをターゲットとして追加することも、特定の範囲内で一致するすべてのサーバーを追加することもできます。サーバをターゲットとして追加するには、次のように指定します。

■      Target Name

Workload Optimization Manager UI に表示される名前

■      ユーザ名

管理者ロールを持つアカウントのユーザー名

■      パスワード

管理者ロールを持つアカウントのパスワード

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      JMX リモートポート

すでに実行中の Tomcat プロセスに設定されている JMX ポート。

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

■      Proxy Host

このターゲットが使用するプロキシのアドレス。プロキシ経由で AppDynamics インスタンスに接続する場合にのみ、プロキシ情報を入力します。

■      Proxy Port

上記で指定したプロキシで使用するポート。デフォルトでは 8080 です。

■      [Proxy Username]

上記で指定したプロキシで使用するユーザー名。

■      [Proxy Password]

上記で指定したプロキシで使用するパスワード。

■      [Secure Proxy Connection]

オンにすると、Workload Optimization Manager は HTTPS 経由でプロキシに接続します。

アクション

Workload Optimization Manager は、次のようにアプリケーション サプライ チェーンのアクションを推奨します。

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

 JVM アプリケーション

Workload Optimization Manager は、ターゲットとしての個々の JVM アプリケーションへの接続をサポートします。Workload Optimization Manager は、リモート JMX アクセスを介してリモートクライアントとして JVM プロセスに接続します。ターゲット設定には、JMX/RMI レジストリで使用されるポートが含まれます。

前提条件

■      JVM アプリケーションの有効な JMX ユーザーアカウント

JMX セキュリティが有効になっている場合は、readonly  ロールを持つ JMX ユーザーである必要があります。

■      アプリケーションは、JVM バージョン 6.0 以降で実行する必要があります。

■      VMware 環境の場合、アプリケーションをホストする VM に VMware Tools をインストールする必要があります。これにより、アプリケーションをホストする VM がアプリケーションの IP アドレスを取得できるようになります。

■      リモート JMX アクセスが、ファイアウォールに対して開かれたポートを介して有効であること。

■      検出されたインフラストラクチャ。

Workload Optimization Manager は、VM またはコンテナで実行されている JVM アプリケーションを検出します。ホスティング VM またはコンテナは、Workload Optimization Manager のインベントリにすでに存在している必要があります。

VM で実行されているサーバーのターゲットを設定するには、最初にハイパーバイザ ターゲットを介してホスト VM を検出する必要があります。コンテナで実行されているサーバーのターゲットを設定するには、JVM アプリケーションのコンテナ検出を設定しておく必要があります。

–      コンテナ ターゲットの詳細については、Kubernetes プラットフォーム ターゲット（53  ページ）を参照してください

–      ハイパーバイザ ターゲットの詳細については、「ハイパーバイザ ターゲット」（84  ページ）を参照してください。

JMX リモート アクセスの設定

Workload Optimization Manager は、JMX リモートアクセスを介して JVM アプリケーションをモニタおよび制御します。JMX リモート ポートを設定する必要があります。

ファイアウォールを使用するには、RMI サーバ ポートも設定する必要があります。RMI ポートを設定しない場合、JMX は任意のエフェメラル ポートを設定しますので、このポートがファイアウォールに対して開いていることは保証できません。

JMX リモート ポートを設定するには、アプリケーションの起動時にコマンドラインでポートを渡します。たとえば、ポートを 8090 に設定するには、次のオプションを使用してアプリケーションを起動します。

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8090

JVM アプリケーションターゲットの追加

JVM ターゲットを設定するときは、特定のスコープを宣言し、その特定のスコープ内に一致するすべてのアプリケーションを追加します。これを行うには、次のように指定します。

■      [Scope（適用範囲）]：

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      [Port Number]：JMX リモートポート

■      [Username/Password]：管理者ロールを持つユーザーアカウントのログイン情報

指定するログイン情報は、アプリケーションの起動時に JMX ログイン設定に指定するログイン情報と一致する必要があります。

アプリケーションで認証を無効にしても、[Username] と [Password] には任意の値を指定する必要があります。JMX 認証を無効にするには、アプリケーションの起動時にコマンド ラインで次のフラグを使用します。

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

単一 VM 上の複数の JVM ターゲット

異なるポートを持つターゲットを指定できますが、それらは同じ VM 上で実行されます（同じ IP アドレスを使用）。同じ範囲で異なるポートを使用してターゲットを指定することもできますーこれは、同じ VM で実行されているアプリケーションを異なるポートに割り当てるためのもう一つの方法です。手順は、次のとおりです。

これを行うには、2 つの個別の手順でターゲットを追加します。たとえば、2 つの JVM アプリケーション ターゲットを追加し、両方とも 10.10.123.45 の VM で実行するとします。1 つのアプリケーションはポート 123 上にあり、もう 1 つのアプリケーションはポート 456 上にあります。2 つのターゲットを指定するには:

■      次のパラメータを使用して最初のターゲットを指定します。

–      スコープ：VMs_myCluster.mycorp.com

–      ポート番号：123

–      ユーザー名：AppUser

–      パスワード：**********

次に、[追加（Add）] をクリックします。

■      次のパラメータを使用して 2 番目のターゲットを指定します。

–      スコープ：VMs_myCluster.mycorp.com

–      ポート番号：456

–      ユーザー名：OtherAppUser

–      パスワード：**********

次に、[追加（Add）] をクリックします。

アクション

Workload Optimization Manager は、次のようにアプリケーション サプライ チェーンのアクションを推奨します。

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

Oracle WebLogic

一般的な WebLogic 展開は、ドメインの管理のために単一のエントリ ポイントを提供する1つの管理サーバーを備えた管理対象ドメインです。ドメインには、管理対象サーバの他の WebLogic サーバを含めることができます。WebLogic Administration ServerをWorkload Optimization Manager のターゲットとして設定します。

スタンドアロンの WebLogic 展開では、単一のサーバが独自の管理サーバとして機能しますースタンドアロンサーバを Workload Optimization Manager のターゲットとして設定できます。

WebLogic 展開には、複数の WebLogic サーバーにワークロードを分散するクラスタを含めることができます。マネージャが推奨するアクションは、クラスタ アーキテクチャを尊重します。たとえば、WebLogic サーバーの水平拡張を有効にしている場合、Workload Optimization Managerは、特定のクラスタに新しいサーバーをプロビジョニングすることを推奨できます。

前提条件

■      サービスユーザーアカウント。

アクションを実行するには、サービス アカウントに管理者ロールが必要です。読み取り専用のモニタリングと分析の場合は、ターゲットをより制限されたロールに設定できますが、推奨されるすべてのアクションを WebLogic インターフェイス経由で手動で実行する必要があります。

■      WebLogic では、接続のローカルエンドとリモートエンドの両方が DNS によって解決可能である必要があります。Workload Optimization Manager の IP アドレスとすべての WebLogic サーバーの IP アドレスは、ローカル DNS サーバーで解決できる必要があります。

■      検出されたインフラストラクチャ。

Workload Optimization Manager は、VM またはコンテナで実行されている WebLogic サーバーを検出します。ホスティング VM またはコンテナは、Workload Optimization Manager のインベントリにすでに存在している必要があります。

VM で実行されているサーバーのターゲットを設定するには、最初にハイパーバイザ ターゲットを介してホスト VM を検出する必要があります。コンテナで実行されているサーバのターゲットを設定するには、WebLogic アプリケーションのコンテナ検出を設定しておく必要があります。

–      コンテナ ターゲットの詳細については、Kubernetes プラットフォーム ターゲット（53  ページ）を参照してください

–      ハイパーバイザターゲットの詳細については、「ハイパーバイザターゲット」（84  ページ）を参照してください。

T3 リッスン ポートの検索

WebLogic ターゲットを設定するには、サーバーが管理通信をリッスンするポートを知っている必要があります。WebLogic Administration Console を起動します。

■      [Domain Structure] に移動し、対象のドメインを表示します。

■      [環境（Environment）] > [サーバー（Servers）] に移動し、ターゲットとして設定しているドメイン管理サーバを選択します。コンソールには、T3 リスニング ポートを含むサーバーの構成情報が表示されます。

WebLogic ターゲットの追加

スタンドアロン サーバーとドメイン マネージャの両方を含む、1 つ以上の WebLogic ターゲットを特定の範囲に追加できます。このターゲットを追加するには、次を指定します。

■      Target Name

Workload Optimization Manager UI に表示される名前

■      ユーザ名

管理者ロールを持つアカウントのユーザー名

■      パスワード

管理者ロールを持つアカウントのパスワード

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      Port Number

WebLogic リモート ポート

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

アクション

Workload Optimization Manager は、次のようにアプリケーション サーバー サプライ チェーンのアクションを推奨します。

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

IBM WebSphere

一般的な Web サービスは、Deployment Manager によって制御される、Web サーバーのセルです。セルは、管理対象アプリケーション サーバをホストする複数の VMS を組み込む管理対象ドメインを構成します。Deployment Manager は、管理対象ドメインに単一のエントリ ポイントを提供する、1つの WebSphere インスタンスです。

注:

ターゲットとして、IBM Deployment Manager を追加する場合は、各 Web ノードの名前が、Workload Optimization Manager インスタンスによって IP アドレスに解決可能であることを確認する必要があります。

DNS または Workload Optimization Manager インスタンスのファイル /etc/resolv.conf  を変更して、環境で使用するドメイン名を認識させることが必要な場合があります。

WebSphere インストールを構成するには、WebSphere Integrated Solutions Console を使用できます。これは、SOAP ポートや PMI 設定などの構成設定を公開するクライアントです。

インストール内のサーバを管理するために、IBM は Performance Monitoring Infrastructure（PMI）を使用します。各 WebSphere は、さまざまなアプリケーション サーバ コンポーネントからパフォーマンス データを収集する PMI サービスを実行します。Workload Optimization Manager は、PMIを使用して、インストールされている WebSphere のモニタリングと制御を行います。

前提条件

■      基本レベル以上でモニタリングするように設定された PMI サービス

■      サービスユーザーアカウント

アクションを実行するには、サービス アカウントに管理者ロールが必要です。読み取り専用のモニタリングおよび分析の場合は、ターゲットをより制限されたロール（モニタ）に設定できますが、その場合は、推奨されるすべてのアクションを手動で実行する必要があります。

■      検出されたインフラストラクチャ。

Workload Optimization Manager は、VM またはコンテナで実行されている WebSphere サーバーを検出します。ホスティング VM またはコンテナは、Workload Optimization Manager のインベントリにすでに存在している必要があります。

VM で実行されているサーバーのターゲットを設定するには、最初にハイパーバイザ ターゲットを介してホスト VM を検出する必要があります。コンテナで実行されているサーバのターゲットを設定するには、WebSphere アプリケーションのコンテナ検出を設定しておく必要があります。

–      ハイパーバイザ ターゲットの詳細については、「Kubernetes プラットフォーム ターゲット」（53  ページ）を参照してください。

–      コンテナターゲットの詳細については、「ハイパーバイザターゲット」（84  ページ）を参照してください。

SOAP コネクタ アドレスの検索

WebSphere ターゲットを設定するには、サーバーが管理通信をリッスンするポートを知っている必要があります。次のようにして、WebSphere 管理コンソールを起動します。

■      [System Administration] > [Deployment Manager] に移動します。

■      [追加プロパティ（Additional Properties）] で、[ポート（Ports）] をクリックします。

SOAP_CONNECTOR_ADDRESS  のエントリは、現在設定されているポート番号を示します。

WebSphere ターゲットの追加

個々の WebLogic サーバーをターゲットとして追加することも、特定の範囲内で一致するすべてのターゲットを追加することもできます。サーバをターゲットとして追加するには、次のように指定します。

■      Target Name

Workload Optimization Manager UI に表示される名前

■      ユーザ名

管理者ロールを持つアカウントのユーザー名

■      パスワード

管理者ロールを持つアカウントのパスワード

■      スコープ

VM が個別の Workload Optimization Manager ターゲットの一部として検出されたときに、基礎となる VM に結合されるアプリケーションのグループ。

ターゲット範囲を設定すると、Workload Optimization Manager はそのグループまたはクラスタ内の各 VM をスキャンし、指定されたポートを介してターゲットへの接続を試みます。Workload Optimization Manager は、見つかったターゲットのインスタンスを、メトリックが取得されるエンティティとして追加します。

サポートされるグループの最大サイズは 500 VM で、推奨サイズは 250 VM です。それ以上の VM をグループに追加すると、検出とモニタリングのパフォーマンスが低下する可能性があります。スコープごとに多数の VM をターゲットに設定するには、それらを小さなグループに分割し、各グループを個別のターゲットのスコープとして設定する必要があります。

■      Port Number

WebSphere のリモート ポート

■      [Full Validation]

選択すると、Workload Optimization Manager は、選択した範囲内の VM でホストされているすべてのデータベースサーバーを有効なターゲットにする必要があります。Workload Optimization Manager が範囲内のデータベースサーバーを認証できない場合、ターゲットは検証されず、データは収集されません。

アクション

Workload Optimization Manager は、次のようにアプリケーション サーバー サプライ チェーンのアクションを推奨します。

モニタ対象リソース

Workload Optimization Manager は、アプリケーション サーバー サプライ チェーンの次のリソースをモニタリングします。

Instana

Workload Optimization Manager は、Instana プラットフォームによって管理されるアプリケーションの検出をサポートします。Workload Optimization Manager は、環境の正常性の計算に、これらのアプリケーションについて検出された情報を含めます。

注：

Kubernetes 環境の場合、Workload Optimization Manager は、NewRelic、AppDynamics、Instana、および Dynatrace のコンテナー化されたアプリケーション コンポーネントをサプライチェーンに結合して、アプリケーションの統一されたビューを提供します。詳細については、「クラウド ネイティブ ターゲット」（53  ページ）を参照してください。

前提条件

■      Instana、リリース 209 以降

■      自己ホスト型インスタンスまたは SaaS Instana インスタンス

このインスタンスは、環境で実行中のアプリケーションをモニタリングするように設定する必要があります。

■      Instana によって管理されるアプリケーションを実行している仮想マシンおよび/またはコンテナ。

Workload Optimization Manager が Instana を介してアプリケーションを検出するには、アプリケーションが環境内にある仮想マシンまたは Kubernetes コンテナで実行されている必要があります。また、これらのエンティティは、Workload Optimization Manager ハイパーバイザ、パブリッククラウド、または Kubernetes ターゲットで管理する必要があります。

■      有効な Instana API トークン。

これは、デフォルトの権限で作成された API トークンである必要があります。

エンティティ マッピング

新しいターゲットを検証した後、Workload Optimization Manager は接続されたエンティティを検出し、サプライチェーンに追加します。次の表は、Instana の用語を、Workload Optimization Manager がサプライチェーンで作成するエンティティのタイプにマッピングしたものです。