【本編】AWS DevOps AgentはZabbixアラートをどこまで調査できる？zabbix-mcp-server連携で監視情報を深掘り

1. はじめに

1-1. AWS DevOps Agentとは

AWS DevOps Agentは、インシデント発生時にAWS環境のログやメトリクスを参照しながら調査を行い、根本原因の特定や緩和策の提示を支援する、フロンティアエージェントの一つです。

アラートやユーザーによるチャットを起点に調査を開始し、AWS内のログやメトリクスなどを横断的に分析し、仮説を立てて検証を繰り返し根本原因を特定することができます。

また、MCPサーバーをAWS DevOps Agentに接続することで、AWSのAPIだけではアクセスできない監視ツール、ログ基盤、チケット管理システムなどの周辺情報も調査に活用できます。

AIエージェントを活用したクラウド環境の監視方法について、NTT東日本のエンジニアがご相談にお応えしますので、お気軽にご連絡ください！

2. 本コラムでの実施内容

本コラムでは、AWS上で稼働するZabbix Serverで監視を行っている環境を想定し、ZabbixアラートをトリガーにAWS DevOps Agentで調査を開始する構成を検証します。

前述の通りZabbixにて監視している内容はAWSのAPIだけではアクセスできないため、zabbix-mcp-server（MCPサーバー）を用意し、Zabbixでアラートが発生した際にAWS DevOps Agentがアラート内容を受け取るだけでなく、Zabbix API経由でホスト情報、障害情報、トリガー、アイテムなどを追加で取得しながら調査できるようにします。

2-1. 具体的なシチュエーション

AWS上でホストしているApp Serverにて重いSQLクエリを実行し、これに伴って発生したCPU使用率の高騰をトリガーにAWS DevOps Agentに調査してもらいます。

Zabbixでは、App Serverをzabbix-agent2で監視しています。テンプレートとして以下を適用し、さらにMySQLプロセスのCPU使用率を取得するアイテムを追加しています。

テンプレート：

• Linux by Zabbix agent
• MySQL by Zabbix agent 2
• AWS EC2 by HTTP

アイテム：

• キー：proc.cpu.util[mysqld]

この環境で同じCPU使用率高騰のアラートを発生させ、以下の2パターンで調査結果を比較します。

• MCPサーバーありのAWS DevOps Agent：AWS APIで取得可能な情報以外に、Zabbixで監視しているCPU使用率以外の情報を取得し追加の調査が可能な状態
• MCPサーバーなしのAWS DevOps Agent：CloudWatchメトリクスよりCPU使用率が高騰していることは確認できるが、AWS APIで取得可能な情報からは詳細な調査ができない状態

2-2. 検証環境の構成

AIエージェントを活用したクラウド環境の監視方法について、NTT東日本のエンジニアがご相談にお応えしますので、お気軽にご連絡ください！

3. 検証環境の構築

本コラムで使用するZabbixや監視対象となるEC2インスタンスなどはCloudFormationテンプレートとして定義しています。

なお、CloudFormationテンプレートの詳細やスタックの展開、展開後の各種設定などの手順が多いため【環境構築編】AWS DevOps AgentはZabbixアラートをどこまで調査できる？zabbix-mcp-server連携で監視情報を深掘りに記載しておりますので、そちらをご確認ください。

4. 実際に試してみた

4-1. CPU使用率高騰のアラートの発生

App ServerにSSHで接続し、以下の重いSQLクエリを実行することでCPU使用率の高騰（Linux: High CPU utilization）を発生させます。

for i in 1 2; do
  timeout 600 bash -c 'while true; do mysql -uroot -p'\''<スタック展開時に指定したDBRootPassword>'\'' appdb -e "SELECT SQL_NO_CACHE SUM(a.amount * b.amount * c.amount) FROM transactions a CROSS JOIN transactions b CROSS JOIN transactions c WHERE a.id < 5000 AND b.id < 5000 AND c.id < 500;" > /dev/null 2>&1; done' &
done

<スタック展開時に指定したDBRootPassword>の置換を忘れないようにしてください

しばらく待つとZabbixにてアラートが発報し、トリガーアクションが動作していることを確認できます。

そしてトリガーアクションによるAWS DevOps AgentへのWebhookによって、調査が自動的に開始されます。

4-2. MCPサーバーありのAWS DevOps Agent

ZabbixからWebhookでAWS DevOps Agentに通知された情報を元に、zabbix-mcp-serverを介して該当ホストを特定し、そのホストで発生中の障害を確認している様子が確認できます。

