ja:documentation:pandorafms:monitoring:06_web_monitoring

文書の過去の版を表示しています。


ウェブ監視

In Pandora FMS, the Web Server works on an independent server, the Network Server. This system operates under the web transaction principle, where each complete transaction against one or several WEB pages is defined by one or more consecutive steps, which must conclude satisfactorily to consider the transaction finished successfully.

Pandora FMS では、ウェブサーバは ネットワークサーバ 内で動作します。このシステムは Web トランザクション の原理に基づいて動作します。つまり、1 つ以上の Web ページに対する各トランザクションは、1 つ以上の連続したステップによって定義され、トランザクションが正常に完了したとみなされるには、これらのステップが正常に完了している必要があります。

  • Network Server has important limitations such as dynamic JavaScript management at runtime.
  • For more complex web transactions, Pandora FMS has another much more powerful (and complex) component called WUX Monitoring (Web User Experience).
  • ネットワークサーバには、実行時の JavaScript の動的管理などの重要な制限があります
  • より複雑な Web トランザクション用に、Pandora FMS には WUX 監視 (Web ユーザエクスペリエンス) と呼ばれる、さらに強力な (そして複雑な) コンポーネントがあります。

The Network Server is active by default. Depending on the number of requests, you may need to increase the number of threads and the default timeout:

ネットワークサーバはデフォルトで有効になっています。リクエスト数に応じて、スレッド数とデフォルトのタイムアウト値を増やす必要がある場合があります。

network_threads 4
web_timeout 60

Each module can also use a different timeout.

各モジュールは異なるタイムアウトを使用することもできます。

Pandora FMS has CSRF protection and it may happen that when web checks are debugged, this message is obtained:
Cannot verify the origin of the request
Take this protection into account to consider using “WUX Monitoring”.

Pandora FMS には CSRF に対する保護機能があり、Web チェックをデバッグするときに次のメッセージが表示される場合があります:
Cannot verify the origin of the request
この保護機能を考慮して、“WUX モニタリング” の使用を検討してください。

/etc/pandora/pandora_server.conf
# Uncomment to perform web checks with LWP instead of CURL.
#web_engine lwp

Upon restarting the Pandora FMS Server, LWP will be used to carry out web checks instead of the Curl binary.

Pandora FMS サーバを再起動すると、Curl バイナリの代わりに LWP を使用して Web チェックが実行されます。

For checks over IPv6, FQDN addresses must be used. This means that URLs must have full names, such as ipv6.google.com.
Numerical representation of IPv6 addresses such as ::1 or 2606:4700:3108::ac42:2896 are not valid for performing IPv6 checks with PFMS web modules.

IPv6 のチェックには、FQDN アドレスを使用する必要があります。つまり、URL は ipv6.google.com のように完全な名前でなければなりません。::12606:4700:3108::ac42:2896 のような IPv6 アドレスの数値表現は、PFMS ウェブモジュールで IPv6 チェックを実行する際には無効です。

Menu Management → Resources → Manage agents.

To monitor a web page remotely, select the agent that will contain the new module.
In that agent, click on the corresponding Modules shortcut, click the Create module button , choose Web module from the list, and press the Create button.

メニュー 管理(Management) → リソース(Resources) → エージェント管理(Manage agents)

Webページをリモートで監視するには、新しいモジュールを格納するエージェントを選択します。
そのエージェントで、対応するモジュールショートカットをクリックし、モジュール作成(Create module)ボタンをクリックします。リストからウェブモジュールを選択し、作成(Create)ボタンを押します。

After naming the module, you must choose the type of module to use:

モジュールに名前を付けた後、使用するモジュールの種類を選択する必要があります。

  1. Remote HTTP module to check latency: Obtains the total load time elapsed from the first request until the last one is checked.

  2. Remote HTTP module to check server response: This module type works similarly to the previous one, with the only difference that it lacks thresholds. The only values it obtains are 1 for normal status and 0 for critical status.

  3. Remote HTTP module to retrieve numeric data: Using a regular expression, this module applies it to the HTTP response to obtain a numeric value.

  4. Remote HTTP module to retrieve string data: Using a regular expression, this module compares it against the HTTP response to obtain a text value.

  5. Remote HTTP module to check server status code: The basic check of a web page consists of quickly obtaining its status code and knowing in advance if more checks can be performed.

  1. Remote HTTP module to check latency: 最初のリクエストから最後のチェックが完了するまでのトータルの時間を取得します (ウェブチェックを完了するには、1つ以上のトランザクションがあります)。複数のリクエストが定義されている場合、それぞれの平均時間が利用されます。
  2. Remote HTTP module to check server response: すべてのトランザクションの結果をチェックし、1 (正常) もしくは、0 (異常) を返します。一部のステップが失敗すると、全体を障害として認識します。誤検出を避けるために、リトライ回数を設定することができます。 障害が発生した場合にテストを何回か実行する場合は、リトライ フィールドを使用してください(下記の詳細フィールドを参照)。
  3. Remote HTTP module to retrieve numeric data: 正規表現を利用して HTTP 応答から数値を取得します。
  4. Remote HTTP module to retrieve string data: 正規表現を利用して HTTP 応答から文字列を取得します。
  5. Remote HTTP module to check server status code:: web_engine curl の設定トークンで curl ツールの利用を有効化すると、HTTPヘッダーを返すことができます。

This text box is accompanied by three practical buttons:

このテキストボックスには、便利なボタンが3つ付いています。

  • Button Load basic.
  • ボタン 基本情報を読み込む(Load basic)

Always places the following code regardless of whether it works or is compatible with the selected module type:

常に以下のコードを配置します (動作するか、選択したモジュールタイプと互換性があるかどうかに関わらず):

task_begin
get https://demoweb.com/page/
check_string text string or HTML code to search (regexp)
task_end

The above code is merely illustrative; each type of web module has its specific and/or appropriate instructions for it.

上記のコードはあくまで例示であり、各タイプのウェブモジュールにはそれぞれ固有の、あるいは適切な使用方法があります。

  • Button Check.
  • ボタン チェック(Check)

When pressed, the syntax of the inserted commands will be verified; if they are valid, otherwise it will show a yellow icon with a pop-up message when placing the pointer over it. Essentially, it ensures that it starts with task_begin and that at least one task_end tag appears (this must always appear last). The appropriate parameters for each web query should be reviewed, depending on the module type.

押すと、挿入されたコマンドの構文が検証されます。有効でない場合は、ポインターを重ねたときにポップアップメッセージとともに黄色のアイコン が表示されます。基本的には、task_begin で始まり、少なくとも 1 つの task_end タグ (これは常に最後に存在する必要があります) が存在することを保証します。モジュールタイプに応じて、各ウェブクエリの適切なパラメータを確認する必要があります。

  • Button Debug.
  • ボタン デバッグ(Debug)

Many times it is necessary to determine in detail if the web query is receiving the expected response. To be able to use it, the module must be in a state other than unknown status. The module must also be saved each time before using this button.

ウェブクエリが期待通りの応答を返しているかどうかを詳細に確認する必要がある場合が多くあります。この機能を使用するには、モジュールが「不明」以外の状態である必要があります。また、このボタンを使用する前に、毎回モジュールを保存する必要があります。

With this button, the first thing checked is if a response other than HTTP 200 is received. This is done through the following curl parameter for the get parameter:

このボタンでは、まず HTTP 200 以外のレスポンスが受信されたかどうかを確認します。これは、次の curl パラメータの get を使用して行われます。

