Dozzle Cloud 通知渠道完全指南：邮件、Telegram、Discord、Slack、ntfy、Webhook 与浏览器推送
【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle
Dozzle Cloud 的通知渠道（Channels）决定了告警发往哪里：邮件、Telegram、Discord、Slack、ntfy、Webhook 或浏览器推送；而告警由什么触发则在你的自托管 Dozzle 实例上配置。读完本文，你将掌握 Dozzle Cloud 全部八类通知渠道的配置方法、双向 Agent 的使用方式，以及一套把告警噪音降到最低的"降噪工具箱"和"为什么没收到告警"的排查清单。
本文依据仓库文档 docs/es/guide/dozzle-cloud/channels.md（英文原版见 docs/guide/dozzle-cloud/channels.md）编写，并结合仓库源码验证了标签解析、告警投递与熔断等底层机制。
渠道与规则的分工：一个在 Cloud，一个在你的实例
首先必须厘清一个最容易搞混的概念：
- 渠道（Channels）配置在 Dozzle Cloud，控制告警被投递到哪里（a dónde）；
- 触发条件（Alerts）配置在你的自托管实例上，控制告警何时产生（qué las dispara），详见 Alerts。
这种分工的原因很直接：日志在你的实例上，所以匹配日志的规则必须定义在本地；而 Cloud 持有与你手机之间的长连接，所以投递地址配置在 Cloud。规则定义在哪、渠道配置在哪，参见 Vincular tu instancia 中的对照表。
渠道的开关彼此独立，你可以同时启用任意多个——每个已启用的渠道都会收到每一条告警，也可以单独关闭其中任意一个。这一设计在 Cloud 的 Channels 页面上一目了然。
可用渠道总览
| 渠道 | 告警 | 每日摘要 | 双向 Agent |
|---|---|---|---|
| 邮件（Email） | ✓ | ✓ | |
| Telegram | ✓ | ✓ | ✓ |
| Discord Bot（私信 DM） | ✓ | ✓ | ✓ |
| Discord Webhook（服务器频道） | ✓ | ✓ | |
| Slack | ✓ | ||
| ntfy | ✓ | ||
| Webhooks（通用） | ✓ | ||
| 浏览器推送（Browser Push） | ✓ |
所有渠道在所有套餐中均可用，包括免费套餐。这与 Plans & Limits 中"智能告警、重复折叠、抑制、所有通知渠道、容器操作与无限 MCP 访问在所有套餐上可用"的说明一致。
各渠道配置详解
邮件（Email）
邮件渠道会用你注册 Cloud 时使用的地址自动配置好，无需任何手工设置。停止接收的唯一动作是禁用邮件渠道。
有一个值得记住的坑：如果告警莫名不再到达，先检查垃圾邮件文件夹——第一条告警偶尔会落入其中，将其标记为"非垃圾邮件"即可永久修复。
Telegram（双向渠道）
配置 Telegram 只需三步：
- 在 Channels 页面选择Telegram；
- 点击链接打开机器人；
- 按下Start。
一旦机器人收到你的消息，渠道即被激活。
Telegram 是**双向（bidireccional）**渠道：你可以在同一聊天中直接提问，例如"今天有错误吗？"（¿ha habido errores hoy?）、"给我看下 CPU 使用率"（enséñame el uso de CPU）、"我有哪些告警？"（¿qué alertas tengo?），Agent 会基于实时状态回答。双向能力在底层实现上依赖 Dozzle 实例向 Cloud 建立的长连接工具流（Tool Stream）：Cloud 通过 gRPC 把工具请求（如fetch_logs、find_containers、inspect）下发给你的实例，实例执行后把结果回传，因此聊天中的提问能覆盖你所有已连接的实例。
Discord：两种渠道，谨防重复告警
Discord 有两种完全不同的渠道类型，同时启用两者是"每条告警收到两遍"的最常见原因：
- Discord Bot（私信 DM）——机器人以私信方式把告警发给你个人。这是双向渠道，可以直接向它提问。配置方式：在 Channels 页面授权该 Bot。
- Discord Webhook（服务器频道）——告警发布到你服务器上的某个频道，例如
#alerts。这是单向渠道。配置方式：在你的 Discord 服务器设置中创建 webhook，把 URL 粘贴到 Cloud。
如果你既收到 DM 又收到服务器频道消息，说明两个渠道都被启用了：关掉不想要的那个即可，关闭一个不影响另一个。常见做法是保留共享的服务器频道、关掉 DM。
从仓库看，Discord webhook 的负载格式在 payloadTemplates.ts 中由内置模板生成——使用 Discord webhook API 兼容的content+embeds结构（title、description、fields 中带 Host 与 Image）。
Slack
在 Slack 工作区中创建一个 Incoming Webhook，然后把 URL 粘贴到 Channels 页面的 Slack 渠道中即可。Slack 渠道同样由 payloadTemplates.ts 提供内置负载模板：采用 Slack 的 blocks + mrkdwn 格式（section文本块展示容器名与详情，context元素展示 Host 与 Image 信息）。
ntfy
在 ntfy 渠道中输入你的topic URL即可。ntfy.sh 公共服务和自托管的 ntfy 服务器都支持。ntfy 特别适合在没有额外账号的情况下直接把通知推送到手机。
同样，payloadTemplates.ts 为 ntfy 内置了负载模板（topic、title、message字段），其中 topic 默认形如dozzle-{{ .Container.HostName }}。
Webhooks（通用）
输入任何接受 POST 请求的 URL。告警以 JSON 格式投递，因此你可以把它接入任何已有系统：Home Assistant、n8n、自写脚本或其他告警工具。
[!NOTE] 这是Cloud 渠道，与你自托管 Dozzle 可以直接调用的 webhook 是两回事。自托管实例直调的 webhook 及其 Go 模板变量，见 Alerts。
从实现上看，告警从你的实例到 Cloud 的投递由 internal/notification/dispatcher/cloud.go 中的CloudDispatcher完成：它把通知序列化为 JSON，向 Cloud 的/api/events端点（默认https://doligence.dozzle.dev，可用环境变量DOLIGENCE_URL覆盖）发起POST，并在请求头携带X-API-Key认证。投递带 10 秒超时，并实现了熔断器：
- 收到
429 Too Many Requests时，按响应的Retry-After头退避（默认 60 秒）； - 收到
401/403（API Key 无效或过期）时，熔断长达 6 小时——因为重试无益，直到你修复 Key 并重建 dispatcher； - 熔断期内直接跳过云端请求并记录日志，避免无效重试。
这就是"渠道配置在 Cloud，投递连接由实例主动发起"的源码级印证。
浏览器推送（Browser Push）
在 Channels 页面启用浏览器推送渠道，并在浏览器询问时允许通知，告警就会以桌面通知的形式到达。
如果启用后什么都没有：最可能是浏览器拒绝了权限弹窗。浏览器一旦被拒绝就不会再次询问——需要到浏览器设置中清除该站点的通知权限，然后重新启用。另外，浏览器推送在隐私窗口 / 无痕窗口中不工作。
让告警安静下来：降噪工具箱
"只有当事情真正重要时才应该被打扰。如果 Cloud 太吵，那是配置问题，而不是产品问题。"针对不同场景，官方给出了这样一张对照表：
| 场景 | 该做什么 |
|---|---|
| 一个已知的反复出现的错误 | 静音该模式（Silencia el patrón） |
| 告警有用但过于频繁 | 点一下"踩"（pulgar hacia abajo） |
| 计划内维护、备份、升级 | 开始前先静音该模式 |
| 告警正确但发错了应用 | 禁用那个渠道 |
| 什么也不想要、任何来源都不要 | 禁用所有渠道 |
删除告警规则几乎从来不是正确答案——那是为了解决一行烦人的日志而删掉一整类监控。
按模式静音：静音的是"这一类"告警
静音是**基于模式（por patrón）**的：它让"这一种告警"安静下来，而不是只消音当前这一条。之后同类的出现保持安静，而真正不同的内容依然会送达。
- 从某条告警静音——在 Cloud 中打开该告警，选择静音；
- 在聊天中静音——直接说"静音这个"或"别再用 X 打扰我了"。Agent 会先复述它将要静音的确切模式并等待你的确认——因为一次静音是持久的，可能在未来掩盖一次真实故障。
静音持续到你主动撤销为止。可以问"我静音了什么？"（¿qué he silenciado?）来列出静音规则，同样方式撤销。被静音的告警仍会被记录：静音改变的是"什么会打扰你"，而不是"什么被监控"。
更少，而不是没有：用"踩"而非静音
如果一条告警确实有用但来得太频繁，给它点"踩"（pulgar hacia abajo），而不是静音。这传递的信号是"继续盯着它，但少打扰我"。反过来，对判断准确的告警点"赞"也有同样的调节作用。
重复告警已被聚合
静音之前，先确认问题是不是"重复"。同一故障的多次出现会被折叠进同一条告警并带计数——40 次崩溃产生一条写着"40"的告警。如果你收到大量告警，通常是大量不同的问题，或者你已经超出了套餐的事件额度，告警退化成了未聚合的原始模式。参见 Plans & Limits。
这个"折叠"行为在 Dozzle Cloud 的功能描述中有明确说明："47 次崩溃到达时是一条写着 47 的告警"，并且容器恢复时会收到恢复通知。
在源头过滤：dev.dozzle.cloud.min_level标签
对于正常运行期间本身就吵闹的容器，更好的修复在更上游：dev.dozzle.cloud.min_level标签可以阻止低严重级别的日志行离开你的主机。详见 Tus datos。
源码实现位于 internal/cloud/log_streamer.go：
- 严重级别排名（
cloudLevelRank）为：trace=1、debug=2、info=3、warn=4、error=5、fatal=6； - 值
disabled表示完全跳过该容器，不向 Cloud 转发任何日志； - 值为
trace时与未设置等效（trace 是最低级别，全部转发）； - 值为
debug/info/warn/error/fatal时，只转发该级别及以上的行；未检测出级别的行始终放行； - 无法识别的值（比如拼错的
warning或wran）会被记录为错误并忽略，容器按未设置标签处理（全部转发）； - 标签在日志读取器启动时读取，运行中的容器修改标签后，重启容器才生效。
示例（来自 your-data.md）：
services: zigbee2mqtt: image: koenkk/zigbee2mqtt labels: # 只把 warn/error/fatal 转发给 Dozzle Cloud - dev.dozzle.cloud.min_level=warn noisy-debug-tool: image: example/debug labels: # 完全不发送该容器的任何内容 - dev.dozzle.cloud.min_level=disabled这个过滤发生在你的 Dozzle 实例上、日志离开主机之前，被丢弃的行不会触网，也不计入套餐额度；本地日志查看不受影响。
为什么我没收到告警？八步排查
来自 Cloud 的官方排查清单，按顺序依次检查：
- 存在针对它的规则吗？日志里出现错误本身不会产生告警——必须有什么东西在"盯着"它。默认规则只覆盖以错误状态退出的容器；一个持续运行但不断记录错误的容器，需要一条 log 规则。
- 有启用任何渠道吗？没有已启用渠道的规则无处投递。
- 实例已连接吗？如果问题发生时实例处于离线状态，就不会转发任何内容。参见 Vincular tu instancia。
- 它是否被聚合进你已收到的一条告警？40 次失败产生一条写着"40"的告警，这是预期行为，不是漏报。
- 你静音它了吗？检查你的静音规则。
- 容器被排除转发了吗？检查容器标签（
dev.dozzle.cloud.min_level=disabled的容器按设计不发送任何内容）。参见 Tus datos。 - 超出套餐限额了吗？超出额度后投递行为改变，告警被抽样。参见 Plans & Limits。
- 检查垃圾邮件文件夹——这专门针对邮件渠道。
告警规则本身：三类型与默认参数
既然渠道只负责"投递到哪"，补充说明一下"何时触发"这部分，便于你理解两者如何衔接。告警规则配置在你的自托管实例上（详见 Alerts），支持三种类型，均从Notifications页面配置：
| 类型 | 触发条件 | 典型用例 |
|---|---|---|
| Log | 日志消息匹配模式 | 5xx 错误、堆栈跟踪 |
| Metric | CPU / 内存超过阈值 | 容器 CPU 超过 90% |
| Event | Docker 容器生命周期事件 | OOM 杀掉、容器不健康 |
每条规则把容器表达式（监控哪些容器）与触发表达式（满足什么条件才触发）配对。如果你在 Cloud 的聊天/Agent 中创建规则，底层走的是 internal/cloud/tools.go 中定义的 MCP 工具（create_log_notification、create_metric_notification、create_event_notification等），其参数默认值如下：
- 容器表达式使用 expr-lang 语法，可用字段包括
name、id、image、state、health、host、labels； - log 表达式对每一行日志求值，字段包括
message、level、stream、type、timestamp、id，JSON 日志可通过message.<key>访问解析后的字段； - metric 表达式字段为
cpu（0-100 百分比）、memory（百分比）、memoryUsage（字节），cooldown_seconds默认300 秒，sample_window_seconds默认15 秒； - event 表达式针对生命周期事件求值，事件名如
start、stop、die、restart、kill、oom、health_status等。
重要的是：通过 Cloud 渠道创建的告警规则也会路由回 CloudDispatcher——internal/cloud/tools_notifications.go 中保留了一个专门的 dispatcher ID（cloudDispatcherID = 0），所有经 Cloud 工具创建的告警都指向它，这样你就能通过已配置的 Cloud 渠道（Telegram、Discord 等）收到告警。这也解释了为什么"在 Cloud 里找不到'告诉我这个容器出错时通知我'的地方"——规则定义在自托管实例，投递在 Cloud。
小结
Dozzle Cloud 的通知体系把"监控什么"与"发到哪"彻底解耦：规则在自托管实例上按容器/日志/指标/事件四类表达式求值，渠道在 Cloud 上负责把告警投递到邮件、Telegram、Discord、Slack、ntfy、Webhook 或浏览器推送。免费套餐即可使用全部渠道；Telegram 与 Discord Bot 还支持双向 Agent，可以在聊天中直接查询容器状态。当告警太吵时，优先级依次是：源头用dev.dozzle.cloud.min_level过滤 → 对误报点"踩" → 对已知模式静音 → 禁用整条渠道——而不是删除规则。最后，任何"没收到告警"的问题，都可以对照八步排查清单逐项定位。
【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
