現在位置: ホーム / 製品・サービス / 統合システム監視 MIRACLE ZBX / MIRACLE ZBX - Zabbix テック・ラウンジ / Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その14

Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その14

こんにちは、MIRACLE ZBXサポートを担当している花島タケシです。 アイテムの監視設定画面に「Check now」ボタンが追加されましたので、今回はそのボタンの解説をします。

「Check now」ボタンがつきました

アイテムの監視設定画面に「Check now」ボタンが追加されました。

すぐにお試し監視が行えます。

「Check now」ボタンが追加されました。

このボタンは、アイテムの全体表示の画面と個別設定の両方のページに追加されています。

このボタンを押すと、アイテムの監視がスケジュールとは関係なく即座に行われます。

Zabbix サーバープロセスがそのアイテム設定を読み込んでいなくてはいけないという制約がありますが、監視に失敗したアイテムや監視間隔が長いアイテムの監視が正しく行えるか?という確認のために使用できます。

また、対象となる監視タイプはパッシブ監視のアイテムとなります。

以下でどのように実装されているかを確認していきます。

「Check now」ボタンを押すと…

task, task_check_now テーブルへデータが挿入されます。

といきなり書いてしまいましたが、この機能のために新たに task_check_now テーブルが追加されました…

Task Manager を利用した機能が追加される度にテーブルが増えています。もう少し考えて拡張した方が良いとは思うのですが。

ちなみに、現在追加されている Task manager 関連のテーブルは以下の通りです。

  • task_acknowledge
  • task_check_now
  • task_close_problem
  • task_remote_command, task_remote_command_result

 

どのテーブルがどの機能に該当するかは過去のドキュメントを参照してください。

 Zabbix サーバー側の動作

Task Manager 登場以来、多くの機能がこれに付与されてきて、説明も過剰になってきているため、この辺りの動作については簡単に行います。

「Check now」に関する処理は、tm_process_tasks() の以下の部分です。 

561       case ZBX_TM_TASK_CHECK_NOW:
562         if (0 != ttl && clock + ttl < now)
563           zbx_vector_uint64_append(&expire_taskids, taskid);
564         else
565           zbx_vector_uint64_append(&check_now_taskids, taskid);
566         break;

ttl 変数については、3600という固定値をDBから読み取って代入されています。

これは、「Check now」ボタンを押したときに挿入された値となります。

Zabbix サーバーが動作していなくても、Web フロントエンド が動作している状態を考慮したものと考えられます。
ボタンを押してから1時間経過した要求は、即時に行う必要がないものとして切り捨てられます。(clock はボタンを押したときの時刻です。)

結果として、即時に処理を行うリストが check_now_taskids(配列) として生成されます。

次に、check_now_taskids の処理となります。 

578   if (0 < check_now_taskids.values_num)
579     processed_num += tm_process_check_now(&check_now_taskids);
580
581   if (0 < expire_taskids.values_num)
582     expired_num += tm_expire_generic_tasks(&expire_taskids);

tm_process_check_now()  では、task テーブルと tack_check_now テーブルから情報を取得した後に、zbx_dc_reschedule_items() にて、監視アイテムのスケジュールの変更を行います。

src/libs/zbxdbcache/dbconfig.c