-w '%{http_code}'

In the benign case of HTTP 3xx redirects, it will be enough to place the final address after the redirect. The curl command can use the --location parameter to follow the received redirect.
Bear in mind that using --location-trusted will force all established information to be delivered to the redirected URL.

HTTP 3xx リダイレクトの無害なケースでは、リダイレクトの後に最終アドレスを配置するだけで十分です。curl コマンドは、--location パラメータを使用して、受信したリダイレクトを追跡できます。
--location-trusted を使用すると、確立されたすべての情報がリダイレクト先の URL に強制的に配信されることに注意してください。

Receiving an HTTP 200 code does not necessarily mean the page is actually available since it can later be redirected via JavaScript.

HTTP 200 コードを受け取ったからといって、必ずしもページが実際に利用可能であるとは限りません。JavaScript によって後でリダイレクトされる可能性があるからです。

If the -s, -o and -w parameters (and their values) are removed, leaving only the URL, the HTML code itself can be analyzed, which can be useful to rule out a JavaScript redirect, a protection CAPTCHA to determine if it is a human querying, etc.

-s-o-w パラメータ(およびそれらの値)を削除して URL のみを残すと、HTML コード自体を分析できます。これは、JavaScript リダイレクトや、人間によるクエリかどうかを判断するための保護 CAPTCHA などを除外するのに役立ちます。

Some web servers are configured to only serve requests from certain web browsers. For debugging, the curl software allows using the --user-agent parameter to simulate being the desired browser (at the module level, see Agent browser ID):

一部の Web サーバは、特定の Web ブラウザからのリクエストのみを処理するように設定されています。デバッグのために、curl ソフトウェアでは、--user-agent パラメータを使用して、目的のブラウザをシミュレートできます(モジュールレベルでは、エージェントブラウザ ID を参照)。

--user-agent 'Mozilla/5.0 \ 
(Windows NT 10.0; Win64; x64) \ 
AppleWebKit/537.36 \
(KHTML, like Gecko) \ 
Chrome/99.0.4844.84 \ 
Safari/537.36' 'https://pandorafms.com/en/'

If this traditional web monitoring becomes too complicated, you can consider using WUX Monitoring, which can execute JavaScript code and many other functionalities.

従来のウェブ監視が複雑になりすぎる場合は、JavaScript コードやその他の多くの機能を実行できる WUX 監視 の使用を検討してください。

HTTP ヘッダのカスタマイズ

With the header option, you can modify HTTP header fields or create custom fields. To change the Host field of the HTTP header:

header オプションを使用すると、HTTP ヘッダフィールドを変更したり、カスタムフィールドを作成したりできます。HTTP ヘッダーの Host フィールドを変更するには:

task_begin
get http://192.168.1.5/index.php
header Host 192.168.1.1
task_end

プロキシの利用

In each of the web check module types, Basic tab, the following fields necessary for proxy use will appear:

各ウェブチェックモジュールタイプの基本(Basic)タブには、プロキシの使用に必要な以下のフィールドが表示されます。

ウェブサービスと API の監視

REST APIs can be monitored, except for more complex types of APIs based on protocols such as SOAP or XMLRPC.

REST API は監視可能ですが、SOAP や XMLRPC などのプロトコルに基づくより複雑なタイプの API は監視できません。

By checking the output with a regular expression and using a web module to obtain text responses, everything can be verified as correct:

正規表現で出力をチェックし、Webモジュールを使用してテキスト応答を取得することで、すべてが正しいことを検証できます。

task_begin
get http://127.0.0.1/pandora_console/include/api.php?info=version
get_content 786
debug /tmp/api
task_end

For the previous case of PFMS API 1.0, it is expected to return version 786 and for it to be reported as critical status, this value must be placed in the Critical threshold (Min / Max) threshold, checking Inverse interval (any value other than 786 will cause it to change to critical status).

前述の PFMS API 1.0 の場合、バージョン 786 が返されることが想定されており、障害状態として報告するには、この値を 障害しきい値 (最小 / 最大) しきい値に配置し、条件の反転(Inverse interval) を確認する必要があります (786 以外の値になると、障害状態に変更されます)。

For more complex responses, other regular expressions and the get_content_advanced token must be used.

より複雑なレスポンスの場合は、他の正規表現と get_content_advanced トークンを使用する必要があります。

  • When making API calls, it is important to keep in mind that the destination API must have permissions to be queried.
  • API呼び出しを行う際は、呼び出し先の API がクエリを実行するための権限を持っていることを確認することが重要です。

In the following case with a response in JSON format, the license_mode field is searched for and then its content is extracted with a regular expression:

以下の JSON 形式のレスポンスの場合、license_mode フィールドが検索され、正規表現を使用してその内容が抽出されます。

task_begin
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=license&return_type=json&apipass=1234&user=admin&pass=pandora
get_content_advanced "license_mode":"([A-Za-z ]+)"
debug /tmp/api_license
task_end

For the above, the response is expected to be Perpetual in the critical threshold with inverse interval activated: Any other type of license will cause the module status to change.

上記の場合、条件の反転が有効になっている障害しきい値では、応答は Perpetual になると予想されます。その他の種類のライセンスでは、モジュールの状態が変更されます。

シンプルな HTTP 認証の利用

By default, web checks in PFMS Server are performed without any user authorization (Anyauth in the Check type field). Some pages may require Simple HTTP authentication (or other historically standardized methods). It is generally used as a quick check, a minimum security greeting that allows access to more advanced security checks (encryption, data persistence, etc.).

デフォルトでは、PFMS サーバのウェブチェックはユーザ認証なしで実行されます (チェックタイプ(Check type) フィールドの Anyauth)。一部のページでは、簡易 HTTP 認証 (またはその他の従来標準化された方法) が必要になる場合があります。これは通常、より高度なセキュリティチェック (暗号化、データ永続性など) へのアクセスを可能にする、最小限のセキュリティ の入り口として、迅速なチェックに使用されます。

  • Using quotes in the password for http_auth_pass is not supported.
  • Avoid using single quotes.
  • http_auth_pass のパスワードに引用符を使用することはサポートされていません。
  • シングルクォーテーションの使用は避けてください。

Consider the following file with PHP code hosted in the root of a web server called https://example.com/:

https://example.com/ というウェブサーバのルートディレクトリにホストされている、PHP コードを含む以下のファイルを考えてみましょう。

your_file_name.php
<?php
# BASIC authentication
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="My Realm"');
    header('HTTP/1.0 401 Unauthorized');
    exit;
} else {
    echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>";
    echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";
}
?>
  1. The HTML code is the minimum for the test.
  2. No identity check is performed. It is simply expected that a username and password be provided according to the BASIC authentication standard.
  3. In the PFMS Server, a Remote HTTP module to check server response module will be added to an agent (verify that this module type has been chosen) in this way:
  1. HTMLコードはテストに必要な最小限のコードです。
  2. 本人確認は行われません。BASIC 認証規格に従ってユーザ名とパスワードが入力されることが前提となります。
  3. PFMS サーバでは、Remote HTTP module to check server responseモジュールがエージェントに追加されます(このモジュールタイプが選択されていることを確認してください)。追加方法は以下のとおりです。
