個人用ツール

Pandora:Documentation ja:Operations

提供: Pandora FMS Wiki JP

移動先: 案内, 検索

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

目次

ソフトウエアエージェントを使ったモニタリング

エージェントの名前

From Pandora FMS version 7 onwards, the agents have an alias and a name (or unique identifier). An agent configured by default will generate a name (or identifier) based on a pseudo-random hexadecimal string, and an alias (or visible name) based on the hostname of the machine.

Pandora FMS バージョン 7 以降では、エージェントには、別名と名前(またはユニークな識別子)があります。デフォルトでは、エージェントはランダムの 16進数から成る文字列の名前(または識別子)を生成します。また、マシンのホスト名から成る別名(または表示名)を生成します。

In previous versions there was only the "name" of the machine, and the previous system is totally compatible with the most modern versions of Pandora FMS, only that if in the same Pandora FMS installation there are two agents with the same identifier (or names) the data of both agents will be mixed and/or will be overwritten. That's why we introduced from version 7 onwards the possibility that agents with different names could have the same alias.

以前のバージョンでは、マシンの "名前" しかありませんでしたが、以前のシステムは Pandora FMS の最新バージョンと完全に互換性があります。同じPandora FMS インストールで同じ識別子(または名前)両方のエージェントのデータが混在し、上書きされます。 そのため、バージョン7以降では、異なる名前のエージェントが同じ別名を持つ可能性があります。

The following configuration tokens are used to change this behavior:

pandora_agent
pandora_alias

以下の設定トークンにより、この動作を変更できます。

pandora_agent
pandora_alias

By default, the configuration file does not use either one of them, so it gets the hostname of the machine as an alias and a very large random hexadecimal number as a name or identifier. The agent name is no longer visible (except in the agent detail view) and CANNOT be changed. The Agent Alias can be changed at any time, without having to worry about the configuration of the software agent, since the agent's unique identifier is the agent's "name".

デフォルトでは、設定ファイルのいずれかを使用しないので、マシンのホスト名を別名として取得し、非常に大きなランダムな16進数を名前または識別子として取得します。エージェント名は表示されなくなり(エージェント詳細表示を除く)、変更することはできません。 エージェントの一意の識別子はエージェントの「名前」であるため、エージェントの別名はソフトウェアエージェントの設定を心配することなく、いつでも変更できます。

エージェント設定

All the configuration and monitoring parameters of the software agents can be found in their configuration file pandora_agent.conf. This is stored locally in the machine where the software agent is installed, so any modification we want to make in the agent must be reflected in this file. You have a detailed description of all agent configuration tokens in the chapter "PandoraFMS Agent Configuration" [1] while here we will only focus on the advanced uses of some of them.

ソフトウェアエージェントのすべての設定と監視パラメータは、設定ファイル pandora_agent.confにあります。 これは、ソフトウェアエージェントがインストールされているマシンのローカルに保存されるため、エージェントの設定変更は、すべてこのファイルに反映させる必要があります。全エージェント設定トークンの詳細については、"PandoraFMS ソフトウエアエージェント" の章( https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:Configuration_Agents )を参照してください。ここでは高度な設定向けに、そのうちのいくつかのみに焦点をあてます。

リモート設定

On the Enterprise version, there is a remote Agent Configuration feature which allows centralized configuration and file management from the server console. This allows centralized management of all our software agents without the need to physically access the systems where they are installed.

エンタープライズ版では、設定の中央管理およびコンソールからのファイル管理が行える、リモートエージェント設定機能があります。これにより、エージェントをインストールしたシステムへログインすることなく、設定ファイルの管理をサーバコンソールから統括して行うことができます。

The configuration consists of two files. Their file names are <md5>.conf and <md5>.md5, where <md5> is the agent's name hash code. Those files are stored in '/var/spool/pandora/data_in/conf' and '/var/spool/pandora/data_in/md5' folders respectively.

設定は、<md5>.conf および <md5>.md5 という名前の 2つのファイルで行います。ここで、<md5> は、エージェント名のハッシュです。これらのファイルは、"/var/spool/pandora/data_in/conf" および、"/var/spool/pandora/data_in/md5" ディレクトリに配置されます。

These files stored in the server are modified by Pandora FMS console when the agent configuration is edited remotely.

サーバに保存されるこれらのファイルは、Pandora FMS コンソールでの操作により修正されます。



To enable the remote configuration, you only need to enable the corresponding parameter in the agent's local configuration file first. From this moment on, all the changes must be done from Pandora FMS console:

リモート設定を有効にするためには、最初にエージェントのローカル設定ファイルで以下のパラメータを設定します。有効にしたのちは、すべての変更は Pandora FMS コンソールから実施する必要があります。

remote_config 1

Info.png

Once the agent's remote configuration is enabled, any changes made locally in the configuration file will be overwritten by the configuration stored in the console. If you want to prevent this from happening, stop the agent, modify the configuration file, disable the remote configuration and launch the agent again.


Info.png

エージェントのリモート設定を有効にしたあとは、ローカルの設定ファイルを変更してもコンソールに保存されている設定で上書きされます。これを停止したい場合は、エージェントを停止し設定ファイルを編集し、リモート設定を無効化したのち、エージェントを再起動します。


共通設定パラメータ

In the Pandora FMS Software Agents section you can find a complete explanation on Agent Configuration. In this section, the common parameters used to configure the Software Agents are going to be explained.

Pandora FMS ソフトウエアエージェント の章に、エージェント設定に関する詳細説明があります。この章では、ソフトウエアエージェントの設定に利用する共通のパラメータについて説明します。

The most used parameters are:

よく使われるパラメータは次の通りです。

  • server_ip: IP address of Pandora FMS Server.
  • server_ip: Pandora FMS サーバの IP アドレスです。
  • server_path: Path of incoming folder for Pandora FMS server. By default /var/spool/pandora/data_in.
  • server_path: Pandora FMS サーバの incoming フォルダのパスです。デフォルトは、/var/spool/pandora/data_in です。
  • temporal: Software agent's temporal folder. By default /var/spool/pandora/data_out.
  • temporal: ソフトウエアエージェントのテンポラリフォルダです。デフォルトは、/var/spool/pandora/data_out です。
  • logfile: Software agent's log file. By default /var/log/pandora/pandora_agent.log
  • logfile: ソフトウエアエージェントのログファイルです。デフォルトは、/var/log/pandora/pandora_agent.log です。
  • interval: Agent's execution interval. By default 300.
  • interval: エージェントの実行間隔です。デフォルトは、300 です。
  • intensive_interval: Intensive module execution interval. By default 300.
  • intensive_interval: 高頻度モジュールの実行間隔です。デフォルトは、300 です。
  • debug: Debug mode enable. By deafult 0 (disabled).
  • debug: デバッグモードを有効にします。デフォルトは 0 (無効)です。
  • agent_name: Agent name. By default hostname is taken.
  • agent_name: エージェント名です。デフォルトはホスト名が使われます。
  • remote_config: Remote configuration enable. By default 0 (disabled).
  • remote_config: リモート設定を有効にします。デフォルトは 0 (無効)です。

An example of the general parameters from a Unix configuration would be:

UNIX 向け設定 での一般的なパラメータ設定例は次の通りです。

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        /var/spool/pandora/data_out 
logfile         /var/log/pandora/pandora_agent.log 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config    1 

An example of the general parameters from a Windows configuration would be :

Windows 向け設定 での一般的なパラメータ設定例は次の通りです。

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        c:\program files\pandora_agent\temp
logfile         c:\program files\pandora_agent\pandora_agent.log 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config   1

カスタムフィールド

Custom fields are an easy way to personalize agent information. Create custom fields by clicking on 'Resources' -> 'Custom fields'.

カスタムフィールドは、エージェントの情報を追加する簡単な仕組みです。カスタムフィールドは、'リソース(Resources)' -> 'カスタムフィールド(Custom fields)' をクリックすると作成できます。





  • Name: Name of the custom field.
  • Display on front: With this field checked, the custom field will be displayed in front of the agent like on the screenshot below:
  • 名前(Name): カスタムフィールド名。
  • 前面に表示(Display on front): これをチェックすると、カスタムフィールドは以下の画面ショットのようにエージェント表示に表示されます。



These custom fields can also be passed from the agent configuration file, using the following configuration token:

これらのカスタムフィールドは、次のような設定トークンを使ってエージェント設定ファイルから渡すことができます。

custom_field1_name Model
custom_field1_value i386

This example allows you to use a custom agent field defined in the agent's. conf.

エージェントの設定で定義したカスタムフィールドが使えます。

ソフトウエアエージェントを使った監視

Software agents are running on the systems from which they collect information. Each of the checks they make on the system, such as CPU usage, free memory or disk space, corresponds to a module. Therefore, each of these modules collects a single data in each execution.

ソフトウェアエージェントは、情報を収集するシステム上で実行されます。 CPU使用率、空きメモリ、ディスク容量など、システム上で行う それぞれのチェックモジュール に対応します。 これら各モジュールは、実行ごとに 1つのデータを収集します。

There are also some agent-specific directives that serve to collect certain data directly from the operating system (e.g. CPU usage, memory, events, etc.). With these agent-specific directives, you don't need to execute commands. Please check the Software Agents Installation Section to obtain more information about them.

オペレーティングシステムから特定のデータ(CPU使用率、メモリ、イベントなど)を直接収集するためのエージェント特有の ディレクティブ もあります。 これらのエージェント固有のディレクティブでは、コマンドを実行する設定は必要はありません。 詳細に関しては、ソフトウェアエージェントのインストールの章を確認してください。



Pandora FMS software agents use the commands of the operating system in which they are installed to obtain the information for each one of their modules. The Pandora FMS data server processes and stores in the database all the information generated by the software agents, which send you their data in an XML file.

Pandora FMS ソフトウエアエージェントは、情報を得るために OS のコマンドを利用しています。Pandora FMS データサーバは、ソフトウエアエージェントが実行したコマンドによって生成されたデータを処理しデータベースへ保存します。エージェントからのデータは、XML でサーバへ送られます。


Logical schema of an agent/physical agent


In the agent configuration file, the modules are defined by the following structure:

エージェント設定ファイルでは、モジュールは次のような構造で定義されます。

module_begin 
module_name cpu_user
module_type generic_data
module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'
module_description User CPU Usage (%)
module_end

A real case can be:

以下に別の例を示します。

module_begin 
module_name Files data_in
module_type generic_data
module_exec ls /var/spool/pandora/data_in | wc -l
module_description Number of files incoming dir
module_end

The line module_exec contains the command that will be executed to collect the information. The value returned by that execution will be the data obtained by the module and will be shown in the monitoring. Another command to get information using module_exec would be:

module_exec 行には、情報を収集するために実行するコマンドが含まれます。実行結果の値は、モジュールのデータとなり監視データとして表示されます。 情報を収集する module_exec の他の例を以下に示します。

module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'

To collect the information the agent will execute the command in the shell as if it was done by an operator, so it is always advisable to manually launch the command and analyze the output:

エージェントは、情報を収集するためにオペレータによって実行されたかのようにシェルでコマンドを実行するので、手動でコマンドを起動して出力を分析することをお勧めします。

$> vmstat 1 2 | tail -1 | awk '{ print $13 }'

The value returned by the execution will be stored in XML as module data. You can indicate anything in the line module_exec as long as the output is compatible with the values accepted by Pandora (numerical, alphanumeric or boolean), so it is possible to indicate custom scripts:

実行結果の値は、モジュールデータとして XML に格納されます。 出力が Pandora が受け入れ可能な値(数値、英数字またはブール値)と互換性がある限り、module_exec 行には何でも指定することができます。次のようにカスタムスクリプトを指定することができます。

module_exec myScript.pl --h 127.0.0.1 -v cpu

Again the agent is going to execute the command and collects the returned value in the same way as an operator would type in the shell:

繰り返しますが、オペレータがシェルでコマンドを実行するのと同じようにエージェントはコマンドを実行し、その戻り値を収集します。

$> myScript.pl --h 127.0.0.1 -v cpu

When the software agent is executed for the first time, it sends an XML to the Pandora FMS which creates the agent automatically with all its modules.

ソフトウエアエージェントの初回実行時には、Pandora FMS へ送った XML から全モジュールとともにエージェントを作成します。

モジュールの種類

