Datadog Fleet Automationを使ってAgentをリモートでアップグレード・設定変更してみた
こんにちは、なおにしです。
Datadog のFleet Automation 機能を検証する機会がありましたのでご紹介します。
はじめに
Datadog では、Fleet Automation 機能を利用して Datadog Agent をリモート管理できます。
具体的にはドキュメントに記載のとおり、Fleet Automation 機能を用いて以下の操作が可能です。
| 操作 | 説明 | 最小エージェントバージョン |
|---|---|---|
| Datadog Agent のフレア送信 | Datadog Agent のトラブルシューティング情報を Datadog のサポートチームに送信するための機能flareをリモートで実行する |
7.47以上 7.66以上推奨 |
| Datadog Agent のアップグレード | Datadog Agent をリモートでアップグレードする | 7.66以上 |
| Datadog Agent の設定 | Datadog Agent をリモートで設定する | 7.73以上 |
Zabbix のように Server と Agent が基本的に同じバージョンで構成される環境であれば、特定の新機能が必要な場合や EOL を迎える場合に両方をアップグレードするといった運用になるかと思いますが、Datadog のようなSaaS では Server 側は随時最新化されているので、Agent も定期的にアップグレードすることが推奨されます。
Agent がインストールされているホストの台数が少なければ、都度ログインして手動でアップグレードすることも可能ではあるかと思いますが、台数が多くなればなるほど、その運用負荷は増大します。
というわけで、実際に Fleet Automation 機能を使用して、Datadog Agent をリモートでアップグレードおよび設定変更してみます。
やってみた
事前準備
まず、Datadog 組織の設定として、Remote Configurationが有効になっていることを確認します。
エージェント側からも以下のように確認できます。
# datadog-agent status "remote configuration"
====================
Remote Configuration
====================
Organization enabled: True
API Key: Authorized
Last error: None
実際に Fleet Automation のページから確認したところ、管理下のホストとして認識はされています。
ですが、対象のホストを選択して内容を見ると、Remote Agent ManagementがNOT ENABLEDになっていました。
エージェント側でも確認したところ、確かに Fleet Automation が有効化されていないようです。
# datadog-agent status "fleet automation"
================
Fleet Automation
================
Fleet Management is disabled
Remote Management Status: Disabled
Datadog Installer Status: Not running
この状態では、残念ながらエージェントをリモートで設定することもアップグレードすることもできなさそうです。
現在インストールされているエージェントのバージョンは以下のとおりです。
# datadog-agent version
Agent 7.71.2 - Commit: a13e160920 - Serialization version: v5.0.164 - Go version: go1.24.6
このため以下に記載のとおり、バージョン7.66以上であればリモートでのバージョンアップは可能かと思ったのですが、今回検証した環境ではそうでもなさそうでした。
組織レベル、APIキーレベルのいずれでも Fleet Automation は有効になっているので、以下の記述に基づいてエージェントレベルで逆に明示的に remote_configuration.enabled をtrue に指定してみたりしましたが有効化されませんでした。
Starting with Agent version 7.47.0,
remote_configuration.enabledis set totrueby default in the Agent. This setting causes the Agent to request configuration updates from the Datadog site.If you don’t want your Agent to send configuration requests to Datadog, you can set
remote_configuration.enabledtofalsein the Agent.
そこで改めて確認すると、以下のドキュメントでは前提条件にエージェントのバージョンが7.73以降であることが明記されていました。
Fleet Automation に関するドキュメントの記載箇所によって微妙に内容の捉え方が難しいところですが、とりあえずエージェントのバージョンを7.73.xに指定してアップグレードしてみます。バージョンを指定したアップグレード方法については以下に記載があります。
To upgrade to a specific minor version, set
DD_AGENT_MINOR_VERSION=<TARGET_MINOR>before running the script.
DD_AGENT_MINOR_VERSION=73 \
bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"
アップデート後、バージョンを確認してみます。
# datadog-agent version
Agent 7.73.3 - Commit: 445a6fcd5c - Serialization version: v5.0.175 - Go version: go1.24.11
Fleet Automation が有効化されていました。
# datadog-agent status "fleet automation"
================
Fleet Automation
================
Fleet Management is enabled
Remote Management Status: Enabled
Datadog Installer Status: Running
UIからもRemote Agent ManagementがENABLEDになっていることを確認できました。
リモートでの Datadog Agent のアップグレード
事前準備で色々と回り道をしましたが、本題のアップグレードを試してみます。
[Fleet Automation] - [Upgrade Agent]を開くと、対象のホストが表示されました。Release notes は GitHub へのリンクになっているところが良いですね。そのまま[Review Deployment Plan]を押下します。
今回は対象が1ホストしかいませんが、実際には大量のホストに対してエージェントのアップグレードを実行できるため、その際のロールアウト計画を指定することができるようです。画面右のDeployment Safeguardsの和訳は以下のとおりです。より詳細な挙動や前提条件についてはドキュメントをご参照ください。
[Upgrade 1 Agent]を押下します。
展開の安全策
デプロイメントは、スコープ内のインフラストラクチャに基づいてステージにグループ化され、より迅速なデプロイメントを実現します。開発環境やステージング環境など、リスクの低い環境が最初にデプロイされ、その後に本番環境がデプロイされます。
各ステージでは、複数のエージェントが、選択した同時実行数まで並行してデプロイされます。3つのエージェントが連続して失敗した場合、または失敗数が全体の10%に達した場合、デプロイは自動的に一時停止されます。
後でいつでもデプロイメントを再実行できます。
改めて注意書が表示されるので[Confirm]を押下します。注意書きの和訳は以下のとおりです。
注: 導入中、エージェントは一時的にダウンタイムが発生し、自動的に再起動します（エージェント1台あたり1分未満）。万が一、アップグレードが失敗した場合は、影響を受けるエージェントは以前のバージョンに戻されます。
進捗状況が表示されます。
Datadog Agent はアップグレード実行に合わせて一旦停止されていました。
# systemctl status datadog-agent
○ datadog-agent.service - Datadog Agent
Loaded: loaded (/usr/lib/systemd/system/datadog-agent.service; enabled; preset: disabled)
Active: inactive (dead) since Tue 2026-01-27 06:23:40 UTC; 1min 29s ago
Duration: 22min 19.270s
Process: 21076 ExecStart=/opt/datadog-agent/bin/agent/agent run -p /opt/datadog-agent/run/agent.pid (code=exited, status=0/SUCCESS)
Main PID: 21076 (code=exited, status=0/SUCCESS)
CPU: 10.609s
Jan 27 06:12:21 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:12:21 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:12:21 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:12:21 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:12:21 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:12:21 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:22:22 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:22:22 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:22:22 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:22:22 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:22:22 ip-172-30-0-202.ap-northeast-1.compute.internal agent[21076]: 2026-01-27 06:22:22 UTC | CORE | WARN | (comp/core/autodiscovery/providers/conf>
Jan 27 06:23:40 ip-172-30-0-202.ap-northeast-1.compute.internal systemd[1]: Stopping datadog-agent.service - Datadog Agent...
Jan 27 06:23:40 ip-172-30-0-202.ap-northeast-1.compute.internal systemd[1]: datadog-agent.service: Deactivated successfully.
Jan 27 06:23:40 ip-172-30-0-202.ap-northeast-1.compute.internal systemd[1]: Stopped datadog-agent.service - Datadog Agent.
Jan 27 06:23:40 ip-172-30-0-202.ap-northeast-1.compute.internal systemd[1]: datadog-agent.service: Consumed 10.609s CPU time.
今回は4分ほどでアップグレードが完了しました。
サービスも起動しました。エージェントが停止している時間は3分半ほどでした。
# systemctl status datadog-agent
● datadog-agent.service - Datadog Agent
Loaded: loaded (/etc/systemd/system/datadog-agent.service; enabled; preset: disabled)
Active: active (running) since Tue 2026-01-27 06:27:18 UTC; 1min 18s ago
Main PID: 26335 (agent)
Tasks: 8 (limit: 1053)
Memory: 95.5M
CPU: 2.100s
CGroup: /system.slice/datadog-agent.service
└─26335 /opt/datadog-packages/datadog-agent/stable/bin/agent/agent run -p /opt/datadog-packages/datadog-agent/stable/run/agent.pid
Jan 27 06:27:18 ip-172-30-0-202.ap-northeast-1.compute.internal systemd[1]: Started datadog-agent.service - Datadog Agent.
バージョンアップされていることも確認できました。
# datadog-agent version
Agent 7.75.0 - Commit: 58a1be9ec8 - Serialization version: v5.0.177 - Go version: go1.25.5
アップグレードの履歴も残っているので、どのくらいの時間を要したか後で確認するのに便利そうです。画面のとおりアップグレードのスケジュール実行も可能なようですが、今回は割愛します。
リモートでの Datadog Agent の設定変更
Fleet Automation によって Datadog Agent を構成する場合、以下3つのパターンがあります。
- 複数エージェントの構成
- 単一エージェントの構成
- APIを用いたエージェントの構成
詳細はドキュメントをご参照ください。今回は対象ホストが1台ということもあり、単一エージェントの構成を試してみます。
実際の設定ファイル(datadog.yaml)では、エージェントインストール後に以下の部分だけを変更している状態です。
# diff datadog.yaml datadog.yaml.org | grep -v api_key
11c11
---
952c952
< logs_enabled: true
---
> # logs_enabled: false
2179c2179
< log_level: 'warn'
---
> # log_level: 'info'
[Fleet Automation] - [View Agents] で対象ホストを選択し、[Configuration]タブを確認すると以下のとおり上記と一致しています。
例として、今回は Datadog Agent をログ収集のみに使用することを目的として、以下に記載の内容を適用してみます。
上記を適用する意図やその効果、確認方法などについては以下の記事もご参照ください。
適用前のホストの登録状況は以下のとおりです。メトリクス情報が収集されています。
それでは、[Datadog Agent Configuration]で[Edit]を押下して設定します。バリデーションチェックもしてくれるのはありがたいですね。[Deploy Changes]を押下します。
エージェントのアップグレードとは異なり自動で画面遷移しなかったのですが、[Fleet Automation] - [Configure Agents] の画面で進捗状況を確認できます。
完了しました。
設定ファイルを直接確認したところ、コメントが全て削除されて個別に設定されている項目だけを残した状態になっていました。
# grep -v api_key /etc/datadog-agent/datadog.yaml
config_id: shcw-0005j-szne
enable_payloads:
events: false
series: false
service_checks: false
sketches: false
log_level: warn
logs_enabled: true
site: datadoghq.com
Datadog Agent も再起動されていました。
# systemctl status datadog-agent
● datadog-agent.service - Datadog Agent
Loaded: loaded (/etc/systemd/system/datadog-agent.service; enabled; preset: disabled)
Active: active (running) since Tue 2026-01-27 07:17:16 UTC; 1min 15s ago
Main PID: 35176 (agent)
Tasks: 9 (limit: 1053)
Memory: 71.2M
CPU: 1.854s
CGroup: /system.slice/datadog-agent.service
└─35176 /opt/datadog-packages/datadog-agent/stable/bin/agent/agent run -p /opt/datadog-packages/datadog-agent/stable/run/agent.pid
改めて[Host List]を確認したところ、対象ホストが表示されなくなりました（タイムレンジが直近でもPast 2 Hoursしか選べないので、2時間ほど待ちました）。
Past 4 Hoursを選択するとINACTIVEのステータスとして表示されます。
補足
インテグレーションの設定については閲覧することは可能ですが、変更することはできなさそうです。将来的にはあらゆる設定がリモートで可能になるとすごいですね。
まとめ
大量の Zabbix Agent のアップグレードが課題となっている状況に実際に直面したことがある身からすると、Fleet Automation によるリモート管理の体験はとても良いものでした。感動です。Ansible のような自動化ツールを別途準備する必要もなく、Datadog だけで完結できるのも魅力だと思います。
なお、Datadog のコンソールからエージェントを操作しているように見えますが、エージェントに対して通信が発生しているわけではありません。ドキュメントにも以下のとおり明記されており、実際に今回の検証もインターネットからのインバウンドは許可していない環境で実施しています。
ネットワークとプロキシ
Datadog は SaaS 製品です。監視データを送信するには、お客様のネットワークから公共のインターネットへのアウトバウンド接続を確立する必要があります。トラフィックは常に Agent から Datadog へと開始され、デフォルトでは、TLS で暗号化された TCP 接続で行われます。Datadog から Agent へのセッションが開始されることはありません。
本記事がどなたかのお役に立てれば幸いです。