task_begin
# BASIC authentication
get https://example.com/your_file_name.php
check_string Pandor4!
task_end
  • In the Check type field, BASIC must be selected.
  • In the HTTP auth (login) field, place any user.
  • In the HTTP auth (password) field, place Pandor4!.
  • Save the module and force the check.
  • チェックタイプ(Check type) フィールドで BASIC を選択します。
  • HTTP認証(ログイン)(HTTP auth (login)) フィールドには、任意のユーザ名を入力します。
  • HTTP認証(パスワード)(HTTP auth (password)) フィールドには、Pandor4! を入力します。
  • モジュールを保存し、チェックを強制実行します。

The check_string command will verify that the dummy test passwords match and will set the module to normal. To test and verify the critical status, change the HTTP auth (password) field to any other value and repeat the procedure.

check_string コマンドは、ダミーのテストパスワードが一致することを確認し、モジュールを通常状態に設定します。障害状態をテストおよび検証するには、HTTP 認証 (パスワード)(HTTP auth (password)) フィールドを別の値に変更し、手順を繰り返します。

Similarly, the test PHP file can be changed with other authentication standards.

同様に、テスト用の PHP ファイルは、他の認証規格に合わせて変更することも可能です。

  • DIGEST:
your_file_name.php
<?php
# DIGEST authentication
<?php
if (!isset($_SERVER['PHP_AUTH_DIGEST'])) {
    header('HTTP/1.1 401 Unauthorized');
    header('WWW-Authenticate: Digest realm="My Realm",
           qop="auth", nonce="' . uniqid() . '",
           opaque="' . md5('My Realm') . '"');
    exit;
}

// Process the digest authentication
echo $_SERVER['PHP_AUTH_DIGEST'];
?>
task_begin
# DIGEST authentication
get https://example.com/your_file_name.php
check_string admin
task_end

ウェブページ上のフォームチェック

A form check is much more complex than simple text checking on a web page. To be able to perform these types of checks (POST), you must have the necessary credentials and/or variables. Additionally, it is necessary to go to the page and obtain the HTML code to get the variable names, and then minimum knowledge of HTML is required to enter the query for the Network Server.

フォームチェックは、Web ページ上の単純なテキストチェックよりもはるかに複雑です。このようなチェック (POST) を実行するには、必要な認証情報や変数が必要です。さらに、ページにアクセスして HTML コードを取得し、変数名を取得する必要があります。その後、ネットワークサーバ のクエリを入力するには、HTML に関する最低限の知識が必要です。

The practical method for designing a multi-step WEB transactional test is to test each block of code, adding them one by one with the error debugging command. The debug button is disabled for these types of cases.

複数ステップの WEB トランザクションテストを設計する実際的な方法は、error debugging コマンドを使用してコード ブロックを 1 つずつ追加してテストすることです。このようなケースでは、debug button は無効になります

Consider the following file with PHP code hosted at the root of a web server called https://example.com/:

https://example.com/ というウェブサーバのルートディレクトリにホストされている、PHP コードを含む以下のファイルを考えてみましょう。

your_file_name.php
<?php
   if( $_POST["name"] || $_POST["age"] ) {
      echo "Welcome <b>". $_POST['name']. "</b><br />";
      echo "You are <i>". $_POST['age']. "</i> years old.<br />";
      echo 'Now: '.time();
      exit();
   }
?>
<form action = "<?php $_PHP_SELF ?>" method = "POST">
   Name: <input type = "text" name = "name" />
   Age: <input type = "text" name = "age" />
   <input type = "submit" />
</form>

  - For educational reasons, strict HTML code is omitted.   - The first visit shows a simple form to enter name and age, and at least one of them must be entered. When sending the data via POST, a message will be displayed showing said entered value or values.   - The $_PHP_SELF command allows using any valid filename.   - The time() command (UNIX time) will be used in the debug (log) files in a separate terminal window.

  1. 厳密な HTML コードは省略しています。
  2. 初回アクセス時には、名前と年齢を入力する簡単なフォームが表示されます。少なくともどちらか一方を入力する必要があります。POST でデータを送信すると、入力された値が表示されます。
  3. $_PHP_SELFコマンドを使用すると、任意の有効なファイル名を指定できます。
  4. time() コマンド(UNIX 時間)は、別のターミナルウィンドウに表示されるデバッグ(ログ)ファイルで使用されます。

In the PFMS Server, an agent will be chosen to add a Remote HTTP module to check server response module with the following script:

PFMS サーバでは、エージェントが選択され、次のスクリプトを使用してRemote HTTP module to check server response モジュールを追加します。

task_begin
debug /tmp/post_variable
variable_name name
variable_value JIMMY
variable_name age
variable_value 99
post https://example.com/your_file_name.php
# Verify if exists "<b>Jimmy<b>":
check_string \<b\>Jimmy\<\/b\>
task_end

The post command is in charge of performing the web query. Note that then the check_string command checks uppercase or lowercase indifferently. If the variable is found with the name, it will report normal status, otherwise the module will go into critical status. This last part can be tested and verified by making the following change and then forcing the check on the agent:

post コマンドは、Web クエリを実行する役割を担います。なお、check_string コマンドは、大文字と小文字を区別せずにチェックします。変数が指定された名前で見つかった場合は、正常状態が報告されます。それ以外の場合は、モジュールは重大な状態になります。この最後の部分は、次の変更を行い、エージェントでチェックを強制することでテストおよび検証できます。

variable_name name
variable_value Kevin

リクエスト数と再試行回数

In modules for web checks, the Requests (Basic tab) and Retries (Data tab) fields are included via the Web Console.

Web チェック用のモジュールでは、リクエスト(Requests) (基本(Basic) タブ) と 再試行(Retries) (データ(Data) タブ) フィールドが Web コンソールに含まれます。

Pandora FMS will repeat the check the number of times indicated in this parameter. If one of the checks fails, the check will be considered failed.
Depending on the amount of checks in the module, a certain number of pages will be obtained. It is important to keep this in mind to calculate the total time it will take the module to complete operations.

Pandora FMS は、このパラメータで指定された回数だけチェックを繰り返します。いずれかのチェックが失敗した場合、そのチェックは失敗とみなされます。
モジュール内のチェックの数に応じて、取得されるページ数が決まります。モジュールが操作を完了するのにかかる合計時間を計算する際には、この点を考慮することが重要です。

The number of times it performs a Request until a successful result is obtained.

成功した結果が得られるまで、Request を実行する回数。

ウェブブラウザ識別子

ウェブチェックタイムアウト

The timeout is defined by default in the web_timeout token as 60 seconds.

タイムアウトは、デフォルトでは web_timeout トークンで 60 秒として定義されています。

If a different timeout is needed for a specific module, it can be configured in the Timeout field of the Data tab.

特定のモジュールに対して異なるタイムアウトが必要な場合は、データ(Data) タブの タイムアウト(Timeout) フィールドで設定できます。

task_begin
[resource <1|0>]
[cookie <1|0>]
[post url]
[get url]
[head url]
[check_string text]
[check_not_string text]
[variable_name variable]
[variable_value value]
[get_content regular_expression]
[get_content_advanced html(regular_expression)html]
[header html_header]
[debug path_to_log]
task_end

task_begin
[resource <1|0>]
[cookie <1|0>]
[post url]
[get url]
[head url]
[check_string テキスト]
[check_not_string テキスト]
[variable_name 値]
[variable_value 値]
[get_content 正規表現]
[get_content_advanced html(正規表現)html]
[header HTMLヘッダ]
[debug ログのパス]
task_end

Marks the start of a block of code which must end with task_end.

task_endで終了しなければならないコードブロックの開始を示します。

Each web module must contain at least one block of code, with at least one instruction to execute:

各ウェブモジュールには、少なくとも1つのコードブロックと、少なくとも1つの実行命令が含まれている必要があります。

task_begin
head https:/example.com/
task_end

Several blocks of code can be added when forms need to be checked or, in general, when several additional steps have to be performed to reach a specific result:

フォームのチェックが必要な場合、または一般的に、特定の結果を得るために複数の追加手順を実行する必要がある場合は、複数のコードブロックを追加できます。

  • The most common case is form checking, whether for user authentication processes or filling out a survey with one or more fields to fill in.
  • Another case would be querying a specific web page and, according to its response, continuing and performing a second query. In this scenario, the result of the first and second code blocks must be successful for the complete check to be given as positive and move on to comparing with the module's thresholds to determine if its status should change.
  • 最も一般的なケースは、ユーザ認証プロセスや、1つ以上の入力項目を含むアンケートへの回答など、フォームチェックです。
  • 別のケースとしては、特定の Web ページを照会し、その応答に基づいて次の照会を実行するケースが挙げられます。このシナリオでは、最初のコードブロックと 2番目のコードブロックの両方の結果が成功して初めて、完全なチェックが成功と判断され、モジュールのしきい値との比較を経て、ステータスを変更するかどうかが決定されます。

Specifies (resource 1) if multimedia elements such as images, sound, etc. will be downloaded in a code block.

画像や音声などのマルチメディア要素が コードブロック でダウンロードされる場合、(resource 1) を指定します。

If this command does not appear in a code block, resource 0 is implicitly used.

このコマンドがコードブロック内に記述されていない場合、resource 0 が暗黙的に使用されます。

Specifies (cookie 1) if the cookies obtained in a code block will be stored for subsequent use in other code blocks.

コードブロックで取得したクッキーを他のコードブロックで後続で使用するために保存するかどうかを指定します(cookie 1)。

If this command does not appear in a code block, cookie 0 is implicitly used.

このコマンドがコードブロック内に記述されていない場合、cookie 0 が暗黙的に使用されます。

post

Command that, using variable_name and variable_value, specifies the web check URL. If it is used more than once in a code block, the URL to be examined will be the one specified in its last appearance.

このコマンドは、variable_namevariable_value を使用して、ウェブチェックの URL を指定します。コードブロック内で複数回使用された場合、検査対象の URL は最後に指定された URL になります。

Command that specifies the web check URL. If it is used more than once in a code block, all URLs will be examined; however, the URL specified in its last appearance will be the one providing the data for the check.

ウェブチェックの URL を指定するコマンドです。コードブロック内で複数回使用された場合、すべての URL が検査されますが、最後に指定された URL がチェックデータを提供する URL となります。

Special command that returns the specific HTTP header code response in a web check.

ウェブチェックにおいて、特定の HTTP ヘッダコード応答を返す特別なコマンド。

The response format is HTTP/V XXX where V is the version and XXX the code. Some responses that can be obtained: HTTP/2 403, HTTP/1.1 200, HTTP/1 302, etc.

応答形式は HTTP/V XXX で、V はバージョン、XXX はコードです。取得できる応答の例としては、HTTP/2 403HTTP/1.1 200HTTP/1 302 などがあります。

Generally used as the only command in a single code block, see “Server status code check” for more information.

通常は単一の コードブロック 内の唯一のコマンドとして使用されます。詳細については、サーバステータスコードチェック を参照してください。

Checks that a specific text string exists in the web check being performed. The returned result is a boolean variable (0 false, any other value is true) and must be stored in a server response check module type (web_proc type).

実行中のウェブチェックに特定のテキスト文字列が存在するかどうかを確認します。返される結果はブール変数(0 は偽、その他の値は真)であり、サーバ応答チェックモジュールタイプweb_proc タイプ)に格納する必要があります。

