Operations Manager エージェント

重要

このバージョンの Operations Manager はサポート終了に達しました。 Operations Manager 2022 にアップグレードすることをお勧めします。

System Center Operations Manager では、エージェントは、構成データを検索し、分析とレポートのための情報を事前に収集し、SQL データベースや論理ディスクなどの監視対象オブジェクトの正常性状態を測定し、オペレーターまたは条件に応じてタスクをオンデマンドで実行する、コンピューターにインストールされるサービスです。 これにより、Operations Manager は、Windows、Linux、UNIX オペレーティング システム、および Web サイトや Active Directory ドメイン コントローラーなどの IT サービスのコンポーネントを監視できます。

Windows エージェント

監視対象の Windows コンピューター上で、Operations Manager エージェントは、Microsoft Monitoring Agent (MMA) サービスとしてリストされます。 Microsoft Monitoring Agent サービスはイベントおよびパフォーマンス データを収集し、タスクと、管理パックで定義されている他のワークフローを実行します。 このサービスは、報告先の管理サーバーと通信できなくなった場合でも稼働を続け、収集したデータやイベントを監視対象コンピューターのディスクに待機させておき、 接続が復旧し次第、それらのデータやイベントを管理サーバーに送信します。

Note

  • Microsoft Monitoring Agent サービスは、「ヘルス サービス」と呼ばれることがあります。

Microsoft Monitoring Agent サービスは、管理サーバー上でも実行されます。 管理サーバー上で、このサービスは、監視ワークフローを実行し、資格情報を管理します。 ワークフローを実行するために、このサービスでは、指定された資格情報を使用して MonitoringHost.exe プロセスを開始します。 これらのプロセスでは、イベント ログ データ、パフォーマンス カウンター データ、Windows Management Instrumentation (WMI) データを監視および収集し、スクリプトなどのアクションを実行します。

エージェントと管理サーバー間の通信

Operations Manager エージェントは、アラートと検出データを割り当てられているプライマリ管理サーバーに送信し、プライマリ管理サーバーは、そのデータをオペレーション データベースに書き込みます。 また、エージェントのイベント、パフォーマンス、状態に関するデータもエージェントからプライマリ管理サーバーに送信され、プライマリ管理サーバーがそれらのデータをオペレーション データベースとデータ ウェアハウス データベースに同時に書き込みます。

エージェントは、各ルールとモニターのスケジュール パラメーターに従ってデータを送信します。 最適化された収集ルールでは、カウンターのサンプルと前のサンプルとの差が、指定された許容範囲 (10% など) に達した場合にのみ、データが転送されます。 これにより、ネットワーク トラフィック、およびオペレーション データベースに保存されるデータの量を削減できます。

また、すべてのエージェントは、 ハートビートと呼ばれるデータのパケットを管理サーバーに送信します。既定では、60 秒置きに送信します。 このハートビートは、エージェントの可用性、およびエージェントと管理サーバー間の通信をチェックするためのものです。 ハートビートの詳細については、「 Operations Manager のハートビートのしくみ」を参照してください。

Operations Manager は、リモート ヘルス サービスの状態を監視サーバーの視点から監視する ヘルス サービス ウォッチャーをエージェントごとに実行します。 エージェントは、TCP ポート 5723 経由で管理サーバーと通信します。

エージェントから管理サーバーへの通信の図。

Linux/UNIX エージェント

UNIX および Linux エージェントのアーキテクチャは、Windows エージェントのものと大幅に異なります。 Windows エージェントには、監視対象コンピューターの正常性の評価を担当するヘルス サービスがあります。 UNIX および Linux エージェントは正常性サービスを実行しません。代わりに、評価する管理サーバー上のヘルス サービスに情報を渡します。 管理サーバーではすべてのワークフローを実行し、UNIX および Linux 管理パックの実装で定義されているオペレーティング システムの正常性を監視します。

  • ディスク
  • プロセッサ
  • メモリ
  • ネットワーク アダプター
  • オペレーティング システム
  • 処理
  • ログ ファイル

