DigitalOcean 监控和告警指南 2026

作者：CloudPicked 评测团队•更新于 2026年7月17日•阅读约 17 分钟

DigitalOcean 为每个 Droplet 提供免费的内置监控和告警策略功能，无需额外成本。这些功能涵盖基本的基础设施指标，如 CPU、RAM、磁盘和带宽，以及每个账户一个免费的运行时间检查。本指南逐步介绍设置和配置，包括生产工作负载的关键考虑事项。

免费内置监控——追踪的内容（CPU/RAM/磁盘/带宽）

DigitalOcean 监控是一项免费的内置功能，对每个 Droplet 可用，无需额外成本，无论您有多少个 Droplet。系统收集四个主要的基础设施级指标：CPU 使用率（每核百分比）、内存/RAM 使用率、磁盘使用和 I/O（读/写），以及入站和出站带宽（每秒比特数）。它还显示系统平均负载。所有数据以图表形式显示在每个 Droplet 的控制面板的监控标签页中，让您可以看到资源趋势，无需每次都 SSH 进入并运行 `top` 或 `htop`。重要的是要理解 DigitalOcean 监控不是完整的可观测性堆栈——它缺少日志聚合、分布式跟踪和用于应用级性能或数据库查询分析的 APM。它只是回答基本问题："这台机器使用了多少，这是否异常？"这涵盖运行中小型网络应用或 API 的典型 Droplet。要查看端点延迟、每条路由的错误率或缓慢的数据库查询，您需要单独的工具。某些指标（如 CPU、磁盘 I/O 和带宽）从虚拟机监控程序即时报告，无需额外设置，但精确的内存使用情况需要安装监控 Agent，接下来介绍。

每核 CPU 使用率（百分比）
内存 (RAM) 使用情况需要 Agent 才能准确
磁盘使用和磁盘 I/O（读/写）

安装监控 Agent

用户经常问到的一点是：在 Droplet 上安装监控 Agent (do-agent) 有两种方法。最简单的方法是在创建新 Droplet 时检查"监控"框——它在首次启动时通过 cloud-init 自动安装，无需额外步骤。这对任何新 Droplet 都最有效。对于没有 Agent 的现有 Droplet，通过 SSH 使用官方安装脚本手动安装，如 `curl -sSL https://repos.insights.digitalocean.com/install.sh | sudo bash`（命令可能会定期更新；在生产环境中运行前检查 docs.digitalocean.com 以获取最新语法）。安装后，使用 `sudo systemctl status do-agent` 验证状态——您应该看到 active (running)。如果 Agent 无法启动或指标不显示，请使用 `journalctl -u do-agent -n 50` 检查日志。Agent 仅通过 HTTPS 端口 443 向 DigitalOcean 端点发送数据；它不在您的 Droplet 上打开任何入站端口，因此您通常不需要调整云防火墙入站规则。但是，如果您的 Droplet 默认限制出站（deny-all），您必须首先允许出站 HTTPS。自定义或最小化映像可能不支持自动安装脚本——始终在事先检查官方文档中的兼容性列表。

最简单：在创建新 Droplet 时检查监控
手动安装：在现有 Droplet 上通过 SSH 运行 install.sh
使用 systemctl status do-agent 检查状态
Agent 仅发送出站 HTTPS；无需更改入站端口

为 Email/Slack 通知创建告警策略

告警策略是一项规则，当指标在设定时间内超过阈值时发送通知。在控制面板中从监控 > 告警策略 > 创建告警策略创建一个。有四个主要步骤。首先，选择要监控的指标：CPU 使用率、内存使用率、磁盘使用率或带宽。其次，设置阈值和持续时间——例如，"CPU 在 5 分钟内持续超过 80%。"系统不会因短暂峰值而发出警报；它等待阈值在您指定的持续时间内保持，减少来自短流量突增的误报。第三，通过单个实例或标签选择目标 Droplet，以自动涵盖所有标记的 Droplet，这对大型集群或自动扩展很方便，因为添加机器时您无需重新配置。第四，选择通知渠道：Email（发送给账户所有者或团队成员）或 Slack（在集成中连接 Slack 工作区并授予权限后）。连接后，任何选择 Slack 的告警策略都会在指标超过阈值时以及解决时发布到该频道，让团队了解问题的开始和结束。

