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

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

Zabbix 3.4で追加された機能として、Alerterプロセスが複数起動できるようになります。 本ドキュメントでは、Zabbix 3.0において、その前段階であるEscalatorプロセスが既に複数起動するように修正されていますので、この点について解説を行います。

概要

Zabbix 3.4で新しく追加された機能として、Alerterプロセスも複数起動できるようになります。

Zabbix 3.0では、その前段階であるEscalatorプロセスが既に複数起動するように修正されています。
今回はEscalatorプロセスが複数起動できるようになった点について解説を行います。 

なぜEscalatorプロセスが複数起動できるようになった(した)のか?

 Zabbixで監視を行っていて問題となることに、監視対象のログに一時的に大量の出力されることがあります。これが発生した場合、Zabbixエージェントは、そのログを読み込み送信を行いますが、大変な負荷がかかることにあります。

同様に、Zabbixサーバも負荷も大変なことになります。Zabbixサーバ側の処理としては、Trapperプロセスがデータを受け取り、キャッシュへ保存します。

DB SyncerプロセスがキャッシュからDBへの書き出しを行い、その過程においてトリガー評価等も行います。Trapper, DB Syncerは既に複数起動できるようになっており、並列化を行うことができます。

 

Escalatorプロセスは何をしている?

Escalatorプロセスは、escalationsテーブルに書き込まれたデータを検知し、それぞれにデータに対してメッセージを整形した後に、alertsテーブルへアラート送信のためのデータを加えることになります。

この「データ」は、「実行内容のタイプ」が「メッセージの送信」であろうと、「リモートコマンド」であろうと変わらず(当然データの中身は変わりますが)、Escalatorプロセス自体がアラートメールの送信やコマンド実行をすることはありません。

各プロセスの連携については次回で説明します。

並列化された実装を見ていこう!

 並列化については下記にて行われています。

https://support.zabbix.com/browse/ZBXNEXT-2844

並列度を指定するStartEscalatorsパラメータがzabbix_server.confに追加されています。
また、Escalatorプロセスに関するソースコードは、src/zabbix_server/escalator/escalator.cとなります。

この機能追加で主だった修正は以下の通りです。

@@ -1426,10 +1432,44 @@
 	zbx_vector_uint64_create(&escalationids);
 	sql = zbx_malloc(sql, sql_alloc);
 
+	switch (escalation_source)
+	{
+		case ZBX_ESCALATION_SOURCE_TRIGGER:
+			zbx_strcpy_alloc(&filter, &filter_alloc, &filter_offset, "triggerid is not null");
+			if (1 < CONFIG_ESCALATOR_FORKS)
+			{
+				zbx_snprintf_alloc(&filter, &filter_alloc, &filter_offset,
+						" and " ZBX_SQL_MOD(triggerid, %d) "=%d",
+						CONFIG_ESCALATOR_FORKS, process_num - 1);
+			}
+			break;
+		case ZBX_ESCALATION_SOURCE_ITEM:
+			zbx_strcpy_alloc(&filter, &filter_alloc, &filter_offset, "itemid is not null");
+			if (1 < CONFIG_ESCALATOR_FORKS)
+			{
+				zbx_snprintf_alloc(&filter, &filter_alloc, &filter_offset,
+						" and " ZBX_SQL_MOD(itemid, %d) "=%d",
+						CONFIG_ESCALATOR_FORKS, process_num - 1);
+			}
+			break;
+		case ZBX_ESCALATION_SOURCE_DEFAULT:
+			zbx_strcpy_alloc(&filter, &filter_alloc, &filter_offset,
+					"triggerid is null and itemid is null");
+			if (1 < CONFIG_ESCALATOR_FORKS)
+			{
+				zbx_snprintf_alloc(&filter, &filter_alloc, &filter_offset,
+						" and " ZBX_SQL_MOD(escalationid, %d) "=%d",
+						CONFIG_ESCALATOR_FORKS, process_num - 1);
+			}
+			break;
+	}
+
 	result = DBselect(
 			"select escalationid,actionid,triggerid,eventid,r_eventid,nextcheck,esc_step,status,itemid"
 			" from escalations"
-			" order by actionid,triggerid,itemid,escalationid");
+			" where %s"
+			" order by actionid,triggerid,itemid,escalationid",
+			filter);
 
 	*nextcheck = now + CONFIG_ESCALATOR_FREQUENCY;
 	memset(&escalation, 0, sizeof(escalation));
@@ -1648,12 +1689,16 @@
...
 
 		sec = zbx_time();
-		escalations_count += process_escalations(time(NULL), &nextcheck);
+		escalations_count += process_escalations(time(NULL), &nextcheck, ZBX_ESCALATION_SOURCE_TRIGGER);
+		escalations_count += process_escalations(time(NULL), &nextcheck, ZBX_ESCALATION_SOURCE_ITEM);
+		escalations_count += process_escalations(time(NULL), &nextcheck, ZBX_ESCALATION_SOURCE_DEFAULT);
+
 		total_sec += zbx_time() - sec;
 
 		sleeptime = calculate_sleeptime(nextcheck, CONFIG_ESCALATOR_FREQUENCY);

 

二番目の修正は、Escalatorプロセスのメインの関数内のループ内に記述されています。
(こういったデーモンでは、無限ループが存在し処理を繰り返す実装になっています。)

今まではシングルプロセスで処理していたためprocess_escalations()を対象を明確にせずにコールしていましたが、マルチプロセス対応にするために対象を、トリガー、アイテム、その他と明確にしてコールするように変更されていることがわかります。

一番目の修正が、上述のprocess_escalations()への修正となります。マルチプロセス対応となったにも関わらず、変更が大変少ないことが分かります。実際は関数定義も変更されていますが、そこは割愛します。

呼び出元で対象を明示していましたが、ここではその対象ごとの処理が加わっています。

処理対象となるデータをescalationsテーブルから抽出するのですが、対象ごとに条件を加えています。特にEscalatorプロセスの数を複数にした場合、

mod(triggerid, Escalatorプロセスの総数)=(Escalatorプロセスの番号-1)

というような条件を付与しています。(Escalatorプロセスの番号は1から始まります。)

 

この剰余を用いた割り振りにより、簡素に処理の並列化を実現しています。

escalatorsテーブルに先に挿入されたデータを優先的に処理を行うといった機構の場合、一回に処理を行う最大量、escalatorsテーブルへ新しいカラムの追加、ロックの新設といった設計の追加が必要となりますが、必要なくなっています。

ただし、同じtriggeridからのエスカレーションが急激に増えた場合、若しくは特定のtriggeridからのエスカレーション頻度が高い場合にバランシングが行えません。

上述のことと矛盾しますが、監視対象のログに急激に出力がされた場合(さらに、こういった場合、同じ出力が継続します。)、その出力に関するトリガーは同一のものです。

しかしながら、以前のようにシングルプロセスである場合、他のアラートが全く処理されなくなるのでましとは言えますが。

以上、今回はEscalatorプロセスの並列化を説明しました。

次回はAlerterプロセスについて解説を行う予定です。

関連記事

 

注意事項

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

 

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

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

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

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