Operations Manager の UNIX および Linux エージェントは、CIM オブジェクト マネージャー (つまり、CIM サーバー) と、一連の CIM プロバイダーで構成されます。 CIM オブジェクト マネージャーは、プロバイダーへの要求の WS-Management 通信、認証、承認、ディスパッチを実装する サーバー コンポーネントです。 CIM クラスとプロパティを定義し、カーネル API と連動して生データを取得し、データの書式設定を行い (差分と平均を計算するなど)、CIM オブジェクト マネージャーからディスパッチされた要求を処理するために、エージェントでの CIM 実装ではプロバイダーが重要になります。 System Center Operations Manager 2007 R2 から System Center 2012 SP1 まで、Operations Manager の UNIX および Linux エージェントで使用されていた CIM オブジェクト マネージャーは OpenPegasus サーバーです。 監視データの収集とレポートのために使用されるプロバイダーは Microsoft で開発され、CodePlex.com でオープンソース化されます。

Operations Manager UNIX/Linux エージェントのソフトウェア アーキテクチャの図。

これは、System Center 2012 R2 Operations Manager で変更され、現在、UNIX および Linux エージェントは、CIM オブジェクト マネージャーとして Open Management Infrastructure (OMI) の完全に一貫した実装に基づいています。 Operations Manager の UNIX/Linux エージェントの場合、OpenPegasus は OMI に置き換えられます。 OpenPegasus と同様に、OMI はオープンソースで軽量でポータブルな CIM オブジェクト マネージャー実装ですが、軽量で、OpenPegasus よりも軽量でポータブルです。 この実装は引き続き、System Center 2016 - Operations Manager 以降で適用されます。

Operations Manager UNIX/Linux エージェントの更新されたソフトウェア アーキテクチャの図。

管理サーバーと UNIX および Linux エージェント間の通信は、エージェントのメンテナンスと正常性の監視という 2 つのカテゴリに分かれています。 管理サーバーは以下の 2 つのプロトコルを使用して UNIX または Linux コンピューターと通信します。

  • Secure Shell (SSH) と Secure Shell ファイル転送プロトコル (SFTP)

    エージェントのインストール、アップグレード、削除などのエージェントのメンテナンス タスクに使用されます。

  • Web Services for Management (WS-Management)

    すべての監視操作に使用され、インストール済みのエージェントの検出も含みます。

Operations Manager 管理サーバーと UNIX および Linux エージェント間の通信では、WS-Man over HTTPS と WinRM インターフェイスを使用します。 すべてのエージェントのメンテナンス タスクは、ポート 22 で SSH 経由で実行されます。 すべての正常性の監視はポート 1270 で WS-MAN 経由で実行されます。 管理サーバーは、データを評価して正常性の状態を示す前に、WS-MAN 経由でパフォーマンスと構成データを要求します。 エージェント メンテナンス、モニター、ルール、タスク、および復元などのすべての操作は、特権のないアカウントまたは特権付きアカウントに対する要件に従って定義済みのプロファイルを使用するように構成されます。

Note

この記事で言及するすべての資格情報は、Operations Manager のインストール中に構成された Operations Manager アカウントではなく、UNIX または Linux コンピューター上で設定されたアカウントに関連しています。 資格情報および認証情報についてはシステム管理者に問い合わせてください。

System Center 2016 - Operations Manager 以降で管理サーバーごとに監視可能な UNIX および Linux システムの数を拡張する新たな機能改善をサポートするため、既定で使用される WSMAN Sync API の代わりに新しい Async Windows Management Infrastructure (MI) API を利用できます。 この変更を有効にするには、新しいレジストリ キー UseMIAPI を作成し、Linux/Unix システムを監視する管理サーバーで新しい Async MI API を使用するように Operations Manager を有効にする必要があります。

  1. 管理者特権のコマンド プロンプトからレジストリ エディターを開きます。
  2. の下にレジストリ キー UseMIAPI を作成します。

WSMAN Sync API を使用する元の構成を復元する必要がある場合は、この UseMIAPI レジストリ キーを削除します。

エージェント セキュリティ

UNIX/Linux コンピューターでの認証

Operations Manager では、システム管理者が UNIX または Linux コンピューターのルート パスワードを管理サーバーに入力する必要がなくなりました。 昇格によって、特権のないアカウントが、UNIX または Linux コンピューターの特権のあるアカウントの ID を使用できます。 昇格プロセスは、管理サーバーが提供する資格情報を使用する UNIX su (スーパー ユーザー) および sudo プログラムにより実行されます。 SSH を使用する特権のあるエージェントのメンテナンス操作 (検出、展開、アップグレード、アンインストール、およびエージェントの復元など) については、su のサポート、sudo による昇格、および SSH キー認証 (パス フレーズあり、またはパスフレーズなし) のサポートが提供されます。 特権のある WS-Management 操作 (セキュア ログ ファイルの表示など) については、sudo による昇格 (パスワードなし) のサポートが追加されます。

