プラグイン開発ガイド

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

このプラグイン開発ガイドには、独自のプラグインを作成したいユーザ向けのドキュメントが含まれています。 このドキュメントを使用して、ビジネスニーズを解決するプラグインを作成する方法を学習してください。

プラグインとも呼ばれるコンピュータアドオンは、別のアプリケーション (この場合は Pandora FMS) の機能を拡張できるようにするアプリケーションです。

プラグインを使用すると、Pandora FMS の機能を拡張できます。これにより、新しい監視オプションを開発する際にさまざまな可能性が提供されます。

それらを使用すると、サービス、アプリケーション、またはデータベースの監視などを統合でき、タスクや処理を変更または自動化するために使用することもできます.

目的の 1 つは、同じ作業環境でできるだけ多くのシステムとサービスを監視できるようにすることであり、プラグインの利用はそのタスクに大いに役立ちます。

ほとんどのプラグインは、Pandora FMS の外部サービスから収集されたデータまたはパフォーマンス統計を表示できるようにするのに便利です。

実行タイプ別:

• エージェントプラグイン: エージェントプラグインは Pandora FMS ソフトウェアエージェントによって実行されます。通常はローカルにあり、リモートでは動作しないため、エージェントデーモンによって実行されます。 エージェントプラグインは通常、実行時に XML を出力し、モジュールにはデータが含まれます。
• サーバプラグイン: サーバプラグインは プラグインサーバ によって実行され、通常は API または別の方法でリモートでデータを取得します。(ほとんどの場合)エージェントプラグインとして設定することもできますが、推奨されるオプションは、サーバプラグインとして設定することです。 サーバプラグインは、実行の成功を示す 1 などの 1 つの値のみを返します。

Pandora FMS には、システム用に作成されたすべてのプラグインをダウンロードできるライブラリがあります。

プラグインは誰でもライブラリにアップロードできますが、受け入れて公開する前にレビュープロセスがあります。

現在、ライブラリには、すべての分野、データベース、アプリケーション、クラウド、メッセージングサービスなどをカバーする多数のプラグインがあります。

ライブラリには、快適に閲覧できるさまざまなタグやメニューに加えて、ライブラリにアップロードされたプラグインを検索できる検索エンジンがあります。

通常、各プラグインには、インストール、プラグインの設定、およびプラグインが収集するデータの詳細が記載されたドキュメントが付属しています。

プラグインは、Pandora FMS コンソールからインストールできます。 タイプに応じて 2 つの異なる方法で実行でき、プラグイン設定が作成されます。 ただし、エージェントプラグインはソフトウェアエージェントによって実行され、サーバプラグインはプラグインサーバによって実行されます。 通常、サーバプラグインはエージェントとモジュールを作成しますが、エージェントプラグインは、それが設定されているソフトウェアエージェント内でのみモジュールを作成します。

プラグインをインストールするには、Pandora FMS でカスタム実行を作成します。 設定可能な特定の時間間隔ごとにプラグインが実行され、更新されたモジュールが表示されます。

プラグインを開発するときは、いくつかの側面を考慮して、その開発を正しく計画することが重要です。

プラグイン計画の最初のステップで、次の質問に答えることができる必要があります。

• プラグインの目的は何でしょうか?
• あなたのプラグインが対応するユースケースは何ですか?

プラグインで達成しようとしているソリューションを明確にすることが重要です。 関心のあるサービスを監視し、Pandora FMS ですべてのデータを統合することで、時間やコストの面で有利になる場合があります。また、プラグインにより電子メールを読み込んで特定のメッセージが到着したときアラームを鳴らすといった自動化をすることもできます。

プラグインは、ニーズを解決したり、相互作用、処理、およびデータ表示を容易にしたりできます。

プラグインの主な機能は、サービス、アプリケーション、データベースなどからデータを取得し、このデータを Pandora FMS に表示できるようにすることです。 しかし、必要なサービスからデータを取得するにはどうすればよいでしょうか?

これは間違いなく、プラグインで利用することを想定している技術やサービスに依存するため、それらについて予備調査を実施し、プラグインの実現可能性を調べ、プラグインを作成できるかどうかを調べる必要があります。 可能であればテスト環境を用意します。

