Hundreds of Agents.
One version. One config. One place to check.
Datadog Fleet Automation lists every Agent and OpenTelemetry Collector in the estate, with its version, its configuration and the integrations it runs. You can upgrade and reconfigure them from Datadog rather than from a ticket. It is how Managed Observability keeps a fleet current without a maintenance window per host.
Quick facts
Related
- Infrastructure Monitoring, the hosts the Agents are billed as
- Integrations, the configuration each Agent carries
- Governance Console, the keys and drift across the organisation
The fleet as it is, not as the deployment repository says it is
The question is simple: how many Agents are running, and which versions? The answer is a spreadsheet from the last audit, a Kubernetes DaemonSet that is probably current, and a dozen VMs nobody wants to log into. Fleet Automation answers it from the Agents themselves, now, and lets you act on the answer.
Every Agent, with its version and its products. The inventory includes the Kubernetes clusters, the VMs, the containers and the OTel Collectors, grouped by cluster where that is how they run, with APM, logs and security shown per Agent.
Configuration with a history. What each Agent and integration is configured to do, and when that changed, so the host that stopped sending logs after a config push is identified from Datadog rather than from the host.
Upgrades from Datadog, on a schedule. Outdated Agents and Collectors are listed and upgraded remotely, scheduled by API or Terraform, so a security fix reaches the fleet without a change ticket per host.
Keys and flares, without a login. Which API key each Agent uses, and a support flare pulled remotely when an Agent misbehaves, so the first step of the investigation does not need SSH.
A free feature that needs Remote Configuration on, an inventory that only sees what the integrations see, and an upgrade that ran on half the fleet
How it bills. Fleet Automation is not metered. Datadog includes it with the platform, and an Agent that appears in it is already billed as whatever host or container it runs on. The lever is not cost. It is whether the Agents are configured to be managed at all.
The configuration traps. An Agent appears in the inventory without being manageable from it. Remote Configuration has to be enabled, and on VMs remote updates have to be switched on separately, before an upgrade from Datadog does anything. The inventory shows the Agents that report, plus the hosts without one that a connected cloud integration can see; a host outside those integrations, or with an Agent too old to report, does not appear. Remote upgrades cover Linux and Windows VMs only. Agents in Kubernetes and other containerised workloads are upgraded through the Helm chart or the Operator. The inventory is where a version pinned back by the next deploy shows up. A remote config change applied to every Agent at once has no canary unless somebody built one.
Field noteThe most common gap we see is an inventory with several major Agent versions in it, and a tracer that needs the newest one on a service that runs the oldest. The upgrade nobody scheduled is the reason the feature nobody enabled does not work.
Field noteThe pattern we keep finding is Remote Configuration on for the organisation, because Datadog enables it by default, and remote updates switched on for none of the VMs, because nobody went back for them. The fleet is visible and not manageable, and the VMs are the older half.
Field noteThe Agent version is bumped in one cluster by hand, and the next Helm deploy from the repository pins the previous version back. The inventory shows the regression, but nothing reads it between reviews. The cluster is back on the old version, and the fix it carried is gone.
Field noteSeveral API keys are in use across the fleet, one of them created by a person who has left. Fleet Automation shows which Agents use it. The rotation is a project nobody started because the blast radius was unknown.
Make the fleet manageable before trying to manage it
We start with a Datadog HealthScan. It is read-only and fully automated, and it reports every Agent, its version, its platform, whether Remote Configuration is on, and which API keys are in use, before anything changes. Then the sequence is enablement, baseline, rings.
- Inventory the fleet. Every Agent and Collector against the host list from the cloud account, so the hosts with no Agent are counted too.
- Enable Remote Configuration everywhere. Through the Helm chart, the Ansible role or the installer, with remote updates on where upgrades are wanted. The deployment pipeline is updated so the next deploy does not undo it.
- Agree a target version and a cadence. One supported Agent version for the fleet, a window for applying Datadog's releases, and a canary group that gets them first.
- Upgrade in rings. Canary, then non-production, then production, scheduled through the API, with the inventory checked between rings.
- Standardise the configuration. Integration configs and log collection are pushed from Datadog where that is the right source of truth. Where the deployment repository is, they stay there. The choice is written down.
- Hand over, in writing. The version baseline, the rings, the keys in use, which configuration lives where, and the inventory on the day we finished.
Access is admin on the Datadog organisation plus a change to the Agent deployment, Helm values, Ansible or the installer flags, that your team or ours applies. We do not need shell access to the hosts, which is the point of the feature.
How Managed Observability keeps hundreds of Agents current
Datadog releases Agents often. Autoscaling adds hosts from an image that was current last quarter. A deploy quietly pins a version back. Managed Observability uses Fleet Automation as the tool, and the version baseline and the rings as the practice.
Every month, the version spread. How many Agents are on the baseline, how many drifted, and which hosts cannot be upgraded remotely and need a deploy change instead.
Upgrades, in rings, by us. Datadog's releases are tested on the canary group, scheduled across the rings, and verified in the inventory. A security fix in the Agent reaches the fleet as a routine, not an incident.
Configuration drift is closed. An Agent whose config differs from the fleet, a host whose log collection stopped after a push, or an integration disabled by a deploy is found in the review and corrected.
Keys are kept honest. Which keys are in use and by which Agents, so a rotation is a scheduled task with a known blast radius rather than a risk nobody takes.
We operate the stack. You own the product.
Fleet Automation is the tool. The practice is the version baseline, the rings and the cadence, kept for years. We run that practice as part of Managed Observability and write down each change. The Agents, their configuration and the deployment changes live in your accounts, and you can take them over whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Fleet Automation, answered plainly
How is Datadog Fleet Automation billed?
It is not metered. Datadog includes Fleet Automation with the platform, and each Agent in the inventory is already billed as the host or container it runs on. We do not publish prices. What decides whether it is useful is whether Remote Configuration is enabled on the Agents, which is configuration rather than cost.
Can Datadog upgrade our Agents remotely?
Yes, for Linux and Windows VM Agents with Remote Configuration enabled and remote updates switched on. Outdated Agents and OpenTelemetry Collectors are listed, and upgrades can be run from the Datadog UI, the public API or Terraform on a schedule. Agents in Kubernetes and other containerised workloads are not upgraded remotely; they are upgraded through the Helm chart or the Operator, and Fleet Automation shows the result. SDK upgrades for APM are in Preview.
Does Fleet Automation show hosts that have no Agent?
Only partly. It lists the Agents that report to Datadog, and it can flag hosts with no Agent where a connected cloud integration sees them. A host in an account or provider with no integration, or with an Agent too old to report, does not show. That is why the implementation starts by comparing the inventory with the host list from the cloud account rather than trusting the inventory alone.
Can we manage Agent configuration from Datadog instead of our deployment repository?
You can push integration configuration and custom log collection from Datadog to Linux and Windows VM Agents with Remote Configuration enabled and remote updates switched on. Containerised Agents are not supported, so on Kubernetes the chart stays the source of truth. Whether you should depends on where the rest of the configuration lives. For a VM fleet deployed by Ansible, the repository is usually the right source of truth and Datadog the view. For VMs nobody redeploys, pushing from Datadog is often the only practical way. We make that choice per fleet and write it down.
What does Critical Cloud do with Fleet Automation every month?
Managed Observability reviews the version spread, upgrades Agents in rings from the canary group outward, closes configuration drift, checks which API keys are in use and by which Agents, and reports what changed. The fleet stays on a known baseline without a maintenance window per host.
- Datadog products: every product, and how we implement and run each one
- Infrastructure Monitoring: the host meter every Agent in the fleet lands on
- Integrations: the configuration each Agent carries, kept current
- Datadog HealthScan: every Agent, its version and its Remote Configuration state, read-only and fully automated
A fleet on one version. A fix that reaches every host.
Tell us how many hosts you think you have. We will show you how many Agents Datadog can see, which versions they run, and what it takes to bring them to one.