はじめに
こんにちは！初めまして！
Qiita初投稿になります！
最近、目まぐるしいくらいAIが進化していますね。
情報量が多すぎて、正直ついていけていません……。
個人利用でClaude、Chatgpt、Claude Code、Codexは使ってるんですが
実際のシステム上に組み込むってなるとなかなか使いづらい部分もあるので、クラウド環境ですぐ使えるBedrock使ってみようかな～と思って重い腰上げ、今年の3月頃にようやくAWSアカウント作成しました。
今更感はありますが...。
そこで今回はせっかくなので、Zabbixで検知したアラートを起点に、ServiceNowへのインシデント起票、AWX/Ansibleによる障害機器のログ収集、Amazon BedrockによるAI一次切り分けまでを自動化する構成を作ってみました。
自分用の備忘録も兼ねて、設定した内容やハマったポイントなどを、各セクションごとに分けて記事にしていこうと思います！
前提条件
今回のメインは連携部分とBedrock周りなので以下の構築・起動・導入手順は割愛します。
- WSL 2（Windows Subsystem for Linux 2）
- Zabbix Server
- Zabbix Proxy 兼 踏み台サーバ
- AWX
- ServiceNow PDI
全体構成図
まずは今回構築したシステム全体の構成図です。
※なるべくコストを抑えた検証構成にしています。
ほぼLambda頼りになってしまいました。
ただ、Zabbix、ServiceNow、AWX、Bedrockをつなぐには、
イベントを受けて処理を振り分ける場所が必要だったので、
今回はLambdaを連携の中心に置いています。
監視対象はNW機器にしたかったので、Cisco DevNet Sandboxを使いました。
また、AWXで実行するPlaybookはGitHub上で管理してAWX側から同期して実行する構成にしています。
検証環境
今回の検証で利用した主な環境は以下です。
| 項目 | バージョン | OS | インスタンスタイプ |
|---|---|---|---|
| WSL2 | 2.6.3.0 | Ubuntu 24.04.4 | - |
| Zabbix Server | Zabbix 7.0.25 | RHEL-9.4.0 | t3.small |
| Zabbix Proxy 兼 踏み台サーバ | Zabbix 7.0.25 | RHEL-9.4.0 | m7i-flex.large |
| AWX | 21.7.0/k3s | RHEL-9.7.0 | m7i-flex.large |
| AWS Lambda | Python 3.11 | - | - |
Bedrockのモデルは以下を使用しました。
jp.anthropic.claude-haiku-4-5-20251001-v1:0
注意：各バージョンは検証時点のものです。
各サービスの役割
| サービス | 役割 |
|---|---|
| Zabbix Server | アラート検知・Webhook送信 |
| Zabbix Proxy | 監視対象環境への監視中継 |
| AWS Lambda | 各連携の仲介役 |
| ServiceNow | インシデント起票・更新・クローズ・Work notes追記 |
| AWX | Ansible・Playbook実行基盤 |
| Ansible | 障害機器からのログ収集処理 |
| GitHub | Playbook管理 |
| Amazon S3 | 取得ログの保存 |
| Amazon Bedrock | ログ解析・過去類似事象確認・AIによる一次診断 |
処理の流れ
大まかな流れは以下になります。
- Zabbixで障害アラートを検知
- Zabbix ActionからWebhookでAWS Lambdaを呼び出し
- LambdaがServiceNowへインシデントを自動起票
- LambdaがAWXのJob Templateを実行
- AWX/Ansibleが対象機器からログを収集
- 取得ログをAmazon S3へ保管
- LambdaがBedrockへログ解析を依頼
- Bedrockが原因候補や確認観点を生成
- 解析結果をServiceNowのWork notesへ追記
- 復旧時はServiceNowのチケットを更新またはクローズ
今回のゴール
障害機器から取得したログをAmazon Bedrockで解析し、ServiceNowの過去インシデントから類似事象を検索したうえで、AIによる一次診断結果をServiceNowのWork notesへ追記し、復旧時にはServiceNowのチケットを自動クローズするところまでが今回のゴールとなります。
動作イメージ
実際に動かすと、ServiceNow側ではインシデントが自動起票されてAWXのジョブ起動結果やBedrockによるAI診断結果がWork notesへ追記されます。
-
自動起票
-
自動ログ取得コマンド/AWXJob実行ID
-
Bedrock過去事例解析
-
Bedrock一次切り分けと復旧後の自動クローズ
なぜこの構成にしたか
業務ではAnsibleを使ったり、ServiceNowでインシデント管理してるのでそこにAIを使った切り分けを入れてみようかな～ってサウナ入りながら浮かんだのでこの構成にしました。
「ZabbixとServiceNowつないで、AWXでログ取って、Bedrockに読ませたら面白そうだな～？」とか考えていたらだいぶ欲張りセットになっていました笑
とはいえやりたいことはシンプルです。
Zabbixのアラートをただの通知で終わらせず、人が調査を始める前にシステム側でチケット起票・ログ収集・一次切り分けの材料整理まで進めてくれる状態を作ってみたいな～と。
その考えをもとに今回の構成を実際に組んでみました！
連載予定
| 回 | セクション | 内容 |
|---|---|---|
| 第0回 | 全体構成編 | 全体構成とゴールイメージ |
| 第1回 | Zabbix設定編① | CiscoDevNetSandbox Launch 監視設定 |
| 第2回 | Zabbix設定編② | Zabbix Action / Webhook設定 |
| 第3回 | 自動起票編 | LambdaからServiceNowへの起票・更新・クローズ |
| 第4回 | AWX設定編 | GitHub連携、AWX設定、Playbook設定 |
| 第5回 | Bedrock編 | モデル選定・ロール付与・プロンプティング |
| 第6回 | 最終動作確認編 | Zabbix検知からWork notes追記までの通し確認 |
まとめ
今回は全体構成編ということでシステム構成の全体像を整理しました。
検証環境としてはすでに一通り動くところまで作っているので、
今後の記事では各セクションごとに実際に設定した内容やハマった点を順番に整理していこうと思います。
まずは第1回Zabbix設定編①として、Zabbix ActionとWebhook設定まわりを書いていきます。
気になった方がいたら、ぜひ続きを見ていただけるとうれしいです！