digitalocean/do-agent: What the Droplet Metrics Agent Actually Collects and Where It Stops

The problem do-agent solves is DigitalOcean's, not yours

The README states the purpose in one line: do-agent enables droplet metrics to be gathered and sent to DigitalOcean to provide resource usage graphs and alerting. That sentence defines both the scope and the audience. The consumer of the data is DigitalOcean's backend, and the output is the graphs and alerts shown in the control panel. If you have ever created a Droplet and wondered why the CPU chart is empty until you tick the Monitoring checkbox, do-agent is the missing piece. It is not a general purpose telemetry shipper, and the README never presents it as one. There is no section on configuring a remote write endpoint, no mention of Prometheus exposition, no output format documented for third parties. The audience is therefore narrow and specific: teams running workloads on DigitalOcean who want the platform's built in monitoring to work, and who are willing to accept that the metrics flow to DigitalOcean rather than to a store they control. Anyone evaluating do-agent as a replacement for node_exporter or the OpenTelemetry collector is reading the wrong project.

How the agent fits between /proc, /sys and the DigitalOcean backend

The repository is a Go program, built with GNU Make, and the README's development section lists Go 1.11 or later, Make and Docker as requirements. The Docker example is the clearest statement of the data flow: the container is run with /proc mounted read only at /host/proc and /sys mounted read only at /host/sys, then started from the digitalocean/do-agent:stable image. That path layout tells you the agent reads host kernel interfaces rather than a container's own namespaces, which is the standard pattern for a node level collector. From there the README says the agent sends metrics to DigitalOcean backend servers, and it also mentions that the agent performs authentication against those servers. So the flow is: read counters from the mounted proc and sys trees, authenticate to the DigitalOcean metrics endpoint, and push samples. The README does not document the wire format, the sampling interval, the endpoint hostname, or the full metric list. Those are implementation details you would have to read out of the source. What is documented is the dependency on network reachability for both authentication and metric delivery, which is why the SELinux note exists at all.

Installing it means running a hosted script or ticking a checkbox

There are three documented installation paths. The first is at Droplet creation: select the Monitoring checkbox on the create screen and the README says you get the latest stable version of do-agent. The second is the repository script, fetched and piped to a shell: curl -sSL https://repos.insights.digitalocean.com/install.sh | sudo bash, with a wget equivalent. The README also shows the inspect first variant, downloading to ./install.sh with curl -L -o, reading it with less, then running it with sudo. The third path is the container, which does not install anything on the host but does require the two read only mounts shown above. Note what the script is for: it configures a package repository, and the README says to use your OS package manager (yum, dnf, apt-get) to update and manage do-agent afterwards. That matters for lifecycle. Removal is apt-get remove do-agent on Debian based systems and yum remove do-agent on RHEL based ones. If you bypass the repository and place a binary by hand, you lose the update path and the README's SELinux warning applies to you directly.

The SELinux nis_enabled flag is the failure mode people hit

The README devotes a dedicated note to SELinux, and it is the most concrete operational constraint in the document. The install script sets nis_enabled to 1. Without that boolean, the README states, do-agent cannot reach the network to perform authentication or send metrics to DigitalOcean backend servers. If you reverse the setting, or install the agent manually rather than through the script, you must run setsebool -P nis_enabled 1 && systemctl daemon-reexec or the agent will not operate. Two things are worth pulling out. First, this is a network reachability failure, not a metrics parsing failure, so the symptom is silence rather than an error in a graph. Second, the fix is persistent (-P) and requires a systemd re-exec, which is a heavier action than flipping a runtime boolean. On a hardened host where nis_enabled is deliberately off, do-agent is the wrong tool unless you are willing to change that policy. The README does not offer an alternative mechanism for authentication that avoids the boolean, so the trade-off is real rather than cosmetic.

Distribution support is a list, not a promise

The README enumerates supported platforms: Ubuntu from the oldest End Of Standard Support LTS release and later, Debian from the oldest supported LTS release and later, Fedora 27 and newer, CentOS 6 and newer, and Docker. CloudLinux 6 and newer sits under a separate Not officially supported heading. Immediately after, the README admits that do-agent works on most Linux distributions and invites you to run it wherever you succeed, with the caveat that issues will not have official support from DigitalOcean. Read that as a boundary rather than a marketing line. If your fleet is Ubuntu and Debian LTS, you are inside the supported set and package updates are the expected maintenance path. If you are on an unlisted distribution, you are on your own for build and packaging, and the version numbers in the support list will drift as upstream LTS windows move. The README links out to the Ubuntu and Debian release pages for those definitions rather than pinning versions itself, so the effective support window is whatever those projects currently consider supported.

What do-agent does not do, and what to use instead

The limitation is structural, not a missing feature. do-agent sends to DigitalOcean. There is no documented remote write target, no local scrape endpoint, and no retention story in the README, so historical data lives wherever DigitalOcean keeps it and expires on DigitalOcean's terms. If you need to query metrics months later, join them with application telemetry, or ship them to a store you own, a general purpose collector is the right choice. Prometheus node_exporter is the obvious comparison and the difference in approach is stark: node_exporter exposes metrics on an HTTP endpoint and holds no credentials, while do-agent authenticates outbound to a vendor backend and is configured by an install script rather than a config file. The trade is operational cost against control. With node_exporter you run Prometheus, storage, and alert rules yourself. With do-agent you get graphs and alerting in the DigitalOcean control panel with no backend to operate, and you accept that the pipeline terminates at DigitalOcean. Neither is wrong; they answer different questions. The README gives no indication that do-agent can do both, so running it alongside a Prometheus stack is duplication, not integration.

Maintenance cost and the Apache-2.0 licence question

The project is active, with releases 3.18.14, 3.18.12 and 3.18.10 appearing between March and May 2026 according to the release list, and the last push to master in September 2026. Version numbering suggests patch level cadence rather than large feature jumps. For operators, the practical maintenance cost is low if you installed through the repository: apt-get or yum handles updates, and the agent is a single service. The cost rises if you build from source, because the README pins Go 1.11 or later and expects GO111MODULE=on with GOFLAGS=-mod=vendor and go mod vendor for dependency changes, which is a vendored module workflow rather than a plain go build. The licence is Apache-2.0, a permissive licence that permits commercial use and modification with attribution and notice requirements; the README does not discuss licensing beyond the repository metadata, so treat any redistribution question as one for your own counsel rather than something this document answers. One thing the README does not cover is what happens to the agent's behaviour during a DigitalOcean control plane incident: since authentication and delivery both depend on reaching backend servers, that is the scenario to reason about before you rely on the graphs alone.

Editorial conclusion

Adopt do-agent if your compute runs on DigitalOcean Droplets and you want the platform's own resource graphs and alerting without operating a metrics backend. Do not adopt it if you need long term storage, arbitrary backends, or per-metric control, because the README describes a collector that sends to DigitalOcean and nothing else. Before rolling it out fleet wide, verify three things: that your distribution is inside the supported list in the README, that SELinux hosts have nis_enabled set to 1 with setsebool -P nis_enabled 1 && systemctl daemon-reexec, and that your package manager can see the repository the install script configures, since that is how updates and removal are meant to happen.

Official sources

1. digitalocean/do-agent on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases