告警监控范围

本页说明 Dockerman 的容器告警何时在监控、在各个引擎上能检测什么，以及 Dockerman 对一条通知能知道和不能知道什么。

告警规则由本机上的 Dockerman 后台服务（daemon）评估，而不是由 Dockerman 窗口评估。某台主机上某个容器的持续故障是一个事件（Incident）：它在打开时通知一次，保持开启期间可以提醒你，只有在容器被观测到重新稳定、被主动停止、被删除或对应规则被关闭时才会结束。一次性的事实（例如非零退出）是一个告警事件（Alert Event）。

内置规则在你开启之前全部关闭。唯一的例外是从使用旧版通知设置的版本升级：如果那里已开启桌面通知，容器意外退出会开启“容器崩溃（非零退出）”，容器健康检查失败会开启“服务无响应”。

一览

失去观测从不算作恢复。未观测的事件保持开启，提醒继续；一旦 Dockerman 重新看到该容器，必须持续稳定满规则的完整稳定间隔，事件才会恢复。

监控哪些主机

daemon 会监控以下位置的所有容器：

• LOCALHOST，即运行 Dockerman 的这台电脑；
• 每个已保存的、观测此主机开关（在舰队页面）为开启状态的主机。

已保存的 SSH 主机只有在同时具有已保存的凭据和已固定（受信任）的主机密钥时才会被监控，这样 daemon 才能在不询问你任何内容的情况下连接。普通 TCP 主机则两者都不需要。daemon 会自行连接这些主机，无需打开任何 Dockerman 窗口。

其他所有主机完全不会被监控。告警页面上的主机覆盖范围列表会显示每台主机的状态（监控中、部分监控、不支持或未监控）及原因。

Dockerman 窗口与 daemon

窗口关闭到托盘

关闭主窗口会把 Dockerman 隐藏到菜单栏或系统托盘。应用仍在运行，因此监控和系统通知照常工作。点击通知会把 Dockerman 带到前台。

在没有托盘的桌面（部分 Linux 桌面）上，关闭窗口会退出应用，见下一节。

Dockerman 已退出但 daemon 仍在运行

daemon 是一个独立进程。退出 Dockerman（托盘菜单中的退出 Dockerman，或应用的退出命令）不会停止它，所以它会继续观测、打开和结束事件，并向外部渠道（Telegram、Ntfy、Gotify、Discord、Webhook）发送通知。

系统通知需要应用在运行。应用退出期间，每条系统通知都会在事件或告警事件的送达状态中记录为未送达：应用未运行。再次打开 Dockerman 时，错过的系统通知不会补发；进行中的事件会显示在告警页面、容器列表和容器详情页中。

如果希望在 Dockerman 退出期间也能收到故障通知，请为规则添加一个外部渠道。

daemon 停止、重启或退出登录

打开 Dockerman 会启动 daemon（dockerman 命令行工具同样会）。Dockerman 不会在登录时自动启动。电脑重启后、退出登录后或 daemon 停止后，在你再次打开 Dockerman 之前不会监控任何内容。在这段空档内开始并结束的故障永远不会被报告。

daemon 启动时：

• 所有仍在进行中的事件都会从其最后一次观测起标记为未观测；
• daemon 会对每台主机列出一次所有状态的容器，并检查其中正在运行的容器，作为新的基线；
• 容器已不在其主机上的进行中事件会以“已删除”结束，且不发送通知（已停止的容器仍在其主机上，会保留其事件）；
• 仍在崩溃循环的容器会被重新检测到（在 Docker 上通过持续重启周期，见引擎支持），不会为它没有看到的重启编造时间戳。

睡眠

电脑睡眠期间，daemon 处于暂停状态，不观测任何内容。

唤醒后，daemon 会发现系统时钟（wall clock）比单调时钟多前进了超过一个采样间隔（5 秒）。随后它会把每台主机都视为先丢失再恢复：进行中的事件从睡眠前的最后一次观测起标记为未观测，唤醒后需要完整的稳定间隔才能恢复。手动调整系统时钟会产生同样的效果。

这种检测依赖单调时钟在睡眠期间停止走动，这是 macOS 和 Linux 上的行为，在 Windows 上尚未验证。

主机断开连接

当 daemon 丢失某台主机的事件流，或无法对该主机采样时：

• 该主机进行中的事件会被标记为未观测（详情横幅显示“自 … 起未观测”）；
• 这次中断从不被视为恢复；
• 不会发出主机级别的告警，也不会为这次中断本身打开容器事件。Dockerman 没有主机连通性告警。

事件流恢复后，会使用与 daemon 启动时相同的基线，把在空档期间被删除的容器的事件以“已删除”结束。

空档期间发生的重启，只能通过 daemon 再次检查容器时读取到的重启次数得知。只有当两次检查之间的间隔落在规则的时间窗口内时，它们才会计入“重启循环”规则。否则它们会显示为“未观测期间重启 N 次”，并且不会触发该规则。

事件处于未观测状态时，提醒会继续。

引擎支持

告警不覆盖 Kubernetes 集群。

Docker

重启循环在出现以下两类证据之一时打开：

• 计数重启。 时间窗口内达到配置的重启次数，由带时间戳的事件证明，或由两次间隔不超过时间窗口的检查之间重启次数的增加证明。
• 持续重启周期。 容器至少在配置的时长（默认 120 秒）内被观测到反复重启，且从未稳定运行满稳定间隔。这也能捕获开始监控时就已在崩溃循环的容器。

