ja:documentation:06_metaconsole:09_metaconsole

NG 756 より前のバージョンのメタコンソール

If you already knew Pandora FMS before version 5.0, then you know that the Metaconsole concept already existed.

Pandora FMS バージョン 5.0 以前を知っている方なら、メタコンソールのコンセプトがすでにあることは知っているかと思います。

This section discusses the differences between the current Metaconsole and the old one, and also the solved failures and the developments proposed.

この章では、現在のメタコンソールと以前のものの違いおよび、改善された問題と改善点を示します。

Before version 5.0, a normal Pandora FMS installation (Console+Server) could also work as Metaconsole.

バージョン 5.0 以前は、Pandora FMS の通常インストール (コンソール + サーバ) で、メタコンソールとしても動作しました

通信

The communication between the Metaconsole and the instances was unidirectional. The Metaconsole was connected to the instance databases and managed all memory data.

メタコンソールとインスタンスの間の通信は、直接ではありませんでした 。メタコンソールは、インスタンスのデータベースへ接続し、メモリ上で全データの管理 をしていました。

It did not store almost nothing in its own database.

自分自身のデータベースには、ほとんど何も保存しませんでした

同期

Synchronization is done one-way between instances: from Metaconsole to instances.

同期 は、メタコンソールからインスタンスへの一方通行 で実施されました。

Let us suppose that you wish to configure some alert templates so that they have several or all the instances.

全てのインスタンスで、いくつかのアラートテンプレートを設定したいと仮定します。

Without logging out of the Metaconsole, templates can be configured and synchronized with the desired instances.

メタコンソールからログアウトせずに、テンプレートを設定して、目的のインスタンスと同期させることができます。

問題

The Metaconsole was very inefficient due to its non-centralized architecture. A lot of connections to different databases were established and user experience was poor.

集中管理アーキテクチャではない ため、メタコンソールはとても非効率 でした。多くの異なるデータベース接続が必要で、ユーザにとってわかりにくくなっていました。

The available options were insufficient to get the intended control of instance environments without logging out of the Metaconsole.

メタコンソールから離れることなくインスタンス環境を制御するためのオプションも不十分 でした。

Summarizing, the Metaconsole was slow when it was a little bit loaded and the user was very limited by its options.

結果、メタコンソールは負荷のある環境では遅く、オプションとして使うユーザは限定的となっていました。

The Metaconsole from version 5.0 is an special environment completely independent and incompatible with the console.

バージョン 5.0 からの メタコンソール は、完全に独立した特別な環境 となり、コンソールとは別のもの となっています。

通信

The communication between the Metaconsole and the instances is bi-directional. The Metaconsole connect with the instance database and the instances replicate part of their data to the Metaconsole database.

メタコンソールとインスタンスの間の通信は、双方向 です。メタコンソールは、インスタンスのデータベースへ接続し、また、インスタンスはデータの一部をメタコンソールのデータベースに複製します。

Other data, such as groups, alert templates, tags… are stored in the Metaconsole.

グループ、アラートテンプレートタグなどのその他データは、メタコンソールに保存されます。

同期

The synchronization is done in a one way: From the Metaconsole to the instances.

同期 は、メタコンソールからインスタンスの一方方向 にて実施されます。

For example:

例:

Lets suppose that we want to configure some alert templates for the ones that have several or all instances. Without exit from the metaconsole we could configure the templates and synchronize them with the instances that we want.

いくつか、または、全インスタンスで、いくつかのアラートテンプレートを設定したいと仮定します。メタコンソールから離れることなく、テンプレートの設定と必要なインスタンスに同期を行うことができます。

改善

From version 5.0 onwards, the Metaconsole is a much more centralized, quick, and flexible tool than the previous version. It also includes many more views and features, as well as developments in the existing ones. It does not manage all data in memory, storing part of the information, which improves user experience.

バージョン 5.0 からのメタコンソールは、以前のバージョンと比べて、より中央管理高速柔軟 なツールとなっています。多くの表示や機能 を備え、以前のものよりも改善がされています。メモリ上でのデータ管理は実施せず、一部の情報を保存し、ユーザの利便性を向上しています。

This table summarizes the differences between the old Metaconsole features and the new ones.

以下の表に、新旧のメタコンソールの違いを示します。

Before version 5.0 From version 5.0
The metaconsole can work as an instance
Synchronization Decentralization Centralized
Communication Unidirectional Bidirectional
Instance configuration
User panel
Tactical view Through instances General and 15 last events
Agent browser
Group view
Event visor (Data in Instances) (Data in the Metaconsole)
Tree view
Alert view
Module view
Network map
Traffic monitoring (Netflow)
Synchronization tools Users/Profiles
Components
Policies
Alerts
Users/Profiles
Groups
Components
Alerts
Tags
Move agents between instances
Report templates
Editors Reports
Visual console
Users/Profiles
Groups
Components
Reports
Visual console
Alerts
Tags
Categories
Apply/Policy queue
Monitor view
Custom field view
Wizard
Visual console viewer
Cronjob setup
バージョン 5.0 以前 バージョン 5.0 から
メタコンソールがインスタンスとして動作
同期 非中央管理 中央管理
通信 一方方向 双方向
インスタンス設定
ユーザパネル
概要表示 インスタンス経由 全体および最新の 15イベント
エージェントブラウザ
グループ表示
イベント表示
(インスタンス内データ)

(メタコンソール内データ)
ツリー表示
アラート表示
モジュール表示
ネットワークマップ
トラフィックモニタリング (Netflow)
同期ツール ユーザ/プロファイル
コンポーネント
ポリシー
アラート
ユーザ/プロファイル
グループ
コンポーネント
アラート
タグ
インスタンス間のエージェント移動
レポートテンプレート
エディタ レポート
ビジュアルコンソール
ユーザ/プロファイル
グループ
コンポーネント
レポート
ビジュアルコンソール
アラート
タグ
カテゴリ
適用/ポリシーキュー
監視表示
カスタムフィールド表示
ウィザード
ビジュアルコンソール表示
Cronジョブ設定

The Metaconsole has tools for element synchronization, such as the synchronization of users and groups, which is essential for instance correct management. Synchronization is based on passing all the information created in the Metaconsole to the different instances in order to manage all the information from each and everyone of them from the Metaconsole.

メタコンソールには、ユーザおよびグループなどの要素を同期するツールがあります。これは、インスタンスの正しい管理のために基本的なものです。同期の基本は、メタコンソールで作成されたすべての情報を、メタコンソールから管理できるようにするために異なるインスタンスへ渡すことです。

For example, a user created in an instance, but not in the Metaconsole, cannot be managed from the Metaconsole. On the other hand, if there is a created user in the Metaconsole, and users are synchronized, this user will be in Instances and it will be possible to manage it from the Metaconsole.

たとえば、インスタンスで作成されメタコンソールでは作成されていないユーザは、メタコンソールから管理できません。 一方、メタコンソールに作成されたユーザがいて、ユーザが同期されている場合、このユーザはインスタンスにも存在し、メタコンソールから管理することができます。

The Metaconsole has tools for element propagation, such component propagation or moving agents between instances (or nodes). Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole. It only provides data availability in instances, something that is necessary if, for example, policies that are applied in different instances (or nodes) are used.

メタコンソールには、インスタンス(ノード)関でエージェントを移動させたりコンポーネントを伝播させるなど、要素を伝播させるためのツールがあります。同期とは異なり、メタコンソールを最適に機能させるための基本的なツールではなく、インスタンス内のデータの可用性を上げるためのものです。例えば、異なるインスタンス(またはノード)に適用されるポリシーを使用する場合などです。

For example, you may want to move an agent from Instance A to Instance B to balance instance load, through this set of tools it can be easily achieved.

たとえば、エージェントをインスタンスAからインスタンスBに移動して、インスタンスの負荷を分散したい場合があります。この一連のツールを使用すると、簡単に実行できます。

インスタンスとメタコンソールのインストールでは、サーバ間の通信が双方向でできる必要があります。

そのためには、以下を確認する必要があります。

  • メタコンソールがインスタンスへ接続できる
  • インスタンスがメタコンソールへ接続できる

インスタンス同士は通信できる必要はありません。

より詳細を確認するには、メタ コンソールアーキテクチャ を参照してください。

タイムゾーン設定 は同じである必要があります。インスタンスとメタコンソールの間で同期が行われます。正確には、表示されるデータが同期されます。

例: インスタンスがメタコンソールと 5分ずれている場合、メタコンソールでデータが表示された時、表示される時間がイベントが生成された時間を過ぎてしまう事が発生します。

インスタンス

一つのインスタンスのインストールは、Pandora FMS Enterprise の一般的なインストー ルと同じです。一つのインスタンスは、サーバとウェブコンソールから構成されます。 インスタンスのインストール方法詳細は、Pandora FMS のインストール を参照してください。


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタコンソール

メタコンソールは、Pandora FMS Enterprise をメタコンソールライセンスを使ってイン ストールしたものです。

Pandora FMS の通常のコンソールとメタコンソールでは、同じライセンスは利用できません。

“マイグレーション”、“自己プロビジョニング”、サービスの実行など、メタコンソールに関連するさまざまな操作を実行するには、サーバを有効化する必要があります。

