Dozzle Cloud 通知渠道完全指南邮件、Telegram、Discord、Slack、ntfy、Webhook 与浏览器推送【免费下载链接】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 实例上配置。读完本文你将掌握 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 StreamCloud 通过 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 兼容的contentembeds结构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/403API 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为trace1、debug2、info3、warn4、error5、fatal6值disabled表示完全跳过该容器不向 Cloud 转发任何日志值为trace时与未设置等效trace 是最低级别全部转发值为debug/info/warn/error/fatal时只转发该级别及以上的行未检测出级别的行始终放行无法识别的值比如拼错的warning或wran会被记录为错误并忽略容器按未设置标签处理全部转发标签在日志读取器启动时读取运行中的容器修改标签后重启容器才生效。示例来自 your-data.mdservices: zigbee2mqtt: image: koenkk/zigbee2mqtt labels: # 只把 warn/error/fatal 转发给 Dozzle Cloud - dev.dozzle.cloud.min_levelwarn noisy-debug-tool: image: example/debug labels: # 完全不发送该容器的任何内容 - dev.dozzle.cloud.min_leveldisabled这个过滤发生在你的 Dozzle 实例上、日志离开主机之前被丢弃的行不会触网也不计入套餐额度本地日志查看不受影响。为什么我没收到告警八步排查来自 Cloud 的官方排查清单按顺序依次检查存在针对它的规则吗日志里出现错误本身不会产生告警——必须有什么东西在盯着它。默认规则只覆盖以错误状态退出的容器一个持续运行但不断记录错误的容器需要一条 log 规则。有启用任何渠道吗没有已启用渠道的规则无处投递。实例已连接吗如果问题发生时实例处于离线状态就不会转发任何内容。参见 Vincular tu instancia。它是否被聚合进你已收到的一条告警40 次失败产生一条写着40的告警这是预期行为不是漏报。你静音它了吗检查你的静音规则。容器被排除转发了吗检查容器标签dev.dozzle.cloud.min_leveldisabled的容器按设计不发送任何内容。参见 Tus datos。超出套餐限额了吗超出额度后投递行为改变告警被抽样。参见 Plans Limits。检查垃圾邮件文件夹——这专门针对邮件渠道。告警规则本身三类型与默认参数既然渠道只负责投递到哪补充说明一下何时触发这部分便于你理解两者如何衔接。告警规则配置在你的自托管实例上详见 Alerts支持三种类型均从Notifications页面配置类型触发条件典型用例Log日志消息匹配模式5xx 错误、堆栈跟踪MetricCPU / 内存超过阈值容器 CPU 超过 90%EventDocker 容器生命周期事件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、labelslog 表达式对每一行日志求值字段包括message、level、stream、type、timestamp、idJSON 日志可通过message.key访问解析后的字段metric 表达式字段为cpu0-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 IDcloudDispatcherID 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），仅供参考