企业官网建设流程全解析

Dozzle Cloud 通知渠道（Channels）配置指南：从投递设置到降噪调优

【免费下载链接】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 实例上配置。本文以 docs/guide/dozzle-cloud/channels.md 为核心，完整讲解全部 8 种渠道的配置方法、双向 Agent 能力差异，并结合仓库源码剖析重复告警折叠、静音（mute）机制与dev.dozzle.cloud.min_level源头过滤的底层实现。读完你将能独立完成渠道的启用/禁用、双向问答、降噪调优，并能自主排查"为什么没收到告警"。

渠道与告警规则的分工：先搞清楚你在哪儿配置

渠道只回答"告警去哪里"（where），不回答"什么触发告警"（what）。两者位于完全不同的配置面：

规则定义在自托管实例上，因为你的日志在那里（参见 Alerts 中对 Log/Metric/Event 三类告警及容器表达式的说明）；投递配置在 Cloud 上，因为 Cloud 才持有与手机/聊天工具的长连接（连接方式见 Connecting Your Instance）。如果你在 Cloud 里到处找"当这个容器报错时告诉我"的开关却找不到，原因就在这里——请回到自托管 Dozzle 的 Notifications 页面。

渠道可以任意多开：每个启用状态的渠道都会收到每一条告警，且每个渠道可独立开关。删除告警规则几乎从来不是正确答案——那等于为了消除一行噪音而移除整类监控。

可用渠道一览

所有渠道在所有套餐上均可用，包括免费套餐（各套餐的配额与限制见 Plans & Limits）：

"双向 Agent"意味着你不仅收告警，还能在同一会话里问：支持该能力的渠道（Telegram、Discord Bot）允许你直接向 Agent 提问容器状态，例如"今天有报错吗？""显示 CPU 使用率""我有哪些告警？"并得到基于实时状态的回答。Cloud 侧的 Agent 工具链在仓库 internal/cloud/tools.go 及tools_containers.go、tools_logs.go等文件中实现（如 internal/cloud/tools_containers.go、internal/cloud/tools_logs.go）。

E-mail：零配置，但先查垃圾箱

Email 使用你注册 Cloud 账号时填写的地址自动配置，无需任何设置。停用只需关闭 email 渠道。

如果告警突然收不到，先查垃圾邮件：第一条告警偶尔会被投递到垃圾箱，把它标记为"非垃圾邮件"即可永久解决。这是渠道级最常见的"假故障"。

Telegram：跟着链接按 Start，即可双向问答

在 Channels 页面选择Telegram，点击链接打开官方机器人并按下Start。只要机器人收到过你的消息，渠道即激活。

Telegram 是双向渠道。你可以在同一会话内回复并询问容器相关问题，例如：

• "今天有错误吗？"（any errors today?）
• "显示 CPU 使用率"（show CPU usage）
• "我有哪些告警？"（what alerts do I have?）

Agent 会基于实时状态作答。这一问答能力与 In Your Dozzle 中描述的 Cloud Rail 面板中的 "Ask Dozzle" 属于同一套会话体系。

Discord：两种独立渠道，双开是"每条告警收两遍"的常见原因

Discord 有两种彼此独立的渠道类型，如果两者同时开启，你几乎必然每一条告警都收到两份：

• Discord Bot（私信 DM）——机器人通过私信把告警发给你个人。双向渠道，可以直接向它提问。配置方式：在 Channels 页面授权该机器人。
• Discord Webhook（服务器频道）——告警发布到你服务器上的某个频道（如#alerts）。单向渠道。配置方式：在 Discord 服务器设置中创建一个 Webhook，把 URL 粘贴到 Cloud 的 Discord 渠道里。

如果告警同时出现在你的私信和一个服务器频道，说明两个都配了。关掉不想要的那个即可——关闭一个不影响另一个。常见做法是保留团队共享的服务器频道、关闭个人私信。

Slack：粘贴 Incoming Webhook URL

在 Slack 工作区中创建一个 Incoming Webhook，将生成的 URL 粘贴到 Channels 页面的 Slack 渠道即可。告警将以 Slack 消息形式发布到该 Webhook 关联的频道。

ntfy：填 Topic URL，手机推送无需额外账号

输入你的 topic URL 即可。ntfy.sh公共服务和自托管的 ntfy 服务器都可用。它特别适合不需要额外账号的手机推送场景——ntfy 支持 Android/iOS 客户端直接订阅 topic。

Webhooks：任何接受 POST 的 URL，JSON 载荷

输入任何接受 HTTP POST 的 URL。告警以JSON形式投递，因此你可以把告警路由进任何已有系统：Home Assistant、n8n、自写脚本、其他告警工具。

注意：这是Cloud 渠道，与你自托管 Dozzle 可直接调用的本地 webhook 是两回事。自托管侧的 webhook（含 Go 模板变量{{.Detail}}、{{.Container.Name}}、{{.Log.Message}}、{{.Stat.CPUPercent}}等）配置见 Alerts。

Cloud 告警 JSON 结构可从仓库 internal/cloud/alerts.go 中的AlertHit定义看到端倪：每条命中包含alertId、containerId、hostId、headline、level、eventCount、suppressedCount、containerCount、summary、investigation等字段。值得注意的是eventCount（折叠进本条告警的事件数）与suppressedCount（被抑制、未单独产生通知的事件数）——这正是下文"重复告警已自动合并"的云端数据基础：GetAlerts/GetRecentAlerts从 Cloud 的告警数据库读取这些已聚合的命中记录，而不是逐条返回原始事件。

