Dozzle Cloud 通知渠道Channels配置指南从投递设置到降噪调优【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle Cloud 的通知渠道Channels决定了容器告警最终送达哪里——邮箱、Telegram、Discord、Slack、ntfy、Webhook 还是浏览器桌面通知而告警由什么触发则在你的自托管 Dozzle 实例上配置。本文以 docs/guide/dozzle-cloud/channels.md 为核心完整讲解全部 8 种渠道的配置方法、双向 Agent 能力差异并结合仓库源码剖析重复告警折叠、静音mute机制与dev.dozzle.cloud.min_level源头过滤的底层实现。读完你将能独立完成渠道的启用/禁用、双向问答、降噪调优并能自主排查为什么没收到告警。渠道与告警规则的分工先搞清楚你在哪儿配置渠道只回答告警去哪里where不回答什么触发告警what。两者位于完全不同的配置面你要改的东西在哪里改什么触发告警——容器、匹配模式、阈值自托管 Dozzle → Alerts告警投递到哪里——Email、Telegram、Slack……Dozzle Cloud → Channels回顾历史告警、静音、升级套餐Dozzle Cloud规则定义在自托管实例上因为你的日志在那里参见 Alerts 中对 Log/Metric/Event 三类告警及容器表达式的说明投递配置在 Cloud 上因为 Cloud 才持有与手机/聊天工具的长连接连接方式见 Connecting Your Instance。如果你在 Cloud 里到处找当这个容器报错时告诉我的开关却找不到原因就在这里——请回到自托管 Dozzle 的 Notifications 页面。渠道可以任意多开每个启用状态的渠道都会收到每一条告警且每个渠道可独立开关。删除告警规则几乎从来不是正确答案——那等于为了消除一行噪音而移除整类监控。可用渠道一览所有渠道在所有套餐上均可用包括免费套餐各套餐的配额与限制见 Plans Limits渠道告警每日摘要双向 AgentEmail✓✓Telegram✓✓✓Discord Bot私信✓✓✓Discord Webhook服务器频道✓✓Slack✓ntfy✓Webhooks✓浏览器推送Browser push✓双向 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 的 URLJSON 载荷输入任何接受 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 太吵这是调优问题有专门工具场景做法一条你已知晓的反复出现的错误静音该模式pattern告警有用但太频繁点一个拇指朝下thumbs down计划内维护、备份、升级开始前先静音该模式告警正确但应用不对禁用那个渠道完全不想要任何告警禁用所有渠道再次强调删除告警规则几乎从来不是正确答案它会移除整类监控来修复一行噪音。静音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值效果未设置转发所有日志行。默认。disabled完全跳过该容器不向 Cloud 转发任何日志。trace与未设置相同trace 是最低级别全部转发。debug/info/warn/error/fatal仅转发该级别及以上的行无法识别级别的行始终放行。配置示例docker-composeservices: zigbee2mqtt: image: koenkk/zigbee2mqtt labels: # 只向 Dozzle Cloud 转发 warn/error/fatal - dev.dozzle.cloud.min_levelwarn noisy-debug-tool: image: example/debug labels: # 该容器不发送任何数据 - dev.dozzle.cloud.min_leveldisabled由 internal/cloud/log_streamer.go 中的parseMinLevel实现可见无法识别的值如拼错的warning、wran会被记为错误并忽略容器将按未设置标签全量转发标签在日志读取器启动时读取因此对运行中的容器修改标签需重启容器后生效。过滤发生在你的 Dozzle 实例上、日志离开宿主机之前——被丢弃的行从不触碰网络也不计入套餐配额且完全不影响 Dozzle 本地日志查看。为什么我没收到告警八步排查清单按顺序逐一检查有对应的规则吗日志里的错误本身不会产生告警必须有人盯着它。默认规则只覆盖以错误状态退出的容器一个持续运行却不断记错误的容器需要一条log 规则参见 Alerts 的 Log Alerts 一节。有渠道处于启用状态吗规则没有启用渠道就等于无处投递。实例在线吗如果问题发生时实例离线则没有任何数据被转发见 Connecting Your Instance——连接是实例发起的出站长连接无需公网 IP、开放端口或域名。是不是被合并进你已经收到的那条告警了四十次失败产生一条写着四十的告警。这是设计使然不是漏报。你静音它了吗检查你的静音规则。该容器被排除转发了吗检查dev.dozzle.cloud.min_level标签是否为disabled见 Your Data。超出套餐限额了吗超过配额后投递方式改变告警被抽样见 Plans Limits。查垃圾邮件——尤其是 Email 渠道。小结渠道配置的三个要点职责分离触发规则在自托管实例Alerts投递渠道在 CloudChannels历史/静音/升级在 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考