通常、これらのサービスには監視統計を取得する何らかの方法があり、その方法はサービスによって異なります。 多くの場合、必要なデータを処理し、プラグインで表示できる API または CLI を持っています。

場合によっては、技術やサービス自体を作成したコミュニティまたは会社が、データとのやり取りをより簡単にするために作成したライブラリがあります。

サービスや技術からデータを取得する場合、データを操作するために特定のアクセス許可があるアカウントが必要になるか、データを取得する前に環境内で事前に設定を行う必要がある可能性があります。

一般的に言えば、これらの要件は、サービスまたは技術のドキュメントで示されています。

プラグインのドキュメントとして、サービスからデータを取得し詳細を残すためには何が必要でどのような要件があるかを明確にしておくことが重要です。

パフォーマンス統計は、ライブラリ、CLI、または HTTP 呼び出しを使用した API のいずれかを介して、リモートで取得できます。または、データは、コマンドであったり独自の技術を使用して内部またはローカルでのみ取得できる場合があります。 ケースに応じて、プラグインの実行は異なります。

データをリモートで取得できるプラグインは、データを取得するためにサービスマシン上に存在する必要がないため、プラグインサーバで実行できます。

ソフトウェアエージェントを介してのみ実行できる特定のプラグインもあります。データの取得がサービスと同じシステム上である必要がある場合です。

Pandora コンソールでプラグイン データを表示する方法を定義する場合、このデータをどのように表示するかを指定することが重要です。

通常、これらのデータはエージェントとモジュールの構造に従って表示されるため、この構造を正しく定義して、混乱しないように、情報をできるだけ簡単に表示できるようにすることが重要です。大量のデータを処理したり、多くのデータベースや仮想マシンなどを持っている場合など、多くの「もの」を監視したりするのは、プラグインで実現するのが難しくなります。

プラグイン内に、エージェントまたはモジュールの名前をカスタマイズするオプションを含めたり、それらの名前にある種のプレフィックスを追加して、それらをより見やすく、区別しやすくすることができます。

プラグインで使用されている技術によっては、正しく動作させるために依存関係のインストールが必要になる場合があります。 これらは、何らかの機能を実行するためにプラグインにインポートした言語のライブラリ、またはそれ自体で使用される言語のライブラリです。

プラグインが python3 で記述されている場合、プラグインを使用するマシンに python3 をインストールする必要があります。これは、そのプラグインのユーザにとって、潜在的な大きな障害になる可能性があります。

Python で作成されたプラグインでの一つのオプションとしては、プラグインで使用されるすべての依存関係をプラグインと共に requirements.txt ファイルで提供することです。このファイルをインストールすると、必要なすべての依存関係が自動的にインストールされます。

リモート MongoDB プラグインの requirements.txt ファイルの例。

dnspython==2.1.0
pymongo==3.12.0

ファイルには、プラグインを実行するためにシステムにインストールしておく必要がある 2 つのライブラリが含まれていることがわかります (コンパイルされたプラグインでない場合)。

このファイルは手動で作成できますが、pip freeze コマンドを使用して、インストールされたすべての仮想環境の依存関係を含む requirements.txt ファイルを生成することもできます。

pip freeze> requirements.txt

依存関係をインストールする環境に requirements.txt ファイルをコピーし、次のコマンドを実行してそれらをインストールできます。

pip install -r requirements.txt

プラグインの依存関係の問題を解決する一つの方法は、すべての依存関係が既にインストールされている実行可能ファイルを作成することです。これは、perl プラグインおよび python プラグインにとって理想的なソリューションです。

python で実行可能ファイルを作成する場合、pyinstaller ライブラリが利用可能です:

これは、次のコマンドでインストールできます。

pip install pyinstaller

インストールしたら、次のコマンドを使用してプラグインのバイナリファイルに作成できます。

Linux:

pyinstaller –onefile <nombre_plugin>.py

MS Windows:

python3 -m PyInstaller –onefile <nombre_plugin>.py

dist というフォルダーが生成され、その中にバイナリが生成されます。

あるオペレーティングシステムでコンパイルされたプラグインは別のオペレーティングシステムで動作しない場合があります。プラグインのコンパイルは CentOS 7 で行うことをお勧めします.このシステムでコンパイルされたプラグインは通常、他のすべての GNU/Linux オペレーティングシステムで動作するためです。