The arguments taken by the check_string syntax are not normal text strings, they are regular expressions. Any character that is not a letter or a number will have to be escaped with \:

check_string 構文で受け取る引数は、通常のテキスト文字列ではなく、正規表現です。文字または数字以外の文字はすべて \ でエスケープする必要があります。

task_begin
get https://apache.org/
# Comment: Search "/images/oakleaf.svg" (including quotation marks)
check_string \"\/images\/oakleaf\.svg\"
debug /tmp/apache
task_end

Note that although the period can do without being escaped, in the previous code it has been denoted to emphasize regular expression syntax.
A debug instruction is included in case queries and responses need to be analyzed. Once this work is done, and to save storage space, it is recommended to remove it from routine monitoring.

ピリオドはエスケープしなくても問題ありませんが、前のコードでは正規表現構文を強調するためにエスケープされています。
debug 命令は、クエリとレスポンスを分析する必要がある場合に備えて含まれています。この作業が完了したら、ストレージ容量を節約するために、ルーチン監視から削除することをお勧めします。

The following “clean” code is equally valid even if the order of appearance of the get command has been changed (and even if the Check button indicates an error) within the same code block task_begintask_end:

以下の「クリーン」コードは、同じコードブロック get 内において、task_begintask_end 内で get コマンドの出現順序が変更された場合(および チェックボタン がエラーを示している場合)でも同様に有効です。

task_begin
check_string \"\/images\/oakleaf.svg\"
get https://apache.org/
task_end

See also “Form check on a web page

ウェブページ上のフォームチェック も参照してください。

Checks that the web check being performed lacks a specific text string. In the rest of its operation it is the same as check_string.

実行中のウェブチェックに特定のテキスト文字列が欠落しているかどうかを確認します。その他の操作は、check_string と同じです。

Declares a variable whose value will be set by the next variable_value instruction. For greater code clarity, it is recommended to use in ordered pairs of contiguous lines.

次の variable_value 命令によって値が設定される変数を宣言します。コードの可読性を高めるため、連続する行の順序付きペアで使用することをお勧めします。

The debug button omits syntax verification of this command: If a value is omitted and/or there is disparity with variable_value, it will still and always show a correct syntax.

デバッグボタンはこのコマンドの構文検証を省略します。値が省略された場合、または variable_value と不一致がある場合でも、常に正しい構文が表示されます。

This pair (or pairs) of instructions must be accompanied by a post command. In the web query, the order of appearance of the variables will be the last one declared first, the second to last declared second, and so on.

この命令のペア(または複数のペア)には、post コマンドが必ず必要です。ウェブクエリでは、変数の出現順序は、最後に宣言されたものが最初、最後から2番目に宣言されたものが2番目、といった具合になります。

ウェブページ上のフォームチェック も参照してください。

Sets the value of a variable declared with variable_name.

variable_nameで宣言された変数の値を設定します。

For greater code clarity (and to facilitate debugging tasks, if applicable) it is recommended to use in ordered pairs of contiguous lines, first variable_name and then variable_value.

コードの明瞭性を高めるため(また、該当する場合はデバッグ作業を容易にするため)連続する行の順序付きペアで、最初に variable_name、次に variable_value を使用することをお勧めします。

The debug button omits syntax verification of this command: If a value is omitted and/or there is disparity with variable_name, it will still and always show a correct syntax.

デバッグボタン はこのコマンドの構文検証を省略します。値が省略された場合、または variable_name と不一致がある場合でも、常に正しい構文が表示されます。

While these instructions can be placed in any order, this can cause unpredictable results if odd or orphan commands are accidentally established.

これらの命令は任意の順序で配置できますが、奇妙なコマンドや孤立したコマンドが誤って作成されると、予期しない結果が生じる可能性があります。

ウェブページ上のフォームチェック も参照してください。