途中、MySQLプロセスによるCPU使用率の高騰や、CPU使用率が急騰したタイミングで新しいMySQL接続が確立されていることを把握することができていました。

さらに待つと調査が完了し、「根本原因」タブで調査結果を確認できます。

最終的に根本原因として「暴走クエリによるCPU飽和」であると判断されました。

4-2-1. 緩和計画

AWS DevOps Agentは根本原因として断定した内容に対処するための方法を「緩和計画」として提示してくれます。

「緩和計画」タブから確認することが可能で、今回MCPサーバーありの場合は以下を提案されました。

App Serverにて暴走クエリを特定し強制終了する

今回は検証環境なので、提示された緩和策をそのまま試してみます。

本番環境では事前の検証や追加のコマンドの実施、あるいは運用ルールや承認フローの確認などが必要になるかと思います

1. 準備

提示されたコマンドを実行し、長時間実行中のクエリを確認します

コマンド結果から、暴走クエリはIDが17、18であることが確認できました

SSHでターミナルにアクセスしているため、コマンドを一部変更しています

[ec2-user@ip-10-0-1-166 ~]$ mysqladmin -u root processlist -p
Enter password:
+----+-----------------+-----------------+-------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
| Id | User            | Host            | db    | Command | Time  | State                  | Info                                                                                                 |
+----+-----------------+-----------------+-------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
| 5  | event_scheduler | localhost       |       | Daemon  | 29203 | Waiting on empty queue |                                                                                                      |
| 16 | root            | localhost:59616 |       | Sleep   | 27    |                        |                                                                                                      |
| 17 | root            | localhost       | appdb | Query   | 1566  | executing              | SELECT SQL_NO_CACHE SUM(a.amount * b.amount * c.amount) FROM transactions a CROSS JOIN transactions  |
| 18 | root            | localhost       | appdb | Query   | 1566  | executing              | SELECT SQL_NO_CACHE SUM(a.amount * b.amount * c.amount) FROM transactions a CROSS JOIN transactions  |
| 22 | root            | localhost       |       | Query   | 0     | init                   | show processlist                                                                                     |
+----+-----------------+-----------------+-------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+
[ec2-user@ip-10-0-1-166 ~]$

2. 事前検証

CPU使用率がまだ100%付近であることはZabbix上で確認しています

3. 適用

提示されたコマンドを実行し、長時間実行中のクエリを終了します

コマンドを実行しID：17、18のクエリがKILLされました

SSHでターミナルにアクセスしているため、コマンドを一部変更しています

[ec2-user@ip-10-0-1-166 ~]$ mysql -u root -p'<App ServerへのMySQLセットアップ時に設定したパスワード>' -e "SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND='Query' AND TIME > 300 ORDER BY TIME DESC" -s -N | while read id; do mysql -u root -p'<App ServerへのMySQLセットアップ時に設定したパスワード>' -e "KILL $id"; echo "Killed query ID: $id"; done
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
Killed query ID: 17
mysql: [Warning] Using a password on the command line interface can be insecure.
Killed query ID: 18
[ec2-user@ip-10-0-1-166 ~]$

4. 事後検証

提示されたコマンドを実行し、長時間実行中のクエリが一覧にないことを確認します

コマンドを実行し、300秒以上実行中であるクエリはないことが確認できました。

SSHでターミナルにアクセスしているため、コマンドを一部変更しています

[ec2-user@ip-10-0-1-166 ~]$ mysqladmin -u root processlist -p
Enter password:
+----+-----------------+-----------------+----+---------+-------+------------------------+------------------+
| Id | User            | Host            | db | Command | Time  | State                  | Info             |
+----+-----------------+-----------------+----+---------+-------+------------------------+------------------+
| 5  | event_scheduler | localhost       |    | Daemon  | 29513 | Waiting on empty queue |                  |
| 16 | root            | localhost:59616 |    | Sleep   | 37    |                        |                  |
| 27 | root            | localhost       |    | Query   | 0     | init                   | show processlist |
+----+-----------------+-----------------+----+---------+-------+------------------------+------------------+
[ec2-user@ip-10-0-1-166 ~]$

これらの対処により、CPU使用率の高騰が収まり、Zabbix上でもアラートが回復したことを確認することができます。

4-2-2. 恒久対処

AWS DevOps Agentは恒久的に対処するための方法を「次のステップ」として提示してくれます。

障害の内容などに応じて設定変更を検討すると良いでしょう。

4-3. MCPサーバーなしのAWS DevOps Agent

比較のため、zabbix-mcp-serverを接続していないAWS DevOps Agentにも同じアラートを起点に調査させてみます。

