NAS 出事只会发邮件？群晖 Webhook 把告警直接打进协作群
引言
硬盘降级、存储池失联、备份任务失败——这些事件发生时，DSM 的邮件通知没问题，但邮件在协作时代太慢：没人一直守着收件箱。群晖 DSM 的 Webhook 通知把事件直接推到团队已经在用的通道里，配置入口在控制面板 > 通知设置 > Webhook。提供商覆盖 Synology Chat、Microsoft Teams、LINE、短信与自定义 Webhook 五类，NAS 一有变更，消息直接落进群。
什么场景用它最值
一是值班响应：硬盘或存储池事件需要第一时间在群里被看到，而不是等邮件被翻到。二是多通道冗余：Webhook 与电子邮件、推送服务并列在通知设置下，重要事件多一条腿走路。三是接入自有系统：自定义 Webhook 可把 NAS 事件转发到自有运维平台，或任何提供 Webhook 入口的服务。
操作步骤
-
走一遍标准添加流程。为什么：在「控制面板 > 通知设置 > Webhook」单击「添加」，从提供商下拉列表选择通道类型，从规则下拉列表绑定规则，指定提供商名称（用于区分不同的 Webhook），修改主题（会附加到通知消息的开头），粘贴对应平台的 Webhook URL 后单击应用。名称与主题两个字段决定群里消息的可辨识度，多通道管理就靠它们。
-
先把「规则」想清楚再绑定。为什么：添加时可从规则下拉列表选择规则、或单击「创建」新建——规则决定哪些事件通过此 Webhook 发送通知。通道是路，规则是货：先把事件分级（哪些进群、哪些只留邮件），再回来配通道，顺序反了就要返工。
-
Synology Chat 与 Microsoft Teams 粘 URL 即用。为什么：这两类提供商的配置路径一致——按官方指引到各自平台获取 Webhook URL，复制粘贴到 DSM 单击应用即可。官方在页面里附了获取 URL 的详细说明链接，照文档走不踩坑。
-
自定义 Webhook 对接任意平台。为什么：提供商选「自定义」时，Webhook URL 的格式由应用程序服务提供商定义，消息正文用占位符 @@TEXT@@ 承载——它会被替换为事件消息。HTTP 方法二选一：GET 时设置分隔符字符（默认空格），在参数中保留值为 @@TEXT@@ 的字段，可按 API 文档添加标头；POST 时从 application/json、application/x-www-form-urlencoded、multipart/form-data、text/xml 四种 Content-Type 中选择，JSON 与 XML 还能直接编辑 HTTP 主体模板（系统给出值为 @@TEXT@@ 的参数模板，可按目标平台 API 文档修改字段名称）。团队协作平台只要提供群机器人 Webhook 入口，就能走这条路接入。
-
消息语言与文案可定制。为什么：官方明确两点——Webhook 通知的语言可在「控制面板 > 区域选项 > 语言」中配置；通知消息可在「通知设置 > 事件」里选择事件后单击「编辑消息」修改，未修改则发送默认消息。群内消息面向非技术同事时，改成人话比默认格式传播效率高。
-
配完必发测试消息。为什么：每个配置好的 Webhook 在列表中都可单击「发送测试消息」，官方将其作为检查设置是否正确的手段——URL 抄错一位、主体模板少个字段，测试一发就现形，别等真事件发生才发现通道是哑的。
-
短信作为极端兜底。为什么：提供商列表中的短信通道支持 clickatell、clickatell-2017 和 SendinBlue-v3，可启用发送消息的间隔时间（输入 1 到 10000 之间的值）避免轰炸；用户名、密码、API 密钥、发件人等字段有官方字符上限（用户名 1-128、API 密钥 1-256、发件人 1-64）。网络与协作平台都失联的场景里，短信往往是最后一环。
三条边界先知道
- 规则先行：Webhook 只是通道，发什么、何时发由规则决定，事件分级要在配通道前完成。
- 自定义看协议：GET 与 POST、四种 Content-Type、@@TEXT@@ 占位符，逐项对照目标平台的 API 文档。
- 测试是验收：配完发一条测试消息，通道才算真正上线。
结语
告警的价值在于被看到，而不在于被发送。把 DSM 的事件经 Webhook 直接送进协作群，响应链条从「翻邮件」缩短为「群里看到」。贵州诚鑫致达科技部署企业 NAS 时，会把 Webhook 通道与规则分级一起配置，并用测试消息完成验收，让每一条告警都有人接得住。