这将是一个系列，讲解 夜莺监控 的设计思考。你可以把它理解为：原理、最佳实践和产品设计时的折中取舍。
本系列其他文章：
本篇主要回答两个问题：
- 夜莺和时序库对接的设计逻辑。
- 夜莺和 agent 对接的设计逻辑。
核心要点
- 夜莺 V5 开始放弃自研时序库，转向对接 Prometheus、VictoriaMetrics 等现成时序库，背后是项目定位从“大运维平台”收敛到“告警引擎”。
- 作为告警引擎，夜莺不需要自研 TSDB，只需要能查询各类数据源并完成告警判定。
- 夜莺仍然提供指标写入和转发能力，是为了让使用 PUSH 模型的采集器更容易接入，并把数据转存到后端时序库。
- Categraf 的出现，是为了统一零散 exporter 的使用体验，并补充机器元信息、心跳、采集规则下发等能力。
- Categraf 不是夜莺必选项；如果你已经有成熟采集和存储链路，夜莺可以只作为告警引擎使用。
夜莺和时序库对接的设计逻辑
如果是夜莺老用户，应该知道在 V4 以及之前的版本，夜莺有自研时序库。从 V5 开始，夜莺放弃自研时序库，转而对接各类数据源。这个变化背后的核心原因，是项目定位。
V4 之前的版本沿袭了很多 Open-Falcon 的设计逻辑，甚至一度想做一款运维平台。后来发现这样会遇到几个问题：
- 运维平台范围太大，需要投入很多人力，单靠开源社区比较难。
- 运维平台没有统一共识，各家公司或多或少都有自己的额外需求，什么都想往里塞。
- 国内外知名开源项目通常都有清晰、专注的定位；定位越精准细分，越容易做透。
- 社区用户来用夜莺，大多是奔着监控和告警能力来的，而不是奔着完整运维平台来的。
本质上，夜莺做了一个选择：不要做大而全的平台，而是把项目定位收敛到告警引擎。
纵观监控领域，时序库、采集器、可视化工具都有成熟开源项目。唯独统一告警引擎这一块相对缺失，所以夜莺从 V5 开始重点做告警引擎。
为什么告警引擎不需要自研时序库
作为一款告警引擎，夜莺需要的是查询数据并判断异常，不一定需要自己存储所有数据。
因此，从 V5 开始，夜莺不做自己的时序库，而是对接各类现成时序库。整个架构示意图如下：
这个设计的逻辑很清楚：
- Prometheus、VictoriaMetrics 等系统负责指标存储和查询。
- 各类采集器或 exporter 负责采集数据。
- 夜莺负责配置告警规则、查询数据源、生成告警事件和发送通知。
这样做可以减少重复造轮子，也能让用户复用自己已经建设好的监控数据基座。
为什么夜莺仍然提供指标接收和转发能力
上面的架构需要用户自己搞定采集器和存储。以指标场景为例，用户需要自行搞定 Prometheus（或 VictoriaMetrics）加各类 exporter。除了 exporter，社区里还有很多其他采集器。
为了让社区用户更轻松一些，夜莺往前走了一步：虽然不做时序库，但可以接收时序数据，并把数据转存到时序库。
夜莺支持多种采集器，比如 Datadog-agent、Grafana-agent、Alloy、Telegraf，以及后来的 Categraf。不同采集器有不同协议，夜莺支持多种指标写入协议，最终把数据转存给时序库。
架构示意图如下：
夜莺配置文件 config.toml 里有 Pushgw 部分，用于配置后端时序库地址。可以配置多个 Writer，数据会同时转存到多个后端。当然，也可以不配置 Writer，不让夜莺转发数据。
PUSH 和 PULL：两种采集模型
监控数据采集领域，典型有两种模式：PULL 和 PUSH。
- Prometheus 的方式是 PULL：Prometheus 主动抓取 exporter 暴露的指标。
- Datadog、Categraf 的方式是 PUSH：agent 主动把指标推送到服务端。
夜莺提供数据接收 HTTP 端口，是典型的 PUSH 模式。如果你想用 PULL 模式，继续使用 Prometheus + exporter 即可。
PUSH 模式有一个天然难点：较难感知源端是否挂了，也就是 Nodata 告警。既然夜莺选择支持 PUSH 模式，也就专门提供了 Nodata 告警能力。因此，上图中各类 PUSH 类型 agent 如果数据经由夜莺转发，就可以享受 Nodata 告警能力，更方便地知道哪个 agent 挂了。
小结：夜莺和时序库的关系
夜莺的典型用法，是用户自行搞定数据采集和存储，夜莺仅作为告警引擎对接数据源，做告警判定。
如果你也想让数据流经夜莺，建议选择下文介绍的 Categraf 采集器。它和夜莺的整合最为顺滑。
夜莺和 agent 对接的设计逻辑
既然社区已经有很多采集器，为什么还要再做一个 Categraf？
社区使用最多的采集器，大概是各类 exporter。但 exporter 比较零散，体现为：
- 不同 exporter 的设计逻辑不同，有的和监控目标是一对一关系，有的是一对多关系。
- 不同 exporter 的日志打印方式不同。
- 不同 exporter 的传参和配置文件格式各异。
- 有些采集需求没有对应 exporter。
所以，夜莺团队希望做一些整合，搞一个更统一的采集器。
还有另一个重要原因：夜莺除了开源版，还有企业版。企业用户需要一致的产品体验。给企业用户一堆 exporter，不太容易形成统一体验；企业用户还会有各种定制采集需求，提到各个 exporter 项目里响应太慢；同时，企业用户还需要采集规则下发能力。这些需求都需要一个单独的 agent，于是 Categraf 诞生了。
引入 Categraf 之后，架构示意图如下：
Categraf 带来的额外能力
夜莺有了自己的 agent 之后，就带来了额外能力：
- agent 可以采集机器 metadata 信息并上报给夜莺，用户可以在页面上查看。
- agent 和服务端周期性心跳，夜莺可以生成机器列表，类似一个资产台账。当然，自己做 Table 仪表盘也可以达到部分效果。
Categraf 配置文件里会配置两个夜莺接口地址：heartbeat 和 writer。
| 配置 | 作用 |
|---|---|
| heartbeat | 心跳接口，用于告诉服务端自己活着，同时上报机器 meta 信息 |
| writer | 指标推送接口，协议是 Prometheus remote write |
如果 heartbeat 被 Disable，夜莺机器列表里的 CPU、内存等字段会显示 Unknown，点击机器也看不到 metadata 信息。
Categraf 也可以把 writer 直接配置为时序库的 remote write 地址，但这样数据就不经过夜莺，不太推荐。数据经过夜莺，可以更好地和机器列表、Nodata 告警等能力打通。
不想用 Categraf 行不行
可以。夜莺本来就侧重做告警引擎，你自己搞定数据采集和存储完全 OK。
不过，如果是新项目，还是建议使用 Categraf，至少用 Categraf 采集机器 CPU、内存、进程、metadata 等基础信息。这样夜莺的机器列表、心跳、机器元信息和相关体验会更完整。
至于数据库、中间件等监控数据，可以不用 Categraf，继续使用你自己习惯的采集器。
选择建议
| 场景 | 建议 |
|---|---|
| 已经有成熟 Prometheus + exporter 体系 | 夜莺只作为告警引擎即可 |
| 新建监控体系，希望快速打通机器基础指标 | 使用 Categraf |
| 需要机器列表、metadata、心跳和 Nodata 告警 | 使用 Categraf，并让数据流经夜莺 |
| 数据库、中间件已有稳定采集器 | 可以继续使用原采集器 |
| 企业版需要统一采集规则下发 | 使用 Categraf 更合适 |
FAQ
夜莺放弃自研时序库，是不是能力变少了？
不是。夜莺是把项目定位收敛到告警引擎，把时序存储交给 Prometheus、VictoriaMetrics 等成熟系统。这样可以避免重复造轮子，也让夜莺更专注。
夜莺是否必须部署 Categraf？
不必须。夜莺可以直接对接已有数据源做告警判定。Categraf 的价值在于改善机器基础指标采集、心跳、metadata 和采集规则管理体验。
使用 Categraf 时，数据一定要经过夜莺吗？
不一定。Categraf 可以直接写时序库。但如果希望使用夜莺的机器列表、Nodata 告警和更完整集成体验，建议让 Categraf 的 writer 指向夜莺。
总结
在夜莺体系里，最简单的用法是只使用 n9e 进程作为告警引擎。如果有边缘机房场景，可以继续引入 n9e-edge 做边缘机房告警。
Categraf 不是必选项，但使用 Categraf 采集机器基础指标并和夜莺打通，体验会更好。夜莺不自研时序库，却提供 agent 和指标转发能力，看起来有点拧巴，但本质上是两个不同目标：不重复造存储轮子，同时给用户一条更顺滑的采集接入路径。
