夜莺提供的能力

粗粒度能力

采集、存储监控数据，并基于存储的监控数据进行告警和大盘展示。

采集：可使用 Telegraf 或 Prometheus exporter，优先推荐 Telegraf 

存储：可使用 VictoriaMetrics 或 Prometheus 等，优先推荐 VictoriaMetrics 

告警：定期执行 PromQL，若触发阈值则钉钉、微信、邮件等告警

细粒度能力

配置告警规则

屏蔽告警规则

根据告警信息中的标签是否匹配屏蔽规则决定是否屏蔽

订阅告警规则

根据告警信息中的标签是否匹配订阅规则决定是否订阅

使用场景：

若服务部署在 k8s 里，则除了配置服务告警外，还可订阅 k8s 的健康状况告警

查看活跃告警

未处理的告警

查看历史告警

告警自愈

支持 webhook 和 shell 两种方式

业务组/团队/用户管理

每个业务组是自闭环的，每个业务组只需关注本业务组的告警规则即可

即时查询

可通过在页面上输入 PromQL 查看结果

对象视角

可查看目前监控的所有机器

其页面菜单为：

夜莺工作原理

架构图一：

架构图二:

由架构图可知，整体流程为：

1）Telegraf 拉取各硬件/中间件等暴露的监控指标

2）Telegraf 将监控数据推送给 n9e-server

3）n9e-server 将数据写入 TSDB

4）n9e-webapi 定期在 TSDB 中执行 PromQL 并判断是否触发告警规则

5）n9e-webapi 向用户团队发送告警信息

夜莺主要包括两部分：

【n9e-webapi】

对外提供 restful api，用于和前端页面交互；

把用户配置类信息(如告警规则)写入 mysql；

将鉴权 jwt token 存入 redis。

【n9e-server】

接收 Telegraf 等上报的监控数据，并通过 remote write 协议写入多个时序库；

从数据库中同步告警规则，并读取 TSDB 中数据做告警判断；

使用 redis 存储 server 本身及监控对象的心跳信息。

由架构图一可知：

1）一套 n9e-webapi 可对应多套 n9e-server。所以若公司所有 BU 的整体数据量巨大，可为每个 BU 部署一套 n9e-server 集群，这样每套 n9e-server 集群中的数据量将不会太大，计算将不会太慢；这里 n9e-server 集群可使用 Prometheus 存储，若考虑到高可用和可扩展性，则推荐使用 VictoriaMetrics。

2）n9e-server 集群可多写，如除将本集群的数据写入一份本地 TSDB 外，还可写一份到各 BU 大一统的 TSDB 集群中。

夜莺最佳实践

1. 推荐使用 Telegraf 采集监控数据

Telegraf 是 InfluxData 开源的一款采集器，可采集操作系统、各种中间件的监控指标，采集目标列表非常丰富。

Telegraf 是个 all-in-one 的架构，一个二进制可以搞定机器、网络设备、中间件、数据库、Statsd 等各种采集能力，相比散落的各类 Exporter 而言，维护成本更低一些，Telegraf 支持通过 OpenTSDB 这个 output plugin 来对接夜莺。

2. 推荐使用 VictoriaMetrics 作为时序库

VictoriaMetrics 架构简单，可靠性高，在性能，成本，可扩展性方面表现出色，社区活跃，且和 Prometheus 生态绑定紧密。夜莺推荐您在生产环境中使用 VictoriaMetrics 作为时序数据库。

VictoriaMetrics 提供单机版和集群版。如果您的每秒写入数据点数小于 100 万，VictoriaMetrics 官方默认推荐您使用单机版，单机版可以通过增加服务器的 CPU 核心数，增加内存，增加 IOPS 来获得线性的性能提升。且单机版易于配置和运维。

因为 Prometheus 时序存储是单机版，对于大规模场景，推荐使用 VictoriaMetrics 或者 M3DB，因为 M3DB 有些复杂，一般建议使用 VictoriaMetrics，VictoriaMetrics 和 Prometheus 的查询接口完全兼容，所以夜莺也可以对接 VictoriaMetrics，通过 Prometheus 协议的查询接口来查询 VictoriaMetrics 的数据。

大规模集群环境建议的组合方式是 Nightingale+Telegraf+VictorMetrics，简称 NTVM，如果是规模不大，组合方式是 Nightingale+Telegraf+Prometheus，简称 NTP，如果 Telegraf 的采集能力在某些场景下不足，可以用对应场景的 Exporter 来补齐。

3. 接入多个 PROM/VM/M3DB 集群

若整体数据量巨大，则可为每个区域、BU 等分别部署一套 PROM/VM/M3DB 集群，这样每个区域、BU 的数据量将不会太大，可加快执行 PromQL 的执行速度。若需要一份大一统的全量数据，则每套 n9e-server 集群除了写本地 TSDB 外，还可往该聚合 TSDB 库写一份数据。

4. 为每个 BU 设置一个业务组