BLOG

2017 年 10 月 20 日

Zabbix 3.2以降の新機能解説（Zabbix 4.0を見据えて）その5 - Alert Managerのキュー管理

こんにちは、MIRACLE ZBX サポートを担当している花島タケシです。「Zabbix 3.2 以降の新機能解説（4.0 を見据えて）その 3」では、Alerter プロセスが複数起動できることを解説しました。今回は、Alert Manager がどのようにキュー管理をしているかを解説します。

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

前回「Zabbix 3.2 以降の新機能解説（4.0 を見据えて）その 3」では、Alerter プロセスが複数起動できることを解説しました。
Alert Manager プロセスがキュー管理をし、アラート配信処理を Alerter プロセスへ、UNIX ソケットを用いた通信で依頼をするという方法です。( 以下、Alert Manager, Alerter と記述します。)

今回は、Alert Manager がどのようにキュー管理をしているかを解説します。
ソースコードの解説は、src/zabbix_server/alerter/alert_manager.c にほぼ終始しています。

なお、解説に用いるコードは Zabbix 3.4.0 beta2 となります。

Alert Manager 管理領域の構成

基点となる管理領域は、zbx_am_t 構造体 ( 内部変数としては、manager が用いられます。) となり、am_init() で初期化されます。

処理を進めていくと、mediatype, alertpool, alert といった内部データが、manager にぶら下がる構成になり、Alert Manager は manager から全ての情報を辿っていくことになります。

前記の 3 つはそれぞれ、zbx_am_mediatype_t 構造体、zbx_am_alertpool_t 構造体、zbx_am_alert_t 構造体により管理されます。

メディアタイプは、ほぼ Web フロントエンドでの管理 -> メディアタイプに設定した情報となります。media_type テーブルから情報を取得します。

アラートは、Escalator プロセス等により生成されたデータです。alerts テーブルからの情報となります。
アラートプールだけはちょっと異なります。

これは内部的に持っているデータであり、対応するテーブル等はありません。これのユニーク性は、

イベントを生成したソース
イベントが由来するオブジェクト
イベントが由来するオブジェクト ID

により担保されます。後でも述べますが、これにより由来が同じであるアラートのグループ化を行っています。

また、事前に説明を加えておくと、zbx_am_t, zbz_am_mediatype_t, zbx_am_alertpool_t のそれぞれには、queue というメンバーが存在します。

これらは、それぞれ下位の情報をキューとしてを保持するためのものとなります。

DB からアラート情報を読み込む

以下のソースコード解説は、白紙の状態、つまりまだ何もアラートが発生していない状態を想定しています。これはソースコードの読解を容易にするためです。

ソースコードを読むにあたり、実際の動作を想定し、クリーンな状態から登録があり、処理が進み、二度目以降のループ処理と想定することは、単に上から読むよりも動きを理解できると思います。

最初に am_db_queue_alerts() をコールし、manager ツリーを構成する処理を行います。

構造体関連図 1

ソース解説を行おうとしましたが煩雑であるため、生成されるデータ構造の図を示しました。

am_db_queue_alerts() からは、am_db_get_alerts() がコールされ、アラート情報 ( 配列 ) が構築されます。このときに、alert が所属する alertpool のための alertpoolid が、下記の 3 つを用いて生成されます。

これにより、同じ属性を持つ alert が同一の alertpool に所属することを保証します。

イベントを生成したソース
イベントが由来するオブジェクト
イベントが由来するオブジェクト ID

次に、取得したアラート情報 ( 配列 ) が保持している mediatypeid を用いて、DB からメディアタイプの情報を取得し、am_db_update_mediatypes() によりメディアタイプ情報 ( 配列 ) が構築されます。

新規に読み取ったメディアタイプに対しては、location メンバーの値は NOWHERE( 無所属 ) となります。また、manager 構造体の mediatypes に付与されます。

メディアタイプ情報は manager に関連付けられていますが、アラート情報はまだどこにも関連付けられていません。

