【Zabbix × ServiceNow検証②】MIDサーバを利用してServiceNowからZabbixの障害をクローズする方法

お疲れ様です。SCSKの新沼です。

今回は、前回に続いてZabbixとServiceNowの連携について検証したいと思います。
前回のブログ（ZabbixからServiceNowへの自動起票編）をまだ読んでいない方は、ぜひこちらからご覧ください！
【Zabbix × ServiceNow検証①】Zabbixの障害通知をServiceNowのインシデントとして自動起票・クローズ連携する方法

前回の検証では、Zabbixで検知したアラートをServiceNowのインシデントとして自動起票させる「情報の集約」を実現しました。しかし、実際の運用現場では、情報の通知だけでなく、「ServiceNow側で対応を終えたら、自動的にZabbixのアラートも消えてほしい」という、双方向の同期が求められます。

今回は、ネットワーク的な制約をクリアしつつ、この「双方向連携」をどう実現したか、詳しく解説していきます。

1. 検証の概要
2. 検証環境のアーキテクチャ
3. 実装内容
4. 実際の動作確認
おわりに

1. 検証の概要

前回のブログでは、Zabbix → ServiceNowへの連携として、以下2点を実装いたしました。

Zabbixで障害発生時に、WebhookでServiceNowにインシデントが自動起票される
Zabbixで障害クローズ時に、WebhookでServiceNowの対象インシデントのステータスを「解決済み」に更新する

今回の検証目的は、MIDサーバを利用して、ServiceNow → Zabbixのセキュアな通信（逆方向の連携）を実装することです。

ゴールとしては、以下の動作を実装・確認しました。

ServiceNowでインシデントを「解決済み」にした際、自動的にZabbix APIを実行して対象の障害をクローズ（確認済みに）する

これにより、運用担当者が複数の画面を行き来することなく、ServiceNow側の操作のみで監視情報の管理を完結できる仕組みを目指します。

2. 検証環境のアーキテクチャ

本検証では、ZabbixサーバはAWS上のプライベートサブネット内に配置されており、セキュリティの観点からインターネット（外部）からの直接的な通信はすべて遮断されています。一方、クラウドサービスであるServiceNowから見ると、この閉域環境にあるZabbixは「住所はわかるが、たどり着けない場所」にあります。

ここで活躍するのが、ServiceNowが提供するMIDサーバ（Management, Instrumentation, and Discovery Server）です。

構成図の通り、MIDサーバをZabbixと同じプライベートサブネット内に配置します。このMIDサーバは、自分からServiceNowに対して「何か命令はありますか？」と定期的に確認に行く（ポーリングを行う）という挙動をします。つまり、通信の起点は常に内部（プライベート側）からとなるため、ファイアウォールのインバウンド設定を緩和することなく、セキュアにServiceNowからの指示を受け取ることが可能になるのです。

3. 実装内容

それでは、実装内容を解説します。本検証では、ServiceNowの「Flow Designer」や「RESTメッセージ」といった標準機能を最大限に活用し、MIDサーバを経由させるための作り込みを行いました。

① MIDサーバのセットアップと検証

まずは、AWSのプライベートサブネット内にMIDサーバ用のLinuxインスタンスを用意しました。
MIDサーバのインストールは、ServiceNowのコンソールから「MIDサーバー」＞「ダウンロード」でダウンロードしてください。
インストール方法の詳細は、「MIDサーバー」＞「インストール方法について」をご参照ください。

JREのインストール: MIDサーバの稼働にはJava環境が必要なため、適切なバージョンのOpenJDKをセットアップします。
インストーラーの実行: ServiceNowインスタンスからダウンロードしたMIDサーバ用ファイルを解凍し、接続先URLや認証情報を設定します。
バリデーション: ServiceNowの管理画面から、MIDサーバが「Up」の状態になり、さらに「Validated（承認済み）」となるまで確認します。この状態になって初めて、ServiceNowからのリクエストを代行できるようになります。

② RESTメッセージの定義（Zabbix APIの設定）

ServiceNowからZabbix API（JSON-RPC）を呼び出すためのテンプレートを作成します。

エンドポイント: http://<Zabbixサーバ内部IP>/zabbix/api_jsonrpc.php を設定します。
メソッド: 今回は障害をクローズ（確認済み）にするため、event.acknowledge メソッドを使用します。
MIDサーバの指定: RESTメッセージ設定内の「MID Server」項目で、先ほど構築したMIDサーバを指定します。

③ Zabbix API実行用のペイロード（JSON）設計

ZabbixのAPIに渡すJSONデータには、以下の情報が含まれるようパラメータ化しました。

eventids: どの障害を閉じるか（前回、ServiceNow起票時にレコードに保存しておいたEvent IDを使用）
action: 6（「確認」および「障害のクローズ」を意味するフラグ）
message: 「ServiceNow側で解決されたため自動クローズ」といったコメント

④ Flow Designer による自動化ロジックの構築

「インシデントが解決されたらAPIを実行」という動きを、ServiceNowのノーコード/ローコード開発機能である Flow Designer で実装しました。

Trigger: インシデント（incident）テーブルの「状態（State）」が「解決済み（Resolved）」に変わったとき。
Action: 先ほど作成したRESTメッセージを呼び出す。
Data Mapping: インシデントレコード内に保持されている「Zabbix Event ID」をAPIの引数として渡すように紐付けます。

実装の詳細はSCSKまで

本記事では概要をご紹介していますが、実際の環境構築においては、RESTメッセージの詳細なパラメータ設計や、Flow Designerでのエラーハンドリング、さらにはセキュアな認証情報の管理など、一筋縄ではいかない「特別な設定」が数多く存在します。
弊社には、数多くの検証と実案件で培ったServiceNow実装のノウハウが豊富にございます。