English

お問い合わせ

BLOG

Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その7 - Task Managerプロセス利用のサービス障害対応済み通知

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

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

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

障害対応の通知とは?

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

参考

Zabbix Documentation 3.4 - 4 ACKNOWLEDGEMENT OPERATIONS

Zabbix Documentation 3.4 - 5 WHAT'S NEW IN ZABBIX 3.4.0

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

上記の参考でもわかるように、アクションの設定に "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 を使用する最後のサービス、リモートコマンドのプロキシ等での実行について解説を行います。

関連記事

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

注意事項

  • 本ドキュメントの内容は、予告なしに変更される場合があります。
  • 本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
  • 本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、当社はその損害についての責任を負いません。あくまでお客さまのご判断にてご使用ください。
サイバートラストのテレワークソリューション
採用情報ページ リニューアル
組込み Linux にプラスして 長期間の製品ライフサイクルをサポート EM+PLS