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

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

こんにちは、MIRACLE ZBXサポートを担当している花島タケシです。 今回はZabbixおよびMIRACLE ZBXのTask Managerプロセスを利用した新たなサービス障害対応済みの通知について解説します。

Task Managerプロセスを利用した新たなサービス(障害対応の通知)

前回の予告どおり、今回はZabbixおよびMIRACLE ZBXのTask Managerプロセスを利用した新たなサービス障害対応済みの通知 についての解説を行います。

障害対応の通知とは?

詳しくは下記を参照してください。

参考

https://www.zabbix.com/documentation/3.4/manual/config/notifications/action/acknowledgement_operations

https://www.zabbix.com/documentation/3.4/manual/introduction/whatsnew340#being_notified_on_problem_acknowledgement

トリガーによって生成された障害イベントに対しコメントを入力すること(障害対応)ができます。これは以前のバージョンでもありました。
この障害対応したことを、他のメンバーに通知する機能となります。

上記の参考でもわかるように、アクションの設定に"Acknowledgement oprations"
タブが追加され、そこから設定を行います。

ただし、3.4.2にて"Notify all who left acknowledgement and comments"は、
"Notify all involved"へと変更されています。

データベース変更と処理の想像

この機能の実装のために、下記のようにデータベースに修正が加えられています。

  • task_acknowledgeテーブルが追加
  • escalationsテーブルにacknowledgeidカラムが追加
  • actionsテーブルにack_shortdata, ack_longdataカラムが追加
  • alertsテーブルにacknowledgeidカラムが追加

 

上記からも、障害対応通知に対するアクションがactionsテーブルの追加された二カラムに収められ、障害対応コメント入力後にtask_acknowldgeテーブルへ情報が収められ、その後どこかのプロセスが処理を行い、escalationsテーブルへエスカレーションのためのデータが入れられた後に、Escalatorプロセスにより以降の処理がされるであろうと想像できます。(Escalator, Alerter, escalations, alerts テーブルの関係を思い出してください。)

Webフロントエンドでの入力

Webフロントエンドにて、障害対応を行うと最終的に、acknowledgeテーブル、taskテーブルとtask_acknowledgeテーブルへデータがinsertされます。
(途中の経過はWebフロントエンドの実装があまりに複雑なため割愛します。ごめんなさい。)

frontends/php/include/classes/api/services/CEvent.php:

441 public function acknowledge(array $data) {
456 foreach ($eventids as $eventid) {
457 $acknowledges[] = [
458 'userid' => self::$userData['userid'],
459 'eventid' => $eventid,
460 'clock' => $time,
461 'message' => $data['message'],
462 'action' => $action
463 ];
464 }
465
466 $acknowledgeids = DB::insert('acknowledges', $acknowledges);
...
499 for ($i = 0; $i < $ack_count; $i++) {
500 $tasks[] = [
501 'type' => ZBX_TM_TASK_ACKNOWLEDGE,
502 'status' => ZBX_TM_STATUS_NEW,
503 'clock' => $time
504 ];
505 }
506
507 $taskids = DB::insert('task', $tasks);
...
511 for ($i = 0; $i < $ack_count; $i++) {
512 $tasks_ack[] = [
513 'taskid' => $taskids[$i],
514 'acknowledgeid' => $acknowledgeids[$i]
515 ];
516 }
517
518 DB::insert('task_acknowledge', $tasks_ack, false);

(余談ですが、障害をクローズする場合もこの関数で行われます。)

acknowledgeテーブルは、Webフロントエンドに入力した情報を収めます。taskテーブルは、Task Managerがポーリングする対象となるテーブルですね。typeがZBX_TM_TASK_ACKNOWLEDGE であるため判別ができます。
そして、task_acknowledgeテーブルによりこれら二つの関連付けができるようになっています。

 Task Managerによるポーリング

 Webフロントエンドからの入力が各テーブルに収められたら、その後はTask Managerプロセスによる処理となります。

375 static int tm_process_tasks(int now)
376 {
...
391 while (NULL != (row = DBfetch(result)))
392 {
393 ZBX_STR2UINT64(taskid, row[0]);
394 ZBX_STR2UCHAR(type, row[1]);
395 clock = atoi(row[2]);
396 ttl = atoi(row[3]);
397
398 switch (type)
399 {
400 case ZBX_TM_TASK_CLOSE_PROBLEM:
401 /* close problem tasks will never have 'in progress' status */
402 if (SUCCEED == tm_try_task_close_problem(taskid))
403 processed_num++;
404 break;
405 case ZBX_TM_TASK_REMOTE_COMMAND:
406 /* both - 'new' and 'in progress' remote tasks should expire */
407 if (0 != ttl && clock + ttl < now)
408 tm_expire_remote_command(taskid);
409 processed_num++;
410 break;
411 case ZBX_TM_TASK_REMOTE_COMMAND_RESULT:
412 /* close problem tasks will never have 'in progress' status */
413 if (SUCCEED == tm_process_remote_command_result(taskid))
414 processed_num++;
415 break;
416 case ZBX_TM_TASK_ACKNOWLEDGE:
417 zbx_vector_uint64_append(&ack_taskids, taskid);
418 break;
419 default:
420 THIS_SHOULD_NEVER_HAPPEN;
421 break;
422 }
423
424 }
425 DBfree_result(result);
426
427 if (0 < ack_taskids.values_num)
428 processed_num += tm_process_acknowledgments(&ack_taskids);

3.2.xでは、Task Managerが処理を行う対象は、ZBX_TM_TASK_CLOSE_PROBLEM だけでしたが、3.4.xでは4つに増えています。

今回のケースでは、ZBX_TM_TASK_ACKNOWLEDGEが対象となります。(残りの二つは次回解説を行う予定です。)
この場合、ack_taskidsにてリストを作成し、tm_process_acknowledgements()により処理を行います。

tm_process_acknowledgements()では、各taskidを用いて必要な情報をDBから抽出します。
ここから、src/zabbix_server/actions.c : process_actions_by_acknowledgments() をコールして、最終的にescalations()テーブルへ情報を挿入します。

後の処理は既存のEscalator, Alerterプロセスにまかせます。

この機能を実装するにあたり、Task Managerプロセスが導入されました。それに伴い、taskテーブルとtask_close_problemテーブルも導入されました。
Webフロントエンドから手動クローズを行うと、これらのテーブル等に適宜情報を挿入し、該当のイベントのステータスを変更します。

後の処理は、新しく追加したTask Managerプロセスに任せることになります。

本機能も既存の処理に上手に割り込ませて実装できていると思います。
次回は、Task Managerを使用する最後のサービス、リモートコマンドのプロキシ等での実行について解説を行います。

関連記事

注意事項

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

 

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

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

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

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