Fedora および Ubuntu で作成したバイナリを使用すると、他のシステムで依存関係エラーが発生することを確認しています。

プラグインの開発にどのツールと技術を使用するかを明確にすることが重要です。

プラグインは、データや Pandora FMS の追加機能を統合するスクリプトです。これらは小さなプログラムであるため、開発するには、フレームワークまたは Visual Studio Code などのコードエディタが必要です。

次に、github や gitlab などのツールは、作成されたプラグインのコードを保存および維持するのに役立ちます。

プラグインの開発には、プログラミング言語を使用する必要があります。Pandora FMS は、データが XML 形式で提供される限り、あらゆるタイプの言語をサポートします。Pandora FMS はそれらを理解しコンソールに表示できます。 そのために、エージェント、モジュール、およびそれらの属性を含む XML でラベル構造に従います。

通常、Pandora FMS プラグインで最も一般的に使用されるスクリプト言語は、Python、Perl、BASH、および Powershell であり、最初の 2 つはおそらく最も充実したものです。

Python と perl には、Pandora FMS によって開発された Plugin Tools と呼ばれるプラグイン作成を容易にするツールがあります。このツールには、プラグイン作成を容易にし、自動化するように設計された多くの機能があるため、言語を選択する際の決定的な利点となる可能性があります。

プラグインの開発には、通常、監視するサービスのインストール、アカウントなどのテスト環境が必要です。速度とシンプルさから環境作成に役立つ 2 つの技術としては、docker と vagrant があります。 もちろん、テストしたいサービスのプロジェクトでソリューションを用意する必要がありますが、いくつかのコマンドまたは小さな構成のみで実行できます。

Pandora FMS がプラグインから受信したデータを使用して表示するには、それらのデータを XML 形式に変換する必要があります。

Pandora FMS の XML データ形式を理解すると、プラグインを改善したり、プラグインを使用してカスタムエージェントを作成したり、カスタム XML ファイルを Pandora FMS データサーバに送信したりするのに役立ちます。

他の XML ドキュメントと同様に、データファイルは XML 宣言で開始する必要があります。

<?xml version='1.0' encoding='UTF-8'?>

ただし、プラグインとそのデータが XML に基づいているのはエージェントプラグインのみです。エージェントプラグインのみがターミナル実行で XML を出力します。サーバプラグインは単純なデータのみを表示します。サーバプラグインにおける最も基本的なことは、正常な場合は 1 を出力し、逆に何らかのエラーが発生した場合は 0 を出力することです。

プラグインが収集するデータは、エージェントとモジュールを介して Pandora FMS に表示できるため、データを表示する方法を示すことが重要です。 たとえば、各エージェントは監視対象のデータベースで、モジュールとしてその情報を表すなどです。

エージェントとモジュールの xml 構造には、それらを構成するためのさまざまな属性があります。

データを送信するエージェントを定義する要素 agent_data は、次の属性をサポートします。

• 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 アドレス(または FQN)。
• parent_agent_name: 親エージェントの名前。
• agent_alias: エージェントの別名。
• agent_mode: エージェントの動作モード。(0: 通常モード, 1: 学習モード, 2: 自動無効化モード)
• secondary_groups: エージェントのセカンダリグループ。
• custom_id: エージェントカスタム ID。
• url_address: エージェントログイン URL。

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'>

各 モジュール にはモジュール要素が必要であり、次の要素をネストして定義できます。

• 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]

Pandora FMS バージョン 749 から、しきい値を強制するための新しいトークンが利用可能になりました。

• 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 つの名前、型、およびデータ要素が必要です。

例:

<module>
<name>CPU</name>
<description>CPU usage percentage</description>
<type>generic_data</type>
<data>21</data>
</module>

XML データ ファイルには、任意の数の要素を含めることができます。

リストモジュールもあり、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>
Se puede especificar una marca de tiempo para cada valor:
<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>

しきい値と単位の指定を含むその他の例:

<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 には、プラグインの開発を容易にする perl および python プログラミング言語で利用できる plugintools というツールがあります。これらは、プラグインの作成に必要なほとんどを処理を簡単に実現する機能が組み込まれています。

