目次

コマンドセンター(メタコンソール)

Pandora FMS ドキュメント一覧に戻る

コマンドセンター

Pandora FMS バージョン 756 から、中央管理モードの環境における同期システムを一から再設計し、これまでの手動同期を必要とせずに変更がノードに自動的に複製されるようになったため、より高速で効率的になりました。

この変更により、以前のシステムは古いシステムと見なされるため、それが有効だった環境では、新しい中央管理システムを利用しかつ データの整合性を保証できるように するために、以前のシステムを自動マージするシステムを利用する必要があります。

更新時に、すでに中央管理化されているすべてのコマンドセンター環境は、再び正しく中央管理できるように、中央管理(Centralised management) の新たな マージツール(Merging tool) を通るように強制されます。

マージ処理では、コマンドセンターで構成済みの、無効になっていない ノードのみが考慮されます。

マージツールは、ノードデータベースとコマンドセンター (コマンドセンターから管理されるもの) のさまざまな要素を次のようにマージします。コマンドセンターに登録されているノード間で優先順位が確立され、最も優先度の高い項目がリストの先頭に、最も優先度の低い項目が末尾に配置されます。

例:

この優先順位リストは、同じ要素が異なるノードに存在するが、設定が異なる場合に使用されます。

監視ポリシーの場合、ポリシーのモジュール、アラート、その他の要素は、ポリシーの個別の独立した要素と見なされますが、同様にマージされます。

モジュールのみの場合の例:

マージツールによって一元化される要素

次の要素は、新しいマージツールから一元化される要素です。

マージツールから統合した後、サーバ設定ファイル pandora_server.conf のパラメーター autocreate_group を有効なグループIDで調整してください。

上記すべてをまとめたもの:

以下の要素は、上記の 優先順位ルール に従って、マージツールを使用してコマンドセンターによって集中管理されます。

要素 ID プロファイル 名前 グループ Ex.1) OS
ユーザ ✅ ❌ ❌ ❌ ❌ ❌
ユーザプロファイル ❌ ❌ ✅ ❌ ❌ ❌
エージェントグループ ❌ ❌ ✅ ❌ ❌ ❌
ファイルコレクション ❌ ❌ ✅ 2) ❌ ❌ ❌
アラートテンプレート ❌ ❌ ✅ ❌ ❌ ❌
アラートコマンド ❌ ❌ ✅ ❌ ❌ ❌
警告アクション ❌ ❌ ✅ ❌ ❌ ❌
サーバプラグイン ❌ ❌ ✅ ❌ ✅ ❌
OS ❌ ❌ ✅ ❌ ❌ ❌
モジュールラベル ❌ ❌ ✅ ❌ ❌ ❌
モジュールカテゴリ ❌ ❌ ✅ ❌ ❌ ❌
モジュールグループ ❌ ❌ ✅ ❌ ❌ ❌
コンポーネントグループ ❌ ❌ ✅ ❌ ❌ ❌
ネットワークコンポーネント ❌ ❌ ✅ ❌ ❌ ✅
ローカルコンポーネント ❌ ❌ ✅ ❌ ❌ ✅
コンポーネントテンプレート ❌ ❌ ✅ ❌ ❌ ❌
インベントリモジュール ❌ ❌ ✅ ❌ ❌ ✅
監視ポリシー ❌ ❌ ✅ ❌ ❌ ❌
ポリシーモジュール ❌ ❌ ✅ 3) ❌ ❌ ❌
インベントリモジュール
ポリシー 		❌ ❌ ✅ 4) ❌ ❌ ✅
ポリシープラグイン ❌ ❌ ✅ 5) ❌ ✅ 6) ❌
ポリシーコレクション ❌ ❌ ✅ 7) ❌ ❌ ❌
アラートと外部アラート
ポリシーアラート 		❌ ❌ ✅ 8) ❌ ❌ ❌
アラートのアクション
および外部アラート		 ❌ ❌ ✅ 9) ❌ ❌ ❌
ポリシー内の
エージェント 		❌ ❌ ✅ 10) ❌ ❌ ❌
エージェント 11) ❌ ❌ ❌ ❌ ❌ ❌

これらの要素が中央管理されているセクションは、コマンドセンターからのみ管理できます。ノードからこれらの要素にアクセスする場合、リスト表示のみが可能で、編集および作成オプションは表示されません。環境が中央管理モードであることを示す警告も表示され、管理者がこれらの要素を設定するための対応するコマンドセンターセクションへのリンクがあります。

マージツールで使われているデータベーステーブル

次のテーブルは、マージツールにおいてコマンドセンターとノード間で同期されます。


  • tgroup
  • tcollection
  • tplugin
  • tconfig_os
  • ttag
  • tcategory
  • tmodule_group
  • tnetwork_component_group
  • tnetwork_component
  • tlocal_component
  • tnetwork_profile
  • tmodule_inventory
  • talert_commands
  • talert_actions
  • talert_templates
  • talert_calendar
  • talert_special_days
  • tprofile
  • tuser
  • tuser_profile
  • tpolicies
  • tpolicy_modules
  • tpolicy_modules_inventory
  • tpolicy_plugins
  • tpolicy_collections
  • tpolicy_alerts
  • tpolicy_alerts_actions
  • tautoconfig
  • tautoconfig_rules
  • tautoconfig_actions
  • tpolicy_agents