Unlike the check_string and check_not_string commands, which only return a true or false result, the get_content command is used when a numeric value or a specific text string needs to be obtained.

check_string および check_not_string コマンドは、真偽値のみを返しますが、 get_content コマンドは、数値または特定のテキスト文字列を取得する必要がある場合に使用されます。

Similarly, these three commands use regular expressions to perform their work with the fundamental difference that get_content delivers the full result of its search.

同様に、これら 3 つのコマンドは 正規表現 を使用して処理を実行しますが、根本的な違いは get_content が検索の完全な結果を返すことです。

To obtain a numeric value from an API-type query, the following code can be used
get_content \d+ in a code block task_begintask_end:

API タイプのクエリ から数値を取得するには、次のコードを使用できます。
get_content \d+ コードブロック内 task_begintask_end:

task_begin
get http://127.0.0.1/pandora_console/include/api.php?apipass=1234&user=admin&pass=pandora&op=get&op2=total_modules&id=0
get_content \d+
debug /tmp/num_of_modules
task_end

Allows extracting a text string in an HTML element. “Numeric” values can also be extracted, depending on the regular expression used. Syntax:

HTML 要素内のテキスト文字列を抽出できます。使用する正規表現によっては、「数値」も抽出できます。構文:

task_begin
get <URL>
get_content_advanced <html_code>(regex)</html_code>
task_end

It must be used in conjunction with get to set the URL to check. Once its HTML content is obtained, the entire page will be searched until an HTML element match is found and its content will be returned. See “Obtaining text data from a web page”.

チェック対象の URL を設定するには、getと組み合わせて使用​​する必要があります。HTML コンテンツが取得されると、ページ全体が検索され、一致する HTML要素が見つかり、そのコンテンツが返されます。詳細については、“Webページからテキストデータを取得する” を参照してください。

Allows adding HTTP headers to the web query.

ウェブクエリに HTTP ヘッダを追加できるようにします。

By default, Curl is used to perform web checks and two elements are always included:

デフォルトでは、Curl がウェブチェックを実行するために使用され、常に 2つの要素が含まれます。

  1. -H 'Pragma: no-cache': Used to skip CDN cache. Pragma is compatible with HTTP 1.0 (the most used HTTP versions currently are 1.1 and 2.0).
  2. -H 'Accept: text/html': This indicates that the HTML code is requested as the first response.
  1. -H 'Pragma: no-cache': CDN キャッシュをスキップするために使用します。Pragma は HTTP 1.0 と互換性があります(現在最もよく使用されている HTTP バージョンは 1.1 と 2.0 です)。
  2. -H 'Accept: text/html': HTML コードを最初のレスポンスとして要求することを示します。

With header included in a task_begintask_end block, additional value pairs can be specified. In a PFMS API 1.0 query, this is very useful when authenticating via a user's private Bearer token and then checking an expected response value with check_string:

task_begintask_end ブロックに header が含まれている場合、追加の値ペアを指定できます。PFMS API 1.0 クエリでは、これはユーザのプライベート Bearer トークン を介して認証し、その後 check_string を使用して期待される応答値をチェックする場合に非常に便利です。

task_begin
header Authorization Bearer 05c43863bf76c54456837ea7c3008e56
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=test
debug /tmp/api
check_string 786
task_end

It could also be useful for explicitly requesting a response in a specific language:
header Accept-Language en-US.

また、特定の言語での応答を明示的に要求する場合にも役立ちます:
header Accept-Language en-US

With header, it is unnecessary to use double or single quotes, or colons, since when executing the check these characters are inserted in the appropriate way:

header の場合、二重引用符や一重引用符、コロンを使用する必要はありません。チェックを実行する際に、これらの文字は適切な方法で挿入されるためです。

  • The language header Accept-Language es-ES is queried with Curl as follows:
    -H 'Accept-Language:es-ES'
  • The referrer (indicates the web page visited previously) header Referer pandorafms.com:
    -H 'Referer:pandorafms.com'
  • If the queried web server requires particular headers, these must start with -X…. It is usually followed by one or more hyphens and then the name and value of the header itself.
    Take the case of sending a customer identifier header X-Customer-ID “Ñ123”, it is queried:
    -H 'X-Customer-ID:"Ñ123"' (note the use of double quotes to wrap Ñ123).
  • 言語ヘッダ Accept-Language es-ES は、Curl を使用して次のように照会します。
    -H 'Accept-Language:es-ES'
  • referrer(以前にアクセスしたウェブページを示す)header Referer pandorafms.com:
    -H 'Referer:pandorafms.com'
  • 照会先のウェブサーバが特定のヘッダを要求する場合、それらは -X… で始まる必要があります。通常、その後に 1つ以上のハイフンが続き、その後にヘッダー名と値が続きます。
    顧客識別子 header X-Customer-ID “Ñ123” を送信する場合、クエリは次のようになります。
    -H 'X-Customer-ID:"Ñ123"' (二重引用符を使用して Ñ123 を囲んでいることに注意してください)。

See also:

以下も参照してください:

Web checks can be debugged by adding the debug\_<path>/<file_name> option.
Two files <path><file_name>.req and <path><file_name>.res will be created with the contents of the HTTP request and response, respectively:

ウェブチェックは、debug\_<path>/<file_name> オプションを追加することでデバッグできます。
HTTP リクエストとレスポンスの内容がそれぞれ <path><file_name>.req<path><file_name>.res という 2 つのファイルが作成されます。

task_begin
get http://192.168.1.5/index.php
debug /tmp/debug_file
task_end

When forcing checks to speed up debugging work, you must always wait for the response from the server or device being monitored. There is at least one way to see the content of these files in real time via command line:

デバッグ作業を高速化するために強制チェックを行う場合、監視対象のサーバまたはデバイスからの応答を必ず待つ必要があります。コマンドラインを使用してこれらのファイルの内容をリアルタイムで確認する方法が少なくとも1つあります。

tail -f <path><file_name>.res --retry

These debugging files, once created with the provided name, will always have subsequent queries and responses added to them, which will always cause an increase in their size. Once debugging is finished, it is recommended to remove all debug instructions.

指定された名前で作成されたこれらのデバッグファイルには、後続のクエリとレスポンスが必ず追加され、ファイルサイズが常に増加します。デバッグが完了したら、すべての debug 命令を削除することをお勧めします。

Marks the completion of a block of codes. See task_begin.

コードブロックの完了を示します。task_begin を参照してください。

To check the response time in seconds (latency) of a web page, select the Remote HTTP module to check latency module type.

ウェブページの応答時間(レイテンシ)を秒単位で確認するには、Remote HTTP module to check latency モジュールタイプを選択します。

The download time of the web's HTML code is different from the time it takes to display a web in a browser. The latter usually depends on the loading time of multimedia elements and the loading and execution of the incorporated JavaScript code.

ウェブサイトの HTML コードのダウンロード時間と、ブラウザでウェブサイトを表示するのにかかる時間は異なります。後者は通常、マルチメディア要素の読み込み時間と、組み込まれた JavaScript コードの読み込みおよび実行時間に依存します。

In a WEB test, one or several intermediate requests may exist that complete the transaction. In this way, it obtains the total time elapsed from the first request until the last one is checked.

ウェブテストでは、トランザクションを完了させるために、1つまたは複数の中間リクエストが存在する場合があります。このようにして、最初のリクエストから最後のリクエストがチェックされるまでの合計経過時間を取得します。