• エージェント作成。
• モジュール作成。
• Tentacle でのファイル送信。
• 設定ファイルの読み込み。

プラグインを使用する際に便利なものとして、パラメータと設定ファイルがあります。これらを使って、サービス IP や対象となる認証情報のような常に変動するデータを定義したり、モジュールやエージェントの名前をカスタマイズしたりすることができます。プラグインの設定にパラメータを使用することは、設定ファイルを使用することに比べて利点と欠点があります。パラメータを使うとプラグインの使用に多くの設定ファイルが必要なくなりますが、設定ファイルを使用した場合はプラグインの設定を確実にすばやく実行できます。各プラグインに最適なオプションを検討することが重要です。

通常、プラグインで非常に便利なもう 1 つのオプションは、パラメータをヘルプに含めて、すべてのプラグインオプションとパラメータ、およびその設定方法を表示することです。 これは、ソフトウェアに含まれるプラグインに関する小さなデジタルドキュメントのようなものです。

プラグインのヘルプメニューの例:

プラグインの設定は、これがエージェントプラグインかサーバプラグインかによって異なる場合があります。

サーバプラグインを使用して Pandora FMS から監視するには、サーバメニューの “プラグイン” に移動します。

“追加(add)” をクリックします。

好みの名前と説明を付ける必要があります。

コマンドとして、プラグインパスに実行コマンドを入力する必要があります。

/usr/share/pandora_server/util/plugin/

プラグインパスには、コマンドを入力する必要があります。

プラグインパラメータでは、マクロ _field_ に続いてそれらを入力します。

–SERVER

–SUBJECT

–BODY

完了したら、“作成(create)” をクリックします。

前の手順が完了したら、プラグインを呼び出します。 エージェント表示に移動し、プラグインモジュールを作成します。

名前を指定する必要があります。“プラグイン” セクションに、設定したばかりのプラグインが追加されます。

完了したら、“作成(create)” をクリックします。

モジュールの値が 1 で表示されている場合、それは正しく実行されていることを意味します。

エージェントプラグインを使用して Pandora FMS で監視するには、GNU/Linux の次のパスにあるソフトウェアエージェントの .conf ファイルから呼び出します。

/etc/pandora/pandora_agent.conf

conf では module_plugin コマンドを用いて設定し、実行コマンドを続けます。

プラグイン実行の例:

module_plugin /etc/pandora/plugins/MyMonitor.pl /etc/pandora/plugins/MyMonitor.conf

リモート設定が有効になっている場合は、コンソールからも設定を行えます。 例:

プラグインデータの表示は通常、エージェント表示から行われます。 通常、データ構造はエージェントとモジュールにて定義されるため、プラグインがエージェントとモジュールを作成するのは普通のことです。したがって、これらのデータはエージェント自体の表示メニューに表示できます。

仮想サーバマシンごとにエージェントを作成する Xenserver プラグインなど、多くのプラグインでは複数のエージェントが作成される場合があります。この場合、エージェントのプレフィックスに例えば xen- を定義できるため、エージェントを表示した際に名前にその構造が含まれていることがわかり、それらのエージェントがその特定のプラグインに由来するものであることがわかります。

pspz2 ファイルは、プラグインとモジュールの定義を含む plugin_definition.ini ファイルの 2 つのファイルを zip 圧縮したファイルです。

このファイル形式は、プラグインのインストールを簡素化するため、プラグインをパッケージ化するときに非常に便利です。 この形式を使用すると、Pandora FMS コンソールの “プラグイン登録(plugins registration)” 画面からプラグインをよりすばやくインストールできます。

プラグインの 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: ファイル .pspz に含まれるスクリプトと同じ名前にする必要があります。以前は < script_file > という名前でした。 この例では、ssh_pandoraplugin.sh という名前のシェルスクリプト (.sh 形式) です。

plugin_type: 0 は Pandora FMS 標準のプラグイン、1 は Nagios プラグインです。

total_modules_provided: .ini ファイルの次のセクションで定義されているモジュールの数を指定します。 少なくとも 1 つ設定します (少なくとも例で使用)。