浏览器推送：桌面通知，注意权限陷阱

在 Channels 页面启用它，并在浏览器弹出授权请求时允许通知，之后告警会以桌面通知形式到达。

启用后仍收不到，最常见原因是浏览器拒绝了权限弹窗。浏览器被拒绝后不会再次询问——需在浏览器设置中清除该站点的通知权限，然后重新启用。另外，浏览器推送在隐私/无痕窗口中不生效。

让告警安静下来：从静音到源头过滤

你只应该在真正重要的时刻被打扰。如果 Cloud 太吵，这是调优问题，有专门工具：

再次强调：删除告警规则几乎从来不是正确答案，它会移除整类监控来修复一行噪音。

静音（Mute）是模式级的

静音按模式生效：它压住的是一整类告警，而不是眼前这一条。后续同类出现保持安静，而任何真正不同的告警仍然会通过。

• 在告警上操作：在 Cloud 中打开该告警，选择静音。
• 在聊天中操作：说"把这个静音"或"别跟我讲 X 了"。Agent 会说出它即将静音的确切模式并等待你确认——因为静音是持久性的，可能掩盖后续真实故障。

静音会一直持续直到你主动解除。问"我静音了什么？"（what have I muted?）即可列出你的静音规则，用同样的方式解除。被静音的告警仍会被记录——静音改变的是"什么会打扰你"，而不是"什么被监控"。静音规则查询与解除在 Cloud 侧由 Agent 工具实现，测试见 internal/cloud/tools_notifications_test.go（其中[Mm]ute相关用例覆盖了静音规则的读写行为）。

少一点，而不是全关

如果某条告警确实有用但太频繁，点拇指朝下（thumbs down）而不是静音它。这是"继续盯着，但少烦我"的信号。同理，对判断准确的告警点拇指朝上（thumbs up）也能以相同方式优化投放频次。

重复告警已经被合并了

在静音之前，先确认问题是不是"重复"本身。同一故障的重复发生会被折叠进同一条告警并带上计数——例如容器退出 40 次，产生的是一条写着"40"的告警（源码侧体现为AlertHit.EventCount，见 internal/cloud/alerts.go）。如果你收到大量告警，通常是大量不同的问题；或者你已经超出套餐的事件配额，告警退化为"原始、未分组"模式（详见 Plans & Limits——超限后约每十条事件才出一条 raw 告警且不再折叠）。

从源头过滤：dev.dozzle.cloud.min_level

对于正常运行时就话很多的容器，更好的修复在上游：dev.dozzle.cloud.min_level标签阻止低严重级别的日志行离开你的宿主机。这个标签在仓库 internal/cloud/log_streamer.go 中定义并解析：

const cloudMinLevelLabel = "dev.dozzle.cloud.min_level" var cloudLevelRank = map[string]int{ "trace": 1, "debug": 2, "info": 3, "warn": 4, "error": 5, "fatal": 6, }

其取值语义（详见 Your Data）：

配置示例（docker-compose）：

services: zigbee2mqtt: image: koenkk/zigbee2mqtt labels: # 只向 Dozzle Cloud 转发 warn/error/fatal - dev.dozzle.cloud.min_level=warn noisy-debug-tool: image: example/debug labels: # 该容器不发送任何数据 - dev.dozzle.cloud.min_level=disabled

由 internal/cloud/log_streamer.go 中的parseMinLevel实现可见：无法识别的值（如拼错的warning、wran）会被记为错误并忽略，容器将按未设置标签全量转发；标签在日志读取器启动时读取，因此对运行中的容器修改标签需重启容器后生效。过滤发生在你的 Dozzle 实例上、日志离开宿主机之前——被丢弃的行从不触碰网络，也不计入套餐配额，且完全不影响 Dozzle 本地日志查看。

为什么我没收到告警？八步排查清单

按顺序逐一检查：

1. 有对应的规则吗？日志里的错误本身不会产生告警，必须有人盯着它。默认规则只覆盖"以错误状态退出的容器"；一个持续运行却不断记错误的容器需要一条log 规则（参见 Alerts 的 Log Alerts 一节）。
2. 有渠道处于启用状态吗？规则没有启用渠道就等于无处投递。
3. 实例在线吗？如果问题发生时实例离线，则没有任何数据被转发（见 Connecting Your Instance——连接是实例发起的出站长连接，无需公网 IP、开放端口或域名）。
4. 是不是被合并进你已经收到的那条告警了？四十次失败产生一条写着"四十"的告警。这是设计使然，不是漏报。
5. 你静音它了吗？检查你的静音规则。
6. 该容器被排除转发了吗？检查dev.dozzle.cloud.min_level标签是否为disabled（见 Your Data）。
7. 超出套餐限额了吗？超过配额后投递方式改变，告警被抽样（见 Plans & Limits）。
8. 查垃圾邮件——尤其是 Email 渠道。

小结：渠道配置的三个要点

• 职责分离：触发规则在自托管实例（Alerts），投递渠道在 Cloud（Channels），历史/静音/升级在 Cloud。
• 按需静音而非删规则：静音是模式级的且持久，重复告警已被EventCount折叠，从源头用dev.dozzle.cloud.min_level过滤比事后处理更高效。
• 双向 Agent 只在 Telegram 与 Discord Bot：其余渠道为单向投递；告警 JSON 载荷可被 Webhook 路由进任意系统。

【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle