コマンドセンター

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

From Pandora FMS version 756, the synchronization system for environments with centralized mode has been redesigned from scratch, making it faster and more efficient, since the changes will be replicated to the nodes automatically without the need for manual synchronization, as it was the case up to now.

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

This change deems the previous system outdated, so in environments where it was active, it will have to go through the previous automatic merging system to use the new centralization system and be able to guarantee data integrity.

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

When updating, all already centralized Metaconsole environments will be forced to go through the new Merging tool section located in Centralised management to be able to be centralized again correctly.

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

The Merging tool will merge the different elements of the node and Metaconsole databases (of those that must be managed from Metaconsole) in the following way. An order of priority will be established between the Metaconsole nodes and the Metaconsole itself, placing the elements with the highest priority at the top of the list and at the bottom those with lower priority.

マージツール(Merging tool) は、ノードデータベースとメタコンソールデータベース(メタコンソールから管理する必要があるデータベース)のさまざまな要素を次のようにマージします。優先順位は、メタコンソールのノードとメタコンソール自体の間で確立され、優先度が最も高い要素がリストの一番上に配置され、優先度が低い要素が一番下に配置されます。

For example:

例:

This priority list is used for cases where the same element exists in the different nodes but has different configurations. For example, for 2 nodes and the Metaconsole to have the group “Databases”. With this order of priority, the configuration of the highest priority element will be taken for all, in the example of the Metaconsole.

この優先順位リストは、同じ要素が異なるノードに存在するが、設定が異なる場合に使用されます。 たとえば、2つのノードとメタコンソールにグループ “Databases” があるとします。 この優先順位では、メタコンソールの例では、すべてに対して最も優先度の高い要素の設定が採用されます。

In another case, if for example only nodes 1 and 2 had a policy called “Windows”, for all nodes and the Metaconsole the configuration for that policy would be that of Node 1 (we skip the Metaconsole because it does not have it).

別のケースでは、たとえばノード 1 と 2 のみに “Windows” というポリシーがある場合、すべてのノードとメタコンソールにおいて、そのポリシーの設定はノード 1 の設定になります(メタコンソールにはそれがないためスキップします)。

The case of policies would be the most particular one out of all the synchronized elements due to how they are configured, since every module, alert, plugin… is dealt with as an independent element and seeing it only with modules, if you have:

ポリシーの場合は、そのの設定方法により、同期されるすべての要素の中で最も特殊なものになります。なぜなら、すべてのモジュール、アラート、プラグイン… が独立した要素として扱われ、次の場合はモジュールでのみ表示されるためです。

The result of the Command Center would be:

マージツールの結果は次のようになります。

This allows the result to have as many different configurations as possible so that you can now manage them from the Metaconsole.

これにより、結果として可能な限り多くの異なる構成を設定できるため、メタコンソールからそれらを管理できるようになります。

The following elements are those centralized from the new Merging tool:

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

• Users: It is only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same ID will be considered the same user (following the priority rules described previously).
• User profiles: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same user (following the priority rules described previously).
• Agent groups: They are only managed from the Metaconsole. Node management is disabled.
• By unifying from the Merging tool those with the same name will be considered to be from the same group (following the priority rules described previously).

• ユーザ: メタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じID を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
• ユーザプロファイル: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つユーザは同じユーザと見なされます(前述の優先ルールに従います)。
• エージェントグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。
• マージツールから統合することにより、同じ名前を持つものは同じグループからのものと見なされます(前述の優先ルールに従います)。

• File collections: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same short name will be considered to be from the same collection (following the priority rules described previously).
• Alert template: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same template (following the priority rules described previously).
• Alert commands: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same command (following the priority rules described previously).
• Alert actions: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same action (following the priority rules described previously).
• Server plugins : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name and execution will be considered as the same plugin (following the priority rules described previously).
• OS: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same OS (following the priority rules described previously).
• Module tags: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same tag (following the priority rules described previously).
• Module categories: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same category (following the priority rules described previously).
• Module groups: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same group (following the priority rules described previously).
• Component group: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same group (following the priority rules described previously).
• Network components: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name and OS will be considered as the same component (following the priority rules described previously).
• Local components: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name and OS will be considered as the same component (following the priority rules described previously).
• Component Template: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same template (following the priority rules described previously).
• Inventory module: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name and OS will be considered as the same module (following the priority rules described previously).
• Monitoring policies: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name will be considered as the same policy (following the priority rules described previously).
• Policy modules: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name within a policy with the same name will be considered as the same module (following the priority rules described previously).
• Policy inventory modules: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name and OS within a policy with the same name will be considered as the same module (following the priority rules described previously).
• Policy plugins : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same execution within a policy with the same name will be considered as the same plugin (following the priority rules described previously).
• Policy collections: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same short name within a policy with the same name will be considered as the same collection (following the priority rules described previously).
• Alerts and policy external alerts: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same template on the same module name within a policy with the same name will be considered as the same alert (following the priority rules described previously).
• Actions on alerts and policy external alerts: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those with the same name on the same template on the same module name within a policy with the same name will be considered as the same action (following the priority rules described previously).
• Agents within policies: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Merging tool those within policies with the same name will be considered as the agents within the same policy. Agent logs within Metaconsole policies will be discarded and noly node logs will be taken into account (which is where application becomes effective).
• Agents: Agent management in node is allowed, except for their deletion which should be done from the Metaconsola.

The sections where those elements are centrally managed can only be managed from the Metaconsole. In case of accessing those elements from the nodes, you may only list them, and the editing and creating options will disappear. Also a warning that will indicate that the environment is in centralized mode, with a link that will lead to the administrator to the corresponding Metaconsole section for element configuration.

• ファイルコレクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
• アラートテンプレート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
• アラートコマンド: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じコマンドと見なされます(前述の優先ルールに従います)。
• アラートアクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じアクションと見なされます(前述の優先ルールに従います)。
• サーバプラグイン : それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前と実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
• OS: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じOS と見なされます(前述の優先ルールに従います)。
• モジュールタグ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じタグと見なされます(前述の優先ルールに従います)。
• モジュールカテゴリ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じカテゴリと見なされます(前述の優先ルールに従います)。
• モジュールグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
• コンポーネントグループ: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前を持つものは同じグループと見なされます(前述の優先ルールに従います)。
• ネットワークコンポーネント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
• ローカルコンポーネント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前とOS を持つものは同じコンポーネントと見なされます(前述の優先ルールに従います)。
• コンポーネントテンプレート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じテンプレートと見なされます(前述の優先ルールに従います)。
• インベントリモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前とOS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
• 監視ポリシー: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前を持つものは同じポリシーと見なされます(前述の優先ルールに従います)。
• ポリシーモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内で同じ名前のモジュールを持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
• ポリシーインベントリモジュール: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前のポリシー内で同じ名前のモジュールと OS を持つものは同じモジュールと見なされます(前述の優先ルールに従います)。
• ポリシープラグイン : それらはメタコンソールからのみ管理されます。ノード管理は無効になります。 マージツールから統合することにより、同じ名前のポリシー内で同じ実行ファイルを持つものは同じプラグインと見なされます(前述の優先ルールに従います)。
• ポリシーコレクション: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内で同じ短い名前を持つものは同じコレクションと見なされます(前述の優先ルールに従います)。
• アラートとポリシー外部アラート: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内の同じモジュール名に同じテンプレートを持つものは同じアラートと見なされます(前述の優先ルールに従います)。
• アラートおよびポリシー外部アラートのアクション: れらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールから統合することにより、同じ名前のポリシー内の同じモジュール名の同じテンプレート上の同じ名前を持つものは、同じアクションと見なされます(前述の優先ルールに従います)。
• ポリシー内エージェント: それらはメタコンソールからのみ管理されます。ノード管理は無効になります。マージツールからら統合することにより、同じ名前のポリシー内の同じ名前のエージェントは、同じポリシー内のエージェントと見なされます。(アプリケーションの動作に関わる)メタコンソールポリシー内のエージェントログは破棄され、ノードログは考慮されません。
• エージェント: メタコンソールから実行する必要がある削除を除いて、ノードでのエージェント管理が許可されます。

The following tables are synchronized between the Metaconsole and nodes within the Merging tool (see also “Main database tables”):

次のテーブルは、マージツールにおいてメタコンソールとノード間で同期されます。(“メインデータベーステーブル” も参照ください。)

• The Metaconsole must be able to connect to all databases and all node APIs. Make sure that the “Consoles setup” configuration is correct and that the indicators are green.

• メタコンソールは、すべてのデータベースとすべてのノード API に接続できる必要があります。“コンソールのセットアップ” の設定が正しく、インジケーターが緑色であることを確認してください。

• Node consoles must be able to connect to the Metaconsole database. Usually this will not be a problem, unless you have the consoles on computers other than that of Pandora FMS servers. Make sure that the Setup → Enterprise configuration parameters for the Metaconsole on the nodes is correct.

• ノードコンソールは、メタコンソールデータベースに接続できる必要があります。 Pandora FMS サーバとは別のマシンにコンソールがあるような場合でなければ、通常、これは問題にはなりません。ノード上で セットアップ(Setup) → Enterprise のメタコンソール設定パラメーターが正しいことを確認してください。

• Servers from all nodes must be able to connect to the Metaconsole's API. It is recommended to configure the public URL in the Metaconsole.

• 全ノードのサーバは、メタコンソールの API へ接続できる必要があります。メタコンソールで公開 URL を設定することをお勧めします。

• Node servers must have their API configuration correct in “pandora_server.conf” or their public URL configuration in the consoles Setup. If it is not configured, servers must be hosted in the same machines their consoles are in.

• ノードサーバは、“pandora_server.conf” で正しいAPI設定や、コンソールのセットアップでの公開URL設定が必要です。

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

• Each node must be able to connect to its own history database.

• それぞれのノードは、それ自身のヒストリデータベースへの接続ができる必要があります。

• All nodes and the Metaconsole must be from the same version.
• All nodes and the Metaconsole must be in the same MR.

• すべてのノードとメタコンソールは同じバージョンである必要があります。
• すべてのノードとメタコンソールは同じMRである必要があります。

• All nodes and Metaconsole must have the same maximum collection size configured in the Setup.

• すべてのノードとメタコンソールには、セットアップにて同じ最大コレクションサイズを設定する必要があります。

• To avoid errors, the Metaconsole and the nodes must have the memory_limit parameter from php.ini to -1, that is, limitless, but only for the database merging process. After finishing it, it is recommended to set it back to the previous value. That is because a lot of memory is used to merge the nodes, and in very large environments (with many different elements) a large amount of memory can be used, that way you make sure that the system can use all the memory available. If the items to be merged exceed the value of the physical memory available on the server, the Merging tool will fail due to an unexpected error, and in the console/apache logs you will see the line indicating the excess memory reached.
• All nodes must have a value for the parameter post_max_size from php.ini higher or equal to the value configured for the same Metaconsole parameter. This value must be at least as big as the biggest file collection size there is. It should also be taken into account that this parameter must have a value higher than or equal, both in the nodes and in the Metaconsole, to the value of upload_max_filesize.
• All nodes must have a value for the upload_max_filesize parameter from php.ini higher or equal to the value configured for the same Metaconsole parameter. This value must be at least as high as the size of the biggest file collection you have.
• All nodes and Metaconsole must have enough space in the disk that hosts its directory “attachment” to be able to carry out backups from the database and collections.

