こんにちは!
SCSKの新沼です。
システム監視で障害を検知したあと、皆さんはチームメンバーへの連携や対応タスクの管理をどのように行っていますか?
今回は、Zabbixで障害の検知を行い、対応タスクの管理は別ツールで手動起票している方に向けて、Backlogとの連携検証をしました。
Zabbixの障害通知をBacklogの課題として自動起票し、障害復旧時には自動でクローズする連携方式をご紹介します。
こんな方におすすめの記事です
- 普段のプロジェクト管理・タスク管理にBacklogを利用している
- Zabbixの障害通知とタスク起票を1本のフローで自動化したい
- Zabbix標準のWebhook連携をカスタマイズしたい
Backlogとは?
Backlogは、株式会社ヌーラボが提供する国産のプロジェクト管理・タスク管理ツールです。
課題(タスク)管理、ガントチャート、Wiki、Gitリポジトリなどを1つのサービスで扱えることが特徴で、開発現場だけでなく社内の運用業務やチームのタスク管理ツールとして幅広く利用されています。
REST APIも公開されているため、外部システム(今回のZabbixのような監視ツール)からのタスク自動起票・更新にも活用できます。
1. 検証の概要
今回の検証では、以下の2点をゴールとして実装・確認を行いました。
- Zabbixで障害発生時に、WebhookでBacklogに課題(タスク)が自動起票されること
- Zabbixで障害クローズ時に、Webhookで対象タスクのステータスを「未対応」から「完了」に更新すること
検証環境のアーキテクチャ
セキュリティ要件を考慮し、セキュアな環境をAWS上で再現しています。
- Zabbixサーバ:AWS EC2上に構築し、外部からの直接アクセスが不可なプライベートサブネットに配置
- 通信経路:Zabbixからのアウトバウンド通信は、NAT Gatewayを経由してBacklogへ送信
2. Zabbix → Backlog連携の仕組み
Zabbixの標準機能である「Webhook(メディアタイプ)」を使用します。
Zabbixがアラートを検知すると、JavaScriptで記述されたWebhookスクリプトが実行され、BacklogのREST APIに対してリクエストを送信する仕組みです。
- 障害発生時:
POST /api/v2/issuesで新規課題を起票 - 障害復旧時:起票時の課題キーをキーにして
PATCH /api/v2/issues/{issueKey}を実行し、ステータスを「完了」に更新
ポイント:起票と復旧をどう紐付けるか
本連携の鍵は、「障害発生時に起票された課題」と「同じ障害の復旧通知」をどう紐付けるかという点です。
本検証では、Zabbixのイベントタグ機能を活用しました。
- 障害発生時、Webhookで課題を起票し、Backlog APIからのレスポンスに含まれる課題キー(例:
ZABBIX-9)を取得 - 取得した課題キーを、Zabbixのイベントタグ
BacklogIssueKeyとして同一イベントに紐付ける - 復旧通知時には、同じイベントに紐付いた
BacklogIssueKeyタグを参照して、対象の課題をPATCHで更新
これによって、「同じ障害イベントの起票と復旧を確実に紐付けて更新する」ことが可能になります。
3. 実装手順
Backlog側での事前準備
Zabbixの設定に入る前に、Backlog側で以下3つの情報を取得しておきます。
① APIキーの取得
- Backlogにログイン後、右上のアイコン > [個人設定] > [API] を開く
- [API] タブで「メモ」に任意の名前を入力し [登録] をクリック
- 登録されたAPIキーを控えておく
② projectId / issueTypeId の取得
- [プロジェクト] > [プロジェクト設定] > [種別] を開き、障害を登録したい種別をクリック(今回は「タスク」を選択)
- 遷移先のURLに含まれる
projectIdとissueTypeIdを控えておく
Zabbix側の設定
Step1: メディアタイプ(Webhook)の設定
Zabbixの [通知] > [メディアタイプ] > [メディアタイプの作成] から、Backlog連携用のWebhookを作成します。
主要なパラメータ設定:
| パラメータ名 | 設定値 |
|---|---|
api_key |
Backlogで取得したAPIキー |
backlog_url |
https://<あなたのBacklogスペース>.backlog.com |
event_value |
{EVENT.VALUE} |
issue_key |
{EVENT.TAGS.BacklogIssueKey} |
issue_type_id |
Backlogで取得したissueTypeId |
message |
{ALERT.MESSAGE} |
project_id |
Backlogで取得したprojectId |
subject |
{ALERT.SUBJECT} |
さらに、Zabbixの障害画面から該当のBacklog課題へワンクリックで遷移できるよう、以下のメニュー項目も設定しておきます。
- メニュー項目名:
Backlog: {EVENT.TAGS.BacklogIssueKey} - メニュー項目URL:
https://<あなたのBacklogスペース>.backlog.com/view/{EVENT.TAGS.BacklogIssueKey}
スクリプト部分について:
WebhookのJavaScriptスクリプトでは、event_value の値によって「新規起票(POST)」と「ステータス更新(PATCH)」を分岐させています。
💡 【POINT】クローズ連携(ステータス変更)を実現するには
Backlog側の必須項目や、ステータスID(今回は完了=statusId=4)、優先度(priorityId)などは、ご利用のBacklogプロジェクトの設定に依存します。そのため、正しくクローズ連携を動作させるには、環境に合わせたスクリプトのカスタマイズが必要です。
本記事ではスクリプトの詳細な中身は割愛しております。
「Backlog連携をこれから導入したい」「既存のスクリプトでうまくクローズ連携ができない」といったお困りごとがあれば、ぜひSCSKまでお問い合わせください。
メッセージテンプレート:
Webhookで送信するメッセージは、[メッセージテンプレート] タブから障害用・障害復旧用の2種類を設定します。
- 障害時(件名):
{EVENT.NAME} - 障害時(メッセージ):
Zabbixにて障害を検知しました。 ・発生日時:{EVENT.DATE} {EVENT.TIME} ・対象ホスト:{HOST.NAME} ・障害内容:{EVENT.NAME} ・深刻度:{EVENT.SEVERITY} - 障害復旧時(件名):
{EVENT.NAME} - 障害復旧時(メッセージ):
対象サーバーの障害が復旧しました。
Step2: ユーザーへのメディア割り当て
通知を実行するZabbixユーザーに対し、作成したBacklog用メディアを割り当てます。
- [ユーザー] > [ユーザー] から通知対象ユーザーを選択し、[メディア] タブを開く
- [追加] をクリックし、タイプに
Backlog_test、送信先にBacklogを入力 - [有効] にチェックを入れて [追加] → [更新] をクリック
Step3: トリガーアクションの設定
障害発生時と復旧時に、対象ユーザーに対してWebhookを発行するための「アクション」を設定します。
- [通知] > [アクション] > [トリガーアクション] > [アクションの作成]
- [アクション] タブで、任意のアクション名を入力
- [実行内容] タブで、[実行内容] と [復旧時の実行内容] の両方を追加
- ユーザーはStep2で設定したユーザーを、送信メディアタイプは
Backlog_testを選択
「実行内容(障害発生時)」と「復旧時の実行内容(障害回復時)」の両方にBacklogへの通知処理を組み込むのがポイントです。片方だけだと、起票はされてもクローズが動かない(またはその逆)状態になってしまうため、忘れずに設定しましょう。
4. 実際の動作確認
設定が完了したので、実際に疑似障害を発生させて連携の動きを確認します。
① Zabbixで障害検知 → Backlogにタスク起票
検証用ホストのサーバをダウンさせて、Zabbix側でアラートを発生させます。
Zabbix側の障害画面を見ると、タグに BacklogIssueKey: ZABBIX-9 が付与されていることが確認できます。
Backlog側を見に行くと、、、
無事にタスクが自動起票されました 🎉
Zabbixから送信した件名・発生日時・対象ホスト・深刻度が、Backlogのタスクにそのまま反映されています。
② Zabbixで障害復旧 → Backlogのタスクを完了
続いて、サーバを起動させてZabbix側の障害を復旧させます。
Zabbix側ではステータスが「解決済」になります。
この復旧アクションをトリガーとして再度Webhookが送信され、先ほど起票されたBacklogのタスクも連動してステータスが「未対応」→「完了」に更新されました。
※前述の通り、このようにBacklog側でクローズへのステータス更新を正常に行うには、環境に合わせたスクリプトのカスタマイズが必要になります。
5. つまずきポイントと対処のヒント
実装の過程でハマりやすいポイントを、参考までにいくつかご紹介します。
- 課題キーが取得できず、クローズ側でエラーになる
→ 障害発生側のWebhookで、Backlog APIのレスポンスからの課題キーの取り出しや、Zabbixタグへの格納処理が正しく動作しているかを確認しましょう。 - クローズ時に新規タスクが再起票されてしまう
→event_valueの分岐(1=障害/0=復旧)が正しく機能しているかを見直しましょう。 - クローズはされるがステータスが想定と違う
→statusIdはBacklogプロジェクト側の定義に依存します。「完了」に対応するIDが4とは限らないため、対象プロジェクトの設定をご確認ください。
おわりに
今回は、ZabbixとBacklogをWebhookで連携し、障害通知の自動起票・クローズを実現する方法をご紹介しました。
この連携により、以下のようなメリットが期待できます。
- 起票漏れ・クローズ忘れの防止:人手を介さないため、対応漏れが構造的に発生しない
- 対応履歴の一元管理:Backlog上に対応履歴が自動で蓄積され、後からの振り返りやKPT運用が容易に
- 運用工数の削減:監視オペレーターの起票作業がゼロに
「監視は Zabbix、タスク管理は Backlog」という運用をされているチームには、特に効果を実感いただける連携です。
最後まで読んでいただき、ありがとうございました!
少しでも皆さんの監視運用やタスク管理の効率化のヒントになれば嬉しいです。
「うちの環境でも試してみたい」「もう少し詳しく聞きたい」など、ご質問・ご相談があれば
お気軽にSCSKまでお問い合わせください。
弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。
★SCSK Plus サポート for Zabbix★

★YouTubeに、SCSK Zabbixチャンネルを開設しました!★
★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★








