ウェブ監視

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

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

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

network_threads 4
web_timeout 60

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

/etc/pandora/pandora_server.conf

# Uncomment to perform web checks with LWP instead of CURL.
#web_engine lwp

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

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

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ヘッダーを返すことができます。

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

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

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

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

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

• ボタン チェック(Check)

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

• ボタン デバッグ(Debug)

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

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

-w '%{http_code}'

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

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

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

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

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

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

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

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

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

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

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

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

以下の 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

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

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

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

• チェックタイプ(Check type) フィールドで BASIC を選択します。
• HTTP認証（ログイン）(HTTP auth (login)) フィールドには、任意のユーザ名を入力します。
• HTTP認証（パスワード）(HTTP auth (password)) フィールドには、Pandor4! を入力します。
• モジュールを保存し、チェックを強制実行します。

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

同様に、テスト用の 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

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

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>

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

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

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

variable_name name
variable_value Kevin

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

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

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

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

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

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

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

task_begin
head https:/example.com/
task_end

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

• 最も一般的なケースは、ユーザ認証プロセスや、1つ以上の入力項目を含むアンケートへの回答など、フォームチェックです。
• 別のケースとしては、特定の Web ページを照会し、その応答に基づいて次の照会を実行するケースが挙げられます。このシナリオでは、最初のコードブロックと 2番目のコードブロックの両方の結果が成功して初めて、完全なチェックが成功と判断され、モジュールのしきい値との比較を経て、ステータスを変更するかどうかが決定されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API タイプのクエリ から数値を取得するには、次のコードを使用できます。
get_content \d+ コードブロック内 task_begin … task_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

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

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

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

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

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

1. -H 'Pragma: no-cache': CDN キャッシュをスキップするために使用します。Pragma は HTTP 1.0 と互換性があります（現在最もよく使用されている HTTP バージョンは 1.1 と 2.0 です）。
2. -H 'Accept: text/html': HTML コードを最初のレスポンスとして要求することを示します。

task_begin…task_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

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

• 言語ヘッダ 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 を囲んでいることに注意してください)。

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

• ウェブブラウザ識別子
• cookie

ウェブチェックは、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

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

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

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

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

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

task_begin
get https://pandorafms.com
task_end

• チェック定義でトランザクションが複数回実行される場合（getコマンド）、各リクエストの平均時間が使用されます。
• 警告状態と障害状態のしきい値はユーザが設定する必要があります。
• ダウンロード時間にすべてのリソース（JavaScript、CSS、画像など）を含めるには、resource 1をtask_endの前の行に追加する必要があります。
• ウェブチェックはプロキシサーバの使用もサポートしています。そのためには、必要なProxyという名前のフィールドを入力する必要があります。
• debug パラメータは、各チェックのクエリとレスポンスの両方の累積レコードを 2つのファイルに保持するために使用されます。

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

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

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

task_begin
get <URL>
task_end

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

task_begin
get <URL>
check_string <text>
task_end

• 要求されたテキスト文字列が存在する場合は、通常ステータスに移行し、存在しない場合はクリティカルステータスに移行します。
• 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

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

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

• 警告状態と障害状態のしきい値はユーザが設定する必要があります。 デフォルトではこれらのしきい値はゼロなので、有効な数値チェックはすべて正常状態として分類されます。
• プロキシサーバ は、必要な 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 パラメーターを参照してください。

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

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

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

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

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

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

task_begin
head https://pandorafms.com
task_end

• サーバ設定では、Curl を使用する必要があります。
• ステータスコードを取得するには、head パラメータを使用することが重要です。
• 障害しきい値を設定するには、HTTP/X 200 OK（Xはプロトコルバージョン）を指定し、条件の反転を指定します。

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

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

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