title: 夜莺（Nightingale）架构设计与部署模式精简指南
date: 2026-08-07T00:00:00+08:00
lastmod: 2026-08-07T00:00:00+08:00

夜莺（Nightingale）架构设计与部署模式精简指南

夜莺（Nightingale）是一款开源监控告警平台，核心进程为 n9e，依赖 MySQL 和 Redis 存储管理数据，可接入 Prometheus、VictoriaMetrics、ElasticSearch 等多种数据源。

它的架构灵活，从单机测试到大规模生产环境都能覆盖；它的设计偏重告警引擎，商业版 Flashcat 则在此基础上提供了一站式智能观测能力。

一、两种数据流模式

夜莺在数据采集层面支持两种不同的使用方式。

模式 1：数据不经夜莺

这是最常见的使用方式：

用户自行解决数据采集，比如通过 Categraf
只把时序库（如 Prometheus、VictoriaMetrics）配置到夜莺中
夜莺用来看图、配置告警规则

这种模式下，夜莺完全不参与数据采集和存储，只做”告警大脑”。

模式 2：数据经夜莺转发

Categraf 通过 remote write 协议把数据推给夜莺，夜莺不直接存储，而是转发到时序库：

转发目标由 config.toml 中的 Pushgw.Writers 决定
新用户推荐使用 VictoriaMetrics，性能更好、支持集群、与 Prometheus 接口兼容

这种模式适合希望统一收集入口、简化 Categraf 配置的场景。

二、四种部署模式

1. 单节点测试模式

最快的上手方式：

# 从 GitHub Releases 下载发布包后执行
./n9e

默认端口 17000，默认账号 root，密码 root.2020
依赖 etc 和 integrations 目录
配置数据存储在本地 SQLite（n9e.db）
仅供测试，不建议上生产

2. 单节点生产模式

依赖 MySQL 和 Redis，在 etc/config.toml 中配置：

[DB]
DSN = "root:密码@tcp(localhost:3306)/n9e_v6?charset=utf8mb4&parseTime=True&loc=Local"

[Redis]
Address = "127.0.0.1:6379"
RedisType = "standalone"

这是中小规模场景的常规选择。

3. 夜莺集群模式

多台机器部署 n9e 进程，共享同一套 MySQL 和 Redis：

配置文件完全一致
多个 n9e 进程会自动分派告警规则，每条规则只在一个实例上运行
若某实例故障，其他实例会自动接管告警规则
实现告警判定的高可用

4. 边缘模式（n9e-edge）

适用于多机房、网络质量差的场景。

架构特点

中心机房部署 n9e + MySQL + Redis
边缘机房部署 n9e-edge
n9e-edge 从中心 n9e 同步告警规则，缓存到本地内存
告警判定在边缘本地完成，内网连接边缘时序库，可靠性更高
网络断开时，n9e-edge 仍可基于缓存规则继续判定
告警事件写回中心 MySQL，并调用钉钉、飞书等发送通知

数据源配置

在夜莺 WebUI 中配置数据源时，需要注意两点：

时序库内网地址：供 n9e-edge 访问边缘时序库
关联告警引擎集群：指定由哪个 n9e-edge 处理该数据源的告警

n9e-edge 需要独立的 Redis（与中心机房 Redis 不同），边缘机房的 Categraf 应连接本地 n9e-edge。

三、关键配置样例

中心机房 n9e 配置

文件：etc/config.toml

[HTTP.APIForService]
Enable = true
# BasicAuth 用户，供 n9e-edge 连接
[HTTP.APIForService.BasicAuth]
user001 = "修改为安全的密码"
user002 = "修改为安全的密码"

如果 n9e 暴露在公网，务必修改默认密码。

边缘机房 n9e-edge 配置

文件：etc/edge/edge.toml

[CenterApi]
# 中心 n9e 地址
Address = "http://N9E-CENTER:17000"
# BasicAuth 凭证
Username = "user001"
Password = "修改为安全的密码"

[Ibex]
Enable = true
RPCListen = "0.0.0.0:20090"

[Redis]
Address = "127.0.0.1:6379"
RedisType = "standalone"

默认监听端口 19000，可根据需要修改。

边缘 Categraf 配置

[writers]
url = "http://N9E-EDGE:19000/prometheus/v1/write"

[heartbeat]
url = "http://N9E-EDGE:19000/v1/n9e/heartbeat"

Ibex 故障自愈配置

Categraf 的 ibex 配置：

[ibex]
servers = "N9E-EDGE:20090"

注意这里不带 http:// 前缀。

四、其他实用场景

网络分区安全场景也适用 n9e-edge：

某个网络区域只有一台中转机可以连通中心 n9e，其他机器都无法连通。

解决方案：在中转机上部署 n9e-edge，其他 Categraf 连接这个 n9e-edge，即可实现告警管理，而无需每台机器都能直接访问中心。

五、总结

夜莺的架构设计兼顾了简单易用与生产级可靠性：

模式	适用场景	关键特点
单节点测试	本地试用	SQLite、不依赖外部服务
单节点生产	中小规模	MySQL + Redis
夜莺集群	高可用生产	多实例分派规则、故障自动接管
边缘模式	多机房/网络分区	`n9e-edge` 本地判定、缓存继续告警

通过灵活的配置和组件化设计，夜莺能够适应不同网络条件和安全需求，帮助团队解决告警收敛、降噪、排班、认领、升级等闭环管理问题。