The following are the types of modules possible in software agents depending on the type of data returned:

データのタイプに応じた、ソフトウエアエージェントのモジュールのタイプは次の通りです。

  • generic_data: Numerical and floating point data.
  • generic_data_inc: A kind of increasing numerical data. Stores the difference between the previous and current data divided by the elapsed time in seconds, showing the rate per second. This type of data is used to count "number of times per second" of something, such as log entries/sec, receivedbytes/sec , incoming connections/sec , etc.
  • generic_data_inc_abs: Type of absolute increasing numerical data. It stores the difference between the previous and current data, without dividing it between the elapsed seconds, so the value will correspond to the total increase between the two executions, and not to the increase per second. This type of data is used to count the number of times something happens, such as log entries, total received bytes, number of incoming connections, and so on.
  • generic_proc: Boolean type of data, where a value of 0 means False or incorrect, and values above zero mean True or correct. The generic_proc types have the critical (0) and correct (1 or higher) states preconfigured.
  • generic_data_string: Kinds of alphanumeric data (text).
  • async_data: It's a kind of asynchronous numeric data. It's the same as 'generic_data' but for asynchronous data which is only updated if there is a change. The asynchronous kind of data don't have a defined periodicity when we can obtain data.
  • async_string: This is a kind of asynchronous alphanumeric data. It's the same as 'generic_string' but for asynchronous data which are only updated if there is a change. It's the kind of data that you're recommended to use if you want to monitor searches in logs or event viewers. We could have new data by any second or not having one at all in many days.
  • async_proc: It's a kind of asynchronous boolean data. It's the same as 'generic _proc' but for asynchronous data which are only updated if there is a change.
  • generic_data: 数値および浮動小数点データです。
  • generic_data_inc: インクリメンタルな数値データです。前の値と現在の値の差分を間隔で割った値を保存します。このデータタイプは、'秒間の回数' をカウントするのに利用します。たとえば、秒間のログエントリー数、秒間受信バイト数、秒間のコネクション数などです。
  • generic_data_inc_abs: 絶対増加する数値データのタイプです。 これは、経過した秒数で割ることなく、前と現在のデータの差分を格納します。したがって、値は 2回の実行の間の差となり、1秒あたりの値にはなりません。このタイプのデータは、ログエントリ、合計受信バイト数、接続数など何かが発生した回数をカウントするために使用されます。
  • generic_proc: ブール型のデータです。値が 0 の場合は障害を意味し、0 より大きい場合は正常であることを意味します。 generic_proc型には、あらかじめ設定された障害(0)および正常(1以上)の状態があります。
  • generic_data_string: 文字列(テキスト)データです。
  • async_data: 非同期の数値データです。'generic_data' と同じですが非同期のデータで、変化したときのみ更新されます。非同期データは、収集間隔の定義がありません。
  • async_string: 非同期の文字データです。generic_string と同じですが非同期のデータで、変化したときのみ更新されます。データを取得したあとに、次の新たなデータの取得がいつになるかわからないような、ログやイベントをモニタするのに利用します。新しいデータを数秒間隔で受信したり、逆に数日間何もデータがない場合もあります。
  • async_proc: 非同期のブーリアンデータです。generic_proc と同じですが非同期のデータで、変化したときのみ更新されます。
  • Image module: They are based on a text string type module (generic_data_string or async_string). If the data in the module is a base64 image, in other words, part of the string contains "data:image", it will be identified as an image and, on the views that it appears, it will enable a link to open a window to display the image. Also on its historical data the strings that build/generate the images will be saved and displayed.
  • Image module: テキスト文字列型モジュール(generic_data_string または async_string)をもとにしたものです。モジュール内のデータが base64 イメージの場合、つまり文字列の一部に "data:image" が含まれている場合、それは画像データとして識別され、表示画面では画像を表示するウィンドウを開くリンクが有効になります。 また、ヒストリデータとしても文字列として保存され、画像を構築/生成し表示されます。

The software agent already comes preconfigured to send certain data from the system on which it's installed. These usually are (depending on the version):

ソフトウエアエージェントは、インストールされたシステムのデータを送信するようにあらかじめ設定されています。設定されているのは次のデータです (バージョンにより異なります)。

  • System CPU
  • Available space on the hard-drive
  • Free memory
  • Monitor of the programs and services states
  • CPU 情報
  • ディスクの空き容量
  • メモリの空き容量
  • プログラムやサービスの状態

ローカルモジュールの間隔

The local modules (or software agent modules) all have the interval of their agent as a "base". In other words, if an agent has an interval of 5 minutes (300 seconds), all modules will default to an interval of 5 minutes. You can make a module have a GREATER interval, but you can never make it less than the agent's base interval, since the interval of a module is defined as a multiplier of the agent's interval.

ローカルモジュール(ソフトウエアエージェントのモジュール)には、ベースとしてエージェントの実行間隔があります。言い換えると、エージェントの間隔が 5分(300秒)の場合、すべてのモジュールはデフォルトで 5分間隔となります。モジュールの間隔はエージェントの間隔よりも大きくすることはできますが、小さくすることができません。モジュールの間隔は、エージェントのそれに対して何倍するかで設定します。

If an agent has an interval of 300 and a module of that agent has the following configuration:

エージェントの間隔が 300 で、モジュールに次の設定がされていたとします。

module_interval 2

The interval module will be 300x2. The module_interval parameter only supports whole numbers greater than zero.

このとき、モジュールの間隔は、300x2 になります。module_interval パラメータは、0 より大きい数値のみ対応しています。

モジュール作成インタフェース

(Enterprise only)

(Enterprise 版のみ)

In the Enterprise version it is possible to create and manage local modules of the software agents if they have the parameter remote_config 1. If you do not have the Enterprise version, all these operations must be done directly on the configuration file of the software agent, locally in the system where the agent is installed.

Enterprise 版では、ソフトウエアエージェントの設定が remote_config 1 になっていれば、ソフトウエアエージェントのローカルモジュールを作成・管理することができます。Enterprise 版を利用していない場合、ソフトウエアエージェントの設定は、エージェントをインストールしたサーバ上で直接設定ファイルを編集することで行う必要があります。

The creation of local modules from console is done using a form where, besides the common configuration with the remote modules (thresholds, type, group...) there is a text box where specify the configuration data that will be placed into the configuration file of the software agent.

コンソールからのローカルモジュールの作成は、リモートモジュール(の閾値、タイプ、グループなど)と同様に、フォームを利用して行います。設定データを指定するテキストボックスがあり、ソフトウエアエージェントの設定ファイルが表示されています。

In this text box there are two buttons, one to create a basic configuration structure and the other to check that the data is correct. This check is intended for basic parameters, e.g. checking if it begins with 'module_begin', ends with 'module_end' and if it has a valid type and name. Other parameters may be wrong, but that won't be detected here.

このテキストボックスには、2つのボタンがあります。一つは、基本設定の作成(create a basic configuration structure)で、もう一つは、データの正常性確認(check that the data is correct)です。この確認では、module_begin で始まり、module_end で終了、また正しいタイプと名前が設定されているかどうか、基本的なパラメータを確認します。他のパラメータの間違いは検出できません。

The field name and the type combo are linked the the parameters module_name and module_type of the data configuration. When change the module name on the name field, the configuration data name will be changed automatically and vice versa. In the same way, when select a type in the combo, the data configuration type will be changed and when a correct type were write in the configuration data this type will be selected in the combo automatically.

フィールド名とタイプの選択は、データ設定の module_name および module_type パラメータにリンクされています。 名前フィールドでモジュール名を変更すると、設定データ名が自動的に変更されます。 逆も同様です。同様に、タイプを選択するとデータ設定タイプが変更され、設定データにタイプを書くとメニューからそのタイプが自動的に選択されます。

When a module is charged from a local component, it can has macros. If it has macros, the configuration data will be hidden and will appear a field for each macro. This feature is explained deeply at the section Templates and components

ローカルコンポーネントからモジュールを変更すると、マクロを設定することができます。マクロがある場合、設定データは表示されなくなり、それぞれのマクロのフィールドに表示されます。この機能の詳細については、テンプレートとコンポーネントにて説明しています。

状態にもとづくモニタリング

事後処理

Pandora FMS software agent supports the execution of commands and scripts as post-conditions. This means that actions could be performed depending on the value obtained in the execution of the module.

Pandora FMS ソフトウエアエージェントは、モジュールの実行結果の値に応じたスクリプトの実行をサポートしています。これは、モジュールの実行で得られた値に応じてアクションを行えることを意味します。

With the parameter module_condition we will indicate a value or range of values and the execution to be carried out in case the module is between these values:

module_condition パラメータにて、モジュールの実行の事後処理を定義します。モジュールから返される値にもとづいて実行されるコマンドを定義します。設定ファイルの例を次に示します。

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 20 add_processes.sh
module_end

You can define multiple postconditions for the same module. For example:

一つのモジュールに複数の事後処理を定義することもできます。例えば次の通りです。

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition (90, 100) remove_processes.sh
module_condition < 20 add_processes.sh
module_end

Some examples:

その他の例:

Execution when the module data is less than 20:

モジュールのデータが 20未満になったら場合に実行:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 20 add_processes.sh
module_end

If the script get_cpu_usage.pl returns 18, then the software agent will execute the script add_proceses.sh, otherwise not.

スクリプト get_cpu_usage.pl が 18 を返したら、ソフトウエアエージェントはスクリプト add_proceses.sh を実行し、そうでなければ実行しません。

Execution with two preconditions:

2つの事後処理を実行:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 10 start_new_server.sh
module_condition < 20 add_processes.sh
module_end

If the module returns 15, the software agent will only execute the script add_processes.sh. But if the value is 6 the script will execute both scripts start_new_server.sh y add_processes.sh

モジュールが 15を返した場合、ソフトウエアエージェントは、スクリプト add_processes.sh のみを実行します。値が 6の場合は、start_new_server.sh と add_processes.sh の両方のスクリプトを実行します。

事前処理

The parameter module_precontition defines a precondition to evaluate before a module execution, depending an the result of this precondition the software agent will execute the module or not. The structure in the configuration file is:

module_precondition パラメータにて、モジュール実行前の事前処理を定義します。この事前処理により、ソフトウエアエージェントはモジュールを実行するかどうか決めます。設定ファイル例は次の通りです。

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_end

You can define multiple preconditions for the same module. For example:

同じモジュールに複数の事前処理を定義することもできます。例えば、次の通りです。

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_precondition = 1 important_service_enabled.sh
module_end

In the example above we have two preconditions. For the module to be executed all preconditions must be met, in this case two, so the module will only be executed when the number_active_processes.sh script returns a number greater than 10 and the important_service_enabled.sh script returns 1.

上記の例では、2つの precondition が定義されています。モジュールを実行するには、すべての前提条件、この場合は 2つが満たされている必要があります。モジュールは、number_active_processes.sh スクリプトが 10より大きい数値を返し、important_service_enabled.sh スクリプトが 1を返す場合にのみ実行されます。

Module execution only when the precondition is above 10:

事前処理の結果が 10を超えたときのみモジュールを実行:

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_end

In the example above, the software agent executes the script 'number_active_processes.sh', if the returned value is greater than '10'. If the returned value is lower than '10', the module won't be executed.

上記の例では、ソフトウエアエージェントは、値が 10 より大きい場合に 'number_active_processes.sh' スクリプトを実行します。値が 10以下の場合はモジュールが実行されません。

高頻度モニタリング

There are certain modules that are of special importance, such as critical running processes or services. Intensive monitoring is available to enable more controlled monitoring of these cases.

重要な実行プロセスやサービスなど、特に重要なモジュールが存在する場合があります。 これらのケース向けに、より制御された監視を可能にする集中監視が利用できます。

It consists of warning in a shorter interval that a problem has appeared without reducing the agent's general interval.

エージェントの通常の実行間隔を短くすることなく、問題が発生した場合にのみ短い間隔で監視をします。

The software agent presents these two configuration parameters:

ソフトウエアエージェントには、以下の 2つの設定パラメータがあります。

  • "Interval": agent sampling time in seconds. This is the general range for all local modules. Required parameter.
  • Intensive_interval: time in which we will be notified of a problem in the especially critical modules. Optional parameter.
  • "Interval": エージェントの実行間隔を秒で指定します。これは、全ローカルモジュールの一般的な間隔で、必須のパラメータです。
  • Intensive_interval: 障害状態のモジュールに対して監視を行う間隔で、オプションパラメータです。