像 SIGHUP 这样的重载信号不会掩盖下一次真正的崩溃。

Podman

• 没有持续重启周期触发。 Podman 兼容 Docker 的 inspect 从不报告 restarting 状态，因此重启循环只能通过计数重启检测。
• 每次 kill 都视为主动操作。 Podman 的 kill 事件不带信号，所以任何 podman kill 之后的退出都被视为主动停止，上文关于重载信号的保证仅适用于 Docker。
• 仅当重启策略为 always 或 unless-stopped 时，podman stop 才会把事件以“已停止”结束。 Podman 把停止报告为一次退出加一次清理，没有 stop 事件。在这两种策略下，引擎会重启每一次退出，所以出现清理而不是重启就意味着容器被停止了。在 on-failure 或 no 下，同样的事件也可能出现在引擎不再重启的崩溃之后，所以事件会保持开启，直到容器重新稳定运行、被删除或规则被关闭。
• 健康状态通过 inspect 读取。 Podman 报告每次健康检查运行但不带结果，因此 daemon 会 inspect 容器来获知健康状态。对同一状态的重复报告只算一次变化。

Apple Container

Apple Container 没有事件流。daemon 不监控 Apple Container 主机，告警页面会将它们显示为不支持。

什么算作故障

• 主动操作从不算作意外重启： 通过 Dockerman、Docker CLI 或脚本重启容器；先停止再启动容器；启动一个没有重启策略的已崩溃容器。
• 主动停止会把进行中的事件以“已停止”结束，且不发送恢复通知。在 Docker 上，docker restart 以一次主动停止开始，所以它会把该容器进行中的事件以“已停止”结束。
• 对运行中的容器执行 docker rm -f 会把其事件以“已停止”而不是“已删除”结束，因为强制 kill 先于删除被观测到。
• 重建的容器是一个新实例。 以同名重建的容器从没有事件和冷却历史开始。
• 空闲不等于挂起。 低 CPU 或安静的日志从不算作无响应。响应状态只来自引擎的健康检查或服务探测；两者都没有的容器会在详情页显示“响应状态未知”，并给出启用监控的方法。
• 服务无响应使用引擎自身的健康检查重试次数和启动等待期作为宽限期。可选的最短持续不健康时长（默认无）只在连续观测期间计算：daemon 重启、主机断开或睡眠之后会重新开始。
• 服务无响应事件只有在收到健康报告时才会恢复。 容器必须持续运行，且其健康检查报告正常或服务探测通过，并保持满稳定间隔（默认 60 秒）。仍在运行但依然不健康或仍在启动中，都不算稳定。如果容器最终两者都没有（其服务探测已被移除），则只需保持运行。

服务探测从这台电脑发起

服务探测是针对没有引擎健康检查的容器的 TCP 连接或 HTTP GET（期望 2xx 或 3xx 响应）。它在容器详情页中配置。daemon 从这台电脑发起探测，本地和远程主机都一样。它不会在容器内部运行，也不会通过 SSH 在远程主机上运行。

• 对于远程主机，失败可能意味着服务没有响应，也可能意味着这台电脑无法访问它（网络路径、防火墙、VPN）。
• HTTP 服务探测只是可达性检查：它只读取状态码。它会绕过系统代理（因此测试的是这台电脑自身到服务的路径），不跟随重定向（3xx 视为通过），并接受自签名证书。
• 它只在容器运行时执行。每个检查间隔一次，在检查之前，daemon 会按名称在容器所在主机上查找容器，以获知它是否在运行以及何时启动（用于宽限期）。无法连接主机时不会执行检查。
• 容器启动后的宽限期内的失败不计入。
• Dockerman 失去该主机（其事件流或采样器无法访问它）期间的失败不计入。那是主机断开，而不是服务挂起。主机恢复后，连续失败计数会重新开始。
• 达到配置的连续失败次数后，会打开一个“服务无响应”事件，与引擎健康检查报告不健康时打开的事件相同。一次通过的检查会重置计数。当检查在规则的稳定间隔内持续通过时，事件恢复。
• 默认值：每 30 秒一次，超时 5 秒，连续失败 3 次，启动后宽限 60 秒。全部可以修改。
• 其配置属于主机和容器名称，因此重建容器后依然保留。重建的容器从零开始统计自己的失败次数。
• 移除服务探测会丢弃其结果，即使是在 daemon 未运行时移除也一样。此后，进行中的事件会在容器保持运行满规则的稳定间隔后恢复，除非其引擎健康检查报告不健康。
• 与这里的其他所有内容一样，它只在 daemon 运行且电脑处于唤醒状态时执行。

通知

每条通知都会写明主机、容器、原因、观测到的重启次数和时间窗口或故障持续时间，以及已知的退出码。它从不包含日志文本或环境变量值。系统通知使用 Dockerman 的界面语言；外部渠道收到的是英文文本。

每个事件和告警事件都会记录各个渠道的送达情况：

静音容器或静默时段只会抑制送达：事件仍会打开和结束，被抑制的通知不会补发。

如果状态显示“已交给系统”但系统通知没有出现，通常是系统通知设置中关闭了 Dockerman 的通知（在 macOS 上为 系统设置 > 通知 > Dockerman），或者专注模式或勿扰模式隐藏了它们。Dockerman 无法读取这项权限。点击通知只会把 Dockerman 带到前台。