鉄の意志を持つセルフヒーリング・パイプライン：ZabbixとAnsibleによる完全自動修復アーキテクチャの構築
夜間、PagerDutyやSlackの通知音で叩き起こされる時代は終わった。真に成熟したDevOps組織において、人間が深夜に対応するのは「コードのバグ修正」であって、「プロセス落ちの再起動」や「枯渇したディスクの一時退避」といった泥臭いオペレーションではない。
今回は、Zabbixの深い内部機構とAnsible Automation Controller（旧Tower）のAPIを直結させ、「検知から0秒で発動する、人間不在のインフラ自動修復（セルフヒーリング）パイプライン」の構築手法を解剖する。
マニュアルをなぞるだけの解説はしない。ここでは、高負荷に耐え、暴走を防ぎ、セキュリティを担保したプロダクション環境で即座に使える「極限の知見」だけを提示する。
—
1. Zabbix Webhookメディアタイプ：内部アーキテクチャと限界突破の設計
多くのエンジニアは、Zabbixのアラート連携に「外だしスクリプト（AlertScriptPath）」や「古いPythonスクリプト」を使いがちだが、大規模環境においてそれはアンチパターンである。プロセス起動のオーバーヘッド、コネクションプールの欠如、エラーハンドリングの脆弱性がパイプラインのボトルネックになる。
ここで採用すべきは、Zabbix 4.4以降で導入された JavaScriptベースの `Webhook` メディアタイプ だ。
なぜWebhookメディアタイプなのか？
Zabbixの内部で動くEmbedded JS Engine（Goja）上で直接HTTPリクエストを生成するため、外部プロセスを一切フォークしない。数千件のアラートが同時に発生したスパイキーな状況下でも、CPUとメモリのフットプリントを最小限に抑えながら、ミリ秒単位で外部APIを叩き起こすことが可能だ。
堅牢なWebhookスクリプトの設計
単にAPIを叩くだけのコードは素人仕事だ。プロダクション環境では、「タイムアウト制御」「JSONペイロードの厳密な構築」「HTTPステータスコードの完全なハンドリング」が求められる。
以下に、Ansible Automation ControllerのWebhook受信用エンドポイントを叩くための、洗練されたZabbix JavaScriptコードを提示する。
try {
// 1. パラメータのバリデーションと取得
var params = JSON.parse(value);
var req = new CurlHttpRequest();
// タイムアウト設定（Zabbixのデフォルトは短いので必ず明示的に指定）
req.AddHeader(‘Content-Type: application/json’);
req.AddHeader(‘Authorization: Bearer ‘ + params.token);
// 2. Ansible Automation Controllerへ送るペイロードの構築
// Zabbixのマクロから動的にホスト名やトリガー情報を注入
var payload = {
“extra_vars”: {
“zabbix_alert”: {
“event_id”: params.event_id,
“host”: params.host,
“host_ip”: params.host_ip,
“trigger_name”: params.trigger_name,
“severity”: params.severity,
“status”: params.status,
“item_value”: params.item_value
}
}
};
// 3. APIリクエストの実行
var url = params.url;
Z.log(4, ‘[Ansible Integration] Sending payload to ‘ + url);
var response = req.Post(url, JSON.stringify(payload));
var status = req.GetStatus();
// 4. レスポンスのハンドリング
if (status >= 200 && status < 300) {
Z.log(4, '[Ansible Integration] Successfully triggered playbook. Response: ' + response);
return 'OK';
} else {
throw 'Failed with status code ' + status + '. Response: ' + response;
}
} catch (error) {
Z.log(1, '[Ansible Integration Error] ' + error);
// Zabbixのアラート履歴にエラーメッセージを残すためのスロー
throw 'Failed to execute webhook: ' + error;
}
---
2. Ansible Automation Controller（AWX）側の受入態勢とAPI連携
Zabbixから飛んできたリクエストを受け止め、即座に該当ホストへ修復プレイブックを流し込むためのAutomation Controller側の構成を固める。
テンプレートの「Survey（入力変数）」と「Webhook」の有効化
1. ジョブテンプレートの設定:
- `Execution Environment`: 適切なコレクションが含まれたイメージを指定。
- `Enable Webhook`: チェックを入れる。
- `Webhook Service`: `Generic` を選択。
2. Webhook Key（トークン）の生成:
- 発行されたSecretトークンを、先ほどZabbix側のWebhookメディアタイプの設定（`token` パラメータ）に埋め込む。
これにより、Automation Controllerは `https://
—
3. 実践：セルフヒーリング実装事例とセキュリティ・暴走防止の極意
ここからが本題だ。自動修復における最大の悪夢は 「無限ループ（フラッピング）」 である。
例えば、「Nginxが落ちる ⇒ Zabbix検知 ⇒ Ansibleが再起動 ⇒ 設定ミスで即座に再墜落 ⇒ Zabbix検知 ⇒ 無限ループ」という悪夢のコンボが発動すると、数分でインフラは完全に崩壊する。
これを防ぐための「3つの鉄則」を実装に落とし込む。
事例A：Webサービスの自動再起動（Systemdプロセス監視）
Zabbix側の設定
- アイテム: `proc.num[nginx]`
- トリガー: `last(/Web01/proc.num[nginx])<1`
- リカバリ条件: 障害発現後、同一イベントでの多重発火を防ぐため、Zabbixのイベント生成モードは「単一」または「複数（ただしリカバリで閉じる）」を厳守。
Ansibleプレイブック（セルフヒーリング用）
暴走を防ぐため、プレイブック側でも「過去N分以内に同じ修復が走っていないか」のガードを入れるか、Zabbixのアクション側で「同一ホストに対する連続実行の抑制（クールダウン）」を必ず設定する。
—
- name: Self-Healing Pipeline – Nginx Restart
hosts: “{{ zabbix_alert.host_ip }}”
gather_facts: false
become: true
tasks:
- name: Ensure Nginx is running and healthy
ansible.builtin.systemd:
name: nginx
state: restarted
register: nginx_restart
- name: Verify service port is responding
ansible.builtin.wait_for:
host: “127.0.0.1”
port: 80
delay: 2
timeout: 10
when: nginx_restart.changed
事例B：ディスク容量枯渇の自動一時退避（ログローテーション・古いキャッシュのパージ）
「ディスクが95%を超えた」というアラートに対し、人間がログインして `/var/log` を削る作業ほど無駄なものはない。安全にパージできる領域を自動開放する。
—
- name: Self-Healing Pipeline – Emergency Disk Space Recovery
hosts: “{{ zabbix_alert.host_ip }}”
gather_facts: false
become: true
tasks:
- name: Get current disk usage of /var/log before purge
ansible.builtin.command: df -h /var/log
register: df_before
changed_when: false
- name: Purge rotated logs older than 3 days in /var/log
ansible.builtin.shell: |
find /var/log -type f -name “.gz” -mtime +3 -delete
find /var/log -type f -name “.log.” -mtime +3 -delete
args:
executable: /bin/bash
register: purge_logs
- name: Clean Docker system prune if Docker exists
ansible.builtin.command: docker system prune -f –volumes
when: ansible_facts.services[‘docker.service’] is defined
ignore_errors: true
- name: Get current disk usage of /var/log after purge
ansible.builtin.command: df -h /var/log
register: df_after
changed_when: false
- name: Debug disk cleanup results
ansible.builtin.debug:
msg:
- “Before: {{ df_before.stdout_lines[1] }}”
- “After: {{ df_after.stdout_lines[1] }}”
—
4. プロダクション運用のためのセキュリティ・最適化ハック
このパイプラインを本番環境（特に金融・大規模EC等）に投入する際、アーキテクトとして担保すべきセキュリティとパフォーマンスの要件がある。
1. ネットワークセグメンテーションとゼロトラスト
- Zabbix Server と Ansible Automation Controller の間は、ファイアウォールで厳格にポート（TCP/443）を制限する。
- さらに、Automation ControllerのWebhookエンドポイントには、APIトークン認証に加え、可能であればZabbix側からの送信元IPアドレス制限（あるいはリバースプロキシでのBasic認証等の追加ヘッダー検証）をかける。
2. 「自動修復のサーキットブレーカー」パターン
もし同一ホストで同一の障害が 「1時間に3回以上発生した場合」、自動修復を一時停止し、人間（SREチーム）にエスカレーションしてチケットを切る仕組みをZabbixのアクションエスカレーション機能で作り込むこと。
無限ループによるシステムの破壊を防ぐ最後の砦となる。
3. 監査ログとトレーサビリティ
すべての自動修復は、Ansible Automation Controller側で誰が（システムが）何を実行し、どのような標準出力/標準エラーが出たかが完全にジョブ履歴として残る。
これにより、「深夜に勝手にサーバーが再起動されたが、原因は何だったのか」というブラックボックス化を防ぎ、完全な監査証跡（Compliance & Audit Trail）を維持できる。
—
結びにかえて
オブザーバビリティの本質は、「綺麗なダッシュボードを作ること」ではない。「検知した異常を、人間の認知と介入を介さずに、プログラムされた論理によってミリ秒単位で収束させること」にある。
Zabbixの堅牢なメトリクス収集力と、Ansible Automation Controllerの強力なオーケストレーション能力をこのパイプラインで結合させた瞬間、あなたのインフラは「自己治癒能力を持った生命体」へと進化する。
さあ、人間の手を煩わせるだけのインフラ監視は、今日ここで終わらせよう。