At module level, the parameter module_intensive_condition will be used to determine under which condition the status of the module will be notified in the time defined by the intensive_interval.

モジュールレベルでは、パラメータ module_intensive_condition を使用して、 intensive_interval で定義された時間間隔を適用する条件を設定します。

  • module_intensive_condition = 0: if the module obtains as a result the value indicated in this parameter (in this case 0), it will be notified in the intensive interval defined in the agent.
  • module_intensive_condition = 0: モジュールの値がこのパラメータで指定した値の場合、エージェントで定義された高頻度の間隔で監視します。

If you want to check whether the SSHD system service is running every 10 seconds, but want to be notified every 10 minutes if the service is fine, you may configure the agent in the following way:

SSHD システムサービスの監視を通常は 5分ごとに実施したいが、障害時は 10秒ごとに監視したい場合は、次のようにエージェントを設定することができます。

intensive_interval 10
interval 300
module_begin
module_name SSH Daemon
module_type generic_data
module exec ps aux | grep sshd | grep -v grep | wc -l
module_intensive_condition = 0
module_end

If the service goes down, you will be notified in the next 10 seconds. If the service is up, you will be notified in the next 5 minutes, like normally.

サービスがダウンすると、次の 10秒で通知されます。サービスが起動していれば、次のチェックは通常通り 5分後です。

指定時間モニタリング

The software agent supports the definition of programmed modules which are executed in the defined instances. The syntax is the same as crontab. The module structure is the following:

ソフトウエアエージェントは、モジュールを指定時間に実行する設定ができます。書式は crontab と同じです。モジュールの設定例は次の通りです。

module_begin
module_name crontab
module_type generic_data
module_exec script.sh
module_crontab * 12-15 * * 1
module_end

In this example the module is executed every Monday from 12 to 15.

この例では、モジュールは毎月曜の 12 から 15時の間に実行されます。

If we're required to execute the module every hour and ten minutes, we can use this module definition:

モジュールを毎時 10分に実行したい場合は、次のようにします。

module_begin
module_name crontab
module_type generic_data
module_exec script.sh
module_crontab 10 * * * *
module_end

Info.png

Note that if you use an interval that causes the module not to report data, this module will go into "unknown" status. Use asynchronous modules for these cases.


Info.png

モジュールがデータを出力しない期間を設定した場合、モジュールは "不明" 状態になります。このような場合は非同期モジュールを利用します。


Windows における特定の監視

The software agent for Windows platforms has specific features for this platform to make monitoring easier. Following these feature are explained with some examples.

Windows プラットフォームのソフトウエアエージェントは、モニタリングを簡単にするための特有の機能があります。以下にいくつかの例とともに、機能の説明をします。

プロセスモニタリングと、プロセスウォッチドック

プロセスモニタリング

The parameter module_proc chekcs if a process with given name is running in this machine. The module definition is:

module_proc パラメータは、指定した名前のプロセスがそのマシンで動いているかどうかをチェックします。モジュール定義は次の通りです。

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_description Process Command line
module_end

If the process name has blanks, don't use «" "». The process name is the same as showed in Windows Task Manager (taskmngr) including the .exe extension, its very important to use the same upper-case and lower-case.

プロセス名にスペースが含まれる場合は、«" "»を使わないでください。プロセス名は、Windows のタスクマネージャー(taskmngr)で表示されるものと同じで、拡張子 .exe を含んでいます。大文字、小文字を正しく設定することが重要です。

If you want the software agent to notice you immediately when a process is not working you must add the parameter module_async yes, the module definition would be:

プロセスが動作していない時、すぐにソフトウエアエージェントから通知が欲しい場合は、module_async yes のパラメータを設定します。モジュールの設定例は次の通りです。

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_async yes
module_description Process Command line
module_end
プロセスウォッチドック

La funcionalidad de watchdog del agente software de Pandora para Windows permite actuar inmediatamente ante la caída de un proceso, levantando de nuevo. Es importante decir que el watchdog sólo funciona si el módulo es asíncrono.

Windows のソフトウエアエージェントのウォッチドック機能は、プロセスがダウンしたときに再起動することができます。ウォッチドックは、モジュールが非同期の場合にのみ動作します。

La definición de un módulo con watchdog sería parecida a esta:

ウォッチドックモジュールの設定例を以下に示します。

module_begin
module_name Notepad
module_type generic_data
module_proc notepad.exe
module_description Notepad
module_async yes
module_watchdog yes
module_user_session yes
module_start_command c:\windows\notepad.exe
module_startdelay 3000
module_retrydelay 2000
module_retries 5
module_end

In the previous example, the watchdog will activate each time the notepad.exe process is deactivated and the command c: \windows\notepad. exe will be executed. In addition, if we look at the other watchdog configuration parameters, we will see that the process reactivation will be attempted 5 times with an initial wait time of 3 seconds and a wait time between retries of 2 seconds. In this example, the notepad.exe process will be launched in the user's session.

上記の例では、ウォッチドックが notepad.exe プロセスがダウンしたときは常に c:\windows\notepad.exe を実行しそれを再起動します。また、再起動のリトライは 3秒間隔で 5回まで実施し、1回のタイムアウトは 2秒という設定です。この例では、notepad.exe プロセスはユーザのセッションで起動します。

サービスモニタリングと、サービスウォッチドック

サービスモニタリング

The parameter module_service checks if a specified service is running in the machine. The definition of this module is:

module_service パラメータは、指定したサービスがマシンで動作しているかどうかをチェックします。モジュールの設定例を以下に示します。

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_end

If the service name has blanks, so please don't use «" "». To find the service name, you can look at the Service Name field under the Windows Service Manager. It's important to keep in mind that all names are case sensitive.a

サービス名にスペースが含まれる場合、«" "» は使わないようにしてください。サービス名を見つけるには、Windows サービスマネージャのサービス名フィールドを見てください。大文字、小文字の確認が重要です

If we want the software agent to notice us immediately when a service is down, we're required to add the parameter module_async yes. The module definition would be as follows:

サービスがダウンしたときにソフトウエアエージェントがすぐに通知して欲しい場合は、module_async yes を追加する必要があります。モジュールの設定例を以下に示します。

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_async yes
module_end
サービスウォッチドック

As with processes there is a watchdog mode for services that allow you to restart a down service. A module definition example using watchdog is like this:

プロセスと同様に、ダウンしたサービスを再起動できるウォッチドックモードがあります。ウォッチドックを使ったモジュール定義例は次の通りです。

module_begin
module_name ServiceSched
module_type generic_proc
module_service Schedule
module_description Service Task scheduler
module_async yes
module_watchdog yes
module_end

The watchdog definition for services doesn't need any extra parameter because they are in the service definition.

ウォッチドックの定義には、特別なパラメータは必要ありません。サービスの定義内にあるためです。

基本リソースのモニタリング

This section describes how to monitor basic variables of a Windows machine.

この項では、Windows マシンの基本的な値をモニタリングする方法について説明します。

CPU のモニタリング

To monitor the CPU you can use the parameter module_cpuusage that returns the percentage cpu usage.

CPU をモニタするには、CPU 使用率を返す module_cpuusage パラメータを利用します。

Its possible to monitor the cpu based on its id with the following module definition:

次のような設定で、CPU の ID を元に CPU をモニタすることができます。

module_begin
module_name CPU_1
module_type generic_data
module_cpuusage 1
module_description CPU usage for CPU 1
module_end

Also you can monitor the average of CPU usage from all system with the module:

また、次のように、すべての CPU の平均使用率をモニタすることもできます。

module_begin
module_name CPU Usage
module_type generic_data
module_cpuusage all
module_description CPU Usage for all system
module_end
メモリのモニタリング

To monitor the memory you can use two parameters module_freememory that returns the amount of free memory in the system and module_freepercentmemory that returns the percentage of free memory.

メモリをモニタするには、システムの空きメモリ容量を返す module_freememoryと、空き率をパーセンテージで返す module_freepercentmemory の 2つのパラメータを利用できます。

An example module usgin module_freememory would be:

module_freememory を使ったモジュールの例を以下に示します。

module_begin
module_name FreeMemory
module_type generic_data
module_freememory
module_description Non-used memory on system
module_end

A module using module_freepercentmemory would be defined in this way:

module_freepercentmemory を使ったモジュールの例を以下に示します。

module_begin
module_name FreePercentMemory
module_type generic_data
module_freepercentmemory
module_end
ディスクのモニタリング

To monitor the disk space you can use two parameters: module_freedisk that returns the amount of free space and module_freepercentdisk that returns the percentage of free space. Both parameters require the unit to monitor as an input, don't forget the character «":"».

ディスクスペースをモニタするには、空き容量を返す module_freedisk と、空き率をパーセンテージで返す module_freepercentdisk の 2つのパラメータを利用できます。両方のパラメータには、モニタするドライブ名の指定が必要で、":" を忘れないようにしてください。

A module that uses module_freedisk is define in this way:

module_freedisk を使ったモジュールの設定例を以下に示します。

module_begin
module_name FreeDisk
module_type generic_data
module_freedisk C:
module_end

An example moudel that uses the parameter module_freepercentdisk is defined with this structure:

module_freepercentdisk を使ったモジュールの設定例を以下に示します。

module_begin
module_name FreePercentDisk
module_type generic_data
module_freepercentdisk C:
module_end

WMI クエリ

The Pandora FMS Software Agent allows you to extract information by using WMI queries and ODBC connections - very common technologies used to store external or system-related information.

Pandora FMS のソフトウエアエージェントは、システムに関連した情報や外部の情報を保持するのに使われる共通の技術である WMI クエリおよび ODBC 接続を使って情報を取得することができます。

The software agent allows you to execute any local WMI query you want using the module_wmiquery parameter. To perform the query, set the parameter module_wmiquery by the query which is going to be performed and to set the parameter module_wmicolumn by the column which has the information to monitor.

module_wmiquery パラメータを使って、ソフトウエアエージェントはローカルで WMI クエリを実行することができます。クエリを実行するには、実行するクエリを module_wmiquery パラメータで設定し、取得したい情報を持つカラムを module_wmicolumn で指定します。

For example, we can get a list with the services installed:

例えば、次の設定ではインストールされているサービス一覧を取得できます。

module_begin
module_name Services
module_type generic_data_string
module_wmiquery Select Name from Win32_Service
module_wmicolumn Name
module_end

Using WMI we can also get the CPU load:

WMI を使って、CPU ロードも取得できます。

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

ソフトウエアエージェントでのリモートチェック

A remote check performed by the agent makes it easy to monitor complex networks that have special, security-related requirements.

エージェントによるリモートチェックは、セキュリティ等の特別な理由のある複雑なネットワークを簡単にモニタリングできます。

This way of working is usually used when you want to launch remote checks on systems that the main Pandora FMS server does not have access to, for which we can install a software agent, run remote checks from that point and distribute them in broker agents.

この方法は、主に Pandora FMS サーバが直接アクセスできないシステムに対してリモートチェックを行う場合に使用します。ソフトウェアエージェントをインストールし、そのからリモートチェックを実行し、ブローカエージェントで配布することができます。

This section explains how to use this feature of the software agent

この章では、ソフトウエアエージェントのこの機能の使い方について説明します。

ICMP チェック

ICMP or ping checks are very useful to know if a machine is connected to a network or not. In this way, a single software agent could easily monitor the status of all machines.

ICMP もしくは ping の監視は、マシンがネットワークにつながっているかどうかを確認するのに便利です。単一のソフトウェアエージェントがすべてのマシンのステータスを簡単に監視できます。

Unix

By using the UNIX software agent, you're able to utilize the system commands to create a module which performs the ping check. An example module definition would be:

UNIX ソフトウェアエージェントを使用することにより、システムコマンドを利用して ping チェックを実行するモジュールを作成することができます。 モジュール定義の例は次のとおりです。

module_begin
module_name Ping
module_type generic_proc
module_exec ping -c 1 192.168.100.54 >/dev/null 2>&1; if [ $? -eq 0 ]; then echo 1; else echo 0; fi
module_end

In this example module, we're going to perform a ping check on the host '192.168.100.54'. If you want to check a different host, all you have to do is to change the IP.