資格情報の指定およびアカウントの構成方法の詳細については、「Unix および Linux コンピューターにアクセスするための資格情報を設定する方法」を参照してください。

ゲートウェイ サーバーでの認証

ゲートウェイ サーバーを使用して、管理グループの Kerberos 信頼境界の外部にあるコンピューターのエージェント管理を実現します。 ゲートウェイ サーバーは、管理グループが存在するドメインによって信頼されていないドメインに存在するため、証明書を使用して各コンピューターの ID、エージェント、ゲートウェイ サーバー、および管理サーバーを確立する必要があります。 これは、Operations Manager の相互認証に必要です。

これには、ゲートウェイ サーバーにレポートを行う各エージェントの証明書を要求してから、MOMCertImport.exe ツールを使用してその証明書をターゲット コンピューターにインポートする必要があります。ツールは、インストール メディアの SupportTools\ (amd64 または x86) ディレクトリに格納されています。 VeriSign などのパブリック CA である証明機関 (CA) にアクセスできる必要があります。また、Microsoft Certificate Services を使用することもできます。

エージェントの展開

System Center Operations Manager Agents は、次の 3 つの方法のいずれかを使用してインポートできます。 多くの場合は、これらのメソッドを必要に応じて組み合わせて使用し、さまざまなコンピューターをインストールします。

Note

  • MMA は、組み込みのバージョンの MMA が既にインストールされているため、Operations Manager 管理サーバー、ゲートウェイ サーバー、オペレーション コンソール、オペレーション データベース、Web コンソール、System Center Essentials、またはSystem Center Service Managerがインストールされているコンピューターに MMA をインストールすることはできません。
  • 使用できるのは、MMA または Log Analytics エージェント (VM 拡張機能バージョン) だけです。
  • オペレーション コンソールからの 1 つまたは複数のエージェントの検出とインストール。 これが最も一般的なインストール形式です。 管理サーバーは RPC を使用してコンピューターを接続できる必要があり、管理サーバーのアクション アカウントまたは他の指定された資格情報にターゲット コンピューターへの管理アクセス権がある必要があります。
  • インストール イメージへの組み込み。 これは、他のコンピューターの準備に使用される基本イメージへの手動インストールです。 この場合、Active Directory 統合を使用して、初期スタートアップ時に管理サーバーにコンピューターを自動的に割り当てることができます。
  • 手動インストール。 このメソッドは、ファイアウォールのためにリモート プロシージャ コール (RPC) が使用できない場合など、他のいずれかの方法でエージェントをインストールできない場合に使用されます。 セットアップをエージェントで手動で実行するか、または既存のソフトウェア配布ツールを使用して展開します。

検出ウィザードを使用してインストールされたエージェントは、エージェントのバージョンの更新、パッチの適用、エージェントが報告する管理サーバーの構成など、オペレーション コンソールから管理できます。

エージェントを手動でインストールした場合は、エージェントの更新も手動で行う必要があります。 Active Directory 統合を使用して、管理グループにエージェントを割り当てることができます。 詳細については、「Active Directory と Operations Manager の統合」を参照してください。

Windows および UNIX および LINUX システムへのエージェントのデプロイの詳細を確認するには、必要なタブを選択します。

Windows システムを検出するには、TCP 135 (RPC)、RPC 範囲、および TCP 445 (SMB) ポートが開いた状態で、SMB サービスがエージェント コンピューターで有効になっている必要があります。

  • ターゲット デバイスを検出したら、それに対してエージェントを展開できます。 エージェント インストールで必要な操作は次のとおりです。
  • エンドポイント マッパー TCP 135 およびサーバー メッセージ ブロック (SMB) ポート TCP/UDP 445 以降の、RPC ポートを開く。
  • Microsoft ネットワーク用ファイルとプリンター共有および Microsoft ネットワーク用クライアント サービスを有効にする (これで、SMB ポートがアクティブになります)。
  • 有効になっている場合、Windows ファイアウォール グループ ポリシー設定で、[リモート管理の例外を許可する] および [ファイルとプリンターの共有の例外を許可する] の [要請されない着信メッセージを許可するアドレス] をエージェントのプライマリおよびセカンダリ管理サーバーの IP アドレスとサブネットに設定する必要があります。
  • ターゲット コンピューターでローカル管理者の権限があるアカウント。
  • Windows Installer 3.1。 インストール方法については、Microsoft サポート技術情報の記事 893803 https://go.microsoft.com/fwlink/?LinkId=86322 を参照してください
  • \msxml サブディレクトリにある Operations Manager 製品のインストール メディアの Microsoft Core XML Services (MSXML) 6。 プッシュ エージェントのインストールでは、ターゲット デバイスに MSXML 6 がまだインストールされていない場合にインストールされます。