Zabbixより、WebhookでAWS DevOps Agentに通知された情報を元に、AWS上のインスタンスを特定している様子が確認できます。

途中、CloudWatchメトリクス等から実際にCPU使用率が高騰していることは把握できたものの、どのプロセスがCPUを消費しているのかまでは把握できない状態であることが分かります。

そこで追加の手がかりを得るため、ユーザーデータでzabbix-agent2を導入していることから、Zabbix Server側のCloudWatchメトリクス等も確認。その結果、Zabbix ServerのネットワークOUTが該当の時間に急騰していたことと、今回のApp ServerのCPU使用率高騰を関連付けました。

最終的に根本原因として「Zabbix Serverからの大量のpassive checkデータの送信が原因」であると判断されました。

Zabbix ServerのネットワークOUT急増は、実際には保坂がZabbix Webインターフェースにてアラート発生状態を確認していたことに起因します

4-3-1. 緩和計画

MCPサーバーなしのAWS DevOps Agentからは「インスタンス自体の再起動を行い、暴走プロセスを終了させる」ことを対処として提示されました。

4-4. 比較結果

このように、MCPサーバーを接続した構成では、Zabbix上のプロセス単位のメトリクスやMySQL接続数などを参照できるため、CPU使用率高騰の原因をMySQLの暴走クエリまで絞り込むことができました。

一方、MCPサーバーを接続していない構成では、CloudWatchメトリクスを中心とした調査となるため、EC2インスタンス全体のCPU使用率高騰は把握できるものの、どのプロセスが原因なのかまでは判断しきれませんでした。

AIエージェントを活用したクラウド環境の監視方法について、NTT東日本のエンジニアがご相談にお応えしますので、お気軽にご連絡ください！

5. 余談

AWS DevOps Agentは、デフォルトの状態でもAWS API等を使用し、かなり細かな情報まで調査をします。

そのため、うっかりSSMで接続し重いSQLクエリを実行しようものなら、SSMセッションログ等を元に「ユーザー：保坂がSSM経由で重いSQLクエリを実行した」などと言われてしまいます。

今回の検証では、意図的な操作内容が調査結果に影響しないよう、App Serverへの接続にはSSMではなくSSHを利用しました。

逆に言えば、SSMセッションログ等を記録しておくことで、ユーザーの操作に起因する障害の原因特定もスムーズになります。

また、今回の環境ではCloudFormationでスタックを展開していますが、ユーザーデータ上でMySQLのセットアップ等も行っていると手がかりの一つとなり、MCPサーバーが存在しない場合でもMySQLプロセスが怪しい旨を指摘されることになります。

AWS DevOps Agentの調査力が高いため、比較検証用の条件を整えるのも一苦労でした。

AIエージェントを活用したクラウド環境の監視方法について、NTT東日本のエンジニアがご相談にお応えしますので、お気軽にご連絡ください！

6. さいごに

本コラムでは、Zabbixで発生したアラートを起点にAWS DevOps Agentによる調査を開始し、zabbix-mcp-server（MCPサーバー）を介してZabbix上の監視情報を参照する構成を紹介しました。

今回の検証では、MCPサーバーなしの構成ではCloudWatchメトリクスを中心とした調査となり、CPU使用率高騰の詳細な原因までは特定できませんでした。一方、MCPサーバーを接続した構成では、Zabbixに蓄積されたホスト情報、障害情報、プロセス単位のメトリクスなどを参照でき、MySQLプロセスのCPU使用率上昇や接続数の増加から、暴走クエリによるCPU飽和という根本原因の特定につなげることができました。

監視運用では、アラート発生後の一次切り分けに多くの時間がかかります。AWS DevOps Agentに、CloudWatchなどのクラウド側の情報だけでなく、Zabbixのような既存の監視基盤に蓄積された情報も参照させることで、初動調査を効率化し、運用担当者が判断すべきポイントの整理に有効であることを確認できました。

一方で、AWS DevOps Agentが提示する調査結果や緩和計画については、そのまま本番環境へ適用するのではなく、実行内容や影響範囲を確認したうえで判断することが重要です。特に、プロセス停止や設定変更を伴う対応では、既存の運用ルールや承認フローと組み合わせて利用する必要があります。

既存の運用基盤を活かしながらインシデント対応の効率化や属人化の低減を進めるうえで、MCPサーバーを用いたAWS DevOps Agent連携は有効な選択肢の一つになるのではないでしょうか。

本コラムが皆さまの監視運用の新しい選択肢として参考になれば幸いです。

• Amazon Web Services（AWS）およびその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。