系统架构
夜莺的核心是一个 n9e 进程：测试零依赖，生产加 MySQL 和 Redis，多实例共享同一套库即为集群，多机房用 n9e-edge。
进程与角色
绝大多数部署只需要 n9e 一个进程；n9e-alert、n9e-pushgw 是可拆出的角色，n9e-edge 给多机房用，Categraf 在采集侧。
存储
夜莺自带一个时序库让你零依赖起步；这页讲它的边界，以及什么时候必须换成 Prometheus 或 VictoriaMetrics。
业务组
业务组是权限边界：规则、对象、仪表盘都归属某个业务组，成员关系决定谁能看、谁能改。
核心对象模型
整个产品挂在三个对象上：规则查询数据源，越界的规则产生事件。
生命周期与级别
告警事件由规则 + 标签集唯一标识，经历触发、持续、恢复三个阶段；S1 / S2 / S3 不改变机制，只告诉收到的人有多急。
标签与注解
标签决定一个事件「是谁」，注解决定通知里能看到什么，两者不能混用。
判定与恢复
规则不是查到就报：评估周期、持续时长、恢复条件三个参数加一套状态机，决定事件何时首次触发、何时恢复、会不会抖动。
降噪与路由模型
屏蔽规则、订阅、事件 Pipeline、通知规则不是并列的备选，而是按固定先后作用于事件；搞错顺序就会出现配了屏蔽仍收到告警。
认证与权限模型
权限只有两层：角色决定能进哪些页面、调哪些接口，业务组成员关系决定能动哪些数据；界面、HTTP API 和 MCP 共用这一套。