Zabbix / MIRACLE ZBX ServerのPollerプロセスの全体像解説

本記事では、Zabbix / MIRACLE ZBX Server の Poller プロセスの処理について解説を行います。特に Poller プロセスが行う一連の監視処理の流れについて解説を行います。

概要

本記事では、Zabbix Server の Poller プロセスの処理について解説を行います。特に Poller プロセスが行う一連の監視処理の流れについて解説を行います。なお、本調査に使用した環境は以下の通りです。

調査環境

MIRACLE ZBX / zabbix-3.0.10-1

Poller プロセスはパッシブ系のアイテムの監視処理を行うプロセスです。具体的には下記表のピンク色の行のタイプのアイテムの処理を行います。

アイテムのタイプ	処理を行うプロセス
Zabbix エージェント	Poller
Zabbix エージェント ( アクティブ )	Trapper
シンプルチェック	Poller (icmpping 類の監視は Pinger プロセス )
SNMPv1 エージェント	Poller
SNMPv2 エージェント	Poller
SNMPv3 エージェント	Poller
SNMP トラップ	SNMP Trapper
Zabbix インターナル	Poller
Zabbix トラッパー	Trapper
Zabbix アグリゲート	Poller
外部チェック	Poller
データベースモニター	Poller
IPMI エージェント	IPMI Poller
SSH エージェント	Poller
TELNET エージェント	Poller
JMX エージェント	Java Poller
計算	Poller

Poller 系のプロセスには、Poller, IPMI Poller, Java Poller, Unreachable Poller があります。

これらのプロセスのソースコードは共通です。起動時に渡すパラメータにより、各種類のプロセス群を起動しています。

大体の処理は Poller と同じですが、割り当てられるアイテムのタイプや一度に処理するアイテムの数等が異なります。また、種類毎に使用する監視キューも異なります。

IPMI Poller, Java Poller プロセスはそれぞれ IPMI エージェント、JMX エージェントタイプのアイテムを処理します。Unreachable Poller は Poller プロセスの監視処理においてタイムアウトやネットワークのエラーとなったアイテムを処理するためのプロセスです。

解説

Poller プロセスは、Zabbix Server の main() からフォークして起動されます。
zabbix_server.conf の StartPollers に指定した数だけプロセスが起動されます。

Poller プロセス（zbx-tl-015-poller 用）

該当するソースコードは下記となります。説明のため、主要な処理だけを記載しています。

src/zabbix_server/poller/poller.c

ZBX_THREAD_ENTRY(poller_thread, args)
    {
    for (;;)
    {
    ...
    processed += get_values(poller_type, &nextcheck);
    sleeptime = calculate_sleeptime(nextcheck, POLLER_DELAY);
    ...
    zbx_sleep_loop(sleeptime);
    }
    }

Poller プロセスはアイテムの値を取得する等の処理を行う get_values() をコールした後に算出した時間だけスリープすることを繰り返します。

次に Poller プロセス処理の本体となる get_values() の処理を見ていきます。

get_values() の処理

該当するソースコードは下記となります。主要な処理だけを抜き出しています。

src/zabbix_server/poller/poller.c

static int get_values(unsigned char poller_type, int *nextcheck)
    {
    ...
    num = DCconfig_get_poller_items(poller_type, items);/*1*/
    for (i = 0; i < num; i++)
    {
    ...
  errcodes[0] = get_value(&items[0], &results[0], &add_results);/*2*/
  dc_add_history(items[i].itemid, items[i].value_type, items[i].flags, &results[i],
  　　　　　　　　　　　　　　　　　&timespec, items[i].state, NULL);/*3*/
 ...
  DCpoller_requeue_items(&items[i].itemid, &items[i].state, &timespec.sec, plastlogsize, NULL,
  　　　　　　　　　　　　　　　　　　　&errcodes[i], 1, poller_type, nextcheck);/*4*/
    }
    }

処理の流れは下記となります。

監視キューからアイテムの設定を取得する
アイテムの監視データを取得する
取得したアイテムの監視データをヒストリキャッシュに書き出す
監視処理が終わったアイテムを監視キューに戻す

それぞれの処理について解説を行います。

1. 監視キューからアイテムの設定を取得する

監視を行うアイテムが Configration キャッシュ上にある監視キューに、監視を行う時刻の順番で格納されています。

Poller プロセスはこのキューから 1 つづつアイテムを取得してその監視処理を行います。ただし、SNMP エージェントタイプのアイテムの監視ではそのインターフェイスの「bulk リクエストを使用」にチェックが入っている場合、1 つ以上のアイテムをまとめて取得して処理します。

2.＆ 3. アイテムの監視処理を行う

取得したアイテムの監視を行う時刻が現在の時刻を過ぎていた場合は、その監視処理を行います。監視処理では、監視対象のホストからデータを取得し、取得したデータをヒストリキャッシュに書き出します。ネットワーク的な問題やタイムアウト等でこの処理が失敗したアイテムは Unreachable Poller の監視キューに回されて、通常とは異なる監視間隔で監視処理が行われます。

※本記事ではこの処理について詳細には触れません。機会があれば別の記事で解説をします。

4. 監視処理が終わったアイテムを監視キューに戻す

監視が行われたアイテムは、次回監視を行う時刻が算出され、監視キューに監視時刻の順番に戻されます。

アイテムの次回の監視時刻は下記のように算出されます。これは、同じ時刻に処理が重ならないようにするための仕組みです。

監視時刻 := 基準時刻 + オフセット時間
基準時刻 : 現在の時刻 (UNIX タイム ) を監視間隔で割れる時刻
オフセット時間 := アイテムの ID(itemid)( 注 1) の監視間隔による剰余

※例外の更新間隔の設定されている場合はその設定値を反映した監視間隔となります。
※エラーなく監視処理が行われた場合を想定しています。
※( 注 1)SNMPv* エージェントタイプのアイテムであり、そのインターフェイスの「bulk リクエストを使用」にチェックが入っている場合は、その interfaceid となります。

例えば、監視間隔が 15 秒であり itemid が 160 であるアイテムは下記の時刻に監視を行うようになります。

基準時刻 := UNIX タイムが 15 で割れる時刻
オフセット時間 := 160 の 15 による剰余 (=10)

現在の時刻が "2017-8-17 19:03:16" である場合、基準時刻が "2017-8-17 19:03:15" となり、"2017-8-17 19:03:25" が次回の監視時刻となります。

最後に、監視が終了したアイテムをキューから削除し、新たに先頭になったアイテムの次回の監視時刻を取得します。この時刻から現在の時刻を引き、その値の分だけプロセスがスリープすることになります。ただし、その値が負である場合、プロセスがスリープする時間は 0 となります。( スリープしません )。また、値が 5 よりも大きい場合は、5 秒スリープすることになります。