task_begin
get https://pandorafms.com
task_end
  • If the check definition states that the transaction is performed more than once (get command), the average time of each request will be used.
  • Thresholds for warning and critical states must be set by the user.
  • For the download time to include all resources (JavaScript, CSS, images, etc.), resource 1 must be added in a line before task_end.
  • Web checks also support the use of proxy servers; for this, the fields named Proxy that are necessary must be completed.
  • The debug parameter is used to keep an accumulated record in two files of both the query and the response of each check.
  • チェック定義でトランザクションが複数回実行される場合(getコマンド)、各リクエストの平均時間が使用されます。
  • 警告状態と障害状態のしきい値はユーザが設定する必要があります。
  • ダウンロード時間にすべてのリソース(JavaScript、CSS、画像など)を含めるには、resource 1task_endの前の行に追加する必要があります。
  • ウェブチェックはプロキシサーバの使用もサポートしています。そのためには、必要なProxyという名前のフィールドを入力する必要があります。
  • debug パラメータは、各チェックのクエリとレスポンスの両方の累積レコードを 2つのファイルに保持するために使用されます。

With a Remote HTTP module to check server response type module, a 1 (OK) or a 0 (CRITICAL) is obtained as a result of checking the entire transaction.

Remote HTTP module to check server response タイプのモジュールでは、トランザクション全体をチェックした結果、1正常(OK))または 0障害(CRITICAL))が得られます。

The module type (web_proc) used here dispenses with values set in the thresholds: It only accepts false (0) and true values. In this way, it is uniquely and automatically associated with normal and critical (0) states.

ここで使用されているモジュールタイプ(web_proc)は、しきい値に設定された値を必要としません。偽(0)と真の値のみを受け入れます。このようにして、正常状態と障害状態(0)に一意かつ自動的に関連付けられます。

If there are several attempts but at least one of them fails, the test as a whole is also considered to have failed. Specifically, the number of attempts is sometimes used to avoid false positives; for this, use the Requests field in advanced options.

複数回試行しても、そのうち少なくとも 1回が失敗した場合、テスト全体も失敗したとみなされます。具体的には、試行回数は誤検出を回避するために使用されることがあります。そのためには、詳細オプションのRequests フィールドを使用してください。

In its basic syntax, it is enough to add the following in the Web Checks box:

基本的な構文では、ウェブチェック(Web Checks) ボックスに以下を追加するだけで十分です。

task_begin
get <URL>
task_end

Unlike the HTTP status check, the previous check brings all the HTML code, which can be used for additional purposes such as checking that a text string exists on said website with check_string:

HTTPステータスチェックとは異なり、前述のチェックではすべての HTML コードが取得されるため、check_string を使用して、指定された Web サイトにテキスト文字列が存在するかどうかを確認するなど、追加の目的に使用できます。

task_begin
get <URL>
check_string <text>
task_end
  • If the requested text string exists, it will go into normal status, otherwise it will go into critical.
  • check_not_string <text> can be used for the opposite case: If the indicated text is not found, it will go into normal status, otherwise it will go into critical.
  • Although other parameters such as resource can be used to download all resources (images, etc.), this will only overload the PFMS Server with unnecessary work.
    The addition of other parameters must be weighed carefully; only those really necessary should be used, especially if it is a simple query.
  • The same applies to downloading and saving cookies; unless other web check steps are going to be performed, you can explicitly declare to skip them:
  • 要求されたテキスト文字列が存在する場合は、通常ステータスに移行し、存在しない場合はクリティカルステータスに移行します。
  • check_not_string <テキスト> は、逆の場合に使用できます。指定されたテキストが存在しない場合は、通常ステータスに移行し、存在する場合はクリティカルステータスに移行します。
  • resource などの他のパラメータを使用してすべてのリソース(画像など)をダウンロードすることもできますが、これは PFMS サーバに不要な負荷をかけるだけです。他のパラメータの追加は慎重に検討する必要があります。特に単純なクエリの場合は、本当に必要なもののみを使用してください。
  • cookies のダウンロードと保存についても同様です。他のウェブチェック手順が実行されない限り、明示的にスキップするように指定できます。
task_begin
get https://apache.org/
# No save cookie
cookie 0
# Do not download images, etc
resource 0
check_string Jimmy
debug /tmp/apache
task_end

Note the use of comments at the beginning of a line with # .

行頭に # を付けるとコメントになることに注意してください。

To check that a web page responds with a numeric value, or contains a specific value, the Remote HTTP module to retrieve numeric data module type is used.

ウェブページが数値で応答するか、特定の値を含むかどうかを確認するには、Remote HTTP module to retrieve numeric data モジュールタイプを使用します。

For this, the basic query get_content \d+ can be used (the added regular expression filters only digits). The mechanism is to analyze the entire HTTP response from the beginning and start comparing until it matches the given regular expression.

このためには、基本的なクエリ get_content \d+ を使用できます(追加された正規表現は数字のみをフィルタリングします)。このメカニズムは、HTTP レスポンス全体を最初から分析し、指定された正規表現に一致するまで比較を開始することです。

* Thresholds for warning and critical states must be set by the user. By default, these thresholds are zero, so any valid numeric check obtained will be classified as normal status.

  • Proxy servers can be used by completing the necessary Proxy fields.
  • Adding the debug instruction keeps the queries and responses in two files to be debugged later.
  • To force a direct query with Curl to the web server (thus skipping CDN cache), PFMS includes the command header Pragma: no-cache by default.
    Pragma was chosen instead of Cache-Control to maintain compatibility with HTTP 1.0 (the most used versions currently are 1.1 and 2.0).
  • For an advanced query and to extract a numeric value from any HTML element on the page, such as a level 3 heading or the first paragraph that appears with a specific CSS Attribute, see the get_content_advanced parameter.
  • 警告状態と障害状態のしきい値はユーザが設定する必要があります。 デフォルトではこれらのしきい値はゼロなので、有効な数値チェックはすべて正常状態として分類されます。
  • プロキシサーバ は、必要な Proxy フィールドに入力することで使用できます。
  • debug 命令を追加すると、クエリとレスポンスが 2 つのファイルに保存され、後でデバッグできます。
  • Curl を使用して Web サーバに直接クエリを実行する(CDN キャッシュをスキップする)ために、PFMS にデフォルトで header Pragma: no-cache コマンドが含まれています。
    HTTP 1.0 との互換性を維持するために、Cache-Control の代わりに Pragma が選択されました(現在最もよく使用されているバージョンは 1.1 と 2.0 です)。
  • 高度なクエリを実行して、レベル 3 の見出しや特定の CSS 属性とともに表示される最初の段落など、ページ上の 任意の HTML 要素から数値を抽出するには、get_content_advanced パラメーターを参照してください。

If no figure is obtained from the last check, or the web server is unable to respond or is unreachable, the last value and therefore the last recorded state of the module will be kept.

最後のチェックで数値が得られなかった場合、または Web サーバが応答できないかアクセスできない場合は、最後の値、つまりモジュールの最後に記録された状態が保持されます。

The Remote HTTP module to retrieve string data module type works similarly to its numeric counterpart without the inconvenient filtering process to guarantee only figures.

Remote HTTP module to retrieve string data モジュールタイプは、数値版と同様に動作しますが、数値のみを保証するためのフィルタリング処理は不要です。

task_begin
get https://academy.pandorafms.com/
get_content_advanced <h3 class="h2-b">(.*)</h3>
task_end

