# 在可观测体系中的位置

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

最后校对于 2026-10-10

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

## 六层里，夜莺占中间三层[​](#六层里夜莺占中间三层 "六层里，夜莺占中间三层的直接链接")

第 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`， 规则判定在本地完成，断网期间照常告警。见[边缘机房](https://n9e.github.io/zh/docs/install/edge.md)。

下一步：[选一条路进来](https://n9e.github.io/zh/docs/get-started/choose-your-path/existing-metrics.md)。