Zabbix 3.2以降の新機能解説（Zabbix 4.0を見据えて）その14 - 監視設定画面の「Check now」ボタン

こんにちは、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 情報を更新します。
キューのリスケジュールをした後は、これ以上他のプロセスと連携する必要がないためです。

注意事項

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