メタコンソールライセンスの有効化

Enterprise 版の Pandora FMS コンソールをインストールした後、インストール方法に関係なく、Pandora コンソール(http://IP/pandora_console/)にアクセスする必要があります。ライセンスを受け入れるための画面が表示されます。 ライセンスの有効化の詳細 については、こちら をご覧ください。

メタコンソールを有効化にするには、メタコンソールライセンスが必要です。ノードライセンスを有効化すると、通常のコンソールが表示されます。

Pandora FMS のバージョン 7.0NG では、メタコンソールを使用する環境では特別なライ センスを利用します。 メタコンソール配下でエージェントの合計数を超えていない限り 、必要な数だけインスタンスを作成できます。

このライセンスはメタコンソールに適用され、必要な数のインスタンスと同期することができるため、各インスタンスに設定された任意のエージェントを集中管理することができます。

このライセンスでは、初期インストールを開始する場合、まずはメタコンソールをインストールする必要があります。ライセンス認証が完了したら、各インスタンスを登録します(以下のセクションで説明します)。その後メタライセンスを同期させて、すべてのインスタンスが動作するようにします。

ネットワーク障害時以外は、Pandora FMS ノードは Pandora FMS メタコンソールに常時 接続できる必要があります。任意の期間でオフラインになる可能性のあるノードに対応する必要がある場合は、Enterprise 版サポートまでご相談ください。


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

インスタンスとメタコンソールが通信できるようにするためには、両方を正しく設定する必要があります。

メタコンソール

インスタンスの登録と設定


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタセットアップセクションでは、メタコンソールにリンクするインスタンスの登録および構成ができます。

新しいインスタンスを登録するには、管理したいインスタンスが参照する一連のパラメータを知っている必要があります。 まだライセンス登録されていないインスタンスの場合 、デフォルトのデータは次のとおりです。

  • サーバ名: localhost.localdomain
  • 認証トークン: なし
  • コンソール URL: http://IP/pandora_console
  • API パスワード: なし
  • DB ホスト: DB サーバの IP
  • DB 名: pandora
  • DB ユーザ: pandora
  • DB パスワード: pandora
  • DB ポート: 3306
  • 管理ユーザ: admin
  • パスワード: pandora

拡張フィールド

ノードとメタコンソールの接続を確実にするために、接続データを手動で設定することができます。

  • メタコンソール DB ホスト(Metaconsole DB host): データベースIP
  • メタコンソール DB 名(Metaconsole DB name): pandora
  • メタコンソール DB ユーザ(Metaconsole DB user): pandora
  • メタコンソール DB パスワード(Metaconsole DB password): pandora
  • メタコンソール DB ポート(Metaconsole DB port): 3306

これらのフィールドは、ノードメタコンソール へ接続するときの設定を示 します。

インスタンスに有効なライセンスが既に入っている場合は、インスタンスに設定されているのと同じデータベースからデータを取得する必要があります。

設定済インスタンスの表示では、インスタンスの変更、無効化、削除ができます。 各インスタンスの構成に関する情報をチェックするための表示がいくつかあります。これらの表示は、この画面をロードするときに行われますが、個々の表示をクリックすることによっても行うこともできます。

表示は次の通りです。

  • データベース: インスタンスデータベースを正しく設定していないか、必要な権限がない場合は、表示が赤になり、問題に関する情報が表示されます。
  • API: この表示はインスタンスの API テスト結果です。 失敗した場合は、失敗 に関する情報が表示されます。
  • 互換性: この表示は、インスタンスとメタコンソールの間で必要ないくつかの要件のチェックを行います。 たとえば、インスタンスサーバ名は、メタコンソールの構成 で設定した名前と一致している必要があります。
  • イベントの複製: この表示は、インスタンスがイベント複製を有効化しているかどうか、インスタンスの最新のイベントを受信されているかどうかを示します。
  • エージェントキャッシュ: この表示は、ノードのエージェントとモジュールの最後の状態がメタコンソールのデータベースに正しく保存されたかどうかを示します。 変 更が発生すると、その変更のみがデータベース上で変更されます。
  • 同期 :これは、異なる要素をメタコンソースからインスタンスに同期させることができるかどうかを示します。

インスタンスが正しくリンクされてデータが表示されるためには、最初の 3つの表示は緑でなければいけません。対して、イベントの複製表示はこれに関する情報表示のみです。

イベントの複製無しでも、インスタンスを適切に構成できます

イベントの複製を選択すると、すべての管理がメタコンソールから実行でき、インスタンスのイベントは単なる情報保持となります。

データベースの暗号化を有効化している場合、ノードとメタコンソールは、ともに同じ encryption_passphrase 設定を用いる必要があります。

インデックスのスケーリング


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタコンソールとインスタンスの間の同期のほとんどは、要素の内部 ID に関係なく名前で実行されます。ただし、グループ、タグ、アラート、オペレーティングシステム、およびモジュールのグループを除きます。ID は同期していることが重要です。

メタコンソールから同期されたグループ、タグ、アラート、オペレーティングシステム、およびモジュールのグループ IDがインスタンスに存在しないようにする には、テーブル tgrupo、ttag、talert_templates、talert_actions、talert_commands、tconfig_os、および tmodule_group の AUTO_INCREMENT の値を増やします。このように、インスタ ンスに要素が追加されたときに、メタコンソールの値を超過しないよう、余裕を持たせます。

これには、メタコンソールのデータベースで次のクエリを実行します。

ALTER TABLE tgrupo AUTO_INCREMENT = 3000;
ALTER TABLE ttag AUTO_INCREMENT = 3000;
ALTER TABLE talert_templates AUTO_INCREMENT = 3000;
ALTER TABLE talert_actions AUTO_INCREMENT = 3000;
ALTER TABLE talert_commands AUTO_INCREMENT = 3000;
ALTER TABLE tconfig_os AUTO_INCREMENT = 3000;
ALTER TABLE tmodule_group AUTO_INCREMENT = 3000;

メタコンソールではなく、インスタンスで作成される要素数が 3000 を超える可能性があると思われる場合は、より大きい値を設定できます。

大規模環境でメタコンソールのイベントのパフォーマンスを改善するには、データベースに以下のインデックスを追加することをお勧めします。

ALTER TABLE tmetaconsole_agent_secondary_group ADD INDEX id_tagente (id_tagente);

ALTER TABLE tmetaconsole_event ADD INDEX server_id (server_id);}}

レポートスケジューラ


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