マージツールによるデータベースマージを起動するための前提条件

console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora

これらの要件がすべて満たされていない場合、ノードはマージされず、エラーが返されます。 エラー結果を確認すると、満たされていない条件に関するメッセージを確認できます。

データベースのマージが完了したら、設定ファイル php.ini に対応する memory_limit の値を再設定することが重要です。 変更を有効にするには、Apache httpd サービスを再起動する必要があることに注意してください。

マージツールを起動する前の推奨事項

データベース統合プロセスの必須条件ではありませんが、次の処理も実行することをお勧めします。

マージ処理が開始されると、ノードとコマンドセンターの両方がメンテナンスモードになります。 これの目的は、サーバと pandora_db を停止して、ユーザが処理中に要素を変更してエラーや不整合を引き起こすことを防ぐためです。

マージ処理の実行

マージ処理には 2つの段階があり、コマンドセンターから管理できるさまざまな要素を同期する最初の段階と、イベント内の情報を一元化された要素内で更新する 2番目の段階があります。 この処理は、コンソールができるだけ早く再びアクセスできるようにするためのものです。イベントの更新は、通常、より多くの情報を扱うため、最も時間がかかる可能性がある処理であるためです。 両方のステージは、2つの進捗バーで区別され、さらに 2つのサブステージに分割されます。

ステージ 1 要素

このステージでは、コマンドセンターから管理できるすべてのノードのデータベースで要素の同期が行われます。 それ自体がマージ処理であり、2つのサブステージに細分され、それぞれに独自の進捗バーがあります。

この処理中にエラーが発生した場合(たとえば、データベースとの接続が失われた場合)、プロセス自体が生成されたバックアップの復元を試みます(復元の進行状況を示す 3番目の赤い進行状況バーが表示されます)。 失敗の理由によりバックアップのリカバリができない場合は、手動でリカバリを実行する必要があります。

障害の原因によってバックアップのリカバリが妨げられている場合、リカバリは手動で実行する必要があります。

コマンドセンターとノードのデータベース間の接続がしばらく失われたり、十分なディスク容量がないためにバックアップを作成できなかったりするなど、予期しない障害が発生する場合があります。そのため、表示されるエラーメッセージは一般的なものになる可能性があります。その場合にサポートが必要であれば、Pandora FMS サポートチームに連絡して支援を受けてください。

ステージ 2: イベント更新

このステージでは、イベント内のさまざまな同期要素への参照情報が更新されます(たとえばグループごとに)。 ステージは、メインデータベースのイベントの更新とヒストリデータベースのイベントの更新に細分され、マージ処理を開始する前に存在していたイベントにのみ影響します。環境を一元化した後に新しく生成されたイベントには、すべての正しい参照情報が含まれているため、更新する必要はありません。

マージツールを通してすでに一元化された環境

ステージ1が終了すると、環境は一元化されていると見なされ、そこ時点よりコマンドセンターからすべてを管理できるようになります。要素の同期も変更され、各ノードの pandora_ha プロセスがデータベースとコマンドセンターのデータベースの同期を担当するようになります。

コマンドセンターで変更を加えると(たとえば、ユーザを作成すると)、ノードデータベースへの必要なクエリ(INSERTS, UPDATES など)がキューに入れられます。それは順番に server_threshold ごとに pandora_ha によって読み取られ実行されます。 これにより、サーバがしばらくダウンした場合でも、サーバを再起動したときに正しく追いつくことができます。

この保留中のクエリのリストは、コマンドセンターのコンソールセットアップから確認できます。 何らかの理由でクエリが失敗した場合、ノードは残りのクエリを続行せず、コンソールセットアップにエラーが表示され、管理者が手動で処理する必要があります。ほとんどの場合、マージツールでマージ処理を再度起動することで修正できるはずです。

新たなノードを含める

集中管理環境に新しいノードを追加するには、コマンドセンターで セットアップ(Setup) → メタセットアップ(Metasetup) → コンソールセットアップ(Consoles setup) に移動し、新しいノード(New node) ボタンをクリックします。接続を確立し保存するにはすべてのフィールドに入力する必要があります。データがない完全に新しいノードの場合は 空のノードを登録(Register empty node) ボタンで追加し、それ以外の場合は マージするデータを含むノードを登録(Register node with data to merge) ボタンを使用する必要があります。

確認し OK をクリックすると、新しいノードが集中管理化されます。

Pandora FMS ドキュメント一覧に戻る

1)
実行
2)
Short name.
3) , 4) , 5) , 6) , 7)
同じ名前のポリシー内
8)
同じ名前のポリシー内で同じモジュール名
9)
同じ名前のポリシー内の同じモジュール名の同じテンプレート内
10)
同じ名前のポリシー内、コマンドセンターポリシー内のエージェントレコードは破棄され、ノード レコードのみが考慮されます。
11)
ノード管理, コマンドセンター内で削除