选择指标：CPU / 内存 / 磁盘 / 带宽
设置阈值和最小持续时间，例如，5 分钟内 80%
将告警策略分配给单个 Droplet 或标记所有相关的

免费运行时间检查——每个账户 1 个

除了 Droplet 指标外，DigitalOcean 为每个账户提供一个免费的运行时间检查。它从世界各地的多个检查位置按计划 ping 指定的 URL（HTTP 或 HTTPS），以确认您的网站或 API 端点正在响应并测量响应时间。与查看机器内部资源的监控不同，运行时间检查从外部查看，就像真实用户访问网站一样——它可以捕捉监控无法捕捉的问题，如 DNS 失败、过期的 SSL 证书或负载均衡器正常但后端 Droplet 故障。在监控 > 运行时间 > 创建检查处创建一个。输入要检查的 URL，选择检查位置，并设置检查频率。创建后，通过选择类似停止状态或高响应时间的条件，将告警策略链接到运行时间检查，然后通过 Email 或 Slack 发送警报，就像使用 Droplet 指标一样。关键限制是每个账户一个免费的运行时间检查。如果您需要监控多个端点或关键服务，请查看接下来介绍的其他工具。即使一个运行时间检查也很有价值——将其绑定到您最关键的端点，如主页或主 API 健康检查。

要点总结： 每个账户 1 个免费运行时间检查；从外部全球位置监控

每个账户 1 个免费运行时间检查；从外部全球位置监控
测量上行/下行状态和响应时间
在监控 > 运行时间 > 创建检查处配置
以与 Droplet 指标相同的方式将告警策略链接到运行时间检查
对于多个端点，使用外部工具补充

集成外部监控工具

用户经常问到的一点是：当 DigitalOcean 的内置监控不够时——需要日志聚合、超过 1 个运行时间检查或完全可自定义的仪表板——存在多个选项。一个流行的开发者方法是在单独的 Droplet 上自托管 Prometheus，在目标 Droplet 上运行 node_exporter 以公开系统指标供 Prometheus 抓取，然后附加 Grafana 用于仪表板和详细的告警规则——比基本告警策略灵活得多，但需要管理一个额外的服务器，无需经常性费用。或者，使用 SaaS 代理（如 Datadog 或 New Relic），其安装方式与 do-agent 类似，但涵盖 APM、日志管理和分布式跟踪，以及供应商的月费用（与 DigitalOcean 费用分开）。对于多个无额外成本的运行时间检查，在小型 Droplet 上自托管 Uptime Kuma——它监控尽可能多的端点，包括公共状态页。DigitalOcean 还公开了 Metrics API；如果您已经有中央仪表板并想将 DigitalOcean 数据与其他基础设施集成，请使用您的个人访问令牌将原始指标拉入外部系统。

Prometheus + node_exporter + Grafana 用于完全可自定义的仪表板和警报
Datadog / New Relic 代理用于完整的 APM、日志记录和跟踪（单独费用）
自托管 Uptime Kuma 以免费监控无限端点
DigitalOcean Metrics API 以将原始数据拉入您的中央仪表板

何时使用此功能（真实用例）

当您想要基本基础设施可见性而无需增加成本或复杂性时，DigitalOcean 的内置监控和告警策略效果最佳。第一个用例：为副项目或 MVP 运行几个 Droplet 的独立开发者或小团队。启用免费监控和 CPU 或磁盘接近满的告警策略在停机前警告您，无需企业工具投资。第二个：管理许多客户 Droplet 的代理机构。使用带有告警策略的标签可让您一次配置并自动覆盖所有相关机器，减少在引入新客户或扩展时的重复设置。第三：还未准备好采用完整可观测性堆栈的初创公司。免费监控加上主端点上的一个运行时间检查是在增长过程中采用复杂工具之前的合理起点。第四：在多个 Droplet 上使用负载均衡器的团队。按后端组标记的告警策略可让您在负载均衡器删除故障机器之前捕捉故障机器，从而比等待客户报告更快地进行修复。第五：在文件系统填满并导致系统崩溃之前追踪磁盘使用情况。所有这些场景都受益于免费的基线监控。

需要无成本基本警报的独立项目 / MVP
通过标签管理多个客户 Droplet 的代理机构
还未准备好采用完整可观测性平台的初创公司