• エラーを回避するには、メタコンソールおよびノードの 設定ファイル php.ini の memory_limit に -1 の設定が必要です。つまり、無制限です。ただしマージプロセスのみ です。 終了後、以前の値に戻すことをお勧めします。これは、ノードのマージに大量のメモリが使用され、非常に大規模な環境(多くの異なる要素がある)では大量のメモリを使用できるようにシステムが使用可能なすべてのメモリを確実に使用できるようにするためです。 マージされるアイテムがサーバで使用可能な物理メモリの値を超えると、予期しないエラーが原因でマージツールが失敗し、コンソール/Apache ログに、メモリ超過が発生したことを示す行が表示されます。
• すべてのノードでは、php.ini の post_max_size の値は、メタコンソール の upload_max_file_size より大きいか等しい必要があります。この値は、存在する最大のファイルコレクションサイズと少なくとも同じ大きさである必要があります。
• すべてのノードでは、php.ini の upload_max_filesize の値は、メタコンソール の同じパラメータより大きいか等しい必要があります。
• すべてのノードでは、php.ini の post_max_size の値は、メタコンソール における同じパラメータより大きいか同じ必要があります。この値は、存在する最大のファイルコレクションサイズと少なくとも同じ大きさである必要があります。また、ノードとメタコンソールの両方で、このパラメーターの値がupload_max_filesize の値以上である必要があります。
• すべてのノードとメタコンソールは、データベースとコレクションのバックアップを実行できるように、“attachment ディレクトリが存在するディスクに十分な空きがある必要があります。

• All nodes and Metaconsole must have the computer's date and time correctly configured (the use of NTP servers is recommended).

• すべてのノードとメタコンソールでは、コンピューターの日付と時刻が正しく設定されている必要があります(NTPサーバの使用をお勧めします)。

Although they are notrequisites for database unification process, it is recommended to carry out the following actions too:

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

• Stop thepandora_serverof all nodes and the Metaconsole for the whole process. As key elements such as groups are going to be changed, their IDs can be modified, and it is not recommended to have the server process include new references to the environment while it lasts. However, the running server shouldn't be a problem in most cases.
• Stop thecron pandora_db process temporarily for the duration of the process, for the same reasons as the server.

• 処理全体を通してで、すべてのノードの pandora_server とメタコンソールを停止します。グループなどの重要な要素が変更されるため、それらの ID が変更されることがありあす。また、処理中は、環境にアクセスするような処理を動かすことはお勧めしません。 ただし、ほとんどの場合、実行中のサーバは問題にはなりません。
• サーバと同じ理由で、処理中は、cron pandora_db プロセスを一時的に停止します。

The merging process has 2 stages, a first stage to synchronyze the different elements that can be managed from the Metaconsole and a second stage to update the references in the events to those centralized elements. This process is performed that way to allow the console to be accesible again as soon as possible, since event updating is part of the process that can take the longest since it usually entails more information. Both stages are in turn divided into other 2 sub-stages differentiated in 2 progress bars.

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

In this stage elements are synchronized found in the databases from all nodes that can be managed from the Metaconsole. It is the merging process as such and it is sub-divided in other 2 stages, each one with its own progress bar:

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

• Initialize: It checks all the previous requirements, generates the corresponding backups (if the requirements are met) in case any part of the process fails, and generates the result of the database merging within the memory. If this process fails for any reason, the databases will not have been modified yet, so it will not be necessary to restore backups. Backups are stored in each node/Metaconsole in the directory: /attachment/merge_backups
• Apply: If the previous initialization stage was successful, it will be applied to all nodes and the Metaconsole. This process is sequential in order of priority, so when one is finished, the next one will start.

• 初期化: すべての要件をチェックし、(要件が満たされている場合は)処理のいずれかの部分が失敗した場合に対応するバックアップを生成し、メモリ内でデータベースをマージした結果を生成します。この処理が何らかの理由で失敗した場合、データベースはまだ変更されていないため、バックアップを復元する必要はありません。 バックアップは、各ノード/メタコンソールの次のディレクトリに保存されます: /attachment/merge_backups
• 適用: 前の初期化段階が成功した場合、統合の結果はすべてのノードとメタコンソールに適用され始めます。このプロセスは優先度の高い順に実行されるため、1つが終了すると、次のプロセスが開始されます。

