採用情報

お問い合わせ

BLOG

Zabbix テック・ラウンジ

2017 年 08 月 07 日

Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その3 - Alerterプロセスの複数起動

こんにちは、MIRACLE ZBX サポートを担当している花島タケシです。 前回は Zabbix 3.0 で実装された Escalator プロセスの複数起動について解説しましたが、今回は Zabbix 3.4 で実装される Alerter プロセスの複数起動について解説します。

概要 - Alerter プロセスも複数起動できるようになります。

前回は ( 直接的ではありませんでしたが )、Alerter プロセスが処理を行う前の Escalator プロセスの並列化について解説を行いました。
今回は Alerter プロセスの並列化について解説を行います。

使用するソースコードは 3.4alpha1 です。

Alert Manager プロセスと Alerter プロセス

いきなり今まで見たこともない Alert Manager プロセスが出てきました。

Alerter プロセスの並列化は、大元の管理用のプロセスとなる Alert Manager プロセスと実際にアラート配信を行う Alerter プロセスに分離した実装となりました。

今までの Zabbix での各機能の並列化は、こういった主従関係がある実装をしてきませんでした。
Poller, DB Syncer, Escalator も全て主従関係のない協調型の実装となっています。
名前からも分かるように、主の立場になるプロセスが Alert Manager プロセスとなります。
そして、従の立場になるプロセスが Alerter プロセスで、こちらは複数起動させることができます。

また、Alert Manager - Alerter 間の通信は UNIX ソケットによるものとなっています。
これもちょっと変わった実装となっています。DB Syncer は別として、各機能間のデータの受け渡しは DB を介することが一般的でした。

こういった点で、Alerer プロセスの並列化方法は今までと変わっています。

Alert Manager プロセスと Alerter プロセスの役割

新しく追加された Alert Manager プロセスには以下の機能があります。

  1. Alerter プロセスへのアラート処理の割り振り
  2. DB を参照しアラートキューの管理
  3. 今までの Watchdog プロセスの代替

3. については特に言及することもないでしょう。

Alert Manager プロセスは起動後に IPC ソケットの初期化を行った後に、アラートキュー、Alerter プロセス管理用等のデータ領域 ( メモリ ) の初期化を行います。その後に、デーモンとしてのループ処理を行います。

下記がソースコードからの抜粋と適当な解説になります。

src/zabbix_server/alerter/alert_manager.c

1840 ZBX_THREAD_ENTRY(alert_manager_thread, args)
1841 {
...

/* IPC ソケット通信サービスの初期化 */
1863 if (FAIL == zbx_ipc_service_start(&alerter_service, ZBX_IPC_SERVICE_ALERTER, &error))
...

/* 管理領域の初期化 */
1870 am_init(&manager);
...

/* デーモンとしてのループ処理 */
1891 for (;;)
1892 {
...

/* アラート情報の DB とのシンク */
1929 if (ZBX_DB_OK == manager.dbstatus && now - time_db >= ZBX_AM_DB_POLL_DELAY)
1930 {
1931 if (SUCCEED == (ret = am_db_flush_alert_updates(&manager)))
...

/* Watchdog 処理 */
1929 if (ZBX_DB_OK == manager.dbstatus && now - time_db >= ZBX_AM_DB_POLL_DELAY)<br />
1930 {
1931 if (SUCCEED == (ret = am_db_flush_alert_updates(&manager)))
...

/* アラート処理の Alerter プロセスへの配信 */
1953 while (SUCCEED == am_check_queue(&manager, now))
1954 {
1955 if (NULL == (alerter = zbx_queue_ptr_pop(&manager.free_alerters)))
1956 break;
1957
1958 if (FAIL == am_process_alert(&manager, alerter, am_pop_alert(&manager)))
1959 zbx_queue_ptr_push(&manager.free_alerters, alerter);
1960 }
...

/* Alerter からのメッセージ受信 */
1963 ret = zbx_ipc_service_recv(&alerter_service, 1, &client, &message);
...

/* メッセージに対する処理 */
1969 if (NULL != message)
1970 {
1971 switch (message->code)
1972 {

/* Alerter プロセスの登録 */
1973 case ZBX_IPC_ALERTER_REGISTER:
1974 am_register_alerter(&manager, client, message);
1975 break;

/* アラート処理の結果の処理 */
1976 case ZBX_IPC_ALERTER_RESULT:
1977 if (SUCCEED == am_process_result(&manager, client, message))
1978 sent_num++;
1979 else
1980 failed_num++;
1981 break;
1982 }
1983
1984 zbx_ipc_message_free(message);
1985 }
...

1989 }

一方、実際にアラート処理を行う Alerter プロセスは、UNIX ソケットを作成後、Alert Manager プロセスへ自身の情報を送付し登録を行います。その後、ループ処理に入り、ソケットから Alert Manager プロセスからのメッセージを読み込み、それに応じたアラート処理を行います。

src/zabbix_server/alerter/alerter.c

276 ZBX_THREAD_ENTRY(alerter_thread, args)
277 {
...

/* IPC ソケットの作成 */
298 if (FAIL == zbx_ipc_socket_open(&alerter_socket, ZBX_IPC_SERVICE_ALERTER, 10, &error))
299 {
...

/* Alert Manager へ自身の情報を送付 */
305 alerter_register(&alerter_socket);
...

/* デーモンとしてのループ処理 */
317 for (;;)
318 {
...

/* Alert Manager からのメッセージを読み込む */
337 if (SUCCEED != zbx_ipc_socket_read(&alerter_socket, &message))
338 {
...

/* メッセージに応じたアラート処理 */
348 switch (message.code)
349 {
350 case ZBX_IPC_ALERTER_EMAIL:
351 alerter_process_email(&alerter_socket, &message);
352 break;
353 case ZBX_IPC_ALERTER_JABBER:
354 alerter_process_jabber(&alerter_socket, &message);
355 break;
356 case ZBX_IPC_ALERTER_SMS:
357 alerter_process_sms(&alerter_socket, &message);
358 break;
359 case ZBX_IPC_ALERTER_EZTEXTING:
360 alerter_process_eztexting(&alerter_socket, &message);
361 break;
362 case ZBX_IPC_ALERTER_EXEC:
363 alerter_process_exec(&alerter_socket, &message);
364 break;
365 }
...

368 }

3 つのパラメータ

Alerter プロセスの並列化に伴い、メディアタイプへ 3 つのパラメータが追加されました。

  1. 並列度 (Concurrent sessions)
  2. リトライ回数 (Attempts)
  3. リトライ間隔 (Retry intervals)

注目する点は、上記のパラメータは Alerter プロセスではなく、メディアタイプごとへ設定ができる点です。当然、Zabbix サーバへの設定で起動する Alerter プロセスを制御できます (StartAlerters パラメータ )。

ただし、メディアタイプごとの並列度を設定できることにより、特定のメディアタイプが処理を占有することを避けるようにできているようになっています。( ただし、実装にバグっぽいところもありますが ...)

次回は、この Alerter の並列処理の実装解説を行うか、プロセス間のデータの受け渡し方法をさらっと解説を行うかどちらかにしたいと思います。

関連記事

Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 1
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 2
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 3
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 4
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 5
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 6
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 7
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 8
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 9
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 10
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 11
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 12
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 13
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 14
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 15
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 16
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 17
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 18
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 19
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 20
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 21

CentOS 7 延長サポートサービス
デジタルトランスフォーメーションのための電子認証基盤 iTrust
SSL/TLS サーバー証明書 SureServer Prime