常见错误和修复

综合多次测试，最常见的错误是忘记在现有 Droplet 上安装监控 Agent，然后想知道为什么内存指标不显示或显示为空白。始终首先使用 `systemctl status do-agent` 验证；如果不存在，按照前面的部分进行安装。第二个：设置告警策略阈值过紧，如 CPU 超过 50%，导致警报疲劳——太多误报导致团队忽视实际问题。修复：观察 1-2 周的真实基线使用情况，然后将阈值设置在正常峰值明显之上，而不是任何峰值都立即发出警报。第三个：误解免费运行时间检查涵盖所有端点，而实际上每个账户只覆盖一个，当其他端点失败时留下盲点。如果您有多个关键端点，从一开始就计划备份监控工具。第四个：创建告警策略但没有完全配置通知渠道或正确连接 Slack，或 Slack 频道后来被删除或存档而没有通知——策略"静默"，即使它在运行。设置后至少手动触发一次测试通知。第五个：完全跳过标签，强制您为每个新 Droplet 重新配置告警策略，当团队忙碌或自动化创建实例时会被遗忘。

忘记安装 Agent——内存指标丢失——首先检查 systemctl status do-agent
阈值过紧 → 警报疲劳——调整前进行基线测量
误认为免费运行时间检查覆盖所有端点，而只允许 1 个
创建了告警策略但通知渠道损坏或 Slack 频道已删除——测试真实发送

最佳实践

首先：每次创建新 Droplet 时都启用监控作为默认习惯——它无需花费且避免改造安装。其次：早期标准化标签（按环境 prod/staging，按角色 web/db/worker）并将告警策略绑定到标签而非个别 Droplet，这样新实例在接收相同标签时立即自动继承警报。第三：从真实观察而非猜测设置阈值，并在 Droplet 大小或工作负载发生重大变化时重新访问。第四：将一个免费运行时间检查专用于单个最关键的端点，如反映整体系统状态的中央健康检查端点，然后使用自托管 Uptime Kuma 或外部工具补充次要端点。第五：不要仅依赖监控用于高风险生产系统——一旦系统需要深度日志分析和请求跟踪，就添加 Prometheus/Grafana 或 SaaS 可观测性服务。最后：在设置后至少手动测试一个告警策略（例如，模拟高 CPU）以确认通知到达其预期渠道。保持与当前 DigitalOcean 定价和条款一致，截至 2026 年 7 月。

作为默认实践在每个新 Droplet 上启用监控
早期标准化标签；将告警策略绑定到标签，不是个别 Droplet
从真实基线设置阈值；当 Droplet 大小或工作负载变化时重新访问
使用 1 个免费运行时间检查在最关键的端点；用 Uptime Kuma 补充其他

领取 $200 免费额度 →

常见问题（FAQ）

DigitalOcean 监控需要额外费用吗？

不需要。监控是每个 Droplet 的免费内置功能，包括每个账户一个免费的运行时间检查。（信息截至 2026 年 7 月；查看 DigitalOcean 的官方网站了解当前条款。）

我必须安装监控 Agent 才能看到图表吗？

CPU、磁盘 I/O 和带宽等某些指标从虚拟机监控程序报告，无需额外设置。精确的内存使用和更细粒度的指标需要首先安装 do-agent。

告警策略支持哪些渠道？

Email 和 Slack。Slack 需要授权 DigitalOcean 应用通过集成连接您的工作区，然后才能选择它作为通知渠道。

如果我需要为超过 1 个端点进行运行时间检查怎么办？

DigitalOcean 为每个账户提供只有 1 个免费运行时间检查。对于更多，使用外部工具，如在 Droplet 上自托管 Uptime Kuma 或第三方服务。

内置监控是否存储应用日志？

不。DigitalOcean 监控仅收集基础设施级指标（CPU/RAM/磁盘/带宽），不收集应用日志。对于集中式应用日志，通过 rsyslog 或 Vector 将日志传输到单独的日志聚合服务。

这适合真实生产系统吗？

是的，作为以零成本提供良好基础设施级洞察的基础。但是，复杂的生产系统应该添加 Prometheus/Grafana 或 SaaS 工具（如 Datadog）以进行深度日志分析和请求跟踪。