系统架构
夜莺的核心是一个 n9e 进程：测试零依赖，生产加 MySQL 和 Redis，多实例共享同一套库即为集群，多机房用 n9e-edge。
夜莺的架构不复杂：核心就一个 n9e 进程。测试时它可以什么都不依赖地跑起来，
上生产才需要 MySQL 和 Redis。多机房网络不好的场景另有一套边缘模式。
一个进程能干的事
┌──────────────────────────── n9e ────────────────────────────┐
│ Web / API 告警判定引擎 Pushgw 写入 通知发送 MCP/A2A │
└──┬───────────────┬──────────────┬────────────────┬──────────┘
│ │ │ │
浏览器 / API 数据源 时序库 通知媒介
Prometheus 等 （可外置，也可用内置） 钉钉 / 飞书 / …
│
MySQL + Redis
（元数据与协调）
n9e 进程只依赖二进制同级目录下的 etc/ 和 integrations/ 两个目录，别的服务都不是必需的。
三种规模
单机测试
下载发布包，./n9e 直接跑，端口 17000，账号 root / root.2020。
这种模式下元数据存在同级目录的 n9e.db（SQLite），Redis 用进程内的 miniredis，
指标存在内置时序库里。方便，但不要用于生产——见上生产前的检查清单。
单机生产
改 etc/config.toml，把元数据换到 MySQL 或 PostgreSQL，Redis 换成真的：
[DB]
DBType = "mysql"
DSN = "root:<password>@tcp(localhost:3306)/n9e_v6?charset=utf8mb4&parseTime=True&loc=Local"
[Redis]
RedisType = "standalone"
Address = "127.0.0.1:6379"
库名习惯叫 n9e_v6，从 v6 版本沿用至今，建表语句里也是这个名字。
集群
多台机器各跑一个 n9e，配置文件完全一致，共享同一套 MySQL 和 Redis，就是集群了。
告警规则会自动在实例之间分派：100 条规则、2 个实例，大约各跑 50 条， 一条规则只在一个实例上运行，不会重复告警。某个实例挂掉，它的规则会被另一个接管。
注意：集群模式下必须关掉内置时序库。它的数据在单个进程的本地磁盘上， 多实例时每个实例只有一部分数据。
数据流经不流经夜莺
这是两种截然不同的接法，决定了你能用到哪些功能。
| 数据不流经夜莺 | 数据流经夜莺 | |
|---|---|---|
| 采集 | 你自己的 Prometheus 抓 | Categraf 用 remote write 推给夜莺 |
| 夜莺做什么 | 只查询时序库 | 接收后按 Pushgw.Writers 转存 |
| 设备列表 | 空的 | 有机器，能分组、打标签 |
| 故障自愈 | 用不了 | 可用 |
| 告警规则 | 完全可用 | 完全可用 |
夜莺自己不长期存储指标（内置时序库是开箱即用的例外，见存储）。
边缘模式
多机房场景下，如果让中心的 n9e 去查边缘机房的时序库，网络一抖告警就不可靠，
严重时中心根本连不通边缘的时序库。
这时在边缘机房部署 n9e-edge：规则配置仍然在中心统一管理并下发，
但判定在边缘本地完成，查的是边缘自己的时序库。中心和边缘断开时，边缘照常告警。
详见边缘机房。