Here get_content_advanced is the key parameter that allows choosing an HTML element (in this case a level three heading h3, class ha2-b) and then, according to a regular expression (.*), extracting the character string located there.

ここで get_content_advanced は、HTML 要素 (この場合はレベル 3 の見出し h3、クラス ha2-b) を選択し、正規表現 (.*) に従って、そこにある文字列を抽出することを可能にするキーパラメータです。

Since for the normal condition values cannot be compared, the warning threshold or the critical threshold is used with the inverse interval set with the expected text:

通常の状態では値を比較できないため、期待される次のようなテキストおよび条件の反転設定とともに、警告しきい値または障害しきい値が使用されます。

Terms &amp; Important Notes (note the use of entities in the received HTML code).

Terms &amp; Important Notes(受信したHTMLコードにおけるエンティティの使用に注意してください)

To check the status code of a web page, select the Remote HTTP module to check server status code module type (web_server_status_code_string type) with the following task_begintask_end code block:

ウェブページのステータスコードを確認するには、次の task_begintask_end コードブロックを使用して、Remote HTTP module to check server status code モジュールタイプ (web_server_status_code_string タイプ) を選択します。

task_begin
head https://pandorafms.com
task_end
  • In the server configuration, Curl must be used.
  • It is important to use the head parameter to obtain the status code.
  • To configure the critical threshold, HTTP/X 200 OK can be placed (where X is the protocol version) and marking the inverse interval:
  • サーバ設定では、Curl を使用する必要があります。
  • ステータスコードを取得するには、head パラメータを使用することが重要です。
  • 障害しきい値を設定するには、HTTP/X 200 OKXはプロトコルバージョン)を指定し、条件の反転を指定します。

This way, upon receiving any different response, the module will change to critical status:

このように、異なる応答を受け取った場合、モジュールは障害状態に変わります。

In addition to the functionality offered by PFMS Web server, there is another way to perform transactional monitoring: Web User Experience Monitoring (WUX).

PFMS ウェブサーバが提供する機能に加えて、トランザクション監視を実行する別の方法があります: ウェブユーザエクスペリエンス監視(WUX)

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

To check the response time or latency of a web page, select the module type Remote HTTP module to check latency. Example:

ウェブの応答時間をチェックしたい場合は、モジュールタイプ Remote HTTP module to check latency を選択します。例:

task_begin
get https://pandorafms.com
task_end
  • For the download time to include all resources (JavaScript, CSS, images, etc.), resource 1 must be added in a line before task_end.
  • Web checks also support the use of proxy in the Proxy URL token.
  • すべてのリソース (JavaScript、CSS、画像など) のダウンロード時間取得には、task_end の前の行に resource 1 を追加する必要があります。
  • Web チェックでは、Proxy URL トークンでのプロキシの使用もサポートされています。

The web download time is not the time it takes to display a website in a browser, as this is usually dependent on the JavaScript load time.

ウェブサイトのダウンロード時間は、ブラウザで Web サイトを表示するのにかかる時間ではありません。通常、これはJavaScriptの読み込み時間に依存し、JavaScriptをダウンロードしますが、実行しません。

A form check is much more complex than simply checking text on a web page. In order to perform this type of check, you must have the necessary credentials. In addition, you need to go to the page and get the HTML code to get the variable names, and then you need to have minimal knowledge of HTML to enter the query for the Network Server.

フォームチェックは、Webページ上のテキストを単純にチェックするよりもはるかに複雑です。この種のチェックを実行するには、必要な認証情報が必要です。さらに、ページにアクセスしてHTMLコードを取得し、変数名を取得する必要があります。さらに、ネットワークサーバへのクエリを入力するには、最低限のHTMLの知識が必要です。

The practical method to design a WEB transactional test with several steps is to test them one by one in debugging mode.

複数のステップを含む WEB トランザクションテストを設計する実用的な方法は、デバッグモードでステップを 1 つずつテストすることです。

Pandora コンソールのログイン URL が以下であると仮定します。

http://192.168.70.116/pandora_console/

HTML コードを確認すると、ログインフォームの変数は次の通りです。

  • nick> ユーザ名
  • pass> パスワード

フォームの認証を通すためには、変数 variable_name および variable_value の両方が必要です。Pandora FMS コンソールのデフォルトは、admin および pandora です。

最初のステップはフォームへのアクセスです。次に、ユーザとパスワードを送り認証します。(認証の成功を 2つ目のステップで確認します)

task_begin
post http://192.168.70.116/pandora_console/index.php?login=1
variable_name nick
variable_value admin
variable_name pass
variable_value pandora
cookie 1
resource 1
task_end

上記の設定で、ウェブページにアクセスし認証することができます。これにより、認証した状態でのウェブページ上の何らかのチェックを実行できます。cookie 1 トークンを使用して、前の手順で取得した cookie の永続性を維持します。 それらがなければ、セッションを再現することはできません。

2つ目のステップでは、ユーザーの詳細ページにアクセスし電話番号を探します。ユーザ “admin” のデフォルトは、555-555-555 です。 コンソールに正しくログインできているかどうかがわかります。

task_begin
get http://192.168.70.116/pandora_console/index.php?sec=workspace&sec2=operation/users/user_edit
cookie 1
resource 1
check_string 555-555-5555
task_end

最後にコンソールからログアウトし、ログアウトメッセージを探します。

task_begin
get http://192.168.70.116/pandora_console/index.php?bye=bye
cookie 1
resource 1
check_string Logged out
task_end

To check the server status code of a website, select the type of module Remote HTTP module to check server status code:

ウェブサイトのサーバステータスコードを確認するには、モジュールの種類を選択します Remote HTTP module to check server status code:

task_begin
head https://pandorafms.com
task_end
  • It is important to use the head parameter to obtain the status code.
  • In server configuration, in section web_engine curl must be typed in.
  • ステータス コードを取得するには、head パラメータを使用することが重要です。
  • サーバ設定のセクション web_enginecurl と入力する必要があります。

Some pages may require simple HTTP authentication. It is generally used as a quick check, a minimal security greeting that allows access to more advanced security checks (encryption, data persistence, etc.).

一部のページでは、シンプルなHTTP認証が必要となる場合があります。これは通常、より高度なセキュリティチェック(暗号化、データの永続化など)へのアクセスを可能にする、最低限のセキュリティチェックとして使用されます。

  • The use of quotation marks in the password for http_auth_pass is not supported.
  • Avoid using single quotation marks.
  • http_auth_pass に指定するパスワードではクォーテーションには対応していません。
  • シングルクォート ' の利用は避けてください。

Pandora FMS と Goliat webチェックにて、REST APIを監視することができます。ただし、SOAP や XML-RPC を用いた API は監視できません。

例えば、動作しているときに数値(0からn)で返すような特定の Web API を監視したい場合、次のようなコードで、Pandora は何も応答が無い場合に障害と認識します。

task_begin
get http://artica.es/integria/include/api.php?user=my_user&pass=my_pass&op=get_stats&ms=opened,,1
check_string \n[0-9]+
task_end

実際の応答は次の通りです。

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Mon, 13 May 2013 15:39:27 GMT
Pragma: no-cache
Server: Apache
Vary: Accept-Encoding
Content-Type: text/html
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Client-Date: Mon, 13 May 2013 15:39:27 GMT
Client-Peer: 64.90.57.215:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Set-Cookie: a81d4c5e530ad73e256b7729246d3d2c=pcasWqI6pZzT2x2AuWo602; path=/

0

