AWS DevOps Agent を使ってみる (Getting started with AWS DevOps Agent の実施)

1. はじめに

• システム障害アラートのコールを受ける業務があり、精神的にもよくないので、なるべく負荷軽減したい。
• AWS DevOps Agent を使うと、システム障害原因調査をAgentがやってくれるとのこと。
• アラートの連絡を受けた時、Agentによる一次調査が終わっていれば、少しは楽になるかなと思い、どんなものかを試してみることにする。

2. やったこと

• 自分のAWSアカウントでDevOps Agentを有効にする。
• Getting Started にあるテスト（疑似障害）を発生させる。（Getting Startedには、①EC2インスタンスのCPU高騰、②Lambdaの実行エラーの2パターンがあるが、本記事では①のEC2インスタンスCPU高騰の内容を記載）
• 疑似障害についてDevOps Agentに問い合わせして、きちんと調べてくれるのか確認する。

3. 構成図

4. 手順

基本的には「Getting started with AWS DevOps Agent」をそのまま実施し、気になるところを追加で確認する。

4.1 エージェントスペースの作成

Getting started のページに、マネコン/CLI/CDK/CloudFormation/Terraformの5通りの作成方法の説明がある。私は初心者なのでマネコンの手順「Creating an Agent Space」で実施する。

• DevOps エージェント -> エージェントスペースを作成　を選択する。
  

• エージェントスペース名と、応答言語（日本語を選択）のみを設定し、エージェントスペースを作成する。

• エージェントスペースが作成されると、初期状態では自分のAWSアカウントのみが監視対象となっている。必要に応じて、別のAWSアカウントを追加したり、GitHubやSlackなど各種の外部接続登録が可能な様子。

4.2 テスト環境の作成

「Creating a test environment」の通りに、疑似障害を起こすテスト環境を作成する。本記事では「Test option A: EC2 CPU capacity test」について記載する。（記事にしていないが、「Test option B: Lambda error rate test」も簡単に確認可能。）

• 「Test option A: EC2 CPU capacity test」では、インスタンス内でyesコマンドを含むスクリプトを実行して、CPU100%貼り付けを発生させる。

• 以下の2つがCloud Formationで作成される。

  • EC2インスタンス(負荷スクリプト含む)
  • CPU負荷を監視するCloudWatchアラーム

• このCloudFormationの前提条件として、EC2インスタンスを立てるサブネットが別途必要なため、以下のVPC/サブネットを事前に用意する。(起動スクリプトでyum updateするのと、後でSession Managerで接続するので、インスタンスからインターネット接続できるようにした）

  • NAT GatewayのないVPC
  • 「パブリックIPv4アドレスの自動割り当てを有効化」したパブリックサブネット

• CloudFormation を実行してリソースを作成する。

• ドキュメントでは「インスタンス起動直後に負荷スクリプトが自動実行される」とあるが、うまくいかない（UserData内でスクリプトを呼んでいない気がする…）ため、一度Session Managerで接続して負荷スクリプトを手動実行する。

[root@ip-10-0-0-122 ec2-user]# ./cpu-stress-test.sh

• CloudFormationで作成したCloudWatch アラームが、CPU高騰をトリガにアラーム状態になることを確認する。

4.3 テスト（疑似障害）に関するDevOps Agentへの問い合わせ

• エージェントスペース -> オペレーターアクセス　で、DevOpsエージェントとのチャット画面を開くことができる。
  

• 「CloudWatch アラーム AWS-DevOpsAgent-EC2-CPU-Test で直近に発生したアラームの概要、原因、対策を教えて」と問い合わせしたところ、アラームの詳細情報は得られたが、原因はつかめなかった。

4.4 少しだけ追加検証

• DevOps Agent の障害原因調査が失敗する原因として、DevOps Agentが調査できる情報が少ないことが考えられる。そのため、調査に役立ちそうな情報を増やしてみる。

• 今回、Session Manager で接続して、負荷をかけるスクリプトを実行しているが、この行動は DevOps Agentでは把握できない。そのため、Session Manager での操作ログをCloudWatch Logsに出力する設定を追加する。（手順は省略）

• ログが出る設定にした後、再度Session Managerでインスタンスに接続し、あえてスクリプトの内容をcatで表示した上で、スクリプトを再実行し、CloudWatchアラームを再発生させる。

[root@ip-10-0-0-23 ec2-user]# cat cpu-stress-test.sh
#!/bin/bash
echo "Starting AWS DevOpsAgent CPU Stress Test"
echo "Time: $(date)"
echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)"
echo ""
～省略～

[root@ip-10-0-0-23 ec2-user]# ./cpu-stress-test.sh
Starting AWS DevOpsAgent CPU Stress Test
Time: Fri May 29 10:45:26 UTC 2026
Instance:

CPU Cores: 2
～省略～

• この操作ログがある状態で、再度 DevOps Agent に原因調査を依頼する。「CloudWatch アラーム AWS-DevOpsAgent-EC2-CPU-Test で直近に発生したアラームの概要、原因、対策を教えて」と再度普通に聞いてもSession Manager については調べてもらえなかったが、「Session Manager のログを確認して」と追加依頼することで、原因にたどり着くことができた。

5. 所感

• 使い方の雰囲気は分かったので、引き続き以下の深堀りを行いたい。
  • CloudWatchアラームなどをトリガーに自動で調査を開始する手順
  • 調査結果を外部に送信する手順
  • DevOps Agentの調査に必要なログやメトリクスは何か
  • datadog, grafanaなどの外部接続