このモジュールの例では、192.168.100.54 宛の ping チェックを実行します。他のホストをチェックしたければ、IP アドレスを変更するだけです。

Windows

The software agent for Windows platforms has the following parameters to configure the ping checks:

Windows のソフトウエアエージェントには ping チェックを設定するためのパラメータがあり、次の通りです。

  • module_ping_count x: Number of ECHO_REQUEST packages to send (By default 1).
  • module_ping_count x: 送信する ECHO_REQUEST パケット数 (デフォルトは 1)
  • module_ping_timeout x: Timeout in seconds (Default value is '1').
  • module_ping_timeout x: 秒単位のタイムアウト値 (デフォルトは 1)
  • module_advanced_options: Opciones avanzadas para ping.exe.
  • module_advanced_options: ping.exe のオプションパラメータ

An example of a module configuration could be:

モジュールの設定例を次に示します。

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 5
module_end

In this example we perform the same check that in the previous one, but now we use the software agent for Windows platforms.

この例では、Unix の場合と同じチェックを行います。ただし、Windows 環境でのソフトウエアエージェントです。

TCP チェック

TCP checks are useful to verify if a port of a host is open. It could be interesting to know if an application is connected to the network or not.

TCP チェックは、ホストのポートが開いているかを確認するのに便利です。アプリケーションがネットワーク上で応答するかどうかを確認することができます。

Unix

With the software agent for Unix platforms we could perform the TCP check with the following module:

Unix のソフトウエアエージェントでは、次のようなモジュール設定にて TCP チェックを実行します。

module_begin
module_name PortOpen
module_type generic_proc
module_exec nmap 192.168.100.54 -p 80 | grep open > /dev/null 2>&1; echo $?; if [ $? == 0 ]; then echo 1; else echo 0; fi
module_timeout 5
module_end

With this module we check if the port 80 of the host 192.168.100.54 its open or closed.

このモジュールでは、ホスト 192.168.100.54 の 80番ポートが開いているかどうかをチェックします。

Windows

If we are using the software agent for Windows we have some parameters to configure the TCP check. The parameters are:

Windows のソフトウエアエージェントを使っている場合は、TCP チェックを設定するためのパラメータがあります。パラメータは次の通りです。

  • module_tcpcheck: Host to be checked
  • module_tcpcheck: チェックするホスト
  • module_port: Port to be checked
  • module_port: チェックするポート番号
  • module_timeout: Timeout for the check
  • module_timeout: チェックのタイムアウト値

An example of a module definition would be:

モジュールの設定例を以下に示します。

module_begin
module_name TcpCheck
module_type generic_proc
module_tcpcheck 192.168.100.54
module_port 80
module_timeout 5
module_end

This module is the equivalent for the Windows software agent to perform the check on 80 port of host 192.168.100.54

このモジュールも同様に、192.168.100.54 の 80番ポートに対してチェックを行います。

SNMP チェック

SNMP checks are commonly used to monitor network devices to check interface status, inbound/outbound bytes, etc.

SNMP チェックは、一般的にネットワークデバイスのインタフェースのステータス、送受信トラフィックなどをチェックするのに利用します。

Unix

If you are using the software agent for Unix platforms you can create the module using the command snmpget like the following:

Unix のソフトウエアエージェントを利用している場合は、次のように snmpget コマンドを使ったモジュールを作成します。

module_begin
module_name SNMP get
module_type generic_data
module_exec snmpget 192.168.100.54 -v 1 -c public .1.3.6.1.2.1.2.2.1.1.148 | awk '{print $4}'
module_end

This module returns the value for OID .1.3.6.1.2.1.2.2.1.1.148 of the host 192.168.100.54.

このモジュールは、ホスト 192.168.100.54 の OID .1.3.6.1.2.1.2.2.1.1.148 の値を返します。

Windows

For Windows software agent we have the following parameters to configure the module:

Windows のソフトウエアエージェントでは、モジュールを設定するための次のパラメータがあります。

  • module_snmpversion [1,2c,3]: SNMP version (By default 1).
  • module_snmpversion [1,2c,3]: SNMP バージョン (デフォルトは 1)
  • module_snmp_community <community>: SNMP community (By default public).
  • module_snmp_community <community>: SNMP コミュニティ(デフォルトは public)
  • module_snmp_agent <host>: Host to monitor.
  • module_snmp_agent <host>: モニタ対象のホスト
  • module_snmp_oid <oid>: OID.
  • module_snmp_oid <oid>: OID.
  • module_advanced_options: Advanced options for snmpget.exe.
  • module_advanced_options: snmpget.exe の拡張オプション

An example module could be:

モジュールの設定例を以下に示します。

module_begin
module_name SNMP get
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.148
module_end

This module is the equivalent for Windows platforms to do the last check performed using Unix software agent.

このモジュールは、Unix のソフトウエアエージェントと同じ動作をします。

プロキシモード

Template warning.png

To use agent's proxy mode on Linux/Unix systems the agen't musn't be executed by root user, so you need to perform a custom installation of Pandora FMS agent. You can see all details about custom installation in section Custom agent installation


Template warning.png

Linux/Unix システムで、エージェントのプロキシモードを利用するためには、エージェントを root 以外のユーザで実行する必要があります。そのため、Pandora FMS エージェントのカスタムインストールが必要です。カスタムインストールの詳細については、エージェントのカスタムインストールを参照してください。


Pandora FMS software agents have a Proxy Mode that allows them to act as proxies redirecting the the communication of several agentrs to Pandora FMS server. The software agent that has Proxy Mode enabled can perform monitoring task too.

Pandora FMS ソフトウエアエージェントには、エージェントから Pandora FMS サーバへの通信をプロキシするする、プロキシモードがあります。プロキシモードを有効にしたソフトウエアエージェントは、モニタリング処理も実行可能です。




The Proxy Mode is very useful when you are dealing with a network in which only one machine can communicate with Pandora FMS server. In this situation all software agents installed in machines without access to Pandora FMS server will send the XML files to the agent working as a proxy and it will redirect all files to Pandora FMS server.

プロキシモードは、1台のマシンのみ Pandora FMS サーバと通信できないといったネットワークの場合にとても便利です。この場合、すべてのマシンにインストールされたソフトウエアエージェントは直接 Pandora FMS サーバへは通信できず、XML ファイルをプロキシとして動作しているエージェントに送ります。プロキシはそれを Pandora FMS サーバへ送信します。

In addition to XML file redirection the Proxy Mode supports Remote Configuration and File Collection features.

プロキシモードでは、XML ファイル送信をプロキシすることに加えて、リモート設定 および ファイルコレクション の機能もサポートしています。

With all these features the Proxy Mode offers a transparent operation of software agents in networks with limited connectivity.

これらの機能により、プロキシモードは接続が制限されたネットワークでのソフトウエアエージェントの「透過的な操作」を提供します。

To enable the Proxy Mode in a software agent you must configure the parameters:

プロキシモードを有効にするには、ソフトウエアエージェントにて次のパラメータを設定します。

  • server_ip: IP of Pandora FMS server. With Proxy Mode enabled the IP can't take this value: 127.0.0.1, localhost, 0.0.0.0, o similar.
  • server_ip: Pandora FMS サーバの IP アドレスです。プロキシモードが有効な場合、172.0.0.1, localhost, 0.0.0.0 といったアドレスは設定できません
  • proxy_mode: If is set to 1 enabled Proxy Mode. By default is 0, disabled.
  • proxy_mode: 1 に設定するとプロキシモードが有効になります。デフォルトは 0 で、無効です。
  • proxy_max_connection: Max. number of connections for proxy, by default 10.
  • proxy_max_connection: プロキシへの最大接続数です。デフォルトは 10です。
  • proxy_timeout: Proxy tiemout, by default 1 second.
  • proxy_timeout: プロキシのタイムアウトです。デフォルトは 1秒です。

An example of configuration could be:

設定例を以下に示します。

server_ip 192.168.100.230
proxy_mode 1
proxy_max_connection 20
proxy_timeout 3

To redirect the connection of a software agent we will only have to put as Pandora's server address the one of the agent with the Proxy Mode activated. For example:

ソフトウエアエージェントの接続を中継するには、ソフトウエアエージェントの設定で接続先の Pandora FMS サーバのアドレスとしてプロキシモードのエージェントのアドレスを指定します。例えば次の通りです。

Our agent with Proxy Mode enabled has this IP: 192.168.100.24

プロキシモードが有効なエージェントの IP アドレスが、192.168.100.24 とします。

In the software agent that can't connect directly with Pandora FMS server we configure the parameter server_ip with this IP:

直接 Pandora FMS サーバへ接続できないソフトウエアエージェントでは、server_ip パラメータを次のように設定します。

server_ip 192.168.100.24


With this configuration the software agent with limited communication will use the software agent in Proxy Mode to communicate with Pandora's server, keeping all its functionalities such as remote configuration, policies or file collections.

この設定により、Pandora FMS サーバと直接通信ができないソフトウエアエージェントが、プロキシモードの他のソフトウエアエージェントを経由して通信できるようになります。リモート設定、ポリシー、ファイルコレクションといったすべての機能が利用できます。

ブローカーモード

The software agent has a Broker Mode that allow one agent to monitor and manage the configuration as if several software agents would be installed.

ソフトウエアエージェントには、複数のソフトウエアエージェントがインストールされているかのように一つのエージェントを設定し、モニターするブローカーモードがあります。



When the broker mode is activated in a software agent, a new configuration file is created. From that moment on, the original software agent and the new broker will be managed separately with their independent configuration files, as if they were two completely separate software agents on the same machine.

ブローカーモードを有効にしたソフトウエアエージェントは、新たな設定ファイルを生成します。同一のマシンで複数のソフトウエアエージェントを動かすのと同じように、オリジナルのソフトウエアエージェントと新たなブローカーがそれぞれの設定ファイルで動作します。

The main features of Broker Mode are:

ブローカーモードのメインの機能は次の通りです。

  • Send local data as other agent. Very useful to monitor different software instances as different agents.
  • ローカルのデータを他のエージェントとして送信します。異なるソフトウエアの状態を異なるエージェントとしてモニタリングするのに便利です。
  • Send data collected from remote checks to other machines as if a software agent had been installed on them.
  • リモートチェックを行ったデータを、ソフトウエアエージェントがインストールされているマシンから送られたかのように送信します。

To create a broker, you're only required to add a line with the parameter broker_agent <broker_name>. It is possible to create as many broker agents as we want, just by adding the corresponding broker_agent lines, as follows:

ブローカーを設定するには、broker_agent <ブローカー名> という設定行を追加するだけです。次のように、必要な数分 broker_agent の設定行を追加するだけで複数のブローカーを作成することが可能です。

broker_agent dev_1
broker_agent dev_2

Once the brokers were created the configuration files dev_1.conf and dev_2.conf will be created with the same content that in the original software agent only the agent name will be changed. Adding or deleting modules from configuration files dev_1.conf and dev_2.conf we can customize the checks performed by the brokers.

ブローカーを設定したら、オリジナルのソフトウエアエージェントの設定と同じような内容で、エージェント名の設定が異なる dev_1.conf および 'dev_2.conf ファイルを作成します。dev_1.conf および dev_2.conf の設定ファイルでのモジュール追加、削除をすることで、ブローカーの設定を変更します。

Inside Pandora FMS web console the brokers appear and are managed as the other agents. It means that if we have a software agent installed with two brokers, in the web console we will see three different agents with their modules, configurations, etc.

Pandora FMS ウェブコンソールで、プローカーが表示され、他のエージェントと同じように管理できます。2つのブローカーでソフトウエアエージェントをインストールしていれば、ウェブコンソールでは、異なる 3つのエージェントでそれぞれのモジュールや設定が参照できることを意味します。

NOTE: broker agent instances cannot use file collections. If you want to use collections, you can "execute" files from collections from a instance, but must be distributed by the "main" agent, not in an instance.

注意: ブローカーエージェントインスタンスは、ファイルコレクションを利用できません。コレクションを利用したい場合は、インスタンスのコレクションからファイルの "実行" ができますが、インスタンスではなく "メイン" エージェントで配布する必要があります。

NOTE: modules that keep data in memory between executions (module_logevent and module_regexp on Windows) will not work when broker agents are enabled.

注意: ブローカーエージェントが有効な場合、実行中にメモリ内にデータを保持しているモジュール (module_logevent と Windows における module_regexp) は動作しません。

利用例

異なるエージェントとしてのローカルデータベースのモニタリング

We want to monitor the basic parameters of a machine (CPU, memory and disk) and also there is a database installed that we want to monitor separately.

マシンの基本的な情報(CPU、メモリ、ディスク)および、インストールされているデータベースの情報を分けてモニタリングしたいとします。

To perform this monitoring we will use the following structure:

このモニタリングを行うには次のような手段をとります。

  • Software agent installed: monitoring CPU, memory and disk.
  • インストールしたソフトウエアエージェント: CPU、メモリ、ディスクをモニタします。
  • Broker for database: monitoring internal status of database.
  • データベース用のブローカー: データベース内の状態をモニタします。

To do this we install the software agent in the machine to monitor CPU, memory and disk. In the software agent configuration we add the following line:

これを行うには、ソフトウエアエージェントを CPU、メモリ、ディスクをモニタするマシンにインストールします。ソフトウエアエージェントの設定で次の行を追加します。

broker_agent DBApp

With this line we create a broker agent called DBApp because of that a configuration file named dbapp.conf will appear. In this configuration file we add the modules to perform checks to database:

この設定を追加することにより、DBApp というブローカーエージェントを作成します。それにより、dbapp.conf という設定ファイルができます。この設定ファイルには、データベースの状態をチェックするモジュールを追加します。

module_begin
module_name Num Users
module_type generic_data
module_exec get_db_users.pl
module_end

module_begin
module_name Num slows queries
module_type generic_data
module_exec get_db_slows_queries.pl
module_end

With this you will see two agents in Pandora web console one with the name of the machine and with the modules CPU memory and disk and the other called DBApp with the modules Num Users and Num slows queries.

これにより、Pandora ウェブコンソールに 2つのエージェントが現れます。一つはマシン名で CPU、メモリ、ディスクのモジュールがあり、もう一つは、DBApp という名前で Num Users および Num slow queries というモジュールがあります。

ブローカーを使ったリモートデバイスのモニタリング

For this example we have a software agent installed in a Windows machine monitoring (CPU, memory and disk) and we need to monitor a router with IP 192.168.100.54 without installing an agent inside. To solve the problem we can use brokers.

この例では、Windows マシンにソフトウエアエージェントをインストールし、(CPU、メモリ、ディスクを)モニタリングしています。また、エージェントのインストールなしに 192.168.100.54 の IP を持ったルータをモニタリングしたいとします。この問題を解決するためにブローカーを利用できます。

We create a borker using the parameter;

次の設定で、ブローカーを作成します。

broker_agent routerFloor5

With this line we create a boker agent with the name routerFloor5 and because the software agent were installed in a Windows machine we can monitor the router using the ping and snmp modules available for Windows software agents. To do that we modify the file routerFloor5.conf adding the lines:

これにより、routerFloor5 という名のブローカーエージェントを作成します。ソフトウエアエージェントが Windows マシンにインストールされているので、Windows のソフトウエアエージェントの機能で ping および snmp でルータをモニタできます。それには、routerFloor5.conf ファイルに次の設定を行います。

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name Eth 1 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.1
module_end

module_begin
module_name Eth 2 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.2
module_end

In this example the web console of Pandora FMS shows two agents, one is the Windows machine with the modules CPU, memory and disk and the other is routerFloor5 with the modules: Ping, Eth 1 up and Eth 2 up.

この例では、Pandora FMS のウェブコンソールには 2つのエージェントが表示されます。一つは CPU、メモリ、ディスクのモジュールを持った Windows マシン、もう一つは、Ping、Eth 1 up、Eth 2 up というモジュールを持った routerFloor5 です。

直接通信できないネットワークのリモートモニタリング

In some cases is needed to monitor devices remotely but Pandora FMS Remote Server can't access to them directly.

デバイスをリモートからモニタする必要があるが、Pandora FMS のリモートサーバがそれらに直接通信できない場合があります。



In this example we must monitor remotely the devices of one of the company sites from the headquarters. Pandora FMS server is in the headquarters connected to the other company sites using a VPN, due to some restrictions the Pandora Remote Server can't access the machines remotely. To monitor the company sites we will use the Broker Mode that allows a software agent to send XMLs to Pandora server as if it would be several different devices.

この例では、本社からある会社のサイトのデバイスをリモートからモニタする必要があるとします。Pandora FMS サーバは本社にあり、他の会社のサイトに VPN で接続しています。何らかの制限により Pandora のリモートサーバはリモートでアクセスできません。会社のサイトをモニタリングするには、ブローカーモードを使います。ソフトウエアエージェントは、異なるデバイスとして Pandora サーバに XML を送信できます。

In the configuration file of software agent we add as many brokers as devices to be monitored. A configuratio example could be:

ソフトウエアエージェントの設定ファイルでは、モニタするデバイスの数だけブローカーを追加します。設定例は次の通りです。

broker_agent device_1
broker_agent device_2
broker_agent device_3
broker_agent device_4
...

Once the broker were created we can customize the monitoring for each devices modifying the configuration file of each broker. For example the configuration for the Windows machine called device_1 is:

ブローカーが作成されると、それぞれのデバイスのモニタリングをそれぞれのブローカーの設定ファイルで設定できます。例えば、Windows マシンで、device_1 の設定は次の通りです。

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

With this configuration we are able to make a remote configuration and send the files to Pandora FMS server in spite of the communication restrictions between the company's headquarters.

この設定で、異なる会社のサイト間で通信に制限があったとしても、リモート設定機能を利用でき、また、モニタした情報を Pandora FMS サーバへ送信することができます。

ブローカーを使ったモニタリング負荷分散

The Broker Mode is very useful to distribute the monitoring load within several network points.

ブローカーモードは、複数のネットワークでモニタリングの負荷を分散するのにとても便利です。



In this example our architecture has several networks named from A to Z with 1000 devices each one. The capacity of Pandora FMS Remote Server is about 2000 agents, because of that we decide to use software agents with Broker Mode enabled to distribute the load. These software agents with Broker Mode enabled monitor remotely all devices from the network and send the data in XML format to Pandora FMS central server.

この例では、A から Z の複数のネットワークがあり、それぞれ 1000のデバイスがあります。Pandora FMS のリモートサーバの許容量は、役 2000エージェントです。そのため、負荷分散のためにブローカーモードでソフトウエアエージェントを利用することにします。ブローカーモードを有効にしたソフトウエアエージェントは、リモートでネットワークから全てのデバイスをモニタし、データを XML で Pandora FMS の中央サーバへ送ります。

For each network we have an agent with Broker Mode enabled, inside it we create as many brokers as devices to be monitored, configuration for the software agent Broker_Agent_Net_A would be:

それぞれのネットワークに、ブローカーモードを有効にしたエージェントがあります。モニタするデバイスの分だけブローカーを作成します。ソフトウエアエージェントの Broker_Agent_Net_A の設定は次のようになります。

broker_agent device_1
broker_agent device_2
broker_agent device_3
broker_agent device_4
...

In addition for each broker we will add the modules to monitor the devices. For example the broker device_1 which is a router would have this configuration:

さらに、それぞれのブローカーには、モニタするデバイスのモジュールを追加します。例えば、ブローカー device_1 はルータで、次のような設定です。

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name Eth 1 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.1
module_end

module_begin
module_name Eth 2 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.2
module_end

Another example would be the broker device_2 which monitors a Windows machine with the following modules:

他の例として、ブローカー device_2 は次のようなモジュールで Windows マシンをモニタします。

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

Using software agents with Broker Mode enabled we can share the load to collect data from thousand of devices easily.

ソフトウエアエージェントをブローカーモードを有効にして使うことで、数千のデバイスからのデータを簡単に負荷分散して収集することができます。

ソフトウエアエージェントを使ったインベントリ

Pandora FMS software agent support inventory features for both hardware and software. The inventory system allows you to get a history of CPU, cards, memory, patches, software, etc … used in the company servers. Furthermore is possible to generate alerts when a change occurs in the inventory, for example if a disk was replaced or if an application was deleted.

Pandora FMS ソフトウエアエージェントは、ハードウエアおよびソフトウエアのインベントリの機能をサポートします。インベントリシステムは、企業のサーバで使われている CPU、拡張カード、メモリ、パッチ、ソフトウエアなどの情報を取得することができます。また、インベントリに変化が発生したときにアラートを上げることもできます。例えば、ディスクを交換したり、アプリケーションが削除されたときです。

You can find more information in section Local Inventory with Software Agents .

より詳細の情報は、ソフトウエアエージェントによるローカルインベントリを参照してください。

UDP リモートコマンド

エージェントからのオンデマンドでの情報提供

Pandora FMS software agent includes the UDP Server functionality, which allows to remotely indicate actions to an agent, such as restarting or executing a command.

Pandora FMS ソフトウエアエージェントは、UDP サーバ 機能を持っています。これは、リモートから再起動やコマンドの実行など、エージェントに対してアクションを実行させることができます。

The basic configuration parameters of the UDP Server in the software agents are:

ソフトウエアエージェントにおける UDP サーバの基本的な設定パラメータは次の通りです。

  • udp_server: enables (1) or disables (0) this functionality.
  • udp_server_port: listening port of the UDP server in the software agent.
  • udp_server_auth_address: IP address where the UDP server accepts requests. You can set it to 0.0.0.0.0 to accept from all origins.
  • udp_server: この機能を有効化(1)または無効化(0)します。
  • udp_server_port: ソフトウエアエージェントの UDP サーバのリスニングポートです。
  • udp_server_auth_address: UDP サーバがリクエストを受け付ける IP アドレスです。0.0.0.0 に設定すると、すべての発信元からのリクエストを受け付けます。

Configuration example :

設定例:

udp_server 1
udp_server_port 41122
udp_server_auth_address 0.0.0.0

Now, to force the restart of the agent we must use the script udp_client. pl, present in the Pandora FMS server, and normally located in /usr/share/pandora_server/util. We can run it from the command line or use it in an alert, making use of the command that comes pre-configured in the "Remote agent control" console.

ここで、エージェントの再起動を行うためには、Pandora FMS サーバに付属する udp_client.pl スクリプトを利用します。通常は、/usr/share/pandora_server/uitl 以下にあります。コマンドラインまたは、コンソールにあらかじめ設定されているリモートエージェントコントロールのコマンドを使って、アラート処理として実行できます。

There is also a default alert action called Restart agent, which uses this script. It uses the action REFRESH AGENT on the script udp_client. pl to restart the agent if it has the UDP server listening.

デフォルトのアラートアクションとして存在する Restart agent は、このスクリプトを利用しています。これは、UDP サーバが有効なエージェントを再起動するために、udp_client.pl スクリプトで REFRESH AGENT アクションを行います。



Please follow these steps to enable the Software Agent's remote refresh option:

ソフトウエアエージェントのリモート再起動オプションを有効化するには、次のようにします。

1. In the configuration file, set up the options for the software agent (UNIX or Windows). Please be mindful on the authorized IP address (is the Pandora FMS server behind a NAT ?), or just put '0.0.0.0' in the field to allow any IP address to force a refresh of the agent.

1. ソフトウエアエージェント (Unix または Windows) の設定ファイルのオプションを設定します。接続を受け付ける IP アドレス (Pandora FMS サーバが NAT 配下にいる場合など) に注意してください。0.0.0.0 を指定すると、すべての IP アドレスからの接続を受け付けます。

2. Restart the software agent for the changes to apply.

2. 変更を反映するために、ソフトウエアエージェントを再起動します。

3. Associate the Restart agent alert to the module of some agent (it is necessary that this agent has the IP address correctly configured).

3. エージェントのモジュールに Restart agent アラートをつけます。(エージェントの IP アドレスが正しく設定されている必要があります。)

4. Force the execution of the alert or force an incorrect state of the module to trigger the alert.

4. アラートを発報するために、アラートの強制実行を行うか、モジュールを強制的に障害状態にします。

Now thanks to this action, it is possible to manually force the alert at any time to refresh the agent software remotely and get the information quickly.

これにより、リモートから任意のタイミングエージェントソフトウエアの再起動を強制することができ、情報をすぐに取得することができます。

カスタムリモートコマンド

Apart from the Refresh agent command, you can specify new and custom actions to perform by the agents under the Pandora server's orders.

エージェントのリフレッシュコマンドとは別に、Pandora サーバからの要求によりエージェントでカスタムアクションを実行することができます。

If you're interested, you need to make a slight modification in pandora_server.conf, apart from enabling udp server, as shown before:

その場合は、pandora_agent.conf で以下のように udp サーバを有効化するのに加えて若干設定を行います。

udp_server 1
udp_server_port 41122
udp_server_auth_address <server IP>

Then you have to add a line for each custom command you want to perform, following this syntax:

次のように、実行したいカスタムコマンドごとに 1行を追加します。

process_nameofthecommand_start <command>

For example, if you wanted to create a custom command to start sshd service, you would have to add a line such as this:

例えば、sshd サービスを起動させるカスタムコマンドを追加したい場合は、次のような行を追加します。

process_sshdproc_start /etc/init.d/sshd start

Then you have to create a new alert action at Pandora Console for each remote command you made. You can copy the "Remote agent control" action, which is already prepared to send udp commands. Set "START PROCESS sshdproc" on Field 1.

作成したリモートコマンドごとに、Pandora コンソールで新たなアラートアクションを作成する必要があります。すでに udp でコマンドを送信する設定がされている "Remote agent control" アクションをコピーすると良いでしょう。フィールド1 に、"START PROCESS sshdproc" を設定します。



Now you only need to set a new Manual alert with the new alert action on the agent whose sshd service you wanted to start. This way, you'll be able to send the start command just through manually forcing the alert.

sshd サービスを起動させたいエージェントで、新たなアラートアクションで新たな手動アラートを設定する必要があるだけです。これにより、手動でアラートを実行することにより、起動コマンドを発行することができます。

Info.png

Custom orders can also be created to execute scripts. This allows a huge variety of remote actions to be performed on a remote agent just by clicking a button.


Info.png

スクリプトの実行順序も作成することができます。これで、"アラートの強制" をクリックすることにより、さまざまなリモートアクションをリモートエージェントで実行することができます。


ソフトウエアエージェントでのプラグインの利用

They are characterized by performing complex advanced checks from the software agents, being able to return several modules as a result instead of a single value. Unlike the server plugins, which are executed by Pandora FMS server, the agent plugins return their data in an XML, reporting one or several modules at the same time.

プラグインは、ソフトウェアエージェントから複雑で高度なチェックを実行することができるものです。単一の値だけではなく、複数のモジュールを返すことができます。 Pandora FMS サーバによって実行されるサーバプラグインとは異なり、エージェントプラグインはXMLでデータを返し、同時に1つまたは複数のモジュールのデータを返します。

Windows システムでの実行

In Windows, all the default plugins are programmed in VBScript, to run them you need to use the appropriate interpreter indicating the full path.

Windows では、デフォルトの全プラグインは、VBScript でプログラムされています。これらを実行するには、フルパスで適切なインタプリタを使用する必要があります。

Here are some examples of how to use the default plugins included in the Windows agent:

以下に、Windows エージェントにデフォルトで含まれているプラグインのいくつかの使い方を示します。

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\logevent_log4x.vbs" Application System 300
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df.vbs"
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\ps.vbs" iexplore.exe myapp.exe

Windows エージェントでは、さまざまなプラグインを使用できます。

Unix システムでの実行

Unix plugins are by default in the directory "/plugin" of the agent directory, in /etc/pandora/plugins, so it would not be necessary to use the full path in its execution if they are in this directory.

Unix プラグインは、デフォルトでエージェントのディレクトリの "/plugin" 以下、/etc/pandora/plugins にあります。そのため、このディレクトリにある限りは実行時にフルパスを指定する必要はありません。

Here are some examples of using plugins:

いくつかのプラグイン利用例を以下に示します。

 module_plugin grep_log /var/log/syslog Syslog .
 module_plugin pandora_df tmpfs /dev/sda1

The Unix software agent comes with several plugins by default ready to function.

Unix ソフトウエアエージェントには、デフォルトでいくつかのプラグインが含まれています。

プラグインの利用例

Plugins for the software agent can return a single data or a group of data. An example of a plugin that returns a data can be the Windows ps. vbs plugin, which simply checks if a process is running. With the next line we run the plugin:

ソフトウエアエージェントのプラグインは、一つのデータもしくはグループ化したデータを返すことができます。Windows で一つのデータを返す ps.vbs の例を示します。次の設定でプラグインを実行します。

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\ps.vbs" IEXPLORE.EXE

The result will be a module that return 0 if the process is down and 1 if the process is running:

プロセスがダウンしている場合は 0 を返し、プロセスがいる場合は 1 を返すモジュールです。

<module>
    <name><![CDATA[IEXPLORE.EXE]]></name>
    <description><![CDATA[Process IEXPLORE.EXE status]]></description>
    <![CDATA[1]]>
</module>

An example of a plugin that returns several data could be the plugin df.vbs for Windows. The line to execute the plugin would be:

次に Windows で複数のデータを返す df.vbs プラグインの例を示します。次の設定でプラグインを実行します。

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df.vbs"

The plugin returns a module per disk found, the result would be:

プラグインは見つけたモジュールごとにモジュールを返します。出力結果は次の通りです。

<module>
    <name><![CDATA[C:]]></name>
    <description><![CDATA[Drive C: free space in MB]]></description>
    <![CDATA[8050]]>
</module>

<module>
    <name><![CDATA[D:]]></name>
    <description><![CDATA[Drive D: free space in MB]]></description>
    <![CDATA[900]]>
</module>

コンソールからのエージェントプラグインの管理

In the Enterprise version it is possible to manage the software agent plugins from the console without directly editing the configuration file.

Enterprise 版では、設定ファイルを直接編集することなく、コンソールからエージェントプラグインを管理することができます。

If an agent has the remote configuration activated, the plugin editor tab is available in its administration view.

エージェントのリモート設定が有効化されていれば、管理画面にプラグイン編集タブが表示されます。

\



ファイル:Plugin editor tab.png

This section shows the list of the active plugins in the agent, and allows you to delete, add or deactivate them. In the case of policy plugins, it may be useful to disable them because they will remain disabled when the policy is re-applied.

ここでは、エージェントで有効なプラグインの一覧が表示され、削除、追加、無効化を行うことができます。ポリシープラグインの場合、プラグインを無効化するのが便利です。なぜなら、ポリシーが再度適用された場合、プラグインは無効化されたままになるからです。



800px

The plugins managed in this editor can also be edited from the agent configuration file.

このエディタから管理されるプラグインは、エージェント設定ファイルでも編集できます。



800px

独自エージェントプラグインの作成方法

Plugins can be created in any programming language. They only have to respect these restrictions:

プラグインは、任意のプログラミング言語で作成することができます。以下の制約を守ってください。

  • Regardless of what we want to do, it must be automatic (without user interaction), and must be done from the shell. You can use any type of scripting language or compiled language, but in that case you must also distribute, in addition to the executable, all libraries (or DLL) that are necessary for the plugin to run.
  • やりたいことが自動実行されます (インタラクティブな実行ではありません)。そのため、事前にコマンドライン (シェル) で動作確認をしてください。どんな種類のスクリプト言語やコンパイル言語でも利用できます。なお、それを実行するために必要な依存ファイル (ライブラリ、dll 等) も用意する必要があります。
  • The plugin must return the information through the standard output (simply using echo, printf or the equivalent in the language that will be used for the plugin), and must use the XML format of Pandora FMS agents to return the information.
  • プラグインは、標準出力に情報を出力しなければなりません (echo や printf など各言語に応じたコマンドにて)。また、Pandora FMS エージェントが情報を返すフォーマットとして XML を利用する必要があります。

This is an example of a numerical module in XML:

以下に、数値モジュールの XML の例を示します。

<module>
<name><![CDATA[Sample_Module]]></name>
<type><![CDATA[generic_data]]></type>
<![CDATA[47]]>
<description><![CDATA[47]]></description>
</module>

The data contained in the <!CDATA[xxx]]> are used to protect XML from certain information that may contain "difficut" characters for XML, such as <, >, & or %.

<![CDATA[xxx]]> は、データを示す記述として使われ、XML で <、>、& や % などの文字を正しく扱えるようにするためのものです。

Before trying to create a plugin, visit the Pandora FMS plugin library at https://library.pandorafms.com, and if you decide to create your own plugin, send it to the public library, so that others can use it.

独自プラグインを作成する前に、http://pandorafms.org にある Pandora FMS プラグインライブラリを参照してください。また、独自プラグインを作成したら、他のユーザが使えるように是非ライブラリにアップロードしてください。

Template warning.png

Make sure you finish the output of your plugin (if it is a script) with an error level 0 or the agent will interpret that the plugin has had an error and wasn't able to run.


Template warning.png

カスタムプラグインの終了コードは 0 になるようにしてください。そうでないと、Pandora FMS エージェントはプラグインでエラーが発生したものと認識し、出力を無視します。


シェルスクリプト(Linux/Unix)によるプラグインの例

#!/bin/bash
# Detect if local Mysql is without password
# First, do we have a running MySQL?
CHECK_MYSQL=`netstat -an | grep LISTEN | grep ":3306 "`
if [ ! -z "$CHECK_MYSQL" ]
then

        CHECK_MYSQL_ROOT=`echo "select 1234" | mysql -u root 2> /dev/null | grep 1234`
        if [ -z "$CHECK_MYSQL_ROOT" ]
        then
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>1</data>"
        echo "<description>MySQL have a password</description>"
        echo "</module>"
        else
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>0</data>"
        echo "<description>MySQL do not have a password</description>"
        echo "</module>"
        fi
fi

exit 0

VBScript (Windows) によるプラグインの例

' df.vbs
' Returns free space for avaible drives.
' --------------------------------------

Option Explicit
On Error Resume Next

' Variables
Dim objWMIService, objItem, colItems, argc, argv, i

' Parse command line parameters
argc = Wscript.Arguments.Count
Set argv = CreateObject("Scripting.Dictionary")
For i = 0 To argc - 1
    argv.Add Wscript.Arguments(i), i
Next

' Get drive information
Set objWMIService = GetObject ("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery ("Select * from Win32_LogicalDisk")

For Each objItem in colItems
	If argc = 0 Or argv.Exists(objItem.Name) Then
		If objItem.FreeSpace <> "" Then
			Wscript.StdOut.WriteLine "<module>"
			Wscript.StdOut.WriteLine "    <name><![CDATA[" & objItem.Name & "]]></name>"
			Wscript.StdOut.WriteLine "    <description><![CDATA[Drive " & objItem.Name & " free space in MB]]></description>"
			Wscript.StdOut.WriteLine "    <data><![CDATA[" & Int(objItem.FreeSpace /1048576) & "]]></data>"
			Wscript.StdOut.WriteLine "</module>"
            Wscript.StdOut.flush
		End If
	End If
Next

エージェントでの nagios プラグインの利用

Nagios has a large number of plugins that you can use with Pandora FMS. One way to do this is to use remote plugins with the Plugin Server, using Nagios compatibility. But in this way, you will only get the statuses, since it does not use the descriptive output that some plugins for Nagios have.

Nagios には多くのすばらしいプラグインがあり、Pandora FMS で利用することができます。プラグインサーバで nagios 互換モードを使ってリモートでプラグインを利用することができますが、ステータスを取得するのみで、いくつかの nagios プラグインが持っている詳細情報を扱うことができません。

Using the wrapper to use Nagios plugins in the software agent will solve this problem. The wrapper comes by default with the Unix 3.2 agent. An equivalent plugin for Pandora FMS Windows agents can be downloaded from the Pandora FMS resource library, at [2]).

ソフトウエアエージェントで nagios プラグインラッパーを使うことで、この問題が解決します。ラッパーは、バージョン 3.2 の Unix エージェントにデフォルトで付属しています。Pandora FMS Windows エージェント用の同様のプラグインは、http://pandorafms.com のリソースライブラリ [3] からダウンロードできます。

What does the plugin wrapper do for Nagios plugins?

nagios プラグイン用のプラグインラッパーは何をするのでしょうか。

It executes the Nagios plugin, using its original parameters and converting the output into useful data for Pandora FMS. It has two types of information:

nagios プラグインをそれ独自のパラメータを使って実行し、出力データを Pandora FMS で使いやすいように、次のような 2種類のデータに変換します。

  • Status information: NORMAL (1), CRITICAL (0), WARNING (2), UNKNOWN () and other (4). By default, it will use a proc module, so NORMAL and CRITICAL values are working "by default"; if you want to have information on WARNING and OTHER values you should setup the module thresholds manually.
  • ステータス情報: 正常(1)、異常(0)、警告(2)、不明() および、その他(4)。デフォルトでは、proc モジュールを利用します。正常および異常状態は、デフォルトで認識します。もし、警告やその他の状態を利用したい場合は、手動でモジュールのしきい値を設定してください。
  • Descriptive information: Usually string information, will be put on the description field on module, this is usually something like "OK: successfully logged in" or similar.
  • 詳細情報: 通常は文字列データで、モジュールの説明フィールドに入ります。例えば、"OK: successfully logged in" といったかたちになります。

If you have a pop3 plugin (in /tmp/check_pop3_login) with the run permissions, (which checks if the pop3 account is working only by connecting to a remote host, sending a user and password and displaying everything is correct), then you can run it from the command line:

実行権限がついた pop3 プラグイン (/tmp/check_pop3_login) があったとします。これは、pop3 アクセスが正常かどうかチェックします。リモートホストに接続し、ユーザ名とパスワードを送信し、問題ないかを確認します。コマンドラインからは、次のように実行できます。

/tmp/check_pop3_login  mail.artica.es sanler@artica.es mypass

It will return something like:

次のような結果が返ってきます。

OK: successfully logged in.

And if it's not ok, will return :

異常の場合はつぎのようになります。

Critical: unable to log on

Using the wrapper is simple, just need to put the wrapper and the module name you want before the call:

ラッパーの利用は簡単で、コマンドの前に、ラッパーとモジュール名を設定します。

/etc/pandora/plugins/nagios_plugin_wrapper sancho_test /tmp/check_pop3_login  mail.artica.es sanler@artica.es mypass

It will generate a full XML for agent plugin:

これで、エージェントプラグイン用に完全な XML を生成します。

<module>
<name>sancho_test</name>
<type>generic_proc</type>
0
<description><![CDATA[Critical: unable to log on]]></description>
</module>

Or:

または、

<module>
<name>sancho_test</name>
<type>generic_proc</type>
1
<description><![CDATA[OK: successfully logged in.]]></description>
</module>

The full entry in the pandora_agent.conf will be something like:

pandora_agent.conf の全設定は次のようになります。

module_plugin nagios_plugin_wrapper POP3_artica.es /tmp/check_pop3_login mail.artica.es sanler@artica.es mypass

This will be seen like this in the module like (on fail event):

これは、モジュール内で次のように表示されます。(障害時)


KeepAlive によるモニタリング

There is a special module, has a unique type called "keep_alive" and it's used to give information in the absence of contact with the agent. It is useful to know when an agent has stopped sending information and alerting us of this fact.

特別なモジュールがあります。"keep_alive" と呼ばれる独特なもので、エージェントからの接続がないことを知るのに便利です。エージェントが情報を送信を停止した場合、それを通知するのに利用します。

When there is a module, remote or local, that obtains information from the agent, the date of last "contact" with the agent is updated, so that whenever there is data, even if it is only one module of the total, the agent will have updated its date of last contact, which is useful to know if the agent "does not respond". Specifically, an agent is considered "dead" when it has not updated its date in twice the time of its interval, that is, if it has an interval of 5 minutes, and more than 10 minutes ago there is no update, the agent is considered dead.

エージェントに情報を取得するリモートもしくはローカルのモジュールがある場合、エージェントの最新の "接続" が更新されます。全モジュールの中の一つのモジュールでもデータが更新されれば、最新の接続日時が更新されます。これは、エージェントが "応答しているかどうか" を知るのに便利です。正確には、その間隔の 2倍の時間データが更新されないと、エージェントは "停止" と認識します。エージェントの間隔が 5分であれば、10分以上更新されなければ、"停止" と認識します。

This is the case when the keepalive module comes into play, triggering and marking the monitor into Critical status.

keepalive モジュールが設定されている場合、それを通知し異常状態にします。

The configuration of this type of modules is very easy, just create a new module type "KeepAlive".:

このモジュールの設定はとても簡単です。新たに "KeepAlive" タイプのモジュールを作成すれば良いだけです。





Once created, if the agent has data, within its interval, it will always be in the "NORMAL" status (green):

作成されると、定義した間隔でエージェントからデータを取得できている間は、常に "正常" 状態(緑)になります。

Keepalive1.png


If the agent stops sending data (in this example, it had an interval of 1 minute), then it will automatically jump and be set to CRITICAL (red) status:

エージェントがデータ送信を停止した場合 (この例では、1分間隔にしています)、自動的に障害状態(赤)になります。



Keepalive2.png


It should be noted that if we have a remote module, for example, a Ping, in addition to the data reported by the agent, the keepalive module would never be triggered, since we are constantly updating the agent through Ping.

重要な点として、エージェントのデータ収集として Ping などのリモートモジュールが定義されている場合、keepalive モジュールは異常状態にはならないことに注意してください。なぜなら、Ping を通してエージェントの状態がアップデートされるためです。

The keepalive module also behaves like any other module, it can be associated with an alert and can be used for any other element: reports, maps, etc.

それ以外では、keepalive モジュールは他のモジュールと同じように動作します。アラートに関連付けることが可能ですし、レポート、マップ等、他の要素で利用することもできます。

Info.png

The keepalive module can be created only from the console (even if we don't have remote configuration enabled) and leaves no trace in the pandora_agent.con file.f


Info.png

keepalive モジュールは、(リモート設定が有効化されていない場合でも)コンソールからのみ作成できます。pandora_agent.conf には設定はありません。


コマンドスナップショットモニタリング

This way to monitor, possible from 4.0.3 version, allows administrator to use a special way to capture output from commands, different from parsing a single value or string. This module stores the information as text, but with the purpose to get the exact output of the command, not as single data. It will show you the same output format and contents as was return by the command.

このモニタリングは、バージョン 4.0.3 から対応しており、単一の値や文字列ではなくコマンドの出力結果をキャプチャするためのものです。このモジュールは、情報をテキストとして保存しますが、単一データではなくコマンドの出力結果全体を保存します。コマンドの出力結果をそのまま表示します。

An image is better than words, so:

言葉で説明するより画面がわかりやすいです。

This is the "netstat -an" command output, captured by Pandora FMS, after clicking in the special icon for command snapshot, only available when we got a multiline text -non splitted- output.

これは、Pandora FMS で "netstat -an" コマンドの出力をキャプチャしたものです。コマンドスナップショットのアイコンをクリックすると、複数行にわたる出力が表示されます。



These are the different "snapshots" among time. Pandora will show information only when the agent got different information (remember, datatype continues being generic_data_string), if you want to store each data (not recommended!) you can use async_string. Showing information only on chagnes is perfect to report data on problems, and compare other events with the information in the command snapshot for that timerange.

これらは、時間ごとに異なるスナップショットになります。Pandora は、エージェントが異なる情報を取得した場合にのみ情報を表示します(データタイプは、generic_data_string であることに注意してください)。毎回データを保存したい場合(お勧めはしません)は、async_string を利用します。変化があった場合の情報のみを表示することは、データに問題がある部分を確認したり、ある時間間隔におけるコマンドスナップショット内の変化を比較するのに便利です。

To capture the commands output in a snapshot, you need to write an small pluegin which send all data, adding also the XML tags, and executing the plugin as an standard pluegin, with module_plugin syntax. Let's see the following example, which generates output for command netstat, as you read before.

コマンド出力をスナップショットとして取得するためには、XMLタグ付きで全データを送信する簡単なプラグインを書く必要があります。また、module_plugin の書式で通常のプラグインと同様にプラグインを実行します。以下に、前述の netstat コマンドの出力を生成するスクリプト例を見てみましょう。

#!/bin/bash
echo "<module>"
echo "<name>netstat</name>"
echo "<type>generic_data_string</type>"
echo "<data><![CDATA["
netstat -an | grep LIST
echo "]]></data>"
echo "</module>"

Save this script contents in a file in the agent (or remotely distribute with file collections) and execute using this syntax:

このスクリプトをファイルに保存(ファイルコレクションでリモートから配布できます)し、エージェントから次のように実行します。

module_plugin <full path for file>

In this way, you will, the agent will generate command snapshot almost for any command (just replace "netstat...." by your command). Some useful suggestions for Unix systems are:

これにより、ほぼどんなコマンド("netstat...." の部分を任意のコマンドに置き換えてください)であっても、エージェントがコマンドのスナップショットを生成します。Unix システムでは、次のようなコマンドも便利です。

* top -b -n 1
* ps aux
* vmstat 1 5
* who 
* last -10

On Windows systems:

Windows システムでは、つぎのようなものがあります。

* tasklist
* netstat -an
* net start

Info.png

Remember that you need to do always inside an script, generating the XML. If you do that inside a module_exec call, each line reported by the command will be interpreted a line in different "data blocks", and you cannot see it as command snapshot.


Info.png

スクリプト内で XML を生成する必要があることに注意してください。module_exec で実行してしまうと、コマンドの実行結果の一行一行が異なるデータとなってしまい、コマンドスナップショットとして見ることができません。


画像の監視と表示

This way of monitoring, available from v 6.0 SP4 onward, allows you to define modules which contain images in text format, coded in base64, displaying the image in place of a specific result. This is stored as text data, but it is visualized as a reconstructed image.

この監視は、バージョン 6.0SP4 以降で可能です。base64 でエンコードされたテキストフォーマットで、画像を含むモジュールを定義することができ、結果に画像を表示することができます。データはテキストで保存されますが、画像として表示されます。

This is what a string output looks like with the content "data:image" (image in base64), captured by Pandora FMS, when you click on the 'capture image' icon:

'画像キャプチャ' アイコンをクリックしたときに、"data:image" (画像は base64) を含む文字列を Pandora FMS が検出します。


To capture images like this, you need to write a plugin which sends all the data and the required XML tags, and execute the plugin with the directive module plugin. The next example plugin generates an image output, as in previou example:

このように画像を表示するには、全データと必要な XML タグを送るプラグインを書き、モジュールプラグインとして実行する必要があります。以下のプラグインの例は、上記の画像を出力する例です。

#!/bin/bash
echo "<module>"
echo "<name>Current league leader</name>"
echo "<type>async_string</type>"
echo "<data><![CDATA[data:image/jpeg;base64,/9j/4AAQSkZ....]]></data>"

//the previous data would be generated by a device/application supplying images in base64.

echo "</module>"

Save the content in a file on an agent (or distribute it with a file collection) and execute:

上記のファイルをエージェント上で保存し(またはファイルコレクションで配り)し、次のように実行します。

module_plugin <ファイルへのフルパス>

パスワードでグループを保護する

By default, when an agent sends data for the first time to the Pandora FMS Server it is automatically added to whatever group is defined in the agent's configuration file. This means that, in practice, anyone can add agents to any group as long as its name is known. This could be a problem if your Pandora FMS instance is shared by multiple clients or you need tight control over what is in each group.

デフォルトで Pandora Server は、Pandora Agent からの最初のデータを受け取ると、pandora_agent.conf で指定されているグループにエージェントを作成します。これはつまり、グループ名が分かれば誰でもそのグループにエージェントを追加できることを意味します。これは 1台の Pandora Server を複数のクライアントで共有している場合など、エージェントのグループ分けを厳格に行いたい場合に問題になる可能性があります。

Starting from version 6.0SP5, you can optionally configure a password for a group from the Pandora FMS Console. An agent will not be added to a group unless the right password is specified in the agent's configuration file. Bear in mind that if the agent already belongs to the group the password is not checked.

バージョン 6.0SP5 から、グループに対してパスワードを設定できるようになりました。パスワードを設定した場合、pandora_agent.conf にも同じパスワードを指定しないと、エージェントは作成されません。パスワードがチェックされるのは初回のエージェント作成時のみです。作成済みのエージェントに対してパスワードチェックは行われません。

To configure a password for a group, navigate to the group editor and click on edit:

グループパスワードを設定するには、Pandora Console の'エージェントグループ管理' 画面で編集アイコンをクリックします:

 <screenshot>

Then enter the group password and save your changes:

パスワードを入力して保存します:

 <screenshot>

To add a new agent to this group, edit its configuration file (pandora_agent.conf) and append the following configuration option:

このグループにエージェントを作成したい場合は、pandora_agent.conf に以下の設定を追加します:

 group_password <password>

Finally, restart the agent. You should see the newly created agent in your Pandora FMS Console:

設定を追加したら Pandora Agent を再起動して設定を反映し、Pandora Concole でエージェントが作成されることを確認します。


 <screenshot>

(OBSOLETE)

セカンダリグループ

From the update package 721, agents can have secondary groups. Unlike the main group, these secondary groups are optional.

バージョン 721 から、エージェントはセカンダリグループを持つことができます。メインのグループとは異なり、セカンダリグループはオプションです。

The fact that an agent belongs to a secondary group means that, in fact, it belongs to several groups at the same time. With this functionality, two users who have very different permissions will be able to access the same agent just by adding the appropriate secondary groups to it.

エージェントがセカンダリグループに属するということは、エージェントが同時に複数のグループに属することになります。この機能により、まったく異なる権限をもつ 2つのユーザがいた場合に、適切なセカンダリグループを追加することによって同じエージェントにアクセスすることができます。

(OBSOLETE)サービスモニタリング

概要

Unlike as with the "specific" monitoring, where there are kept specific values from specific indicators, the service monitoring with Pandora FMS is though to monitor "groups" of elements, from different kind, with certain "margin of error", based on the failure accumulation.

Pandora FMS でのサービスのモニタリングは、ある特定の値だけのモニタリングではなく、異なる種類の要素グループのモニタによる複数の障害情報に基づいて実現します。

To understand better in which the service monitoring consist on, we are going to show an example.

サービスモニタリングどのように構成されるのか理解しやすいように、例を示します。

We want to monitor if the service that we are giving, through a WEB cluster, is "Ok". This cluster consist of the following elements:

我々は、サービスとしてのウェブクラスタが正常かどうかをモニタしたいとします。 このクラスタは、以下の要素から構成されます。

  • Two routers in HA.
  • HA 構成の 2つのルータ
  • Two switches in HA.
  • HA 構成の 2つのスイッチ
  • Twenty WEB Apache servers
  • 20 の apache サーバ
  • Four Weblogic appliance servers
  • 4つの Weblogic アプライアンスサーバ
  • One MySQL cluster of two storage nodes and two SQL processing nodes
  • 2つのストレージノードと 2つの SQL プロセスノードから成る 1つの MySQL クラスタ

It's possible to monitor each element in an individual way and, in fact it's the first thing we will need to activate the service monitoring "globally". Each element included in the service should be an "standard" monitor of the ones monitored with Pandora, that is, it's something PREVIOUS to the service monitoring.

それぞれの要素は個別にモニタリング可能です。実際、最初にサービスモニタリングを有効にする必要がありますが、サービスに含まれるそれぞれの要素は、Pandora で個別にモニタします。これは、サービスモニタリングの前に設定することです。

The need of monitoring services as something "abstract" appears when we ask ourselves this question: What happens when an element that initially is not critical? such as, for example, one of the twenty Apache servers. Firstly, we could not to warn, in fact, could be it has frequent falls, so there are 20 nodes, it shouldn't warn us for the fall of only one node ( let's imagine that this warning wake up someone who is sleeping. In fact, a service with so many redundance is for giving us more peace, not more work. It should only warn us if a more critical element is down (such as a router) or if "several" WEB servers are down, for example, four or five of them.

サービスモニタリングの概念として必要なこととして、このような疑問がでてきます。例えば、20 の apache サーバのうちの一つなど、一つの項目が障害状態だったとしても、全体としては障害では無いのではないだろうか。実際に、よくダウンするとしても 20ノードあるので警告でもないのではないだろうか。1ノードのダウンに対して警告は発するべきではありません (警告が 寝てる誰かを起こすことを考えてください)。実際、サービスは冗長化されており、より安全になっており、緊急作業は不要です。よりクリティカルな要素 (ルータなど) がダウンしたときや、4,5台の複数のウェブサーバダウンしたときに警告を発するべきです。

In this way, if we put "weights" to each element from our example:

次のように、それぞれの要素に "ウエイト" を付与します。

  • Switches and routers: 5 points for each one when there are in critical, and 3 points if they are in warning.
  • スイッチおよびルータ: 個々の障害状態の時は 5ポイント、警告状態の時は 3ポイント
  • WEB servers: 1.2 point for each one in critical. We don't consider the warning status.
  • ウェブサーバ: 個々の障害状態の場合は 1.2 ポイント、警告状態はポイント無し
  • WebLogic Servers: 2 points for each one in critical.
  • WebLogic サーバ: 個々の障害状態の場合は 2ポイント
  • MySQL cluster: 5 points for each node, 3 points in warning.
  • MySQL クラスタ: それぞれのノードに 5ポイント、警告状態で 3ポイント

We fix a warning threshold for the service of 4, and a critical threshold of 6. In this way, and supposing that all things are going ok the service would be "OK" if all the monitored elements are OK.

サービスを警告状態と判断する閾値を 4、障害状態と判断する閾値を 6 とします。すべてのモニタリング要素が正常であれば、サービスも正常です。

Now, suppose that ONE APACHE WEB server:

1台の apache サーバダウンが発生した場合は次のようになります。

  • 1 x Apache server in CRITICAL x 1.2 point = 1.2 so 1.2 < 4 (Warning), the service is still in the OK status
  • 1 x 障害状態の Apache サーバ x 1.2 ポイント = 1.2 となり、ここで、1.2 < 4 (警告) であるため、サービスの状態はまだ正常です。

See what happens if a WEB server and a Weblogic are down:

ウェブサーバと Weblogic サーバがダウンすると次のようになります。

  • 1 x APache server in CRITICAL x 1.2 point = 1.2
  • 1 x 障害状態の apache サーバ x 1.2 ポイント = 1.2
  • 1 x Weblogic server in CRITICAL x 2 = 2
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

Summarizing: 3,2 is still < 4, so the service is still in Ok status and without waking up the operator from the bed.

合計すると 3.2 となり、まだ < 4 です。そのため、サービスの状態はまだ正常です。オペレータが起きる必要はありません。

See what happens if two WEB servers and one Weblogic are down:

2台のウェブサーバと、1台の Weblogic サーバがダウンすると次のようになります。

  • 2 x Servidor Apache en CRITICAL x 1.2 point = 2.4
  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x Servidor Weblogic en CRITICAL x 2 = 2
  • 1 x 障害状態の Weblogic サーバ x 2 = 2

Then, 4,4 is now > 4 and the service for the WARNING status. It's possible that a urgent SMS has not been received from the operator yet, but it's sure that at least someone will receive an email. Let's continue with the example.

この場合、4.4 > 4 となり、サービスが警告状態になります。オペレータはまだ緊急の SMS を受信しませんが、少なくとも誰かがメールを受け取ります。引き続き例を見ていきましょう。

Supposing that besides the previous thing, one Router is down:

上記の状態に加え、1台のルータがダウンすると次のようになります。

  • 2 x Apache server in CRITICAL in x 1.2 point = 2.4
  • 2 x 障害状態の Apache サーバ x 1.2 ポイント = 2.4
  • 1 x Weblogic server in CRITICAL x 2 = 2
  • 1 x 障害状態の Weblogic サーバ x 2 = 2
  • 1 x Router in CRITICAL x 5 = 5
  • 1 x 障害状態のルータ x 5 = 5

We have already a 9,4 higher to the 8 threshold for CRITICAL, so the service is in critical and our operator has no other option than to wake up.

合計ポイントは 9.4 となり、障害状態の閾値である 8 を越えています。サービスは障害状態となり、オペレータは起きることになります。

The service monitoring is a feature only for the Pandora FMS Enterprise version.

サービスモニタリングは、エンタープライズ版の Pandora FMS のみにある機能です。

設定

The services represents association of modules which value is calculated in real time. The parameters that define a service are:

モジュールの関連付けで表現されるサービスの値は、リアルタイムで計算されます。 サービスを定義するパラメータは次の通りです。

  • Name:Name of the service.
  • 名前(Name):サービスの名称です。
  • Description:description of the service
  • 説明(Description):サービスの説明です。
  • Group:group the service belongs to
  • グループ(Group):サービスが属するグループです。
  • Critical:limit value from which the service is in critical state.
  • 障害(Critical):サービスが障害状態となる閾値です。
  • Warning:limit value from which the service is in warning state.
  • 警告(Warning):サービスが警告状態となる閾値です。
  • Value: value of the service. It's calculated in real time.
  • 値(Value):サービスの値です。リアルタイムで計算されます。
  • Status: state of the service depending on its value and the critical and warning limits.
  • 状態(Status):サービスの値や障害状態、警告状態を元にした、サービスの状態です。

Service list.png

The value of a service is calculated as the addition of the weights associated to the state of each module. Services, same as modules, has associated an state depending on its value. The modules that are associated to a service are configured with the following parameters:

サービスの値は、それぞれのモジュールの状態に関連付けられたウエイトの合計で計算されます。サービスモジュールの状態は、その値に関連付けられます。サービスモジュールは、次のパラメータで設定します。

  • Agent Name: name of the agent the module belongs to.
  • エージェント名(Agent Name): モジュールが設定されるエージェントの名前です。
  • Module Name: name of the module.
  • モジュール名(Module Name): モジュールの名前です。
  • Description: free description.
  • 説明(Description): 任意の説明です。
  • Weight Critical: weight when the module is in a critical state.
  • 障害ウエイト(Weight Critical): モジュールが障害状態となるウエイトです。
  • Weight Warning: weight when the module is in warning state.
  • 警告ウエイト(Weight Warning): モジュールが警告状態となるウエイトです。
  • Weight Ok: weight when the module is in normal state.
  • 正常ウエイト(Weight Ok): モジュールが正常状態となるウエイトです。
  • Data: value of the module.
  • データ(Data): モジュールの値です。
  • Status: state of the module.
  • 状態(Status): モジュールの状態です。

Service detail.png

In the previous example, the value of the service is the addition of the weights of modules Module_3 of Agent_1 and Module_3 of Agent_2. The module of the Agent_1 is on critical state, that has associate a weight of 3, and the Agent_2 module is in normal state, which has associated a weight of 0.

上の例では、サービスの値は、Agent_1 の Module_3 と Agent_2 の Module_3 のウエイトの合計です。Agent_1 のモジュールは障害状態で、ウエイトは 3です。Agent_2 のモジュールは正常状態で、ウエイトは 0 です。

If you adds up all the weights, then 3 + 0 = 3

ウエイトを合計すると、3 + 0 = 3 となります。

It's also possible to create modules associated to services, with the advantages that this implies (calculation periodicity, integration with the alert system, etc). The way to associate one module to a service is to follow the following steps:

モジュールは、サービスに関連付けて作成することができます (計算頻度、アラートシステムとの連携等を実装できます)。モジュールをサービスに関連付けする方法を以下に示します。

  1. Create the individual monitors that make up the service and make sure that they work well.
  2. サービスを構成する個々のモニタを作成し、それぞれが正しく動作することを確認します。
  3. Fix the individual thresholds for each monitor to define CRITICAL and/or WARNING states.
  4. 個々のモニタ項目の障害状態および、警告状態の閾値を調整します。
  5. Create a servoce with those monitors that we want, and define thresholds for the service and weights for each monitor included in the service.
  6. 上記で設定したモニタを元にサービスを作成し、サービスの閾値とサービスに含まれる個々のモニタ項目のウエイトを設定します。
  7. Go to the agent where we want to "locate" the monitor associated to the service.
  8. サービスに関連付けしたいエージェントの画面へ行きます。
  9. Create a new module of "prediction" kind associated to this agent, using the module editor of the Prediction server, in order to associate it to one of the services of the list.
  10. エージェントにサービスを関連付けするために、予測サーバのモジュールエディタを用いて、エージェントに新たに予測モジュールを作成します。
  11. If we want to associate alerts to the service, then we should do it on the module that is associated to the server. The server, as it is, has no possibilities of adding alerts, neither graphs or reports. All these has to be done through the monitor that is linked to the service, as we have described before.
  12. サービスにアラートを関連付けしたい場合は、サービスモジュールで設定します。サービス自体には、アラート、グラフ、レポートは追加できません。前述の通り、全てはサービスに関連付けしたモニタにて設定を行います。

Service module.png