1237 static int am_db_queue_alerts(zbx_am_t *manager, int now)
1238 {
...
1253 if (FAIL == (ret = am_db_get_alerts(&alerts, now)))
1254 goto out;
1255
1256 /* update media types for new and queued alerts */
1257
1258 zbx_vector_uint64_create(&mediatypeids);
1259
1260 for (i = 0; i < alerts.values_num; i++)
1261 {
1262 alert = (zbx_am_alert_t *)alerts.values[i];
1263 zbx_vector_uint64_append(&mediatypeids, alert->mediatypeid);
1264 }
1265
1266 zbx_hashset_iter_reset(&manager->mediatypes, &iter);
1267 while (NULL != (mediatype = (zbx_am_mediatype_t *)zbx_hashset_iter_next(&iter)))
1268 zbx_vector_uint64_append(&mediatypeids, mediatype->mediatypeid);
1269
1270 if (0 != mediatypeids.values_num)
1271 {
1272 zbx_vector_uint64_sort(&mediatypeids, ZBX_DEFAULT_UINT64_COMPARE_FUNC);
1273 zbx_vector_uint64_uniq(&mediatypeids, ZBX_DEFAULT_UINT64_COMPARE_FUNC);
1274
1275 ret = am_db_update_mediatypes(manager, mediatypeids.values, mediatypeids.values_num);
1276 }
1277
1278 zbx_vector_uint64_destroy(&mediatypeids);

構造体関連図 2

そして、am_db_queue_alert() に戻り、alert が所属する alertpool を am_get_alertpool() により決定します。該当する alertpoold が存在しない場合には新規に作成され、manager 構造体の alertpools メンバーに付与されます。

alertpool 構造体の location メンバーは同様に NOWHERE となります。

構造体関連図 3

最後に、alert と alertpool, alertpool と mediatype, mediatype と manager の紐付けをそれぞれ、am_push_alert(), am_push_alertpool(), am_push_mediatype() を用いて行います。

am_push_alert(), am_push_alertpool() により、alertpool の queue に alert 情報が、mediatype の queue に alertpool 情報が付与されます。
さらに、alertpool->location は QUEUE となり、キューに入れられたことになります。

しかしながら、am_push_mediatype() では、許容数以下である場合でした、manager の queue に付与されません。

402 static void am_push_mediatype(zbx_am_t *manager, zbx_am_mediatype_t *mediatype)
403 {
404 zbx_binary_heap_elem_t elem = {mediatype->mediatypeid, mediatype};
405
406 if (SUCCEED == zbx_binary_heap_empty(&mediatype->queue))
407 return;
408
409 if (ZBX_AM_LOCATION_NOWHERE == mediatype->location)
410 {
411 if (0 == mediatype->maxsessions || mediatype->alerts_num < mediatype->maxsessions)
412 {
413 zbx_binary_heap_insert(&manager->queue, &elem);
414 mediatype->location = ZBX_AM_LOCATION_QUEUE;
415 }
416 }
417 else
418 zbx_binary_heap_update_direct(&manager->queue, &elem);
419 }

構造体関連図 4

このコードを見ると、ここまで新規登録の処理において alerts_num の加算を行っていません。それにもかかわらず無条件でコールされています。

ということは、制限を超えてしまう気がしてならないのですが ...

配信処理

キューに入れられたアラートを実際に配信する処理を追っていきます。

Alert Manager のループ処理において、am_check_queue() でキューのチェックが行われた後に、am_process_alert() がコールされ配信処理が行われます。

1956 while (SUCCEED == am_check_queue(&manager, now))
1957 {
1958 if (NULL == (alerter = zbx_queue_ptr_pop(&manager.free_alerters)))
1959 break;
1960
1961 if (FAIL == am_process_alert(&manager, alerter, am_pop_alert(&manager)))
1962 zbx_queue_ptr_push(&manager.free_alerters, alerter);
1963 }

am_check_queue() では、manager->queue から直近に処理すべき情報 (mediatype) を取り出します。( と言っても、maanger->queue に入れられる時点でソートはされています。)

さらに、mediatype->queue から alertpool を取り出し、alertpool->queue から処理すべき alert を取り出します。

am_process_alert() をコールするときに、am_pop_alert() を用いて alert を取得しています。am_check_queue() でチェックを行っているため、ここで取得しておけば良いとも思いますが ...

701 static zbx_am_alert_t *am_pop_alert(zbx_am_t *manager)
702 {
703 zbx_am_mediatype_t *mediatype;
704 zbx_am_alertpool_t *alertpool;
705 zbx_am_alert_t *alert;
706 zbx_binary_heap_elem_t *elem;
707
708 if (NULL == (mediatype = am_pop_mediatype(manager)))
709 return NULL;
710
711 alertpool = am_pop_alertpool(mediatype);
712
713 elem = zbx_binary_heap_find_min(&alertpool->queue);
714 alert = (zbx_am_alert_t *)elem->data;
715 zbx_binary_heap_remove_min(&alertpool->queue);
716
717 /* requeue media type if the number of parallel alerts has not yet reached */
718 mediatype->alerts_num++;
719 alertpool->alerts_num++;
720 if (0 == mediatype->maxsessions || mediatype->alerts_num < mediatype->maxsessions)
721 am_push_mediatype(manager, mediatype);
722
723 return alert;
724 }

manager から、mediatype, alertpool と辿って alert を取得します。最後にキューの許容数をチェックして、am_push_mediatype() をコールして、関連する mediatype に関する alert をキューに追加しています。ここでは、許容数のチェックが行われており、正しく動作していると思います。

am_process_alert() に関しては、前回解説を行ったので省略します。

アラートの破棄

最後に、アラートを割り振った Alerter プロセスから結果を取得し、アラートの破棄、リトライを行います。
正常終了やリトライ回数上限に達した場合は、am_remove_alert() により alert の破棄が行われます。

736 static void am_remove_alert(zbx_am_t *manager, zbx_am_alert_t *alert)
737 {
738 zbx_am_alertpool_t *alertpool;
739 zbx_am_mediatype_t *mediatype;
740
741 if (NULL != (mediatype = am_get_mediatype(manager, alert->mediatypeid)))
742 {
743 mediatype->alerts_num--;
744
745 if (NULL != (alertpool = am_get_alertpool(manager, alert->mediatypeid, alert->alertpoolid)))
746 {
747 alertpool->alerts_num--;
748 if (SUCCEED != am_release_alertpool(manager, alertpool))
749 am_push_alertpool(mediatype, alertpool);
750 }
751
752 if (SUCCEED != am_release_mediatype(manager, mediatype))
753 am_push_mediatype(manager, mediatype);
754 }
755
756 am_alert_free(alert);
757 }

ここで許容数チェック用の変数の減算が行われます。

同様に、am_retry_alert() ではリトライ処理が行われ、alert が再度キューに配置され、各カウントの計算が行われます。

まとめ

以上で、従来の Alerter 処理の並列化について解説を完了しました。

少し難しかったと思いますが、Alert Manager と Alerter に分離され、これらは UNIX ソケットにより IPC 通信が行われます。
Alert Manager は DB からデータを取得し、( 一応 ) 許容数内での並列処理を実現しています。

ただし、少し危うい箇所もあるとは思いますが。

注意事項

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