11173 void  zbx_dc_reschedule_items(const zbx_vector_uint64_t *itemids, int nextcheck, zbx_uint64_t *proxy_hostids)
11174 {
...
11182   for (i = 0; i < itemids->values_num; i++)
11183   {
11184     if (NULL == (dc_item = (ZBX_DC_ITEM *)zbx_hashset_search(&config->items, &itemids->values[i])) ||
11185         NULL == (dc_host = (ZBX_DC_HOST *)zbx_hashset_search(&config->hosts, &dc_item->hostid)))
11186     {
11187       zabbix_log(LOG_LEVEL_WARNING, "cannot perform check now for itemid [" ZBX_FS_UI64 "]"
11188           ": item is not in cache", itemids->values[i]);
11189
11190       proxy_hostid = 0;
11191     }
11192     else if (0 == (proxy_hostid = dc_host->proxy_hostid))
11193       dc_requeue_item_at(dc_item, dc_host, nextcheck);

スケジュール変更要求を受けた監視について、最初にキャッシュに存在するかを確認しています。
キャッシュに存在しない場合はスケジュール変更対象としないことになります。

新規にアイテムを作成した直後やアイテムの設定の変更を行った直後には、設定が Zabbix サーバープロセスへ反映されていません。

zabbix_server.conf に設定された CacheUpdateFrequency パラメータ毎に Configuraion Syncer プロセスが設定を反映させます。

この値を大きく設定している場合などは、Runtime Control 機能を用いて設定を強制的に Zabbix サーバープロセスに読み込ませる必要があります。

キャッシュに存在する場合、dc_requeue_item_at() がコールされます。 

 7122 static void dc_requeue_item_at(ZBX_DC_ITEM *dc_item, ZBX_DC_HOST *dc_host, int nextcheck)
7123 {
7124   unsigned char old_poller_type;
7125   int old_nextcheck;
7126
7127   dc_item->queue_priority = ZBX_QUEUE_PRIORITY_HIGH;
7128
7129   old_nextcheck = dc_item->nextcheck;
7130   dc_item->nextcheck = nextcheck;
7131
7132   old_poller_type = dc_item->poller_type;
7133   DCitem_poller_type_update(dc_item, dc_host, ZBX_ITEM_COLLECTED);
7134
7135   DCupdate_item_queue(dc_item, old_poller_type, old_nextcheck);
7136 }

引数の nextchek には、zbx_dc_reschedule_items() をコールするときに time(NULL) の値が当てられているため、現在時刻が入っています。

したがって、Poller プロセスが遅延していない限り、キューの先頭の方に入ります。

ここで重要なことは、プライオリティに ZBX_QUEUE_PRIORITY_HIGH と設定していることです。

このプライオリティ(queue_priority 構造体メンバー)は、「Check now」ボタンのために導入されたものとなります。

DCitem_poller_type_update() にて、ZBX_ITEM_COLLECTED をフラグとして渡すことにより、監視プロセスを (Unreachable Pollerでない)正規のプロセスに強制しています。

そして、DCupdate_item_queue() をコールしてスケジュールの変更をしています。

上記のqueue_priorityですが、通常は ZBX_QUEUE_PRIORITY_NORMAL がセットされ、ネットワーク的な問題で監視が失敗した場合は、ZBX_QUEUE_PRIORITY_LOW がセットされます。

各監視用プロセスは、DCconfig_get_poller_items() にて監視アイテムを取得するときにこの queue_priority の値による判別を行います。
HIGH の場合は例え直前の監視に失敗し一定の時間監視対象外とされていようとも、判定の対象外となり、監視を優先されるようにコードが変更されています。

 7163 int DCconfig_get_poller_items(unsigned char poller_type, DC_ITEM *items)
7164 {
...
7233     /* don't apply unreachable item/host throttling for prioritized items */
7234     if (ZBX_QUEUE_PRIORITY_HIGH != dc_item->queue_priority)
7235     {
7236       if (0 == (disable_until = DCget_disable_until(dc_item, dc_host)))
7237       {
...
7246       else
7247       {
7248         /* move items on unreachable hosts to unreachable pollers or    */
7249         /* postpone checks on hosts that have been checked recently and */
7250         /* are still unreachable
...
7261     }
...

上記をまとめると、この機能により現在時刻を用いてキューのかなりの先頭の方に監視対象として割り当て、新しく導入されたプライオリティフラグを高く設定することになります。

そして、監視用の Poller プロセスが監視対象を取得するときに、監視対象となり易い状態にしています。

最後に、Task Manager はDB情報を更新します。
キューのリスケジュールをした後は、これ以上他のプロセスと連携する必要がないためです。

関連記事

注意事項

本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、当社はその損害についての責任を負いません。あくまでお客さまのご判断にてご使用ください。

 

MIRACLE ZBX 製品・サポートサービス 詳しくはこちら

MIRACLE ZBX Virtual Appliance V3.0 評価版のお申し込み

製品・サービスについてのお問い合わせ

お問い合わせフォームMIRACLE ZBX製品やサポートサービスについてのご相談やご質問は、「お問い合わせフォーム」よりお気軽にお問い合わせください。