execution_command: 使用する場合は、script の前に置かなければなりません。これは、java -jar のようなインタプリタかもしれません。プラグインは Pandora FMS プラグインサーバから次のようなコードで呼び出され実行されます: java -jar < plugin_path/ plugin_filename

execution_postcommand: 使用すると、< plugin_filename > の後にプラグインに送信される追加パラメータを定義できます。ユーザからは見えません。

total_macros_provided: プラグインが持つ動的マクロの数を定義します。

macro__value: そのモジュールの値を動的マクロで定義し、存在しない場合はデフォルト値をとります。

また、動的マクロごとにセクションを作成しなければいけません。例:

[macro_<N>]
hide = 0
description = <your_description>
help = <text_help>
value = <your_value>

プラグインはできるだけ互換性を持たせることが重要です。ある種のプラグインは、MS Windows® のような特定の OS でしか利用できないサービス特有のものであったりします。しかし、避けられない制限の中で、できるだけ多くのシナリオをカバーできる互換性をプラグインに持たせることが重要です。

OSによっては、他の OS には存在しないパッケージがあり、コンパイルしたプラグインの実行でエラーが発生することがあるため、必要なプラグインの依存関係がすべてインストールされている CentOS 7 OS の環境でプラグインをコンパイルすることをお勧めします。

適切なエラー制御を行うと、プラグインの潜在的な将来起こりうるエラーを検出し、迅速に原因を見つけることができるため、長期にわたってプラグインを維持するのに役立ちます。

また、エラーを正確に検出するのにも役立ちます。エラー制御がないと、特定のケースではエラー出力があまりにも一般的になり、問題が何であるかを理解するのが難しくなる可能性があるためです。

プラグインを開発したら、環境でテストを実行してその動作を確認すると良いです。複数のテスト環境でテストできると良いです。

良いテストプロセスは、起こりうるエラーを解決し、長期にわたってプラグインの動作をより強固にするのに役立ちます。よく言われる「転ばぬ先の杖」です。

プラグインを公開する際には、ある点を考慮することが重要です。

プラグインの中には、最初は理解しにくいものがあります。いくつかのプラグインにはいくつかのオプションがあり、それらを理解するのは少し難しいかもしれません。

良いドキュメントは、それを理解するのに役立ちますし、将来的にはプラグイン制作者自身が、時間が経つにつれて忘れてしまったプラグインのある事柄を思い出すのに役立つことさえあります。

Pandora FMS には、ドキュメントのメンテナンスを容易にするためのオンラインクイックガイドのシステムがあり、以下のリンクからアクセスできます。

The alternative to the documentation in quick-guide format is the PDF format.

クイックガイド形式のドキュメントに代わるものとして、PDF 形式のものもあります。

Pandora FMS ライブラリにプラグインをアップロードする方法は非常に簡単です。ライブラリの “my plugins” セクションにある “upload new module” セクションにアクセスするだけです。

タイトル、プラグインの説明、zip 形式で圧縮されたプラグイン、ドキュメント、カテゴリ、タグなど、エントリーのすべてのセクションを設定したら、submit をクリックしてプラグインを公開することができます。

ライブラリにアップロードされたすべてのプラグインは、最終的なリリース前にレビューが行われます。レビュー時間がかかります。

プラグインが公開されると、“latest uploads” に表示されるようになります。

いくつかのグッドプラクティスは、タスクに費やす時間を減らし、プラグインの作成プロセスやプラグインのメンテナンスのさまざまな段階でよくあるエラーを防止・回避し、それらのレビューを容易にするのに役立ちます。これらは以下の通りです。

• システム上でこれまで行ったことのあるプラグインの設定を行う必要がある場合に備えて、正しく動作する設定を十分に文書化して残しておくこと。
• プラグインの使い方をイメージしやすいように、実際に実行した例をドキュメント化すること。
• プラグインのコードにコメントを書くことで、より深く、あるいはより速く理解することができます。
• コードの読みやすさを優先します。複雑であればあるほど、それに対処するための時間とリソースが必要になります。
• コードのテストをします。プラグインの動作をテストして、すべてが問題ないことを確認することが重要です。エラーを時間内に発見して修正することで、将来的な問題を回避することができます。

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