プラグイン開発ガイド
概要
This plugin development guide contains documentation for users who wish to create their own plugins. Use this documentation to learn how to create plugins that solve your business needs.
このプラグイン開発ガイドには、独自のプラグインを作成したいユーザ向けのドキュメントが含まれています。 このドキュメントを使用して、ビジネスニーズを解決するプラグインを作成する方法を学習してください。
プラグインとは?
A computer add-on, also known as a plugin, is an application that allows you to extend the features of another application, in this case Pandora FMS.
プラグインとも呼ばれるコンピュータアドオンは、別のアプリケーション (この場合は Pandora FMS) の機能を拡張できるようにするアプリケーションです。
プラグインはなぜ便利なのか?
Plugins allow to extend Pandora FMS features, which offers a wide variety of possibilities when developing new options for monitoring.
プラグインを使用すると、Pandora FMS の機能を拡張できます。これにより、新しい監視オプションを開発する際にさまざまな可能性が提供されます。
By means of their use you may integrate service, application or database monitoring, among others, and much more, they can even be used to modify or automate tasks and processes.
それらを使用すると、サービス、アプリケーション、またはデータベースの監視などを統合でき、タスクや処理を変更または自動化するために使用することもできます.
One of the objectives is to be able to monitor as many systems and services as possible in the same work environment and the use of plugins helps a lot with that task.
目的の 1 つは、同じ作業環境でできるだけ多くのシステムとサービスを監視できるようにすることであり、プラグインの利用はそのタスクに大いに役立ちます。
Most plugins are useful to be able to display data or performance statistics collected from external services in Pandora FMS.
ほとんどのプラグインは、Pandora FMS の外部サービスから収集されたデータまたはパフォーマンス統計を表示できるようにするのに便利です。
Pandora FMS におけるプラグインタイプ
By execution type:
実行タイプ別:
- Agent plugin: Agent plugins are run by Pandora FMS software agent, they are usually local and do not work remotely so execution will be performed by the agent daemon. Agent plugins usually print an XML in their execution, modules with data.
- Server plugin: Server plugins are executed by the server plugin, they usually retrieve data remotely, either by API or another method, so although they can be configured as an agent plugin (mostly), the recommended option is to configure them as a server plugin. Server plugins print only one value, such as a
1
to indicate their successful execution.
- エージェントプラグイン: エージェントプラグインは Pandora FMS ソフトウェアエージェントによって実行されます。通常はローカルにあり、リモートでは動作しないため、エージェントデーモンによって実行されます。 エージェントプラグインは通常、実行時に XML を出力し、モジュールにはデータが含まれます。
- サーバプラグイン: サーバプラグインは プラグインサーバ によって実行され、通常は API または別の方法でリモートでデータを取得します。(ほとんどの場合)エージェントプラグインとして設定することもできますが、推奨されるオプションは、サーバプラグインとして設定することです。 サーバプラグインは、実行の成功を示す
1
などの 1 つの値のみを返します。
プラグインの見つけ方
Pandora FMS has a library from which you may download all plugins created for the system.
Pandora FMS には、システム用に作成されたすべてのプラグインをダウンロードできるライブラリがあります。
Anyone can upload plugins to the library, although there is a review process before these are accepted and published.
プラグインは誰でもライブラリにアップロードできますが、受け入れて公開する前にレビュープロセスがあります。
Currently the library has a large number of plugins that cover all fields, databases, applications, Cloud, messaging services…
現在、ライブラリには、すべての分野、データベース、アプリケーション、クラウド、メッセージングサービスなどをカバーする多数のプラグインがあります。
The library has a search engine with which you may search for any plugin uploaded to it, in addition to different tags and menus with which you may browse comfortably.
ライブラリには、快適に閲覧できるさまざまなタグやメニューに加えて、ライブラリにアップロードされたプラグインを検索できる検索エンジンがあります。
Each plugin is usually accompanied by its documentation detailing the installation, configuration of the plugin and the data it collects.
通常、各プラグインには、インストール、プラグインの設定、およびプラグインが収集するデータの詳細が記載されたドキュメントが付属しています。
プラグインのインストール方法
Plugins can be installed from Pandora FMS console. Depending on their type they can be run in two different ways, which will create different ways of plugin configuration. Agent plugins are however run by the software agent, while server plugins are run by the plugin server. Usually server plugins create agents and modules while agent plugins only create modules within the software agent in which it is configured.
プラグインは、Pandora FMS コンソールからインストールできます。 タイプに応じて 2 つの異なる方法で実行でき、プラグイン設定が作成されます。 ただし、エージェントプラグインはソフトウェアエージェントによって実行され、サーバプラグインはプラグインサーバによって実行されます。 通常、サーバプラグインはエージェントとモジュールを作成しますが、エージェントプラグインは、それが設定されているソフトウェアエージェント内でのみモジュールを作成します。
Installing the plugin consists of creating its custom execution in Pandora FMS. Every certain configurable time interval, the plugin will run and display the updated modules.
プラグインをインストールするには、Pandora FMS でカスタム実行を作成します。 設定可能な特定の時間間隔ごとにプラグインが実行され、更新されたモジュールが表示されます。
プラグインのライフサイクル
プラグインの計画
When developing a plugin it is important to correctly plan its development taking into account some aspects.
プラグインを開発するときは、いくつかの側面を考慮して、その開発を正しく計画することが重要です。
プラグインで解決できる問題
You should be able to answer these questions in a first step in plugin planning:
プラグイン計画の最初のステップで、次の質問に答えることができる必要があります。
- What is the purpose of the plugin?
- What are the use cases that your plugin will address?
- プラグインの目的は何でしょうか?
- あなたのプラグインが対応するユースケースは何ですか?
It is important to be clear about what solution you intend to achieve with the plugin. It could be monitoring a service of interest, managing to unify all data in Pandora FMS which can be an advantage in time or costs, or it can also be automating a process, such as a plugin that reads emails and with which an alarm can be activated when a certain message arrives.
プラグインで達成しようとしているソリューションを明確にすることが重要です。 関心のあるサービスを監視し、Pandora FMS ですべてのデータを統合することで、時間やコストの面で有利になる場合があります。また、プラグインにより電子メールを読み込んで特定のメッセージが到着したときアラームを鳴らすといった自動化をすることもできます。
Plugins seek to solve a need or make interaction, processing and data display easier.
プラグインは、ニーズを解決したり、相互作用、処理、およびデータ表示を容易にしたりできます。
プラグインはどのようにデータを取得するのでしょうか?
The main utility of a plugin is to retrieve data, from a service, application, database… and be able to display this data in Pandora FMS. But how can data be retrieved from the required service?
プラグインの主な機能は、サービス、アプリケーション、データベースなどからデータを取得し、このデータを Pandora FMS に表示できるようにすることです。 しかし、必要なサービスからデータを取得するにはどうすればよいでしょうか?
This, undoubtedly, depends on the technology or service that is intended to be exploited with the plugin, so it is necessary to carry out a preliminary investigation on the chosen service, to find out the feasibility of the plugin and if it is possible to create a testing environment to test it.
これは間違いなく、プラグインで利用することを想定している技術やサービスに依存するため、それらについて予備調査を実施し、プラグインの実現可能性を調べ、プラグインを作成できるかどうかを調べる必要があります。 可能であればテスト環境を用意します。
Usually these services usually have some way to get the monitoring statistics, that way usually varies depending on the service. Often they have an API or a CLI with which to be able to process the required data and be able to show them with the plugin.
通常、これらのサービスには監視統計を取得する何らかの方法があり、その方法はサービスによって異なります。 多くの場合、必要なデータを処理し、プラグインで表示できる API または CLI を持っています。
In some cases there are libraries that the community or the company that created the technology or service itself created to make interaction much more easier with data from their services.
場合によっては、技術やサービス自体を作成したコミュニティまたは会社が、データとのやり取りをより簡単にするために作成したライブラリがあります。
ユーザはデータを取得するためのアクセス許可が必要ですか?
It is likely that when retrieving data from a service or technology, it is necessary to have an account that needs certain permissions to interact with the data, or that it is necessary to make some previous configurations in the environment before this data can be retrieved.
サービスや技術からデータを取得する場合、データを操作するために特定のアクセス許可があるアカウントが必要になるか、データを取得する前に環境内で事前に設定を行う必要がある可能性があります。
Generally speaking, these requirements are specified in the service or technology documentation itself.
一般的に言えば、これらの要件は、サービスまたは技術のドキュメントで示されています。
It is important to keep clearly in mind what is necessary and what are the requirements to be able to retrieve data from that service and leave them detailed in the plugin documentation.
プラグインのドキュメントとして、サービスからデータを取得し詳細を残すためには何が必要でどのような要件があるかを明確にしておくことが重要です。
データはリモートまたはローカルで収集されますか?
Performance statistics may be retrieved by API remotely, either through some library, CLI, or by API with HTTP calls… or this data may only be retrieved internally or locally by commands or because it uses its own technology. Depending on the case the plugin execution will change and be different.
パフォーマンス統計は、ライブラリ、CLI、または HTTP 呼び出しを使用した API のいずれかを介して、リモートで取得できます。または、データは、コマンドであったり独自の技術を使用して内部またはローカルでのみ取得できる場合があります。 ケースに応じて、プラグインの実行は異なります。
A plugin that can get data remotely, can run with the plugin server, as it does not need to be present on the service machine to get data.
データをリモートで取得できるプラグインは、データを取得するためにサービスマシン上に存在する必要がないため、プラグインサーバで実行できます。
There are certain plugins that can only be run through the software agent since they need to be on the same system as the service from which you want to get data in order to get them.
ソフトウェアエージェントを介してのみ実行できる特定のプラグインもあります。データの取得がサービスと同じシステム上である必要がある場合です。
データをどのように表示しますか?
When defining how to display the plugin data on Pandora console, it is important to specify how you want to display this data.
Pandora コンソールでプラグイン データを表示する方法を定義する場合、このデータをどのように表示するかを指定することが重要です。
Usually these data will be displayed following an agent and module structure, so it is important to define this structure correctly to then be able to see the information as easy as possible so that it is not confusing, something that can be difficult to achieve in plugins that process lots of data or that monitor many “things”, such as the case of having many databases, virtual machines, etc.
通常、これらのデータはエージェントとモジュールの構造に従って表示されるため、この構造を正しく定義して、混乱しないように、情報をできるだけ簡単に表示できるようにすることが重要です。大量のデータを処理したり、多くのデータベースや仮想マシンなどを持っている場合など、多くの「もの」を監視したりするのは、プラグインで実現するのが難しくなります。
Within the plugin you may include options to customize agent or module names, or add some kind of prefix to their name to make them more visible and distinguishable.
プラグイン内に、エージェントまたはモジュールの名前をカスタマイズするオプションを含めたり、それらの名前にある種のプレフィックスを追加して、それらをより見やすく、区別しやすくすることができます。
プラグインの要件と依存関係
Depending on the technologies used in the plugin, dependency installation may be necessary for its correct operation. These can be libraries of the language used that you imported into the plugin to perform some function or the language used itself.
プラグインで使用されている技術によっては、正しく動作させるために依存関係のインストールが必要になる場合があります。 これらは、何らかの機能を実行するためにプラグインにインポートした言語のライブラリ、またはそれ自体で使用される言語のライブラリです。
If the plugin is written in python3, it will be necessary to have python3
installed in the machine you wish to use the plugin in, which could be a great obstacle for possible potential users of that plugin.
プラグインが python3 で記述されている場合、プラグインを使用するマシンに python3
をインストールする必要があります。これは、そのプラグインのユーザにとって、潜在的な大きな障害になる可能性があります。
One option, for plugins created in python is to provide a requirements.txt
file next to the plugin that can include all the dependencies used by the plugin, so installing this file will automatically install all the necessary dependencies.
Python で作成されたプラグインでの一つのオプションとしては、プラグインで使用されるすべての依存関係をプラグインと共に requirements.txt
ファイルで提供することです。このファイルをインストールすると、必要なすべての依存関係が自動的にインストールされます。
Example of the plugin requirements.txt
file, specifically that of remote MongoDB.
リモート MongoDB プラグインの requirements.txt
ファイルの例。
dnspython==2.1.0 pymongo==3.12.0
You may see how the file includes two libraries that it is necessary to keep installed on the system in order to launch it (in case it is not a compiled plugin).
ファイルには、プラグインを実行するためにシステムにインストールしておく必要がある 2 つのライブラリが含まれていることがわかります (コンパイルされたプラグインでない場合)。
The file can be written by hand, but you may also generate a requirements.txt
file that includes all the installed virtual environment dependencies with the pip freeze
command.
このファイルは手動で作成できますが、pip freeze
コマンドを使用して、インストールされたすべての仮想環境の依存関係を含む requirements.txt
ファイルを生成することもできます。
pip freeze> requirements.txt
You may copy the requirements file to the environment in which you want to install the dependencies and run the following command to install them:
依存関係をインストールする環境に requirements.txt ファイルをコピーし、次のコマンドを実行してそれらをインストールできます。
pip install -r requirements.txt
プラグインのコンパイル
One way to solve dependency problems with plugins is to create executables that already come with all the dependencies installed, this is an ideal solution for perl plugins and for python plugins.
プラグインの依存関係の問題を解決する一つの方法は、すべての依存関係が既にインストールされている実行可能ファイルを作成することです。これは、perl プラグインおよび python プラグインにとって理想的なソリューションです。
In the case of python to create executables, the pyinstaller
library is available:
python で実行可能ファイルを作成する場合、pyinstaller
ライブラリが利用可能です:
It can be installed with the following command:
これは、次のコマンドでインストールできます。
pip install pyinstaller
Once installed, the following command can be used to create a binary of the plugin in a file:
インストールしたら、次のコマンドを使用してプラグインのバイナリファイルに作成できます。
GNU/Linux:
pyinstaller –onefile < plugin_name >.py
MS Windows:
python3 -m PyInstaller –onefile <nombre_plugin>.py
A folder called dist
will be generated with the binary inside.
dist
というフォルダーが生成され、その中にバイナリが生成されます。
It may be the case that a plugin that has been compiled on one operating system does not work on another, it is recommended to compile the plugins in Rocky Linux 7, since the plugins compiled on this system usually work on all other GNU/Linux operating systems.
あるオペレーティングシステムでコンパイルされたプラグインは別のオペレーティングシステムで動作しない場合があります。プラグインのコンパイルは Rocky Linux 7 で行うことをお勧めします.このシステムでコンパイルされたプラグインは通常、他のすべての GNU/Linux オペレーティングシステムで動作するためです。
With binaries created in Fedora and Ubuntu we have been able to check that in other systems a dependency error is generated.
Fedora および Ubuntu で作成したバイナリを使用すると、他のシステムで依存関係エラーが発生することを確認しています。
プラグインの開発
It is important to be clear about which tools and technologies will be used in the plugin's development.
プラグインの開発にどのツールと技術を使用するかを明確にすることが重要です。
開発ツール
Plugins are scripts that integrate data or an extra feature in Pandora FMS, they are still small programs, so to develop them it is necessary to have a framework or a code editor such as Visual Studio Code.
プラグインは、データや Pandora FMS の追加機能を統合するスクリプトです。これらは小さなプログラムであるため、開発するには、フレームワークまたは Visual Studio Code などのコードエディタが必要です。
In turn, tools such as github or gitlab can help preserve and maintain the code of the plugins created.
次に、github や gitlab などのツールは、作成されたプラグインのコードを保存および維持するのに役立ちます。
プログラミング言語
For plugin development it is necessary to use a programming language, Pandora FMS supports any type of language, as long as it displays the data in XML format, Pandora FMS will be able to understand and display them in your console. To that end, follow a label structure with the XML that includes agents, modules and their attributes.
プラグインの開発には、プログラミング言語を使用する必要があります。Pandora FMS は、データが XML 形式で提供される限り、あらゆるタイプの言語をサポートします。Pandora FMS はそれらを理解しコンソールに表示できます。 そのために、エージェント、モジュール、およびそれらの属性を含む XML でラベル構造に従います。
Usually the scripting languages most commonly used in Pandora FMS plugins are Python, Perl, BASH and Powershell, the first two being probably the most complete ones.
通常、Pandora FMS プラグインで最も一般的に使用されるスクリプト言語は、Python、Perl、BASH、および Powershell であり、最初の 2 つはおそらく最も充実したものです。
Python and perl have a tool developed by Pandora FMS that plugin creation easier called Plugin Tools, this tool has a lot of features designed to make plugin creation easier as well as automate it, so it can be a decisive advantage when choosing the right language.
Python と perl には、Pandora FMS によって開発された Plugin Tools と呼ばれるプラグイン作成を容易にするツールがあります。このツールには、プラグイン作成を容易にし、自動化するように設計された多くの機能があるため、言語を選択する際の決定的な利点となる可能性があります。
テスト環境構築に便利なツール
For plugin development it is usually necessary a testing environment, either an installation of the service that you want to monitor, an account, etc. Two useful technologies for environment creation due to their speed and simplicity are docker and vagrant, since they allow generating environments with only a few commands or small configurations, although of course, it is necessary to have a solution in those projects of the service that you want to test.
プラグインの開発には、通常、監視するサービスのインストール、アカウントなどのテスト環境が必要です。速度とシンプルさから環境作成に役立つ 2 つの技術としては、docker と vagrant があります。 もちろん、テストしたいサービスのプロジェクトでソリューションを用意する必要がありますが、いくつかのコマンドまたは小さな構成のみで実行できます。
XML
In order for Pandora FMS to consume the data it receives from the plugin in order to display it, it is necessary for those data to be translated into XML format.
Pandora FMS がプラグインから受信したデータを使用して表示するには、それらのデータを XML 形式に変換する必要があります。
Knowing the format of Pandora FMS data XML can help you improve plugins, create custom agents with them, or just send custom XML files to Pandora FMS data server.
Pandora FMS の XML データ形式を理解すると、プラグインを改善したり、プラグインを使用してカスタムエージェントを作成したり、カスタム XML ファイルを Pandora FMS データサーバに送信したりするのに役立ちます。
Like any XML document, the data file should start with an XML declaration:
他の XML ドキュメントと同様に、データファイルは XML 宣言で開始する必要があります。
<?xml version='1.0' encoding='UTF-8'?>
However, although the plugins and their data is based on XML, only the agent plugins will print an XML in a terminal execution, the server plugins only show a simple data, like a one, which will be the value that will contain the module that activates it, so the most normal thing in these cases is that it emits a 1
if it works and a 0
if on the contrary it has given some kind of error.
ただし、プラグインとそのデータが XML に基づいているのはエージェントプラグインのみです。エージェントプラグインのみがターミナル実行で XML を出力します。サーバプラグインは単純なデータのみを表示します。サーバプラグインにおける最も基本的なことは、正常な場合は 1
を出力し、逆に何らかのエラーが発生した場合は 0
を出力することです。
エージェントとモジュール
The data that the plugin collects can be displayed in Pandora FMS through agents and modules, so it is important to outline the way in which you want to display data. For example, each agent could be a database to be monitored, with modules representing its information.
プラグインが収集するデータは、エージェントとモジュールを介して Pandora FMS に表示できるため、データを表示する方法を示すことが重要です。 たとえば、各エージェントは監視対象のデータベースで、モジュールとしてその情報を表すなどです。
The xml structure of agents and modules have different attributes for configuring them.
エージェントとモジュールの xml 構造には、それらを構成するためのさまざまな属性があります。
The element agent_data
, which defines the agent that sends the data, supports the following attributes:
データを送信するエージェントを定義する要素 agent_data
は、次の属性をサポートします。
description
: Agent description.group
: Name of the group the agent belongs to (it must exist in Pandora FMS database). If left empty and there is no default configured group on the server, the agent will not be created.os_name
: Name of the operating system the agent runs in (it must exist in Pandora FMS database).os_version
: Free string describing the version of the operating system.interval
: Agent interval (in seconds).version
: String with agent version.timestamp
: Timestamp indicating when the XML was generated (YYYY/MM/DD HH:MM:SS
).agent_name
: Agent name.timezone_offset
: Offset added to the timestamp (in hours). Useful if working with UTC.address
: Agent IP address (or FQDN).parent_agent_name
: Name of the agent's parent.agent_alias
: Agent alias.agent_mode
: Agent working mode (0
: Normal mode,1
: Learning mode,2
: Autodisable mode) .secondary_groups
: Secondary groups added to the agent.custom_id
: Agent custom ID.url_address
: Agent login URL.
description
: エージェントの説明。group
: エージェントが属するグループの名前 (Pandora FMS データベースに存在する必要があります)。 空のままにし、サーバにデフォルトで設定されたグループがない場合、エージェントは作成されません。os_name
: エージェントが実行されているオペレーティング システムの名前 (Pandora FMS データベースに存在する必要があります)。os_version
: オペレーティング システムのバージョンを説明する任意の文字列。interval
: エージェント実行間隔(秒単位)。version
: エージェントバージョン文字列。timestamp
: XML が生成されたタイムスタンプ(YYYY/MM/DD HH:MM:SS
)。agent_name
: エージェント名。timezone_offset
: タイムスタンプのオフセット(時間単位)。UTC で動作している場合に便利です。address
: エージェント IP アドレス(または FQDN)。parent_agent_name
: 親エージェントの名前。agent_alias
: エージェントの別名。agent_mode
: エージェントの動作モード。(0
: 通常モード,1
: 学習モード,2
: 自動無効化モード)secondary_groups
: エージェントのセカンダリグループ。custom_id
: エージェントカスタム ID。url_address
: エージェントログイン URL。
XML heading example:
XML ヘッダ例:
<agent_data description= group= os_name='linux' os_version='Ubuntu 10.10' interval='30' version='3.2(Build 101227)' timestamp='2011/04/20 12:24:03' agent_name='foo' timezone_offset='0' parent_agent_name='too' address='192.168.1.51' custom_id='BS4884' url_address='http://mylocalhost:8080'>
An module element is needed for each module
, and the following elements can be nested to define the module:
各 モジュール
にはモジュール要素が必要であり、次の要素をネストして定義できます。
- name: Module name.
- description: Module description.
- tags: Tags associated with the module.
- type: Module type (it must exist in Pandora FMS database).
- data: Module data.
- max: Maximum module value.
- min: Minimum module value.
- post_process: Post-processing value.
- module_interval: Module interval (interval in seconds /agent interval).
- min_critical: Minimum value for critical status.
- max_critical: Maximum value for critical status.
- min_warning: Minimum value for alert status.
- max_warning: Maximum value for alert status.
- disabled: Disable (0) or enable the module. Disabled modules are not processed.
- min_ff_event: FF threshold (see Flip-Flop).
- status: Module status (NORMAL, WARNING or CRITICAL). Critical and alert status limits are ignored if the status is specified.
- datalist: It sends the module data in datalist format (one database entry for each of the values received) [0/1].
- unit: Module unit. It supports
_timeticks_
macro to transform data in timeticks format todd/hh/mm/ss
. - timestamp: It sets a timestamp on the data received from the module.
- module_group: Group of modules to which the module will be added.
- custom_id: Module custom ID.
- str_warning: Warning threshold for string modules.
- str_critical: Critical threshold for string modules.
- critical_instructions: Critical module instructions.
- warning_instructions: Warning module instructions.
- unknown_instructions: Module unknown instructions.
- critical_inverse: It activates the inverse interval at the module's critical threshold. [0/1].
- warning_inverse: It activates the inverse interval at the module's warning threshold. [0/1].
- quiet: It activates the module's Quiet mode [0/1].
- module_ff_interval: It specifies an FF Range value of the module.
- alert_template: It associates an alert template to the module.
- crontab: It specifies a module crontab.
- min_ff_event_normal: FF threshold value when switching to NORMAL status.
- min_ff_event_warning: FF threshold value when switching to WARNING status.
- min_ff_event_critical: FF threshold value when switching to CRITICAL status.
- ff_timeout: FlipFlop timeout value.
- each_ff: It enables the “Change each status” option.
- module_parent: Module name in the same agent that will be the parent of this module.
- ff_type: It activates the Keep counters of the FF threshold. [0/1].
- name: モジュール名。
- description: モジュールの説明。
- tags: モジュールに関連付けられたタグ。
- type: モジュールタイプ(Pandora FMS データベースに存在するひつようがあります)。
- data: モジュールデータ。
- max: モジュール最大値。
- min: モジュール最小値。
- post_process: 保存倍率。
- module_interval: モジュール実行間隔(間隔をエージェントの実行間隔で割った値)。
- min_critical: 障害状態の最小値。
- max_critical: 障害状態の最大値。
- min_warning: 警告状態の最小値。
- max_warning: 警告状態の最大値。
- disabled: モジュールの無効化・有効化。無効化モジュールは処理されません。
- min_ff_event: 連続抑制回数 (連続抑制回数 を参照)。
- status: モジュールの状態(NORMAL, WARNING または CRITICAL)。ステータスが指定されている場合、障害およびアラートステータスの制限は無視されます。
- datalist: モジュールデータを datalist フォーマットで送信。(受け取った値ごとに 1 つのデータベースエントリ) [0/1]
- unit: モジュールの単位。timeticks フォーマットを
dd/hh/mm/ss
に変換する_timeticks_
マクロをサポートします。 - timestamp: モジュールから受信したデータにタイムスタンプを設定します。
- module_group: モジュールが追加されるモジュールグループ。
- custom_id: モジュールカスタム ID。
- str_warning: 文字列モジュールの警告閾値。
- str_critical: 文字列モジュールの障害閾値。
- critical_instructions: 障害モジュール手順。
- warning_instructions: 警告モジュール手順。
- unknown_instructions: 不明モジュール手順。
- critical_inverse: 障害閾値判定範囲を反転させる。[0/1]
- warning_inverse: 警告閾値判定範囲を反転させる。[0/1]
- quiet: モジュールの静観モードを有効化。[0/1]
- module_ff_interval: モジュールの連続抑制の間隔を定義。
- alert_template: アラートテンプレートをモジュールに関連付けます。
- crontab: モジュール crontab を指定します。
- min_ff_event_normal: 正常状態に変化する場合の連続抑制回数。
- min_ff_event_warning: 警告状態に変化する場合の連続抑制回数。
- min_ff_event_critical: 障害状態に変化する場合の連続抑制回数。
- ff_timeout: 連続抑制回数のタイムアウト値。
- each_ff: 連続抑制で状態ごとの回数定義を有効化。
- module_parent: このモジュールの親になる同じエージェント内のモジュール名。
- ff_type: 連続抑制でのカウンタ値の維持の有効化。[0/1]
From Pandora FMS version 749, new tokens are available to force thresholds:
Pandora FMS バージョン 749 から、しきい値を強制するための新しいトークンが利用可能になりました。
- min_warning_forced: It forces min_warning to the new specified value even if the module exists, it takes precedence over min_warning.
- max_warning_forced: It forces max_warning to the new specified value even if the module exists, it takes precedence over max_warning.
- min_critical_forced: It forces min_critical to the new specified value even if the module exists, it takes precedence over min_critical.
- max_critical_forced: It forces max_critical to the new specified value even if the module exists, it takes precedence over max_critical.
- str_warning_forced: It forces str_warning to the new specified value even if the module exists, it takes precedence over str_warning.
- str_critical_forced: It forces str_critical to the new specified value even if the module exists, it takes precedence over str_critical.
- A module must have at least one name, type and data element.
- min_warning_forced: モジュールが存在する場合でも、min_warning を新しい指定値に強制し、min_warning よりも優先されます。
- max_warning_forced: モジュールが存在する場合でも、max_warning を新しい指定値に強制し、max_warning よりも優先されます。
- min_critical_forced: モジュールが存在する場合でも、min_critical を新しい指定値に強制し、min_critical よりも優先されます。
- max_critical_forced: モジュールが存在する場合でも、max_critical を新しい指定値に強制し、max_critical よりも優先されます。
- str_warning_forced: モジュールが存在する場合でも、str_warning を新しい指定値に強制し、str_warning よりも優先されます。
- str_critical_forced: モジュールが存在する場合でも、str_critical を新しい指定値に強制し、str_critical よりも優先されます。
- モジュールには、少なくとも 1 つの名前、型、およびデータ要素が必要です。
For instance:
例:
<module> <name>CPU</name> <description>CPU usage percentage</description> <type>generic_data</type> <data>21</data> </module>
There can be any number of elements in an XML data file.
XML データ ファイルには、任意の数の要素を含めることができます。
Do not forget to close the tag agent_data
!
agent_data
タグを閉じることを忘れないでください!
There are also list modules, which instead of having only one value may contain several, these are useful for string values. The datalist tag should be used in this type of modules as you see in the following example:
リストモジュールもあり、1 つの値だけではなく、複数の値を含むことができます。これらは文字列に役立ちます。 次の例に示すように、このタイプのモジュールでは datalist タグを使用する必要があります。
<module> <type>async_string</type> <datalist> <data><value><![CDATA[xxxxx]]></value></data> <data><value><![CDATA[yyyyy]]></value></data> <data><value><![CDATA[zzzzz]]></value></data> </datalist> </module>
A time stamp can be specified for each value:
各値にタイムスタンプを指定できます。
<module> <type>async_string</type> <datalist> <data> <value><![CDATA[xxxxx]]></value> <timestamp>1970-01-01 00:00:00</timestamp> </data> <data> <value><![CDATA[yyyyy]]></value> <timestamp>1970-01-01 00:00:01</timestamp> </data> <data> <value><![CDATA[zzzzz]]></value> <timestamp>1970-01-01 00:00:02</timestamp> </data> </datalist> </module>
Some more examples that include the use of thresholds and units:
しきい値と単位の指定を含むその他の例:
<module> <name><![CDATA[Cache mem free]]></name> <description><![CDATA[Free cache memory in MB]]></description> <tags>tag</tags> <type>generic_data</type> <module_interval>1</module_interval> <min_critical>100</min_critical> <max_critical>499</max_critical> <min_warning>500</min_warning> <max_warning>600</max_warning> <unit><![CDATA[MB]]></unit> <data><![CDATA[3866]]></data> </module> <module> <name><![CDATA[Load Average]]></name> <description><![CDATA[Average process in CPU (Last minute) ]]></description> <tags>tag</tags> <type>generic_data</type> <module_interval>1</module_interval> <data><![CDATA[1.89]]></data> </module>
プラグインツール
Pandora FMS has a tool called plugintools, available for the perl and python programming languages that makes plugin development easier, since it has built-in features that make most of the processes necessary for creating a plugin easier:
Pandora FMS には、プラグインの開発を容易にする perl および python プログラミング言語で利用できる plugintools というツールがあります。これらは、プラグインの作成に必要なほとんどを処理を簡単に実現する機能が組み込まれています。
- Agent creation.
- Module creation.
- Send files through Tentacle.
- Read configuration files.
- エージェント作成。
- モジュール作成。
- Tentacle でのファイル送信。
- 設定ファイルの読み込み。
Python 版 plugintools
Perl 版 plugintools
パラメータと設定
A utility to consider, that is usually quite useful when interacting with a plugin, is the parameters and configuration files, since these give the option of being able to customize the plugin's execution making possible to create different executions. With these you may define data that will always be variable such as the service IP or the credentials to be targeted or be able to customize the name of the modules or agents among other things. Using parameters for plugin configuration has advantages and disadvantages over using configuration files, since you avoid using more files for plugin use, but plugin configuration can surely be done faster with a configuration file, it is important to evaluate which option is best for each plugin.
プラグインを使用する際に便利なものとして、パラメータと設定ファイルがあります。これらを使って、サービス IP や対象となる認証情報のような常に変動するデータを定義したり、モジュールやエージェントの名前をカスタマイズしたりすることができます。プラグインの設定にパラメータを使用することは、設定ファイルを使用することに比べて利点と欠点があります。パラメータを使うとプラグインの使用に多くの設定ファイルが必要なくなりますが、設定ファイルを使用した場合はプラグインの設定を確実にすばやく実行できます。各プラグインに最適なオプションを検討することが重要です。
プラグインヘルプ
Another option that is usually quite useful in a plugin, is to include a parameter as its help option, to show all the plugin options and parameters and how to configure it. It is like a small digital documentation about the plugin included in its software.
通常、プラグインで非常に便利なもう 1 つのオプションは、パラメータをヘルプに含めて、すべてのプラグインオプションとパラメータ、およびその設定方法を表示することです。 これは、ソフトウェアに含まれるプラグインに関する小さなデジタルドキュメントのようなものです。
Pandora FMS プラグイン設定
The plugin settings may vary depending on whether this is an agent or server plugin.
プラグインの設定は、これがエージェントプラグインかサーバプラグインかによって異なる場合があります。
サーバプラグイン
In order to monitor from Pandora FMS with a server agent plugin, go to the “plugins” section within the servers menu.
サーバプラグインを使用して Pandora FMS から監視するには、サーバメニューの “プラグイン” に移動します。
Click on “Add”. It should be given the name and description you prefer.
“追加(add)” をクリックします。好みの名前と説明を付ける必要があります。
As a command you should enter the execution with the plugin path.
コマンドとして、プラグインパスに実行コマンドを入力する必要があります。
The recommended path for using server plugins is:
/usr/share/pandora_server/util/plugin/
サーバプラグインを利用するための推奨パスは次のとおりです。
/usr/share/pandora_server/util/plugin/
The execution with the plugin path must be entered as a command:
プラグインパスには、コマンドを入力する必要があります。
In plugin parameters enter them followed by the macro _field_
.
プラグインパラメータでは、マクロ _field_
に続いてそれらを入力します。
–SERVER
–SUBJECT
–BODY
Once this is done, click on “create”.
完了したら、“作成(create)” をクリックします。
Once the previous steps have been completed, call the plugin. Go to the agent view and create a plugin module. A name must be given and in the “plugin” section the one you just configured is added.
前の手順が完了したら、プラグインを呼び出します。 エージェント表示に移動し、プラグインモジュールを作成します。名前を指定する必要があります。“プラグイン” セクションに、設定したばかりのプラグインが追加されます。
Once done, click “create”.
完了したら、“作成(create)” をクリックします。
If the module is shown with 1
, it means that it is running correctly and an agent containing the modules has been created.
モジュールの値が 1
で表示されている場合、モジュールは正常に実行されており、モジュールを含むエージェントが作成されたことを意味します。
エージェントプラグイン
In order to monitor from Pandora FMS with an agent plugin, call it from the software agent .conf
file that is in the following path, in GNU/Linux:
エージェントプラグインを使用して Pandora FMS で監視するには、GNU/Linux の次のパスにあるソフトウェアエージェントの .conf
ファイルから呼び出します。
/etc/pandora/pandora_agent.conf
The execution on the last conf line can be created with the module_plugin
command, followed by the execution command.
conf では module_plugin
コマンドを用いて設定し、実行コマンドを続けます。
Example of a possible plugin execution:
プラグイン実行の例:
module_plugin /etc/pandora/plugins/MyMonitor.pl /etc/pandora/plugins/MyMonitor.conf
This can also be done from the console if remote configuration is enabled. Example:
リモート設定が有効になっている場合は、コンソールからも設定を行えます。 例:
Pandora FMS でのプラグインの表示
The display of the plugin data is usually done from the agents view. The data structure is usually defined by agents and modules so it is normal for the plugin to create agents and modules within them, so these data can be displayed in the view menu of the agent itself.
プラグインデータの表示は通常、エージェント表示から行われます。 通常、データ構造はエージェントとモジュールにて定義されるため、プラグインがエージェントとモジュールを作成するのは普通のことです。したがって、これらのデータはエージェント自体の表示メニューに表示できます。
In many plugins it could be the case that many agents are created, such as the Xenserver plugin that creates an agent for each virtual server machine, but luckily you may define a prefix for the agents, in this case for example the prefix xen-
could be used, so when viewing the agents you may see that some have that structure in the name and you will know that those agents come from that particular plugin.
仮想サーバマシンごとにエージェントを作成する Xenserver プラグインなど、多くのプラグインでは複数のエージェントが作成される場合があります。この場合、エージェントのプレフィックスに例えば xen-
を定義できるため、エージェントを表示した際に名前にその構造が含まれていることがわかり、それらのエージェントがその特定のプラグインに由来するものであることがわかります。
PSPZ2
A pspz2 file is a zip compressed file made up of two files, the plugin and a plugin_definition.ini
file that contains the plugin and module specification.
pspz2 ファイルは、プラグインとモジュールの定義を含む plugin_definition.ini
ファイルの 2 つのファイルを zip 圧縮したファイルです。
This file format is very useful when packaging plugins, as it simplifies their installation. Using this format, plugins can be installed more quickly in Pandora FMS console from the “plugins registration” section.
このファイル形式は、プラグインのインストールを簡素化するため、プラグインをパッケージ化するときに非常に便利です。 この形式を使用すると、Pandora FMS コンソールの “プラグイン登録(plugins registration)” 画面からプラグインをよりすばやくインストールできます。
Example of plugins_definition.ini
of a plugin:
プラグインの plugins_definition.ini
ファイルの例:
[plugin_definition] name = Pandora Azure Storage description = "Take data from azure storage" timeout = 20 filename = pandora_azure execution_command = execution_postcommand = parameters = -c _field1_ –agent_name _field2_ -g _field3_ plugin_type = 0 total_modules_provided = 0 total_macros_provided = 8 [macro_1] hide = 0 description = "Conf path (obligatory)" help = "Path conf" value = [macro_2] hide = 0 description = "Agent name (optional)" help = "Name of the agent" value = _agentname_ [macro_3] hide = 0 description = "group (optional)" help = "Pandora FMS Target Group " value =
filename: It should have the same name as the script included in file .pspz
, previously named as < script_file >
. In this example it is a shell script ( .sh
format) named ssh_pandoraplugin.sh
.
filename: ファイル .pspz
に含まれるスクリプトと同じ名前にする必要があります。以前は < script_file >
という名前でした。 この例では、ssh_pandoraplugin.sh
という名前のシェルスクリプト (.sh
形式) です。
plugin_type: 0
for a Pandora FMS standard plugin, and 1
for a Nagios plugin.
plugin_type: 0
は Pandora FMS 標準のプラグイン、1
は Nagios プラグインです。
total_modules_provided: It specifies how many modules are defined in the following sections of the .ini
file. Set at least one (for use in an example at least).
total_modules_provided: .ini
ファイルの次のセクションで定義されているモジュールの数を指定します。 少なくとも 1 つ設定します (少なくとも例で使用)。
execution_command: If it is used, it must be placed before script. It could be an interpreter, such as java -jar
. Therefore, the plugin will be called for execution, from the Pandora FMS Plugin Server, with the following code: java -jar < plugin_path/ plugin_filename
.
execution_command: 使用する場合は、script の前に置かなければなりません。これは、java -jar
のようなインタプリタかもしれません。プラグインは Pandora FMS プラグインサーバから次のようなコードで呼び出され実行されます: java -jar < plugin_path/ plugin_filename
execution_postcommand: If used, it defines the additional parameters transmitted to the plugin after < plugin_filename >
, which is invisible to the user.
execution_postcommand: 使用すると、< plugin_filename >
の後にプラグインに送信される追加パラメータを定義できます。ユーザからは見えません。
total_macros_provided: It defines the number of dynamic macros the plugin has.
total_macros_provided: プラグインが持つ動的マクロの数を定義します。
macro__value: It defines the value for that Module using that dynamic macro, if it does not exist the default value is taken.
macro__value: そのモジュールの値を動的マクロで定義し、存在しない場合はデフォルト値をとります。
And it must create a section for each dynamic macro, for example:
また、動的マクロごとにセクションを作成しなければいけません。例:
[macro_<N>] hide = 0 description = <your_description> help = <text_help> value = <your_value>
互換性
It is important for the plugin to have as much compatibility as possible. Certain plugins are unique to services that can only be exploited on a given operating system, such as MS Windows®. But within the inevitable limitations it is important to give the plugin a compatibility that covers as many scenarios as possible.
プラグインはできるだけ互換性を持たせることが重要です。ある種のプラグインは、MS Windows® のような特定の OS でしか利用できないサービス特有のものであったりします。しかし、避けられない制限の中で、できるだけ多くのシナリオをカバーできる互換性をプラグインに持たせることが重要です。
Certain operating systems have packages that do not exist in others, which can lead to errors in the execution of a compiled plugin, so it is advisable to compile the plugins on a machine with Rocky Linux 7 operating system that has all the necessary plugin dependencies installed.
OSによっては、他の OS には存在しないパッケージがあり、コンパイルしたプラグインの実行でエラーが発生することがあるため、必要なプラグインの依存関係がすべてインストールされている Rocky Linux 7 の環境でプラグインをコンパイルすることをお勧めします。
エラー制御
Having good error control can help maintain the plugin over time, as it can help detect potential future errors in the plugin and locate them more quickly.
適切なエラー制御を行うと、プラグインの潜在的な将来起こりうるエラーを検出し、迅速に原因を見つけることができるため、長期にわたってプラグインを維持するのに役立ちます。
It can also help to detect what the error is accurately, since without error control in certain cases the error output may be too generic and it may be difficult to figure out what the problem is.
また、エラーを正確に検出するのにも役立ちます。エラー制御がないと、特定のケースではエラー出力があまりにも一般的になり、問題が何であるかを理解するのが難しくなる可能性があるためです。
プラグインのテストと検証
Once the plugin has been developed, it is suitable to perform tests in environments to check its operation, in fact it would be great to be able to test it in more than one test environment.
プラグインを開発したら、環境でテストを実行してその動作を確認すると良いです。複数のテスト環境でテストできると良いです。
A good testing process can help to solve possible errors and to make the plugin's operation more solid over time, as it is usually said, better safe than sorry.
良いテストプロセスは、起こりうるエラーを解決し、長期にわたってプラグインの動作をより強固にするのに役立ちます。よく言われる「転ばぬ先の杖」です。
プラグインの公開
When publishing the plugin, it is important to take certain aspects into account.
プラグインを公開する際には、ある点を考慮することが重要です。
プラグインのドキュメント
Using some plugins could be at first difficult to understand. Some may have several options and it can be a bit hard to understand them.
プラグインの中には、最初は理解しにくいものがあります。いくつかのプラグインにはいくつかのオプションがあり、それらを理解するのは少し難しいかもしれません。
Good documentation can help you understand it, it can even be useful for plugin creators themselves in the future, to help them remember certain things about the plugin that they may have forgotten over time.
良いドキュメントは、それを理解するのに役立ちますし、将来的にはプラグイン制作者自身が、時間が経つにつれて忘れてしまったプラグインのある事柄を思い出すのに役立つことさえあります。
Pandora FMS has a system of online quick guides that makes documentation maintenance easier, which can be accessed from the following link:
Pandora FMS には、ドキュメントのメンテナンスを容易にするためのオンラインクイックガイドのシステムがあり、以下のリンクからアクセスできます。
The alternative to the documentation in quick-guide format is the PDF format.
クイックガイド形式のドキュメントに代わるものとして、PDF 形式のものもあります。
ライブラリへのプラグインのアップロード
The process when uploading a plugin to Pandora FMS library is very simple. Just access the “upload new module” section within “my plugins” section of the library.
Pandora FMS ライブラリにプラグインをアップロードする方法は非常に簡単です。ライブラリの “my plugins” セクションにある “upload new module” セクションにアクセスするだけです。
Once all the sections of the entry have been configured, such as the title, a description of the plugin, the compressed plugin in zip format, the documentation, categories and tags, the plugin can be published by clicking on submit.
タイトル、プラグインの説明、zip 形式で圧縮されたプラグイン、ドキュメント、カテゴリ、タグなど、エントリーのすべてのセクションを設定したら、submit をクリックしてプラグインを公開することができます。
All plugins uploaded to the library are reviewed and need a review time, before their final release.
ライブラリにアップロードされたすべてのプラグインは、最終的なリリース前にレビューが行われます。レビュー時間がかかります。
Once the plugin is published, it will appear in the “latest uploads” section:
プラグインが公開されると、“latest uploads” に表示されるようになります。
プラグインのレビューとメンテナンスに役立つグッドプラクティス
Some good practices can help decrease the time spent on tasks, prevent and circumvent common errors during the different stages of the plugin creation process and plugin maintenance over time, and make their review easier. These can be:
いくつかのグッドプラクティスは、タスクに費やす時間を減らし、プラグインの作成プロセスやプラグインのメンテナンスのさまざまな段階でよくあるエラーを防止・回避し、それらのレビューを容易にするのに役立ちます。これらは以下の通りです。
- Leaving a good previous configuration well documented in case it is necessary to make some previous configurations on the system on the plugin itself.
- Documenting an example of actual execution of the plugin that helps the user visualize its use.
- Writing comments in the plugin code can help understand it better or faster.
- Prioritizing code readability. The more complex it is, the more time and resources will be needed to deal with it.
- Testing your code. It is important to test the plugin's operation to verify that everything is fine. Finding an error in time and fixing it will avoid problems in the future.
- システム上でこれまで行ったことのあるプラグインの設定を行う必要がある場合に備えて、正しく動作する設定を十分に文書化して残しておくこと。
- プラグインの使い方をイメージしやすいように、実際に実行した例をドキュメント化すること。
- プラグインのコードにコメントを書くことで、より深く、あるいはより速く理解することができます。
- コードの読みやすさを優先します。複雑であればあるほど、それに対処するための時間とリソースが必要になります。
- コードのテストをします。プラグインの動作をテストして、すべてが問題ないことを確認することが重要です。エラーを時間内に発見して修正することで、将来的な問題を回避することができます。