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

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

前回は 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)
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の並列処理の実装解説を行うか、プロセス間のデータの受け渡し方法をさらっと解説を行うかどちらかにしたいと思います。

関連記事

 

注意事項

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

 

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

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

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

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