谁在什么时候动了哪台机：群晖 CMS 日志页给机队操作留台账
引言
十台 NAS 用 CMS 集中管理之后，效率是上去了，但一个新的问题跟着来：所有变更动作都发生在 CMS 主机这一个界面里，一旦某台分支机器的套件半夜被更新、某条策略被人改了口径，想知道「谁在什么时候干的」，逐台翻日志等于大海捞针。CMS 的「日志」页就是为这个场景准备的台账：按官方帮助，它显示 CMS 主机日志和服务器通知，提供搜索、过滤、导出和清除选项；主机日志记录服务器增减、DSM 与套件更新、群组和策略变更、任务执行四类事件，服务器通知则把各托管服务器触发的通知汇总到一处。这篇把台账的读法和管法走一遍。
什么场景用它最值
一是变更审计：机队环境出问题要回溯「最近改过什么」，主机日志按时间线给出四类事件的完整记录。二是告警聚合：分支机器的通知不用逐台登录查看，汇到 CMS 日志页统一过目。三是权限交接：管理员离岗交接时，导出一段时期的日志作为操作历史移交，责任边界清楚。
操作步骤
-
进入 CMS 的「日志」页，先分清两张选项卡：主机日志记录发生在 CMS 主机上的管理动作，服务器通知汇总托管服务器触发的通知。为什么：两份记录的视角不同——前者是「谁通过 CMS 做了什么」，后者是「各台机器自己报了什么」；排障时先定性质，是人为变更引发的问题就查主机日志，是机器自身状态引发的问题就查服务器通知，顺序反了会白忙。
-
把主机日志当变更台账读，按四类事件对号：与服务器相关的日志（如添加或脱离服务器）、与 DSM 和套件更新相关的日志（如在服务器上安装或更新套件）、与群组和策略相关的日志（如创建、编辑或移除策略或群组）、与任务相关的日志（如运行任务、取消任务或导入脚本）。为什么：这四类正好覆盖机队管理的全部变更面——成员变动、版本变动、配置口径、批量动作；问题回溯时按类别缩小范围，比线性翻页快得多。
-
要让服务器通知真正汇过来，先去「策略 > 编辑 > 配置规则 > 通知 > CMS」启用「向 CMS 主机发送通知」。为什么：这是个默认不生效的开关——通知聚合的前提是策略里明确开了这条路；托管服务器数量多时更值得开，等于把散在各机的告警收进一个收件箱，巡检从「挨台看」变成「一处看」。
-
定期用「导出」把日志落档：单击导出按钮，可选 HTML 或 CSV 格式保存到本地设备。为什么：台账的价值在于可追溯、可移交——CSV 便于二次筛选和长期归档，HTML 适合直接作为附件放进事件报告；机队管理动作留档的周期建议与内控要求对齐，别依赖线上记录永久存在。
-
清除动作交给管理员并形成规矩：只有属于 administrators 群组的用户能查看或删除所有主机日志和服务器通知，「全部清除」按钮对一般用户禁用。为什么：日志既是审计工具，本身也需要被管理——清除权限收在管理员手里是官方的设计，团队内部再把「清除前先导出存档」写进流程，台账的可信度才有制度支撑。
-
一般用户按委派范围看日志：未被委派管理权限的机器，其日志与通知对一般用户不可见。为什么：分支管理员只看自己那几台机器的操作记录，总部视角才看全网——权限边界与日志可见范围天然对齐，交接和分责时不会出现「看到不该看的」或「该看的看不到」。
三条边界先知道
- 语言跟系统走：日志和通知的显示语言基于系统显示语言——多语言团队读台账时留意同一事件的呈现差异，导出归档建议统一系统语言口径。
- 清除不可逆：全部清掉之后线上就没了，清除前导出存档应作为硬性前置动作。
- 通知聚合要先开：不在策略里启用「向 CMS 主机发送通知」，服务器通知选项卡就是空的——别把「没通知」误读成「没问题」。
结语
集中管理把十台机器的动作收进一个界面，日志页则把这些动作变成可追溯的记录：谁加了服务器、谁更新了套件、哪条策略几点被改、哪个任务半夜跑过，四类事件一查便知。贵州诚鑫致达科技在为客户部署多机集中管理时，会把 CMS 日志的导出归档周期和清除审批写进运维手册——台账制度立住了，集中管理的效率优势才不会以责任模糊为代价。