在可观测体系中的位置

六层可观测栈里，夜莺负责中间的规则、降噪和路由送达；采集、存储和 Grafana 可视化继续用现有的。

看完这页，你能判断夜莺该放在你现有技术栈的哪个位置，以及哪些组件不用换。

六层里，夜莺占中间三层

第 1 层和第 2 层夜莺不接管：你的采集器继续跑，你的时序库继续存。第 6 层夜莺只负责发出去，不做排班和升级（那是 PagerDuty、FlashDuty 这类值班平台的活，夜莺可以把事件交给它们）。

你现在在用	接入夜莺之后
Prometheus / VictoriaMetrics / Thanos / Mimir	注册成数据源，抓取配置一行不改
ElasticSearch / OpenSearch / Loki / VictoriaLogs	注册成数据源，用同一套规则体系做日志告警
MySQL / PostgreSQL / ClickHouse / TDengine	注册成数据源，让规则直接跑 SQL
Grafana	继续看图。夜莺自带仪表盘，但不要求你搬走
node_exporter 等各类 exporter	继续被你的 Prometheus 抓，夜莺查 Prometheus
Alertmanager	这一层会被替掉——规则、静默、路由、接收器都搬成夜莺的对象

唯一真正重叠的是 Alertmanager 和各家时序库自带的告警功能。夜莺想替掉的就是这一层。

夜莺自带一个时序库（默认开启），让你不装任何外部组件就能跑通全流程。它存在的意义是「开箱即用」，不是「又一个时序库」：数据落在单个 Center 进程的本地磁盘上，多副本部署时每个副本只有一部分数据。

小规模（约 10 万活跃序列以内）可以一直用；再往上就该关掉它，把 Pushgw.Writers 指向外部时序库。两者可以同时开着做双写，方便平滑迁移。

数据不流经夜莺：你自己搞定采集和存储，夜莺只查询。机器列表会是空的，故障自愈用不了，但告警规则完全可用。
数据流经夜莺：Categraf 用 remote write 把数据推给夜莺，夜莺不自己存，按 Pushgw.Writers 的配置转发给一个或多个时序库。机器列表、故障自愈都能用。
边缘下沉：边缘机房和中心网络不可靠时，在边缘部署 n9e-edge，规则判定在本地完成，断网期间照常告警。见边缘机房。