If there is an error during this process (for example, connection loss with a database), the process itself will try to restore the generated backups (a third red progress bar will be seen that will mark the restoration progress). If the reason for the failure prevents the backups from being recovered, the recovery must be done manually.

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

• Synchronization cancelled:

• 同期が中止された場合:

In this stage the existing references to the different synchronized elements in events will be updated (for example by groups). The stage is subdivided in the update of the main database events and the history database event update and will only affect those events that existed before launching the merging process. The new generated events after centralizing the nevironment will have all the correct references and won't need to be updated.

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

• Main database: As events are a large volume of information that is also affected, this update process takes place in parallel with the normal operation of the already merged environment. At this point, the server and pandora_db can be started again normally, and standard users are able to access the console again. Of course, you will see in the event view the update process bar for all the events, so that for that part there might still be inconsistencies (regarding filters for example) only for the events that were there before the merge. New events would be generated normally. This stage and process is launched by each of the nodes, through a specific task in the console's cron. Due to the volume of information, it can be a heavy and time-consuming task, so as far as possible the less load the environment has at that time the better (try to launch it outside of the busiest hours on Pandora FMS).
• History database: It would be the continuation of the previous point, updating the events in the historical database under the same characteristics already indicated.

• メインデータベース: CA イベントは大量の情報であり、影響も受けます。この更新処理は、すでにマージされた環境の通常の操作と並行して行われます。 この時点で、サーバと pandora_db を正常に再起動でき、標準ユーザはコンソールに再度アクセスできます。 もちろん、イベント表示では、すべてのイベントの更新処理バーが表示されますが、マージ前に存在していたイベントについてのみ（フィルターなどに関して）不整合が発生する可能性があります。 新しいイベントは通常どおり生成されます。 このステージと処理は、コンソールの cron の特定のタスクを介して、各ノードによって起動されます。 情報量が多いため、それは重くて時間のかかる作業になる可能性があります。可能な限り、環境の負荷が少ないタイミングがよいでしょう(Pandora FMS に負荷がかかっていない時間に起動してみてください)。
• ヒストリデータベース: これは上記の続きであり、すでに示したのと同じようにヒストリデータベース内のイベントを更新します。

Once stage 1 is finished, the environment will be considered centralized, and from there you will be able to manage everything from the Metaconsole. Element synchronization has also been changed, now the pandora_ha process of each node is in charge of synchronizing its database with that of the Metaconsole.

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

When you make a change in the Metaconsole (for example, create a user) this queues the necessary queries to the database for the nodes (INSERTS, UPDATES, etc.) which pandora_ha reads in an orderly manner and executes in each server_threshold. This ensures that if a server is down for a while, when it is started again it can catch up correctly.

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

This list of pending queries can be seen from the Metaconsole in the Consoles setup. If for some reason any query fails, the node will not continue with the rest, you will see an error in Consoles setup and it will be necessary to treat it manually by an administrator. In most cases you should be able to fix it by launching the merging process again in the Merging tool.

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

If in an already centralized environment you add a new node, edit one, or re-enable an existing one that has been left out of the merge, it will be necessary to go through the Merging tool again.

すでに一元化されている環境で、新しいノードを追加したり、編集したり、マージから除外された既存のノードを再度有効にしたりする場合は、マージツール を再度実行する必要があります。

A message will be displayed warning the administrator to do this task. While it is not performed, the node will remain locked and inaccessible, in pending-to-merge status. The changes made will not be assigned to it aor will it have access to the console until it goes through the merging process.

管理者にこのタスクを実行するよう警告するメッセージが表示されます。 未実行の間は、ノードはマージ保留中状態で、ロックされてアクセスできない状態のままになります。 加えられた変更はそれに割り当てられないか、マージ処理が完了するまでコンソールにアクセスできます。

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