正規表現で出力を確認することにより、全体が正しく動作しているかを確認できます。より複雑な出力の場合は、それに合わせた正規表現を用います。データ部分だけでなく、応答内容全体をチェックすることに注意してください。そのため、HTTP ヘッダーにもマッチさせることができます。

別の例:

 task_begin
 get https://swapi.dev/api/planets/1/
 get_content Tatooine
 task_end

この場合、モジュールが監視を実行できるようにするデータのタイプは、'Remote HTTP module to retrieve string data (web_content_string)' である必要があります。

 task_begin
 get https://pokeapi.co/api/v2/pokemon/ditto/
 get_content imposter
 task_end

上記のモジュールと同様に、モジュールが正しく機能するには、定義されたデータのタイプが Remote HTTP module to retrieve string data (web_content_string)' である必要があります。

get_content_advanced でモジュールを作成することもできます。

 task_begin
 get https://api.hillbillysoftware.com/Awards/ByYear/1990
 get_content_advanced "Nominee":"([A-Za-z]]+)","Year":"1990"
 task_end

この呼び出しは以下を返します。

Pandora FMS は、次のように結果を表示します。

  • It is important to correctly define the capture groups in parentheses so that the call is performed properly.
  • When making API calls, it is important to note that the target API must have permissions to be queried.
  • 呼び出しが適切に実行されるように、括弧内のキャプチャグループを正しく定義することが重要です。
  • API 呼び出しを行う場合、対象 API にクエリを実行するための権限が必要であることに注意することが重要です。

HTTP ヘッダーのカスタマイズ

header オプションで、HTTP ヘッダのカスタマイズしたり追加したりできます。たとえば、Host HTTP ヘッダーを変更するには次のようにします。

 task_begin
 get http://192.168.1.5/index.php
 header Host 192.168.1.1
 task_end

ウェブチェックのデバッグ

ウェブチェックをデバッグしたい場合は、debug <ログファイル> オプションを追加します。ログファイル.req および ログファイル.res というファイルが作成され、HTTP リクエストと応答が記録されます。たとえば次のようにします。

 task_begin
 get http://192.168.1.5/index.php
 debug /tmp/request.log
 task_end

LWP の代わりの Curl の利用

LWP は、複数スレッドで HTTPS リクエストを実行するとクラッシュすることがあります(OpenSSL の制約による)。代替としては curl ツール を利用することです。この問題を解決するためには、/etc/pandora/pandora_server.conf を編集し、次の行を加えます。

web_engine curl

Pandora FMS サーバを再起動すると、ウェブチェックに LWP の代わりに Curl バイナリが利用されます。

In addition to the feature offered by PFMS Web server, there is another way to perform transactional monitoring: the WEB User Experience Monitoring (WUX).

PFMS ウェブサーバが提供する機能に加えて、トランザクション監視を実行する別の方法があります: WEB ユーザエクスペリエンス監視 (WUX)

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

ウェブチェックは、プロキシ経由でも行うことができます。プロキシを設定するには、拡張オプション(Advanced options) をクリックすると表示される、プロキシURL(Proxy URL) フィールドにプロキシの URL を設定する必要があります。

例えば、URL は次のようになります。

http://proxy.domain.com:8080

認証が必要なプロキシの場合は、次のように my-user にユーザ名、my_pwd にパスワードを指定します。

http://my_user:my_pwd@proxy.domain.com:8080

Sometimes monitoring does not consist of finding out whether a specific Web site is working or how long it takes, but to get a real time value, such as the total number of modules registered in the same PFMS server through the API. For this example a module called Remote HTTP module to retrieve numeric data will be used with the appropriate regular expression:

特定の Web サイトが稼動しているか、どれくらい時間がかかっているかを知りたいわけではなく、API を通してPandora FMS サーバに登録されたモジュール数などのコンテンツの内容を確認したい場合もあります。そのためには、適切な正規表現で Remote HTTP module to retrieve numeric data モジュールを利用します。

task_begin
get http://127.0.0.1/pandora_console/include/api.php?apipass=1234&user=internal_API&pass=1234&op=get&op2=total_modules&id=0
get_content \d+
task_end

出力は次のようになります。

It is also possible to specify a more complex regular expression for collecting data from more complex HTTP responses with the get_content_advanced configuration token. In this didactic example, the year is obtained in the footer of Pandora FMS official documentation (and stored in a string data type, Remote HTTP module to retrieve string data):

また、より複雑な HTTP 応答からのデータを収集するための正規表現を設定トークン get_content_advanced で指定することもできます。この実践的な例では、Pandora FMS 公式ドキュメントのフッターから年を取得します(また、文字列データタイプ Remote HTTP module to retrieve string data で保存します:

task_begin
get https://pandorafms.com/manual/
get_content_advanced \(c\) ([\d]+) Pandora FMS\(tm\) </span>
task_end

Note that the inverse interval has been used: if a string other than 2022 is received, the module will go into critical.

しきい値の反転が使用されていることに注意してください。2022 以外の文字列を受信すると、モジュールは障害状態になります。

  • The part of the regular expression defined in get_content_advanced must be enclosed in brackets.
  • If the text to be looked for contains parentheses, you must escape the characters by means of the backslash \.
  • get_content_advanced に定義する正規表現は、カッコでくくらなければいけません。
  • 検索するテキストにカッコが含まれている場合は、バックスラッシュ \ を使用して文字をエスケープする必要があります。

To configure the thresholds that will trigger warning or critical status, use the module configuration to verify that the received string matches what is expected.

警告または障害状態のしきい値を設定するには、モジュールの設定を使用して、受信した文字列が期待どおりのものであることを確認します。

拡張プロパティのフィールドは他のタイプのモジュールのフィールドと似ていますが、WEB チェックではいくつかの異なるフィールドがあります。

タイムアウト(Timeout)

これはリクエストのタイムアウトです。この時間を超えるとリクエストは破棄されます。

エージェントブラウザID(Agent browser id)

これは、特定のページが一部の Web ブラウザのみを受け入れる場合に使用する Web ブラウザの識別子です。(詳細は、https://www.zytrax.com/tech/web/browser_ids.htm を参照してください)

リクエスト(Requests)

Pandora FMS は、このパラメータで示された回数だけチェックを繰り返します。 チェックの 1つが失敗した場合、障害とみなされます。モジュール内のチェックの数に応じて、一定数のページが取得されます。 つまり、モジュールが 3つのチェックで構成されている場合は、3ページがダウンロードされ、リクエストフィールドに値が設定されている場合は、ダウンロード数はその数を掛け合わせた数になります。 モジュールが処理を完了するのにかかる合計時間を把握するには、これを覚えておくことが重要です。

リトライ(Retries)

成功するまで リクエスト(Request) を実行する数です。例:

  • リトライ = 2、リクエスト = 1: 最初のテストに失敗すると、もう一度実行し、2回目で成功すると、正常と判断します。
  • リトライ = 1、リクエスト = 2: 2回のチェックを実行します。しかし一方の失敗で、障害と判断します。

Goliat は HTTP と HTTPS の両方をチェックできます。 HTTPS を利用しているセキュリティで保護されたウェブサイトのチェックを行うには、その URL にプロトコルを組み込むだけです。

task_begin
get https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=zpwhtygjntrz&ss=1&scc=1&ltmpl=default&ltmplcache=2
cookie 1
resource 0
check_string Google
task_end
  • ja/documentation/pandorafms/monitoring/06_web_monitoring.1776479594.txt.gz
  • 最終更新: 2026/04/18 02:33
  • by junichi