Active Directory エージェントの割り当て

System Center Operations Manager では、エージェントで管理されたコンピューターを管理グループに割り当てるために使用できるようにすることで、Active Directory Domain Services (AD DS) を利用できます。 この機能は、サーバー展開ビルド プロセスの一部としてデプロイされるエージェントでよく使用されます。 コンピューターが初めてオンラインになったときに、Operations Manager エージェントはそのプライマリおよびフェールオーバー管理サーバーの割り当てを Active Directory に照会し、コンピューターの監視を自動的に開始します。

AD DS を使用して管理グループにコンピューターを割り当てるには、次の手順を実行します。

  • AD DS ドメインの機能レベルは、Windows 2008 ネイティブ以上である必要があります。
  • エージェントで管理されたコンピューターとすべての管理サーバーは、同じドメインまたは双方向に信頼関係のあるドメインに存在する必要があります。

Note

ドメイン コントローラーにインストールされていることを確認するエージェントは、Active Directory に構成情報のクエリを実行しません。 これはセキュリティ上の理由によるものです。 エージェントはローカル システム アカウントで実行されるため、ドメイン コントローラーでは Active Directory 統合が既定で無効になります。 ドメイン コントローラーのローカル システム アカウントにはドメイン管理者権限があります。したがって、ドメイン コントローラーのセキュリティ グループ メンバーシップに関係なく、Active Directory に登録されている管理サーバー サービスの接続ポイントはすべて検出されます。 そのため、エージェントは、すべての管理グループ内のすべての管理サーバーへの接続を試みます。 結果を予測できない可能性があるため、セキュリティ上のリスクを伴います。

エージェントの割り当ては、クライアント アプリケーションがサービスへのバインドに使用できる情報を公開するための Active Directory オブジェクトである、サービス接続ポイント (SCP) を使用して行われます。 これは、MOMADAdmin.exe コマンドライン ツールを実行し、管理対象コンピューターのドメインに Operations Manager の管理グループ用の AD DS コンテナーを作成するドメイン管理者により作成されます。 MOMADAdmin.exe の実行時に指定された AD DS セキュリティ グループには、コンテナーに対する読み取りアクセス許可と削除子アクセス許可が付与されます。 SCP には、サーバーの FQDN とポート番号を含む、管理サーバーへの接続情報が含まれます。 Operations Manager エージェントは、SCP を照会して、自動的に管理サーバーを検出できます。 継承は無効ではなく、エージェントは AD に登録されている統合情報を読み取ることができるため、Everyone グループが Active Directory のルート レベルですべてのオブジェクトを強制的に読み取る場合、これは AD 統合機能に重大な影響を与え、本質的に中断します。 Everyone グループに読み取りアクセス許可を与えることでディレクトリ全体に継承を明示的に強制する場合、上位の AD 統合コンテナー (OperationsManager) とすべての子オブジェクトでこの継承をブロックする必要があります。  これを行わない場合、AD 統合は設計どおりに機能せず、エージェントに対して信頼性の高い一貫性のあるプライマリとフェールオーバーの割り当てがデプロイされません。 さらに、管理グループが複数ある場合、両方の管理グループのすべてのエージェントがマルチホームになります。 

この機能は、分散管理グループ展開でエージェントの割り当てを制御する場合に適しています。リソース プール専用の管理サーバーまたはウォーム スタンバイ構成のセカンダリ データ センター内の管理サーバーにエージェントがレポートしないようにすることで、通常の操作中でのエージェントのフェールオーバーを防ぐことができます。

エージェント割り当ての構成は、エージェントの割り当てとフェールオーバー ウィザードを使用し、プライマリ管理サーバーおよびセカンダリ管理サーバーにコンピューターを割り当てる Operations Manager 管理者により管理されます。

Note

Active Directory 統合は、オペレーション コンソールからインストールされたエージェントに対しては無効にされています。 Active Directory 統合は、既定では MOMAgent.msi を使用して手動でインストールされたエージェントに対して有効にされます。

次のステップ