データベース保守スクリプト(pandora_db )を起動するには、メタコンソールがインストールされているシステムにサーバのパッケージ(オープンおよび Enterprise 版をイ ンストールする必要があります。 cron で毎時実行するように正しく設定されている必要があります。詳細は、こちら を参照してください。

オンデマンドレポート(電子メールで送信)を使用する場合は、通常の Enterprise コンソールと同じように cron 拡張の実行を設定する必要があります。 通常これは、cronに次 の行を入力し、対応するローカルパスを調整することによって行います。

747 より前のバージョンの場合、パスは /var/www/pandora_console/padora_console.log です。

最後に、電子メールを送信できるように SMTP を構成するには、メール設定セクションの対応するパラメータを編集する必要があります。デフォルトでは次の値が設定されています。

インスタンス

インスタンスでは、メタコンソールからデータにアクセスできるようにするためのパラメータがあります。

メタコンソールからのアクセス設定


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタコンソールは、一つのインスタンスに対して次の 2つの方法でアクセスします。

  • インスタンスに保存されているデータの参照および編集のための データベース へのリモートアクセス
  • 設定ファイルの編集や NetFlow モニタリングなど、いくつかのアクションのための API アクセス

インスタンスでは、メタコンソールからこれら両方のアクセス を許可する設定が必要です。

データベース

メタコンソール内でインスタンスを設定するためには、データベースへのアクセス情報( ホスト、データベース、ユーザおよびパスワード)が必要です。ほかに重要な点は、ユー ザがデータベースへリモート接続できる権限を設定することです。次のように MySQL の GRANT コマンドで実行します。

GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY <UserPass>;

例:

GRANT ALL PRIVILEGES on `PandoraMetaBase.*` to `adminmeta@localhost` IDENTIFIED BY `pandora`;

API

インスタンスの API へのアクセスは、次のパラメータで設定します。

  • ユーザとパスワード: インスタンスのユーザとパスワードが必要です。
  • API パスワード: インスタンスで設定されている API アクセスのためのパスワ ードが必要です。
  • APIアクセスを許可するIPアドレスリスト: インスタンスの設定で、API へのア クセスを許可する IP アドレスのリストがあります。全 IP アドレスやあるサブネットに対してアクセスを許可する場合は、ワイルドカード '*' が使えます。

自動認証


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタコンソールのいくつかの場所では、インスタンスのウェブコンソールへアクセスします。

例えば、イベント表示では、イベントに関連付けされたエージェントをクリックした場合、そのエージェントが属するインスタンスのコンソールの画面へ行きます。

この時、自動認証が使われます。

この認証は、インスタンスの 自動ログインパスワード で設定した ハッシュ 文字列により行われます。

この設定は、メタコンソールでのインスタンスの設定に必須ではありませんが、インスタンスへのリンクをクリックしたときに、自身で認証を行う必要があります。

イベント複製


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

メタコンソール内でインスタンスのイベントを参照できるようにするためには、メタコンソールのデータベースへアクセスできる必要があります。

インスタンスは、最後に複製を実施した日時から次の日時の間のイベントをメタコンソールへ複製します。

イベントの複製に加えて、メタコンソールの自動承諾を実施します。一つのモジュールに関連付けられたイベントにおいて、イベントをメタコンソールに複製するとき、同じモジュールで発生していた以前のイベントをすべて承諾します。

イベントの複製を設定するには、インスタンスの Enterprise 設定で、イベント複製(Event Replication) を有効にします。

次の設定を行います。

  • 間隔(Intervale): メタコンソールにイベントを複製する時間間隔を秒単位で設 定します。

例えば、60秒に設定すると、初回の複製はサーバが起動してから 60秒後に実行されます 。

  • 複製モード(Replication Mode): 全イベントを複製するか、承諾されたもののみを複製するかの設定です。
  • ローカルコンソールでのイベント表示(Show list of events in the local console (only reading)): イベントの複製が有効の場合、イベントの管理はメタコンソール で行われます。インスタンスではイベントへのアクセスができません。このオプションを有効にすると、参照専用でイベント表示にアクセスすることができます。
  • メタコンソールデータベース認証(Metaconsole Database Credentials): ホスト名、データベース名、ユーザ、パスワードおよび、ポート番号(デフォルトのポート番号 は表示されません)。


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

イベントの複製はサーバで実行されます。設定ファイルで次の設定を有効にします。

イベント複製の設定を変更した場合は、サーバを再起動する必要があります。

すでに多くのイベントが発生している新たなノードをメタコンソールに追加する場合は、イベントをメタコンソールへコピーするのに時間がかかります。

指定の日付以降のイベントを対象のメタコンソールに同期したい場合(たとえば、現在の 日付からイベントを複製)は、ノードのあるデータベースで次の SQL を実行します (for versions of Pandora older than 5.1SP3)。

UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"

5.1SP3 より新しいバージョンでは、次のクエリを実行します。

UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";

子ノードで SELinux を有効化しているとイベントの複製は動作しません。無効化してく ださい。

メタコンソールからの自動プロビジョニング


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

Pandora 7から、Enterprise 設定には、メタコンソールのノードフォームに入力するよりも少ない設定でメタコンソールにノードを登録するオプションがあります。

API 経由でメタコンソールに接続できるかどうかを確認したり、ノードがメタコンソールに登録されているかどうかを確認することもできます。

ノードのデータベース、および API に接続するための正しい資格情報を設定します。

初めて設定を行う場合は、API パスワードを入力できます。 更新の場合はノードのパス ワードが使われます。

詳細オプションは、データベースに接続するためにノードに送信される設定です。

メタコンソールの追加設定


Version NG 755 or earlier: you will need to configure the use of the Command Center, where all the relevant information is available.


バージョン NG 755 以前では、コマンドセンターの利用を設定する必要があります。そちらに関連する情報があります。

ノードイベントの複製が有効になっている場合、メタコンソールは自信のデータベースにイベントデータを保存します。メンテナンスのために、これらのデータは削除やメタコンソールのヒストリイベントデータベースへ移すことができます。これは、pandora のインスタンスのように、データベースメンテナンススクリプト /usr/share/pandora_server/util/pandora_db.pl を実行することにより実施します。通常、それを起動するには、サーバのファイルが使われますが、メタコンソールの場合はサーバがありません。そのために、一つのノードから /etc/pandora/pandora_server.conf をコピーし、データベースに関するパラメータ (ホスト名、データベース名、ユーザおよびパスワード) を編集し保存します。以下に例を示します。

/etc/pandora/pandora_meta.conf

/etc/cron.daily/pandora_meta_db というスクリプトを次の内容で作成します。

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_meta.conf

chmod でパーミッションを修正します。

chmod 755 /etc/cron.daily/pandora_meta_db

実行できるようにするためには、Enterprise 版を含む Pandora FMS サーバ(実行はしま せんが)の必要なパッケージをインストールする必要があります。

動作しエラーが出ないことを確認するには、次のように手動で実行してみます。

/etc/cron.daily/pandora_meta_db

メタコンソールとインスタンスの間でメタライセンスを同期する方法の例を見てみます。

最初に、それ自身のキーで正しく認証されたインスタンスがあります。

ノードが正しく認証されたら、ライセンスをのちほど同期するためにメタコンソールでの設定をします。

ここで、メタライセンスをインスタンスと同期するために、メタコンソールライセンスへ行き “認証と同期” を行います。

すると、インスタンスにメタライセンスが登録されます。

There are several permission systems that restrict what an user can see or manage.

ユーザが何を参照・管理できるかを制限するいくつかの権限管理システムがあります。

The ACL system controls which elements an user can see or manage depending on the group they belong to.

ACL システムは、ユーザが所属するグループによってユーザが参照・管理できる要素を制御するシステムです。

For example:

例:

  • A user may have reading permissions on the alert templates of the Application group and those of Administration on the Server group.
  • You will be able to see and assign templates to both groups, but you only have the option to edit or delete those of the Server group.
  • あるユーザは、アプリケーショングループのアラートテンプレートに対して参照権限をもち、サーバグループのそれに対しては管理権限を持つ
  • あなたは、両方のグループに対して割り当てられたテンプレートを参照できるが、サーバグループに対してのみ編集や削除が可能

To find out more about the ACLs, click on this link.

ACL に関する詳細は、こちらを参照してください。

One tag is a label that you may assign to a module.

タグは、モジュールに割り当てることができるラベルです。

An user could have the ACLs of some specific group restricted by Tags. If so, only these ACLs will be applied to the modules that contain those Tags.

ユーザに対して、タグで制限されたいくつかの特定のグループにおいて ACL を設定できます。この場合、タグを含むモジュールに対してのみ ACL を適用できます。

For example:

例:

  • An user may have reading or administration permissions on the Server group restricted to the Systems Tag.
  • It will only have these permissions on the modules, that even belonging to an agent of the Server group, will have the System Tag assigned.
  • ユーザは、Systems タグがついているもに限って、サーバグループに対して参照・管理権限を持つ
  • サーバグループのエージェントで System タグがついているモジュールに対してのみ同様のパーミッションを持つ

To learn more about the tags, click on this link.

タグに関する詳細は、こちらを参照してください。

Users have an access level assigned regarding the Metaconsole Wizard. This level may be Basic or Advanced.

メタコンソールウィザードで、ユーザにアクセスレベルを割り当てられます。このレベルは、基本 または 拡張 です。

Besides, alert templates and module components (local and network) will also have this access level.

アラートテンプレートとモジュールコンポーネント(ローカルおよびネットワーク)もまた、kのアクセスレベルを持ちます。

表示

基本アクセス

Basic access users will only see in the Wizard the alerts corresponding to the alert templates with Basic level and the modules created from Basic level components.

基本アクセス ユーザは、ウィザード内で基本 レベルのアラートテンプレートと基本 レベルのコンポーネントから作成されたモジュールに対応したアラートのみを参照できます。

高度なアクセス

Advanced access level users will see in the Wizard the alerts and modules from both Basic and Advanced levels.

高度な アクセスレベルのユーザは、ウィザード内で基本 および高度 の両方のレベルのアラートとモジュールを参照できます。

設定

Apart from visibility, the access level also affects module configuration and its alerts.

表示に加えて、アクセスレベルは、モジュールの設定とそのアラートにも影響します。

The section Operation (Monitoring Wizard) explains in detail the differences between Basic and Advanced monitor configuration.

操作 (モニタリングウィザード) にて、基本と拡張モニターの設定の違いの詳細を説明します。

The Advanced section contains the Metaconsole administration options, between them:

高度な セクションには、次のメタコンソール管理オプションがあります。

  • The data synchronization between the Metaconsole and the Instances
  • The data management of the Metaconsole
  • The licence management of the Metaconsole
  • The Metasetup where there are:
    • The Instances configuration
    • The Metaconsole configuration options
  • メタコンソールとインスタンスの間のデータ同期
  • メタコンソールのデータ管理
  • メタコンソールのライセンス管理
  • 以下が可能なメタセットアップ
    • インスタンスの設定
    • メタコンソールのオプション設定

In this chapter we are going to talk about the Metasetup and the licence management, in the next chapter we will describe in detail the synchronization and data management of the Metaconsole.

この章では、メタセットアップとライセンス管理について説明します。以下では、メタコンソールの同期とデータ管理の詳細について説明します。

In the Metasetup section, besides all the options of the console configuration, there is a tab for the console Setup.

メタセットアップのセクションでは、コンソール設定の全オプションに加えて、コンソール設定のタブがあります。

In this tab, we will select the instances. All the configuration process is available at the manual section Install and Configure

タブではインスタンスを選択します。すべての設定手順は、インストールと設定にあります。

In the Metasetup section we find tabs with the Metaconsole configuration different options:

メタセットアップのセクションには、違ったオプションのメタコンソール設定のタブがあります。

一般的な設定

In this section we find general data of the Metaconsole, such as the language, the date/hour configuration or customization about some sections, among others.

このセクションには、言語、日時設定、その他設定情報など、メタコンソールの一般的なデータがあります。

It is possible to customize if we want that the Netflow section would be enabled or disabled, the tree view classified by tags, the visual console and the possibility of web checks creation from the Wizard.

Netflow のセクションを有効化、無効化できます。ツリー表示はタグで分類され、ビジュアルコンソールおよびウェブチェックの作成がウィザードからできます。

The parameters that require explanation are:

以下にパラメータの補足をします。

  • Centralized Management: This option allows us to centrally manage policies and events from Metaconsole, without being able to manage them from the nodes.
  • Enable update manager: This option allows us to activate both the “Offline update manager” and the “Online update manager”, which allow us to update the Metaconsole in this configuration.
  • 中央管理(Centralized Management): このオプションで、ノードからではなく、メタコンソールからポリシーおよびイベントを中央管理できます。
  • アップデートマネージャの有効化(Enable update manager): このオプションで、メタコンソール更新のための “オフラインアップデートマネージャ” および “オンラインアップデートマネージャ” の両方を有効化できます。

パスワードポリシー

It is possible to set a password policy with limitations in the password number of characters, expiration, temporary blocking of one user. To know more about the password policy go to the manual section Password policy

パスワードの文字数、有効期限、一時的なユーザのブロックなどの、パスワードポリシーを設定することができます。パスワードポリシーの詳細については、パスワードポリシーを参照してください。

認証

To know more about the authentication go to the manual section Authentication.

認証に関しての詳細は、認証 を参照してください。

表示設定

All configuration related to the data representation. Colors and graph resolution, number of items in the view pagination,etc.You can see more information about the visual configuration in this link.

データ表示に関する全設定です。色とグラフの解像度、ページのアイテム数などがあります。表示設定の詳細は、こちら を参照してください。

パフォーマンス

Visualization options, historic, event purging and maximum size of blocks in the data migration.

表示オプション、履歴、イベント削除および、データマイグレーションの最大ブロックサイズ設定ができます。

ファイル管理

File manager where it is possible to upload and delete the files from the images folder from the Metaconsole installation.

ファイルマネージャでは、メタコンソールの画像フォルダのファイルのアップロードおよび削除ができます。

The Metaconsole code re-uses some images from the normal console code. These images will be not accessible form this manager and it will be necessary to get to the installation manually to manage them.

メタコンソールでは、通常のコンソールと同じ画像を再利用しています。これらの画像は、このマネージャからはアクセスできません。それらを変更するには、手動でインストールする必要があります。

文字列翻訳

With the string translation feature it is possible to customize translations.

文字列翻訳機能では、翻訳のカスタマイズが可能です。

We do a search of the string in the language that we want to customize. The original string will be shown, the translation to that language and a third column to writte the customized translation.

カスタマイズしたい言語の文字列を検索します。オリジナルの文字列が表示されます。対象の言語のカスタム翻訳文字列を 3番目のカラムに書きます。

Email

Con la utilidad de mail podemos personalizar el envio de mails desde la metaconsola, donde deberemos de configurar la cuenta de mail con la que queremos enviar, por ejemplo, los informes generados.

メールユーティリティでは、メタコンソールからのメール送信をカスタマイズできます。ここでは、例えば生成したレポートなどの送信時のメールアカウントを設定する必要があります。

アップデートマネージャオプション

En esta sección podemos modificar las opciones que se van a usar para el Update Manager. Por defecto viene ya configurado para poder realizar la actualización online. Esta sección solo será visible si tenemos activado el “Enable update manager”.

ここでは、アップデートマネージャで利用するオプションを編集することができます。デフォルトでは、オンラインで更新するように設定されています。このセクションは、“アップデートマネージャの有効化” が有効になっている場合のみ表示されます。

オフラインアップデートマネージャ

En esta sección podremos actualizar la metaconsola sin necesidad de conectarnos a ningún otro lugar. Solo tendremos que subir los ficheros “rpm” en orden hasta la versión que queremos actualizar, dado que no son versiones acumulativas. Esta sección solo será visible si tenemos activado el “Enable update manager”.

ここでは、外部へのネットワーク接続無しにメタコンソールを更新することができます。差分更新ではないため、更新するには、更新したいバージョンの “rpm” ファイルをアップロードするだけです。このセクションは、“アップデートマネージャの有効化” が有効になっている場合のみ表示されます。

オンラインアップデートマネージャ

En esta sección podremos actualizar la metaconsola de manera automática, solo tendremos que poseer una licencia válida de metaconsola y acceso a internet. Esta sección solo será visible si tenemos activado el “Enable update manager”.

ここでは、メタコンソールを自動で更新することができます。必要なのは、正しいメタコンソールのライセンスとインターネット接続のみです。このセクションは、“アップデートマネージャの有効化” が有効になっている場合のみ表示されます。

The Metaconsole has tools for the synchronization of elements, which are fundamental for the correct management of the Instances. The synchronization is based on passing all the information created in the metaconsole to the different Instances to manage all possible information of each of them from the Metaconsole.

メタコンソール には、要素を同期するツール があります。これは、インスタンスの正しい管理のために基本的なものです。同期の基本は、メタコンソールで作成されたすべての情報を、メタコンソールから管理できるようにするために異なるインスタンスへ渡すことです。

For example, if we have 20 different instances(nodes) in our company, and we want the same user to have the same access permissions in those 20, we can create a user with the desired profiles and synchronize that user to have it in the 20 instances(nodes) and thus not have to create it individually in each instance.

例えば、会社に 20の異なるインスタンス(ノード)があり、これらに同じユーザで同じ権限でアクセスしたい場合、希望のプロファイルを有するユーザを作成し、そのユーザを 20のインスタンス(ノード)へ同期させることができます。各インスタンスにおいて個別にユーザを作成する必要はありません。

Another example, we have to monitor different clients that are distributed throughout our instances, so that some clients are also repeated in different instances. We will be able to create the different groups to which the agents of the different instances will belong, and then synchronize each corresponding group with its instance.

別の例をあげると、インスタンス全体に分散されている異なるクライアントを監視しなければならない場合、いくつかのクライアントは、異なるインスタンスで監視されます。異なるインスタンスのエージェントが属する異なるグループを作成し、それぞれの対応するグループをインスタンスと同期させることができます。

Next, we are going to see in detail the different synchronizations that the Metaconsole allows us to make.

以下に、メタコンソールで可能な異なる同期の詳細を説明します。

This option allows the user to synchronize the users of the Metaconsole and their profiles in the instances.

このオプションでは、メタコンソールユーザおよびプロファイルをインスタンスに同期することができます。

Within this synchronization we can find two different options:

この同期には、次の 2つのオプションがあります。

  • Copy the configured profiles to the user
  • ユーザへの設定されたプロファイルのコピー

  • Give new profiles to the created user
  • 作成したユーザへの新たなプロファイルの設定

In both cases we have the option to create the groups associated to the profiles in case they do not exist in the instance(node).

いずれの場合も、プロファイルに関連付けられたグループを、インスタンス(ノード)に存在しない場合に備えて作成することができます。

Before using this synchronization, it is recommended to take into account the users that are going to create new ones in the instances, due to possible conflicts with the user ID. It is recommended not to have users created in the instances and to create them all from the meta console in order to have the same users both in there as in the instances.

この同期を利用する前に、ユーザ ID の競合の可能性を考慮し、インスタンス内で作成する新規ユーザについては注意する必要があります。インスタンスに同じユーザを持つには、インスタンス内でユーザを作成するのではなく、メタコンソールから作成することをお勧めします。

In both cases, profiles that do not exist in the instance will be created.

両方の場合において、インスタンスに存在しないプロファイルは作成されます。

When in doubt about which option is best to use, user profiles must be copied.

どちらのオプションを使うべきか良くわからない場合は、ユーザプロファイルのコピー を利用すると良いでしょう。

This option allows the user to synchronize the Metaconsole groups with the instances.

このオプションでは、メタコンソールのグループをインスタンスに同期できます。

It is recommended not to have groups created in the instances and to create them all from the meta console in order to have the same groups both in there and in the instances.

複数のインスタンスで同じグループを持つ場合は、個々のインスタンスでグループを作成するのではなく、メタコンソールから作成することをお勧めします。

Once the groups have been synchronized, their names should not be modified either in the meta console or in the node. If it is done, it will be necessary to modify them in both places so that it does not give problems since the synchronization is based on the ID, but some operations use the name. The synchronization in the current version synchronizes the name the first time, but if there are later changes of names in the groups they will not be synchronized.

初回のグループ同期がされるとグループ名は編集できません。編集したり削除したりすると、同じ変更をノードにする必要があります。グループ同期はグループ ID をベースに行われます。ノードとメタコンソール間の初回の同期では、グループ名が同期されます。しかし、以降の同期では、グループ名は同期されません。

This option allows the user to synchronize the Metaconsole alerts with the instances.

このオプションでは、メタコンソールのアラートをインスタンスに同期できます。

It is recommended not to have alerts created in the instances and to create them all from the console in order to have the same alerts both in there and in the instances.

全体で同一のアラートを設定したい場合は、インスタンスでアラートを作成するのではなく、メタコンソールで作成することをお勧めします。

This option allows the user to synchronize the components of the Metaconsole with the instances.

このオプションでは、メタコンソールのコンポーネントをインスタンスに同期できます。

It is recommended not to have components created in the instances and to create them all from the Metaconsole in order to have the same components both in there and in the instances.

全体を通して同じコンポーネントを設定したい場合は、インスタンスでコンポーネントを作成するのではなく、メタコンソールで作成することをお勧めします。

This option allows the user to synchronize the tags of the Metaconsole with the instances.

このオプションでは、メタコンソールのタグをインスタンスに同期できます。

It is recommended not to have tags created in the instances and to create them all from the Metaconsole in order to have the same tags both in there and in the instances.

全体を通して同じタグを利用する場合は、インスタンスでタグを作成するのではなく、メタコンソールで作成することをお勧めします。

This option allows the user to synchronize the OS of the Metaconsole with the instances.

このオプションは、メタコンソール上の OS をインスタンスに同期することができます。

It is recommended not to have OS created in the instances and to create them all from the Metaconsole in order to have the same OS both in there and in the instances.

全体を通して同じ OS を設定したい場合は、インスタンスで OS を作成するのではなく、メタコンソールで作成することをお勧めします。

This option allows the user to synchronize the module groups operating in the Metaconsole with the instances.

このオプションは、メタコンソール上のモジュールグループをインスタンスに同期することができます。

It is recommended not to have the groups of modules created in the instances and to create them all from the Metaconsole in order to have the same groups of modules both in there and in the instances.

全体を通して同じモジュールグループを使いたい場合は、インスタンスでモジュールグループを作成するのではなく、メタコンソールで作成することをお勧めします。

The MetaConsole has tools for the propagation of elements. Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole, it only facilitates the availability of data in the Instances, something that is necessary if, for example, we use policies that are applied in different instances (or nodes).

メタコンソールには、要素を伝播させるためのツールがあります。同期とは異なり、メタコンソールを最適に機能させるための基本的なツールではなく、インスタンス内のデータの可用性を上げるためのものです。例えば、異なるインスタンス(またはノード)に適用されるポリシーを使用する場合などです。

It is recommended to synchronize the instances with the meta console after the creation of the different elements in the propagation tool.

伝播ツールでさまざまな要素を作成した後は、インスタンスをメタコンソールと同期させることをお勧めします。

Next, we are going to see in detail the different propagations or data management that allows us to make the meta console.

以下では、メタコンソールで可能な異なる伝播やデータ管理の詳細を示します。

The following actions can be performed in this section:

ユーザ管理セクションでは、次の操作ができます。

  • User management
  • Profile management
  • Edit my user
  • ユーザ管理
  • プロファイル管理
  • 自身のユーザ編集

For example, we have 10 instances inside our meta console, where we want a user with special permissions to operate inside 3 of them. First, we would go to profile management where we would create a special profile with the permissions we want. Then we create the user we want to manage the three instances, assigning the permission we have created to it. Finally, we will synchronize this user and profiles with the instances to have it in all three. After a while the user has become obsolete, but instead of deleting the user we deactivate it in case we want to use it again in the future, we go to user management and use the bulb icon to deactivate it until further notice.

たとえば、メタコンソール配下に 10個のインスタンスがあり、うち 3つには特別な権限を持つユーザを用意したいとします。 まず、必要な権限を持つ特別なプロファイルを作成するために、プロファイル管理に行きます。 次に、3つのインスタンスを管理するユーザを作成し、作成したアクセス許可を割り当てます。 最後に、このユーザとプロファイルをインスタンスと同期させて、3つすべてのインスタンスがこれらを持つようにします。 しばらくすると、ユーザは利用されなくなってしまいましたが、将来利用したい場合に備えてユーザを削除するのではなく、ユーザ管理に行き、電球アイコンを使用して後で必要になるまでは無効にします。

ユーザ管理

In this section we can see the list of users already created, modify their configuration, delete them, deactivate them or create new users.

このセクションでは、すでに作成済みのユーザ一覧の参照、設定変更、削除、無効化、新規ユーザの作成ができます。

新規ユーザの作成

To add a user click on the “Create User” button, where we will see the following form which must be filled:

ユーザを追加するには、“ユーザの作成(Create user)” ボタンをクリックします。 次のようなフォームが表示されるので入力します。

The parameters that require explanation are:

パラメータの説明を以下に示します。

  • Interactive charts: It allows the user to choose if they prefer to see the interactive graphics, or on the contrary, to use the general configuration of the Metaconsole.
  • Metaconsole access: It sets the user permissions to access the console. These permissions can be:
    • *Basic: With this access the user will be able to use in the Wizard only the components whose Wizard level is Basic, as long as the user has ACL permissions on the group they belong to. * *Advanced: With this access the user will be able to use any of the components in the Wizard regardless of their Wizard level, as long as the user has ACL permissions on the group they belong to.
  • 動的グラフ(Interactive charts): ユーザが動的なグラフを見るかまたは、メタコンソールの設定に従うかを設定します。
  • メタコンソールアクセス(Metaconsole access): ユーザがメタコンソールへアクセスできるかを設定します。次のオプションがあります。
    • 基本(Basic): これを選択すると、ユーザは所属するグループの ACL 内で、ウィザードでレベルが 基本 のコンポーネントのみを利用できます。
    • 拡張(Advanced): これを選択すると、ユーザはウィザードレベルにかかわらず、ウィザードで任意のコンポーネントを利用できます。所属するグループの ACL で制限されます。
  • Search custom field view: Seleccionamos el filtro por defecto para la vista de “Campos personalizados”
  • Not Login: If this option os selected, the user will be able to access the API.
  • Enable agents management: This option is used to enable the agent management in the Wizard. If it is deactivated, only the Wizards of modules and alerts will be available.
  • Enable node access: This option is used to enable access to the instances. If it is activated, it will be possible to access the consoles of the instances through the name of agents and modules in many places; for example, from the network map or the events view.
  • カスタムフィールド表示検索(Search custum field view): カスタムフィールドのデフォルトフィルタを選択します。
  • ログイン無し(Not Login): このオプションを選択すると、ユーザは API にアクセスできます。
  • エージェント管理を有効にする(Enable agents management): このオプションは、ウィザードでエージェント管理を有効にします。無効の場合、モジュールとアラートのウィザードのみ利用できます。
  • ノードアクセスを有効にする(Enable node access): このオプションは、インスタンスへのアクセスを有効にします。有効にした場合、インスタンスのコンソール上のエージェントおよびモジュール名でアクセスできます。例えば、ネットワークマップやイベント表示で使えます。
ユーザの編集/無効化/削除

In the user list the following options are available:

ユーザ覧では、次のオプションがあります。

  • Activate/Deactivate the user
  • Edit the user
  • Delete the user form the Metaconsole
  • Delete the user form the Metaconsole and all Instances
  • ユーザの有効化/無効化
  • ユーザの編集
  • メタコンソールからユーザを削除
  • メタコンソールおよび全インスタンスからユーザを削除

A user's editing form is the same as the creation form, but including the profile editor.

ユーザの編集フォームは、作成フォームと同じですが、プロファイルエディタを含みます。

In the profile editor the user can be assigned profiles in certain groups besides limiting those privileges to the selected Tags. If Tags are not selected, the user will have access to all modules, whether they have associated Tags or not.

プロファイルエディタでは、特定のグループのプロファイルをユーザに割り当てることができます。加えて、選択したタグで権限を制限することができます。タグが選択されていない場合は、タグに関連付けられているかどうかにかかわらずユーザはすべてのモジュールにアクセスすることができます。

プロファイル管理

In this section we can see the list of profiles already created, modify their configuration, delete them or create new profiles.

このセクションでは、作成済みのプロファイル一覧の参照、設定の編集、削除、新たなプロファイルの作成ができます。

There are a series of ACL flags that will give access to the different Pandora FMS functionalities. To know which function enables each ACL flag of the profiles, visit section Perfiles en Pandora FMS in the user manual.

さまざまな Pandora FMS 機能にアクセスできる一連の ACL フラグがあります。どの機能がどのプロファイルの ACL で有効になるかは、Pandora FMS のプロファイル を参照してください。

新規プロファイル作成

To add a profile click on the “Create” button to see the following form, where we must fill in those permissions that we want to give with the new profile:

プロファイルを追加するには “作成(Create)” ボタンをクリックし、次のフォームを開きます。ここでは、プロファイルに設定したい権限を設定します。

Some of these bits don't make sense in the Metaconsole. However, we may want to use the Metaconsole to synchronize profiles to Instances, where they could be useful.

これらの設定のうちの一部は、メタコンソールでは意味をなさないものがあります。 ただし、メタコンソールを使用してプロファイルをインスタンスに同期させた場合には有効です。

プロファイルの編集/削除

In the list of profiles you have options to:

プロファイルの一覧には次のオプションがあります。

  • Edit the profile
  • Delete a profile from Metaconsole
  • プロファイルの編集
  • メタコンソールからのプロファイルの削除

自身のユーザの編集

In this section we can configure the user who is authenticated in the Metaconsole. The profiles assigned to the user will be merely informative. If the authenticated user is not an administrator, this will be the only section you can see.

このセクションでは、メタコンソールで認証されるユーザデータを編集できます。画面にキャラクターとともにユーザに割り当てられたプロファイルが表示されます。ユーザが管理者ではない場合は、これが唯一の参照可能なセクションです。

The following actions can be performed in this section:

ここでは、次の操作ができます。

  • Migration of agents between instances
  • Self-provisioning of agents
  • Group management
  • インスタンス間のエージェント移動
  • エージェントの自己プロビジョニング
  • グループ管理

For example, we are planning to manage 15 instances in the metaconsole, and we want the distribution of the agents to be organized according to the load of each instance, creating the agents so that they are always generated in the instance with the lowest load. To do this, we will go to auto-provisioning and activate the option indicated for it. Once done, if for example, we realize that certain agents should go together in the same instance, we will go to the migration of agents between instances, where we will choose which agents move to which other instances so that we don't have to delete and create the agents manually.

たとえば、メタコンソールでは 15個のインスタンスを管理する予定であり、各インスタンスの負荷に応じてエージェントを分散する構成をし、負荷が最も低いインスタンスで常にエージェントを作成したいとします。これを行うには、自動プロビジョニングに行き、オプションを有効化します。 たとえば、特定のエージェントに関しては同一のインスタンスで設定したい場合は、インスタンス間でエージェントを移動できます。ここでは、どのエージェントを他のインスタンスに移動するかを選択します。エージェントを手動で削除して作成する必要はありません。

エージェントの移動

This feature requires a running Metaconsole server to work.

この機能を利用するには、メタコンソールサーバが動作している必要があります。

In this section we can migrate agents between the instances connected to our Metaconsole.

ここでは、メタコンソールに接続したインスタンス間でエージェントを移動できます。

In order for the historical data of the agents to be transferred, the “Discard history data” checkbox must be activated. Once we have everything selected and we press the “move” button, it will start to perform the following checks to be able to perform the migration.

エージェントの履歴データを転送するには、“履歴データを破棄する” チェックボックスをチェックする必要があります。 移動対象すべてを選択して “移動” ボタンを押すと、移動できるようにするための以下のチェックを実行します。

The agents do not exist in the destination server

移動先サーバにエージェントが存在しない

There must not exist any agent to migrate with the same agent name in the target server.

移動するエージェントと同じ名前のエージェントが移動先にあってはいけません。

The necessary collections are synchronized with the destination server

移動先サーバとコレクションが同期されている必要があります

To prevent the agent from attempting to download non-existent collections once migrated, verify that the collections exist on both servers (source and destination).

移動後、エージェントが存在しないコレクションをダウンロードするのを防ぐために、両方のサーバ(移動元と移動先)にコレクションが存在するか確認します。

The necessary alert definitions are synchronized with the target server

移動先サーバとアラート定義が同期されている必要があります

Verify that the templates, actions and commands defined on the source server are also defined on the target server. The relations are made through ID, so these values must also be identical.

移動元サーバのテンプレート、アクション、コマンドが、移動先サーバでも定義されていることを確認します。関係性は ID を通して設定されるため、これらも合っている必要があります。

The configuration files of the software agents associated to the agents do not exist in the target server

ソフトウエアエージェントに関連づけられる設定ファイルが対象サーバに存在しない

There must not be configuration files with the same name as those associated to the agents that we are going to migrate in the target server. If so, we must remove them from the destination server.

エージェントに関連づけられた同じファイル名の設定ファイルが移動先サーバに存在してはいけません。もし存在する場合は、移動先サーバから削除する必要があります。

Both servers have the same version

両方のサーバは同じバージョン

Verify that Pandora FMS versions are identical in both servers.

Pandora FMS のバージョンが両方のサーバで同じかどうかを確認します。

The address of the destination server is configured

移動先サーバのアドレスが設定されている

Verify that the IP address of your destination server (Dataserver) is configured, you can access the following screen through <i>Servers > Manage servers</i> of the instance to which we want to move the agents:

移動先サーバ(データサーバ)の IP アドレスが設定されていることを確認します。<i>サーバ(Servers) > サーバ管理(Manage servers)</i> を通して、エージェントを移動させたい先のインスタンスの次の画面にアクセスすることができます。

The necessary policies are synchronized with the target server

移動先サーバとポリシーが同期されている必要があります

Verify that the source server policies are available on the target server. All relations are made through ID, so these values must also be identical.

移動元サーバのポリシーが移動先サーバにも存在することを確認します。すべての関係性は ID を通して設定されているため、この値も同じでなければいけません。

The groups are synchronized with the destination server

移動先サーバとグループが同期されている必要があります

Verify that the groups of the source server are defined in the destination server. All relations are made through ID, so these values must also be identical.

移動元サーバのグループが移動先サーバにも存在することを確認します。すべての関係性は ID を通して設定されているため、この値も同じでなければいけません。

The remote plugins are synchronized with the destination server

移動先サーバとプラグインが同期されている必要があります

Verify that the server plugins are defined in the destination server. All relations are made through ID, so these values must also be identical.

移動元サーバのプラグインが移動先サーバにも存在することを確認します。すべての関係性は ID を通して設定されているため、この値も同じでなければいけません。

Inventory plugins are synchronized with the target server

移動先サーバとインベントリプラグインが同期されている必要があります

Verify that the inventory plugins are defined on the target server. All relations are made through ID, so these values must also be identical.

移動元サーバのインベントリプラグインが移動先サーバにも存在することを確認します。すべての関係性は ID を通して設定されているため、この値も同じでなければいけません。

Once all the checks are done, click on the “Next” button to continue with the migration, where a table with the status of the migration will appear.

すべての確認が完了したら、移動を続けるために “次(Next)” ボタンをクリックします。ここで、移動状態の表が表示されます。

In order to avoid blocking the work queue, the agent to be transferred will always be processed with lower priority, this avoids the system being blocked by transferring an agent with a lot of data, giving priority to the migration of the agent over the migration of the data.

処理のキューがブロックされるのを防ぐために、エージェント移動は常に低い優先順位で処理されます。これにより、大量のデータをもつエージェントの移動によりシステムがブロックされるのを防ぎます。エージェントの移動は、データの移動より優先されます。

In order to optimize the process the original agent will be deactivated and the automatic disable mode will be established. By default, this configuration will eliminate the original agent in 30 days.

処理の最適化のために、オリジナルのエージェントは自動的に無効化されます。デフォルトでは、オリジナルのエージェントは、30日で削除 されます。

Defined prediction modules may lose functionality once the agent is migrated. Review definitions after migration.

エージェントが移動されると、予測モジュールは機能しなくなります。移動後に設定を確認してください。

エージェント自動プロビジョニング

When we deploy Pandora in big and complex environments with many Pandora nodes and Metaconsole environment, we find the problem of deciding how to deploy the agents: which server is assigned to them? how to balance the workload?

Pandora のノードとメタコンソールを用いて、大規模かつ複雑な環境に Pandora FMS を展開する場合、どのサーバにどのエージェントを割り当てて展開するか、負荷分散をどうするか、グループをどう割り当てるかを決めることが問題になります。

For this, the concept of agents auto-provisioning appears, which allows assigning an agent to one of the multiple Pandora servers that we have in our infrastructure.

この目的に対して、エージェントの自動プロビジョニングは、インフラ内にある複数の Pandora サーバのどれにエージェントを割り当てるかを決定することができます。

This feature requires a Metaconsole server with a Provisioning Server running in order to work.

この機能を利用するためには、メタコンソールサーバと ProvisioningServer が起動している必要があります。

This functionality is used to manage the assignment initial of the agents to a given server. When you install your agents for the first time, select the IP address of the Metaconsole as server_ip.

この機能は、特定のサーバへ初期 のエージェントの割り当て管理をするために使用されます。エージェントを初めてインストールするときは、メタコンソールの IP アドレスを<i>server_ip</i>として利用します。

To be able to use this feature we will have to configure the server and the Metaconsole.

この機能を利用できるようにするには、サーバとメタコンソールを設定する必要があります。

サーバの設定

For the autoprovisioning system to work we must enable the ProvisioningServer at /etc/pandora/pandora_server.conf:

自動プロビジョニングシステムが動作するためには、/etc/pandora/pandora_server.conf にて ProvisioningServer を有効化する必要があります。

 # Enables auto provisioning service
 provisioningserver 1

Verify that the IP address of your destination servers (Dataserver) is configured in each node. You can access the following screen through <i>Servers > Manage servers </i>

それぞれのノードで、対象サーバ(データサーバ)の IP アドレスが設定されているかを確認してください。<i>サーバ → サーバ管理</i> から次のような画面にアクセスできます。

コンソールの設定

In this section we can choose between three different types of autoprovisioning, activating the one we want by means of a switch:

ここでは、3種類の自動プロビジョニングを選択することができます。必要なものを有効化します。

Round Robin

ラウンドロビン(Round Robin)

It uses the Round-robin planning method to distribute, in an equitable way and in a rational order, all the new Pandora software agents that reach the Metaconsole. The distribution of the agents will be done in a circular way, assigning the corresponding server to each new agent.

ラウンドロビンで、メタコンソールに接続してきたすべての新しい Pandora ソフトウェアエージェントを公平かつ合理的な順序で配布します。エージェントの配布は循環的に行われ、それぞれの新しいエージェントに対応するサーバが割り当てられます。

Less Loaded

最小負荷(Less Loaded)

The new agents will be dynamically assigned to those servers with less load.

新しいエージェントは、負荷の少ないサーバーに動的に割り当てられます。

Custom

カスタム(Custom)

In the customized classification, we will be able to define our own classification rules, based on certain parameters retrieved from the information reported by the agent (name of the agent and its IP address).

カスタム分類では、エージェントによって報告された情報(エージェント名と IPアドレス)から取得された特定のパラメータに基づいて、独自の分類ルールを定義できます。

If we choose the Custom option, we will click on the “Create a custom entry” button where the following form will appear:

カスタムを選択した場合、“カスタムエントリの作成(Create a custom entory)” ボタンをクリックします。次のようなフォームが表示されます。

In the configuration section we will have to put the content that will be added to the configuration file. It is a way of customization that will be used to classify the agents; an example would be:

設定画面で、設定ファイルに追加する内容を入力します。エージェントを分類するのに使われるカスタマイズの方法です。以下に例を示します。

 # Text contained here will be validated and inserted in the agent configuration
 server_ip 192.168.80.164

Once created we will have to introduce the rules that we want the agents to comply with by hitting the “add” button.

設定したら、“追加(add)” ボタンをクリックすることにより、エージェントにルールが適用されます。

We will be able to specify the matching conditions in the form of rules using the following fields:

次のフィールドを用いて、ルールのフォームにマッチング条件を指定することができます。

  • agent alias
  • agent address
  • エージェントの別名
  • エージェントのアドレス

We will be able to specify the operations using the following fields:

次のフィールドを用いて、オペレーションを指定することができます。

  • OR
  • AND

自動設定

In this section you can edit the autoconfigurations of the agents in a centralized way from the Metaconsole. In order to make this edition, we must have activated the “Centralized management”.

ここでは、メタコンソールから集中的にエージェントの自動設定を編集することができます。編集を行うためには、“中央管理(Centralized management)” を有効化する必要があります。

For more information, visit this link.

より詳細は、こちらを参照してください。

グループ管理

In this section we can manage, delete and create new groups in the Metaconsole.

ここでは、メタコンソールでのグループの管理、削除、新規作成ができます。

グループの作成

To create a new group, click on the “create group” button and the following form will appear:

新たなグループを作成するには、“グループの作成(create group)” ボタンをクリックします。すると、次のようなフォームが表示されます。

The parameters that require explanation are:

以下にパラメータの説明を補足します。

  • Parent: combo where another group can be defined as the parent of the group being created.
  • Propagate ACL: allows ACLs to be propagated to child subgroups..
  • Custom ID:the groups have an ID in the Database. In this field it is possible to put another custom ID that can be used from an external program to perform an integration.
  • 親(Parent): ここで、作成したグループの親グループを定義することができます。
  • AL の伝播(Propagate ACL): 子グループへ ACL を伝播します。
  • カスタム ID(Custom ID): データベース上にグループが持つ ID です。このフィールドにカスタム ID を設定することができ、外部プログラムとの連携をする場合に利用できます。
グループの編集/削除

In the list of groups there are options for:

グループ一覧には、以下のオプションがあります。

  • Editing the group
  • Deleting the Metaconsole group
  • グループの編集
  • メタコンソールグループの削除

ツリーグループ

In this section we can perform exactly the same actions as in the previous section, changing the display mode:

ここでは、表示モードを変更して前述の画面と同じ操作が行えます。

コレクション

From Pandora FMS OUM729 you can centralize the management of collections from the Metaconsole.

Pandora FMS OUM729 以降では、メタコンソールからコレクションの中央管理ができます。

The first time you access collection management, with centralized management enabled , an internal process of synchronization of the collections from the nodes to the Metaconsole will be performed:

集中管理が有効になっている 状態でコレクション管理に初めてアクセスすると、ノードからメタコンソールへのコレクションの同期プロセスが実行されます。

From this moment on, you will have the collections in the Metaconsole. To avoid conflicts, you must manually copy the collection directories from the nodes to the Metaconsole:

この時点から、メタコンソールにコレクションを持つようになります。競合を避けるには、コレクションディレクトリをノードからメタコンソールへ手動でコピーします。

Source location (node):

コピー元(ノード):

/var/www/html/pandora_console/attachment/collection/

Destination location (Metaconsole):

コピー先(メタコンソール):

/var/www/html/pandora_console/attachment/collection/

Note: Remember to assign the correct permissions to the transferred files:

注意: 転送したファイルに正しいパーミッションを設定することを忘れないようにしてください。

chmod apache. -R  /var/www/html/pandora_console/attachment/collection/*

Once the files are transferred, you can recreate the collection to force synchronization to nodes.

ファイルを転送したら、強制的にノードへ同期するためにコレクションを再作成できます。

For more information about the collections, please visit this link.

より詳細は、こちらを参照してください。

The following actions can be performed in this section:

ここでは、次の操作ができます。

  • Component Group Management
  • Local component management
  • Network Component Management
  • Plugin management
  • コンポーネントグループ管理
  • ローカルコンポーネント管理
  • ネットワークコンポーネント管理
  • プラグイン管理

Before we start, let's explain what a component is: it is a “generic module” that can be applied repeatedly on an agent, being a kind of “master copy” of a module. This is very useful to monitor new agents with the components stored in the database.

まずはじめにコンポーネントは何かを説明します。コンポーネントとは “一般的なモジュール” で、エージェントに繰り返し適用することができるもので、モジュールの “テンプレート” のようなものです。定義されたコンポーネントを使うと、新たなエージェントを監視するのがとても便利です。

For example, we have 12 instances where we want to create the same type of modules in each: we want to create 10 local modules, 5 network modules and 3 custom plugins. Thanks to the management in the Metaconsole we will be able to create these components, each one in its section, and then synchronize them to have them in the different instances without having to manually create them.

例えば、インスタンスが 12個あり、それぞれで同じタイプのモジュールを作成したいとします。ここで、ローカルモジュール 10個、ネットワークモジュール 5個、カスタムプラグイン 3個を作成します。メタコンソールの管理により、これらのコンポーネントを作成し、各インスタンスで個別に手動で作成することなく、各インスタンスへ同期することができます。

コンポーネントグループ管理

In this section we can delete and create new groups of components.

ここでは、コンポーネントグループの削除、新規作成ができます。

グループ作成

To create a new group click on the “Create” button.

新たなグループを作成するには、“作成(Create)” ボタンをクリックします。

グループ削除

ローカルコンポーネント管理

In this section we can delete, duplicate and create new local components. A local component is the elaboration of a module defined in the configuration of software agents, structured as “pieces” of text that can be cut and pasted in the configuration of agents.

ここでは、ローカルコンポーネントの削除、複製、新規作成ができます。ローカルコンポーネントは、ソフトウェアエージェントに設定するモジュールの定義であり、エージェントの設定にカットアンドペーストできるテキストの「部品」として構成されます。

ローカルコンポーネント作成

In order to create a local component click on the “Create” button where the following form will appear:

ローカルコンポーネントを作成するには、“作成(Create)” ボタンをクリックします。次のようなフォームが表示されます。

In order to see in detail more information about the parameters for the creation of a new local component you can visit Create user.

新たなローカルコンポーネント作成のためのパラメータ詳細は、新たなローカルコンポーネントの作成 を参照してください。

ローカルコンポーネントの複製/削除

In the list of local components you have options for:

ローカルコンポーネント一覧には、次のオプションがあります。

  • Duplicating a local component
  • Deleting a local component of the Meta Console
  • ローカルコンポーネントの複製
  • メタコンソールのローカルコンポーネントの削除

ネットワークコンポーネント管理

In this section we can delete, duplicate and create new network components. A network component groups all remote modules (wmi, tcp, snmp, icmp, plugin, web, etc).

ここでは、ネットワークコンポーネントの削除、複製、新規作成ができます。ネットワークコンポーネントは、すべてリモートモジュールです(wmi, tcp, snmp, icmp, プラグイン, web など)。

ネットワークコンポーネントの作成

There are three types of network components that can be created:

作成可能なネットワークコンポーネントは次の 3タイプあります。

  • Network
  • Plugin
  • WMI
  • ネットワーク
  • プラグイン
  • WMI

To create a new network component in the drop-down menu select a network component from the three possible (WMI, Network or Plugin): and click on the button Create. Next, we will see a screen to create a network component.

新たにネットワークコンポーネントを作成するには、ドロップダウンメニューで 3つのネットワークコンポーネント(WMI, ネットワーク、プラグイン)のいずれかを選択します。そして、作成(Create) ボタンをクリックします。すると、ネットワークコンポーネントの作成画面が表示されます。

To see in detail more information about the parameters of creation of a new network component you can visit the section Network component.

ネットワークコンポーネントの作成パラメータに関する詳細は、新たなネットワークコンポーネントの作成 を参照してください。

ネットワークコンポーネントの複製/削除

In the list of network components you have options for:

ネットワークコンポーネント一覧には、次のオプションがあります。

  • Duplicating a network component
  • Deleting a network component from the Metaconsole
  • ネットワークコンポーネントの複製
  • メタコンソールからネットワークコンポーネントの削除

プラグイン管理

In this section we will be able to delete, modify and create new plugins that will use plugin type network components.

ここでは、プラグインタイプのネットワークコンポーネントで利用する、プラグインの削除、編集、新規作成ができます。

プラグインの作成

To create a plugin click on the “Add” button and the following form will appear:

プラグインを作成するには、“追加(Add)” ボタンをクリックします。次のフォームが表示されます。

The parameters that require explanation are:

以下にパラメータの補足説明をします。

  • Plug-in command: Where we will put the PATH to where the plugin is located
  • Plug-in parameters: Where we will put the parameters that we must write so that the plugin works correctly.
  • プラグインコマンド(Plug-in command): プラグインを置いた場所のパスを入力します
  • プラグインパラメータ(Plug-in parameters): プラグインが正しく動作するために必要なパラメータを入力します

プラグインの編集/削除

In the plugin list there are options for:

プラグイン一覧では、次のオプションがあります。

  • Modifying a plugin
  • Deleting a plugin from the Metaconsole
  • プラグインの編集
  • メタコンソールからのプラグインの削除

Certain plugins have a padlock in front of the Modify option, because these plugins cannot be modified or deleted.

特定のプラグインには修正オプションの前に鍵マークがあります。これらのプラグインは変更または削除できないためです。

The following actions can be performed in this section:

ここでは、次の操作ができます。

  • Management of commands
  • Management of shares
  • Management of templates
  • コマンドの管理
  • 共有の管理
  • テンプレートの管理

For example, in our meta console we have 5 instances with different clients and in all of them we need to measure in each agent the temperature of its CPU. With this information, we need an alert to be triggered when the CPU exceeds a certain temperature, and what we want is to create a command that will make the CPU eliminate certain services so as not to be used in an excessive way, causing it to rise in temperature. We would generate an alert that carries out this command and then synchronize it with all our instances so that we don't have to do it manually one by one.

たとえば、メタコンソール配下に異なる監視対象を持つ 5つのインスタンスがあり、すべてのエージェントで CPU の温度を測定したいとします。CPU が特定の温度を超えたときに警告を出し、CPU の過剰な利用で温度が上がらないように、特定のサービスを停止するコマンドを作成したいとします。コマンドを実行するアラートを作成し、すべてのインスタンスと同期させれば、手動で一つずつ行う必要はありません。

In this section we will only talk about the management of templates, in particular, the differences with the management of alerts of the instances. To know more about its operation and configuration you can consult the Alert System section inside the Pandora FMS manual.

ここでは、テンプレートの管理、特にインスタンスのアラート管理との違いについてのみ説明します。操作と設定に関するより詳細は、アラートシステム の章を参照してください。

テンプレート管理

The only difference with regard to the management of alerts of the instances, is in the creation of a new template. When creating a template we have an option called “Wizard level”.

インスタンスにおけるアラート管理との唯一の違いは、新たなテンプレートの作成にあります。テンプレートを作成するとき、“ウィザードレベル(Wizard level)” というオプションがあります。

This field will define which users will be able to use this template to create alerts from the Wizard.

このフィールドは、どのユーザがウィザードからアラートを作成するのに、このテンプレートを使えるかを定義します。

  • No Wizard: This template will not be available in the Wizard.
  • Basic: Any user with access to the Wizard will be able to use this template to create alerts.
  • Advanced: Only users with advanced level of access to Metaconsole will be bale to use this template (see section Create user).
  • ウィザード無し(No Wizard): このテンプレートはウィザードに含まれません。
  • 基本(Basic): ウィザードにアクセスできる任意のユーザが、アラート作成にこのテンプレートを利用できます。
  • 拡張(Advanced): メタコンソールのアクセスで拡張設定ユーザのみがこのテンプレートを利用できます(詳細は 新規ユーザの作成 を参照してください)。

The following actions can be performed in this section:

ここでは、次の操作ができます。

  • Create event alert
  • Modify/Delete/Disable/Silence event alerts
  • イベントアラートの作成
  • イベントアラートの修正、削除、無効化、静観

For example, we have 4 instances where we have in one of the agents the monitoring of the apache server of each of the web pages located in the different instances. We will create an event alert that will warn us when this monitoring goes down to warn the administrator that the Apache service should be immediately fixed, so that it wouldn't be necessary to create one by one manually in the instances agents.

たとえば、4 つのインスタンスがあり、それぞれのインスタンスで、ウェブページを提供する Apache サーバの監視を行うエージェントがあるとします。管理者に Apache サービスを直ちに修正する必要があることを警告するために、障害が発生したことを通知するイベントアラートを作成します。インスタンスのエージェントで、一つ一つ手動で作成する必要はありません。

To find out more about its operation and configuration, please consult the section Alert System of the Pandora FMS manual.

操作と設定に関する詳細は、イベントアラート、イベント相関 を参照してください。

The following actions can be performed in this section:

ここでは次の操作ができます。

  • Tag Management
  • Module group management
  • OS Management
  • タグ管理
  • モジュールグループ管理
  • OS 管理

タグ管理

In this section we will be able to delete, modify, and create new tags.

ここでは、タグの削除、編集、新規作成ができます。

タグの作成

To create a new tag we click on the button “create tag” and then we will get the following form to fill in:

新たなタグを作成するには、“タグの作成(create tag)” ボタンをクリックし、次のフォームに入力します。

タグの編集/削除

In the list of tags we have options to:

タグ一覧には次のオプションがあります。

  • Edit the tag
  • Delete the tag from the Metaconsole
  • タグの編集
  • メタコンソールからタグの削除

モジュールグループ管理

In this section we can delete and create new groups of modules.

ここでは、モジュールグループの削除と新規作成ができます。

グループ作成

To be able to create a new module group we will click on the button “Create module group”:

新たなモジュールグループを作成するには、“モジュールグループの作成(Create module group)” ボタンをクリックします。

モジュールグループ削除

OS 管理

In this section we can delete and create new OS.

ここでは、OS の削除および新規作成ができます。

OS 作成

To create a new OS we click on the button “create OS” and a form will appear for us to fill in:

新たな OS を作成するには、“OS の作成(create OS)” ボタンをクリックし、次のフォームに入力します。

OS 削除

From this section we can create, modify, and delete policies.

ここでは、ポリシーを作成、編集、削除できます。

For example, we have 7 instances in which 2 of them are going to be monitored in the same way, with the same name of agents and modules. We would create a policy that creates the modules in the agents automatically, which we will later synchronize with the different instances without having to create it one by one.

例えば、7つのインスタンスがあり、うち 2つは同じ名前のエージェントとモジュールがあり、同じように編集するとします。エージェントに自動的にモジュールを作成するポリシーを作成します。これは、一つ一つ作成する必要なく、のちほどインスタンスに同期されます。

ポリシーの作成

New policies can be created by clicking on the “Create” button, where the following form is displayed:

新規ポリシーは、“作成(Create)” ボタンをクリックすることにより作成できます。次のようなフォームが表示されます。

For a better understanding of how to configure policies, please refer to the section Policy Management.

ポリシー設定に関する詳細は、ポリシー管理 を参照してください。

ポリシーの編集/削除

In the list of policies we have options to modify a policy and delete it. If a policy has agents, the “Delete” button will be disabled and a button to delete all its agents will appear next to it. This button will introduce the agent deletion into the queue, and as soon as it is processed, the policy deletion button will be active again.

ポリシー一覧には、ポリシーを編集および削除するオプションがあります。 ポリシーにエージェントがある場合は、“削除(Delete)” ボタンは無効化され、隣に全エージェント削除のボタンが表示されます。このボタンはキューにエージェント削除処理を入れます。キューはすぐに実行され、ポリシー削除ボタンが有効化されます。

In this section we can modify, delete and create new categories.

ここでは、カテゴリの編集、削除、新規作成ができます。

カテゴリの作成

To create a new category click on the button “create category”:

新たなカテゴリを作成するには、“カテゴリ作成(create category”) ボタンをクリックします。

カテゴリの編集/削除

In the list of categories we have options to:

カテゴリ一覧には以下のオプションがあります。

  • Edit the category
  • Delete the category from the Metaconsole
  • カテゴリ編集
  • メタコンソールからカテゴリの削除

In this section we will be able to delete the servers installed in the Metaconsole. In order to be able to use all the features, the Auto-provisioning and Migration servers should be activated.

ここでは、メタコンソールにインストールされたサーバを削除できます。この機能を利用するには、自動プロビジョニングおよびマイグレーションサーバが有効化されている必要があります。

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

  • ja/documentation/06_metaconsole/09_metaconsole.txt
  • 最終更新: 2022/04/30 02:47
  • by junichi